|
| 1 | +# CW Escrow Vault |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +The CW Escrow Vault is a CosmWasm smart contract that acts as a solver in the UCS03 ZKGM protocol, enabling fungible cross-chain asset transfers between Cosmos and EVM chains. It manages the escrow and release of native and CW20 tokens, serving as the Cosmos-side counterparty to the U.sol contract on EVM chains. |
| 6 | + |
| 7 | +## Purpose in the ZKGM Protocol |
| 8 | + |
| 9 | +In the UCS03 ZKGM protocol, cross-chain transfers use a sophisticated filling mechanism where: |
| 10 | + |
| 11 | +1. **Market Makers/Solvers** can fill orders by providing liquidity on the destination chain |
| 12 | +2. **Acknowledgements** carry information about who filled the order (the beneficiary) |
| 13 | +3. **Base tokens** are sent to the filler as compensation on the source chain |
| 14 | + |
| 15 | +The CW Escrow Vault implements the **ISolver interface** to participate as an automated market maker in this system, creating a fungible lane between chains. |
| 16 | + |
| 17 | +## Architecture |
| 18 | + |
| 19 | +### Key Components |
| 20 | + |
| 21 | +- **CW Escrow Vault (Cosmos)**: This contract - acts as a solver that fills orders with escrowed tokens |
| 22 | +- **U.sol (EVM)**: The EVM counterpart - mints/burns synthetic tokens and acts as a solver |
| 23 | +- **UCS03 ZKGM Protocol**: The cross-chain messaging protocol with open filling mechanism |
| 24 | + |
| 25 | +### Fungible Lane Configuration |
| 26 | + |
| 27 | +Both vaults are configured as solvers where: |
| 28 | + |
| 29 | +- For Cosmos → EVM: Escrow Vault stores U.sol address as `counterparty_beneficiary` |
| 30 | +- For EVM → Cosmos: Escrow Vault returns zero address to trigger token burning |
| 31 | +- When filling orders, the vault returns the appropriate beneficiary in the acknowledgement |
| 32 | +- The source chain either sends base tokens to the beneficiary or burns them (if beneficiary is 0) |
| 33 | + |
| 34 | +## Transfer Flow |
| 35 | + |
| 36 | +### Forward Transfer (Cosmos → EVM) |
| 37 | + |
| 38 | +1. **User initiates transfer**: Sends native/CW20 tokens via ZKGM with a TokenOrderV2 |
| 39 | +2. **Packet sent to EVM**: ZKGM sends packet across IBC to the destination chain |
| 40 | +3. **U.sol fills the order**: |
| 41 | + - Mints synthetic tokens to the receiver |
| 42 | + - Returns CW Escrow Vault address as beneficiary in acknowledgement |
| 43 | +4. **Base tokens sent to vault**: ZKGM on Cosmos sends base tokens to the Escrow Vault |
| 44 | +5. **Tokens held in escrow**: Vault holds tokens for future reverse transfers |
| 45 | + |
| 46 | +### Reverse Transfer (EVM → Cosmos) |
| 47 | + |
| 48 | +1. **User initiates transfer**: Sends synthetic tokens on EVM via ZKGM with a TokenOrderV2 |
| 49 | +2. **Packet sent to Cosmos**: ZKGM sends packet across IBC to the destination chain |
| 50 | +3. **Escrow Vault fills the order**: |
| 51 | + - Releases escrowed tokens to the receiver |
| 52 | + - Returns zero address (0x0) as beneficiary in acknowledgement |
| 53 | +4. **Base tokens burned**: ZKGM on EVM burns the base tokens (synthetic tokens) since beneficiary is 0x0 |
| 54 | +5. **Balance maintained**: Burning on EVM and releasing from escrow on Cosmos maintains token supply |
| 55 | + |
| 56 | +## Implementation Details |
| 57 | + |
| 58 | +### Solver Interface |
| 59 | + |
| 60 | +The contract implements the ZKGM solver interface: |
| 61 | + |
| 62 | +```rust |
| 63 | +pub enum QueryMsg { |
| 64 | + IsSolver, // Returns success to indicate solver capability |
| 65 | + AllowMarketMakers, // Returns true to allow other market makers |
| 66 | +} |
| 67 | + |
| 68 | +pub enum ExecuteMsg { |
| 69 | + DoSolve { |
| 70 | + packet: Packet, |
| 71 | + order: CwTokenOrderV2, |
| 72 | + path: Uint256, |
| 73 | + caller: Addr, |
| 74 | + relayer: Addr, |
| 75 | + relayer_msg: Bytes, |
| 76 | + intent: bool, |
| 77 | + } |
| 78 | +} |
| 79 | +``` |
| 80 | + |
| 81 | +### Order Filling Logic |
| 82 | + |
| 83 | +When `DoSolve` is called: |
| 84 | + |
| 85 | +1. **Intent Validation**: If flagged as intent, checks packet hash is whitelisted |
| 86 | +2. **Lane Validation**: Verifies a fungible lane exists for the (path, channel, token) tuple |
| 87 | +3. **Fee Distribution**: |
| 88 | + - Calculates fee as `base_amount - quote_amount` |
| 89 | + - Sends fee to the relayer |
| 90 | +4. **Token Transfer**: Sends `quote_amount` to the receiver |
| 91 | +5. **Return Beneficiary**: Returns the configured `counterparty_beneficiary` address |
| 92 | + |
| 93 | +### Configuration |
| 94 | + |
| 95 | +#### Setting Fungible Counterparties |
| 96 | + |
| 97 | +```rust |
| 98 | +SetFungibleCounterparty { |
| 99 | + path: Uint256, // Routing path identifier |
| 100 | + channel_id: ChannelId, // IBC channel |
| 101 | + base_token: Bytes, // Token on source chain |
| 102 | + counterparty_beneficiary: Bytes, // U.sol address on EVM |
| 103 | + escrowed_denom: String, // Local token to use for filling |
| 104 | +} |
| 105 | +``` |
| 106 | + |
| 107 | +#### Intent Whitelisting |
| 108 | + |
| 109 | +```rust |
| 110 | +WhitelistIntents { |
| 111 | + hashes_whitelist: Vec<(H256, bool)>, // Packet hashes and approval |
| 112 | +} |
| 113 | +``` |
| 114 | + |
| 115 | +## Security Features |
| 116 | + |
| 117 | +- **Admin-only configuration**: Only admin can set fungible lanes and whitelist intents |
| 118 | +- **ZKGM-only execution**: Only the ZKGM contract can call `DoSolve` |
| 119 | +- **Lane validation**: Orders are only filled for configured fungible lanes |
| 120 | +- **Intent protection**: Intent-based orders require whitelisting |
| 121 | + |
| 122 | +## Benefits |
| 123 | + |
| 124 | +1. **Capital Efficiency**: No need for separate liquidity pools - uses escrowed tokens |
| 125 | +2. **Instant Filling**: Acts as always-available market maker for configured lanes |
| 126 | +3. **Fee Incentives**: Relayers earn fees for submitting packets |
| 127 | +4. **True Fungibility**: Maintains 1:1 backing between native and synthetic tokens |
| 128 | +5. **Trustless Operation**: Smart contract automation eliminates counterparty risk |
| 129 | + |
| 130 | +## Integration |
| 131 | + |
| 132 | +To integrate with the Escrow Vault: |
| 133 | + |
| 134 | +1. **Deploy the vault** with admin and ZKGM contract addresses |
| 135 | +2. **Configure fungible lanes** for each token and channel pair |
| 136 | +3. **Set counterparty beneficiary** to the corresponding vault on the other chain |
| 137 | +4. **Optionally fund the vault** with tokens for filling orders |
| 138 | +5. **Optionally whitelist intents** for pre-approved transfers |
| 139 | + |
| 140 | +The vault will automatically participate as a solver in the ZKGM protocol, filling orders and maintaining fungibility between chains. |
0 commit comments