# Provider connections Route handles the provider integrations. Your backend uses one Route API key; select which providers its policy may consider, then inspect each quote's execution and preparation capabilities. A provider connection check does not establish liquidity or execution for every pair. ## Connection choices | Adapter | Customer credential | Route-managed access | Current Route capability | | --- | --- | --- | --- | | Circle CCTP | None | Public protocol | Quotes and supported execution paths | | Allbridge | None | Public protocol | Quotes and supported legacy CCTP V1 EVM execution | | LayerZero OFT | None | Public protocol | Quotes and registered OFT execution paths | | Axelar ITS | None | Public protocol | Quotes and verified ITS execution paths | | NEAR 1Click | Partner API key when using your account | Available when configured | Quotes and supported execution paths | | Garden | Saved App ID retained | Temporarily unavailable | Paused | | SwapKit | API key when using your account | Available when configured | Quotes and supported simple EVM/Bitcoin deposits | | Rift | None | Public REST API | Reviewed EVM/Bitcoin orders with explicit variable-output acceptance; provider reports require chain verification | See [compatibility](compatibility.md) for asset representations, wallet requirements and destination fees. Current candidate and action flags decide whether a specific path can proceed. ## Connection options NEAR and SwapKit support two explicit project settings. Garden retains these settings but is currently paused: | Selection | Provider account used | Customer credential needed | |---|---|---| | Use Route’s connection | Route’s managed account | No | | Use my own key | Your provider account | NEAR partner API key or SwapKit API key | In **Providers**, select **Use Route’s connection**, or enter your own credential. The active source is displayed. Shared credentials remain server-side and are never returned to customers. Both modes follow the existing [Route credit rates](usage-and-billing.md), project limits and routing policies. Provider fees and network fees are separate from Route credits. Provider quotas or outages can temporarily prevent quotes. For API setup, use a key with `providers:write`: ```http PUT /v1/providers/swapkit Authorization: Bearer ROUTE_API_KEY Content-Type: application/json {"version":0,"enabled":true,"credentialSource":"route"} ``` Use the actual current connection version from `GET /v1/providers`. That response includes `routeConnections` availability, the selected `credential_source`, `credential_present` for the active connection and `customer_credential_present` for your saved credential. To use your own account, save its credential with `PUT /v1/providers/near/credential` or `PUT /v1/providers/swapkit/credential`, passing the current `version` and `credential`. Then enable the provider with `credentialSource: "customer"`. Obtain a SwapKit key from the [SwapKit dashboard](https://dashboard.swapkit.dev/). A failed customer credential never falls back to Route’s account. Switching changes the provider version: request fresh quotes for new activity. Existing NEAR preparations retain their original credential source for refresh and scheduled tracking. Switching does not delete your saved credential. Replacing or removing a customer credential can prevent tracking of orders made with that account; retain access until those payments complete. ### Removing a provider key with payments in flight `DELETE /v1/providers/{adapter}/credential` with the current `{"version":N}` removes your saved key and is never blocked. The response is `{"ok":true,"version":N+1,"credentialPresent":false,"warnings":[...]}`. When payments tracked with this key have funds in flight and no terminal outcome, `warnings` contains `{"code":"UNSETTLED_PROVIDER_PAYMENTS","count":N,"message":"…"}`. Such payments have a source hash or an unconfirmed wallet handoff of a funding transaction. Payments that use Route’s connection, cancelled payments, payments that were never funded and payments with only a pending spending approval are not counted. The warning lists what automatic tracking may no longer reach; nothing is cancelled or released. For SwapKit payments whose key was removed: - **Delivery:** reconnect the original SwapKit connection, then use `POST /payments/{id}/refresh`, optionally with `{"destinationHash":"HASH"}`. SwapKit must identify that exact transaction as the final delivery leg of the saved source transfer. Route also verifies the finalized canonical receipt, recipient, destination asset, reported amount, saved minimum and source time before reserving the exclusive payout claim. A supplied hash cannot replace provider attribution: missing credentials, unavailable tracking or a mismatched report leave the payment unsettled and keep its reservations. - **Refund:** `{"refundHash":"HASH"}` is accepted only when SwapKit’s tracking reports that exact transaction as the swap’s refund leg. Route then verifies a finalized credit of the reported source-asset amount to the saved refund address. Any wallet can send funds to the refund address, so chain credit alone never settles a refund. Without the key the request returns `409 PROVIDER_CREDENTIAL_REQUIRED`. A hash that SwapKit does not report as the refund returns `409 REFUND_RECEIPT_MISMATCH`. Reconnect a SwapKit key to confirm a refund, or have a workspace member confirm it in the dashboard; the payment and its reservations stay unchanged meanwhile. #### Confirm a SwapKit refund in the dashboard When SwapKit cannot confirm a refund, a workspace member can confirm it from the payment's details with **Confirm refund**. This is a dashboard action only: API keys cannot use it and `/v1` has no equivalent. The member needs a role that can prepare payments (owner, admin, developer or operations) and must have signed in within the last 15 minutes; otherwise the request returns `403 FRESH_SIGN_IN_REQUIRED`. The action is available for a standalone SwapKit payment whose deposit is verified and finalized, with no verified delivery or refund. Multi-step payments are excluded. A payment for which Route already holds delivery evidence (a destination transaction verified while its payout claim is pending, or a recorded settlement discrepancy) is refused with `409 PAYMENT_DELIVERY_EVIDENCE`. Route first asks SwapKit when a connection is available. If SwapKit reports this swap as completed, even when the reported payout does not match the saved recipient or minimum (`409 PROVIDER_REPORTS_DELIVERY`), or reports its own refund with a different transaction (`409 PROVIDER_REPORTS_REFUND`), refresh the payment instead. Manual confirmation applies only when the SwapKit key was removed, its tracking cannot be read or does not describe this swap's deposit, it reports no outcome, or it reports as its refund the same transaction the member supplies but Route cannot verify that report (`providerCheck` `reported-unverified`). Route then verifies the supplied hash on chain: - the transaction is successful and final: EVM `finalized` block, or six Bitcoin confirmations (`409 REFUND_NOT_FINALIZED` otherwise); - it credits the payment's source asset to the saved refund address, as a canonical net credit; - it was included after the deposit: in a later block on Bitcoin (block heights, since Bitcoin block times are not ordered), or at a later block time on EVM networks; - its senders are identifiable and none is the payment's sender, refund or recipient address: the EVM transaction sender and the token senders to the refund address, or the Bitcoin spent-output addresses. A self-transfer or a withdrawal submitted by the payer's saved wallet is refused. Route cannot recognize other wallets the payer controls; - the credited amount is at most the deposit and at least the payment's minimum refund. The minimum refund is the deposit less three allowances: the provider fees in the saved SwapKit quote, the accepted slippage, and 10% of the deposit. The fees count those in the source asset and those in the destination asset, converted at the quote's own rate (deposit ÷ expected output), with Route's 10% fee headroom. The 10% of the deposit covers the refund's source-network fee, which the quote does not price. The minimum is never below half the deposit. If the quote deducts a fee in any other asset, the minimum is half the deposit. A genuine refund below the minimum can still be settled from SwapKit's own report: reconnect SwapKit and refresh the payment. Whether the credit came from the payment's SwapKit deposit address is recorded but not required, because vault-based providers refund from other addresses. A failed check returns `409 REFUND_RECEIPT_MISMATCH` with `details.reason`, and nothing changes. Each payment allows ten checks per five minutes (`429 TRY_LATER`). On success Route reserves the transaction as this payment's exclusive payout (`409 REFUND_ALREADY_CLAIMED` if another payment already holds it). The payment becomes `REFUNDED` and emits `payment.refunded`. The usual refund rules apply to credit holds. `tracking.refundConfirmation` records the member's user ID, the time, the hash, why SwapKit could not confirm (`providerCheck`), the accepted range, the senders and whether one of them is the payment's deposit address. `GET /payments/{id}/next-action` then returns `refunded` with a message that a workspace member, not SwapKit, confirmed it. The workspace audit log records `payment.refund_confirmed_manually` for the member. Chain checks cannot prove that SwapKit sent the transaction; the member's confirmation is that attestation. ## Garden **Temporarily unavailable.** Route has paused new Garden quotes and execution while provider availability and execution support are verified. Garden is excluded from route comparisons, Auto-route plans and SwapKit candidates that depend on Garden. Other providers remain available under your policy. `GET /adapters` reports `platformAvailability.status: "paused"` and `capabilities.quote: false`. `GET /providers` reports effective `enabled: false`; `configuredEnabled` preserves the owner's saved preference. Enabling Garden returns `409 PROVIDER_PAUSED`, for either a customer App ID or Route's connection. Adding or replacing a credential cannot bypass the pause. Paused providers are hidden from dashboard setup, new policy and API-key provider choices, and health checks. Saved credentials, policy preferences and existing order records are retained. Existing strict provider rules remain visible so they can be reviewed; Route never silently changes the required provider. The pause does not delete or cancel an existing order. Asset identities remain in the catalog, but Garden is omitted from their active `quoteProviders`. A Garden-only policy needs another available provider before it can return an eligible route. Route does not silently expand the policy. ## Rift Rift (`rift`) is an optional REST API provider. Enable it in **Providers** and include it in the routing policy and API-key provider restrictions. It needs no provider API key; requests to Route still need a Route API key. This implementation uses Rift's current REST contract, not an earlier Rift SDK. Read the connection's current `version` from `GET /v1/providers`, then use a key with `providers:write`: ```http PUT /v1/providers/rift Authorization: Bearer ROUTE_API_KEY Content-Type: application/json {"version":0,"enabled":true} ``` The version above is illustrative. Use the actual current value. There is no Rift credential endpoint. **Assets and networks:** read `GET /v1/assets` and filter `quoteProviders` for `rift`. The reviewed catalog covers Ethereum, Base, Arbitrum, Ink, Robinhood, Bitcoin and Hyperliquid HyperCore, including crypto, tokenized stocks, ETFs and vault shares whose identity and precision have been verified. Each issuer, contract and network remains a separate asset. Unknown decimals are not guessed. HyperCore balances are distinct from HyperEVM tokens; wrapped Bitcoin is distinct from native BTC. The upstream token list is non-exhaustive, but Route only offers reviewed identities. Use the usual `POST /v1/quotes` with exact catalog asset IDs and a decimal source amount. Different assets on the same network are accepted for Rift. Its `received` is an estimate after venue and delivery costs. `minimumReceived` is null: the final amount may vary and there is no slippage protection or guaranteed minimum. Source gas is checked during wallet preparation; a full arrival estimate remains unavailable. Missing token prices leave USD-policy checks unresolved. Quote freshness ends at the earlier of Rift's expiry and 60 seconds after observation. **Payment flow:** choose a direct Rift candidate explicitly and create the payment through `POST /v1/payments`. Rift is not an automatic fixed-minimum recommendation and cannot be a leg in a composed payment. Read its `execution` flags. Direct preparation supports reviewed assets on Ethereum, Base, Arbitrum, Ink and Robinhood, plus native Bitcoin. EVM senders must be externally owned wallets; Bitcoin senders must use single-key native SegWit or Taproot. HyperCore remains quote-only. Prepare through the existing endpoint, with a persisted UUID `Idempotency-Key`: ```http POST /v1/payments/PAYMENT_ID/prepare Authorization: Bearer ROUTE_API_KEY Idempotency-Key: PERSISTED_UUID Content-Type: application/json {"version":1,"sender":"SENDER_ADDRESS","recipient":"RECIPIENT_ADDRESS","acceptVariableOutput":true} ``` `acceptVariableOutput` must follow the customer's explicit acceptance; do not silently set it in a UI. It is required for Rift, and does not invent a minimum from the estimate. Route binds the quote, source amount, recipient and sender refund address before allocating an order. Refunds return to the sender; an arbitrary refund override is not accepted. The order's deposit deadline is seven days after creation, while the wallet action has its own shorter review expiry. Always follow current action flags. A timeout does not justify a fresh quote or replacement order: resume the same saved preparation and terms. An ambiguous or malformed allocation is retained for review. Review and sign the exact locally built deposit transaction, then use the existing signature and execution endpoints. Creating or preparing an order does not move funds. Continue with `GET /v1/payments/{id}/next-action` and the existing refresh flow. A submitted source deposit proves funding, not recipient delivery. **Tracking:** Rift statuses are `awaiting_deposit`, `funded`, `underfunded`, `executing`, `delivered`, `refunded`, `expired` and `frozen`. Its reported `amount_out` is destination units for delivered orders and source units for refunds. Route keeps the provider status separate from independently verified settlement. The current REST contract has no payout or refund transaction hash. A delivered or refunded report remains `verification-pending` until a canonical, finalized payout is independently linked to this order. An address, amount and time match alone is insufficient; ambiguous evidence does not complete the payment. Do not fund again because verification is pending. Frozen and underfunded orders need review rather than automatic replacement funding. **Live verification:** on October 1, 2026, an isolated Cloudflare staging Worker successfully read Rift’s health endpoint and received valid live quotes for Ethereum USDC → Base USDC and Ethereum USDC → Ethereum AAPLon (a tokenized stock). The earlier development HTTP 403 / Cloudflare 1010 response did not prevent these Cloudflare requests. The checks created no orders and moved no funds. Live order allocation, funding, delivery and refund settlement remain unverified. A successful quote does not guarantee continued availability, a minimum output, or another pair or amount; the implementation also has contract and simulated-provider tests. References: [Rift quickstart](https://www.rift.trade/docs/integration/quickstart), [token identities](https://www.rift.trade/docs/integration/token-list), [quote API](https://www.rift.trade/docs/api/get-a-quote), [order status](https://www.rift.trade/docs/api/get-order-status), [API contract](https://www.rift.trade/docs/openapi.json). ## SwapKit SwapKit (`swapkit`) adds cross-chain quote comparisons through its underlying providers. A candidate such as **SwapKit · NEAR** or **SwapKit · CHAINFLIP** identifies the service behind that path. Direct NEAR candidates remain separate: account access, fees and route terms may differ. Garden-backed candidates are excluded while Garden is paused. Quote failures distinguish provider limits from authentication. `details.errorCode: "SWAPKIT_SIZE_LIMIT_EXCEEDED"` means the requested amount exceeds the selected SwapKit key's trade-size limit; check that Route's `amount` is a decimal quantity of the source token (for example, `"0.000132"` BTC, not `"13200"` satoshis), then reduce the amount or review the provider key's limit. `SWAPKIT_ACCESS_DENIED` means SwapKit rejected authentication or access. `SWAPKIT_PAIR_UNAVAILABLE` means no current route was returned for the exact assets and amount; it does not by itself identify a minimum trade size. These provider checks are separate from your Route policy and usage-credit balance. **Execution coverage:** simple native-token or ERC-20 deposits from Ethereum, Base or Arbitrum, and native Bitcoin deposits from single-key native SegWit/Taproot wallets, to reviewed EVM ERC-20 assets, Stellar classic/native assets or native Bitcoin. Each candidate reports its own `execution.supported` value. Preparation additionally requires a provider deposit channel with a supported deadline and locally verified transaction fields. Contract-call routes, memo-bearing deposits and other source networks remain quote-only when a quote is available. Garden-backed paths, including Bitcoin escrow routes, are paused for both quotes and execution. Bitcoin channels with a block deadline must also include a wall-clock deadline and have more than six blocks remaining. EVM block-deadline channels need separate support. ## Discover and compare Use `GET /assets` and filter `quoteProviders` for `swapkit`. The reviewed catalog includes popular assets on 33 SwapKit networks. An entry means an exact token identity is recognized; a live quote still decides pair availability and liquidity. Stellar entries include native XLM and Circle-issued USDC, not USDT0. The same `POST /quotes` request applies: ```json { "sourceAssetId": "SOURCE_ID_FROM_ROUTE_CATALOG", "destinationAssetId": "DESTINATION_ID_FROM_ROUTE_CATALOG", "amount": "10", "slippageBps": 10 } ``` No wallet addresses are needed for price discovery. Route sends human-readable amounts and converts basis points to SwapKit’s percentage unit: `10` bps becomes `0.1` percent. Chain, contract or issuer, decimals and exact asset identity remain bound to the requested pair. EVM address casing is normalized; other chain identifiers remain case-sensitive. The current integration compares assets across different networks, consistent with Route’s quote API. It does not expose SwapKit’s same-chain swaps, limit orders or other standalone APIs. ## Candidate fields - `route` names SwapKit and its underlying providers. - In `view=full`, `details.quoteId` and `details.routeId` identify the upstream comparison and offer; `details.underlyingProviders` retains the provider sequence. The optional `compact` view keeps the provider names in `route`. Mainnet defaults to a single recommendation summary with `view=best`; use `compact`/`full` for these candidate details. - `received` and `minimumReceived` preserve the expected output and the published slippage floor. A response with a weaker minimum than the requested tolerance is rejected. - `fees` discloses provider charges without deducting included fees from the output a second time. Inbound and priority estimates are additional. Exact wallet gas, approvals and unresolved fee assets remain explicit, so total cost is not yet marked complete. - `compact` and `full` retain `eta` and its timing scope. In `view=full`, `details.inboundSeconds`, `details.swapSeconds` and `details.outboundSeconds` expose available provider stages. Signing, approval and Route receipt-finality timing are not included in a claimed end-to-end guarantee. - `expiresAt` is bounded by Route’s observation freshness, five minutes from the provider’s quote creation, and any earlier provider expiry. - Provider warnings are returned as bounded codes, never raw credential-bearing errors or instructions to execute. Route applies the owner’s policy. SwapKit’s `CHEAPEST`, `FASTEST` or `RECOMMENDED` tags do not override it. Allowing `swapkit` permits that aggregator’s underlying providers; disabling a direct project connection does not exclude that provider’s liquidity inside SwapKit. Platform-wide pauses do: Garden-backed candidates are unavailable while Garden is paused. The underlying providers are disclosed on each candidate. ## Failure and execution boundaries Connection checks authenticate a dry quote request. A successful check verifies access, not every pair. Quote failures remain isolated from other providers: examples include `SWAPKIT_ACCESS_DENIED`, `SWAPKIT_PAIR_UNAVAILABLE`, `SWAPKIT_RATE_LIMIT`, `SWAPKIT_UNAVAILABLE` and `INVALID_SWAPKIT_RESPONSE`. Price comparisons call only SwapKit’s `/v3/quote`. Route does not follow returned `nextActions` URLs, build transactions, allocate deposits, sign, broadcast or move funds during comparison. During payment preparation, Route calls `/v3/swap` once after saving an allocation claim. The same database transaction saves the preparation and reserves its Route credits and API-key USD budget, valued at a fresh source price. `INSUFFICIENT_CREDITS`, `KEY_RESTRICTION`, `KEY_VALUATION_REQUIRED` or `KEY_BUDGET_EXCEEDED` returns before any SwapKit call; nothing is allocated and the draft can still be cancelled. It binds the returned channel, recipient, assets, amount and minimum output, then reconstructs a supported deposit with current wallet nonce and gas. Use the ordinary `/prepare` → `/transaction` → signature → `/execute` flow described in [protocol execution](protocol-execution.md). If the build response is lost or fails validation, `SWAPKIT_ALLOCATION_NEEDS_REVIEW` preserves the existing attempt. Retrieve the payment’s `providerAllocation`; retry only the same preparation. Route can reconcile a captured response without calling `/v3/swap` again. An unknown provider identity requires operator review and cannot be automatically replaced. `providerAllocation.responseCaptured` distinguishes a saved response from an unknown outcome. Initial build errors can include `error.details.providerHttpStatus` and an allowlisted `providerCode`; these diagnostics do not prove that no channel was created. Allocated payments cannot be archived or cancelled as unused drafts. Until its deposit instructions are attached, the preparation has `deposit: null` and a `preparation-pending` blocker, and it keeps its credit and API-key holds. A SwapKit quote that expires before the claim is made is refused with `QUOTE_EXPIRED`, `SWAPKIT_QUOTE_REQUIRED` or `SWAPKIT_QUOTE_EXPIRED` before anything is reserved. A draft whose quote expired is refused with `QUOTE_EXPIRED` first. One outcome proves that no channel exists: SwapKit's definite refusal, a `400` naming `insufficientBalance`, `insufficientGas`, `outputBelowPublishedFloor` or `outputAmountDeviationTooHigh` with no swap. `POST /prepare` then returns `409 SWAPKIT_BUILD_REFUSED`, and the same transaction releases the payment's credit and API-key holds. `providerAllocation.state` becomes `refused` with its `refusal`, the payment stays `PREPARING` without `lastError`, and `next-action` returns `prepare-payment` until the quote deadline in `providerAllocation.expiresAt`. Fix the cause, for example by funding the source wallet, then call `/prepare` again with the same wallets under any `Idempotency-Key`. Route reserves again before it calls SwapKit, and a refused reservation calls nothing. After the deadline, cancel the payment and start from a fresh quote; a refused build does not block cancellation. A composed leg's refusal keeps its holds and is handled as uncertain. After the claim, every other outcome keeps the holds: a failed build, an unknown outcome, or a channel that expires before deposit instructions are attached. A failed or missing response does not prove that no channel exists, and there is no release endpoint. A failed attempt after the claim sets the preparation to `needs-review` with `lastError`, so the payment reports `REQUIRES_ATTENTION` and webhooks receive `payment.requires_attention`. A request that finds another request's build still in progress leaves the preparation unchanged. If a build is interrupted, the preparation stays `preparing` until a later retry records it. A `/prepare` with the same wallets resumes only a validated or accepted build. It reuses the same channel under any `Idempotency-Key`, and the draft’s own quote expiry no longer applies. The resume works only until the earlier of the channel’s saved quote and deposit deadlines, reported as `providerAllocation.expiresAt`; after that, `next-action` returns `review-required` for operator reconciliation. A changed build goes to [quote review](#reviewing-changed-swapkit-terms) instead. A validated channel saved without a preparation, possible for payments prepared before holds moved ahead of the build, resumes the same way; its credits and budget are checked when its deposit instructions are attached. Tracking treats SwapKit completion and refund hashes as hints. Route verifies the source deposit and the final recipient’s chain credit, then reserves an exclusive payout claim before marking delivery or refund complete. A destination hash you supply to `/refresh` must match the delivery leg SwapKit reports for the saved source transfer, and undergoes the same chain verification. The original credential source is required. A supplied refund hash must also be the refund leg that SwapKit reports; see [removing a provider key](#removing-a-provider-key-with-payments-in-flight). Provider status alone does not complete the payment. Bitcoin payouts require the reviewed confirmation threshold. For SwapKit’s NEAR Ethereum ERC-20 → BTC path, a returned fee reserve can make the actual payout exceed the reported amount. Route accepts that difference only after verifying the signed underlying quote and the exact NEAR bridge allocation. Otherwise the payment remains in verification. EVM native destination assets remain quote-only because internal contract payouts need an additional verifier. Native-source refunds can be verified when returned as a direct transfer. To have Route verify a known refund transaction, send it as `refundHash` to `POST /payments/{id}/refresh` (SDK: `refresh(id, {refundHash})`); the hash is only a hint. References: [API overview](https://docs.swapkit.dev/swapkit-api/introduction), [quote and swap flow](https://docs.swapkit.dev/swapkit-api/quote-and-swap-implementation-flow), [SDK documentation](https://swapkit.github.io/SwapKit/). ## Reviewing changed SwapKit terms If `POST /payments/{id}/prepare` returns `SWAPKIT_ALLOCATION_NEEDS_REVIEW`, retain the payment and its original preparation request key. The provider may already have created a deposit channel. 1. Check `providerAllocation.responseCaptured`. If false, the build outcome is unknown: preserve the original payment and ask an operator to establish its allocation outcome. Do not request another build. When true, read `GET /payments/{id}/quote-review`. When the captured response is valid, Route returns the original and updated minimum receipt, expected receipt, provider fees, expiry and a `reviewHash`. 2. Show those values to the payer. After explicit acceptance, call `POST /payments/{id}/quote-review` with an `Idempotency-Key` and `{ "reviewHash": "", "minimumReceived": "" }`. 3. Retry `/prepare` on the **same payment**, using its original wallets and preparation request key. Route uses the accepted terms, rebuilds the wallet action and rechecks the current policy, balances and gas. Sign and submit through the normal transaction flow. Acceptance neither signs nor submits a transaction. Route retains the original quote, captured provider response and accepted revision; it never requests a second channel for this review. The dashboard provides **Review saved quote** and **Accept updated terms** actions. This recovery applies before deposit instructions or a wallet action have been saved. Acceptance changes only the reserved preparation’s minimum receipt and provider quote; its credit and budget holds are unchanged. It does not extend provider deadlines or waive identity, slippage, warning, policy or fee checks. An unknown build outcome, expired channel, changed recipient or provider warning still requires reconciliation. Do not automatically create a replacement payment or deposit. ## Auto-route and execution checks SwapKit quotes can participate in [Auto-route](auto-route.md) plans. Supported SwapKit simple deposits can execute as legs; Garden is excluded while paused. Every leg must have a released builder and receipt verifier before the complete plan can execute. ## Allbridge and Axelar on Stellar Stellar requests now perform live Allbridge registry checks and Axelar ITS contract reads. They are no longer excluded merely because one network is Stellar. `details` distinguishes registry exclusions, token-registration results, actual fee requests and remaining Route capabilities. Axelar checks verified registrations for Ethereum USDC ↔ **Stellar USDC.ITS**, and native Stellar XLM ↔ **Ethereum XLM.ITS**. The catalog exposes these exact representations as separate choices. Stellar USDC.ITS is a six-decimal Soroban token (`kind: "soroban"`); it is **not** Circle's native seven-decimal Stellar USDC. Do not substitute assets by ticker. Each quote rechecks canonical token linkage, precision, hub trust, pauses, flow limits and applicable destination inventory before requesting relay fees. A registered path can be blocked by current inventory: a recorded 1 XLM.ITS → Stellar XLM check was blocked for that reason. Other networks without an integrated chain reader remain explicit capability limitations. Other token pairs need their own verified registration. Axelar relay fees use the source network's native currency (ETH or XLM). EVM source gas is attempted using exact token and destination call history; missing samples and Stellar Soroban fees remain explicit gaps. Full arrival ETA may remain unresolved; owner delivery policy determines whether that blocks execution. Fresh Soroban simulation replaces modeled source fees during preparation. ITS representations do not automatically inherit their underlying asset's USD price, so valuation may also remain unknown. The last verified Allbridge registry lists Stellar USDC but publishes no active Stellar CCTP v2 deployment. Its implemented EVM execution uses the legacy CCTP V1 path; migration remains an open compatibility task. The last verified Ethereum ↔ Stellar fee requests received a provider rejection. Its [contract documentation](https://docs-core.allbridge.io/product/how-does-allbridge-core-work/allbridge-core-contracts) says pool transfers were discontinued. Route reports that upstream limitation and does not revive deprecated pool routes. A future successful fee response still requires matching active deployments and exact assets before a quote is returned. ### Bitcoin wallet actions For a supported SwapKit Bitcoin source, the existing protocol payment flow returns a base64 PSBT in `transaction.psbt` and its exact input list in `transaction.inputs`. The nested `transaction.transaction` retains the same Bitcoin payload. Sign the saved transaction with a single-key native SegWit or Taproot wallet and return a finalized base64 PSBT or raw transaction hex at `/transaction/signature`. Route verifies every input, output and signature before its single submission attempt. No NEAR intent-message signature is required for a SwapKit payment. Route checks confirmed, unspent inputs, reserves them across providers, returns change to the sender, and estimates the network fee from the actual transaction. A spent input, expired channel or higher required fee blocks the unchanged saved action. Do not replace an uncertain payment automatically. Source finality and independently verified delivery are separate tracking steps. A provider's completed status alone cannot mark a payment complete.