UPC Standard (Working Draft)
A working draft of the UPC wire format for compliance attestations. The verifier ABI and registry are live and in use; the envelope schema, subject taxonomy, and lifecycle conventions are proposed here for review.
UPC Standard (Working Draft)
Open working draft: every part on the table, join us
This is the living draft of a wire-format standard for on-chain compliance attestations. We have a preview implementation in open source, IAttestationVerifier, AttestationHub, the ASP list format, a PLONK verifier on EIP-2537 that we use ourselves to build UPP. None of it is final. The interface shape, the field names, the lifecycle conventions, even the cryptographic choices are open to revision based on what integrators, ASP operators, and adjacent-standard maintainers tell us they need.
Our mission: standardize the on-chain compliance envelope, openly, with anyone working on privacy or compliance infrastructure. If that's you, join us! The whole thing is up for debate.
UPC is our open-source attempt at a wire-format standard for compliance attestations on-chain that is the bit of plumbing that lets a policy backend (a KYC provider, a sanctions screen, an accredited-investor verifier, a government list) talk to a privacy protocol (UPP, Privacy Pools, RAILGUN, anything else) without either side caring which the other is.
What's in this section is a working draft. We have a preview implementation running, and a sketch of where the standard should grow. The point of publishing it as a draft is to invite revision. None of it tries to define what the policy should be. That decision belongs to the operator, the regulator, the user, and the jurisdiction. Everything else is open.
UPC sits between policymakers and privacy protocols as a stable wire format. Any compliant backend talks to any compliant protocol through the same standard; like Geth and Nethermind both speaking the Ethereum protocol.
Two tracks, not one
The compliance problem is two problems with different shapes:
- Wire-format standardization - what does an attestation envelope look like, what does the on-chain verifier ABI look like, how does a proof get discovered and routed. The same answer should serve every privacy protocol on every chain.
- Policy and landscape alignment - which checks are required where, who is liable when a check is wrong, what evidence does a regulator need to rely on a result. Per-protocol, per-jurisdiction, per-counterparty. No universal answer.
UPC operates exclusively on track 1. Geth and Nethermind both speak the Ethereum protocol; they don't share a tax position. UPC is the protocol layer for compliance attestations. The policy layer belongs to the operator, the user, the issuer, and the regulator.
This is a deliberate scope choice. If UPC took a stance on policy like "we screen against OFAC", "we are MiCA-compliant out of the box", "approved KYC providers are X, Y, Z", it would stop being a standard and become one more product in an already crowded market.
What the standard defines
The wire format has three pieces:
| Piece | What it is | Status |
|---|---|---|
| Verifier ABI | IAttestationVerifier.verify(): the single on-chain function any backend implements. See Attestation Hub. | Open-source preview |
| Discovery | AttestationHub (per-chain registry of verifiers) and asp-list.json (per-platform list of available ASPs). See Concepts. | Open-source preview |
| Envelope | The structure of an attestation: subject, identity commitment, proof bytes, public inputs, plus draft lifecycle fields. See Envelope. | 4 fields in preview, 5 drafted |
| Lifecycle conventions | Where to gate which check (entry, transfer, exit, audit). UPP's mapping is the worked example. See Lifecycle. | Open by design |
| Coexistence patterns | Bridges to EAS, ERC-3643, Semaphore, WorldID, VC/SD-JWT/BBS+. See Coexistence. | Draft bridge catalog |
The "open-source preview" parts are running code we use ourselves. But they are not finalized, and we'd rather rework them with input than freeze them prematurely. Every cell in this table is open for the working group and integrators to push back on.
The choices we make inside that wire are technical, not political: PLONK over Groth16 (no per-circuit ceremony), BLS12-381 over BN254 (128-bit security), Poseidon hash, LeanIMT, EIP-2537. These are properties of the wire, forced by security and gas constraints, not opinions about whose compliance posture is correct.
What the standard does not define
The standard is silent on every one of these (by design):
- Which compliance inputs to require (KYC, sanctions, accredited investor, jurisdiction, source-of-funds, address risk score, transaction velocity, …)
- Which lifecycle stage to gate (onboarding, deposit, transfer, withdrawal, audit)
- Which jurisdictions to satisfy
- Who bears legal liability when a check is wrong
- Which KYC providers, sanctions lists, or government registries to trust
- Whether attestations are public, private, or selectively disclosed
- What evidence a regulator should accept
These choices belong to the protocol operator, the policy backend, and the user - not to the wire format. UPC will refuse to take a position on any of them, even when asked. That refusal is the standard's value; if it picked winners, integrators couldn't use it across jurisdictions or counterparties.
We do publish opinionated worked examples for how to use the standard. UPP's lifecycle mapping is one such example: gate where value leaves the privacy boundary, not where it enters. Worked examples are recommendations with reasoning. They are not part of the standard, and other privacy systems are free to disagree row by row and still ship against the same IAttestationVerifier.
Coexistence with adjacent standards
UPC slots next to existing standards rather than displacing them.
- EAS (Ethereum Attestation Service) - signed attestations with known attestor and known subject. UPC is the privacy-preserving extension: same idea, subject hidden behind a ZK proof. An EAS attestation can become a UPC tree leaf.
- ERC-3643 (T-REX) - permissioned token standard with on-token compliance modules. UPC sits one layer below: T-REX's
IComplianceModulecan call a UPC verifier. - Semaphore / WorldID / zkPass - alternative ZK identity systems. Each plugs in as an
IAttestationVerifieradapter. - Predicate - transaction-level policy enforcement. Complementary; Predicate's policies can consume UPC proofs as inputs.
- Privacy Pools' ASP / Railgun's PPOI - protocol-specific implementations of the same primitive, each with its own verifier today. The opportunity is for them to consume a shared
IAttestationVerifierso attestation issuers don't need to integrate three times. - VC / SD-JWT / BBS+ - selective-disclosure credential formats. UPC handles set-membership; SD primitives handle attribute disclosure. They compose, they don't compete.