Pathfinder v1 API
The pathfinder.v1.PathfinderService API - route finding and chain/token lookups. Legacy; new integrations should use v2beta.
v1 is the legacy Pathfinder API surface, kept for existing consumers. New integrations should use v2beta instead - see the v2beta page for why.
pathfinder.v1.PathfinderService is a single service with 6 methods:
FindPath- find the best route to bridge/swap tokens between two chains.LookupDenom,GetTokenDenoms,GetChainInfo,ListSupportedChains,GetChainTokens- chain and token metadata lookups.
For the full field-by-field schema, try each method live, and see auto-generated request/response examples, use the interactive API Reference.
The address model
v1 identifies a transfer with a single sender_address and receiver_address pair. If the route the Pathfinder finds needs an address on an intermediate chain (a broker chain for a swap, or a PFM hop), v1 derives that address automatically from the sender/receiver pair via SLIP-44-guarded bech32 re-encoding.
That works for the common case, but different chains can use different SLIP-44 coin types, so a re-derived address can occasionally be malformed or simply wrong for some chains. This is the main reason v2beta exists - see Pathfinder v2beta for the replacement model.
What FindPath returns
FindPathResponse has a route field that's one of three shapes - exactly one is populated per response:
direct- a single IBC hop, no swap. The simplest case: e.g. bridging ATONE from AtomOne to Osmosis.indirect- multiple IBC hops, still no swap. Used when a token needs to pass through an intermediate chain to reach its destination (via manual chaining or Packet Forwarding Middleware).broker_swap- one hop reaches a DEX broker chain (currently only Osmosis), a swap happens there, and zero or more hops continue on to the destination. This is the shape used for any cross-chain swap, and covers same-chain swaps, swap-then-transfer, transfer-then-swap, and swap-with-multi-hop-outbound.
When a broker_swap response includes an execution field, it carries ready-to-use transaction data - either a memo for MsgTransfer (an IBC-hooks memo) or smart_contract_data for direct smart contract execution. See the Spectra IBC Hub repo's docs/IBC_MEMO.md for exactly how those formats assemble.
Denom syntax
Any denom field (token_from_denom, token_to_denom, LookupDenom's denom) accepts three forms:
- A native denom, e.g.
uatone,uosmo. - A full IBC denom, e.g.
ibc/BC26A7A8.... - The
symbol@origin_chainconvenience syntax, e.g.uatone@atomone-1- names the chain a base denom is native to, to disambiguate when the same base denom could otherwise resolve ambiguously.
Full worked examples
For every route shape (direct, broker_swap in each of its variants, indirect) with complete, realistic JSON, see docs/pathfinder/v1.md in the spectra-ibc-hub repo - the source of truth this page summarizes.
Spectra Portal
Spectra Portal is a standalone DApp that extends the functionality of the Spectra Explorer. This DApp provides an interface that grants users a way to bridge tokens across different chains using the Inter Blockchain Communication Protocol, and swap tokens across different chains using the Osmosis DEX.
Pathfinder v2beta API
The current, recommended Pathfinder API - explicit per-chain addresses, a mock/discovery response mode, and a streaming route-finding RPC.