Production Web3
04 / 12
Cross-chain Swap
Same-chain swap, bridge, and cross-chain swap unified as one staged execution experience.
- Role
- Frontend Lead
- Problem
- A successful source transaction did not guarantee that the full cross-chain intent had completed.
- Strategy
- The UI classified the route first, then represented each required stage with its own status and reference. Bridge observation was treated as a distinct signal, so delayed infrastructure and failed execution could receive different guidance.
- Outcome
- Combined workflows that otherwise required separate swap and bridge products.
Historical public product · Current operation not claimed
01
Problem definition
Why this problem had to be solved
Cross-chain Swap turns route selection, optional approval, source execution, bridging, target execution, and recovery into one product flow.
What users and the system were facing
The number and network of execution steps changed with each route.
A source transaction could succeed while the bridge observer or target execution was still pending.
Users needed to distinguish a delayed observer from an actual bridge failure.
Frontend ownership
I led frontend architecture and implemented the core route, execution, state, and recovery experience through production operation.
Chain, token, pair, and route discovery
Swap, bridge, and cross-chain mode classification
Approve, source, bridge-observer, and target stages
Transaction references, errors, analytics, and maintenance
02
Solution strategy
A system strategy carried into production
The UI classified the route first, then represented each required stage with its own status and reference. Bridge observation was treated as a distinct signal, so delayed infrastructure and failed execution could receive different guidance.
System model
Route selection determines optional approval, source-chain execution, bridge observation, target-chain execution, and completion or recovery guidance.
Product evidence
Selected product surfaces
Historical product interfaces. Values shown are captured UI states, not current TVL, APY, or performance claims.
Implementation decisions
Constructed only the stages required by the selected route.
Tracked source and target transactions independently.
Polled bridge observation separately from on-chain receipt success.
Returned user rejection to a retryable state instead of a permanent failure screen.
03
Outcome
What changed—and what I learned
Combined workflows that otherwise required separate swap and bridge products.
Made source and target progress visible without collapsing intermediate success into final completion.
Supported years of network, RPC, price API, wallet, and security changes.
Learning
Cross-chain UX needs an honest model of partial success. Recovery guidance is part of the primary path, not an edge-case appendix.
Today
I would use a durable process ID, cancellable polling with backoff, explicit partial-success states, and formal recovery actions that survive a browser session.
Built with
Public links
Work together