Rath FinanceWhy xPath?
Understand why teams use xPath to unify routing, execution, and gasless flows behind one API.
Why xPath
xPath exists to remove the integration burden of fragmented onchain execution.
Instead of wiring together bridge providers, DEX routers, token catalogs, execution builders, and gasless flows separately, you integrate one API that handles route discovery and execution preparation in a consistent way.
TL;DR
- One API for same-chain swaps, cross-chain routing, and gasless execution
- Less provider-specific logic in your app
- Faster time to ship for wallets, trading apps, and DeFi products
- Unified token discovery, chain discovery, quoting, and transaction building
- Cleaner operational model for status tracking and route execution
The Problem xPath Solves
Building onchain routing products usually means dealing with:
- different bridge providers with different behaviors and coverage
- different DEXs and aggregators per chain
- token metadata and token search spread across ecosystems
- separate systems for quoting, route selection, and transaction building
- additional complexity for Permit2 and gasless execution flows
- inconsistent monitoring and support workflows after submission
That fragmentation slows down product development and increases maintenance cost.
What xPath Changes
xPath gives you one routing and orchestration layer for:
- quote generation across supported chains and providers
- token and chain discovery
- transaction-ready calldata generation
- gasless Permit2-based swap flows
- status tracking for route and bridge execution
Your product can stay focused on user experience, policy, and business logic instead of provider-level plumbing.
Who It Is For
xPath is useful for teams building:
- wallets and embedded wallet products
- trading apps and exchanges
- DeFi frontends and aggregators
- cross-chain asset movement flows
- gasless swap experiences
- agentic workflows that need executable route data
Without xPath vs. With xPath
| Without xPath | With xPath | |
|---|---|---|
| Routing | Build provider logic yourself | Use one routing surface |
| Execution | Assemble calldata per flow | Build transaction-ready payloads |
| Token discovery | Maintain token search separately | Use shared discovery endpoints |
| Gasless support | Add a separate relayer path | Use dedicated gasless endpoints |
| Monitoring | Track state across systems | Use shared status endpoints |
| Maintenance | Higher operational overhead | Lower integration complexity |
Next Steps
- Read Introduction for the core xPath flow
- Use API Reference for endpoint details
- Start with Quote API to fetch ranked routes
- Use Build Path API to generate executable calldata