§20. Layer 5 – Value & Settlement: Privacy Rails & Non-Custodial Flow

Jason St George. "§20. Layer 5 – Value & Settlement: Privacy Rails & Non-Custodial Flow" in Next‑Gen Store of Value: Privacy, Proofs, Compute. Version v1.0. /v/1.0/read/part-iv/20-layer-5/

§20. Layer 5 – Value & Settlement: Privacy Rails & Non‑Custodial Flow

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,
• collateral gets posted or released.

The constraints are harsh:

• Repression‑resilience. Default assumption: yield‑curve control, capital controls, KYC chokepoints, and on‑/off‑ramp throttling.

• Privacy & lawfulness. Users need privacy by default and auditability by consent, without collapsing into “just trust a bank.”

• Non‑custodial safety. Settlement protocols must be self‑custodial and refund‑safe, not custodial wrappers around centralized APIs.

Layer 5’s job is to provide rails that meet those constraints and integrate with Layer 4 and Work Credits.

20.1 Settlement as a first‑class workload

The stack treats settlement itself as a canonical workload:

• Workload type Settlement(S, policy) includes:

  • Chain(s) involved (e.g., BTC, ZEC, XMR, an L2).
  • Transfer size and fee ranges.
  • Corridor routing (direct vs multi‑hop).
  • Policy hooks (KYC attestations, jurisdictional constraints).

• Proofs at Layer 4 can attest that:

  • The settlement followed policy (e.g., “was atomic,” “sender is member of cleared set,” “respected refund timer bounds”).
  • The final state matches an expected before/after set.

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, collateralized, or used as inputs to other contracts.

20.2 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 at protocol level.

2. Refund‑safe.

   • If a swap or corridor transfer fails, both sides can unilaterally reclaim funds after a bounded time.
   • Refund logic is testable and provable (Layer 4), not “trust our support team.”

3. Privacy‑by‑default with optional disclosure.

   • Default flows have strong anonymity sets and shielded contents.
   • Viewing keys and PIDL receipts allow specific flows to be revealed without revealing the graph.

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

20.2.1 Policy = predicates, not surveillance

A common misreading of “lawful privacy” assumes it means “we’ll do chain analysis when regulators ask.” That is not what this thesis proposes. Policy compliance in Layer 5 is achieved through predicate proofs, not graph inspection.

What can be proved (ZK-compatible):

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

Policy as code:

Policies are encoded as ZK-checkable predicate sets. A corridor defines:

CorridorPolicy {
  required_predicates: [
    AML_MEMBERSHIP(sender, approved_issuers),
    AMOUNT_RANGE(value, 0, limit),
    JURISDICTION(sender, allowed_jurisdictions)
  ],
  optional_predicates: [
    TAX_VIEWKEY(auditor_pubkey, valid_until)
  ],
  viewing_key_scope: SELECTIVE  // not UNIVERSAL
}

Users prove predicates at transaction time. Verifiers check proofs. No one inspects the underlying graph.

Viewing keys are for auditors with consented scope:

• Viewing keys reveal specific flows, not the user’s entire history.
• Keys can be time-bounded, amount-bounded, or counterparty-bounded.
• The user (or institution) decides which flows to disclose and to whom.
• Universal tracing is architecturally impossible without breaking the privacy model.

Why this matters:

If “lawful privacy” collapses into “surveil first, prove compliance later,” then:

1. Privacy rails become custodial (someone has to run the surveillance).
2. The “repression-resilient” claim fails (surveillance infrastructure can be co-opted).
3. We’re back to “trust the intermediary”—exactly what the thesis rejects.

Predicate-based compliance preserves privacy by default while enabling verifiable policy adherence. This is the only design consistent with the thesis.

20.3 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↔ZEC/XMR corridors.

  • Using adaptor signatures or HTLC‑like patterns.
  • Ensuring atomicity: either both legs settle or both refund.

• Shielded pools and internal flows.

  • For in‑asset privacy (e.g., ZEC shielded transfers, XMR transfers, shielded pools on L2s).
  • With proofs for policy compliance where needed.

• Conditional payment flows.

  • “Pay address A if proof P of workload W is posted within time T; else refund.”
  • This is the settlement side of Work Credits and proof procurement.

PRK expresses 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)

Under the hood, PRK:

1. Selects appropriate corridors and liquidity providers based on policy and fees.
2. Constructs the required atomic swap or shielded transfer transactions.
3. Uses Layer 4 (PaL) to prove settlement properties as needed.
4. Emits PIDL receipts tying flows to proofs and policies.
5. Updates settlement telemetry (VerifySettle).

20.4 Settlement safety: refund and bridge invariants

Non‑custodial rhetoric is cheap; invariants are not. Layer 5 encodes two critical categories of safety.

Refund safety

For a corridor or swap:

• There exists a unilateral path for each participant to reclaim their initial asset if the other side stalls or misbehaves.

• Refund path is:

  • Time‑bounded (e.g., timelocks),
  • Cryptographically enforced (script conditions, adaptor signatures),
  • Verifiable (Layer‑4 proofs can attest that “refund conditions are reachable”).

Bridge safety

Cross‑chain bridges are historically the single biggest loss vector in crypto. Layer 5 imposes:

• No “magic multisigs”.

  • Bridges must not rely solely on a small, permissioned signer set as the only guard.
  • Any such mechanism is treated as custodial, and flows through it do not count as “privacy rails” in the SoV sense.

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

  • Use on‑chain light clients, zk‑proofs of remote chain state, or multi‑party proofs.
  • Avoid “trust our API” patterns.

• Explicit trust classifications.

  • If a bridge must rely on some centralized element, this is reflected in its profile and telemetry. Work Credits and SoV evaluation can then discount or avoid such flows.

BRIDGE invariants are reflected in bridge‑safety templates: standardized patterns that have been analyzed and whose security assumptions are spelled out.

20.5 VerifySettle: settlement telemetry

If VerifyPrice is Layer‑4’s dashboard, VerifySettle and VerifyReach (from Layer 1) are Layer‑5’s.

VerifySettle tracks:

• Success rates across corridors and settlement types (p50/p95, by size bucket).
• Refund outcomes — how often refunds are exercised, how often they fail, average time‑to‑refund.
• Anonymity‑set health — shielded pool sizes, churn, volume; corridor mixing properties.
• Concentration metrics — top‑N LPs, corridor operators, and their jurisdictional spread.

The goals:

• Detect corridor degradation early (e.g., a major jurisdiction throttling BTC↔ZEC flows).
• Ensure privacy is not an illusion (e.g., anonymity sets aren’t quietly collapsing).
• Give treasuries and allocators a basis for SoV decisions: “this corridor is actually alive and healthy; this one is effectively dead.”

VerifyReach, for Layer 1, complements this:

• Even if a corridor is healthy “in theory,” if users behind certain ISPs or in certain countries cannot reach it, that is a SoV‑relevant fact.
• Joint dashboards (VerifyReach + VerifySettle) show where private settlement is actually available under censorship, not just on paper.

20.6 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 touching centralized exchanges in country C?
  • Do non‑custodial corridors maintain ≥95% success with 100% refund safety?

• Corridor LP exit.

  • If a major liquidity provider disappears, do corridors collapse, or does routing adapt?
  • Are there incentives (via Work Credits or fees) to keep enough liquidity distributed?

• Regulatory attack on privacy.

  • If shielded assets are labeled “high risk” in several jurisdictions, can lawful‑privacy corridors (viewing keys + receipts) keep enough demand on‑chain to sustain anonymity sets?
  • Can regulated entities show compliant behavior without doxxing their entire graph?

If, under these tests, Layer 5 continues to offer private, non‑custodial settlement that can be audited by consent, then Privacy has earned its place as a monetary primitive in practice, not just in prose.

20.7 Minimum viable Layer-5 corridor

Like §19.9 for Layer 4, this section commits to a reference design for Layer 5’s minimum viable corridor—the infrastructure that must work for “Private Money” to be real.

20.7.1 Refund safety invariant (formal)

The non-negotiable property that distinguishes corridors from custodial exchanges:

Refund Safety Invariant

For any corridor C and any transaction T initiated on C:

$\textit{refundSafe}(T) = 1 \iff (T \text{ succeeds} \vee T \text{ refunds within timeout})$

Where:

• Timeout is bounded (e.g., ≤24 hours for BTC↔ZEC).
• Refund means unilateral recovery by the initiating party without counterparty cooperation.
• Success means both legs of the swap complete atomically.

Violation conditions (Sev-0):

• Any transaction where funds are locked indefinitely.
• Any transaction requiring counterparty cooperation to recover.
• Any transaction where timeout exceeds published bound.

Target: refund_safe(C) = 1.0 for all corridors. Any violation is a critical incident.

20.7.2 Corridor health SLOs

Telemetry publication:

• Corridor health metrics published hourly.
• Incident reports for any Sev-1 breach within 24 hours.
• Quarterly corridor audits by independent reviewers.

20.7.3 Viewing key disclosure scope model

Viewing keys enable lawful privacy without universal surveillance. The scope model:

Key management:

• Users generate and control all viewing keys.
• Keys are derived hierarchically; revoking a parent key invalidates children.
• Auditors receive time-limited, scope-limited keys; expiration is enforced cryptographically.
• No “master key” exists that reveals all users’ transactions.

20.7.4 Bridge trust classification

Not all bridges are created equal. Corridors classify bridge trust explicitly:

Rules:

• Corridor operators must declare bridge class for all supported routes.
• Users are shown bridge class before transaction.
• WC-Base minted via Class D bridges is not eligible for protocol rewards or pristine collateral status.

20.7.5 Minimum viable corridor spec

A corridor meets “minimum viable” if:

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

Why this matters:

This section transforms “privacy rails” from a promise into a spec. A reviewer can now ask:

• “Is it really non-custodial?” → Refund safety invariant.
• “Can it actually settle?” → Corridor health SLOs.
• “Is the privacy real?” → Viewing key scope model (no master key).
• “What about bridges?” → Explicit trust classification.

If any of these degrade, the “Private Money” claim is falsified.

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