Case study
← All workCross-chain swap portal
Moves a token from three EVM chains onto Base at a fixed 1:1 rate, with its own indexer confirming both halves.
- Client
- Undisclosed — under NDA
- Year
- 2026
- Discipline
- Blockchain · Interface
- Status
- Delivered
Context
A token existing on several chains at once is a liquidity problem wearing a user-experience problem. Holders were spread across the client's own L1, Ethereum and Polygon, and the destination was Base. The portal had to take a holder on any of the three and land them on the fourth at a fixed one-to-one rate, without asking them to understand bridges, wrapped assets or which contract to trust.
Constraints
A cross-chain swap is not one transaction, and cannot be made to look like one without lying. The user signs on the source chain; the credit happens on the destination chain, later, after confirmations. Between those two moments the interface has to be honest about a pending state it does not control, survive the user closing the tab, and never imply a completion that has not happened. A swap interface that optimistically shows success is worse than one that is slow.
Architecture
Four services: the portal front end, a swap service, a dedicated indexer, and PostgreSQL. The indexer is the important one — rather than trusting the front end to track a swap across two chains, it watches both sides and reconciles them, so the record of what happened lives server-side and a returning user is shown the truth rather than whatever their browser last remembered. Wallet connection, chain switching and transaction handling run on wagmi and viem with RainbowKit for the connector UI.
01
A server-side indexer as the source of truth for swap state.
The two halves of a cross-chain swap happen on different chains minutes apart. Only something watching both can say whether a swap completed. Putting that in the client means a closed tab loses the record.
What it cost
A whole extra service and database for what is, in the happy path, a transaction the user could have watched themselves.
02
A fixed 1:1 rate rather than a market rate.
It removes slippage, price impact, and the entire class of interface required to explain them. The product becomes 'move your tokens' rather than 'trade your tokens', which is a far smaller promise to keep.
What it cost
No arbitrage resistance and no market responsiveness — the economics have to be guaranteed outside the portal.
- Source chains supported
- 3
- counted in source
- Services in production
- 4
- read from deployment
- Swap rate
- 1:1, fixed
- counted in source
- Dedicated indexer
- Yes — its own service
- read from deployment
Four services in production covering three source chains onto Base, with swap state reconciled by a dedicated indexer rather than inferred in the browser.
Stack
TypeScript · Next.js · wagmi · viem · RainbowKit · PostgreSQL · Solidity