THORChain Protocol Upgrade v3.20

THORChain v3.20 is a feature-heavy upgrade, with Zcash and Monero moving closer to activation, BNB, Base and Solana trading resuming, and two important additions to the protocol's economic architecture: Protocol-Owned Liquidity mimirs and the new Stable Reserve.

The release also expands Memoless Swaps to ERC-20s, adds MOR to THORChain's EVM token lists, and ships another large batch of swap, solvency and node security improvements. Last but not least, churn will resume on the network.

XMR Is Landing on THORChain

The foundations for XMR support landed in v3.19, but integrating a privacy chain like Monero requires very different infrastructure from THORChain's existing chains. In particular, XMR uses FROST threshold signing, while its privacy model makes transaction observation and recovery more complicated.

v3.20 ships a large batch of fixes and hardening around key generation, signing, vault rotation, transaction observation and recovery.

The main changes include:

• Commit #c3e5c972: improves XMR keygen consensus and prevents failed Monero vault keygens from incorrectly triggering mass validator jailing.
• Commit #5c0b2fed: allows a node that failed locally during FROST keygen to recover when the rest of the network successfully completed it.
• Commit #60645ac1: improves how XMR monovault keygen is coordinated across the network.
• Commit #e3c10ac3: improves FROST signing recovery when some participating nodes are missing the required key.
• Commit #484b24ce: improves recovery of missing FROST and EdDSA keyshares.
• Commit #a46c5976: ensures recovered FROST keyshares are correctly restored with the Monero sidecar.
• Commit #7adf504d: prevents false XMR insolvency reports while the Monero sidecar is still reconciling balances.
• Commit #4fd394d2: improves recovery when Monero spent-output information fails to import correctly.
• Commit #625bcff1: strengthens FROST gas handling and retry behaviour.
• Commit #4cac9e11: introduces a broader security-hardening package across XMR and FROST.
• Commit #e382d2e3: exposes additional XMR outbound information to improve transaction tracking and transparency.

As with any new launch, the integration will be rolled out progressively as liquidity grows, allowing node operators to test and monitor the new signing infrastructure, a process that generally takes a few weeks.

BNB, Base and Solana Prepare to Resume Trading

BNB, Base and Solana have remained halted while a combination of chain-specific, solvency and security issues were worked through.

v3.20 ships the fixes needed to prepare these chains to return, with trading expected to resume progressively after the upgrade.

Solana receives several explicit improvements:

• Commit #c1200c85: recognizes SOL outbounds that reached Solana but failed onchain, allowing them to be signed and attempted again.
• Commit #935eeea6: keeps Solana vault signing state fresh through periodic self-signing.
• Commit #104f5c5c: improves the timing of Solana solvency reports.
• Commit #7cd0eabd: fixes an edge case in Solana block scanning.
• Commit #dab36978: preserves the SOL required for rent during Ragnarok events.
• Commit #01cddf5a: adds Solana information to the node status endpoint.

The upgrade also contains wider vault, solvency and recovery improvements that support safer chain operation. Some additional security fixes included in the v3.20 binary are not yet public, so the full technical detail behind every BNB and Base fix is not available in the public changelog.

ZEC is One Step Closer to Launch

Commit #60eeb816 updates THORChain’s Zcash client so it recognizes Zcash’s NU6.3 “Ironwood” network upgrade, which activated at Zcash block 3,428,143. The commit adds the new consensus branch used after that upgrade and updates THORChain’s Zcash test environment to a compatible Zebra version. ZEC is expected to be THORChain’s next chain integration.

Stable Reserve

v3.20 introduces an experimental new Stable Reserve designed to make THORChain more competitive for stablecoins swaps (Commit #7f3ff130).

For the first time, eligible stablecoins can be swapped directly against protocol-owned stablecoin inventory rather than routing through THORChain's normal RUNE-based liquidity pools.

When enough inventory is available, the Stable Reserve can fill an eligible stable-to-stable swap at 1:1 with no liquidity fee and no slip. Normal outbound network fees still apply. If the Stable Reserve cannot fill the trade, it simply falls back to THORChain's normal pools.

The goal is simple: make THORChain considerably more competitive for stablecoins flow and give wallets, aggregators and exchanges another reason to route transactions through the network.

The Stable Reserve also includes protection against stablecoin depegs. If a supported stable becomes unhealthy, the protocol can stop using it for new fills and move its inventory toward healthy stablecoins or RUNE.

The feature ships disabled by default and can be progressively activated once testing is complete.

POL Becomes Operational

Protocol-Owned Liquidity, or POL, could be one of the most important changes to THORChain's liquidity model.

The foundations were introduced in v3.18, allowing part of THORChain's System Income to be redirected into a dedicated POL Reserve and then deployed as RUNE liquidity into selected pools. That creates a potential flywheel:

System Income → POL → Deeper Pools → Better Swap Execution → More Volume → More System Income

v3.20 makes two Mimirs controlling this mechanism operational:

• POL System Income (Commit #a436d943): controls the percentage of System Income allocated to POL.
• POL Asset Whitelist (Commit #ef72482b): controls which pools are eligible to receive POL liquidity.

Together, these give node operators practical control over how POL is deployed.

MOR Added to EVM Token Lists

MorpheusAI's MOR token is being added to THORChain's EVM token configuration (Commit #a22cad0e).

The update adds MOR to the Ethereum token list and to the Base token allowlist, preparing it to be supported through THORChain.

Memoless Swaps Expand to ERC

THORChain's Memoless Swap system is expanding to ERC-20 tokens (Commit #fa402c5d).

As a refresher, a THORChain transaction contains a memo telling the network what to do with the funds. That works well for integrations built specifically for THORChain, but it creates friction for wallets and services that cannot easily construct custom memos. Removing the memo requirement removes that integration headache.

For users, Memoless Swaps simplify the experience by allowing swaps to be executed from any wallet to any wallet, without requiring the wallet itself to support THORChain or connect to a THORChain-specific interface.

With v3.20, Memoless Swaps expand to ERC-20s. Bifrost can recognize direct ERC-20 transfers into an active THORChain vault and process them through the Memoless system, without requiring the user or wallet to construct the usual memo.

Commit #25e248fc adds additional handler and refund coverage for ERC-20 Memoless transactions, while Commit #cc8c5c5a improves how Memoless Swaps recover when funding encounters an error.

Other Improvements

Swaps & Fees

Better Swap Queue Ordering - Commit #a50d5620

Improves how fee-only swaps are ordered, keeping execution deterministic while respecting minimum slip fees.

Dynamic L1 Fee Fix - Commit #02865243

Fixes an edge case in the Dynamic L1 Fee system introduced in v3.18, improving minimum fee behavior when quote data is still new.

Refund Accounting Fix - Commit #536cae17

Prevents the same refunded balance from being deducted twice.

Vaults & Solvency

Per-Asset Over-Solvency Controls - Commit #73062320

Allows over-solvency sweeps to be controlled independently for individual assets.

Vault Deficit Tracking - Commit #e76a394b

Makes accounting mismatches more visible by explicitly tracking vault deficits when a debit exceeds the recorded balance.

Insolvent Vault Protection - Commit #cd5e4071

Stops vaults affected by insolvency from being selected to receive new deposits.

Outbound Recovery - Commit #b8f1b361

Ignores stale, unfinished outbound observations when recovering transactions, reducing the risk of old data interfering with recovery.

Node & TSS Security

Encrypted TSS Keyshares - Commit #07dba3b0

TSS keyshare files are now encrypted at rest, reducing the risk of sensitive signing material being exposed on disk.

Safer Seed Phrase Handling - Commit #efbcfaee

Moves validator seed phrase loading toward file-based handling instead of exposing secrets through environment variables.

Signer Cache Expiry - Commit #a759cb4f

Extends signer-cache expiry handling across all supported chains, improving recovery from stale signing state.

Remove Keyverify Subsystem - Commit #b5bcd4b7

Removes the temporary Keyverify subsystem introduced during the v3.19 recovery and adds new TSS SessionNonce protections.

Distinguish Round-7 TSS Warnings - Commit #6cbdb578

Improves TSS event reporting by distinguishing round-7 warnings from actual failures and removing duplicate warning events.

Delegated Node Operator Permissions (ADR-030) - Commit #18855228

ADR-030 introduces delegated node operator permissions, allowing operators to keep their BondAddress cold while using separate hot wallets for routine node management. Delegates cannot access bonded RUNE or perform sensitive custody actions. The framework ships in v3.20 and is expected to activate in v3.21.