Thorchain
Thorchain Vaults and Shared Transfer Signing
Thorchain vaults hold native assets under the shared signing control of their assigned validator nodes. In an Asgard vault, each member retains a secret key share. A qualifying group uses a threshold signature scheme, or TSS, to authorize outbound transfers without assembling the complete private key during routine signing. The destination blockchain then processes the signed transaction under its own rules. This arrangement depends on functioning cryptography, available signers, and accurate chain observations; it doesn’t guarantee immediate settlement.
Jump to a section
Native custody behind the pool balances
Asgard vaults hold funds on connected blockchains, while liquidity pools track the balances that determine exchange pricing. A pool entry describes the protocol’s accounting. Spending the corresponding external assets requires a transaction from a vault that holds them. This distinction explains why a completed pricing operation can precede delivery: updating internal balances doesn’t itself transfer funds on another blockchain.
Vault custody also extends beyond assets allocated to liquidity pools. Trade Assets represent credits backed by native assets that remain within the network until withdrawal. Their presence means a vault’s total holdings needn’t equal one pool’s balance. The custody layer supplies the native funds, and the appropriate protocol module records the claim against those funds.
Key generation and local signing shares
Key generation creates the shared vault public key and each participant’s secret share through a distributed ceremony. It establishes which nodes can participate in that vault’s routine signing.
Joint creation of the vault key
Participating nodes contribute cryptographic material and check each other’s contributions across multiple rounds. The ceremony produces a common public key with different secret shares for the members. Its normal operation doesn’t assemble a complete private key for an operator to store. Membership belongs to that key-generation group; a validator outside it can’t contribute a usable share for the same vault.
Persistence and protection of key shares
Each node retains its share and the metadata that identifies the signing party. Version 3.20 added encryption at rest for TSS files that store key shares. Encryption limits exposure from stored files, while backups support recovery after storage loss. Operators still need the correct private material for the vault that they serve. Public addresses alone don’t preserve their ability to sign.
How many Asgard members must sign a transfer?
For an Asgard committee of n members, routine TSS signing requires at least ceil(2n/3) participants. This means two-thirds of the committee, rounded up to a whole node.
The denominator is the membership of the particular vault. It isn’t the total number of validators across all Asgard shards.
Signing and blockchain consensus use separate thresholds. Vault members supply cryptographic shares for a payment; validators also agree on the network’s state and reported external events. Block consensus requires more than two-thirds of voting power.
A signing party can continue when enough eligible members remain available. Once participation falls below its threshold, additional willing validators elsewhere can’t substitute for missing shares.
Bifrost’s view of external-chain activity
Bifrost connects validator operation to the chains that hold vault assets, using chain clients to observe transactions and prepare outbound payments. Its observers report relevant external events to the protocol for consensus. Observation includes chain-specific confirmation rules. On chains with delayed finality, detection can precede the confirmation state that permits processing. A chain reorganization can also remove a previously observed transaction. Bifrost’s errata handling reports those changes so the protocol can correct affected accounting. The network relies on validator attestations about external activity; the TSS signature alone doesn’t establish that an inbound deposit occurred or reached sufficient confirmations.
Outbound instructions and signature production
An outbound instruction supplies the payment that a vault must authorize, and Bifrost turns it into the destination chain’s transaction format. The signing ceremony acts on that transaction’s message.
The instruction that signers receive
The protocol assigns an outbound to a vault with the required funds. Transaction construction includes the destination, asset, amount, and chain-specific fee information. These fields define the authorized movement. A valid signature on a payment with the wrong recipient or amount doesn’t make it consistent with the protocol’s scheduled instruction.
Cooperation on the transaction message
Vault members use their secret shares, the transaction message, and fresh cryptographic randomness to produce signature contributions. The TSS implementation combines those contributions into a signature that verifies against the vault public key. It can group multiple signing messages into a ceremony for efficiency. Grouping signatures doesn’t necessarily combine their underlying payments into one external transaction.
Broadcast and outbound recording
The chain client submits the signed transaction to the external network. Validators then attest to the outbound, allowing the protocol to reconcile its records. Signature production, submission, and external-chain execution describe different states. A broadcast transaction can still await inclusion, and inclusion doesn’t establish successful execution when the destination chain reports failure.
Physical vault shards and changing inbound addresses
Asgard sharding divides custody and signing work among smaller groups of validators, with separate vault keys and chain-specific addresses. Smaller signing committees reduce coordination work and allow vaults to operate in parallel. Mimir, the network’s on-chain parameter system, includes AsgardSize, which governs vault membership size. The active validator set and configuration determine the resulting shards; a fixed vault count isn’t a permanent protocol property. Inbound selection favors stronger bond coverage relative to vault asset value, accounting for pending outbounds. That selection can change between existing vaults as their balances change, even before the next membership rotation.
Churn and migration between vault generations
Churn rotates validator membership and creates replacement vaults whose keys belong to the new signing groups. Asset migration then transfers custody from retiring vaults to the active generation.
Creation and activation
Successful key generation first creates a vault in InitVault status. The network promotes the replacement vaults to Active when the required set is ready. Previously active vaults become Retiring. Changing the membership record doesn’t hand the old signing shares to newcomers; fresh vault keys and asset transfers establish the replacement custody.
Movement of retiring balances
Retiring vault members sign migration transactions using the retiring vault’s key shares. Migration moves funds to Active vaults over successive rounds. The process preserves gas assets until it has moved assets that don’t pay transaction fees. Otherwise, an old vault could lack the funds needed to execute its remaining transfers. Pending outbounds can postpone a migration attempt.
Completion of retirement
The protocol marks a drained vault Inactive, allowing for chain-specific dust and locked reserve requirements. An inactive record can remain visible without serving as the deposit destination. ChurnInterval and FundMigrationInterval govern different parts of rotation and migration. Halts, signing failures, and unfinished transfers can change actual timing, so the configuration doesn’t promise a fixed wall-clock completion time.
Chain-specific spending and signing requirements
Chain clients adapt shared signing to each blockchain’s cryptography and spending rules. The ECDSA and EdDSA signing paths use separate key material, so one signature method doesn’t describe every supported chain.
Unspent transaction outputs, or UTXOs, create another operational dependency. A vault can accumulate many outputs from incoming payments. Spending numerous inputs increases transaction size and the number of signing messages, even when the payment has one recipient. Bifrost consolidates outputs through a vault self-transfer when the chain-specific configuration calls for it. Consolidation reorganizes the vault’s spendable funds and consumes transaction fees.
The Monero integration code uses FROST threshold signing through a separate signer process alongside Bifrost. That process manages Monero-specific cryptography and scanning state, while the protocol retains coordination and observation responsibilities. Its implementation has distinct key-generation and spending checks. The ordinary Asgard signing description doesn’t replace those chain-specific requirements.
Unavailable signers, retries, and operational halts
Missing participants or faulty signing exchanges can prevent a vault from producing a signature, even while its external balance remains intact. Failure handling records the affected ceremony and can trigger another signing attempt. The TSS blame process identifies failed rounds and responsible participants. It can support penalties or temporary exclusion, although a failure report doesn’t by itself distinguish malicious behavior from an infrastructure problem. Retry and rescheduling rules have limits set by protocol configuration. A new attempt still needs usable signing shares and spendable funds.
Halts operate at different layers. A signing halt queues outbounds while stopping new outbound signatures. A trading halt stops trading without necessarily stopping outbound delivery, and a chain halt stops observation for that chain. A quote can remain available during a signing halt. Its existence therefore doesn’t establish that a vault can currently send the quoted output.
The security boundary exposed in May 2026
On May 15, 2026, an attacker reconstructed an Asgard vault’s private key by exploiting the GG20 signing implementation. Malformed key-generation material and repeated signing exchanges leaked the other participants’ secret material. The attacker then signed transfers outside the normal cooperative ceremony.
The threshold protects routine signing while the cryptographic checks and secret shares remain intact. A usable reconstructed key bypasses the requirement to gather fresh signing contributions. The automatic solvency checker detected the balance discrepancy after funds had moved. Monitoring and halts limited further activity, but couldn’t reverse transfers that the external chains had already accepted.
The network restarted on June 22, 2026, with patched TSS code and staged recovery measures. Later upgrades added further keyshare and signing-state protections. Economic bonding makes misconduct costly and supports accountability, but it doesn’t prove that the cryptographic implementation has no defects.
A vault record’s meaning for custody and delivery
A vault record connects its public key, assigned members, status, and balances to the assets that the group controls. Those details answer different questions about receiving deposits and sending payments.
- For a new deposit, match the selected chain to its current active inbound address.
- For signing capacity, count the assigned committee; online status alone doesn’t establish that every member retains usable shares.
- For a retiring balance, account for pending outbounds, migration progress, and the gas that remains necessary.
- For an outbound payment, distinguish the scheduled instruction from its signature, broadcast, and external execution status.
- For present availability, confirm that the network state is fresh and that no trading, signing, or chain halt blocks the intended action.
A funded vault can still lack the participants or permission needed to send an outbound. When its status changes to Retiring, remaining funds serve pending obligations and migration; new deposits belong at the current active inbound address.
What readers ask about Thorchain
Does funding a node’s bond give me access to its vault key shares?
Providing RUNE toward a node’s bond doesn’t give the provider a vault signing share. Vault shares come from the participating nodes’ key-generation ceremony. The bond supplies economic collateral, while the operator’s signing infrastructure holds the private material needed to participate. Capital participation and cryptographic signing authority are separate responsibilities.
Why do older explanations mention Yggdrasil vaults?
Yggdrasil vaults belonged to an earlier architecture that used individual node-controlled wallets for outbound payments. The protocol moved away from that arrangement in favor of sharded Asgard vaults and shared threshold signing.
What happens to funds sent to an inactive Asgard address?
A refund attempt depends on enough of that vault’s original members remaining online with usable signing shares. Members in standby can count toward that availability when they still retain the required material. If the old vault lacks its signing quorum, the network can’t authorize a recovery transfer. An inactive address is unsuitable for new deposits.
Can the public vault key restore a node’s lost signing share?
The public vault key can’t replace a node’s secret signing share. A node needs the appropriate private share and the credentials required to recover its protected backup. The public key permits signature verification, but it doesn’t provide the private signing state needed to rejoin an existing vault’s ceremony.