A Comprehensive Technical Overview of Eco Routes

Eco Routes, the Eco Protocol’s permissionless cross-chain liquidity layer, is designed to streamline onchain UX, starting with stablecoins. Routes is part of the Eco Protocol and simplifies the underlying complexity of managing stablecoins across Ethereum and its Layer 2s — enabling users to easily use their preferred stablecoins on Eco-integrated apps, regardless of the chain that it’s natively deployed.

We’ll explore how Eco Routes works under the hood and break down its technical components — starting from higher-level system mechanics and then explaining the design decisions made for the Routes that are live today: Native and Hyperlane Routes. For a less technical overview, read the Eco Launches Routes in Beta to Prepare for V1 Launch press release here.

Powering Eco Routes with an Intent-Centric Architecture

Instead of requiring users to figure out how to transfer assets across chains, Routes simplifies complex onchain actions. This allows users to accomplish specific goals onchain, allowing them to focus on the desired outcome and leaving the execution of the task to someone else, like a solver. This approach is called intent-centric architecture and now is a well-understood mechanism for executing cross-chain transactions.

Many areas of the economy already operate on intent-centric principles. For example, before Uber, someone needing a ride to the airport had to handle all the details—choosing a cab company, negotiating the rate, scheduling a specific driver, and coordinating the time. Today, someone using Uber simply specifies their destination, and Uber handles the rest: selecting a driver, finding the best route, and optimizing the cost.

The blockchain industry is undergoing a similar transformation. A user trying to move funds from Chain A to Chain B must find a suitable bridge, identify the best price, sign multiple transactions, and switch networks to complete the transfer or swap. Eco uses intents to address this problem by enabling users to express requests like, “Please send Alice 10 USDC on Optimism,” with a single signature. The network then handles the routing, pricing, and completion details seamlessly.

Eco Routes Architecture and Full Transfer Flow

Routes implements an intent-centric architecture specifically for stablecoin transfers and swaps. While the system is designed to be extensible and support many actions beyond simple stablecoin transfers, this post will focus solely on scenarios where the user requests stablecoin transfers (or where an outcome can be composed into a simple stablecoin transfer).

Participants in the System

There are two key participants: Users and Solvers. 

• Users are technically EOAs or smart contract wallets that want to make a payment or transfer to another chain. These users interact with applications that have integrated Routes.
• Solvers are market participants who help execute these user requests in exchange for a fee. Currently, solvers are often contracted on a per-application basis to provide order fills. However, they will soon participate in an open quoting process, competing for transfer volume to offer the most efficient solutions. Applications can also elect to provide their own liquidity.

High-Level Transfer Architecture

The transfer process begins when a user requests a transfer from an Origin Chain and specifies actions to be completed on the Destination Chain. The system relies on three contracts deployed across the Origin and Destination Chains to facilitate this process.

• IntentSource Contract — Deployed on the Origin Chain, this contract manages request origination, custody of funds, and the rewarding of collateral to solvers who successfully complete requests.
• Inbox Contract — Deployed on the Destination Chain, this contract handles the management and accounting of request fulfillment while preventing double fills.
• Prover Contract — Deployed on the Origin Chain, this contract manages the proof of request fulfillment. Multiple types of prover contracts are supported, allowing developers and app users to choose between cost, speed, and trust tradeoffs that best fit their needs. The currently supported prover methods are:
  • Native Route: This method uses storage proofs to verify the fulfillment of a request on the Origin Chain. At a high level, the prover leverages the exposed L1 state on the L2 to confirm that the request was fulfilled on the Inbox Contract on the Destination Chain. 
  • Hyperlane Route: This method uses Hyperlane to communicate the successful fulfillment of a request to the HyperProver Contract on the Origin Chain.

A complete transfer request involves all of these contracts working together to coordinate the creation, fulfillment, and settlement of the request. For example, if Alice transfers 10 USDC from Base to Bob on Optimism, the process follows these four steps:

1. Alice Originates Request:
   1. Alice requests a transfer by locking up funds in the IntentSource contract on the Origin chain. The request specifies a destination chain, a set of functions that must successfully be called with their corresponding calldata, and which prover will validate request fulfillment. In this instance, Alice would request that the solver call transfer(Bob_Address,10000000) on the USDC contract and would select the Hyperlane Route.
   2. If the request is successfully accepted by the contract, it is assigned a hash identifier, and Alice deposits reward tokens into the contract for custody.
   3. These tokens are a reward for anyone who fulfills the request in time. If the request is not fulfilled in time, Alice can reclaim the tokens after the _expiryTime, also specified in the request.
2. Solver Completes Request
   1. A solver sees Alice’s request on the IntentSource contract on the Origin chain. They call a function on the Inbox contract on the Destination Chain with the original data Alice sent with the request. The contract calculates the hash based on the set of calls; this hash 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, marks the request as fulfilled. In this instance, the Inbox contract will check if Bob was transferred 10 USDC. 
   3. The request is marked using a mapping that stores the address credited with the fulfillment, with the hash as the key. Because the hash is unique, the contract prevents anyone else from submitting a fill for a request with the same hash. This prevents two solvers from accidentally filling the same request!
3. Solver Proves Fulfillment
   1. As mentioned, the system currently supports two Routes: the Native Route and the Hyperlane Route. In this instance, Alice selected the Hyperlane Route.
   2. During the fulfillment on the IntentSource, the solver chooses whether to send the proof through the Hyperlane Route immediately or to include it later with a batch. 
      1. Instant Proof: If the instant fulfillment was selected, Hyperlane immediately sends a message that marks the request as proven on the Origin chain in the HyperProver contract.
      2. Batched Proof: If the batch fulfillment was selected, the request is relayed in a batch by Hyperlane, which batches multiple request fulfillments into a single message and marks them all as proven in the Hyperprover contract. This allows the solver to save significant cost. 
   3. In this scenario, the solver chooses instant fulfillment, so the request proof is relayed back to the Origin chain by Hyperlane and marked as fulfilled!
4. Solver Claims Reward
   1. After the request is marked as fulfilled in the relevant Prover contract, the solver can claim Alice’s funds from the IntentSource. If the request was not fulfilled in time, Alice can reclaim her funds after the end of the lockup period.

Key Differences Between The Native Route vs. The Hyperlane Route

Routes provide tradeoffs between speed, cost, and security. Having multiple Routes allow users to opt into different tradeoffs depending on their preferences. Beyond the Native and Hyperlane Routes, more prover methods will be added in the future.

Native Route

The Native Route uses storage proofs to verify the fulfillment of a request on the Origin Chain. This is possible because OP Stack Rollups expose the L1 Blockhash in their execution environment, allowing the verification of storage roots from other chains.

The Native Route breaks a request proof into the following steps:

1. Prove the Settlement Layer root
2. Prove the Destination Chain root (e.g., Bedrock or Cannon)
3. Prove the fulfillment of the request on the Inbox contract

This approach is compelling because it enables the state of the Inbox contract on another chain to be proven without requiring additional trust assumptions beyond those of the two chains. As a result, the Native Route is a great option for prioritizing security. 

While storage proofs are trust-minimized, they come with some disadvantages that currently make them suboptimal for low-value cross-chain payments, particularly in speed and cost.

• Higher cost: Storage proofs require a large amount of calldata, which makes the end-to-end cost of request fulfillment an order of magnitude higher than a simple message relay. While this overhead is reasonable for high-value stablecoin transfers, it becomes prohibitive for everyday, low-value payments (at least within the constraints of existing rollup stacks). 
• Speed: Secure storage proofs depend on sequencer finalization before releasing collateral. For example, in the Bedrock implementation of the OP Stack, sequencers post their roots approximately once an hour and take 4–7 days to finalize. As a result, Solvers must wait that long to reclaim their funds, and charge higher fees to compensate for opportunity costs and the inefficiency of locked funds.

While storage proofs provide strong security guarantees and a failsafe “fallback” mechanism for other proving methods, they are ill-suited for small, low-value transactions where speed and cost efficiency are critical.

Hyperlane Route

In contrast to the Native Route, the Hyperlane Route can complete a full request flow in just minutes. This significantly improves capital efficiency, as solvers can recycle their capital much faster than with the Native Route. Additionally, Hyperlane requests can be batched together, enabling solvers to share the cost overhead of messaging.

Hyperlane offers significant flexibility in how messages are transmitted between applications, enabling developers to define their own security assumptions for each message. 

Although Hyperlane is both faster and more cost-effective, it introduces additional trust assumptions. Users and solvers must rely on the security assumptions established by Routes. Currently, Routes utilizes Hyperlane’s default ISM, with plans to explore alternative ISMs (or combinations of ISMs) in the future.

Future Directions for Eco Routes

Routes is currently in beta, but several improvements are already being made. These improvements focus on three key aspects of the system: solver participation, cost, and user experience.

Solver participation is critical to ensuring competitive pricing and decentralization. Routes will soon support an Open Quoting System and ERC-7683. The Open Quoting System will include a reputation mechanism that tracks how often solvers successfully fulfill their commitments. When users receive a quote, it will consist of a compound score that factors in the solver’s reputation and the total fee.

To reduce costs, we are working on running a protocol relayer for the Hyperlane Route, originating as much data offchain as possible, and implementing more efficient mechanisms on all contracts.

Finally, Routes requires UX improvements — releasing a developer SDK to simplify integration and extending support for gasless initiations / payable functions. These enhancements will enable the simple, one-click user experience that Routes aims to deliver.

Beyond these three areas, we will be working with a number of partners to add new proving methods to Routes, giving developers even more flexibility in selecting which tradeoffs are most appropriate for their use cases.

For more details about these planned improvements, please see our docs.

About Eco

Eco enables any onchain action to be a simple, one-click stablesend. With Eco, apps can easily accept anyone’s preferred stablecoin, regardless of the network — unlocking stablecoin liquidity from any connected chain and giving users the simplest onchain experience. To make this possible, the Eco Protocol brings together Routes, Accounts, and Crowd Liquidity (coming soon) to give app developers the ultimate flexibility while prioritizing speed, cost, and security. 

Website | Twitter | LinkedIn | Discord | Forum

About Eco Inc.

Eco Inc. is a blockchain company building software that maximizes money’s value. The company is a founding contributor to the Eco Protocol and the builder of Bend. We expect better from our money, and we want you to as well. That’s what drives us every day. 

Twitter | LinkedIn