Transaction Timeout Configuration

Transaction timeout controls how long Fireblocks waits for a transaction to be approved, signed, and broadcast before it expires and fails. This value is configurable, and you can set it up to be as short or long as you need. The default is 2 hours (8 hours for cold workspaces). Workspace admins can set any value from 5 minutes up to 24 hours, and you can override it for a single transaction via the API. If a transaction is still waiting for a signature when the window ends, it fails with sub-status TIMEOUT and has to be recreated. The time window starts when the transaction is created, not when it is approved.

How it works

Fireblocks monitors every transaction from creation through all pre-broadcast statuses:

• SUBMITTED: received by Fireblocks, not yet processed

• PENDING_AML_SCREENING: waiting on AML/screening results

• PENDING_ENRICHMENT: waiting on transaction enrichment

• PENDING_AUTHORIZATION: waiting for approval under your Transaction Authorization Policy

• QUEUED: waiting its turn behind other transactions on the same wallet

• PENDING_SIGNATURE: waiting to be signed, either by a person in the Console or mobile app, or automatically by an API Co-Signer

If the transaction is not broadcast to the blockchain within the configured timeout window, Fireblocks transitions it to status FAILED with sub-status TIMEOUT. There may be a processing delay of up to 1 minute between when the timeout window elapses and when the status change is applied. The expiredAt field in the createTransaction API response reflects the exact expiry time.

Default behavior

If no custom timeout is configured, the workspace default is 2 hours (8 hours for cold workspaces). No action is required to maintain current behavior.

The following policy configurations extend the default expiry to 24 hours:

• A transaction policy with two-tier approval configured
• A transaction policy with a designated signer (API user or human) configured

In all cases, the expiry window begins when the transaction is created. If the required approval or signature is not completed within the window, the transaction transitions to FAILED with the substatus TIMEOUT.

Timeout layers

Fireblocks uses a three-layer timeout model. The most specific configuration always takes priority (e.g., Transaction-level > API-level > Workspace-level).

Signing edge cases

The timeout layer applied depends on who signs the transaction, not who initiates it.

Configuration limits

• Console: Enter values in minutes or hours using whole numbers only. Invalid ranges or non-integer values are rejected with an inline validation error.
• API: Pass the value in seconds. Invalid values result in a failed transaction.

Configure transaction timeouts

Workspace and API-level timeouts

1. In the Fireblocks Console, go to Settings > General > Transaction timeout.
   
2. Set your workspace-level default timeout. This applies to all transactions unless overridden.
3. Optionally, set an API-level timeout for flows where transactions are signed automatically by an API Co-signer.
4. Select Save configuration. All updates are subject to your workspace's quorum approval policy. The existing timeout configuration remains active until the change is approved.

Transaction-level timeout

To set a timeout on an individual transaction, pass the expiresAfterSeconds parameter (in seconds) in the configurations object in the createTransaction API call. This value overrides both workspace and API-level configurations for that transaction.

For the full parameter reference, see the createTransaction endpoint in the Fireblocks API documentation.

Audit log

All timeout configuration changes are automatically recorded in the Audit Log. Each entry includes the user who made the change, the previous and new timeout values, and a timestamp. To view the Audit Log, go to Settings > Audit Log in the Fireblocks Console.

Best practices

• Use shorter timeouts for automated flows to improve security and reduce mempool congestion risk during high-volume bursts.
• Match the API-level timeout to your signing SLA. If your automation signs within minutes, a 2-hour workspace default is longer than necessary.
• Monitor for TIMEOUT failures. Subscribe to webhooks or poll the getTransactionById endpoint to detect transactions that fail with sub-status TIMEOUT, and build retry logic accordingly. For webhook event structure, see the Fireblocks webhook reference.

Frequently asked questions

Will this change affect my existing transactions?

No. The default 2-hour workspace timeout is preserved. Existing automations that rely on the current behavior will continue to work unless you change the configuration.

Does the timeout start when the transaction is created or when it is approved?

At creation. Approval time and signing time both consume the same window.

Is the expiredAt field available for all transactions?

Yes. The expiredAt field is included in the createTransaction API response and reflects the calculated expiry time based on whichever timeout layer applies.

Can I set different timeouts for different asset types or vaults?

Not directly. The three layers (workspace, API, and transaction) are the available granularity. For per-transaction customization, use the transactionTimeout parameter in the createTransaction API call.

Can I extend the time period for which a transaction waits for a signature?

Yes. Raise the workspace-level timeout in the Console (up to 24 hours) or pass expiresAfterSeconds (inside configurations) per transaction. 

What should I do when a transaction fails with TIMEOUT?

A TIMEOUT failure means the transaction was not signed and broadcast within the configured window. Because a timed-out transaction was never broadcast to the blockchain, there is no risk of duplicate submission when you recreate it. Recommended steps:

1. Check whether the signing step was missed (pending approvals, Co-signer availability).
2. Review whether your configured timeout is appropriate for your workflow.
3. Recreate the transaction. A timed-out transaction cannot be resubmitted.