§17. Layer 3: Identity & Claims

Jason St George. "§17. Layer 3: Identity & Claims" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v2.0. /v/2.0/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. 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 proportional to the value of credentials they issue. 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.

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.

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; receipts embed these proofs in a way that survives platform stripping.

Work credentials for models.
Model stewards prove they own specific weights and that inferences came from those weights under defined parameters.

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, lot sampling, and ZK-wrapped quotes that any verifier can check; 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.

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. Median and tail verify time and cost per standard identity predicate. 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% triggers investigation.

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.

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