How Routes Enables Trustless, Permissionless Stablecoin Transfers Across Any Chain

Most cross-chain infrastructure forces a tradeoff. You either accept trust assumptions from a centralized bridge operator, pay a premium for a permissioned solver network, or sacrifice speed for security. Eco Routes is built on the premise that none of those tradeoffs are necessary.

Routes uses an intent-centric architecture: users express what they want, an open network of solvers competes to fill it, and decentralized provers verify the result onchain. No operator controls execution. No single solver holds leverage over pricing. No centralized party can censor or block a transfer. Because solvers compete openly for every intent, the market sets the price, and that price is consistently lower than alternatives where execution is gated.

This post walks through how Routes works under the hood: the contract architecture that makes it reliable, the design decisions behind each component, and why each decision can benefit developers building with stablecoins at scale.

Architecture Overview: Four Contracts, Trustless Execution, Seamless Stablecoin UX

Routes works by separating concerns cleanly across four contracts deployed on every supported chain. Instead of a monolithic contract that handles everything and can fail or be exploited in ways that affect everything, each contract owns exactly one job.

Portal is the main entry point. It manages the full intent lifecycle: publishing, funding, fulfillment, proof verification, and reward distribution. The same contract serves as both the source-side IntentSource and the destination-side Inbox, meaning every chain can act as both origin and destination without additional configuration.

Vault is the contract for locking funds. Each intent gets its own Vault, deployed deterministically via CREATE2. User funds never sit in the Portal. They sit in an isolated contract that can only be instructed by its associated Portal.

Executor handles call execution on the destination chain. When a solver fulfills an intent, the Portal delegates the route calls to the Executor rather than running them directly. The Executor is stateless, holding no storage beyond an immutable reference to its Portal.

Provers verify cross-chain fulfillment. After a solver fulfills an intent on the destination chain, the prover relays a proof back to the source chain, confirming it happened. Routes supports multiple prover types, each using a different messaging protocol. Users choose their prover when creating an intent.

The result of this architecture: Routes keeps transfer pricing efficient at the base level, keeps the system honest without a trusted party in the critical path, and keeps the network expandable to new chains without protocol changes.

Contracts: Why Routes Can Make Guarantees Other Systems Can't

Each contract in the Routes architecture solves a specific problem in cross-chain coordination. Understanding the decisions behind each one explains why Routes can make guarantees that other systems cannot. Most cross-chain systems either rely on multisigs, centralized relayers, or trusted bridge operators to fill the gap between chains. Routes fills that gap with cryptographic proofs and contract logic instead.

The Portal: One Deployment, Every Chain

The Portal consolidates everything into a single contract deployed across all supported chains. It handles intent creation on the source side and fulfillment on the destination side. Every chain in the network is both a source and a destination from a single deployment. Adding a new chain is a single contract deployment that immediately interacts with every other chain in the network, with no special configuration per chain pair.

The Portal also implements ERC-7683 through its OriginSettler and DestinationSettler base contracts, providing developers with two integration paths: the Routes' native interface or the standardized cross-chain order protocol interface. Gasless intents use EIP-712 signatures, so users can create intents without submitting an onchain transaction. A solver or relayer submits the signed order on the user's behalf.

The Vault: How User Funds Stay Protected

Every intent gets its own Vault, deployed deterministically via CREATE2. The Vault address is derived from the intent hash, meaning it can be computed before any onchain transaction is submitted.

This is what enables gasless workflows: a user can fund an intent by sending tokens directly to the precomputed Vault address, without any Portal interaction. Each Vault is also a lightweight ERC-1167 minimal proxy pointing to a shared implementation, costing roughly 2,500 gas to deploy versus approximately 200,000 for a full contract, and only deployed when first accessed.

The isolation is also a security property. Each Vault is an independent contract instructable only by its associated Portal. A vulnerability in one intent's execution cannot reach funds held in another. There is no shared pool of user funds that a bug or exploit can drain.

The Executor: How to Run Arbitrary Logic Without Putting User Funds at Risk

When a solver fulfills an intent, the route calls can target any contract and run arbitrary logic. Running that logic inside the Portal would be dangerous. A malicious call could exploit reentrancy to manipulate Portal storage or corrupt the fulfillment state of other intents.

The Executor solves this with a clean, stateless execution context. The Portal transfers route tokens to the Executor, the Executor runs the calls, and the results are returned. It holds no persistent state beyond an immutable reference to its Portal. There is no storage to corrupt and no state to manipulate.

The practical implication: Routes lets you route funds through any logic on the destination chain — swapping, staking, depositing into a protocol — without introducing a new attack surface into the core infrastructure. The Executor is the blast radius limiter.

The Proof System: How Routes’ Proof Systems Enable Maximum Flexibility for Developers

The proof system is the foundation of Routes' trustless design. Without onchain proof, a solver cannot claim their reward. This single constraint eliminates counterparty risk entirely: a solver cannot take payment unless they cryptographically prove they did the work, and no centralized party arbitrates the outcome. The contracts enforce it.

Routes makes the proof system highly flexible. Any messaging protocol can integrate with Routes by implementing the iProver interface, and users choose their prover when creating an intent. That choice encodes their trust assumptions directly into the transfer. Each prover on the source chain maintains a whitelist of trusted destination provers, so spoofed messages cannot mark intents as proven.

Why this matters: Different use cases have different security requirements. A developer building a consumer app that moves small amounts might prioritize speed and low cost. A protocol moving millions in treasury operations might prioritize the most trust-minimized proof available. Routes lets you make that choice per-transfer, not per-deployment.

Choosing a Prover: Coverage, Cost, and Trust-Model Trade-offs

Each prover offers a different balance of cost, speed, chain coverage, and trust assumptions. Having multiple provers lets users and applications choose the best prover for their use case.

Settlement via Circle's own attestation infrastructure. Verification security is identical to native CCTP transfers.

Each prover on the source chain maintains a whitelist of trusted destination provers. When a cross-chain message arrives, the prover validates that the sender is in the whitelist before recording the proof. This prevents spoofed messages from marking intents as proven.

How Routes Guarantees Transfers Even When No Solver Is Available

V2 introduces a second fulfillment mode that did not exist in V1. One of the most common failure modes in intent-based systems is solver unavailability. If no solver wants to fill your transfer — because the route is too exotic, the amount too small, or liquidity is thin — users get stuck. V2 addresses this with two fulfillment modes that work together as a layered availability model.

Settlement mode is the standard flow and works exactly as V1 did: a solver provides the requested tokens on the destination chain using their own inventory and claims the user's locked reward on the source chain. Solvers compete on price and speed, which drives down costs for users.

Orchestration mode removes the need for solver capital entirely. It is enabled by the LocalProver and its flashFulfill operation, a flash-loan-style fulfillment that uses the Vault's own funds within a single atomic transaction on a single chain. Because everything happens locally, there are no cross-chain messaging fees or bridge overhead.

The practical effect is a layered availability model. If a solver offers better pricing, settlement mode runs. If no solver advantage exists, orchestration covers it. If no solver is available, the user can self-solve via a local intent. System availability equals chain availability, not solver availability.

Universal Addressing: How Routes Supports Any Chain Without Chain-Specific Integrations

V2 adds support for non-EVM chains, including Solana, through a universal addressing scheme. All claimant identifiers use bytes32. EVM addresses (20 bytes) are left-padded to 32 bytes. Solana addresses are already 32 bytes and map directly. A solver on Ethereum can specify a Solana address as their claimant, or vice versa.

Route data is published in a universal bytes format that supports different encoding schemes per VM. The Portal on EVM chains decodes EVM-specific routes, while Solana integrations interpret the bytes according to their own conventions. Vault deployment also adapts per chain: standard EVM chains use the 0xff CREATE2 prefix, TRON uses 0x41, but the derivation formula stays the same.

Five Security Guarantees Built Into the Protocol Itself

Rather than documenting security properties as aspirations, Routes encodes them as protocol invariants. These are not properties that depend on a multisig behaving correctly or an operator acting in good faith — they are enforced by the contracts.

Funds isolation: User funds sit in per-intent Vault contracts, not in the Portal. Even if the Executor runs arbitrary code during fulfillment, it cannot reach funds held in other Vaults.

Execution isolation: Route calls run in the Executor, a contract with no persistent state. Malicious or buggy calls cannot corrupt Portal storage, manipulate Vault balances, or affect other intents.

Deadline enforcement: Routes carry execution deadlines; rewards carry claim deadlines. Fulfillment is rejected after the route deadline passes. Refunds are only available after the reward deadline passes. Solvers have a known window to fulfill and prove. Users have a guaranteed path to reclaim funds if nothing happens.

Automatic refunds: If an intent expires unfulfilled, the creator reclaims their locked tokens by calling refund(). Funds are never permanently locked in the system. There is no scenario where a user loses access to their reward tokens indefinitely.

Proof validation: The Portal does not trust callers to assert that an intent was fulfilled. It queries the designated prover contract, which independently validates the message's origin and the sender's whitelist.

Routes Is Built to Compound

Routes is not a bridging product. It is the base layer that enables stablecoin programmability.

Every design decision in Routes connects back to the same goal: a permissionless execution layer where trust is enforced by contracts, not operators. That foundation makes everything built on it reliable. Deposit addresses that automatically route inbound funds according to programmable rules. Transaction logic that executes across chains without manual intervention. Complex multi-step stablecoin flows that settle atomically and correctly, every time. None of that works if the execution layer underneath it can be gated, censored, or priced arbitrarily by an intermediary.

This is the railroad. Open-solver competition keeps transfer prices efficient at the base. Decentralized proving keeps the system honest without a trusted party in the critical path. Universal addressing means the network can expand to every chain without requiring protocol changes. And the pluggable proof system means Routes can integrate new verification methods as the broader ecosystem matures, without breaking anything built on top of it.

The stablecoin economy needs infrastructure that developers can build on permanently, not infrastructure they need to route around when it becomes a bottleneck. Routes is designed to never be that bottleneck. It gets more efficient as more solvers participate, more expressive as more provers integrate, and more capable as higher-order programmability layers build on it. That compounding is the point.

About Eco

Eco powers real-time money movement across every major stablecoin and blockchain, ensuring dollars flow seamlessly across today's fragmented multichain landscape. Leading apps and protocols integrate Eco to power stablecoin flows where best-in-class execution is required — upgrading stablecoin UX throughout their ecosystems and unifying them all in a thriving Stablecoin Economy.

Website | Eco Docs | Twitter | LinkedIn | YouTube

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