§20. Layer 5: Value & Settlement

Jason St George. "§20. Layer 5: Value & Settlement" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v3.2. /v/3.2/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 on testnet with no mainnet activation date set as of this writing), 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.