Repository navigation
Conversation
oskarth
reviewed
Oct 21, 2026
| - 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). |
Collaborator
There was a problem hiding this comment.
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.
| 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" |
Collaborator
There was a problem hiding this comment.
Suggested change
| description: "Across (intents-based cross-chain settlement" | |
| description: "Across (intents-based cross-chain settlement)" |
The closing paren got lost.
| | **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 | |
Collaborator
There was a problem hiding this comment.
Suggested change
| | **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 | |
Suggestion: line 210 now says collateral and slashing are protocol-specific. Lines 213 and 219 could get the same qualifier.
| @@ -132,19 +134,19 @@ example_vendors: [aztec, miden] | |||
| maturity: prototyped | |||
| context: i2i | |||
| crops: { cr: medium, o: partial, p: full, s: medium } | |||
Collaborator
There was a problem hiding this comment.
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).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Factual audit of the Private Repo use case and the Private Trade Settlement cards it builds on.
Private Repo
private-repoin the Atomic DvP Settlement card.Private Trade Settlement
pattern-oifin place of the bridge pattern.Patterns
0xMiden/node.