§17. Layer 3: Identity & Claims

Jason St George. "§17. Layer 3: Identity & Claims" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v3.1. /v/3.1/read/part-iii/17-layer-3/

Layer 3: Identity & Claims

Identity in a repression-prone, AI-saturated internet cannot be “a file with your name on it.” It must be capabilities you can prove on demand (age, jurisdiction, uniqueness, solvency, model ownership) without handing over the dossier.

Reputation should be the trail of receipts from prior correct behavior, not a database of personally identifying facts.

Why Identity Must Decouple from Doxxing

The web’s trust default has flipped: seeing is no longer believing, and platforms strip provenance labels inconsistently [Harwell & Patton 2025]. Accounts and government IDs are brittle anchors; they leak power to gatekeepers.

What scales instead is mechanism over memory: claims backed by cryptographic evidence any honest party can check cheaply and without permission. This is the same shift the thesis makes for money—verification, not authority, is the arbiter.

Design Goals

Identity and reputation in this stack satisfy six goals:

1. Privacy by default, proof by construction. No standing, globally queryable identity graphs. All predicates are proven as needed, most often with zero-knowledge proofs.

2. Selective disclosure and unlinkability. Verifiers learn only the outcome of a predicate, not your name or the rest of your credential bundle.

3. Cheap, public verification. Any honest laptop can check evidence quickly, measured the same way we measure proofs with VerifyPrice.

4. Open admission for issuers and verifiers. Anyone can issue attestations bound to their own reputation and slashing.

5. Hardware honesty for machine identity. Machine claims are anchored in verifiable machines with open designs and sampled supply chains.

6. Lawful privacy. Regulators get provable, time-bounded visibility via receipts and viewing keys, not through custodial chokepoints.

Issuer Pluralism Without Issuer Anarchy

“Open admission for issuers” (goal 4) sounds like chaos: anyone can issue AML credentials, so criminals just issue their own. The resolution is that issuer sets are policy objects, not global permissions.

Issuer sets by policy context:

Issuer sets by policy context.

How issuers enter/exit sets:

1. Stake: Issuers post the base asset as collateral under a defined rule: a fixed per-context floor set by the policy context’s governance, plus a per-credential increment for every credential active (unexpired and unrevoked) in that context, so that the required stake is $S_{\text{floor}} + \delta \cdot N_{\text{active}}$ and is recomputed at each epoch from the issuer’s own published credential count. “Proportional to the value of credentials issued” is not a rule, because that value is not computable; a count of active credentials is. This collateral role is one value-accrual mechanism, not proof of monetary premium. If credentials are later found fraudulent, stake is slashed.

2. Audit receipts: Issuers must publish periodic audit receipts proving their verification processes meet policy requirements. Audits are conducted by independent third parties.

3. Slashing: If an issuer’s credentials are shown to be systematically false (e.g., issuing “not on sanctions list” to sanctioned entities), their stake is slashed and they are removed from relevant issuer sets.

4. Jurisdictional diversity: For high-stakes predicates (AML, accredited investor), issuer sets require representation from $\geq$2 jurisdictions to prevent single-government capture.

How verifiers select policy bundles:

• Verifiers declare which policy contexts they require (e.g., “AML_screened AND Age_verified”).

• The protocol resolves these to issuer sets.

• Presentations must include credentials from issuers in the relevant sets.

• Verifiers can add custom issuer requirements (e.g., “must include credential from Regulator D for EU users”).

Why this isn’t centralization:

• No single issuer is required for any predicate.

• New issuers can join sets by meeting stake and audit requirements.

• Issuer sets are transparent and auditable.

• Users can choose which issuers to use within the set.

This model preserves open admission while ensuring that predicates in regulated contexts are backed by accountable issuers.

The Identity Kernel

We treat identity as a claim machine rather than a name registry.

Identifiers
are cheap, ephemeral, and scoped—pairwise keys or DIDs, not global user IDs.

Credentials
are issued by many parties (exchanges, employers, DAOs, regulators, devices). Each is a capability statement, not a dossier.

Presentations
are one-off proofs of predicates over credentials: membership, attributes in a range, conjunctions of statements. Typically zero-knowledge.

Receipts
are the portable artifacts. Every accepted presentation produces a PIDL receipt binding the claim, proof hash, SLA tier, and timestamps.

This kernel compiles directly into the developer surfaces: PaL SDK to express “prove this predicate,” PIDL receipts to carry results, and privacy corridors to pay without doxxing.

Human Identity: Personhood and Compliance Without Dossiers

What to prove, privately:

• Uniqueness / Sybil resistance. Rate-limited nullifiers, stake-and-slash, or attested-liveness ceremonies.

• Eligibility. Age, residency, licensing, or “member-of a KYC-screened set,” proved with set-membership or range proofs.

• Standing & solvency. Proofs of reserves/income ranges, revealed under viewing keys during credit underwriting.

How it composes with the stack:

A wallet invokes PaL to compile predicates to proofs, pays over privacy rails, and gets a PIDL receipt the counterparty can verify on-chain or in a browser in $<5$s p95.

Sybil Resistance Menu

Sybil resistance (preventing one entity from creating unlimited fake identities) is a core challenge. Different mechanisms offer different tradeoffs; the stack supports a menu of approaches rather than mandating one.

Sybil resistance mechanism menu. VerifyPrice is the cost to the verifier; the cost to the party creating the identity is a separate quantity, and for proof-of-work it is the point.

Tradeoff guidance:

• For maximum privacy: Rate-limited nullifiers + economic PoW. No linkage, but limited action rate.

• For regulated contexts: Stake-based + issuer-set credentials. Some linkage to stake address, but accountability.

• For machine identity: Device attestation bounded by L0 grade. Accept fingerprinting risk for hardware honesty.

• For proof of personhood: Social ceremonies with ZK proofs. Higher coordination cost, but strong Sybil resistance.

Composability:

Mechanisms can be combined. A high-stakes action might require:

1. Rate-limited nullifier (prevents spam),

2. Stake (ensures accountability),

3. Issuer credential (meets regulatory requirement).

Each layer adds cost and reduces privacy; the protocol allows verifiers to specify requirements and users to choose compliant paths.

Machine Identity: Capability, Not Brand

Machines (provers, miners, sensors, model endpoints) need identity, but it should look nothing like a cloud vendor account. Their “identity” is a statement of capability on a particular hardware profile coupled with receipts for past behavior.

When a device participates, it attests to what it is and what it did. Attestations link to open hardware profiles. Those attestations are then wrapped in succinct proofs so any chain can verify them cheaply—and cheaply is all the wrapping buys. The proof establishes that a signature under the vendor’s attestation key exists; the vendor key remains the root of trust for what the attestation says (§14: Layer 0: Verifiable Machines & Energy). The trust a verifier places in “a device of profile $P$” rests on the sampling record and openness grade of $P$, not on the proof around its quote.

This is reputation for robots: SLA-backed capacity that accrues a track record via receipts, not by vendor logo.

Reputation: Priced Behavior, Not Personal Data

• Positive reputation accumulates as fulfilled obligations with proofs: deliveries within SLA, honest inferences, timely settlements, clean audits.

• Negative reputation accrues as rejects and slashes: failed audits, invalid proofs, settlement timeouts.

• Scope and decay are explicit: reputation is contextual and decays unless renewed.

Because receipts are portable and verifiable, reputation becomes a market primitive. A prover can advertise: “over the last 30 days I delivered PROOF_$2^{20}$ within p95 $< 1$s at cost <\0.001$ with 0.04% failure”—and anyone can check.

Patterns That Keep Identity Private and Usable

zK-KYC / zK-AML.
Users prove membership in a regulated allow-list without revealing which issuer or which entry.

Rate-limited actions.
Per-relationship nullifiers cap spam without linking handles.

Credit without doxxing.
A lender demands a proof set plus a bond; the loan contract auto-slashes on missed proofs. No one learns the borrower’s legal name unless escrow triggers.

Creator & data provenance.
Cameras on open hardware sign origin. The signed manifest itself does not survive distribution: C2PA manifests [C2PA spec] travel as file metadata, and most platforms strip metadata on upload—the Washington Post’s 2025 test [Harwell & Patton 2025] found seven of eight platforms did. What survives is a soft binding: a perceptual hash of the content, registered together with the origin proof in the receipt ledger at capture time, so that a stripped copy can be matched back to its receipt by content rather than by metadata. The residual is the analog hole and its digital equivalents—re-encoding, cropping, screen capture—which degrade or defeat perceptual matching; the registry lowers the cost of proving provenance for content that has been stripped, and does nothing for content that has been re-photographed.

Work credentials for models.
Model stewards prove they own specific weights and that inferences came from those weights under defined parameters. The scope of “prove” is bounded by the state of the art: zero-knowledge proofs of inference are practical for small models and for individual layers or sampled operations of larger ones, and frontier-scale ZK inference is a research problem [Peng et al. 2025], not a mechanism this stack can specify. For large models the pattern is therefore attest-and-sample: the steward commits to weights, the serving hardware attests the model hash it loaded (subject to the attestation limits of §14: Layer 0: Verifiable Machines & Energy), and a sampled fraction of inferences is re-executed or algebraically checked by an independent party, with the sampling rate and coverage published as the credential’s assurance level.

Failure Modes & Guardrails

Any identity layer that matters will eventually be attacked. What distinguishes a durable architecture is whether failures are observable, bounded, and repairable without appealing to a central authority.

Centralized attesters.
If one vendor or agency controls machine attestation or anon-cred issuance, identity becomes permissioned by decree. Countermeasure: Pluralism—open hardware profiles and lot sampling, which are the two things that actually reduce dependence on the attester, with ZK-wrapped quotes as the cheap transport for their results rather than a substitute for them (§14: Layer 0: Verifiable Machines & Energy); multiple issuers whose credentials are interchangeable or combined via threshold logic.

Proof cost creep.
If p95 verify time drifts up, only gateways can afford to check receipts. Countermeasure: Treat identity workloads as first-class citizens of VerifyPrice; treat regressions as Sev-1 incidents.

Bridge and settlement doxxing.
If corridors leak metadata, identity collapses into routing tables. Countermeasure: Cryptographic atomicity (adaptor signatures), refund safety, and public settlement telemetry.

Reputation blacklists.
Global “bad lists” are honey traps for political pressure. Countermeasure: Scoped, revocable policies tied to evidence; actors retain the ability to present counter-receipts.

How Identity Fits the Modular Stack

Identity and reputation are just another set of workloads in the same loop:

1. Create / Compute. A human or machine emits a claim: “I am unique and 18+,” “this device captured this video,” “this miner computed MATMUL_4096 under profile P.”

2. Prove. The PaL SDK compiles the predicate into a circuit or useful-work audit, routes it to a prover market, and returns a PIDL receipt. “Circuit” is literal for identity predicates and small models; for large-model inference the compiled object is an attest-and-sample audit (§17: Layer 3: Identity & Claims), because a full ZK circuit for a frontier model is not something PaL can emit today.

3. Settle. The privacy rails kit executes refund-safe payouts across BTC$\leftrightarrow$ZEC/XMR corridors or shielded pools.

4. Verify. Anyone runs verify(receipt) locally, on-chain, or inside another proof.

5. Telemetry. VerifyPrice, anonymity-set size, swap success rates, and hardware-profile distributions are public.

The stack stops being “crypto plus KYC” and becomes one fabric where work, truth, and permission all pass through the same narrow gate: proofs anyone can check.

Identity/Reputation SLOs

For operators and allocators, identity becomes legible through metrics:

• Predicate VerifyPrice. The canonical five-field tuple $(p_{50,t},\, p_{95,t},\, p_{50,c},\, p_{95,c},\, \text{fail})$ per standard identity predicate, i.e. median and tail verify time and cost plus failure rate. Target: p95 under a few seconds, sub-cent cost.

• Unlinkability. Rate at which presentations can be linked by passive adversaries.

• Settlement privacy. Corridor success rates and anonymity-set sizes for identity-linked flows.

• Hardware honesty. Share of machine-signed receipts tied to open profiles.

• Reputation health. Fraction of decisions based on receipts vs. account flags.

Identity $\neq$ name; it is a set of provable capabilities. Reputation $\neq$ biography; it is a ledger of receipts. Bind both to privacy by default, publish VerifyPrice so anyone can check them cheaply, and anchor machine attestations in verifiable hardware.

Implementation Sketch

All of the above shows up in three simple patterns that developers wire into their apps:

Human $\to$ compliance without names.

A wallet encodes a claim like: prove(age $\geq$ 18) $\land$ prove(residency $\in$ EU) $\land$ prove(member_of AML_screened_set). It sends this to PaL, which compiles the predicates, sends them to a prover market, and returns a PIDL receipt. The merchant verifies in $<$5s p95 without ever seeing the passport.

Machine $\to$ capability without brand.

A sensor on hardware profile open_camera_v1 captures video. The device emits an attested capture, PaL wraps it in a succinct proof, producing a provenance proof and receipt. The camera’s “identity” is simply “a device of profile P that has produced N correct receipts.”

Reputation $\to$ receipts, not profiles.

A prover’s handle accumulates receipts. When it advertises itself, it publishes: “Last 30 days: delivered PROOF_$2^{20}$ under SLA Gold with p95 verify-time 0.8s, 99.9% success, zero slashes.” Anyone can pull the underlying receipts and run the reference verifier.

Part III Summary: Minimum Viable Stack

Before proceeding to the economic layers (4–5), we consolidate the minimum viable requirements:

Minimum viable requirements for Layers 0–3.

Telemetry Reproducibility Principle

Telemetry must be reproducible from raw public artifacts by multiple independent parties, or it is not part of the trust base.

Specifically:

1. Raw data availability: All inputs to telemetry metrics are published or archived.

2. Open methodology: Aggregation formulas and statistical procedures are documented.

3. Multi-party verification: At least 3 independent parties publish telemetry; divergence $>$10 percentage points (absolute, between independently computed aggregates) triggers investigation.

Four layers now stand underneath the economic ones: matter that can be audited, packets that survive pressure, code that ships without a gatekeeper, and identity that travels without a name. Each was specified so that its failure is a measurement, not a debate. Part IV asks the only question left for a stack this deep: what work is worth settling on it.

New here? Start with the one-minute version.

Tip: hover a heading to reveal its permalink symbol for copying.