THORChain rolls Monero, router V6 into v3.20 as consensus bug halts churning

THORChain developers have folded what was originally a v3.19.4 point release into a larger v3.20 deployment after a consensus bug surfaced during vault rotation — the network's periodic re-shuffling of asset custody across validator sets. Until v3.20 ships, churning stays paused; once it lands, the plan is to re-enable Solana first, then restore churning. The change of plan pulls Monero (XMR) integration and the router V6 contracts — both already through chain-net testing — into the same window. The situation is documented on THORChain's own developer channels; the primary integration design lives in the THORChain dev docs XMR addition page, the pre-integration timeline in the blog post "$XMR Is Coming", and the July 10 recap in The Cryptonomist.

What happened

Churning — THORChain's mechanism for rotating validator sets in and out of the asgard vaults — hit a consensus failure serious enough that the network paused all rotations. The fix could not be back-carried into a point release. The team met the same day the issue was scoped, killed the planned v3.19.4 patch, and cut a new v3.20 release train targeting an upgrade block height in the following week. All work originally scoped for v3.19.4 — Monero integration and router V6 among it — rolls into v3.20. The SOL pool was explicitly confirmed safe; EdDSA-based chains are not vulnerable to this class of vault-rotation bug, which is why Solana is the first pool the team plans to re-enable once v3.20 activates.

Why this is a bigger release than a security patch

Two features that had been shipping on their own timeline are now bolted onto the same upgrade:

Monero integration

XMR support has been the closest major cross-chain integration to shipping for months. Per the XMR addition design, the sidecar model uses a dedicated Monero daemon per THORNode with explicit mocknet / chainnet / stagenet / mainnet configuration, TLS/auth hardening in mainnet mode, and a 32-byte-equivalent store secret. The integration has cleared chain-net testing and developer review, and the pre-launch write-up laid out a conservative go-live: shallow, protocol-owned liquidity to seed the XMR pool and small test swaps to bound exposure before third-party liquidity providers can enter. A Least Authority audit is being arranged, per the same channels.

Router V6

The V6 router is the contract layer between THORChain's asgard vaults and the EVM chains it swaps against (Ethereum, BSC, Avalanche, Base). Router upgrades matter because THORChain's economic security depends on the asgard vaults being the sole authorized routers on every supported EVM chain — a router bug is a whole-network failure mode. V6 code is described in the July 10 recap as "already ready" and being deployed progressively across chains, rather than in a single big-bang activation.

The consensus fix

The specific class of bug is not fully public, but the containment posture is: churning paused, all pools frozen during rotation, Solana held back until the fix is on-chain. The bug lives deep in Thornode code paths that a patch release cannot safely modify, which is why the team escalated the version number.

Numbers

- Prior planned patch     : v3.19.4 (scrapped)
- New release             : v3.20 (targeting upgrade height in week of Jul 14–20)
- Rolled-in features      : Monero (XMR) integration, router V6
- Churning status         : paused since bug detection, resumes post-v3.20
- Solana pool             : confirmed safe (EdDSA), first pool to re-enable
- XMR pool go-live plan   : shallow protocol-owned liquidity + capped test swaps
- Pending audit           : Least Authority (XMR)

Figures per the THORChain blog XMR write-up, the XMR addition design doc and the Cryptonomist July 10 recap. Code lives at gitlab.com/thorchain.

What to watch

1. The v3.20 activation block. Whoever runs a node, a swap-router, or a THORChain-facing wallet needs the target height on-hand — the release train targets the week starting July 14; the specific height will be pinned in the THORNode release notes on GitLab.
2. Solana pool re-enable — before churning. The intended sequencing is v3.20 activation, then Solana on, then churning back on. Any deviation from that order matters: re-enabling churning without the SOL re-enable would leave the SOL pool in the pre-v3.20 posture during the first rotation.
3. XMR pool depth. The launch cap is deliberately shallow. Anyone routing size through XMR/RUNE in the first week will hit slippage that reflects protocol-owned liquidity, not organic depth. LPs are the ones to watch — the pool becomes usable at scale only once third-party liquidity enters.
4. Router V6 rollout per EVM chain. Progressive deployment means the ETH router and the BSC router will not necessarily transition at the same block. Integrators (aggregators, wallets) that pin router addresses need to track the migration list on GitLab, not assume a global cut-over.
5. The Least Authority audit. "Being arranged" is not "complete." XMR goes live before the audit report is public; the audit outcome will land after operators are already routing swaps.

Context — the second major THORChain restart in 12 months

THORChain has been here before. The $10.7M vault exploit in mid-2025 triggered a month-long trading halt and an 11-step restart plan; the vault-rotation attack surface was one of the recurring concerns of the post-mortem. This v3.20 pause is not an exploit — no funds moved out — but the pattern is the same class of failure mode: churning is the moment at which THORChain concentrates its highest cross-chain risk, and a bug found in that path is a network-wide operational event, not a per-chain one. Cross-chain routers whose economic security depends on periodic key rotation are particularly exposed to consensus bugs in rotation code; this is the second time in a year the same subsystem has forced a coordinated pause. The design goal for v3.20 is to close that class of bug rather than patch its current instance.