Transfer Architecture

As mentioned in the What is Eco? section, the Eco Protocol involves two discrete systems working in concert:

A Cross-Chain Transfer System, which provides developers with secure stablesend/swap pathways between any rollup settling on Ethereum (L2 or L3). This system should enable developers or their end users to opt into speed or trust tradeoffs which best fit their needs.
A Dedicated Eco Rollup, natively integrated with the cross-chain transfer system, optimized for hyper-cheap and lighting-quick stablecoin transactions, with native functionality which makes it easy for app developers to integrate and provide more intuitive UX to end users. We want our rollup to be the default home for apps constructing the onchain payments stack or otherwise defaulting to stablecoins for their use case.

This section goes over the architecture for the Cross-Chain Transfer System.

Cross-Chain Transfer System

The Cross-Chain Transfer System aims to address the issue of fragmented cross-chain liquidity by pioneering a message bridge mechanism that enables cross-chain data passing without introducing new trust assumptions. This is possible because sequencers regularly post L1 roots (e.g., Ethereum's root on Optimism), allowing the use of storage proofs to verify the states of other roll-ups that share the same parent layer.

For the Alpha launch, the protocol has released its intents protocol as an MVP on Optimism and Base. This version of the intents protocol supports cross-chain transfers of stablecoins and like-kind assets between Optimism and Base. This launch positions Eco as the fastest and most trust-minimized way to complete cross-chain stablecoin payments between prominent Ethereum layer 2s.

Participants

The Cross-Chain Transfer System relies on an intent based architecture, where users specify the actions they want to happen on another chain. In the system, there are two actors, users and fillers.

Users are EOAs or smart contract wallets with a need to perform a payment or action on another chain. Typically, these users are using an application that has integrated the transfer system.
Fillers are highly specialized market participants that help users perform cross chain actions for a fee. For the Alpha release of the system, the architecture is optimized for applications that fill intents for their own users.

The following section of the documents will mention some reasonably technical concepts. If you're not familiar with concepts like Storage Proofs, please see the Technical Background section.

High-Level System Architecture From a terminology perspective, the Origin chain is the chain where the User requests the intent and the Destination chain is the chain where the filler executes a transfer request. The system relies on 3 contracts on these chains to manage cross-chain transfers:

IntentSource Contract — lives on the Origin chain and is responsible for the management of intent origination, custody of funds and filler fulfillment. Each chain supported by the Eco Protocol has at least one.
Inbox Contract — lives on the Destination chain and is responsible for the management of intent fulfillment, preventing double fills, and filler whitelisting (for the Alpha). Each chain supported by the Eco Protocol has at least one.
Prover Contract — lives on the Origin chain and is responsible for the management of intent fulfillment proof. Each chain supported by the Eco Protocol has at least one.

Fulfilling a cross-chain transfer request requires 3 basic steps. This example highlights an L2 to L2 transfer fulfillment:

User Originates Request
1. The User locks up funds in the IntentSource contract on the Origin chain. The intent specifies a destination chain and a set of functions that must successfully be called with corresponding calldata, and which prover contract will be used for validating intent fulfillment. For most request, the contracts will be stablecoin contracts and Users will request transfers to specific addresses.
2. If the intent request is successful in the contract, it is assigned a hash identifier, and reward tokens are deposited into the contract.
3. These tokens are a reward for anyone that fulfills the intent in time. If the intent is not fulfilled in time, the tokens can be reclaimed by the User.
Filler Completes Request
1. A Filler sees the intent on the 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 from the original data (which should match the hash on the Origin chain).
2. The 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, stores an address indicating that the call was successful (the hash is the key) and a flag indicating who can claim the funds.
3. Because the hash is unique, the contract prevents anyone else from submitting a fill for an intent with the same hash. This prevents two Fillers accidentally filling the same intent!
Filler Proves Fulfillment
1. The Filler then submits a proof on the Origin chain to the 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.
2. The proof proves that the intent was fulfilled on the Destination chain by proving the relevant storage slot in the Inbox contract using the Destination state root.
3. After proving intent fulfillment, the Filler can claim funds from the IntentSource.

A more detailed diagram of this process is below:

Interoperability

The system is designed to be maximally flexible. All three of the main contracts in the system are designed to be able to be swapped out by users originating intents. This means that the addition of an alternative proof mechanism or alternative logic in the intent source contract, is as simple as deploying different contracts and specifying them in contract calls.

After you've read the Cross-Chain Transfers section, it's worth checking out the Future Considerations section to learn more about how this architecture can be extended.

PreviousRoadmap NextIntent Source Contract

Last updated 10 days ago

Cross-Chain Transfer System

Participants

Users are EOAs or smart contract wallets with a need to perform a payment or action on another chain. Typically, these users are using an application that has integrated the transfer system.

Fillers are highly specialized market participants that help users perform cross chain actions for a fee. For the Alpha release of the system, the architecture is optimized for applications that fill intents for their own users.

The following section of the documents will mention some reasonably technical concepts. If you're not familiar with concepts like Storage Proofs, please see the Technical Background section.

IntentSource Contract — lives on the Origin chain and is responsible for the management of intent origination, custody of funds and filler fulfillment. Each chain supported by the Eco Protocol has at least one.

Inbox Contract — lives on the Destination chain and is responsible for the management of intent fulfillment, preventing double fills, and filler whitelisting (for the Alpha). Each chain supported by the Eco Protocol has at least one.

Prover Contract — lives on the Origin chain and is responsible for the management of intent fulfillment proof. Each chain supported by the Eco Protocol has at least one.

Fulfilling a cross-chain transfer request requires 3 basic steps. This example highlights an L2 to L2 transfer fulfillment:

User Originates Request

The User locks up funds in the IntentSource contract on the Origin chain. The intent specifies a destination chain and a set of functions that must successfully be called with corresponding calldata, and which prover contract will be used for validating intent fulfillment. For most request, the contracts will be stablecoin contracts and Users will request transfers to specific addresses.
If the intent request is successful in the contract, it is assigned a hash identifier, and reward tokens are deposited into the contract.
These tokens are a reward for anyone that fulfills the intent in time. If the intent is not fulfilled in time, the tokens can be reclaimed by the User.

Filler Completes Request

A Filler sees the intent on the 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 from the original data (which should match the hash on the Origin chain).
The 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, stores an address indicating that the call was successful (the hash is the key) and a flag indicating who can claim the funds.
Because the hash is unique, the contract prevents anyone else from submitting a fill for an intent with the same hash. This prevents two Fillers accidentally filling the same intent!

Filler Proves Fulfillment

The Filler then submits a proof on the Origin chain to the 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.
The proof proves that the intent was fulfilled on the Destination chain by proving the relevant storage slot in the Inbox contract using the Destination state root.
After proving intent fulfillment, the Filler can claim funds from the IntentSource.

A more detailed diagram of this process is below:

Interoperability

After you've read the Cross-Chain Transfers section, it's worth checking out the Future Considerations section to learn more about how this architecture can be extended.