chore(use-cases): audit private-repo and one hop out by rymnc · Pull Request #210 · ethsystems/map

rymnc · 2026-10-21T14:53:28Z

Factual audit of the Private Repo use case and the Private Trade Settlement cards it builds on.

Private Repo

Replace the unsourced volume claims with OFR Brief 26-05: USD 12.7 trillion average daily U.S. repos outstanding (July 2025 to March 2026), split by segment.
Link the Atomic DvP Settlement approach, the Private MMF use case and approach (open question 13) and the Trading domain.
List private-repo in the Atomic DvP Settlement card.

Private Trade Settlement

UTXO DvP:
- Settlement is one JoinSplit per asset, conserving value within each asset.
- Add a trusted-setup assumption where Groth16 is used (Railgun, Paladin Zeto).
- Drop Privacy Pools, which has no two-asset settlement path.
TEE+ZK: Describe what the pattern and the PoC do: each party locks its own note, the TEE checks the terms, and contracts are read over RPC. Remove the cross-chain funds proofs and the bridge-pattern citation.
Intent-Based:
- Cite pattern-oif in place of the bridge pattern.
- Describe ERC-7683 as a Draft that leaves settlement security to each protocol.
Privacy L2: Replace "escape-game exits" with escape hatch.
Business view: Scope MiCA to the EURC leg (Art. 2(4)).
Technical view: Reference the two ERC-7573 patterns in the body.

Patterns

TEE+ZK Settlement:
- Scope the proof to what the circuit checks.
- Separate the atomic key reveal from settlement, which stays timeout-based on any network.
- Add the 2025-2026 memory-interposer attacks on SGX, TDX and SEV-SNP.
Post-quantum fields: separate forgery of proofs and signatures from HNDL on encrypted data, in TEE+ZK Settlement and Cross-Chain Privacy Bridge.
Cross-Chain Privacy Bridge: Link Privacy L2s and Forced Withdrawal under See also.
Privacy L2s: Move the Miden link to 0xMiden/node.

oskarth · 2026-10-21T16:47:42Z

 - 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).


Suggested change

- 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).

- Atomic reveal: the keys for both legs are revealed together (on one network, in the transaction that accepts the proof). Settlement itself is not atomic on any network: after the timeout, refunds compete with unclaimed notes, so each recipient has to claim in time (see Trade-offs).

Suggestion: the claim-or-refund race is the same on one network or several. The refund path only checks the timeout, and the tee_swap SPEC (Phase 4, T3) treats both cases the same. The same tweak would fit the "On one network..." sentence on line 52.

agreed. the refund path checks only block.timestamp > timeout (tee_swap SPEC, Phase 4), and the claim path has no deadline, so the race is the same on one network or several. applied your suggestion, plus the same change on line 52 and on the trade-offs bullet that made the cross-chain-only claim. addressed in 7cace5b

oskarth · 2026-10-21T16:47:42Z

    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"


Suggested change

description: "Across (intents-based cross-chain settlement"

description: "Across (intents-based cross-chain settlement)"

The closing paren got lost.

fixed, thanks. addressed in 7cace5b

oskarth · 2026-10-21T16:47:42Z

 | **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 |


applied. lines 213 and 219 now say "where the protocol requires it" and "where the protocol has it". addressed in 7cace5b

oskarth · 2026-10-21T16:47:42Z

@@ -132,19 +134,19 @@ example_vendors: [aztec, miden]
 maturity: prototyped
 context: i2i
 crops: { cr: medium, o: partial, p: full, s: medium }


Suggested change

crops: { cr: medium, o: partial, p: full, s: medium }

crops: { cr: medium, o: partial, p: partial, s: medium }

Optional, and it was already there before this PR: the pattern says p: partial because the operator sees plaintext. The TEE column in the table on line 237 would follow (P:part).

applied. the operator sees plaintext, so p: partial matches the pattern's crops_context.p and this section's own threat model. the table now says P:part. addressed in 7cace5b

cygnusv

Looks good! Just some minor comments

cygnusv · 2026-10-26T05:38:41Z

 **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.


With one proof per asset, "submitted together" doesn't make the legs atomic by itself. Each proof is valid on its own, so whoever holds both can submit only the leg that pays them. Atomicity comes from binding each proof to the trade, for example to one settlement call that carries both legs, so neither proof verifies alone. A clarification here would be good.

agreed. the text now says each proof is valid on its own, and atomicity comes from binding both proofs to the trade, for example a shared trade hash checked by one settlement call that carries both legs. the private-bond custom-utxo PoC lists this gap as "Missing Swap Binder" (pocs/private-bond/custom-utxo/SPEC.md, limitations section). addressed in 7cace5b

cygnusv · 2026-10-26T05:38:41Z

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


MMF open question 13 covers locking a position for a lender, not substitution, and line 70 already links it. Dropping the parenthetical keeps this question about substitution.

dropped the parenthetical; line 70 keeps the link. addressed in 7cace5b

cygnusv · 2026-10-26T05:38:41Z

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


The front matter also sets secondary_domain: Payments, and private-bonds lists both domains this way:

Suggested change

- **Domain:** [Trading](../domains/trading.md)

- **Domains:** [Trading](../domains/trading.md), [Payments](../domains/payments.md)

applied. addressed in 7cace5b

cygnusv · 2026-10-26T06:38:52Z

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


Great reference for context 👍

rymnc added 2 commits October 21, 2026 20:23

chore(use-cases): audit private-repo and one hop out

277e302

fix: followups

abd603d

rymnc marked this pull request as ready for review October 21, 2026 15:13

rymnc requested review from cygnusv and oskarth as code owners October 21, 2026 15:13

rymnc self-assigned this Oct 21, 2026

Merge branch 'master' into chore/private-repo-cycle

31b13b8

oskarth reviewed Oct 21, 2026

View reviewed changes

cygnusv approved these changes Oct 26, 2026

View reviewed changes

fix: address review on private-repo audit

7cace5b

rymnc merged commit b0e9815 into master Oct 26, 2026
4 checks passed

rymnc deleted the chore/private-repo-cycle branch October 26, 2026 07:57

	- 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).
	- Atomic reveal: the keys for both legs are revealed together (on one network, in the transaction that accepts the proof). Settlement itself is not atomic on any network: after the timeout, refunds compete with unclaimed notes, so each recipient has to claim in time (see Trade-offs).

	description: "Across (intents-based cross-chain settlement"
	description: "Across (intents-based cross-chain settlement)"

	\| Trust model \| Cryptographic \| Sequencer + bridge \| Hardware vendor \| Honest-majority MPC \| Solver collateral + reputation \|
	\| Trust model \| Cryptographic \| Sequencer + bridge \| Hardware vendor \| Honest-majority MPC \| Intent protocol's settlement rules \|

	crops: { cr: medium, o: partial, p: full, s: medium }
	crops: { cr: medium, o: partial, p: partial, s: medium }

	- Domain: [Trading](../domains/trading.md)
	- Domains: [Trading](../domains/trading.md), [Payments](../domains/payments.md)

Conversation

rymnc commented Oct 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Private Repo

Private Trade Settlement

Patterns

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cygnusv left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rymnc commented Oct 21, 2026 •

edited

Loading