Why a THORChain halt can leave a deposit awaiting a refund

A THORChain deposit can wait for a refund because a halt may stop the network from observing it, processing it or signing the outbound transaction that returns it. Those are separate stages, controlled by different chain-level settings. A transfer already sent on Bitcoin, Ethereum or another connected chain remains on that chain; THORChain must observe it and reach consensus before it can decide what happens next.

The term “paused” hides the key distinction. A trading halt keeps chain observation running and sends refunds instead of executing swaps. A signing halt queues outbound transactions, including refunds. A full chain halt stops observation, so nodes may not yet know that a deposit arrived. Readers looking at a thor swap route should keep that sequence in view: the route determines where a completed swap would go, while the halt determines which processing steps can proceed.

What does a THORChain halt stop?

A THORChain halt stops the specific operation named by its control, and the difference determines whether a refund can be created or only delayed. The network uses chain-specific settings, so a halt on one connected chain does not automatically mean every THORChain operation has stopped.

A trading halt, set with a key such as HALTETHTRADING, leaves Bifrost—the component that scans external chains—online. Nodes continue observing inbound transactions, but transactions involving that chain are not processed as swaps; the documented behavior is refunds only. A signing halt, such as HALTSIGNINGETH, allows inbound transactions and swap processing to continue, but stops outbound signing. That leaves the resulting transaction in a queue until signing resumes.

A chain halt, such as HALTETHCHAIN, is broader. Bifrost stops scanning the chain, and nodes may need to resync to its tip before activity resumes. If a deposit arrives during that gap, THORChain cannot act on an inbound transaction it has not observed. A frontend may still show a pending transaction, but that status does not establish whether nodes have seen it.

There are also narrower pauses. A liquidity-provider pause stops pool deposits or withdrawals, for example, without necessarily stopping swaps. A network-wide trading halt affects trading across connected chains while native RUNE transactions can continue. The halt’s scope matters: a paused pool action is not evidence that a swap, chain scanner or refund queue is paused too.

How does an inbound deposit become a refund?

An inbound deposit becomes eligible for a refund only after THORChain observes it and the relevant transaction checks allow it to proceed. On the source chain, the transaction first needs confirmation. THORNodes then independently scan for the vault activity; once a supermajority observes the same transaction, it reaches observation consensus. Chains that can reorganize also require confirmation counting to reduce the risk of acting on a transaction that later disappears.

After those steps, THORChain processes the transaction and its memo, which carries the user’s requested action. If the network is in a trading halt for the relevant chain, it can choose the refund path rather than execute the swap. But creating a refund and delivering it are different events: the refund must still be signed, broadcast to the source chain and confirmed there.

• Not observed: A full chain halt may have stopped scanning. There is no confirmed THORChain decision yet.
• Observed, awaiting processing: Nodes have seen the inbound, but consensus, finality or processing has not completed.
• Refund queued: THORChain has determined the return path, but a signing halt or outbound queue may delay broadcast.
• Broadcast: An outbound transaction exists on the source chain and needs that chain’s confirmation.

The sequence explains why “refund only” does not mean “refund immediately.” A trading halt can produce a refund decision while a signing halt prevents its outbound from being signed. If the chain itself is halted, the earlier observation step may be missing. The inbound can therefore remain unresolved until scanning resumes and nodes catch up.

How can you tell whether a refund is actually pending?

Check the source-chain transaction and THORChain’s transaction record separately; a wallet spinner alone cannot show which stage has stopped. Keep the inbound transaction hash, then inspect its THORChain status for observation, node signers, confirmation or finality fields, and any outbound transaction hash. An outbound hash is evidence that a refund was broadcast; before that, the transaction may still be awaiting a decision or signature.

Compare the status with the type of halt reported for that chain. A trading halt points toward refund processing; a signing halt explains a queued outbound; a chain halt explains why the inbound may not appear as observed. Halt status can also be stale: THORChain’s documentation warns that during a consensus halt, the inbound-address endpoint may report halted = false even though the network is hard-halted.

Do not resend the deposit while its status is unresolved. A second transfer is a separate transaction and can create a second pending operation; it does not accelerate the first refund. The useful checkpoint is a source-chain outbound hash and its confirmation, not a frontend changing from “pending” to a generic “complete” label.

What should you expect when the chain resumes?

Resumption restores only the stages covered by the lifted halt, and a full chain halt can require nodes to sync before scanning and trading restart. Once observation resumes, nodes can catch up on external activity; after consensus and finality, THORChain can process the inbound under the active rules. If the result is a refund, outbound signing and source-chain confirmation still follow.

So a deposit awaiting a refund is not necessarily lost, but “paused” alone cannot prove that a refund has been created or sent. Identify the halt type, locate the inbound in THORChain’s transaction record, and look for the outbound hash. Those facts separate an unobserved deposit from a queued refund and a refund already moving on its source chain.