Delays

Overview

There are five phases a transaction goes through when interacting with THORChain:

1. Inbound Confirmation
2. Observation & Consensus
3. Finality & Confirmation Counting
4. Outbound Delay (Queueing)
5. Outbound Confirmation

Wait times can be between a few seconds to several hours. The assets being swapped, the size of the swap and the current network traffic within THORChain will determine the wait time.

1. Inbound Confirmation

This depends purely on the host chain and is out of the control of THORChain.

Typical confirmation times:

2. Observation & Consensus

Once a transaction is confirmed on its host chain, THORNodes must observe it. Each THORNode scans external chains for relevant vault activity. Once a supermajority (2/3+ of active nodes) independently observe the same transaction, it reaches consensus and is marked as observed. This process could be seconds to minutes depending on how fast nodes can scan their blockchains to find transactions.

You can inspect this process using the /thorchain/tx endpoint. For example:

View example Tx

"external_observed_height": 874437,
"external_confirmation_delay_height": 874437

In this example, Bitcoin block 874437 is when the transaction was first observed and when confirmation counting begins.

You can track the number of nodes that have seen a Tx by checking the signers array or looking at the status field on the /tx endpoint.

See Inbound Transactions for more information.

3. Finality & Confirmation Counting

To protect against reorgs, THORChain requires some chains (like Bitcoin and Ethereum) to wait for economic finality — enough confirmations to make a reorg economically infeasible. It tracks both, then computes the number of blocks to wait. It then populates this on the /tx endpoint.

Example: https://thornode.ninerealms.com/thorchain/tx/b9d70ea425c44ce0a2f78ea0bdb2fc861e214d93752bc9a1f811000dc2b44d4b

• BFT chains like Cosmos do not require additional confirmation counting.
• UTXO and EVM chains do.

This is reflected in these fields:

"consensus_height": 18972084,
"finalised_height": 18972084,
"outbound_height": 18972085,

• block_height = first seen external block height
• finalised_height = block height required to mark tx as final
• outbound_height = when outbound is eligible for scheduling

Finality is dynamically calculated using:

RequiredConfirmations = min(
    (TxValue / BlockReward) × ConfMultiplier,
    MAXCONFIRMATIONS
)

• The confirmation multiplier and cap are set via Mimir per chain
• Larger transactions generally require more confirmations

See Finality & Pre-Confirmation for deeper explanation and code references.

4. Outbound Delay (Queueing)

After finality, the transaction is ready for outbound processing. THORChain throttles all outputs to prevent fund loss attacks. The maximum delay is 720 blocks which is approx 1 hour. Outbound delay worked out by computing the value of the outbound transaction in RUNE then applying an artificial delay. If the tx is in "scheduled", it will be delayed by a number of blocks.

A transaction in "scheduled" state is delayed. Once it reaches "outbound", it’s in the signing queue and about to be broadcast.

See more information here.

Swapper Clout Reduces Delay

Clout is the cumulative total fees paid (in RUNE) for a given address. Swappers with a high clout have proven themselves to be highly aligned to the project and therefore can reap the rewards by getting faster trade execution. Frequent swappers who pay more fees earn Swapper Clout. This is used to reduce or eliminate outbound delay.

• For each swap, 50% of fees (in RUNE) are attributed to the sender and recipient
• Clout reduces the effective value of the outbound when calculating delay
• The formula:

delay = delayCalc(outboundValue - (cloutScore - cloutUsed))

• Clout is applied proportionally across all active outbounds from the same address
• Clout is restored once the outbound achieves observation consensus

See full implementation

Monitoring the Outbound Queue

• All Queued TxOuts
• Scheduled (Delayed) Outbounds
• Ready-to-Send Outbounds

5. Outbound Confirmation

This depends purely on the host chain and is out of the control of THORChain.

Typical confirmation times:

UX Guidelines: Handling Delays

Apps and frontends should:

1. Use the Quote endpoint to estimate gas fees and inform the user.
2. Avoid leaving users staring at a spinner — move swaps to a "pending" state with a countdown.
3. Notify the user once their swap completes — especially if it's faster than expected.
4. Let users close the app while waiting — no need to keep them locked in.