An overview of the Eco Routes architecture.
IntentSource
Contract — lives on the Origin chain and is responsible for the management of intent origination, intent publication, and solver fulfillment. It deploys Vault
contracts to manage the custody of funds and collateral logic for each intent.
Inbox
Contract — lives on the Destination chain and is responsible for the management of intent fulfillment and prevention of double fills.
Prover
Contract — lives on the Origin chain and is responsible for the management of intent fulfillment proof. Multiple types of prover contracts are currently supported in the Eco Protocol system. Different types of provers enable developers and app users to opt into speed or trust tradeoffs which best fit their needs.
IntentSource
contract on the Origin chain. The intent specifies various details, including the destination chain, a set of functions that must be successfully called with corresponding calldata, the value to send per call, the prover responsible for validating intent fulfillment, and more. In most cases, these requests involve stablecoin contracts, where users request transfers to specific addresses. The user also specifies a set of reward tokens to incentivize the solver to fulfill the intent.
Vault
contract address. IntentSource
utilizes these Vault
contracts to manage the custody of funds and enforce collateral logic for each intent.
Vault
contracts are created using Create2, meaning that their addresses are deterministically computed. Consequently, when an intent request is successfully published, it is assigned a hash identifier that also serves as the address of the corresponding Vault
contract. This mechanism means that users are not required to publish the intent on the same chain where they plan to send the collateral. Instead, users can simply send the collateral to the Vault
contract address, and the Vault
can be deployed at claim time to facilitate either the distribution of rewards to the solver or the refund of funds to the user. This is a similar pattern to how smart contract addresses can be funded before the deployment of the smart wallet logic to the address.
IntentSource
contract on the Origin chain. They call a function on the Inbox
contract on the Destination Chain with the original data the user sent with the request. The contract calculates the hash based on the set of calls (which should match the hash on the Origin chain).
Inbox
contract then executes the specific function calls. At the end of the calls, the Inbox
contract makes sure that all the specified calls were successful, and if so, marks the intent as fulfilled. The intent is marked using a mapping that stores the address credited with the fulfillment, with the hash as the key.
Prover
contract to prove intent fulfillment with storage proofs. The Hyperlane Route uses the HyperProver
contract to prove intent fulfillment.
Prover
contract to claim the funds. The proof uses the L1Block oracle on the L2 to construct a series of Storage Proofs. These proofs derive the state root of the Destination chain and make it accessible in the execution context of the Origin chain.
Inbox
contract using the Destination state root.
IntentSource
, the solver chooses whether they want an instant proof communication or to be added to a batch.
HyperProver
contract.
HyperProver
contract.
IntentSource
. If the intent was not fulfilled in time, the user can reclaim their funds after the end of the lockup period. Because intent source uses Create2 to derministically compute the Vault
contract address, IntentSource
will deploy the Vault
contract to the predetermined address that holds the funds at the time of claim, send the reward tokens to the solver, and then self-destruct the Vault
contract. This ensures that the Vault
contract is only deployed when the solver is claiming funds and allows the user to initiate an intent with as little as a single token send on the source chain.Native Route Transfer Flow
Hyperlane Route Transfer Flow
Eco7683OriginSettler.sol
and the Eco7683DestinationSettler.sol
contracts. These contracts are used to settle intents on the Origin and Destination chains respectively in the interfaces supported by ERC-7683.