§20. Layer 5: Value & Settlement

Jason St George. "§20. Layer 5: Value & Settlement" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v1.9. /v/1.9/read/part-iv/20-layer-5/

Layer 5: Value & Settlement

Layer 4 turns work into truth. Layer 5 turns truth into money movement.

It is the layer where balances change, salaries get paid, cross-asset swaps execute, and collateral gets posted or released.

The constraints are harsh:

Repression-resilience.
Default assumption: yield-curve control, capital controls, KYC chokepoints.

Privacy & lawfulness.
Users need privacy by default and auditability by consent.

Non-custodial safety.
Settlement protocols must be self-custodial and refund-safe.

Privacy Rails and Lawful Obligations

Privacy rails are designed for lawful confidentiality and user-controlled disclosure; they are not framed as tools for evading legal obligations. Some regulatory demands may be incompatible with privacy-preserving systems; in those cases, the protocol acknowledges the tension rather than promising universal compliance. See §24: Legal, Policy, and Jurisdictional Posture for the full legal posture.

Settlement as a First-Class Workload

The stack treats settlement itself as a canonical workload:

• Workload type Settlement(S, policy) includes chain(s) involved, transfer size, corridor routing, and policy hooks.

• Proofs at Layer 4 can attest that settlement followed policy and the final state matches expectations.

This means:

• Layer 5 isn’t “just payments”; it is a proven computation over state transitions.

• Settlement events generate PIDL receipts that can be audited, archived, or collateralized.

Design Constraints for Privacy Rails

Privacy rails must satisfy a tight triangle:

1. Non-custodial. Users never relinquish both principal and unilateral control to intermediaries. Adaptor signatures, HTLC-like constructs, or scriptless scripts enforce this.

2. Refund-safe. If a swap fails, both sides can unilaterally reclaim funds after bounded time. Refund logic is testable and provable.

3. Privacy-by-default with optional disclosure. Default flows have strong anonymity sets; viewing keys allow specific flows to be revealed.

This is where the Privacy Rails Kit (PRK) lives.

Policy = Predicates, Not Surveillance

Policy compliance in Layer 5 is achieved through predicate proofs, not graph inspection.

What can be proved (ZK-compatible):

• Not on sanctions list $\to$ Membership proof: “sender $\in$ AML-cleared set $S$”

• Within limits $\to$ Range proof: “amount $\leq$ $10,000”

• Authorized counterparty $\to$ Set membership proof

• Tax reporting $\to$ Viewing key + receipt disclosure

What cannot be proved (and we don’t try):

• “Did not interact with blacklisted address $X$” — requires global graph knowledge

• “Full transaction history disclosure” — defeats privacy model

• “Real-time surveillance feed” — centralizes and doxxes

The Privacy Rails Kit (PRK)

PRK is the Layer-5 sibling of PaL. It gives builders a way to express pay-for-proof and pay-for-compute intents and execute them over privacy-preserving, non-custodial corridors.

At a high level, PRK supports:

• BTC$\leftrightarrow$ZEC/XMR corridors. Using adaptor signatures or HTLC-like patterns, ensuring atomicity. Prior art is directly deployed: the COMIT-network Monero–Bitcoin atomic-swap construction and its open-source descendants (see Sources, “Privacy Rails”) are the operative reference for cross-chain atomicity over these pairs, and §20: Layer 5: Value & Settlement’s refund-safety invariants are stated so that such corridors can be certified against them rather than merely named.

• Shielded pools and internal flows. For in-asset privacy with proofs for policy compliance.

• Conditional payment flows. “Pay address A if proof P of workload W is posted within time T; else refund.”

PRK exposes intents like:

pay_for_proof(claim_id, max_price, corridor_policy)
execute_corridor(btc_input, zec_output, privacy_policy)
batch_payroll(payroll_blob, corridor_set, audit_policy)

Settlement Safety: Refund and Bridge Invariants

Non-custodial rhetoric is cheap; invariants are not.

Refund Safety Invariant:

For any corridor $C$ and transaction $T$:

Where:

• Timeout is bounded (e.g., $\leq 24$ hours for BTC$\leftrightarrow$ZEC).

• Refund means unilateral recovery without counterparty cooperation.

• Success means both legs complete atomically.

Bridge Safety:

Cross-chain bridges are historically the single biggest loss vector. Layer 5 imposes:

• No “magic multisigs.” Bridges must not rely solely on small, permissioned signer sets.

• Light-client or proof-based validation where possible.

• Explicit trust classifications reflected in profiles and telemetry.

Bridge trust classification.

Rule: Class D custodial bridges are excluded from SoV backing. Assets held via Class D bridges do not count toward collateral or reserve calculations.

VerifySettle: Settlement Telemetry

VerifySettle tracks:

• Success rates across corridors (p50/p95, by size bucket).

• Refund outcomes — how often refunds are exercised and their timing.

• Anonymity-set health — shielded pool sizes, churn, volume.

• Concentration metrics — top-N LPs, corridor operators, jurisdictional spread.

Corridor Health SLOs:

VerifySettle corridor health SLOs.

Layer-5 Stress Tests

Layer 5 earns the label “Value & Settlement” if it can navigate:

On-/off-ramp strangling.
Can users still move value between BTC and privacy assets without centralized exchanges in country $C$? Do non-custodial corridors maintain $\geq 95\%$ success with 100% refund safety?

Corridor LP exit.
If a major liquidity provider disappears, do corridors collapse, or does routing adapt?

Regulatory attack on privacy.
Can lawful-privacy corridors (viewing keys + receipts) keep enough demand to sustain anonymity sets when shielded assets are labeled “high risk”?

Minimum Viable Layer-5 Corridor

Viewing Key Disclosure Scope Model:

Viewing key disclosure scope model.

Key management: Users generate and control all viewing keys. Keys are derived hierarchically; revoking a parent key invalidates children. No “master key” exists.

Minimum Viable Corridor Spec:

Minimum viable corridor requirements.

Corridors failing these requirements are flagged as “experimental” and excluded from default PRK routing.

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