§20. Layer 5: Value & Settlement

Jason St George. "§20. Layer 5: Value & Settlement" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v3.1. /v/3.1/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, no party loses value, and every party has a unilateral no-loss exit within bounded time — an exit that may be a refund of its own leg or a claim on the counterparty’s, depending on which side of the protocol it stands on (§20: Layer 5: Value & Settlement). 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 can be proved about one’s own inputs only:

• “None of my inputs to this transaction is in published exclusion set $E$” — provable as non-membership against a committed set, in the manner of Privacy-Pools association sets [Buterin et al. 2023]. The proof reaches exactly one hop: it says nothing about where those inputs came from before the prover held them.

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

• “Never interacted, at any distance, with blacklisted address $X$” — taint at distance requires global graph knowledge, and the protocol does not have it

• “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$XMR corridors, and a gated BTC$\leftrightarrow$ZEC corridor. Using adaptor signatures, ensuring atomicity. Prior art is directly deployed for BTC$\leftrightarrow$XMR only: the Bitcoin–Monero atomic-swap protocol of Gugger (2020) and its production implementations (COMIT’s xmr-btc-swap [COMIT 2021], UnstoppableSwap [UnstoppableSwap 2025]) are the operative reference, 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. BTC$\leftrightarrow$shielded-ZEC adaptor-signature swaps do not exist in production. Transparent-ZEC HTLCs exist and forfeit privacy on the ZEC leg, which is the leg the corridor exists to protect; a shielded corridor requires scripting or adaptor constructions inside the shielded pool that Zcash does not currently offer [Hopwood et al. 2025]. The ZEC corridor is therefore registered (§19: Layer 4: Truth & Work) and gated on that work: it is a design target, not a route, and nothing in this document counts it toward a minimum viable stack.

• 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, xmr_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:

The v3.0 draft defined refund safety as “both sides can unilaterally reclaim funds,” and the deployed prior art does not give that. The Gugger (2020) BTC$\leftrightarrow$XMR protocol gives no-loss-or-punish, which is asymmetric by construction: Monero has no scripting, so the XMR leg cannot time out on its own. If the BTC-side party goes offline past the refund window, the XMR is unrecoverable by either side and the protocol’s remedy is the punish path, which delivers the BTC to the XMR-side party. Nobody ends the swap poorer than they began it; the exits are not symmetric refunds. The invariant is therefore stated in the terms the protocol actually satisfies:

Refund Safety

A corridor $C$ is refund-safe if, for every transaction $T$ and every party $P$ to it, $P$ has a unilateral no-loss exit available within a bounded time $\tau_C$ from the moment $T$ leaves the happy path — an action $P$ can take without the counterparty’s cooperation after which $P$ holds value at least equal to what it committed (its own leg refunded, or the counterparty’s leg claimed). Formally,

Where:

• $\tau_C$ is bounded and published per corridor (e.g., $\leq 24$ hours for BTC$\leftrightarrow$XMR at current timelocks) and is the sum of the longest refund window and the longest confirmation delay on either chain.

• An exit is unilateral if it requires no counterparty signature after the setup phase. Which exit a party holds (refund or punish) depends on which leg it stands on and is published in the corridor’s profile.

• Success means both legs complete atomically.

• The metric $\text{refund\_safe}(C)$ of §20: Layer 5: Value & Settlement is computed over protocol-attributable failures: a party that has an available no-loss exit and fails to take it within $\tau_C$ (client offline, keys lost) is recorded under a root-cause class and does not count against the corridor, because a hard $1.0$ that trips on user liveness is a metric no corridor with humans on it can hold.

Bridge Safety:

Cross-chain bridges were, in 2021–22, the single biggest loss vector in the industry. Layer 5 imposes:

• No unclassified signer sets. A small permissioned signer set is admissible only as Class B or Class C at the haircuts below, disclosed as such in the profile, and never presented as trustless. The v3.0 draft said “no magic multisigs” and then admitted a 5-of-9 at a 10% haircut; that was rhetoric the table contradicted. The rhetoric is dropped and the haircuts are raised.

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

• Explicit trust classifications reflected in profiles and telemetry.

Bridge trust classification. Liquid’s federation is a set of named functionaries running hardware signing modules; it is not bonded in the sense of posting slashable collateral, and the earlier “bonded” label is withdrawn.

An atomic swap is not a bridge — no asset is represented on a foreign chain, so there is nothing to classify — and the PRK corridors of §20: Layer 5: Value & Settlement are classified as corridors, not under this table. They carry Class-A-equivalent trust (cryptographic only), which is the reason the kit prefers a corridor to a bridge wherever both exist for a pair.

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.

Anonymity is measured per asset, because the assets hide differently.

A single “anon_set $\geq 1000$” was unreachable for one leg and trivial for the other. Monero’s anonymity is per-output: a ring of 16 today (FCMP++, which would make the effective set the whole output set, is pending), so the meaningful metric is ring size times decoy quality — the fraction of rings whose decoys are indistinguishable from the real spend under the published heuristic set. Zcash’s anonymity is pool-wide: the shielded pool’s size times its spend churn over the window, so a pool of a million notes with no spends is a museum, not an anonymity set. The thresholds are:

• XMR leg: ring size at protocol minimum (16) with $\geq 95\%$ of corridor rings passing the decoy-quality heuristic; Sev-1 if decoy quality falls below $80\%$ for 30 days. A “$\geq 1000$” set is not a Monero quantity until FCMP++ ships, at which point the metric is revised to effective set size.

• ZEC leg (when the corridor is admissible): shielded-pool spend churn $\geq 1000$ distinct shielded spends per day on the pool the corridor uses, with corridor volume $\leq 10\%$ of that churn so corridor notes do not stand out; Sev-1 if churn falls below 500 for 30 days.

• BTC leg: the btc_link metric above; Bitcoin has no anonymity set and the corridor’s job is not to make its BTC outputs distinguishable from ordinary spends.

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 no protocol-attributable loss?

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

Disclosure Scope Model:

The v3.0 draft called this a viewing-key scope model and promised four scopes a viewing key cannot deliver. A shared viewing key is knowledge: once given it cannot be revoked, it reads every note the address ever receives rather than a time window, and it reveals every amount rather than only those above a threshold; and hierarchical derivation, whatever it is called, has a root. The scopes are real requirements, and each is met by a different mechanism — only one of which is a viewing key.

Disclosure scope model, with the mechanism that delivers each scope. A scope not on this list is not offered, and a viewing key is the mechanism for exactly one row.

Key management: Users generate and control all disclosure material. There is no revocation of a shared viewing key — it is knowledge, and knowledge is not recalled — so the operative discipline is forward rotation: receiving addresses and their incoming viewing keys rotate per epoch, a disclosed key exposes past epochs only, and future epochs are dark to every past auditee by construction. Derivation is hierarchical from a spending-key root the user holds; that root is a master key for its own tree, which is why it is never disclosed and why per-epoch keys, not the root, are the unit of disclosure.

Minimum Viable Corridor Spec:

Minimum viable corridor requirements. Admission thresholds are deliberately tighter than the Sev-1 thresholds of §20: Layer 5: Value & Settlement: a corridor enters default routing above the target band and is removed from it at the Sev-1 line, so that the two events are separated by a margin rather than a coin flip. The v3.0 table set admission equal to Sev-1 and would have listed corridors at the edge of removal.

Corridors failing the admission thresholds are flagged as “experimental” and excluded from default PRK routing; a listed corridor that crosses a Sev-1 line is handled by the incident path of §22: Layer 6: Governance & Telemetry.

New here? Start with the one-minute version.

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