Integration changelog

Changes are grouped by date, with one entry per day. The documentation date records guide, example and schema-description updates separately from the API contract version. Current documentation revision: 2026-10-07. Mainnet contract: 1.44.0-preview. Testnet contract: 0.10.7-preview. Both OpenAPI files expose info.x-documentation-revision.

2026-10-07#

CCTP capacity diagnostics: compact/full quote candidate and composed-leg details can identify a failed capacity read by normalized code, category, network, RPC hostname, method and check. Raw upstream messages are excluded. Default best and list summaries and capacity eligibility checks are unchanged.

Composed wallet inputs: the initial composed next action adds optional walletRequirements naming each required public address and network, including customer-controlled intermediate wallets with ETH for fees. Missing or invalid intermediate addresses return INVALID_INTERMEDIATE_WALLETS; per-address error details identify the field and network. The existing preparation operation, wallet authorization and signing requirements are unchanged.

2026-10-05#

Mainnet 1.44.0-preview — simpler quotes and payment start: mainnet quote responses now default to view=best, with one recommendation summary and preparation status. view=list returns safely selectable alternatives; explicit compact and full preserve the previous diagnostic representations. POST /payments can omit candidateId to accept the saved recommendation, with the existing expiry, policy, provider and API-key checks and no silent route substitution. The SDK's startPayment(input, {quoteRequestId, paymentRequestId}) requests the quote, accepts it and returns the next required action; it never signs, submits, automatically retries or creates a replacement. Persist both UUIDs and reuse identical input after a timeout. Testnet still defaults to compact and requires an explicit candidate. Reading or changing quote views never creates a payment or adds a quote charge.

2026-09-30#

Security hardening: Axelar service/factory and Allbridge CCTP bridge addresses are pinned to independently reviewed deployments. Changed or unreviewed targets are refused during quoting and before new approvals, signing, submission or wallet handoff, including saved actions.

SwapKit delivery attribution: a supplied destinationHash now requires the original provider connection and must match the final delivery leg SwapKit reports for the saved source transfer. Canonical chain verification and exclusive payout claims still apply. Missing credentials, unavailable tracking or unrelated recipient credits cannot complete the payment or release its reservations. Reconnect the original connection and track the same payment; do not resend. This tightens the earlier supplied-hash recovery behavior.

Workspace access and releases: members restricted to specific projects cannot manage workspace billing, credit top-ups or workspace settings, including with the Admin role. Production release tooling now requires successful GitHub Actions runs for the exact main revision, including all required checks, before migration or deployment. These fixes change no contract version.

2026-09-27#

Pending wallet report guidance: unresolved transaction reports on unsettled payments now return normalized next-action: review-required with no automatic operation. Recovery must retain the authorization ID and hash from the original report. This avoids confirming a pending cancellation as a payment or recording an earlier approval's hash against a later transfer. Ordinary handoffs with no reported evidence still offer confirm-wallet-broadcast; explicit confirmation retries remain available. No schema or contract version change.

Payment reliability and account security: payment states are normalized across direct, composed and testnet responses. Unknown wallet submissions are explicit and wallet-altered calls require review. Provider fee ceilings include disclosed headroom and cannot reduce an accepted recipient minimum. Managed Stellar delivery continues polling after a relay hash is known; failed or expired relays require attention. SwapKit accepts independently verified destination/refund hashes for recovery. API-key spending holds are released on a finalized source revert; dashboard payments created from API-key quotes retain billable provenance. Exact token price mappings replace canonical-price shortcuts for bridged assets.

Webhooks and access: every payment event has a monotonically increasing version, including a return to an earlier state. Endpoints created by policy-scoped keys receive only that policy's events. Approved receivers have a 24-hour delivery window; legacy receivers with unknown creation scope require dashboard review before reactivation. Removed or demoted members' affected keys are permanently revoked. Sign-in requests preserve other browsers' links; workspace and invitation limits prevent email abuse. Ended sessions and ended invitations are removed after 90 days.

These reliability and security fixes change no contract version: mainnet stays 1.43.0-preview and testnet 0.10.7-preview.

Client changes in 1.43.0-preview and testnet 0.10.7-preview: paymentState on payments and next-action status now use the documented PaymentState enum on both contracts, as does the new workflow.paymentState on mainnet composed payments. Composed payments previously carried the workflow's lowercase state (for example intermediate-held) and testnet payments repeated their lowercase status (for example source_pending); both now carry the enum value, such as INTERMEDIATE_HELD or SOURCE_PENDING. A testnet payment whose status is completed reads VERIFICATION_PENDING or DELIVERED_PENDING_FINALITY until its receipts are verified and final. workflow.state and testnet status keep their lowercase values; treat unrecognized states as non-final. ProtocolTransaction.network is now an exact network identifier instead of a four-value enum. broadcast-confirm returns 409 WALLET_TRANSACTION_REVIEW_REQUIRED when a wallet kept the payment call but changed its nonce, fees or envelope type. SwapKit /refresh accepts refundHash (not together with destinationHash). Candidate.reliabilityWarnings lists informational RECENT_DELIVERY_FAILURES. Webhook envelopes add a top-level version (a strictly increasing per-payment sequence), deliveries add expired, endpoints expose policy_id and scope_review_required, and test or retry of an endpoint that is not enabled and approved returns 409 WEBHOOK_NOT_ACTIVE. A key whose issuer lost the access it needs fails with 401 KEY_ISSUER_ACCESS_REVOKED. GET /v1/adapters adds NEAR capabilities.executionNetworks, and responses carry an informational X-Route-Build header.

Close an unused EVM payment: POST /payments/{id}/transaction/close can close an unfunded standalone EVM protocol payment whose current approval, approval reset, burn or transfer was never signed, submitted or handed to a wallet. It becomes available once the action's review expires, when transaction.closeEnabled is true with closureRequirement: "finalized-nonce-cancellation". The request needs cancellationHash: a canonically finalized transaction from the same sender at the saved nonce, either a zero-value self-transfer or any transaction that neither repeats the payment call nor calls, is logged by or pays the payment's provider contracts or deposit address. Route never creates or sends it. The payment becomes cancelled, only its nonce reservation, API-key holds and payment-credit hold are released, and transaction.closure.proof.proofType is self-cancellation or nonce-consumed. Refusals return 409 EVM_CLOSURE_UNAVAILABLE (with details.expiresAt while the review is live), 409 EVM_CANCELLATION_REQUIRED (naming the network, sender, nonce and observedState), 409 EVM_CLOSURE_REVIEW_REQUIRED (another transaction the wallet signed, recorded as review evidence) or WALLET_RECOVERY_UNAVAILABLE (the network read failed; the reported hash stays recorded and blocks the payment); none releases anything. See closing an unused EVM protocol action.

Same payment sent at another nonce: before closing an expired, unsigned EVM payment, or a wallet handoff or saved-signature source cancelled at its nonce, Route searches the wallet for the same payment sent at another nonce, from when the payment was first revealed. Allbridge payments are searched through the source token's transfers to the bridge. A match is recorded as review evidence and saved on the action as lastError (WALLET_TRANSACTION_REVIEW_REQUIRED, reason: "equivalent-execution"), the close returns EVM_CLOSURE_REVIEW_REQUIRED and every reservation is kept. Route then never submits the saved call or hands it to the wallet, as for a wallet-altered call. Evidence that Route later attributes to another of its payments is resolved, with the attribution checked by the database and audited. Where Route cannot search or cannot finish, a signed-in workspace member with payment permission, who signed in within the last 15 minutes, can use Close after manual check in the dashboard with a reason and an explicit attestation (manualCloseEnabled). The finalized transaction at the saved nonce is still required, recorded same-payment evidence is never overridden, and the release of the wallet slot, API-key hold and credit hold is audited. API keys cannot use it.

Dashboard closes and SDK: expired, unsigned EVM actions offer Close this unused payment, which shows the network, sender and nonce, takes the finalized hash after explicit consent and never sends a transaction; Close this expired payment appears only for Stellar actions. In the SDK, closePayment(id, authorizationId, key, cancellationHash?) sends the EVM closure hash and refresh(id, {refundHash}) submits a known SwapKit refund transaction for verification.

Provider fee ceilings: comparisons carry the disclosed 10% reserve (details.providerFeeHeadroomBps: "1000" in view=full), including Stellar CCTP, LayerZero and Axelar paths. The reserve remains included in compact cost and receipt estimates. Informational Stellar Allbridge comparisons carry no reserve, because Route does not execute that path.

Wallet-altered transactions: broadcast-confirm returns 409 WALLET_TRANSACTION_REVIEW_REQUIRED with WalletAlteredTransaction evidence in error.details when the wallet kept the payment call but changed the nonce, fees or transaction type, and broadcast-recover can return state altered-payment on mainnet and testnet. Route keeps every such observation and saves the latest as the action's lastError (on testnet it can now be an object); hosted testnet errors now include error.details. Recorded evidence on a burn or transfer blocks cancellation closure: canClose is false and closing returns 409 WALLET_CANCELLATION_REVIEW_REQUIRED (SOURCE_CANCELLATION_REVIEW_REQUIRED or COMPOSED_CANCELLATION_REVIEW_REQUIRED for saved-signature and composed sources) with the recorded evidence, keeping every reservation. An altered spending approval moves no funds: it is flagged the same way, but a finalized cancellation of its saved nonce still closes an otherwise unfunded payment, unless the same payment was found sent at another nonce. Route never sends the saved call once such a call is recorded, for protocol actions, NEAR source transactions and testnet actions alike and whatever the account nonce shows, including a wallet-altered copy or the same payment that a /transaction/close or close after manual check observed, even after a later review refresh and signature. Every such observation goes to one append-only evidence journal that the API checks and database triggers read, with the action's lastError, which the database keeps while the evidence is unresolved: /execute and a new /transaction/broadcast wallet handoff return 409 WALLET_TRANSACTION_REVIEW_REQUIRED before any external read, and the handoff reserves nothing and returns no eth_sendTransaction params. An existing handoff is still returned and nothing is sent, but with walletBroadcast.method: null, empty params and a review notice. Transaction views stop offering what Route refuses: walletBroadcastAvailable, signingEnabled and submissionEnabled are false, and mainnet protocol actions now carry actionBlocker (WALLET_TRANSACTION_REVIEW_REQUIRED, evidence in details) as GET NEAR transaction does. The evidence stays the lastError; after an uncertain Route send of the saved original it carries that send's SUBMISSION_UNKNOWN diagnostic as submission. The database refuses the same submission or handoff, answered with the same 409 on mainnet and testnet (testnet previously returned 503). The handoff of an altered spending approval is not refused and keeps its params, but its saved signature is never submitted (submissionEnabled: false); confirming the exact original of an earlier wallet handoff still registers it. Preparation nextAction and testnet nextStep return review-required. A transaction the wallet signed that is the same payment without being the saved call (re-quoted with another fee or finality threshold, another value, another envelope type including blob and set-code transactions, an unreadable call to the payment contract, or any call to its provider contracts or deposit address), sent or still queued at any nonce, is now recorded the same way when it is reported to /transaction/close, the close after manual check, broadcast-recover, broadcast-cancel or a source cancellation: recovery returns state equivalent-execution, the close returns EVM_CLOSURE_REVIEW_REQUIRED with observedState: "equivalent-execution", and Route then never submits or hands off the saved call. Route fails closed on every other reported transaction: any transaction whose signature recovers to the sender and that is neither the exact saved transaction nor a recognized cancellation (the zero-value self-transfer at the saved nonce, or for /transaction/close a finalized non-payment transaction at it), at any nonce and in any envelope (including the saved call batched through the wallet's delegated EIP-7702 or smart-account execution, another contract of the provider or another bridge, and legacy transactions signed without replay protection, accepted as evidence only), is recorded as WALLET_TRANSACTION_REVIEW_REQUIRED evidence with reason: "unclassified-sender-transaction" (recovery state unclassified-sender-transaction, close observedState: "unclassified-sender-transaction"), also at broadcast-confirm, for NEAR, protocol and testnet actions, approvals included. It blocks submission, handoff and closure like the other kinds, and only Route's audited attribution to another of the project's payments resolves it. Recovery no longer returns different-transaction. NEAR source transactions now have a same-payment rule from their 1Click deposit (equivalent-execution with provider: "near"), and recorded NEAR evidence blocks their cancellation closure. Freeze on report (payment scope): every hash reported for any action of a payment (to broadcast-recover, broadcast-cancel, broadcast-confirm, /transaction/close, the close after manual check or a source cancellation, on mainnet and testnet) is recorded for the whole payment before Route reads the network or checks whether the payment could close, unless it is that action's own saved or wallet-confirmed transaction or its recorded cancellation. An inspection then classifies the same record or clears it (the action's own transaction, which still registers, or a recognized cancellation at the saved nonce); one the network does not show yet, or cannot read, stays recorded as new reason: "reported-transaction" evidence (recovery state reported-transaction) and keeps blocking. Who signed it no longer matters: a relayed or sponsored EIP-7702 / ERC-4337 execution, an L2 system or deposit transaction (for example OP-stack type 0x7e) or an unsigned, unknown or other-key envelope is recorded as new reason: "unclassified-transaction" (recovery state unclassified-transaction, close observedState: "unclassified-transaction") instead of WALLET_RECOVERY_UNAVAILABLE or a bare WALLET_TRANSACTION_MISMATCH. Evidence on any action blocks every action of the payment: /execute, a new handoff and a new action (POST /transaction; testnet /prepare and /transaction) return 409 WALLET_TRANSACTION_REVIEW_REQUIRED, the database refuses the same, no cancellation of any action releases the payment's holds, and an action without evidence of its own shows the payment's evidence as lastError. A NEAR source on Optimism, Polygon, BNB Chain, Avalanche, Gnosis and the other allowed EVM networks is now inspected and recorded (closing still needs Ethereum, Base or Arbitrum), and a signed testnet authorization without a handoff can report a hash at broadcast-recover. An approval's byte-identical call in any envelope, including set-code (type 4), is the exempt altered approval. WalletAlteredTransaction.observedNonce is no longer required and its gas fields remain optional; it adds observedFrom, signer and reported. different-transaction stays in the recovery state enum but is no longer returned. Only Route's audited attribution to another payment with matching terms lifts the block; NEAR and testnet evidence needs operator review. A same-payment copy that nobody reports to Route cannot be seen. Only a finalized recognized cancellation clears a report: a pending self-cancellation or nonce proof (recovery cancellation-pending, close observedState: "nonce-consumed-pending") keeps it blocking until a later check sees it final, and broadcast-confirm never clears one. A testnet action takes reports from /prepare on, before its authorization is requested (/transaction is then refused), and broadcast-confirm for an action without a handoff returns 409 WALLET_TRANSACTION_REVIEW_REQUIRED with the recorded report instead of 404 when the hash is on record. While such a check reads the network, /execute and a new handoff return 409 WALLET_EVIDENCE_CHECK_IN_PROGRESS (retryable; it lapses after 2 minutes), and what a check observes is recorded even if the caller's access ends during it or the check outlives those 2 minutes while a submission or handoff starts; a close or cancellation whose check outlived them returns 409 WALLET_EVIDENCE_CHECK_EXPIRED (retryable) and closes nothing. An altered spending approval can now be closed with a finalized nonce proof, and a Stellar hook naming another payment attributes evidence to it only when that payment has the same terms or a saved action with the same calldata.

Managed Stellar relays: a managed Circle-to-Stellar mint whose first OpenZeppelin Channels response was lost (a timeout, HTTP error, invalid reply, a relay ID Route could not save, or a submitter stopped for more than a minute) is saved as submission-unknown with evidence in destinationExecution.lastError, and the payment reads REQUIRES_ATTENTION with next action review-required (on mainnet it also appears in operations attention and emits payment.requires_attention). When Channels resubmits under a new hash, destinationExecution.relayHashes lists every reported hash and transactionHash is the latest, which tracking verifies; a relay replaced more than 16 times stops as failed (DESTINATION_RELAY_UNSTABLE). On mainnet a failed receipt for the tracked relay keeps the payment in REQUIRES_ATTENTION while Route keeps polling Channels, unchanged relay polls no longer change the payment version, and GET /payments/{id}/recovery reports operator-review for a failed or submission-unknown mint.

Guarded automatic re-mint: when the first managed relay lost its response before Route saved a relay ID, or Channels reported it failed or expired, destinationExecution.lastError.retryAllowed is true and remintAfter is 15 minutes after the attempt. After that, background tracking or /refresh sends the same saved mint call once more, only when managed execution is enabled, the Stellar ledger is fresh, the Circle attestation is more than 180 ledgers from expiry, the exact call still simulates without new authorization, and the CCTP nonce, read immediately before sending, is unused. Otherwise nothing is sent, lastError.remint records why and the payment stays REQUIRES_ATTENTION. The replaced attempt is listed in destinationExecution.relayAttempts; a second lost or failed relay has no further automatic recovery. Completion follows whichever recorded relay minted the message, a duplicate that failed only because the message was already minted is not reported as a destination failure, and a mint no recorded relay proves reports DESTINATION_MINTED_UNRECORDED (supply its hash to /refresh on mainnet). Relay and re-mint claims and skipped re-mints are written to the workspace audit log.

Confirm a SwapKit refund in the dashboard: when SwapKit returned a deposit but cannot confirm the refund, for example after the SwapKit key was removed, a workspace member with payment permission can confirm it with the refund transaction hash. Route first asks SwapKit when a connection is available and refuses if SwapKit reports a delivery, any refund or other delivery evidence. It then verifies on chain that the transaction is finalized, credits the payment's source asset to its refund address after the deposit, was not sent or funded by the payment's sender, refund or recipient address, and returns an amount between the dust floor and the deposit; the transaction is reserved as this payment's exclusive payout and the confirmation is audited. The payment reads REFUNDED with tracking.refundConfirmation (method: "manual", the member, amounts, senders and providerCheck). API keys cannot create this confirmation.

Provider credential removal: credential PUT and DELETE responses are documented as CredentialUpdateResult. UNSETTLED_PROVIDER_PAYMENTS now counts only funded payments that use the project's own key and have no terminal outcome: a payment counts when it has a source hash or an unconfirmed wallet handoff of a funding transaction. A payment funded by a direct deposit to its NEAR deposit address is not counted until its source hash is registered. The SwapKit credential DELETE body requires only version.

Rolling API-key holds: holds that a canonically finalized source revert had already left stuck are released once during the upgrade, under the same rule as new reverts: standalone payments, or the first transfer of a composed payment before a second transfer starts. The key guardrail reference lists every release (a finalized source revert, or a verified final cancellation or closure of an unfunded payment); there is still no time-based or operator release, and a release does not deactivate a NEAR or SwapKit deposit address.

Access follow-up: narrowing a member from all projects to a list revokes only their keys for the projects they lose, decided against the member's final access when the change commits; other members' keys and the member's keys in other workspaces are never revoked. At release, existing keys whose issuer was already removed or lost access to the key's project, the right to issue keys or a permission one of its scopes needs are revoked (401 KEY_ISSUER_ACCESS_REVOKED). Sign-in link limits treat an IPv6 /64 as one network (a /48 for the per-email network limit) and count one mailbox, ignoring plus tags and Gmail dots, per browser, per network and for the overall 30 per hour; a browser holding the account's own recent unrevoked session is exempt from the hourly limit, and a 429 names the limit with Retry-After and retryAfterSeconds. Invitation caps count one mailbox per workspace: at the recipient cap the invitation is saved without an email (emailNotification: "suppressed"), a mailbox is not emailed twice in 24 hours (recently_sent), and the 50-per-day inviter limit counts every invitation created or emailed.

Team invitations and access: a pending invitation lapses when the admin who last saved it is removed, demoted or limited to specific projects, and acceptance and the invitee's pending list recheck that the inviter can still invite across the whole workspace. Unexpired invitations already orphaned this way are revoked at release, and each lapse is a system entry in the audit log. The team list shows who last saved each invitation, and the dashboard warns before removing or restricting such a member. Reading the audit log or team list now requires access to all projects (403 FULL_ACCESS_REQUIRED otherwise), and the dashboard hides those pages for project-limited members.

API keys and limits: UUIDs in paths and Idempotency-Key values are canonicalized to lower case before Route derives locks, rate-limit buckets, idempotency scopes and sealing contexts, and protocol and testnet wallet actions accept an upper-case authorizationId. Each API key has its own allowance of 12 quotes and 12 payment drafts per minute within the project's 120 requests per minute, and a quote that no enabled provider can serve returns 409 PROVIDER_REQUIRED before spending the allowance or reserving credits. The audit log and payment draft events record which API key acted ("member via API key …"). Rate-limited 429 responses carry Retry-After, and authenticated customer responses carry RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset for the project budget.

Arrival evidence warnings: policies with fastest delivery or a delivery deadline return warnings from GET and PUT /v1/policy, and Auto-route speed and balanced results include autoRoute.warnings; saving is never blocked. End-to-end arrival is modeled only for reviewed direct paths between Ethereum, Base, Arbitrum, Stellar, Bitcoin, Tron and Solana, until the arrival model review lapses on 2026-10-27 00:00 UTC. Managed CCTP delivery to Stellar also depends on Circle attestation timing, whose review lapses on 2026-10-19 00:00 UTC; the warnings name that date and exclude that path once it passes. The dashboard shows the coverage and expiry dates on the policy form, the saved policy, the simulator and Auto-route. See Fastest estimates.

USD pricing coverage: GET /v1/assets marks each asset usdPricing: "reviewed" or "unsupported". Assets that used to borrow a canonical asset's price without their own reviewed market now return UNSUPPORTED_PRICE_ASSET: NEAR-bridged ETH, nBTC and FRAX; Solana USD1; Starknet XRP; Aptos BTC, ETH, SOL, XRP, LINK, UNI and AAVE; and both HyperCore USDC representations. Routes to or from them cannot be recommended or prepared under a USD policy. reviewed covers only the asset's own price. See Pricing identity and reliability.

Delivery reliability warnings in the dashboard: a cost-first route with recent failed or delayed deliveries shows its warning inside the card that presents it, or next to its quote line when another route fills those cards, and on its comparison row.

Legacy webhook endpoints: endpoints created before mainnet 1.43.0-preview are attributed from creation evidence. One that no API key of its creator could have created stays project-wide; one that only a single policy's keys could have created, and no recent dashboard sign-in could have, takes that policy. An endpoint that either a dashboard sign-in or an API key, or keys of several policies, could have created is disabled with scope_review_required: true until a dashboard user re-enables it as project-wide. Each assignment or review requirement is a system audit entry. Breaking: API keys, including default-policy keys, no longer list or manage project-wide endpoints; manage those in the dashboard.

Webhook events: data.status describes the event, not paymentState: mainnet uses upper-case event names and testnet the lower-case saved status, and webhooks maps each to the state a read returns, including testnet payment.mint_renewed. A composed parent stream no longer repeats a settled transfer's milestone, sends payment.requires_attention for a transfer once until its next milestone, and sends nothing after payment.completed. An uncertain Route send of a spending approval emits payment.requires_attention and reads REQUIRES_ATTENTION until a later action is saved. Temporary receipt, provider-status or destination-lookup outages emit nothing, and a pending payment reads VERIFICATION_PENDING while tracking retries. Route's verification refusals keep their own code in preparation.lastError, read REQUIRES_ATTENTION and emit payment.requires_attention; a later temporary outage does not replace a saved refusal, which clears only when an observation succeeds. A managed relay that failed or lost its response also emits payment.requires_attention. A wallet handoff emits no event until its broadcast is verified.

Background tracking follows payment progress: scheduled checks of mainnet protocol payments no longer recheck every payment every minute. A receipt included but not yet final is checked every minute; a submitted hash without a receipt, or a confirmed source whose delivery is pending, every minute for an hour after the latest new evidence and then gradually slower up to hourly, never dropped. A managed mint paused by the service is checked at least every five minutes, failed destinations and signed EVM or Bitcoin actions never submitted slow to every six hours, a signed Stellar action never submitted stops being checked an hour after its time bounds expire, and a prepared payment waits for its next signed or confirmed action. /refresh checks at once and restores the one-minute cadence on new evidence. A check that only records a new observation time no longer changes the payment version or records a tracking update, so destinationExecution.updatedAt shows when the relay state last changed. Each run checks up to 25 payments, moving funds first.

Automatic tracking errors: scheduled protocol tracking records the same error code and message as /refresh when evidence contradicts the saved action or a required provider connection is missing, for example SOURCE_EVENT_MISMATCH, RECEIPT_MISMATCH, MESSAGE_MISMATCH, HUB_RECEIPT_MISMATCH, SWAPKIT_TRACKING_MISMATCH, PROVIDER_CREDENTIAL_REQUIRED or PAYMENT_CHECK_FAILED. lastError.attempts counts the consecutive checks that returned the same code, and rechecks back off from five minutes, doubling while that code repeats, up to six hours. Other refusals also keep their code and read REQUIRES_ATTENTION, but are rechecked on the regular schedule. DESTINATION_DISCOVERY_UNAVAILABLE and PROVIDER_TRACKING_UNAVAILABLE keep their own code; unavailable network reads and internal failures are recorded as TRACKING_UNAVAILABLE. Those outages retry after five minutes, doubling per failure up to an hour, and leave an already saved refusal and its count in place. See Tracking and recovery.

Axelar ITS to Ethereum: ITS transfers now send the chain name from Axelar's registry, returned in view=full by EVM and Stellar Axelar quotes as details.sourceChain and details.destinationChain (Axelar registers Ethereum as Ethereum). Previously routes to Ethereum quoted as executable but could not be built: EVM sources failed transfer simulation, sometimes after the ITS approval had been paid, and Stellar sources failed at /prepare. Source-event verification and the historical gas model use the same name. Route requires verified registry names for execution support; both quote views report that support in the candidate's execution, while compact responses omit the chain diagnostics.

Circle forwarding stalls: for Circle forwarding to EVM destinations, tracking records Circle's forwardState as a hint with attestedAt. When Circle attested a burn but reports no forwarding transaction after 30 minutes, tracking becomes needs-review and tracking.selfRelay names the destination network, MessageTransmitterV2 contract and receiveMessage call, with its arguments in tracking.message and tracking.attestation. Anyone can relay the message and supply the hash to /refresh, which verifies it fully; Route keeps polling and completes the payment if Circle's forwarding lands first.

SwapKit reserves credits and budget before building a channel: POST /payments/{id}/prepare saves the SwapKit preparation, its credit hold and its API-key USD budget hold in the same transaction as the allocation claim, before SwapKit is called. INSUFFICIENT_CREDITS, key restriction, valuation and budget refusals, and an expired quote (QUOTE_EXPIRED, SWAPKIT_QUOTE_REQUIRED or SWAPKIT_QUOTE_EXPIRED), now return with nothing allocated or held. A definite SwapKit refusal that proves no channel exists (400 naming insufficientBalance, insufficientGas, outputBelowPublishedFloor or outputAmountDeviationTooHigh) returns 409 SWAPKIT_BUILD_REFUSED and releases the holds, and providerAllocation.state becomes refused. Any other failure or unknown outcome after the claim keeps the holds and sets the preparation to needs-review. A validated channel resumes through /prepare with the same wallets under any Idempotency-Key until providerAllocation.expiresAt; after that next-action returns review-required. See SwapKit.

Incomplete Auto-route searches: autoRoute.search.complete is false when a provider could not quote a searched intermediate leg, and autoRoute.search.notes lists unavailable legs, rule exclusions and three-step directions excluded by coverage or key restrictions; decision.explanation says when a search is incomplete. A three-step request with one intermediate asset searches direct and two-step paths only (search.secondLegsPerFirst: null). The dashboard shows the scope that actually ran and the notes, and TypeSafe evidence is now route-evidence-v4. See Auto-route.

Quote lifetime and slippage: a quote's expiresAt now covers its USD prices and every eligible or preparable candidate; other candidates keep their own, possibly earlier, expiresAt and no longer shorten the quote or cause 503 OBSERVATION_EXPIRED. A candidate past its own expiresAt still cannot become a payment (409 QUOTE_EXPIRED, or QUOTE_EXCLUDED if already excluded), and the examples refuse a lapsed candidate. Mainnet POST /quotes and POST /auto-route return 400 INVALID_SLIPPAGE when slippageBps is not an integer from 0 to 1,000. See customer API.

Simulator and policy display: the recommended route card says "Estimated delivery" only for a current end-to-end estimate, leads with the quoted minimum, and labels a best quote that cannot execute "(execution not available)". Policies saved before USD limits show their original USDC units marked "legacy units, not applied", and editing one requires confirming the values as USD. The policy form refuses a delivery time that is not blank or whole seconds from 1 to 86,400.

Idempotency-Key errors: a missing or non-UUID Idempotency-Key returns 400 IDEMPOTENCY_REQUIRED instead of 404 NOT_FOUND on composed prepare, advance and refresh-route, transaction/bitcoin-recover, webhook creation and rotation, and testnet transaction and transaction/renew. On NEAR payments, source renewal, deposit review and captured quote-review acceptance still answer 404 NOT_FOUND, as the OpenAPI documents.

Asset identities: each GET /v1/assets entry includes address (EVM token contract, Stellar asset contract, provider-chain token address or native) and, for Stellar classic assets, issuer; NEAR Intents provider tokens also include providerChain and nearAssetId. Compare EVM addresses case-insensitively. Native Circle USDC on Stellar can be verified by issuer GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN, and the quickstart examples select assets by contract and issuer.

Testnet payment list pages: testnet GET /v1/payments accepts view, limit (1–100, default 50) and cursor, and returns view, hasMore and nextCursor, like mainnet; an invalid view or limit returns 400 INVALID_INPUT. Cursors are not accepted across networks.

OpenAPI corrections: DELETE /providers/swapkit/credential documents its {version} body. POST /payments/{id}/refresh no longer claims to be read-only: for managed Circle-to-Stellar delivery it may submit the already-authorized mint through OpenZeppelin Channels once (apart from the single guarded re-mint above). GET and POST /payments/{id}/quote-review gain operation IDs, scopes, error responses and a oneOf body for SwapKit and NEAR acceptances, and every testnet operation declares x-required-scope.

Payment lists and database access: payment lists, the operations overview, analytics and status filters look up source transactions through an index, and updates find a composed payment's current leg through an index, so large accounts no longer hit the 10-second query limit. The public Worker's database role can no longer create routing policies, policy groups or quotes, or change provider settings.

Request failures and scheduled jobs: an unexpected failure or 5xx records one sanitized operational event with the response's X-Request-Id, method, route template and error code, never bodies, identifiers or messages. When a POST, PUT or DELETE to Route's payment, quote, policy or provider service fails unexpectedly, the 503 message says the request may have taken effect: read the current state before retrying. A USD price read still in flight when its request ended no longer stalls later quotes on that Worker instance. A scheduled run that is cancelled, stops responding or is still running after five minutes counts as a failed run when its lease is reclaimed, repeated losses raise an alert, and provider jobs run on three independent schedules.

Billing: top-up checkout ignores a background status refresh that started before a newer action or returns an older state, so it can no longer offer payment again after submission or undo a verified credit. Invoices include automaticChecksEndAt and checksEnded, and checkout says when automatic checks end and stops polling afterwards. While usage charging is paused, Billing shows the reserved credits that will still be charged at their original rates, with each held operation's rate version and price.

Dashboard reliability and accessibility: revoking an API key or signing out a session asks for confirmation first, and signing out in one tab returns this browser's other dashboard tabs to the sign-in page, which says whether you signed out, the session was ended elsewhere or it expired after inactivity. Confirming a recent sign-in in another tab no longer signs out the original tab. Edit dialogs close once a change is saved, and a failed follow-up refresh says the change was saved. The account still loads when invitations cannot, with Try again. Provider health keeps fresh check results visible, dropdowns no longer discard unsaved forms on Tab, status badges use explicit colours, asset pickers list only verified quotable assets, focus outlines and focus placement are fixed, and details no longer re-announce their whole content.

Guide corrections: Track and recover states the 131,072-byte PUT /policy limit and that the six-attempts-per-minute preparation limit applies to NEAR provider preparation, and release status describes renewal of an expired customer-signed Stellar mint.

Landing examples: receipts now lead with the selected networks and assets, with expandable fee, timing and provider details. Ethereum USDT → Stellar USDT0 recordings were refreshed. Recorded comparisons can now use clearly labelled illustrative network-fee budgets for missing source charges. The receipt lists assumptions and the JSON view preserves original API decisions separately. Quoted multi-step paths remain visible when the demo fee limit or missing combined ETA prevents selection, including Tron USDT → Arbitrum USDT0 → Stellar USDT0. This changes the landing demo only; live quote eligibility, policy checks and execution requirements are unchanged.

Fastest comparisons: reviewed direct paths now expose modeled completion ranges alongside the original provider-stage timing. Ranking includes confirmation allowances and preserves the managed Stellar CCTP source-finality gate. The landing simulator displays estimate ranges and their assumptions across Ethereum, Base, Bitcoin, Tron, Solana and Stellar. Timing availability is distinguished from fee-policy and readiness blockers. Unmodeled or degraded timing remains unresolved. See Fastest estimates.

EVM source gas history: the historical gas model now reads event history in consecutive older pages sized to public RPC limits, so it can reach the documented 24 hours on Ethereum, Base and Arbitrum within its fixed read budget. A provider limit narrows only the page that hit it, and later pages are sized from the event density already read. Before this, provider range and response limits could stop the search after minutes on Base and hours on Ethereum and Arbitrum. That left CCTP burn gas unavailable even when recent burns existed. Stellar CCTP burns that carry metadata after the recipient hook, including Route's own, now count as samples. Margins, freshness and exact-call checks are unchanged.

EVM → Stellar CCTP quote checks: Ethereum, Base and Arbitrum USDC → Stellar USDC quotes now read the source per-message burn limit, messenger and Stellar token mappings, and CCTP and source USDC pause states at the quoted block and ledger, plus the global Fast allowance for Fast. capacity is observed, blocked (excluded, with the reason) or unknown when a read fails. Sender restrictions, balances and allowances remain preparation checks. With observed capacity, a candidate whose only open check is source gas can be prepared with deferred source gas. Stellar-source quotes are unchanged.

Stellar CCTP burns pass their own signature and submission checks: mainnet 1.41.0-preview sizes every Stellar action from an enforcing simulation of the assembled, authorized envelope and adds a bounded resource reserve (20% plus 1,000 stroops on the resource fee, 2% plus 20,000 instructions). Signature and submission re-simulate the exact saved envelope and compare its declared fee, resources and footprint. Previously every Stellar burn failed those checks with TRANSACTION_FEE_CHANGED. The fee budget of new Stellar actions rises by the reserve, and that fee is checked against spendable XLM. Customer-signed Stellar mints carry the same reserve within their destination fee ceiling, so DESTINATION_FEE_EXCEEDED applies slightly sooner. Older saved burns and transfers may fail the stricter checks; use the proof-gated recovery flow after expiry. See Stellar CCTP approval.

Expired Stellar CCTP approval renewal: next-action can return renew-approval. ProtocolTransaction.approvalRenewalEnabled marks an expired Stellar approval with no included receipt. POST /payments/{id}/transaction/renew proves ledger expiry, no receipt and an unused wallet sequence. It then prepares a fresh action at the same sequence for a new signature: an exact approval, or the burn when permission already covers it. The original action and holds are retained; APPROVAL_RECONCILIATION_REQUIRED means nothing changed. An expired action that cannot be renewed now reports nextAction: "review-required" instead of sign or submit. The SDK adds renewApproval. See approval renewal.

Expired Stellar burn and transfer renewal, and payment close: for mainnet Stellar-source protocol payments (Circle CCTP, LayerZero, Axelar), an expired burn or transfer that was never signed now offers renew-source on POST /payments/{id}/transaction/renew, with the same proof. The replacement is a fresh action at the same wallet sequence with fresh terms: for CCTP the burn, or an approval if the allowance lapsed. ProtocolTransaction.sourceRenewalEnabled marks eligibility, and SOURCE_RECONCILIATION_REQUIRED means nothing changed. New POST /payments/{id}/transaction/close closes an unfunded standalone payment whose current Stellar action provably can never execute. The payment becomes cancelled, and its wallet sequence, API-key holds and credit hold are released, so other payments from that wallet are no longer blocked with WALLET_SLOT_RESERVED. next-action returns close-payment for a signed, submitted or uncertain expired burn or transfer, which cannot be renewed, and for an expired approval or unsigned transfer whose renewal cannot run (execution paused, or the payment's saved settings changed); error hints then point to /transaction/close, not /transaction/renew. ProtocolTransaction.closeEnabled also marks an expired approval or unsigned transfer the app may choose to close, and closure holds the proof. A closed payment's tracking.status is closed, and the closure emits payment.cancelled without a later payment.requires_attention. Closing sends nothing, does not revoke an allowance and does not need execution enabled; CLOSE_UNAVAILABLE means nothing changed. The SDK adds closePayment and accepts renew-source for these protocol payments. See closing an expired Stellar payment.

Stellar actions a wallet broadcast itself: a wallet can sign and broadcast a returned Stellar XDR without sending the signature back to Route. Because a Stellar hash excludes signatures, renewal and closure now look up the saved envelope hash first. If the network has exactly the saved envelope with the sender's signature, the request is refused and Route adopts that transaction as the submitted action and tracks it (next-action: track, a wallet.broadcast_verified event and payment.submitted). If the account sequence was used, whether or not the network returns a receipt Route can verify (a fee-bump wrapper or other signatures are never adopted), the observation is recorded (sequence-consumed, lastError.code: STELLAR_SEQUENCE_REVIEW), the preparation moves to needs-review for good (paymentState: REQUIRES_ATTENTION, one payment.requires_attention webhook) and the payment moves to review-required instead of being offered renewal or closure again. Recovery reports no longer say an unsigned Stellar transfer moved no funds. For protocol payments, POST /transaction/renew, /transaction/close and the other protocol mutations now return 400 IDEMPOTENCY_REQUIRED for a missing or non-UUID Idempotency-Key instead of 404 NOT_FOUND; a NEAR renew-source keeps returning 404 NOT_FOUND. See wallet-broadcast Stellar actions.

NEAR native source networks: native Litecoin, Dogecoin and XRP have chain-specific transaction building, wallet signing and receipt verification. Exact catalog paths, wallet formats, minimum reserves and recipient restrictions still apply. Litecoin and Dogecoin require canonical confirmations and decoded transaction evidence; XRP requires a validated successful payment. See wallet compatibility.

Stellar allowance lifetime and exact amount: Route skips a Stellar approval only when the allowance covers the burn through its expiry plus 12 ledgers. A saved burn whose allowance would lapse returns APPROVAL_STATE_CHANGED. New Stellar approvals authorize exactly the amount the burn debits, excluding the sub-6-decimal remainder, and never issue a reset: Stellar approve overwrites. Saved legacy resets and full-amount approvals remain valid. AMOUNT_TOO_SMALL rejects amounts below one 6-decimal unit.

Tracking and attention status: a reverted approval appears as REQUIRES_ATTENTION. Scheduled tracking no longer rechecks payments whose only hashed actions are finalized or renewed approvals. Unchanged observations no longer create a new preparation version, so a background check cannot cause VERSION_CONFLICT while you request the next action.

Stellar-source CCTP spending permission: Route checks native-USDC allowance before building the burn. Insufficient allowance produces a separately signed exact-amount approval with a bounded expiration ledger. Verified approval unlocks a fresh burn review on the same payment; existing sufficient allowance skips approval. See Stellar CCTP approval.

NEAR blockchain review renewal: an unfunded NEAR-source allocation can renew its expired review before any transaction action exists. Route preserves the provider allocation and terms, checks fresh provider status and finalized/optimistic deposit balances, and requires a new NEP-413 approval. Existing NEAR transaction actions require reconciliation; renewal never submits funds. See deposit review.

NEAR blockchain network reads: wallet and receipt checks use a reviewed public endpoint with an identity-verified fallback for temporary transport failures. Queries retain their requested finality. Transaction broadcasts are never automatically retried against another endpoint.

NEAR token deposit tracking: source verification recognizes the supported atomic token-account registration followed by the exact transfer. Sender, token, deposit address, amount, successful receipt effects and finality remain required.

2026-09-26#

TRON settlement reconciliation: NEAR payments preserve the provider-reported amount while verifying the exact solidified recipient credit. For supported Ethereum ERC-20 → TRON USDT payments, linked source, NEAR withdrawal and bridge-fee evidence can explain a larger payout. An exclusive payout claim prevents that receipt from completing another payment. Unexplained differences remain pending with TRON_SETTLEMENT_AMOUNT_MISMATCH.

TRON USDT gas estimates: comparisons use the reviewed transfer model with the live contract energy factor and a reserve. Preparation still simulates the actual transaction and enforces the approved fee limit.

Pricing temporarily pauses an unreachable upstream before retrying, while independent fallbacks continue. Retry guidance preserves the cause and waiting period; stale or missing prices never satisfy a USD limit. Saved comparisons open directly in the simulator, and newer selections take precedence over delayed responses. Overview shows payments needing attention with retry controls when details cannot be loaded. Billing, API keys, policies and activity use clearer summaries; dashboard API responses include server timing information. The USD valuation schema accepts CoinMarketCap as an optional configured source. Reviewed market IDs, exact token mappings and upstream price timestamps are required. Inactive listings and stale observations remain unavailable; existing USD limits still apply.

The dashboard now has a collapsible phone menu, clearer payment summaries and grouped provider cards. Connection summaries distinguish unchecked providers from passed or failed checks. A pending receipt verification is never displayed as completed delivery.

USD price observations now report structured failure reasons and retry guidance. Concurrent market reads are shared, and rate-limited sources back off while independent fallbacks remain available. Preparation/signing still refresh prices and enforce the existing USD limits; stale prices and assumed stablecoin parity are never accepted.

Robinhood receipt reads: tracking uses an independent read fallback when the public gateway is rate-limited, and avoids repeating successful finality reads. Canonical receipt and finality requirements remain unchanged.

Aptos gas estimates: unsigned transfers derive their gas limit from a live simulation with a buffer, then simulate the exact proposed limit. Rechecks preserve signed fee limits. An insufficient gas reserve returns an actionable wallet check.

Aptos receipt tracking: recipient-store lookup supplies the required metadata type when checking exact credits at the transaction’s ledger version.

Saved NEAR quote review: standalone EVM- or Aptos-source payments can explicitly accept a lower executable minimum on the same unfunded allocation. The accepted USD cost ceiling is enforced before signing and submission. Original terms remain in history; credits are reserved once and charged only on verified completion.

USD price coverage: reviewed APT, ADI and SUI USD markets provide independent fallbacks. A fresh narrow bid/ask midpoint may be used when the last trade is stale; responses identify the basis and preserve exchange timestamps. Missing-price messages identify the asset and network.

NEAR execution adds ADI and chain-specific NEAR, TRON, Sui and Aptos signing, fee checks and receipt verification. The API supplies each network's exact signable payload; consult wallet requirements. HyperCore destination comparisons request zero provider slippage while retaining the owner's minimum-receipt limit. Abstract remains excluded from execution while its provider address validation is unresolved.

NEAR network coverage: Robinhood (hood, chain ID 4663) supports native ETH and exact ERC-20 deposit preparation, wallet signing and finalized receipt checks. Transaction gas includes the Nitro data fee. Availability still depends on the exact quoted pair and wallet checks. Quote failures now include normalized rejection details for unsupported source assets, rejected addresses and net recipient slippage.

SwapKit tracking: an included source receipt awaiting finality reports source-confirmed; destination-pending starts after source finality. Completion still requires independently verified destination delivery.

Receipt tracking: when an EVM finality endpoint lags, NEAR tracking can verify the complete receipt through another reviewed read endpoint, or corroborate its exact canonical block against a current finalized checkpoint when receipt history is restricted. The required finality remains unchanged, conflicting blocks are rejected, and no transaction is resent.

Composed final minimum: captured provider quote reviews and subsequent final-leg wallet actions cannot reduce the original final recipient minimum.

Captured NEAR continuation review: mainnet 1.32.0-preview supports explicit acceptance of revised intermediate terms on the same unfunded allocation. Route preserves the original final recipient minimum, enforces the accepted total cost limit on later actions, and requires separate wallet consent. Remaining-route refreshes use the existing allocation’s guaranteed minimum when it is lower than a fresh dry quote. See continuation review.

Cancelled transfers: background tracking skips transfers with verified source cancellation, preserving their closed records and avoiding repeated provider checks.

Base submission reliability: hosted EVM submissions on Base use a separate broadcast endpoint from read queries. Each signed action still has one submission attempt. An unavailable response retains the saved hash for reconciliation; Route does not automatically retry through another endpoint.

2026-09-25#

Continuation after a verified refund or cancellation retains the prepared leg’s exact asset and slippage terms, rather than replacing them with the parent’s slippage ceiling.

Uncertain mainnet submissions now retain a safe diagnostic category in lastError.observation when available, such as an RPC fee rejection or transport timeout. These observations do not prove cancellation or authorize another send; keep tracking the saved hash and follow recovery guidance. Older records may have no category.

Remaining-route estimates can be refreshed for a saved NEAR EVM signature only when fresh provider and chain checks prove it is unsubmitted and unfunded. This preserves the original transaction and supports renewing expired wallet consent without restarting completed transfers.

NEAR deposits on Base, Optimism and Scroll now compare current data and operator fees against the existing reviewed reserve. Fee headroom is added once when preparing the transaction; later checks retain the signed fields and approved maximum, and still block fees above that maximum.

Composed NEAR transfers now retain each leg’s quoted slippage. An expired child quote can be renewed before provider allocation, preserving the same payment, wallets and recipient minimum; replay the original advance request to continue.

Preparation guidance: unprepared NEAR payments return the appropriate next action, including review after quote expiry. SwapKit preparation distinguishes a pending cost check from a provider rejection so the actual wallet fee can be verified; transaction signing still requires complete costs and passing policy checks. Simple SwapKit Bitcoin transfers now include a modeled mining fee in comparisons, replaced by the actual wallet transaction estimate at preparation. Composed-route refreshes distinguish unavailable USD cost evidence (COMPOSED_COST_UNRESOLVED) from exceeding the policy fee limit (COMPOSED_FEE_LIMIT), and reuse public prices only while they remain fresh.

Bitcoin delivery reconciliation: SwapKit payouts through NEAR can complete when the proven on-chain fee reserve differs from the quoted withdrawal fee. Route verifies the exact source-to-output allocation, actual fees, recipient and minimum receipt, then records an exclusive payout claim. Refresh the existing payment; no replacement transfer is required.

SwapKit preparation and tracking: corrected native network requests in the Cloudflare runtime so transaction builds and delivery status checks can reach the provider. Existing uncertain allocation attempts remain in review.

Quote discovery and allocation recovery: independent three-leg search alternatives now run concurrently, preserving exact per-leg amounts, shared quote deduplication and provider deadlines. SwapKit allocation views expose responseCaptured; unknown outcomes require operator review rather than a quote review with no saved terms. Failed build responses include bounded HTTP diagnostics when available, without enabling another allocation.

Browser-wallet gas limits: wallet submission and recovery now recognize a wallet-lowered gas limit within the original ceiling. Sender, chain, nonce, recipient, amount, calldata and legacy gas price remain exact. Route sign-only validation is unchanged.

Testnet wallet reuse: completed payments no longer leave an old approval blocking later transfers from the same wallet. Existing nonce reservations and unfinished-payment checks remain enforced.

Solana/Fogo and Bitcoin recovery: expired NEAR Solana/Fogo sources can renew against the same unfunded deposit after finalized history proves non-execution. Bitcoin sources can reconcile a finalized replacement that funds the exact original deposit or cancels it back to the source wallet. Recovery preserves original records, requires explicit consent for new signatures, and does not automatically send funds. See source recovery and Bitcoin replacement recovery.

Stellar source recovery: mainnet 1.30.0-preview adds NEAR Stellar classic source observations and verified renewal for expired signed or uncertain deposits. The same payment and provider allocation are retained; fresh intent and transaction signatures are required. Unused holds stay reserved, and old signatures remain in history. The API offers renew-source; the SDK adds renewSource. See source renewal.

Close a cancelled standalone signed transfer#

Standalone payments with saved source signatures on Ethereum, Base or Arbitrum can use the existing recovery/cancellation endpoints. A verified finalized nonce cancellation closes the payment and releases unused payment credits and rolling limits once, including after an uncertain submission response. Original signed records and nonce history remain immutable; a new transfer requires a fresh quote and authorization. Repeated submission of a closed action returns a cancellation error. No browser-wallet integration is required. See signed-source recovery.

Close a cancelled first transfer#

A finalized EVM cancellation can close the first source attempt and its unfunded composed parent on Ethereum, Base or Arbitrum. The existing recovery/cancellation endpoints support saved signatures and browser-wallet handoffs, release unused payment credits and rolling limits once, and retain all action and nonce history. Closed workflows return state: "cancelled" and nextAction: "cancelled"; obtain a fresh quote for any new payment. Pending or conflicting evidence retains the existing holds. See first-transfer recovery.

Resume after a verified intermediate cancellation#

A finalized EVM nonce cancellation can close the active second or third source-transfer attempt on Ethereum, Base or Arbitrum, including an action whose signature was already saved. Use the existing recovery and cancellation endpoints with the child payment and authorization IDs, then preview and accept a new attempt on the parent. Completed legs, original signed records, and parent reservations are retained. The cancellation fee is included in continuation estimates. A review deadline or missing receipt alone never authorizes replacement. See cancelled intermediate transfers.

Preserve payment identity during recovery#

Unsigned EVM protocol funding actions can renew review without changing transaction bytes. Composed payments add /refresh-route for remaining estimates before source authorization. Supported finalized intermediate NEAR/SwapKit refunds can be previewed and explicitly continued as a new attempt on the same leg; all attempts stay attached to the original parent payment. Signed or uncertain source actions remain in reconciliation. See recovery and continuation.

Review intermediate continuation#

Composed payments now expose intermediate receipt amounts, exact assets, wallets and onward-transfer state. POST /payments/{id}/advance-preview obtains a fresh continuation estimate without allocating another child or deposit. Pass its review to /advance to reject changed identity or worse quote bounds. The dashboard previews before preparing; the SDK adds previewAdvance. Existing signed or allocated attempts retain their identity and recovery requirements. See interrupted transfers.

Bitcoin and Solana submission observations#

Saved Bitcoin and Solana/Fogo source actions now expose sourceSubmissionObservation when source receipts remain unverified. Bitcoin observations identify reported input conflicts; Solana combines signature-history lookup with finalized block height and blockhash validity. Conflicts, expiry and reported errors require review without replacing transfers or releasing holds. Manual and scheduled NEAR tracking use the same observation logic; SwapKit Bitcoin tracking also includes it. See source recovery.

Stellar submission recovery evidence#

Missing Stellar protocol receipts now include a hash-bound submissionObservation separating network expiry, sequence conflicts and unavailable evidence. The next-action and recovery APIs require review for expired or conflicting actions while retaining reservations; eligible unsubmitted customer mints retain their existing renewal flow. Verified delivery supersedes earlier missing-receipt observations. Mainnet 1.24.1-preview and testnet 0.10.1-preview. See missing Stellar receipts.

Customer Stellar mint renewal#

Mainnet 1.24.0-preview and testnet 0.10.0-preview add POST /payments/{id}/transaction/renew for expired customer-signed CCTP Stellar mints with no recorded submission attempt. Route proves ledger expiry and an unused sequence, then rebuilds the same mint within the existing fee ceiling for a fresh signature. Original actions remain in history; identical requests return the same replacement. The next-action API offers renew-mint and the SDK exposes renewMint. Submitted or ambiguous transactions remain in reconciliation. See mint recovery.

Composed payment recovery#

Recovery reports distinguish completion of an intermediate transfer from completion of the entire payment. A later-leg refund identifies the intermediate network and requires review; it does not mark the original payment refunded. Continuation guidance requires verified, finalized preceding receipts. Existing payment identifiers, pricing and signing requirements are unchanged. See recovery guidance.

2026-09-23#

Sign-in delivery resilience#

Dashboard sign-in requests queue delivery before returning. Temporary email failures retry the same browser-bound link within its original expiry window. Requesting a new link invalidates the previous one. Used and expired links are not retried. Customer API keys and payment signing are unchanged.

Delivery retries and service health#

Webhook metadata identifies receivers awaiting activation. Unactivated receivers retain their queued events and retry allowance; approved receivers continue independently. HTTP 429/503 retries respect a bounded Retry-After. The Health page shows background processing observations and project payments needing review. Observation delays do not mean a transfer failed and never authorize a duplicate payment.

Developer documentation cleanup#

Guides now focus on supported paths, wallet requirements, execution and recovery. Existing documentation links continue to resolve. API contracts, execution coverage and pricing are unchanged.

Provider availability and verification scope#

Corrected the Execute guide, onboarding, provider guidance and OpenAPI description: Garden is paused for new quotes and execution, including Garden-backed SwapKit routes. Paused providers are hidden from active dashboard setup and health checks; saved records and strict policy rules remain intact. API contracts, execution coverage and credit rates are unchanged.

Dashboard inactivity sign-out#

Dashboard sessions now expire after 30 minutes without activity, with a warning two minutes before sign-out and a Stay signed in action. Background reads do not renew sessions. Expiry is enforced by the server across dashboard services, with a seven-day absolute maximum. API keys and payments already in progress are unaffected. No customer API integration changes are required.

Asset-specific provider rules#

Mainnet contract 1.23.0-preview adds optional providerRules to the assigned routing policy. Require a provider for exact source/destination catalog assets, with Fast/Standard selection for direct Circle CCTP. The dashboard offers a visual From → provider → To editor. Rules apply before recommendation and preparation, to Auto-route legs, and during transaction checks. Conflicting overlaps are rejected; unavailable required routes do not fall back. Omitting rules on update retains them; [] removes them. See provider rules.

SwapKit execution and quote review#

Mainnet contract 1.22.0-preview adds simple EVM and native Bitcoin SwapKit deposit execution on supported paths, durable provider allocation state, and GET/POST /payments/{id}/quote-review. Applications can explicitly accept revised minimum receipt terms for the same captured channel before preparation; acceptance does not sign or submit a transaction. Original quote evidence remains immutable.

Auto-route supports two or three separately authorized legs when every leg and intermediate wallet is executable. Remaining legs are re-quoted after verified receipt, with one logical payment completion charge. Garden is paused and excluded from new comparisons and execution, including Garden-backed SwapKit paths.

See supported execution paths and changed quote recovery.

Managed Fast starter#

The published testnet starter supports managed CCTP Fast delivery and resuming the same payment after a lost submission response. No API contract or pricing change.

Stellar testnet delivery through Channels#

• Clarified the existing managed testnet default: OpenZeppelin Stellar Channels builds and submits the destination mint and sponsors its XLM fee. Applications sign source actions; customer-funded minting remains an explicit alternative.
• The previously pending 1 test USDC mint was recovered through hosted Channels and independently verified on Stellar. The expired customer signature remains unchanged. This was operator recovery of a local test record, not a new public recovery endpoint.
• Completed testnet payments no longer expose an old signed action as the next step. Historical actions remain readable; signing and submission flags are disabled and a new execution attempt is rejected.

Required client changes: none. For new testnet payments, use destinationExecution: "managed" and omit destinationFeePayer. Existing customer-mode payments retain their original intent; ask for reconciliation if a signed mint expires.

Live wallet recovery fixes#

• Missing-hash recovery now searches recent blocks first. Recovering a recent transaction no longer starts with an archive-state request halfway through chain history; unavailable evidence still preserves the payment and its reservations.

• A finalized testnet cancellation allows the wallet to prepare a new payment at its next nonce. The consumed nonce remains reserved permanently, and unfinished or unverified actions still block conflicting preparation.

• New customer-signed testnet Stellar mints include a resource-fee margin in the reviewed envelope. Submission still requires the current estimate to fit that signed budget. Existing signed envelopes are unchanged; an expired signed mint requires recovery and cannot be silently replaced.

Required client changes: none. Keep the same payment and authorization during recovery, and supply the original wallet hash if available. The API contracts, credit prices and cancellation proof requirements are unchanged.

Interrupted wallet submission recovery#

• Added /transaction/broadcast-recover and /transaction/broadcast-cancel on mainnet and testnet, with SDK methods. Recovery can locate a canonical original transaction by sender and nonce when its hash was lost, then register it for normal tracking.
• A verified finalized self-transfer cancellation can close an unfunded standalone payment and release unused payment-credit and rolling API-limit holds exactly once. Cancelled actions expose walletBroadcast.state: "cancelled", no send parameters, and a terminal next action.
• Missing receipts, wallet rejection and expiry do not imply cancellation. Funded/composed payments and destination mint cancellation require separate review. Quote charges, network fees and pricing remain unchanged.

Required client changes: existing submission methods continue to work. Update SDK/types to handle the new recovery response and cancelled transaction state, then follow wallet recovery. These endpoints do not sign or broadcast cancellation transactions.

Explicit EVM wallet submission#

• Added POST /payments/{id}/transaction/broadcast and /transaction/broadcast-confirm on mainnet and testnet. Apps may hand an unsigned EVM action to their own wallet, then report its hash for independent verification. Route never broadcasts an action after this handoff.
• Added walletBroadcastAvailable, walletBroadcast and the normalized confirm-wallet-broadcast next action. Exact legacy transactions and EOA accounts are supported; wallet fee/nonce rewriting, EIP-1559 conversion and smart accounts remain outside this flow.
• Added SDK methods and a declared submissionMode: "wallet" compatibility check. Recovery retains the same action, nonce and credit holds across missing hashes, timeouts and review expiry.

Required client changes: none for existing sign-only integrations. To adopt wallet submission, update the SDK/types and implement the explicit handoff, durable hash storage and confirmation sequence in Execute. No automatic replacement, handoff cancellation or change to credit rates is introduced.

2026-09-22#

Task-based developer documentation#

• The main navigation follows six tasks: Get started, Configure access, Check compatibility, Compare routes, Execute, and Track and recover. Advanced features and exact provider/environment contracts remain separate references.
• Access restrictions, provider connections and wallet approval guidance are consolidated. NEAR execution is explicitly named; delivery/finality guidance lives in tracking. Historical verification is an optional appendix.
• The full mainnet and testnet endpoint index is generated from OpenAPI. Styled pages include local outlines, guide filtering, code copying and Markdown downloads.
• Existing Markdown URLs and section bookmarks lead to the current guides. Add ?raw=1 to a Markdown URL to read its source; consolidated legacy sources link to their canonical guide. Examples and the starter ZIP remain downloadable.

Required client changes: none for the payment API or SDK. Documentation readers requiring Markdown should use the raw source links. The API contracts, payment execution, billing and database schema are unchanged.

Verified Bitcoin payout allocation#

• Added bounded automatic reconciliation for NEAR Ethereum ERC-20 → native Bitcoin fee-reserve returns. Route verifies the exact source, intent, withdrawal, bridge transfer, successful connector verification and canonical Bitcoin output. Finality and the signed minimum remain required.
• Every new native BTC delivery completion now requires an immutable, exclusive payout claim committed with the tracking update. Exact-match deliveries claim a transaction/recipient net credit; verified Omni withdrawals additionally identify an output. Historical overlap or conflicting claims stay pending.
• Added optional tracking.bitcoinPayout evidence and tracking.received for the actual BTC receipt. The provider-reported amount remains unchanged. Settlement evidence retains the actual and reported amounts, without changing source USD volume or credit rates.

Required client changes: none for existing tracking flows. Regenerate types to consume the new optional evidence. Keep the same payment and use normal refresh; do not reinterpret a larger output as success locally. Refund adjustments, other source families and deep post-completion reorganizations are outside this new proof path. No automatic signature, replacement or new transfer is introduced.

Saved recovery evidence#

• Added GET /payments/{id}/recovery on mainnet and testnet with payments:read. It classifies the saved outcome, identifies who should act, and returns allowlisted transaction, settlement and reservation evidence. It does not refresh providers or chains, sign, submit, mint, replace payments or release reservations.
• Added getRecovery() to the downloadable client and typed SDK. The SDK checks the report version, payment/network identities, nested evidence and safe operation references, and rejects unexpected signing payloads. Reads never execute the suggested operation.
• Added Recovery details to dashboard payments, with Download support details for a JSON report that excludes credentials, signatures, signing payloads and raw provider responses. Wallet addresses and transaction hashes remain visible for investigation.
• Published complete recovery schemas and runtime-generated examples for both networks. Missing transaction receipts have observed: false with nullable flags; they do not contradict separate saved verified tracking. Mainnet reservation groups show bounded saved reads; testnet groups are explicitly unobserved.
• Explained the known Bitcoin payout discrepancy through exact bridge evidence: a lower actual network fee returned unused fee reserve to the recipient. Automatic completion still requires persisted allocation proof and unique output attribution; an output above the minimum is insufficient.

Required client changes: optional adoption of getRecovery() for support and operator review. Replace the downloadable SDK and refresh generated schemas to use the new response type. INVALID_RECOVERY_REPORT, unsupported states and uncertain submissions must pause automatic replacement. Read the recovery guide before adding a recovery flow.

Existing payments: keep their saved identities, signatures and reservations. This release adds read-only evidence and reporting. It does not release funds or reservations, change submission rules, or complete the unresolved Bitcoin record automatically. POST /refresh remains a separate explicit operation and can perform previously authorized managed destination minting.

Normalized actions and wallet compatibility#

• Added GET /payments/{id}/next-action with the same PaymentNextAction envelope on both networks. It separates app, wallet, operator and terminal steps; exposes payment/preparation versions and operation input; and preserves underlying checks and tracking evidence. It is observational and does not execute the returned operation.
• Added the downloadable JavaScript SDK and TypeScript declarations. getNextAction() validates the normalized response; mutations remain explicit and retain their existing endpoint contracts. The SDK does not auto-sign, broadcast, retry or store a durable workflow.
• Added a pure wallet compatibility helper. Declared account type and signing capabilities produce compatible, unsupported or unknown; this is not a live wallet capability probe.
• Testnet transaction responses now include authorizationPrepared. signingEnabled requires a persisted authorization, so callers must create/recover that authorization before asking the wallet to sign.
• Bitcoin tracking now reports canonical settlement amount mismatches explicitly in settlementDiscrepancies[]. Exact settlement checks remain enforced. The recorded 9,784-versus-10,908-satoshi discrepancy still requires reconciliation; it has not been marked completed by this change.

Required client changes: existing endpoints remain available. New integrations should use getNextAction() for the next step and retain flow-specific handling for payload review and detailed mutation results. Testnet integrations that signed an action before saving its transaction authorization must first call POST /transaction. Generated clients should refresh both schemas. Treat unknown actions or schema versions as a pause, never as permission to submit.

Existing payments: keep all payment, preparation and authorization IDs, original request keys and saved signatures. This release adds guidance and more precise diagnostics; it does not make a replacement payment safe, remove expiry checks, or expand Garden/SwapKit execution coverage.

Integration flow and recovery#

• Fixed the downloadable client's listPayments() query-string validation failure. Resource IDs cannot inject endpoint paths. Error responses preserve correlation and retry metadata without automatic mutation retries.
• Renamed draft creation to createDraft(), quoteAndCreateDraft() and quoteAndCreateExecutionDraft(). Existing prepare(), quoteAndPrepare() and quoteAndPrepareExecution() aliases remain compatible. These helpers save drafts; they do not allocate provider deposits.
• Added the complete CCTP testnet payment starter, with persistent operation state, reference sign-only test-wallet review, bounded polling and restart recovery. Added tests for every published client method, lost-response recovery and the real local customer API handler with simulated chain evidence.
• Added the canonical action and authorization tables, recovery playbook, wallet/path compatibility matrix and unattended-payment recipe.
• Strengthened OpenAPI protocol readiness, assessment, transaction, receipt and nextAction types. Added runtime-generated, schema-validated response fragments, including approval continuation, signed-before-broadcast, uncertain submission and delivered-before-finality.

Required client changes: replace the old example client to fix payment-list queries. Renaming calls to createDraft() is recommended, not mandatory. Preserve an explicit fallback for unknown future states; pause signing/submission instead of guessing. Generated clients should refresh their schema for stronger types. Later approval metadata remains optional for older immutable assessments.

Existing payments: unaffected. This release changes documentation, downloadable examples and schema descriptions; it does not alter stored payment records, provider contracts, expiry windows or execution behavior. Use original payment IDs and authorization state for recovery.

Bitcoin and Stellar evidence#

Recorded the completed Bitcoin → Stellar native-USDC leg, exact source/destination receipts, Bitcoin fee and six-confirmation finality. Documented the separate Ethereum → Bitcoin payout discrepancy: provider-reported amount differs from the canonical recipient output, so the released tracker retains VERIFICATION_PENDING pending reconciliation.

Clarified that the funded run used two individually signed local-harness transfers, not the hosted composed-payment or Auto-route API. Required client changes: none; show recipient delivery separately from verified final completion. Existing tracking records were not overridden. See release evidence.