Coexistence

UPC's job is the wire format. That makes it explicitly a layer, not a replacement. There are existing standards above and below UPC in the stack — token compliance modules, attestation services, ZK identity systems, selective-disclosure credential formats. UPC connects them; it doesn't compete with them.

This page maps the layering and shows where each adjacent standard plugs in.

Backends — data flowing into UPC

These produce the data that becomes a UPC tree leaf or an IAttestationVerifier adapter input.

EAS

attest.org — Ethereum Attestation Service is the dominant attestation primitive on Ethereum: signed structured-data attestations with a known attestor and a known subject. Use UPC as the privacy-preserving extension.

Bridge pattern: an EAS attestation about an address (e.g. "this address passed KYC at issuer X on date Y") becomes a tree leaf via Poseidon(eas_attestation_uid). The user generates a UPC membership proof; the verifier learns "the prover holds an EAS attestation in this approved set" without learning which one.

Semaphore

semaphore.pse.dev — Semaphore is a ZK group-membership system. A Semaphore group is structurally similar to a UPC ASP tree.

Adapter pattern: a SemaphoreAdapter implements IAttestationVerifier, delegating to the Semaphore verifier. UPC's AttestationHub registers the adapter; consumers query the hub by aspId and get a Semaphore-backed verification without knowing the difference.

WorldID / zkPass

world.org and zkpass.org — both are external ZK identity systems with their own proof formats. They plug in the same way as Semaphore: a WorldIDAdapter or ZkPassAdapter implements IAttestationVerifier and lives in AttestationHub.

KYC providers (Sumsub, Onfido, Persona, etc.)

Off-chain identity services. They publish attestations either as EAS records or as ASP tree memberships (via the ASP service interfaces). Users get a credential off-chain; the credential becomes a UPC-verifiable proof on-chain.

Consumers — the application layer that calls UPC

These call IAttestationVerifier.verify() to gate state transitions on compliance.

Privacy pools

UPP, Privacy Pools, RAILGUN — each pool gates at different lifecycle points (UPP at transfer + withdrawal; Privacy Pools at withdrawal only; PPOI effectively at entry via proof-of-innocence — see Lifecycle for the details). All can call the same UPC verifier. The opportunity for the working group: have multiple pools consume the same ASP root, so an attestation issued once is usable across protocols.

ERC-3643 (T-REX)

eips.ethereum.org/EIPS/eip-3643 — permissioned token standard for tokenized securities. T-REX defines IComplianceModule as the on-token gate; a UPC-backed module calls IAttestationVerifier.verify() before allowing a transfer. The investor proves accredited status via UPC; T-REX enforces the result at every transfer.

Predicate

predicate.io — transaction-level policy enforcement. Predicate's policies are programmable rules over transaction context; one of the inputs a Predicate policy can consume is a UPC proof attached to the transaction. UPC handles the proof; Predicate handles the policy.

Selective disclosure — orthogonal composition

UPC's native question is set membership — binary in/out. For attribute-level disclosure ("prove age ≥ 18 without revealing identity") UPC composes with selective-disclosure credential formats.

VC / SD-JWT / BBS+

• W3C Verifiable Credentials — the conceptual model: an issuer issues a credential, a holder presents it, a verifier verifies.
• SD-JWT — the IETF wire format for selective-disclosure JWTs.
• BBS+ signatures — the cryptographic primitive for unlinkable selective disclosure.

Composition: an SD-JWT credential ("over 18") issued off-chain becomes a UPC tree leaf when the issuer publishes the credential's hash to an ASP. The user proves UPC membership and reveals the SD-JWT disclosure on the side. The verifier validates both — UPC says "this credential is in the approved set", SD-JWT says "this credential's over18 claim is true".

For tighter integration, BBS+ can be embedded as a Circom gadget inside UPC's membership circuit, producing a single composite proof. That's the embedded-gadget composition described in the Envelope page.

Where the same attestation crosses systems

The "Can the same attestation be consumed across multiple privacy systems?" question has a concrete answer when the standard converges:

• An issuer (KYC provider, government registry, exchange) publishes an attestation once.
• The attestation surfaces as both an EAS record and an ASP tree leaf.
• Users can prove against it on UPP, Privacy Pools, RAILGUN, or any UPC-aware protocol — same proof, same verifier ABI.
• A wallet pre-flighting the same proof off-chain uses the same verifier.

The plumbing is already there at the contract level. What's not there yet: a worked end-to-end example with a real attestation crossing two protocols. That's an open task.

What this means for the standard

The coexistence map is the answer to "what needs to be standardized first?":

1. Verifier ABI (IAttestationVerifier.verify()) — done, deployed, in use.
2. Discovery mechanism (AttestationHub, asp-list.json) — done, deployed, in use.
3. Envelope schema (typed fields for issuer, validity, revocation, mode) — proposed, see Envelope.
4. Cross-protocol-reuse worked example — open.

If items 3 and 4 converge, the layering above becomes seamless across the ecosystem. If they don't, UPC still works for any single protocol that adopts it; the standard just doesn't realize its full multi-protocol value.