diff --git a/CHANGELOG.md b/CHANGELOG.md index ef5a0ac..485be90 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,8 +4,8 @@ All notable changes to the EthSystems Map are documented here. ## [Unreleased] +- fix: factual audit of the [Private Repo](use-cases/private-repo.md) entry and the Private Trade Settlement cards it builds on. - fix: factual audit of the [Private Identity](use-cases/private-identity.md) entry and the cards one hop out. - - fix: factual audit of the [Private Bonds](use-cases/private-bonds.md) entry and the cards one hop out. In [Private Bonds](use-cases/private-bonds.md) set Trading as secondary domain, add the FHE PoC and the Atomic DvP Settlement approach, correct the PoC RFQ scope, mark ERC-6123 and ERC-7573 Draft and describe ERC-7573 as oracle-conditional settlement that hides no amounts, replace the unsourced HTLC-replacement forecast with the PoCs' actual DvP scope, and link the DvP, crypto-registry and ICMA BDT patterns, the eWpG jurisdiction and sibling bond use cases; in [Private Bonds](approaches/approach-private-bonds.md) refresh the Railgun figure to the project Dune dashboard (~USD 5.7b, Oct 2026), source the Aztec V5 vulnerability to its 2026-08-07 post, describe the PoC whitelist as its compliance hook, set FHE gas to the PoC measurement (~330K per transfer), scope the PoC disclosure claim to what each PoC exercises, and link eWpG, MiCA, the crypto-registry bridge and ERC-7573; in [Verifiable Attestation](patterns/pattern-verifiable-attestation.md) name the EIP-712 vs EIP-191 signing paths, add EAS (MIT) and ONCHAINID (GPL-3.0) licenses, cite ML-DSA (FIPS 204) and EIP-8051 for PQ migration, and note VC Data Model 2.0 Recommendation status; in [ICMA BDT](patterns/pattern-icma-bdt-data-model.md) scope the taxonomy to term-sheet data (no lifecycle event messages), state the royalty-free licence with ICMA-retained IP and replace the 2023 factsheet with the April 2026 FAQ; in [Crypto-registry bridge](patterns/pattern-crypto-registry-bridge-ewpg-eas.md) describe the eWpG register as a decentralised recording system (§4(11), §16) rather than an off-chain notarial store, scope attestation verification to existence, signer and time, replace dead BaFin links with the statute and the current BaFin licensing page and move EAS docs to docs.attest.org; in [DvP via ERC-7573](patterns/pattern-dvp-erc7573.md) state Draft status and that amounts and parties are observable in calls and events; mark ERC-6123 and ERC-7573 Draft and describe ERC-7573 as oracle-conditional settlement in [Private Corporate Bonds](use-cases/private-corporate-bonds.md); move the EAS docs link to docs.attest.org in [Selective Disclosure](patterns/pattern-regulatory-disclosure-keys-proofs.md); link these cards back to Private Bonds - fix: factual audit of the [Private Treasuries](use-cases/private-treasuries.md) entry and the cards one hop out. Fill the empty context section with sourced cash-pooling, transfer-pricing (OECD Chapter X, BEPS Action 13) and Kinexys/JPMD bullets and scope regulatory capital and liquidity reporting to regulated group entities in [Private Treasuries](use-cases/private-treasuries.md); in [Private Payments](approaches/approach-private-payments.md) add the deposit verification cost, note Aztec Alpha and the July 2026 V5 proving-system disclosure, replace the exit-game description of Stateless Plasma with proof-based exits, mark Plasma user proofs as server-side, note that MPC configurations can hide addresses, correct relay-set floors to the PoC spec and state the Resilient Disbursement Rails PoC scope; add FATF R.16 Travel Rule access, the Swift shared-ledger plan and a Resilient Disbursement Rails link in [Private Payments](use-cases/private-payments.md); state GENIUS Act effective date and ERC-7573 Draft status and oracle dependence, and move the Zama link to zama.org, in [Private Stablecoins](use-cases/private-stablecoins.md); date and source the tokenized Treasury market figure (rwa.xyz, 5 Oct 2026) in [Private Money Market Funds](use-cases/private-money-market-funds.md); replace the unsourced Asia municipal-debt line with Hong Kong digital green bonds and Japan's 2026 Local Finance Act amendment in [Private Government Debt](use-cases/private-government-debt.md) - fix(approach): [Private Money Market Funds](approaches/approach-private-money-market-funds.md): Phase 1 review for the MMF approach cycle. Stable- vs floating-NAV yield, aggregates at the fund's cadence, disclosure-key custody instead of threshold NAV opening, investor-side vs portfolio compliance, maturity corrected to `documented`, three new comparison rows, a conditional recommendation, and new open questions (collateral as a future extension). Links: `private-vaults` removed; `erc3643-rwa` and `private-mtp-auth` added. diff --git a/approaches/approach-dvp-atomic-settlement.md b/approaches/approach-dvp-atomic-settlement.md index d8271f0..607163a 100644 --- a/approaches/approach-dvp-atomic-settlement.md +++ b/approaches/approach-dvp-atomic-settlement.md @@ -1,10 +1,10 @@ --- title: "Approach: Atomic DvP Settlement" status: ready -last_reviewed: 2026-06-24 +last_reviewed: 2026-10-21 use_case: private-bonds -related_use_cases: [private-derivatives, private-corporate-bonds, private-government-debt, private-rwa-tokenization] +related_use_cases: [private-derivatives, private-corporate-bonds, private-government-debt, private-rwa-tokenization, private-repo] primary_patterns: - pattern-dvp-erc7573 diff --git a/approaches/approach-private-trade-settlement.md b/approaches/approach-private-trade-settlement.md index b67f1a1..1853044 100644 --- a/approaches/approach-private-trade-settlement.md +++ b/approaches/approach-private-trade-settlement.md @@ -1,7 +1,7 @@ --- title: "Approach: Private Trade Settlement" status: ready -last_reviewed: 2026-08-11 +last_reviewed: 2026-10-21 use_case: private-bonds related_use_cases: [private-derivatives, private-rwa-tokenization, private-corporate-bonds, private-government-debt, private-stocks, private-commodities, private-fx, private-repo] @@ -15,6 +15,7 @@ supporting_patterns: - pattern-dvp-erc7573 - pattern-regulatory-disclosure-keys-proofs - pattern-private-pvp-stablecoins-erc7573 + - pattern-oif pocs: folder: pocs/private-trade-settlement @@ -33,7 +34,7 @@ open_source_implementations: description: "Aztec privacy-native L2" language: TypeScript / Noir - url: https://github.com/across-protocol/contracts - description: "Across (ERC-7683 intents-based cross-chain settlement)" + description: "Across (intents-based cross-chain settlement" language: Solidity --- @@ -67,15 +68,16 @@ maturity: production context: i2i crops: { cr: high, o: yes, p: full, s: high } uses_patterns: [pattern-shielding, pattern-regulatory-disclosure-keys-proofs] -example_vendors: [railgun, paladin, privacypools] +example_vendors: [railgun, paladin] ``` **Summary:** Both counterparties hold assets in a shielded pool; settlement runs as a coordinated JoinSplit that consumes input notes and produces output notes in a single atomic transaction. -**How it works:** Each party deposits to the shielded pool; trade execution is a multi-input, multi-output JoinSplit proven in zero knowledge: bond notes and cash notes are consumed, new owner-rotated notes are created. The verifier contract checks Merkle membership, nullifier uniqueness, and conservation of value across asset classes. Per-note viewing keys enable selective disclosure to regulators. +**How it works:** Each party deposits to the shielded pool; trade execution is one JoinSplit proof per asset, submitted together so both legs settle in one transaction: bond notes and cash notes are consumed, new owner-rotated notes are created. The verifier contract checks Merkle membership, nullifier uniqueness, and conservation of value within each asset. Per-note viewing keys enable selective disclosure to regulators. **Trust assumptions:** - L1 consensus and verifier contract correctness +- If Groth16 is the proof system, per-circuit trusted setup (Railgun, Paladin Zeto) - Gas relayer for liveness on private withdrawals - Per-pool issuer (if KYC-gated entry is enforced) @@ -108,12 +110,12 @@ example_vendors: [aztec, miden] **How it works:** Bond notes and cash notes are native private notes in the rollup's execution model. A private DvP contract call consumes both and produces new notes for each party. Validity proofs settle on L1; Incoming Viewing Keys (IVKs) provide account-level disclosure. **Trust assumptions:** -- Sequencer for ordering (currently centralized in early deployments) +- Sequencer for ordering - Bridge contracts for L1 settlement - Rollup proving system soundness **Threat model:** -- Sequencer outage forces escape-game exits with weakened privacy +- Sequencer outage or censorship leaves users relying on the escape hatch, with weakened privacy - Bridge boundary exposes deposit/withdraw amounts - IVK compromise reveals account-level flows @@ -132,19 +134,19 @@ example_vendors: [aztec, miden] maturity: prototyped context: i2i crops: { cr: medium, o: partial, p: full, s: medium } -uses_patterns: [pattern-tee-zk-settlement, pattern-cross-chain-privacy-bridge] +uses_patterns: [pattern-tee-zk-settlement] poc_spec: pocs/private-trade-settlement/tee_swap/SPEC.md example_vendors: [] ``` -**Summary:** A TEE coordinator matches orders privately, generates zero-knowledge proofs of correct execution, and coordinates cross-chain settlement using stealth addresses with timeout-based refunds. +**Summary:** A TEE coordinator matches orders privately and coordinates settlement on one or more chains by releasing stealth-address keys, with timeout-based refunds. -**How it works:** Counterparties submit encrypted orders to an attested TEE. The TEE matches, validates funds (via cross-chain proofs), and locks notes to stealth addresses on each chain with dual conditions (TEE-revealed key OR timeout refund). On success, the TEE generates a SNARK of correct execution and reveals stealth keys; on failure, both sides reclaim after timeout. EIP-5564 stealth addresses anchor the destination side. +**How it works:** Counterparties submit encrypted orders to an attested TEE, and each locks its note to a stealth address on its own chain with dual spending conditions (stealth-derived key, or owner refund after timeout). The TEE matches the orders and checks that the locked notes fit the agreed terms; the pattern has the TEE prove correct matching in zero knowledge, while the PoC verifies each party's lock proof on-chain and reads both chains over RPC. On success, the TEE publishes the ephemeral keys to an announcement contract and each recipient derives its stealth spending key; on failure, both sides reclaim after timeout. Stealth addresses follow the [EIP-5564](https://eips.ethereum.org/EIPS/eip-5564) construction (the PoC uses a Grumpkin-curve variant). **Trust assumptions:** - TEE vendor and remote-attestation chain - Stealth-address key generation soundness -- Bridge contracts on each chain +- Shielded-pool and verifier contracts on each chain, and the RPC endpoint the TEE reads them through (a light client inside the TEE removes this) **Threat model:** - Hardware vendor can observe plaintext during execution @@ -199,17 +201,17 @@ example_vendors: [] maturity: prototyped context: i2i crops: { cr: medium, o: yes, p: partial, s: medium } -uses_patterns: [pattern-cross-chain-privacy-bridge] +uses_patterns: [pattern-oif] example_vendors: [] ``` **Summary:** Counterparties express settlement intents; competitive solvers fill orders using their own capital across chains, bearing execution risk. -**How it works:** A user publishes an ERC-7683 intent (asset, amount, acceptable rate). Solvers compete to fill the destination leg from their own inventory; the protocol reimburses the winning solver from the source leg after fill. Solver collateral and reputation gate participation. Settlement on the destination chain is fast; source-side reimbursement runs over a slower verification path. +**How it works:** A user opens an intent (asset, amount, acceptable rate) with an intent protocol; [ERC-7683](https://eips.ethereum.org/EIPS/eip-7683) (Draft) standardizes how solvers read such orders, not how they settle. Solvers compete to fill the destination leg from their own inventory; the protocol reimburses the winning solver from the source leg after fill. Any solver collateral, reputation, or slashing rules are protocol-specific. Settlement on the destination chain is fast; source-side reimbursement runs over a slower verification path. **Trust assumptions:** - Solver collateral is adequate for the trade size -- Reputation systems and slashing capture misbehavior +- The intent protocol's settlement and dispute rules capture misbehavior - Source-side proof of fill is verifiable **Threat model:** @@ -233,7 +235,7 @@ example_vendors: [] | **Maturity** | production | documented | prototyped | documented | prototyped | | **Context** | i2i | i2i | i2i | i2i | i2i | | **CROPS** | CR:hi O:y P:full S:hi | CR:med O:part P:full S:med | CR:med O:part P:full S:med | CR:med O:part P:part S:med | CR:med O:y P:part S:med | -| **Trust model** | Cryptographic only | Sequencer + bridge | Hardware vendor | Honest-majority MPC | Solver collateral + reputation | +| **Trust model** | Cryptographic | Sequencer + bridge | Hardware vendor | Honest-majority MPC | Solver collateral + reputation | | **Privacy scope** | Amounts + counterparties + addresses | Full state on L2 | Encrypted coordination, stealth destinations | Strong (MPC) | Intents visible to solvers | | **Performance** | L1 gas; verification cost | L2-internal fees | Enclave speed | MPC rounds | Variable (solver competition) | | **Operator req.** | None (gas relayer optional) | Yes (sequencer) | Yes (TEE coordinator) | Yes (MPC committee) | Yes (solver network) | @@ -245,11 +247,11 @@ example_vendors: [] ### Business perspective -For institutional same-network settlement among known counterparties, UTXO Shielded Pool DvP is the default: production maturity, vendor coverage, and a disclosure interface that maps onto eWpG / MiCA. Privacy L2 Native DvP fits where bond logic is complex and the rollup's decentralization timeline is acceptable. Cross-network settlement carries unavoidable trust: TEE+ZK suits institutions with hardware trust already in scope; MPC/Threshold fits decentralized coordination without hardware vendors; Intent-Based is the suitable choice for asynchronous flows where competitive execution matters more than order privacy. The default is to keep both legs on one network whenever possible; only resort to cross-network when liquidity or regulation forces it. +For institutional same-network settlement among known counterparties, UTXO Shielded Pool DvP is the default: production maturity, vendor coverage, and a disclosure interface to review against eWpG for the bond leg and MiCA for the EURC leg (tokenized bonds that are MiFID II financial instruments fall outside MiCA under Art. 2(4)). Privacy L2 Native DvP fits where bond logic is complex and the rollup's decentralization timeline is acceptable. Cross-network settlement carries unavoidable trust: TEE+ZK suits institutions with hardware trust already in scope; MPC/Threshold fits decentralized coordination without hardware vendors; Intent-Based is the suitable choice for asynchronous flows where competitive execution matters more than order privacy. The default is to keep both legs on one network whenever possible; only resort to cross-network when liquidity or regulation forces it. ### Technical perspective -Same-network settlement is the simpler engineering surface: deploy a verifier and a relayer (UTXO) or rely on rollup primitives (Privacy L2). Cross-network settlement multiplies the surface, TEE attestation chains, MPC committee operations, or solver network integration each carry their own reliability and audit burden. None of the cross-network options offers true atomic settlement; each replaces cryptographic atomicity with a different recovery path: timeout (TEE), slashing (MPC), or solver risk (intent). Realtime proving and based sequencing are the research frontiers that may eventually deliver trustless cross-rollup atomicity but are not production-ready. +Same-network settlement is the simpler engineering surface: deploy a verifier and a relayer (UTXO) or rely on rollup primitives (Privacy L2). Cross-network settlement multiplies the surface, TEE attestation chains, MPC committee operations, or solver network integration each carry their own reliability and audit burden. None of the cross-network options offers true atomic settlement; each replaces cryptographic atomicity with a different recovery path: timeout (TEE), slashing (MPC), or solver risk (intent). ERC-7573 ([DvP](../patterns/pattern-dvp-erc7573.md), [cash-to-cash PvP](../patterns/pattern-private-pvp-stablecoins-erc7573.md)) is a further cross-network option: the locked leg moves only on an oracle-released outcome key, the standard defines no timeout, and its calls and events carry `amount`, `from`, and `to` in the clear. Realtime proving and based sequencing are the research frontiers that may eventually deliver trustless cross-rollup atomicity but are not production-ready. ### Legal & risk perspective @@ -259,7 +261,7 @@ This is a perspective for legal review by the deploying institution, not legal a ### Default -For institutional trade settlement where both legs can coexist on a single network, default to UTXO Shielded Pool DvP on a production shielded pool ([Railgun](../vendors/railgun.md), [Paladin](../vendors/paladin.md), or [Privacy Pools](../vendors/privacypools.md)). Settlement runs as a coordinated JoinSplit; selective disclosure runs through per-note viewing keys; the dispute path is the standard institutional arbitration framework. +For institutional trade settlement where both legs can coexist on a single network, default to UTXO Shielded Pool DvP on a production shielded pool ([Railgun](../vendors/railgun.md) or [Paladin](../vendors/paladin.md)). Settlement runs as a coordinated JoinSplit; selective disclosure runs through per-note viewing keys; the dispute path is the standard institutional arbitration framework. ### Decision factors @@ -279,4 +281,3 @@ Run primary settlement on a shielded pool for liquidity-dense flow; pair with TE 3. **Regulatory acceptance per trust model.** Which trust models (TEE, MPC, economic) satisfy regulatory requirements across jurisdictions? 4. **Solver privacy.** Can intent-based architectures preserve order privacy while enabling competitive execution? 5. **Realtime proving / based sequencing.** Whether synchronous cross-rollup composability can deliver trustless cross-network atomicity within block time. - diff --git a/patterns/pattern-cross-chain-privacy-bridge.md b/patterns/pattern-cross-chain-privacy-bridge.md index f094d67..410884f 100644 --- a/patterns/pattern-cross-chain-privacy-bridge.md +++ b/patterns/pattern-cross-chain-privacy-bridge.md @@ -4,7 +4,7 @@ status: ready maturity: concept type: standard layer: hybrid -last_reviewed: 2026-06-18 +last_reviewed: 2026-10-21 works-best-when: - Moving assets between domains while minimizing linkability. @@ -35,8 +35,8 @@ crops_context: post_quantum: risk: high - vector: "ZK verification of source consensus inherits the underlying SNARK's PQ exposure. Shielded pool commitments and note encryption on the destination carry HNDL risk." - mitigation: "STARK-based bridge proofs and hash-commitment shielded pools. See [Post-Quantum Threats](../domains/post-quantum.md)." + vector: "A CRQC can forge pairing-based SNARK proofs of source consensus and the ECDSA, BLS, or threshold signatures used as finality evidence, which lets an attacker mint unbacked notes. Note encryption on the destination carries HNDL risk." + mitigation: "STARK-based bridge proofs, post-quantum signatures for signature-based finality evidence, and hash-commitment shielded pools with post-quantum note encryption. See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [ERC-20] @@ -111,4 +111,5 @@ Threat model: ## See also -- [ERC-7281: Sovereign Bridged Tokens (xERC20)](https://ethereum-magicians.org/t/erc-7281-sovereign-bridged-tokens/14979) +- [Privacy L2s](pattern-privacy-l2s.md) +- [Forced Withdrawal (L1 Escape Hatch)](pattern-forced-withdrawal.md) diff --git a/patterns/pattern-privacy-l2s.md b/patterns/pattern-privacy-l2s.md index 4bd7340..505dc55 100644 --- a/patterns/pattern-privacy-l2s.md +++ b/patterns/pattern-privacy-l2s.md @@ -4,7 +4,7 @@ status: ready maturity: production type: standard layer: L2 -last_reviewed: 2026-06-17 +last_reviewed: 2026-10-21 works-best-when: - Strong privacy is required beyond value-hiding, including identity unlinkability and programmable access controls. @@ -53,7 +53,7 @@ open_source_implementations: - url: https://github.com/AztecProtocol/aztec-packages description: "Aztec Network: privacy L2 with native shielding" language: "Noir, Rust, TypeScript" - - url: https://github.com/0xMiden/miden-node + - url: https://github.com/0xMiden/node description: "Miden zkVM client-side proving rollup" language: "Rust" - url: https://github.com/ethsystems/pocs/tree/master/pocs/private-bond/privacy-l2 diff --git a/patterns/pattern-tee-zk-settlement.md b/patterns/pattern-tee-zk-settlement.md index 66de1cb..142402c 100644 --- a/patterns/pattern-tee-zk-settlement.md +++ b/patterns/pattern-tee-zk-settlement.md @@ -4,7 +4,7 @@ status: ready maturity: research type: standard layer: hybrid -last_reviewed: 2026-06-18 +last_reviewed: 2026-10-21 works-best-when: - Counterparty risk is the primary concern and atomic settlement is the goal. @@ -31,8 +31,8 @@ crops_context: post_quantum: risk: high - vector: "Settlement proofs based on pairing-friendly curves (Groth16, PLONK with KZG) are broken by a CRQC; encrypted state blobs held by enclave operators face Harvest-Now-Decrypt-Later risk." - mitigation: "STARK-based settlement proofs with hash commitments. See [Post-Quantum Threats](../domains/post-quantum.md)." + vector: "A CRQC can forge settlement proofs based on pairing-friendly curves (Groth16, PLONK with KZG). Orders encrypted to an elliptic-curve enclave key and encrypted state blobs held by enclave operators face Harvest-Now-Decrypt-Later risk, and a CRQC can recover the ECDH secrets behind published stealth-address announcements, linking outputs to recipients." + mitigation: "STARK-based settlement proofs with hash commitments, and post-quantum key exchange for order encryption. See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [EIP-5564, ERC-20, ERC-3643] @@ -49,7 +49,7 @@ open_source_implementations: [] Coordinate private settlement inside a Trusted Execution Environment while anchoring correctness with a zero-knowledge proof verified on-chain. The enclave acts as a neutral synchronization layer between parties who do not trust each other: it matches orders, manages escrow state, and produces a succinct proof of correct execution. External observers see only commitments, proofs, and stealth-address outputs, while the enclave operator sees plaintext under contractual terms. -The key property is the separation of financial risk from privacy risk. The zero-knowledge proof guarantees atomic settlement and state-transition correctness on-chain regardless of enclave integrity, so counterparty risk is bounded by the protocol rather than by hardware trust. If the enclave is compromised, trade details leak but funds are not lost and settlement correctness is preserved. In institutional settings, this residual privacy exposure is managed through contractual controls (non-disclosure agreements, audit rights, penalties) with the enclave operator. +The key property is the separation of financial risk from privacy risk. The zero-knowledge proof attests that the state transition follows the rules the circuit checks, and the on-chain verifier rejects any settlement without a valid proof, so a compromised enclave cannot settle a transition the circuit rejects. On one network, the keys for both legs are revealed in the transaction that accepts the proof; across networks, atomicity falls back to timeout refunds (see Trade-offs). If the enclave is compromised, trade details leak, but the circuit and the timeout path keep locked funds from being lost. In institutional settings, this residual privacy exposure is managed through contractual controls (non-disclosure agreements, audit rights, penalties) with the enclave operator. ## Components @@ -76,7 +76,8 @@ The key property is the separation of financial risk from privacy risk. The zero Guarantees: - Counterparties, amounts, and matching logic are hidden from network observers; inside the enclave the operator can see plaintext under contractual terms. -- Atomic settlement: the zero-knowledge proof guarantees correct execution on-chain regardless of enclave integrity, so financial correctness is independent of hardware trust. +- Settlement correctness: the on-chain verifier accepts only state transitions that the circuit proves valid, whether or not the enclave is intact. The proof covers only what the circuit checks: confidentiality, liveness, and the choice of which orders reach matching still depend on the enclave and its operator. +- Atomicity on one network: the keys for both legs are revealed in the transaction that accepts the proof, and recipients claim before the timeout opens the refund path. Across networks, atomicity is timeout-based (see Trade-offs). - Rollback safety: nonce monotonicity is enforced inside the circuit and anchored to an on-chain state root. - Liveness floor: the timeout refund circuit ensures original owners can reclaim locked notes if the enclave goes offline. - Auditability: viewing keys can disclose scoped data to regulators without exposing the full state. @@ -85,8 +86,9 @@ Threat model: - Soundness of the zero-knowledge proof system and correctness of the on-chain verifier. - Attestation integrity: counterparties must verify the hardware signature, the code measurement, and the revocation status before encrypting orders. -- Semi-honest enclave operator: a fully malicious operator can leak plaintext, reorder, delay, or drop messages, but cannot alter settlement outcomes because the proof is verified on-chain. +- Semi-honest enclave operator: a fully malicious operator can leak plaintext, reorder, delay, or drop messages, but cannot settle a state transition that the circuit rejects, because the proof is verified on-chain. - Side-channel attacks on the underlying hardware (Spectre-family, cache-timing) can leak partial data even when attestation succeeds. +- Physical memory-bus attacks by whoever hosts the hardware: low-cost DRAM interposers have read enclave memory or forged attestation on Intel SGX, Intel TDX, and AMD SEV-SNP ([Battering RAM](https://batteringram.eu/) and [WireTap](https://wiretap.fail/), 2025; [TEE.fail](https://tee.fail/), 2025; [DDRop](https://research.google/pubs/ddrop-generic-memory-interposer-attacks-on-confidential-vms-by-dropping-ddr5-writes/), 2026). Intel and AMD treat these attacks as outside their threat models, so a valid attestation report does not exclude an operator with physical access. - Metadata leakage: packet sizes, timing, and connection patterns can reveal trade magnitudes and enable front-running; padding and constant-time processing are required. - Supply-chain tampering on the hardware is out of scope for the protocol and must be handled at sourcing time. diff --git a/use-cases/private-repo.md b/use-cases/private-repo.md index 25b7db4..e94bb4c 100644 --- a/use-cases/private-repo.md +++ b/use-cases/private-repo.md @@ -7,7 +7,7 @@ secondary_domain: Payments ## 1) Use Case -Tokenized repurchase agreements where counterparties and transaction amounts must remain confidential. Repo is short-term secured lending - conceptually similar to DeFi over-collateralized lending, though TradFi has used this instrument for decades. The intraday lending market processes enormous volumes daily through centralized infrastructure. Privacy prevents counterparty exposure and funding cost arbitrage. +Tokenized repurchase agreements where counterparties and transaction amounts must remain confidential. Repo is short-term secured lending - conceptually similar to DeFi over-collateralized lending, though TradFi has used this instrument for decades. In the U.S. alone, repos outstanding averaged about USD 12.7 trillion a day from July 2025 to March 2026, much of it centrally cleared or settled tri-party ([OFR](https://www.financialresearch.gov/briefs/2026/08/18/closer-look-us-nccbr-market/), 2026-08-18). Privacy prevents counterparty exposure and funding cost arbitrage. ## 2) Additional Context @@ -54,18 +54,20 @@ Visible funding costs and patterns enable competitors to undercut pricing or fro See [approach-private-trade-settlement.md](../approaches/approach-private-trade-settlement.md) for general settlement architecture. Repo-specific considerations: - Privacy-preserving collateral verification -- Atomic settlement with privacy (similar to DvP patterns in [approach-private-bonds.md](../approaches/approach-private-bonds.md)) +- Atomic settlement with privacy (similar to DvP patterns in [approach-private-bonds.md](../approaches/approach-private-bonds.md)); see [Approach: Atomic DvP Settlement](../approaches/approach-dvp-atomic-settlement.md) for the settlement leg - Integration with existing clearing infrastructure ## 6) Open Questions - How do intraday settlement requirements interact with privacy mechanisms? - What's the migration path from centralized repo infrastructure? -- How to handle collateral substitution with position privacy? +- How to handle collateral substitution with position privacy? (Locking a hidden position in favour of a lender is open question 13 in [Approach: Private Money Market Funds](../approaches/approach-private-money-market-funds.md#open-questions)) ## 7) Notes And Links - Related: [private-bonds.md](private-bonds.md) (collateral type, DvP patterns) - Related: [private-stablecoins.md](private-stablecoins.md) (cash leg privacy) -- Market context: Major clearing infrastructure processes billions daily in repo transactions +- Related: [private-money-market-funds.md](private-money-market-funds.md) (MMF shares as confidential collateral; see open question 13 in [Approach: Private Money Market Funds](../approaches/approach-private-money-market-funds.md#open-questions)) +- **Domain:** [Trading](../domains/trading.md) +- Market context: U.S. repos outstanding averaged about USD 12.7 trillion a day from July 2025 to March 2026: USD 3.6 trillion centrally cleared, USD 3.1 trillion tri-party, USD 1.1 trillion cleared and tri-party, and USD 5.0 trillion non-centrally cleared bilateral ([OFR Brief 26-05](https://www.financialresearch.gov/briefs/2026/08/18/closer-look-us-nccbr-market/), 2026-08-18) - Analogy: Conceptually similar to DeFi over-collateralized lending (not flash loans, which are uncollateralized and same-transaction)