Applicable to Private Bonds and Private Derivatives.
Overview
Settlement risk occurs when one party delivers an asset without receiving payment, or vice versa. This approach documents multiple mechanisms for achieving atomic settlement where both legs complete or neither does, eliminating counterparty risk. Single-network vs cross-network atomicity: On a single network (L1 or L2), atomic settlement is an inherent property of blockchain transactions—a smart contract can execute both legs in one transaction, making atomicity straightforward. Cross-network settlement (e.g., L2↔L2 or L1↔L2) is fundamentally harder: trustless atomicity across independent chains remains an open research problem. Current cross-network approaches rely on trusted intermediaries, oracles, or optimistic assumptions. Relationship to Atomic DvP via ERC-7573: The ERC-7573 pattern (draft; requires trusted oracle) specifically addresses cross-network coordination. This approach is more general, documenting the core atomicity mechanisms (HTLCs, escrow, oracles) that work on single networks or can be composed with ERC-7573 for cross-network scenarios.TLDR for Different Personas
Business
Business
Eliminates settlement risk - both legs complete or neither does. Reduces counterparty exposure and enables trustless settlement with unknown parties.
Technical
Technical
Multiple implementation options: HTLCs for trustless atomic swaps, escrow with dual approval for institutional workflows, oracle-based for event-driven settlement. Can integrate with EIP-6123 for derivatives.
Legal
Legal
Clear failure modes and timeout behaviors for dispute resolution. Deterministic outcomes based on explicit conditions. Automatic recovery paths when settlement fails.
Architecture and Design Choices
Payment Locking Mechanisms
- Hash Time-Locked Contracts
- Escrow with Dual Approval
- Conditional Transfer with Oracle
Payment locked with hash; released when preimage revealed
Preimage revelation unlocks both legs simultaneously
Automatic refund if preimage not revealed within window
Cross-chain atomic swaps, trustless counterparties
Escrow Conditions
Time-Based Conditions
Time-Based Conditions
| Condition | Description | Example |
|---|---|---|
| Settlement Date | Release on specific timestamp | T+2 bond settlement |
| Lock Period | Minimum hold before release allowed | Vesting schedules |
| Expiry | Automatic return if not settled by deadline | Failed trade cleanup |
Event-Based Conditions
Event-Based Conditions
| Condition | Description | Example |
|---|---|---|
| Payment Confirmation | Release when payment finality confirmed | Bank transfer clearing |
| Regulatory Approval | Release when compliance check passes | Cross-border settlement |
| Multi-sig Threshold | Release when N-of-M parties approve | Committee settlement |
Value-Based Conditions
Value-Based Conditions
| Condition | Description | Example |
|---|---|---|
| Price Bounds | Settlement only if price within range | Limit orders |
| Collateral Ratio | Release only if collateralization maintained | Margin calls |
| Net Settlement | Batch and net multiple obligations | Clearing house |
Integration with EIP-6123 (Derivatives)
For derivative contracts using EIP-6123 lifecycle management:| Lifecycle Event | DvP Integration |
|---|---|
| Trade Confirmation | Lock initial margin in escrow |
| Valuation Update | Adjust escrow based on mark-to-market |
| Margin Call | Conditional release requires margin top-up |
| Settlement | Final exchange of payment vs position closure |
| Early Termination | Escrow handles close-out netting |
Protocol Flow
Recommended Components
- Standards: ERC-20 or ERC-721 for asset and payment tokens; ERC-7573 (draft) for cross-network coordination; EIP-6123 for derivative lifecycle
- Infrastructure: Escrow smart contract with conditional release logic; time-lock or hash-lock primitives; event listeners for settlement triggers
- Settlement: Asset token contract (security, bond, derivative position); payment token contract (stablecoin, tokenized deposit, CBDC); settlement coordinator (on-chain or hybrid)
Trade-offs and Open Questions
Guarantees
Settlement Atomicity - Both legs complete or neither completes; no partial settlement
Counterparty Risk Elimination - Assets locked in escrow, not held by counterparty
Deterministic Outcomes - Clear conditions define exactly when settlement occurs
Timeout Safety - Automatic recovery path if settlement conditions not met
Trade-offs
Failure Modes
| Failure | Impact | Mitigation |
|---|---|---|
| Oracle failure | Settlement blocked | Multi-oracle consensus, manual fallback |
| Network congestion | Timeout before settlement | Generous timeout windows, priority fees |
| Escrow bug | Asset loss | Formal verification, audits, insurance |
| Counterparty disappears | Delayed recovery | Automatic timeout refunds |
| Condition ambiguity | Disputed settlement | Precise condition specification, arbitration |
Example: Bond Purchase with Tokenized Deposit
Lock Bond
A locks bond tokens in escrow contract with conditions: release to B if €1M EURC received, timeout in 24 hours.
Related Resources
Atomic DvP via ERC-7573
Cross-network DvP coordination
ERC-3643 RWA Tokenization
Compliant security tokens
MPC Custody
Secure key management for escrow
Commit and Prove
Privacy-preserving condition verification
References
- EIP-6123 spec - Smart Derivative Contract standard
- ERC-7573 spec - Cross-network settlement standard