The pain you’re solving
- Users on chain A want to deposit into your vault on chain B but get lost in the bridge UI
- Treasury sits idle on one chain while opportunities exist on another
- Cross-chain rewards distribution forces users to claim on a chain they don’t use
- Adding a new chain means deploying contracts, bridging liquidity, maintaining infrastructure
What Eco gives you
| Capability | Product |
|---|---|
| One-tx cross-chain deposit into your contracts | Routes destination calls |
| Conditional treasury rebalancing | Routes and Programmable Transactions |
| Universal deposit address per user | Programmable Addresses |
| Cross-chain reward distribution | Routes API |
| Best-execution internal routing | Programmable Transactions |
Recommended product mix
| Use case | Use |
|---|---|
| One-click cross-chain deposits | Routes and destination calls |
| Treasury rebalancing | Routes API (programmatic intents) |
| Pre-positioned deposit addresses for users | Programmable Addresses |
| Best-price internal swaps | Programmable Transactions |
Patterns
”Deposit from any chain” button
User clicks Deposit on your Arbitrum vault. Your frontend builds a Routes intent withroute.tokens = [USDC on Arbitrum] and route.calls = [approve(vault), vault.deposit(amount, user)]. User signs once on their source chain. The whole sequence executes atomically, or refunds.
→ Destination calls
