How it works
Balances are read from public RPCs in your browser for every registry chain: native gas, wrapped native and Circle USDC (plus the issuer test tokens and, when enabled, ERC-20s an indexer lists). Nothing is sent to a server.
Every provider is asked what it can do right now: Uniswap pools with liquidity and a probe quote, CCTP domains with bytecode on both sides, Across and LI.FI route lists, Hyperlane and Gateway contracts verified on-chain. "Protocol supports chain X" is never enough for an edge.
For each balance the planner walks the capability graph (shortest paths first), quotes every hop with the amount that actually arrives, reserves gas on every chain a step touches, and keeps the best route per mode. Provider caps and thin pools become PARTIAL routes instead of failures.
Before the wallet is asked to sign, each transaction is eth_call-simulated, gas is estimated on our RPC (plus the L2 data fee), the spender's bytecode hash is compared with the pinned one, and the exact calldata is summarised in plain words.
Your wallet signs one transaction at a time. Cross-chain steps are polled (Circle attestations, relayers, LayerZero Scan). A burn is never sent twice: if the wallet's nonce moved, the transaction is found on-chain or the route stops and asks you.
The full reference (concepts, adding a chain, writing an adapter, the security model, troubleshooting) is in Docs.