Route Choose a compatible payment flow
Documentation revision 2026-09-26. Check the exact asset identity, direction and wallet submission mode before implementing signing. A token symbol or available provider quote does not establish Route execution support. Use the normalized next-action API and SDK to follow an existing payment.
Check compatibility before signing#
Confirm the exact source and destination assets in the catalog, check the candidate’s execution support, then follow the prepared payment’s wallet requirements. Provider availability, policy limits and action flags are rechecked before execution.
Paths, wallets and destination fees#
| Adapter / environment | Assets and direction | Source signing | Destination execution / fee payer | Integration requirements |
|---|---|---|---|---|
| Circle, testnet | Native test USDC, Ethereum Sepolia → Stellar testnet only; Standard/Fast | EVM EOA, exact legacy transaction; Route or wallet submission | Managed Channels sponsorship; optional customer Stellar G-account signer/XLM | Use the testnet starter; test tokens have no USD value |
| Circle, mainnet | Native USDC between Ethereum, Base, Arbitrum and Stellar, exact directional capabilities | EVM EOA legacy transaction or Stellar single-key G account/XDR | Supported EVM forwarding; Stellar managed Channels or customer-funded mint | Managed delivery must be available in the adapter response |
| Allbridge, mainnet | Native USDC, Ethereum/Base/Arbitrum, currently verified legacy CCTP V1 registry paths | EVM EOA legacy transaction | Allbridge relay; quoted relay fees | No active Stellar path is advertised; current V1 registry and contracts must be available |
| LayerZero, mainnet | Exact registered OFT pairs on Ethereum/Base/Arbitrum/Stellar; Stellar USDT0, not native Stellar USDC | EVM EOA or Stellar single-key G account | Configured executor; protocol fee includes delivery terms | Requires the exact registered OFT token pair |
| Axelar, mainnet | Exact ITS registrations on those networks, direction and representation specific | EVM EOA or Stellar single-key G account | ITS routing/execution; protocol gas payment | USD-policy checks require valid representation pricing |
| NEAR, mainnet | Exact provider-offered conversions on the implemented networks listed below, both directions when supported | EVM EOA, Stellar G account, Bitcoin single-key native SegWit/Taproot, Solana original SPL/SOL, Fogo FOGO, NEAR NEP-141, TRON, Sui and Aptos | Provider settles the destination; source wallet pays its own chain fee | Ethereum ERC-20 → BTC fee adjustments require exact bridge allocation proof; unresolved mismatches require review |
| NEAR + protocol composition, mainnet | Bounded supported two- or three-leg paths through Ethereum/Base/Arbitrum; exact per-leg identities | Signer for each source/intermediate action, native gas on each spending network | Each leg's own delivery mechanism | BTC is not a supported intermediate wallet |
| Rift | Reviewed Ethereum/Base/Arbitrum/Ink/Robinhood assets and native BTC; different same-network assets supported; HyperCore quote-only | Exact legacy EVM EOA transaction or single-key native SegWit/Taproot Bitcoin | Provider-managed delivery; independently attributed finalized payout required for completion | Explicit variable-output acceptance; no guaranteed minimum; direct orders only. Health, USDC cross-chain quotes and a tokenized-stock quote were verified from Cloudflare staging on October 1, 2026; live orders and funded settlement remain unverified. See Rift coverage |
| Garden | Temporarily unavailable | New quotes and execution paused | Existing records retained | Excluded from new quotes and execution while paused |
| SwapKit | Simple deposits from Ethereum, Base, Arbitrum or single-key native SegWit/Taproot Bitcoin; reviewed EVM ERC-20, Stellar classic/native and native BTC destinations | Exact legacy EVM transaction signature/wallet broadcast, or finalized Bitcoin PSBT/raw signature | Valid channel deadline and independently verified receipts | Supported deposit channel, deadline, transaction fields and receipt evidence are required |
NEAR's implemented networks are Ethereum, Base, Arbitrum, Optimism (op), Polygon (pol), BNB Chain (bsc), Avalanche (avax), Berachain (bera), Monad, Gnosis, X Layer (xlayer), Plasma, Scroll, Robinhood (hood), ADI, Stellar, Bitcoin (btc), Solana (sol), Fogo, NEAR, TRON, Sui, Aptos, Litecoin (ltc), Dogecoin (doge) and XRP (xrp). Exact source builders and asset types are narrower than each network's catalog. Read the current machine-readable capabilities.executionNetworks and executionNetworkCount from GET /v1/adapters. Other catalog networks can remain quote-only; see availability conditions.
Use GET /assets for exact IDs with their address (contract), issuer, representationOf and decimals. Use GET /adapters for implemented capabilities, then request the actual pair/amount and inspect candidate execution and preparation. Finally inspect the prepared action's flags and current checks. The matrix cannot reserve provider liquidity, establish a current price, or enable a disabled action.
Response shape matters#
GET /v1/payments/{id}/next-action returns one action envelope across supported flows, including the actor, operation, required input and separate payment/preparation versions. Prefer that projection for integration control flow. Existing mutation responses retain their shapes: Mainnet NEAR and protocol transaction creation return the transaction object directly; testnet creation returns a wrapper with transaction. GET /payments/{id}/transaction returns a wrapper in all three flows. Detailed payloads and evidence remain flow-specific. Read the matching OpenAPI contract when inspecting those responses, or reread the normalized snapshot after each operation.
Wallet compatibility gate#
| Wallet family | Required capability | Current boundary |
|---|---|---|
| EVM | Sign-only serialized legacy transaction or the explicit wallet submission handoff using eth_sendTransaction; NEAR additionally needs its intent message signature |
Sign-only transactions must preserve every legacy field. Wallet submission can recognize a lower gas limit within the approved ceiling; gas price and payment fields remain exact. No EIP-1559 conversion, smart accounts/4337, higher gas limits, fee-price editing or automatic replacement. A wallet-changed transaction that keeps the payment call is recorded for review (WALLET_TRANSACTION_REVIEW_REQUIRED), never attached |
| Stellar | Sign exact XDR with the supplied network passphrase; NEAR additionally needs the intent proof | Single-key G accounts; Freighter-style XDR signing. No multisig collection, muxed accounts or fee-bump flow |
| Bitcoin | Sign-only PSBT/raw transaction; NEAR also requires a BIP322 simple intent proof | Single-key P2WPKH or Taproot key-path; no legacy, multisig or script-path inputs |
| Solana / Fogo | Message proof plus exact transaction signing without broadcast | Original SPL/SOL on Solana and FOGO on Fogo; no Token-2022 extensions, Fogo Sessions or paymaster flow |
| NEAR account chain | NEP-413 intent proof and exact Borsh transaction | One full-access Ed25519 key; catalog NEP-141 tokens; NEAR gas plus token storage registration when needed |
| TRON | TIP-191 proof and exact signed protobuf transaction JSON | Single owner key; TRX or catalog TRC-20 tokens; activated recipient/refund accounts; TRX fees |
| Sui | Personal-message proof and exact signed transaction bytes | Single-key Ed25519 signing; one sufficiently funded gas coin and, for tokens, one sufficiently funded token coin; no automatic coin consolidation |
| Aptos | Raw UTF-8 message proof and exact signed BCS transaction | Legacy Ed25519 signer matching the current authentication key; native APT or catalog fungible-asset metadata; no browser signMessage envelope substitution |
Litecoin and Dogecoin support native LTC/DOGE with external sign-only signers. Litecoin sources use native SegWit P2WPKH; Dogecoin sources use compressed-key P2PKH. XRP supports native XRP between existing classic accounts with enabled master-key signing and no required destination tag or deposit authorization. See chain-specific signing. Account connection alone does not establish support for these proof formats.
NEAR, TRON, Sui and Aptos use an external sign-only integration through the API; the dashboard does not connect those browser wallets. Gas is paid in NEAR, TRX, SUI or APT respectively. Exact account and fee checks run before authorization. Provider minimums and liquidity may exclude small payments even when the transaction format is supported.
Check wallet documentation/capabilities and exercise its signing method on a dedicated test transaction before building a payment UX around it. Do not send a mainnet transaction as a capability probe. Keep the reviewed payload intact; chain ID, nonce, gas, recipient, calldata/XDR and validity bounds are part of the authorization. Route's signature verifier still makes the final acceptance decision.
The SDK's checkWalletCompatibility helper checks declared capabilities before you allocate a payment. It returns compatible, unsupported or unknown, with evidence: declared-capabilities-only. It performs no wallet or network calls; your application must still handle wallet account selection, network selection and rejected signing requests.
Use a wallet that supports the exact signing or submission method returned by Route. The starter uses a backend signer; browser integrations must implement the EVM wallet handoff and preserve the reviewed transaction fields.