Skip to main content

Transactions waiting for funding

Transactions stop going out because the wallet that pays gas is short: find the wallet, fund it inside the funding window, and recover failed requests.

Work shows “Waiting for funds” because the wallet that pays its gas is short. Fund the wallet the funding notice names before the funding window closes, 1,800 seconds unless the network sets another value, and the request continues.

Every EVM write you submit through the Console or the API becomes a transaction request, which the platform signs and sends to the chain. When the wallet that pays gas for it is short, the platform pauses the transaction request instead of failing it. It opens a funding notice that names the wallet and the amount, and waits for the wallet to be funded. Nothing from that request is mined while it waits.

The wait has a limit, the funding window, set per network. When the wallet is funded inside the window, the request continues on its own once the custody provider's balance view and the wallet's other open writes allow it, as Check 4 explains. When the window closes first, the platform requeues the request, and it pauses again with a new window, up to its retry budget of 3 retries by default. The request fails when the window closes on its last retry. By default the API answers a write before the request runs, so the failure shows on the request's status and in Activity, not on the original API call.

A caller can decline the pause with Prefer: dalp-no-funding-pause, and the platform also declines it on a network it treats as charging no gas. Whether the chain charges gas explains that setting. A declined pause fails the request at once. When the platform can size the shortfall, that failure carries the funding error described below.

Symptoms

  • The Console's Submissions tray shows the request as “Waiting for funds”, with the line “Held until the wallet it pays from has enough funds. It continues on its own once the funds arrive.”
  • The Transaction funding page shows a notice such as Relayer wallet needs 0.25 ETH, followed by Operations wait until it is funded. Raised <when>., after It holds <held>. when the balance is known. When the Console cannot show the amount, the notice reads <wallet> needs gas.
  • The runner logs, category ddwf.workflow.with-funding-pause, hold Funding pause entered, waiting on the funded subject. The line carries the wallet as subject_address, the balance to fund the wallet up to as recommended_total_wei, and the time the window closes as deadline_ms.
  • After the window closes, the same category logs Funding pause window elapsed, failing terminal. The request is requeued unless that was its last retry.
  • GET /api/v2/transaction-requests/<transactionId> returns activeRequirement while the request waits, with the wallet address, the shortfall and the recommendedTotal. Once the request has failed for funding, it returns contractError with id DALP-9087, and args carries the wallet address, its shortfall and the recommendedTotal.
  • Token, add-on, restriction and portfolio write routes answer 400 with code TRANSACTION_QUEUE_FUNDING_REQUIRED, error DALP-14062, when the request failed for funding. A caller sees this when it waits for the outcome with Prefer: wait=<seconds> and the request fails for funding inside that wait, for example because the pause was declined. data.refusal is FundingRequired, and data.transactionId names the transaction request when the platform recorded one.
  • One of these alerts fires from the bundled observability stack:
Alert
It fires when
LowOperatorWalletBalance
An operator wallet stays below the low-balance mark for 15 minutes. The mark is 0.1 of the native currency, the same one the Console payer status uses. It does not fire on networks reported as charging no gas.
FundingPauseExpirySustained
Three or more funding notices for the same network and kind of wallet expire unfunded within 30 minutes, and that lasts 15 minutes.
FundingPauseNeverResumed
A funding notice is still open past its own deadline while a paused request still waits on it, for 15 minutes.

Checks

Access: “Transaction funding” opens for the system administrator, System Manager and Gas Manager roles. “Platform networks” opens for platform administrators.

  1. Tell a paused request from a failed one. “Waiting for funds” in the Submissions tray, an open notice on Transaction funding, or activeRequirement on the request's status means the request is still inside its window and needs only the funds. A DALP-9087 contractError on the status, or a DALP-14062 answer to a Prefer: wait call, means the request has failed and must be sent again after funding. Between retries the request can pause again with a new notice.

  2. Find the wallet and the amount. When your account has more than one network, the account menu at the top right shows a Network submenu. Select the network the notice is for. Then open “Organisation settings”, “Infrastructure”, “Transaction funding”. Each open notice names the wallet and the amount. From the API, read activeRequirement or contractError on GET /api/v2/transaction-requests/<transactionId>.

  3. Read the window. Open “Platform admin”, “Platform networks”, then “Edit network” on the network, and open “Advanced settings”. The “Gas and funding” group shows “Funding pause window (seconds)” with the value in force. The built-in default is 1,800 seconds. ADI Chain mainnet and testnet, Sepolia and Optimism Sepolia ship with 86,400 seconds. Gas settings lists every key and its range.

  4. If you funded the wallet and the request still waits, search the runner logs in the same category for these lines:

    • Custody provider balance view has not caught up with the funding, not filing. The custody provider's own balance view does not show the deposit. The platform checks again after the network's funding settle delay, 120 seconds by default and never less than 5 seconds, until the provider sees it or the window closes.
    • Sender funds are held by its other open writes, waiting for them to settle. The wallet holds enough, but earlier requests from the same wallet have not settled. The platform checks again with a growing delay, from 5 seconds up to 60 seconds, inside the same window.
    • Funding ask cannot be sized, declining to pause. The platform could not work out the amount, so it did not pause, or it closed a pause already open, and the request failed with its original error.

  5. If NativeBalanceFetchErrors fires for the same network, the platform failed to read wallet balances on that chain. The runner logs Native balance fetch failed in category didx.native-balance-collector with the reason. When the reason is an RPC failure, see RPC upstreams failing over.

Actions

  • The request is paused. Fund the wallet the notice names before the window closes. Select the button on the notice, for example Fund 0.25 ETH, and send the network's native currency to the address the sheet shows. Before you send, compare that address with the wallet address in activeRequirement on the request's status, and with your own record of the platform's wallets. The sheet changes from “Watching for the deposit…” to “Deposit received.” when the wallet's balance rises, or, for a wallet the page does not list, when the notice closes. Do not send the write again. The platform resumes the request when the funds land, and logs a line in the same category that ends slot cleared, for example Funding pause re-invoke succeeded after funding, slot cleared.
  • The request failed for funding. First confirm that it has failed: its status carries the DALP-9087 contractError and no activeRequirement, and Transaction funding has no open notice for it. Then fund the wallet and send the write again under a new Idempotency-Key. A new key makes a new write, so sending it while the original can still continue runs the operation twice. Reusing the failed request's key answers 400 TRANSACTION_QUEUE_DUPLICATE_SETTLED, error DALP-14066.
  • The request failed because other requests held the funds. The failure reads kept the funds this write needs. Submit it again once those writes settle. Wait for those requests to settle, then send the write again.
  • Notices expire unfunded repeatedly. When FundingPauseExpirySustained fires, first check that the notice reaches someone who can fund the wallet. Then raise “Funding pause window (seconds)” on the network if your funding process needs longer. The accepted range is 60 to 604,800 seconds.
  • Wallets run low before any notice opens. When LowOperatorWalletBalance fires, top up the wallet the alert names. The alert has no threshold setting of its own: it reads the same 0.1 mark as the Console.
  • The node kept rejecting a funded wallet. The failure reads the node kept rejecting it for gas while wallet <address> already covered <amount>. The platform retries the request on its own up to its retry budget. If it still fails, send the write again.

Verify recovery

The request leaves “Waiting for funds” in the Submissions tray, its notice on Transaction funding closes, and LowOperatorWalletBalance clears for the wallet.

Escalate

Escalate to your DALP support contact as a platform defect when FundingPauseNeverResumed fires, when a funded wallet's request still shows “Waiting for funds” and none of the lines in Check 4 explain it, or when the request fails again with the node-kept-rejecting message. Include:

  • the network and chain ID, and the wallet address.
  • the transaction request ID, from data.transactionId or the Activity entry.
  • the amount the notice asked for and the hash of the funding transfer.
  • the ddwf.workflow.with-funding-pause log lines for the request, matched on op_name, with the deadline_ms from the entered and elapsed lines.

Was this page helpful?