This article provides a complete analysis and timeline of the events that followed the exploit on May 15, 2026. The article explains how the incident unfolded, how the network coordinated its security response through both automatic and manual mechanisms, and offers context on how THORChain operates for readers unfamiliar with its architecture. The investigation into the root cause of the exploit is still ongoing.
Table of Contents:
(1) Summary
(2) Architecture and Security
(3) Detailed Timeline
Summary
On May 15, 2026, THORChain was the victim of a targeted exploit that drained approximately $10.7M from a single vault (out of five). The attacker was a newly churned node operator who entered the network two days prior and exploited a vulnerability in the GG20 Threshold Signature Scheme.
The network's automatic solvency detection systems triggered within minutes, halting signing and trading across multiple chains without human intervention. Node operators then coordinated rapidly through Discord, stacking manual pauses and casting formal Mimir governance votes that brought the entire network to a controlled halt (trading, signing, chain observation, and churning) within approximately two hours of the community raising the alarm.
The remaining five vaults were unaffected. The SOL pool was explicitly confirmed safe, as EdDSA-based chains are not vulnerable to this class of attack. The investigation is ongoing, coordinated with dedicated specialized entities. As an immediate precautionary measure, patch v3.18.1 was released to safeguard the remaining vaults while the investigation continues. The recovery of lost funds will be decided through community governance via ADR-028 (Architecture Decision Record #028).
Architecture and Security
Before examining the events of May 15, 2026, it is essential to understand the defensive systems that THORChain relies on to secure its assets. This section documents three interconnected layers: the GG20 Threshold Signature Scheme used to collectively control vault keys, the automatic Solvency Checker that monitors vault balances in real time, and the Halt & Emergency governance system through which node operators can manually freeze network activity when a threat is detected.
Why this matters: Each layer played a specific role during the May 15 incident. Understanding how they work, and where they failed or succeeded, is a prerequisite to understanding how the attack unfolded.
Threshold Signature Scheme - GG20
THORChain's vaults are not controlled by a single private key. Instead, they are secured using GG20 (Gennaro-Goldfeder 2020), a Threshold Signature Scheme (TSS) that distributes key control across multiple independent node operators. No single node ever holds or has access to the full private key.
How it works
In a standard GG20 signing ceremony, a quorum of nodes collectively produce a cryptographic signature without any individual ever reconstructing the private key. The process proceeds in multiple communication rounds:
- Each participating node holds a secret key share, a fragment of the vault's private key.
- Nodes exchange small pieces of encrypted information across several protocol rounds.
- At the end of the ceremony, the exchanged values are combined to produce a valid signature.
- The full private key is never assembled in any single location at any point in the process.
Why GG20 is still in use: THORChain had long identified DKLS (Doerner-Kondi-Lee-Shelat) as its intended long-term cryptographic destination, a more modern and robust TSS scheme. However, THORChain had unique requirements that standard DKLS implementations did not meet such as identifiable aborts. To address this, THORChain engaged Silence Labs in November 2025 to build identifiable aborts into a custom DKLS implementation tailored to its needs, with a targeted delivery date of Q1/Q2 2026. GG20 was therefore retained in production in the interim, pending completion of that work.
Automatic Solvency Checker
The THORChain protocol continuously monitors the solvency of its vaults through an automated detection system introduced to catch insolvency events early, or ideally, before they happen at all. The system operates in two distinct modes.
Reactive mode
In reactive mode, each node independently and continuously compares what the network believes it holds in the vault against what is actually present in the on-chain wallets for every connected chain.
- If the vault's expected balance exceeds the actual on-chain balance by more than 1%, the node reports an insolvency event for that chain.
- If more than 66% of nodes report insolvency on the same chain, trading for that chain is automatically halted (Halt{Chain}Trading). This is an automatic process.
- The halt simultaneously emits a security event to the THORSec (THORChain Security) monitoring channel.
Why 1% tolerance? THORChain calculates expected balances by aggregating inbound and outbound transaction values. For gas assets (used to pay transaction fees), minor divergences of up to ±1% can occur naturally due to rounding and timing. Any divergence beyond this threshold is treated as anomalous.
Proactive mode
In proactive mode, rather than detecting an insolvency after the fact, the network attempts to prevent one from occurring in the first place.
- When a node is about to sign an outbound transaction (txOut), it first simulates the effect of executing that transaction on vault balances.
- If the simulation shows that executing the transaction would render the vault insolvent, the node refuses to sign.
- The node automatically reports the attempted insolvency, triggering the same halt and alert mechanism as reactive mode.
During the incident May 15: The solvency checker functioned as designed: it detected the vault imbalance within minutes and automatically triggered chain-level halts. However, because the attacker had already reconstructed the full private key and signed transactions, the proactive mode had no opportunity to intercept the signing process. The reactive mode caught the imbalance after the fact, but the funds had already left the vault.
Halt & Emergency Governance
THORChain includes a layered halt system that allows the network to freeze specific operations at various levels of granularity, from halting signing on a single chain to pausing all activity across the entire network. These controls are governed through Mimir, THORChain's on-chain parameter system.
Node operator-triggered halts
Beyond the automatic solvency-triggered halts, node operators can manually pause trading when they detect suspicious activity. This mechanism is deliberately designed to prevent both unilateral abuse and coordination delays:
- A single node can pause trading for up to 720 blocks (approximately 1 hour).
- Each additional node calling for a halt adds another 720 blocks to the active halt timer.
- Any node calling for trading resumption removes 720 blocks from the timer.
- Each node can use this function only once per churn cycle (approximately 3 days), preventing repeated abuse.
Design principle: No single node can unilaterally control the network for an extended period, but multiple nodes acting independently can sustain a halt long enough for the team to investigate and respond. On May 15, approximately 18-20 nodes stacked pauses to create a multi-hour halt window.
Mimir governance and the 3-vote threshold
THORChain's network parameters are managed through Mimir, a set of on-chain parameters that define how the protocol behaves. There are two different types of Mimir.
Economic Mimirs require ⅔ supermajority (67%) of active nodes to agree. Examples include minimum bond size, minimum swap fee, and churn interval.
Operational Mimirs require only 3 nodes to activate. 4 nodes can overturn, then 5 nodes can re-activate, and so on. Examples include halt trading, halt signing, halt chain global.
Note: The 3-vote minimum for operational parameters reflects a deliberate balance between security and speed. Requiring a supermajority for emergency halts would make rapid response impossible during an active exploit. Conversely, allowing a single node to trigger network-wide halts would create an obvious attack surface for abuse. Three independent nodes must agree,fast enough for emergencies, resistant enough to prevent unilateral manipulation.
Detailed Timeline
This section provides a reconstruction of the May 15, 2026 exploit, starting two days prior to the attack. All times are UTC. Block numbers reference the THORChain mainnet ledger.
The Setup
May 1, 2026 - Presumed Attacker Joins Discord
A freshly created Discord handle (Dinosauruss) joins the THORChain Developer Discord. Dinosauruss proceeds to ask a bunch of questions on how to get their node churned into the network. The normal 3 day churn interval is delayed due to unrelated reasons, forcing Dinosauruss to wait a couple weeks to churn in. Dinosauruss appears to be anxious to get their node churned in ASAP.
May 13, 2026 - Malicious Node Churns into Network
A brand-new node operator address (n84q) on a brand-new node address (n84q), with ~635,000 RUNE across two different bond addresses, is churned into the active validator set. The node is randomly assigned to one of the five vaults like all other nodes. Over the following two days, this node participates in routine GG20 signing ceremonies, getting prepared for the exploit.
May 15, 2026 - Vault drained (~$10.7M in unauthorized outbound transactions)
With the vault full private key reconstructed, the attacker signs and broadcasts outbound transactions directly, bypassing the GG20 signing ceremony entirely. Approximately $10M (initially estimated at $7.4M) is drained from the targeted vault. The five remaining vaults are unaffected.
Automatic Response - The Solvency Checker
A few minutes after the vault is drained, the solvency checker (reactive mode) detects a divergence of more than 1% between expected and actual vault balances across multiple chains. Automatic protocol changes are triggered without any human intervention. The table below shows every automated action taken by the protocol, each one designed to preserve the network and stop further outbound activity.
Within approximately 52 minutes of the unauthorized transactions, the solvency checker had automatically halted signing and trading across ETH, AVAX, BSC, BASE, DOGE, and GAIA, with no human intervention.
Community and Human Intervention
May 15, 2026 from 09:08 to 09:41 - Community Raises Alarm
As network activity doesn’t resume, the node operators and the community start investigating the problem. A community member flags unusual activity (multiple send transactions from the TC router to an Ethereum address with no memo) and calls for an immediate global emergency halt. This is the first human-initiated alert of the incident.
Node xuuu is first to act with a manual 720-block pause Other nodes begin stacking more 720-block pauses in rapid succession.
In parallel, node operators begin casting formal Mimir governance votes. The 3-vote threshold triggers official network-wide parameter changes. Trading, signing, chain observation, and churning are halted consecutively through coordinated Discord communication and on-chain governance, all within approximately one hour of the community alert.
HALTTRADING activated at block 26183438
HALTSIGNING activated at block 26183439
HALTCHAINGLOBAL activated at block 26183590
HALTCHURNING activated at block 26183849
Churning is paused to prevent the malicious node from exiting the network and to block any additional malicious nodes from entering.
Official Communications
The following announcements were issued by the development team in the hours and days following the incident.
May 15, 2026 at 11:01 - First official public statement
The development team confirms unauthorized outbound transactions from one vault. Loss estimated at approximately $7.4M USD. Root cause not yet determined and three vectors under investigation: a GG20 vulnerability, infrastructure compromise, and other attack vectors. Node operators are asked to audit their infrastructure and submit Bifrost logs via make relay.
May 15, 2026 at 19:10 - Second update: attacker identified, leading theory confirmed
After a full day of investigation, the team provides a comprehensive update. Key findings:
(1) the malicious node thor16ucjv3v695mq283me7esh0wdhajjalengcn84q is linked via on-chain forensics to the Ethereum addresses that received the stolen funds;
(2) the leading theory is confirmed as an exploit in the GG20 TSS implementation allowing progressive key material leakage;
(3) the loss is revised to approximately $10.7M;
(4) coordination with Outrider Analytics and law enforcement is underway.
Recovery options under discussion include bond slashing, POL (protocol owned liquidity) absorption, and other community proposals.
May 16, 2026 at 10:26 - Scam alert
The marketing team issues a warning to the community regarding fake links and impersonators circulating across social media. Multiple fraudulent airdrop and refund schemes are being relayed by prominent media outlets. The community is urged to exercise extreme caution and rely only on official channels.
May 18, 2026 at 15:49 - Patch and recovery roadmap
The developer and THORSec teams confirm a strong understanding of the attack while withholding technical details until they can alert other projects using the same GG20 cryptography, so they can protect their systems. Patch v3.18.1 is imminent and all node operators are asked to upgrade immediately.
Recovery of lost funds will be decided through community governance via ADR-028, with the chosen approach to be implemented in v3.19.
The developer team is leaning toward remaining on GG20 in the short term in order to restore network stability as quickly as possible, with longer-term cryptographic decisions deferred until the network has fully recovered.
May 18, 2026 at 20:49 - Patch preparation and Bifrost scale-down requested
All active validators are asked to scale down their Bifrost pods as a precautionary measure while the patch is finalized. Commands: make pull followed by make scale-down (selecting bifrost). This reduces the network's attack surface during the remediation window ahead of the v3.18.1 release.
Conclusions & What Comes Next
The May 15th exploit exposed a vulnerability in THORChain's GG20 implementation. The network's automatic and manual response mechanisms performed as designed, containing the damage to a single vault. The following steps are now underway:
Patch v3.18.1 is the immediate priority and all node operators will upgrade in the coming days.
The investigation is ongoing. A complete technical update will be published once the developer team has gathered all relevant details.
Community governance will determine the recovery path. Proposals are being discussed via ADR-028. Once a perceived consensus is reached, nodes will vote and the chosen approach will be implemented in v3.19.
A follow-up report will be issued once the investigation is complete and the recovery plan has been finalized.