If you've read about intents and solvers and want to see the execution model with your own hands, the fastest path is to publish one. This Routes CLI tutorial follows the Eco Docs quickstart: install the CLI, preview a transfer from Base to OP Mainnet, publish and fund the intent, and track fulfillment.
​

By the end you'll have a working local setup, an intent hash from a real transfer, and a mental model for moving the same flow into your own backend.
​

The quickstart lists four requirements:

The CLI ships with RPC defaults. Set EVM_RPC_URL_8453 if you want to use your own Base endpoint. Before choosing a different chain pair, check Eco's supported chains and tokens page, which is the current source for coverage.
​

The quickstart pins a version so the steps below match what you see:
​

The source lives in the routes-cli repository on GitHub. Its README lists the other top-level commands, including eco-routes-cli chains to list supported chains and eco-routes-cli tokens to list configured tokens.
​

Chain 8453 is Base and chain 10 is OP Mainnet. Follow the prompts to choose the token, recipient, and amount, then review the quote and funding details. Per the quickstart, --dry-run validates the flow without broadcasting a transaction. It does not reserve liquidity or guarantee a later fill, so treat it as a preview, not a commitment.
​

Review the new quote and confirm the transfer when prompted. This command submits source-chain transactions and spends the selected tokens and gas. Save the intent hash and the transaction hashes it returns.
​

What you are publishing is an intent: it defines the transfer you want and the reward for delivering it. In Eco's intents documentation, the lifecycle runs in four stages: publish and fund, fulfill (a solver supplies the destination tokens), prove (the selected prover makes evidence of fulfillment available to the source chain), and settle (the source-chain Portal checks the proof and pays the claimant).
​

For scripted use, the routes-cli README documents a non-interactive form: pass --yes to skip the confirmation prompt and --json for machine-readable output.
​

The --watch flag watches for fulfillment after publishing. You can also look up the intent hash with GET /v1/intents/status, which requires a v1 API key.
​

One detail matters for anyone building on this: a source-chain receipt confirms publication or funding. It does not confirm destination delivery. If an intent stays unfulfilled, check its status and deadline before taking another action. Eco's Vaults page covers the refund path, and the intents documentation notes that refunding is a separate transaction.
​

The CLI is the fastest way to experiment from a shell. For an application, follow Integrate the Routes API, which covers discovering supported assets, requesting and verifying a quote, funding the transfer, and tracking delivery with the Eco API v1.
​

The programmatic path is what you'd wire into a treasury rebalancer, a payment processor, or an agent framework. Eco's pieces on stablecoin treasury netting and API-first treasury describe the broader patterns.
​

The quickstart troubleshooting list covers the issues first-time users hit most:
​

Missing private key. Check that EVM_PRIVATE_KEY is available in the directory or environment where you run the CLI.
​

Insufficient balance. Allow for both the transfer amount and source-chain gas.
​

No quote. If the CLI offers manual route, Portal, or prover entry, cancel. Confirm the pair and amount, then retry quote discovery.
​

RPC or broadcast error. Check the returned transaction hash onchain before retrying a funding transaction, so you don't fund twice.
​

For more detail on any run, the routes-cli README suggests verbose output with DEBUG=*.
​

A simple mental model helps when you're debugging. Each stage of the intent lifecycle maps to a different failure:
​

1. Publish and fund. The creator or another funder transfers the reward to the intent's deterministic vault. Errors here are wallet, balance, or RPC problems on the source chain.
​

2. Fulfill. A solver supplies the destination tokens and executes the route through the destination Portal. An intent that sits unfulfilled usually means no solver took it before the deadline.
​

3. Prove. The selected prover makes evidence of fulfillment available to the source chain.
​

4. Settle. The source-chain Portal checks the proof and pays the recorded claimant. Eco's intent solver primer walks through the solver side of this handshake.
​

Holding this flow in your head makes every error interpretable. Debugging starts with figuring out which stage broke.
​

Once the first intent works, wire status tracking into your observability. For a backend sending many intents, you want a consistent signal when fills complete, stall, or pass their deadline. Eco's pieces on cross-chain transaction tracking and settlement reconciliation cover how to think about this at scale, and the solver economics breakdown explains how quotes get priced.
​

Can I try the Routes CLI without spending funds? Yes. --dry-run validates the flow and shows the quote without broadcasting a transaction. It does not reserve liquidity, so a later publish gets a new quote, per the quickstart.
​

How is publishing an intent different from calling a bridge? A bridge call is a specific transaction to a specific contract. An intent states the transfer you want and the reward for delivering it, and a solver fulfills it. Eco's comparison of intents vs bridges covers the architectural implications.
​

Which chains and tokens does the Routes CLI support? Coverage changes, so check Eco's supported chains and tokens page or run eco-routes-cli chains and eco-routes-cli tokens.
​

What's the difference between the Routes CLI and the Routes API? The CLI is an interactive terminal tool for publishing intents. The API is what you integrate into backend code, starting from Integrate the Routes API.
​

What happens if my intent is not fulfilled? Check its status and deadline first. Per Eco's intents documentation, an unfulfilled reward can become refundable after its deadline, and refunding is a separate transaction.
​