How THORChain Vaults Sign Outbound Transactions

THORChain coordinates outbound transactions by assigning each one to a vault, having Bifrost coordinate a threshold signature, and recording validator attestations after broadcast. The vault’s key is distributed among validator nodes as secret shares. A signing ceremony combines contributions from enough participants to produce one transaction signature without reconstructing the private key.

This process sits at the end of a larger state transition. An external-chain deposit is observed and finalized; THORChain processes the resulting action and schedules an outbound with its destination, asset, amount and memo. The outbound is a protocol instruction until a vault signs and broadcasts it on the destination chain. For a broader account of how route choice fits around this execution step, see thor swap.

What does the vault coordinate before signing?

THORChain selects a vault responsible for the funds and assigns the outbound to it. A vault is a collective signing account, not a conventional wallet with one private key held by one operator. Its public key identifies the account on an external chain; validator nodes retain shares produced during distributed key generation.

The assignment matters because the signer must control the assets being spent. The protocol’s logical vaults can consist of physical vaults, or shards, each with its own key and external-chain address. An outbound is handled by the vault recorded for it, while retiring vaults can continue signing transactions that move their remaining funds. A vault’s status therefore affects which work it can receive and which existing balances it can still move.

Bifrost connects this THORChain instruction to the destination chain. Each node runs chain-specific observer and signer components. The signer reads outbound data, prepares a transaction in the destination chain’s format, and coordinates the signing session for the assigned vault. That preparation includes the chain-specific transaction fields and fee treatment; the same protocol instruction cannot be serialized identically for a UTXO chain and an account-based chain.

How do threshold signatures produce one transaction?

Threshold signing lets multiple nodes authorize one transaction without any node assembling the vault’s full private key. Each participating node loads its own key share and takes part in a multi-round signing protocol over the transaction data prepared for signing. When enough signing participants contribute, the protocol combines their signature shares into a valid signature accepted by the external chain.

The threshold is a coordination rule, not a requirement that every validator be online for every outbound. THORChain documentation describes the signing threshold as a supermajority, at least 67% of the relevant participants. If the signing ceremony fails or times out, the network can retry it or, under its rescheduling rules, assign the outbound to another vault. A failure to form a signature is distinct from a transaction that was signed but did not confirm externally.

The distinction is important for understanding what the signature proves. It authorizes the transaction from the vault’s account. It does not itself prove that the external chain accepted or finalized the transaction. Bifrost’s chain-specific signer broadcasts the signed transaction, and nodes report outbound observations back to THORChain.

The sequence can be read as four separate checkpoints:

• Assignment: THORChain records which vault is responsible for the outbound.
• Keysign: participating nodes use their shares to produce a single valid signature.
• Broadcast: Bifrost sends the signed transaction to the destination chain.
• Attestation: nodes report the outbound, and validator consensus updates its status.

What happens after broadcast, and where can it fail?

After broadcast, the signing node submits an outbound observation, and other nodes can independently observe the transaction on the external chain. Matching validator attestations allow THORChain to mark the outbound complete. This is an internal consensus decision based on observations; it is not a separate proof generated by the external chain for THORChain to verify.

Broadcast is not the same as confirmation. A transaction may remain pending or be dropped because of external network congestion, fee conditions or other chain-specific behavior. Bifrost has chain-specific recovery mechanisms for stuck transactions. The protocol also tracks outbounds to limit duplicate signing and rebroadcasting across retries or restarts. That bookkeeping matters because a rescheduled transaction could otherwise overlap with an older signed transaction that later confirms.

There are thus two different coordination problems. TSS handles authorization: enough key-share holders must participate to create a valid signature. Observation and consensus handle reporting: validators must agree on what happened after broadcast. A successful ceremony does not guarantee fast external confirmation, and a broadcast report does not mean the destination chain has reached its own finality threshold.

For readers assessing an outbound, the useful distinction is between the THORChain instruction, the vault signature, the external broadcast and the network’s completion record. Each describes a different stage. Vault signing coordinates who can authorize the spend; Bifrost supplies the chain-specific execution and observation path around that authorization.