autoRetry to an EVM or Solana /transfer request to let Para manage retries within your fee ceiling and deadline. The wallet pays transaction fees. EVM attempts keep the same nonce and payment payload; Solana attempts follow blockhash expiration rules to prevent duplicate payments.
Use one pending payment per wallet and chain. Para rejects conflicting REST operations with 409 WALLET_TRANSACTION_UNRESOLVED; it does not queue another payment. Coordinate any transactions you send outside Para as well.
An earlier ordinary Solana broadcast can stop blocking new admission once finalized evidence proves its saved recent blockhash can no longer execute, or its saved durable nonce has advanced or the nonce account has closed. Its past payment outcome may still be unknown.
For older records without saved lifetime evidence, contact Para support with the transaction ID. An operator can release the admission hold after reviewing external non-execution evidence; an absent RPC result or old timestamp is insufficient. Releasing that hold does not establish the old payment’s outcome or authorize resending it.
Submit an EVM payment
Get a secret API key from the Developer Portal and use an API-created, unclaimed EVM wallet. To avoid funding pauses, keep enough native tokens for the payment plus the fullmaxExecutionFeeWei ceiling and any separate chain fees. ERC-20 payments still require native tokens for fees. This example sends a native-token payment on Sepolia through the beta API.
auto-retry.mjs
tokenAddress and express value in the token’s smallest unit. The amount must be a positive integer string. Omit kind or use NATIVE for native tokens and ERC20 for token transfers. broadcast and addressScreening must be omitted or true.
You can supply the usual EVM nonce, gas limit, and fee overrides. A supplied nonce must match the next pending account nonce. Para preserves supplied initial fees and fills omitted fees from current RPC estimates.
Type
2 fee caps include base-fee headroom. Legacy gasPrice uses the greater of the RPC price and current base fee plus tip; legacy transactions pay that price for each unit of gas used. Para estimates an omitted gas limit with a 20% buffer. Initial fees must fit the ceiling. Use integer strings for gas limits and fee amounts; fee amounts are in wei per gas. Automatic retry supports legacy type 0 and EIP-1559 type 2.
On chains with a base fee, a zero or missing RPC tip requires a valid eth_feeHistory response to select automatic fees. Para uses recent paid priority fees when available; all-zero history retains a zero tip. Unavailable or invalid history produces RPC_UNAVAILABLE. Complete explicit initial fees bypass this recommendation.
Omitting autoRetry retains the existing transfer behavior, including sponsorship when applicable. Explicit autoRetry requests use wallet-paid gas and do not use gas sponsorship.
Submit a Solana payment
Use an API-created, unclaimed Solana wallet. Send the same headers as the EVM example, with this body:solana-auto-retry.json
to with the recipient’s Solana address and expiresAt with a timestamp in the next 24 hours. value is a positive integer string in lamports for SOL. For legacy SPL tokens, add the mint as tokenAddress and express value in the token’s smallest unit. Omit kind or use NATIVE for SOL and SPL for tokens.
Use SOLANA_DEVNET in beta. Production defaults to SOLANA; production also accepts SOLANA_DEVNET. Para selects compute and priority fees automatically. Solana requests do not accept EVM nonce or gas fields, caller-built instructions, or durable nonce transactions.
maxExecutionFeeLamports bounds the base plus priority transaction fee for each attempt. It excludes the transfer amount and rent required to create a recipient’s associated token account. Keep enough SOL in the sending wallet for those costs as well.
Para first rebroadcasts the identical signed transaction while its blockhash is valid. It can prepare up to three new attempts with a fresh blockhash and adjusted priority fees only after the previous attempt is proven expired without landing. A timer, missing status, or RPC failure alone is not enough. If Para cannot determine the signing or chain outcome, automatic retries stop and the payment can remain unresolved. See Solana’s retry guidance.
If an attempt’s policy decision expires while its blockhash is still valid, Para evaluates current permissions again before resending the saved bytes. This does not create another signature or charge the payment amount again. The original autoRetry.expiresAt still applies; a denial or loss of signing authority stops retries.
Track the operation
202 Accepted means Para saved the operation for processing. It does not mean signing or broadcast succeeded. The response includes transactionId, status, and autoRetry, plus x-transaction-id and Location headers. It does not return signed transaction bytes. hash may be null until the initial transaction is signed.
Poll GET /v1/wallets/{walletId}/transactions/{transactionId} for the current record and retry details. Transaction list responses show the payment record; use the single-record lookup for autoRetry metadata.
Attempt stages are
prepared, signing, rejected, signed, submission_unknown, and submitted. rejected records proof that signing did not start or the signing request was not accepted. An unknown submission may already be on-chain. Para first reconciles persisted attempts and may resend the exact saved bytes before preparing a higher-fee attempt.
EVM replacements are considered after at least 60 seconds from the previous attempt’s broadcast. Fees increase by at least 12.5%, rounded up, using fresh network estimates when higher. For type 2, both the priority fee and maximum fee increase. Three replacements is an upper limit, not a guarantee of confirmation or a fixed completion time.
If an EVM wallet lacks native tokens for the next attempt, or the current base fee plus required tip exceeds the ceiling, Para keeps autoRetry.state as active and checks again automatically. Adding funds or lower network fees can let the original payment continue before its deadline. Waiting does not create another replacement or consume bumpCount; the nonce, payment, ceiling, and deadline remain unchanged. The wallet and chain stay blocked during this wait; the manual cancellation flow is available only after retries become stopped.
The record’s hash remains the initial transaction hash or Solana signature. Once Para verifies a finalized winner, monitoring.winningHash identifies it. A verified successful Para attempt confirms the same payment; an execution revert sets reverted. On EVM, an unrelated same-nonce transaction is handled as a replacement or cancellation of the payment. See Transaction history for finality and webhook behavior.
If admission returns 409 because the wallet is temporarily busy, retry the identical request with the same
Idempotency-Key. Keep the saved body, including its original deadline. A conflict for an already unresolved payment
requires tracking that payment before sending another.
Replaying the same request and Idempotency-Key returns the existing operation with 202, even after its authorization expires. It never extends the deadline, increases the ceiling, or restarts stopped retries. Reusing the key for a different wallet, body, or operation returns 409 IDEMPOTENCY_CONFLICT.
When retries stop
Para stops new attempts when the deadline or attempt limit is reached, or signing authority is no longer valid. EVM retries also stop when the minimum replacement increase itself cannot fit the ceiling. Solana retries stop when funds are insufficient or the next attempt exceeds its fee ceiling. Each signing attempt checks current wallet ownership, the enrolling secret key, and current permissions. A secret-key rotation or wallet claim invalidates future signing authority. A policy denial, approval requirement, or incompatible spend-window change also stops retries. Compatible replacements count the original payment amount once against spend limits.autoRetry.state: "stopped" does not establish payment failure. If any signing or submission may have happened, Para retains the unresolved operation and continues chain monitoring, including finalized nonce checks for EVM when signing produced no saved hash. That wallet and chain remain blocked while retry processing retains an unresolved operation. An uncertain signing result is never signed again automatically. A stop before any signing dispatch, or a definitively rejected initial signing attempt, can safely mark the transaction failed and release the wallet. Rejecting a later fee replacement does not release the original pending payment.
For EVM, if the finalized account nonce proves that none of the saved attempts can execute, Para releases the wallet hold
and sets autoRetry.state: "resolved" with reason: "RECOVERY_NONCE_CONSUMED". Without an identified winner,
monitoring.reason remains nonce_consumed; this does not prove payment success and emits no success webhook.
Continue checking the payment record to establish what happened.
For Solana, Para can resolve a stopped payment as failed with failureCode: "TRANSACTION_EXPIRED" once every dispatched attempt is proven expired and absent from the finalized chain. If signing returned no saved hash, Para checks finalized transaction messages against the saved payment and recovers any matching signature and outcome.
These checks can span several monitoring passes and continue from saved progress after a restart. The wallet hold remains until Para verifies an outcome or completes the absence checks. Missing or incomplete chain history keeps the payment unresolved.
This version has no manual resume or ceiling-increase endpoint. It never retries a reverted payment with a fresh nonce. Expiry does not cancel a transaction that has already been signed or submitted. Use transaction lookup to observe fee attempts; existing terminal transaction webhooks report the verified payment outcome.
Cancel a stopped payment
This cancellation flow is EVM-only. For a stopped, unresolved EVM operation, you can submit a manual cancellation throughPOST /v1/wallets/{walletId}/sign-transaction with broadcast: true. Read the original payment first and use its chainId and autoRetry.nonce. Use a current secret key and a new Idempotency-Key for the cancellation request.
Omit access and authorization lists, or leave them empty. Active operations and all other transaction payloads remain blocked. Current wallet ownership, credentials, and signing policies must allow the cancellation. You authorize its fees in this new request; the original retry ceiling and expiry remain unchanged.
The cancellation receives its own transaction ID, and Para records its hash as a candidate for the original payment before broadcasting. The wallet remains blocked until a winner is finalized. The original payment can still win the race, and an underpriced cancellation may remain pending. Poll both records; signing or broadcasting a cancellation does not prove that the payment was cancelled. A missing mempool entry never releases the hold.
Automatic retry supports native and ERC-20
/transfer payments on supported EVM chains and SOL or legacy SPL transfers on Solana. It does not cover arbitrary sign-transaction calls, Cosmos, Stellar, Sui, sponsored transactions, or workflows that require a new policy approval for signing. Solana retries require compatible permissions v2 policies or disabled policies; legacy EVM-only policies cannot authorize them.