New Discord Announcement from THORChain Devs #🚨thornode-mainnet
**🚨 ALERT 🚨**
We have identified unauthorized outbound transactions from one of the Asgard vaults. As a result, funds were lost from that vault.
This investigation is still in its very early stages, and the information below is preliminary and subject to change as we continue analysis. We ask the community to give the node operators and development teams time to complete a thorough investigation before drawing conclusions.
What we currently know:
- One of the six Asgard vaults appears to have been compromised.
- Current estimates place the loss at approximately $7.4m USD.
- The network automatically detected the abnormal behavior and halted signing activity, which alerted the broader community and prevented further outbound activity.
- Node operators securing the vault maintain bonded RUNE which is subject to slashing in the event of unauthorized outbound transactions.
- Churn activity has been paused while the investigation is ongoing and remediation steps are evaluated.
- As a result, onboarding of additional chains and any operations requiring churns will be delayed until the network is stabilized.
At this stage, the root cause has not yet been determined.
Current areas under investigation include:
- A potential vulnerability in the GG20 implementation layer
- Infrastructure or operational compromise affecting a sufficient number of nodes
- Other attack vectors that could have enabled unauthorized signing activity
At this time, we do not have evidence supporting any specific conclusion, and we want to avoid premature assumptions until the investigation is complete.
We are asking all node operators to immediately review their infrastructure, hosts, key management systems, and operational security for any signs of compromise or abnormal behavior, and to report anything suspicious to the dev team.
Additionally, node operators participating in the affected vault are requested to securely provide Bifrost logs to the dev team for analysis using `make relay`.
We will continue to provide updates as we learn more.
**🚨 ALERT 🚨**
We have identified unauthorized outbound transactions from one of the Asgard vaults. As a result, funds were lost from that vault.
This investigation is still in its very early stages, and the information below is preliminary and subject to change as we continue analysis. We ask the community to give the node operators and development teams time to complete a thorough investigation before drawing conclusions.
What we currently know:
- One of the six Asgard vaults appears to have been compromised.
- Current estimates place the loss at approximately $7.4m USD.
- The network automatically detected the abnormal behavior and halted signing activity, which alerted the broader community and prevented further outbound activity.
- Node operators securing the vault maintain bonded RUNE which is subject to slashing in the event of unauthorized outbound transactions.
- Churn activity has been paused while the investigation is ongoing and remediation steps are evaluated.
- As a result, onboarding of additional chains and any operations requiring churns will be delayed until the network is stabilized.
At this stage, the root cause has not yet been determined.
Current areas under investigation include:
- A potential vulnerability in the GG20 implementation layer
- Infrastructure or operational compromise affecting a sufficient number of nodes
- Other attack vectors that could have enabled unauthorized signing activity
At this time, we do not have evidence supporting any specific conclusion, and we want to avoid premature assumptions until the investigation is complete.
We are asking all node operators to immediately review their infrastructure, hosts, key management systems, and operational security for any signs of compromise or abnormal behavior, and to report anything suspicious to the dev team.
Additionally, node operators participating in the affected vault are requested to securely provide Bifrost logs to the dev team for analysis using `make relay`.
We will continue to provide updates as we learn more.
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
🚨 ALERT 🚨
Developers and THORSec have been investigating today’s incident continuously throughout the day. While new information may still emerge, I want to provide the community with an update based on what we currently know.
The goal of this update is to clarify the current understanding of the situation as accurately and transparently as possible.
A newly churned node, thor16ucjv3v695mq283me7esh0wdhajjalengcn84q, which entered the network several days ago, is currently believed to be associated with the attack. Developers have identified links between Ethereum addresses used to acquire and bond RUNE for this node, and Ethereum addresses that later received the stolen funds. Based on current evidence, it is believed this was conducted by a single malicious operator, though the investigation remains ongoing.
At this time, the leading theory is the attacker exploited a vulnerability within the GG20 TSS implementation which allowed sensitive key material from vault participants to leak over time. By accumulating enough leaked information, the attacker was ultimately able to reconstruct the vault’s TSS private key and execute unauthorized outbound transactions.
The Treasury is actively collecting forensic data and coordinating with Outrider Analytics and relevant law enforcement agencies in an effort to identify the attacker and pursue recovery of stolen funds where possible.
Due to multiple node operators executing make pause, the network is currently paused. Unless further action is taken, the pause state will automatically expire in approximately 12 hours. At this time, the development team is comfortable allowing the pause to expire in order to restore RUNE transfers and chain observation activity.
However, trading, signing, LP actions, and other sensitive operations will remain paused until the network and community align on a comprehensive recovery and remediation plan.
The recovery process will likely require node governance decisions regarding how losses are ultimately handled. Several potential approaches are already being discussed, including:
Slashing the bond of nodes participating in the affected vault
Allowing Protocol-Owned Liquidity (POL) to absorb the loss
Additional recovery proposals that may emerge from the broader community
At this stage, no final decisions have been made.
The team is continuing to work on a complete recovery and restart plan for the network. Bringing trading and full functionality back online will likely take several days, and potentially longer depending on the complexity of the chosen remediation path.
We will continue to provide updates as more information becomes available.
Finally, I want to thank the developers, node operators, security contributors, and the broader THORChain community for the enormous amount of work done today. One of THORChain’s greatest strengths has always been the community’s ability to come together under pressure, collaborate quickly, and solve difficult problems together.
🚨 ALERT 🚨
Developers and THORSec have been investigating today’s incident continuously throughout the day. While new information may still emerge, I want to provide the community with an update based on what we currently know.
The goal of this update is to clarify the current understanding of the situation as accurately and transparently as possible.
A newly churned node, thor16ucjv3v695mq283me7esh0wdhajjalengcn84q, which entered the network several days ago, is currently believed to be associated with the attack. Developers have identified links between Ethereum addresses used to acquire and bond RUNE for this node, and Ethereum addresses that later received the stolen funds. Based on current evidence, it is believed this was conducted by a single malicious operator, though the investigation remains ongoing.
At this time, the leading theory is the attacker exploited a vulnerability within the GG20 TSS implementation which allowed sensitive key material from vault participants to leak over time. By accumulating enough leaked information, the attacker was ultimately able to reconstruct the vault’s TSS private key and execute unauthorized outbound transactions.
The Treasury is actively collecting forensic data and coordinating with Outrider Analytics and relevant law enforcement agencies in an effort to identify the attacker and pursue recovery of stolen funds where possible.
Due to multiple node operators executing make pause, the network is currently paused. Unless further action is taken, the pause state will automatically expire in approximately 12 hours. At this time, the development team is comfortable allowing the pause to expire in order to restore RUNE transfers and chain observation activity.
However, trading, signing, LP actions, and other sensitive operations will remain paused until the network and community align on a comprehensive recovery and remediation plan.
The recovery process will likely require node governance decisions regarding how losses are ultimately handled. Several potential approaches are already being discussed, including:
Slashing the bond of nodes participating in the affected vault
Allowing Protocol-Owned Liquidity (POL) to absorb the loss
Additional recovery proposals that may emerge from the broader community
At this stage, no final decisions have been made.
The team is continuing to work on a complete recovery and restart plan for the network. Bringing trading and full functionality back online will likely take several days, and potentially longer depending on the complexity of the chosen remediation path.
We will continue to provide updates as more information becomes available.
Finally, I want to thank the developers, node operators, security contributors, and the broader THORChain community for the enormous amount of work done today. One of THORChain’s greatest strengths has always been the community’s ability to come together under pressure, collaborate quickly, and solve difficult problems together.
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
Hello THORChads,
The developers and thorsec teams have been hard at work throughout the weekend continuing the investigation to fully understand the events that took place, while also planning the road to recovery. I wanted to provide an update to keep the community informed as we move forward. It is important to note that the investigation is still ongoing, and details may change in the coming days as we continue to gather information and adjust plans accordingly.
At this time, the team has a strong understanding of what occurred and how the attack was executed, though we are not yet in a position to publicly discuss the technical details. What we can say is that the attack vector does not appear to be related to any currently known GG20 exploits, and at this stage we are still assessing whether other GG20 implementations could also be at risk. The team will continue investigating this possibility and will coordinate with other affected teams as appropriate.
We would also like to thank the many cryptographers and security researchers who assisted throughout this process, including members of the team that originally developed GG20.
The team currently expects to release version 3.18.1 tomorrow for node operators to adopt. We ask that all node operators upgrade to this release as soon as possible.
There is also an open question regarding the best approach for handling the lost funds within the network. This will need to be discussed and ultimately decided by the community through governance. To facilitate this discussion, I have created the channel <#1505953830796263424> .
Before the network can return to a fully healthy state, we will need broad consensus on this ADR, after which the selected approach will be implemented as part of the 3.19 release. THORChads are encouraged to share well-structured and thoughtful proposals for the community to support or challenge. In the coming days, we will organize a vote highlighting the most widely supported approaches for node operators to actively vote on.
Regarding the future direction of the cryptographic systems used to secure the vaults, that discussion is still ongoing and requires additional research before any long-term decisions are made. For the immediate future, the team is currently leaning toward remaining on GG20 in order to restore network health and stability as quickly and safely as possible. Longer-term discussions around the future of THORChain’s cryptographic security model will continue once the network has stabilized.
As always, I am proud of how both the team and the community have handled this situation. We will get everything running again as soon as we can, but we are not going to rush the process. THORChain has a strong roadmap ahead, and I am excited for us to return our focus to continuing to push the envelope of what this project can achieve.
Onwards to Valhalla
Hello THORChads,
The developers and thorsec teams have been hard at work throughout the weekend continuing the investigation to fully understand the events that took place, while also planning the road to recovery. I wanted to provide an update to keep the community informed as we move forward. It is important to note that the investigation is still ongoing, and details may change in the coming days as we continue to gather information and adjust plans accordingly.
At this time, the team has a strong understanding of what occurred and how the attack was executed, though we are not yet in a position to publicly discuss the technical details. What we can say is that the attack vector does not appear to be related to any currently known GG20 exploits, and at this stage we are still assessing whether other GG20 implementations could also be at risk. The team will continue investigating this possibility and will coordinate with other affected teams as appropriate.
We would also like to thank the many cryptographers and security researchers who assisted throughout this process, including members of the team that originally developed GG20.
The team currently expects to release version 3.18.1 tomorrow for node operators to adopt. We ask that all node operators upgrade to this release as soon as possible.
There is also an open question regarding the best approach for handling the lost funds within the network. This will need to be discussed and ultimately decided by the community through governance. To facilitate this discussion, I have created the channel <#1505953830796263424> .
Before the network can return to a fully healthy state, we will need broad consensus on this ADR, after which the selected approach will be implemented as part of the 3.19 release. THORChads are encouraged to share well-structured and thoughtful proposals for the community to support or challenge. In the coming days, we will organize a vote highlighting the most widely supported approaches for node operators to actively vote on.
Regarding the future direction of the cryptographic systems used to secure the vaults, that discussion is still ongoing and requires additional research before any long-term decisions are made. For the immediate future, the team is currently leaning toward remaining on GG20 in order to restore network health and stability as quickly and safely as possible. Longer-term discussions around the future of THORChain’s cryptographic security model will continue once the network has stabilized.
As always, I am proud of how both the team and the community have handled this situation. We will get everything running again as soon as we can, but we are not going to rush the process. THORChain has a strong roadmap ahead, and I am excited for us to return our focus to continuing to push the envelope of what this project can achieve.
Onwards to Valhalla
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
Hello Thorchads!
We ask all active validators to please scale down their bifrost pods, **from now until 3.18.1 patch is live**. We request this in an abundance of caution while vulnerabilities are identified and patched.
```
make pull
make scale-down
# choose bifrost
```
> If you have trouble scaling down your bifrost pod, please reach out to devs via make relay or on discord.
Thank you for your cooperation!
@everyone
Hello Thorchads!
We ask all active validators to please scale down their bifrost pods, **from now until 3.18.1 patch is live**. We request this in an abundance of caution while vulnerabilities are identified and patched.
```
make pull
make scale-down
# choose bifrost
```
> If you have trouble scaling down your bifrost pod, please reach out to devs via make relay or on discord.
Thank you for your cooperation!
@everyone
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
THORNODE ❗️MAINNET❗️UPDATE 3.18.1
https://gitlab.com/thorchain/thornode/-/releases/v3.18.1
NETWORK: MAINNET
TYPE: Non-coordianted
URGENCY: ASAP
This is a Bifrost-only patch containing a fix to ensure bifrost-internal signing flows honour the HALTSIGNING / HaltSigning switches.
```
make scale-up -> bifrost
make pull
make install
```
@everyone
THORNODE ❗️MAINNET❗️UPDATE 3.18.1
https://gitlab.com/thorchain/thornode/-/releases/v3.18.1
NETWORK: MAINNET
TYPE: Non-coordianted
URGENCY: ASAP
This is a Bifrost-only patch containing a fix to ensure bifrost-internal signing flows honour the HALTSIGNING / HaltSigning switches.
```
make scale-up -> bifrost
make pull
make install
```
@everyone
GitLab
v3.18.1 · THORChain / THORNode · GitLab
This is a Bifrost-only patch containing a fix to ensure bifrost-internal signing flows honour the HALTSIGNING / HaltSigning switches. Changelog [fix]...
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
THORNODE ❗️MAINNET❗️UPDATE 3.18.1
https://gitlab.com/thorchain/thornode/-/releases/v3.18.1
NETWORK: MAINNET
TYPE: Non-coordianted
URGENCY: ASAP
This is a Bifrost-only patch containing a fix to ensure bifrost-internal signing flows honour the HALTSIGNING / HaltSigning switches.
```
make scale-up ->bifrost
make pull
make install
```
@everyone
THORNODE ❗️MAINNET❗️UPDATE 3.18.1
https://gitlab.com/thorchain/thornode/-/releases/v3.18.1
NETWORK: MAINNET
TYPE: Non-coordianted
URGENCY: ASAP
This is a Bifrost-only patch containing a fix to ensure bifrost-internal signing flows honour the HALTSIGNING / HaltSigning switches.
```
make scale-up ->bifrost
make pull
make install
```
@everyone
GitLab
v3.18.1 · THORChain / THORNode · GitLab
This is a Bifrost-only patch containing a fix to ensure bifrost-internal signing flows honour the HALTSIGNING / HaltSigning switches. Changelog [fix]...
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
## THORNODE ❗️MAINNET❗️ HALT SECURED + TRADE ASSETS
NETWORK: MAINNET
TYPE: Coordinated (3 votes only)
URGENCY: ASAP
Close the secured asset and trade asset surfaces while the tss-lib patch lands. Complements the existing *HALTTRADING* / *HALTSIGNING* / *STOPSOLVENCYCHECK* halts already in effect. Operational mimirs — only 3 votes needed each to set.
Note: HALTSECUREDGLOBAL is currently unset; TRADEACCOUNTSENABLED is currently 1 (flip to 0 to halt).
```
MIMIR_KEY=HALTSECUREDGLOBAL MIMIR_VALUE=1 make mimir
MIMIR_KEY=TRADEACCOUNTSENABLED MIMIR_VALUE=0 make mimir
```
@everyone
## THORNODE ❗️MAINNET❗️ HALT SECURED + TRADE ASSETS
NETWORK: MAINNET
TYPE: Coordinated (3 votes only)
URGENCY: ASAP
Close the secured asset and trade asset surfaces while the tss-lib patch lands. Complements the existing *HALTTRADING* / *HALTSIGNING* / *STOPSOLVENCYCHECK* halts already in effect. Operational mimirs — only 3 votes needed each to set.
Note: HALTSECUREDGLOBAL is currently unset; TRADEACCOUNTSENABLED is currently 1 (flip to 0 to halt).
```
MIMIR_KEY=HALTSECUREDGLOBAL MIMIR_VALUE=1 make mimir
MIMIR_KEY=TRADEACCOUNTSENABLED MIMIR_VALUE=0 make mimir
```
@everyone
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
THORNODE ❗️MAINNET❗️ BAN NODE
NETWORK: MAINNET
TYPE: Coordinated
URGENCY: ASAP
Vote to ban this node (⅔ supermajority required — 63 of 93 active nodes):
```
make pull
make ban
# at the prompt enter: thor16ucjv3v695mq283me7esh0wdhajjalengcn84q
# the script will confirm:
# address : thor16ucjv...cn84q
# ip : 64.95.10.143
# slash : 195222
# operator : thor16ucjv...cn84q (self-bonded)
# confirm y → broadcast
```
@everyone
THORNODE ❗️MAINNET❗️ BAN NODE
NETWORK: MAINNET
TYPE: Coordinated
URGENCY: ASAP
Vote to ban this node (⅔ supermajority required — 63 of 93 active nodes):
```
make pull
make ban
# at the prompt enter: thor16ucjv3v695mq283me7esh0wdhajjalengcn84q
# the script will confirm:
# address : thor16ucjv...cn84q
# ip : 64.95.10.143
# slash : 195222
# operator : thor16ucjv...cn84q (self-bonded)
# confirm y → broadcast
```
@everyone
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
THORNODE ❗️MAINNET❗️UPDATE 3.18.2
https://gitlab.com/thorchain/thornode/-/releases/v3.18.2
NETWORK: MAINNET
TYPE: Non-coordianted
URGENCY: ASAP
This is a Bifrost-only patch containing a fix to repair dead unhealthy-scanner solvency guard
and adding per-chain floor block height for bifrost scanner + remove dead block-status ledger.
```
make update
```
@everyone
THORNODE ❗️MAINNET❗️UPDATE 3.18.2
https://gitlab.com/thorchain/thornode/-/releases/v3.18.2
NETWORK: MAINNET
TYPE: Non-coordianted
URGENCY: ASAP
This is a Bifrost-only patch containing a fix to repair dead unhealthy-scanner solvency guard
and adding per-chain floor block height for bifrost scanner + remove dead block-status ledger.
```
make update
```
@everyone
GitLab
v3.18.2 · THORChain / THORNode · GitLab
This is a Bifrost-only patch containing a fix to repair dead unhealthy-scanner solvency guard. Changelog
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
# Mainnet 3.19.0 Upgrade Proposal - Validators Only
Changelog: https://gitlab.com/thorchain/thornode/-/releases/v3.19.0
Block: 26518000
Date: <t:1780968360:F> (June 9, 2026 01:26 UTC) - https://runescan.io/block/26518000
Note: Block time is an estimate and may fluctuate.
URGENCY: 3 days
> Please note that this release is a private image containing a security patch. Any nodes that wish to review the patch can relay an `age` public key and one of the devs or THORSec will reply with an encrypted patch and instructions to verify the reproducible build hash.
Release 3.19.0 ships our TSS patches which will be disclosed once we proceed through the chain recovery as well as the store migration that will conciliate the economical fallout of the hack for which you can see the details in https://adr28.thorchain.org. This version also includes a new method to handle compromised vaults through the operational mimir `CompromisedVault-<pubkey>` which avoids scheduling, signing and overall transaction processing — while still observing the actual transactions — for the vault specified in the mimir pubkey.
The full network recovery plan is as follows:
1. Vote to approve release 3.19.0.
2. Upgrade the network on Monday.
3. Enable the `CompromisedVault-thorpub1addwnpepqvpnhwzqkd2zqkxsj272faf4ezsngwh773wjdfkus8m4f860u3g5ka22v28` mimir to quarantine the compromised vault.
4. Validate the ADR-028 store migration (Maya team).
5. Verify the integrity of every node's keyshares via the new temporary `keyverify` protocol (Maya team).
6. Unhalt signing.
7. Initiate the churn.
8. Wait for churn to finish
9. Unhalt Secured and Trade assets
10. Unhalt LP actions
11. Unhalt trading
Please approve via `make upgrade-vote`:
Select: `mainnet`
Enter THORNode name: <thornode namespace>
Enter THORNode upgrade proposal name: `3.19.0`
Select THORNode upgrade proposal vote: `yes`
@everyone
# Mainnet 3.19.0 Upgrade Proposal - Validators Only
Changelog: https://gitlab.com/thorchain/thornode/-/releases/v3.19.0
Block: 26518000
Date: <t:1780968360:F> (June 9, 2026 01:26 UTC) - https://runescan.io/block/26518000
Note: Block time is an estimate and may fluctuate.
URGENCY: 3 days
> Please note that this release is a private image containing a security patch. Any nodes that wish to review the patch can relay an `age` public key and one of the devs or THORSec will reply with an encrypted patch and instructions to verify the reproducible build hash.
Release 3.19.0 ships our TSS patches which will be disclosed once we proceed through the chain recovery as well as the store migration that will conciliate the economical fallout of the hack for which you can see the details in https://adr28.thorchain.org. This version also includes a new method to handle compromised vaults through the operational mimir `CompromisedVault-<pubkey>` which avoids scheduling, signing and overall transaction processing — while still observing the actual transactions — for the vault specified in the mimir pubkey.
The full network recovery plan is as follows:
1. Vote to approve release 3.19.0.
2. Upgrade the network on Monday.
3. Enable the `CompromisedVault-thorpub1addwnpepqvpnhwzqkd2zqkxsj272faf4ezsngwh773wjdfkus8m4f860u3g5ka22v28` mimir to quarantine the compromised vault.
4. Validate the ADR-028 store migration (Maya team).
5. Verify the integrity of every node's keyshares via the new temporary `keyverify` protocol (Maya team).
6. Unhalt signing.
7. Initiate the churn.
8. Wait for churn to finish
9. Unhalt Secured and Trade assets
10. Unhalt LP actions
11. Unhalt trading
Please approve via `make upgrade-vote`:
Select: `mainnet`
Enter THORNode name: <thornode namespace>
Enter THORNode upgrade proposal name: `3.19.0`
Select THORNode upgrade proposal vote: `yes`
@everyone
GitLab
v3.19.0 · THORChain / THORNode · GitLab
Proposed Block: 26518000 Date: Tuesday, June 9, 2026 01:26 UTC - https://runescan.io/block/26518000 Note: Block...
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
# Mimir Vote for Compromised Vault — Active Validators Only
Following step three from https://discord.com/channels/838986635756044328/839001804812451873/1512583315339739257 we now need to vote to disable the compromised vault.
```
❯ make mimir
=> Enter THORNode Mimir key:
```
Enter the value
```
CompromisedVault-thorpub1addwnpepqvpnhwzqkd2zqkxsj272faf4ezsngwh773wjdfkus8m4f860u3g5ka22v28
```
Set value to 1
```
=> Enter THORNode Mimir value: 1
```
@everyone
# Mimir Vote for Compromised Vault — Active Validators Only
Following step three from https://discord.com/channels/838986635756044328/839001804812451873/1512583315339739257 we now need to vote to disable the compromised vault.
```
❯ make mimir
=> Enter THORNode Mimir key:
```
Enter the value
```
CompromisedVault-thorpub1addwnpepqvpnhwzqkd2zqkxsj272faf4ezsngwh773wjdfkus8m4f860u3g5ka22v28
```
Set value to 1
```
=> Enter THORNode Mimir value: 1
```
@everyone
Discord
Discord - Group Chat That’s All Fun & Games
Discord is great for playing games and chilling with friends, or even building a worldwide community. Customize your own space to talk, play, and hang out.
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
<:alert:1143254456893456485> **THORNode Halted at 3.19.0 Upgrade Height — Action Required (Affected Validators)**
**NETWORK:** MAINNET
**TYPE:** Per-validator action (non-coordinated)
**URGENCY:** ASAP for affected nodes
These nodes are dead weight on consensus (network at ~89% signed) and block the recovery plan — keyverify (step 5) and the upcoming churn (step 7) need every active node healthy.
**Affected nodes:** `kwex` `0rde` `rsyj` `skf6` `nk4j` `vwj0` (thornode down, host up) and `69mz` (host fully unreachable—operator must restore the machine first)
If you operate one of these, pull the latest node-launcher and re-deploy to pick up the 3.19.0 image:
```
make pull
```
```
make install
```
Your node will catch up the ~18k missed blocks in well under an hour. Once all 7 are signing again we can proceed with the keyverify ceremony and the rest of the recovery.
@everyone
<:alert:1143254456893456485> **THORNode Halted at 3.19.0 Upgrade Height — Action Required (Affected Validators)**
**NETWORK:** MAINNET
**TYPE:** Per-validator action (non-coordinated)
**URGENCY:** ASAP for affected nodes
These nodes are dead weight on consensus (network at ~89% signed) and block the recovery plan — keyverify (step 5) and the upcoming churn (step 7) need every active node healthy.
**Affected nodes:** `kwex` `0rde` `rsyj` `skf6` `nk4j` `vwj0` (thornode down, host up) and `69mz` (host fully unreachable—operator must restore the machine first)
If you operate one of these, pull the latest node-launcher and re-deploy to pick up the 3.19.0 image:
```
make pull
```
```
make install
```
Your node will catch up the ~18k missed blocks in well under an hour. Once all 7 are signing again we can proceed with the keyverify ceremony and the rest of the recovery.
@everyone
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
# THORNODE ❗ MAINNET ❗ SUCESSFUL CHURN - NEED 1 MORE VOTE — HALT CHURNING
We're at 2 of 3 operational votes to halt churning for the migration — need one more node to vote:
> This is to avoid any clashing while we migrate and test the new TSS changes that have been made
```
make mimir
```
key `HALTCHURNING` value `1`
@everyone
# THORNODE ❗ MAINNET ❗ SUCESSFUL CHURN - NEED 1 MORE VOTE — HALT CHURNING
We're at 2 of 3 operational votes to halt churning for the migration — need one more node to vote:
> This is to avoid any clashing while we migrate and test the new TSS changes that have been made
```
make mimir
```
key `HALTCHURNING` value `1`
@everyone
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
# THORNODE ❗ MAINNET ❗ MIMIR VOTE — UNHALT SIGNING (GLOBAL)
**NETWORK:** MAINNET
**TYPE:** Coordinated
**URGENCY:** ASAP
The churn has rotated and the retiring vaults need to migrate funds into the new ones — that needs signing back on. Please vote to un-halt global signing. Operational mimir, so only the small quorum (3 nodes) is needed.
```
make mimir
```
key: `HALTSIGNING` value: `0`
@everyone
# THORNODE ❗ MAINNET ❗ MIMIR VOTE — UNHALT SIGNING (GLOBAL)
**NETWORK:** MAINNET
**TYPE:** Coordinated
**URGENCY:** ASAP
The churn has rotated and the retiring vaults need to migrate funds into the new ones — that needs signing back on. Please vote to un-halt global signing. Operational mimir, so only the small quorum (3 nodes) is needed.
```
make mimir
```
key: `HALTSIGNING` value: `0`
@everyone
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
# THORNODE ❗ MAINNET ❗ MIMIR VOTE — UN-HALT SECURED + ENABLE TRADE ASSETS
**NETWORK:** MAINNET
**TYPE:** Coordinated (operational mimir vote)
**URGENCY:** ASAP
Recovery step — re-opening secured-asset and trade-asset trading.
```
make mimir
```
key: `HALTSECUREDGLOBAL` value: `0`
key: `TRADEACCOUNTSENABLED` value: `1`
Both are operational mimirs — ~3 active-node votes each (vote the same value; land them together, votes purge on churn).
@everyone
# THORNODE ❗ MAINNET ❗ MIMIR VOTE — UN-HALT SECURED + ENABLE TRADE ASSETS
**NETWORK:** MAINNET
**TYPE:** Coordinated (operational mimir vote)
**URGENCY:** ASAP
Recovery step — re-opening secured-asset and trade-asset trading.
```
make mimir
```
key: `HALTSECUREDGLOBAL` value: `0`
key: `TRADEACCOUNTSENABLED` value: `1`
Both are operational mimirs — ~3 active-node votes each (vote the same value; land them together, votes purge on churn).
@everyone
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
# THORNODE ❗ MAINNET ❗ MIMIR VOTE — UN-HALT GLOBAL TRADING
**NETWORK:** MAINNET
**TYPE:** Coordinated (mimir vote)
**URGENCY:** ASAP
Next recovery step — re-opening global trading. All per-chain trading halts are already 0, and secured + trade assets are enabled; the only remaining gate is the global HALTTRADING. Vote it to 0 to reopen swaps.
```
make mimir
```
key: `HALTTRADING` value: `0`
Operational mimir — ~3 active-node votes (vote the same value; votes purge on churn, so land them together).
@everyone
# THORNODE ❗ MAINNET ❗ MIMIR VOTE — UN-HALT GLOBAL TRADING
**NETWORK:** MAINNET
**TYPE:** Coordinated (mimir vote)
**URGENCY:** ASAP
Next recovery step — re-opening global trading. All per-chain trading halts are already 0, and secured + trade assets are enabled; the only remaining gate is the global HALTTRADING. Vote it to 0 to reopen swaps.
```
make mimir
```
key: `HALTTRADING` value: `0`
Operational mimir — ~3 active-node votes (vote the same value; votes purge on churn, so land them together).
@everyone
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
## DISABLE BIFROST KEYVERIFY
**NETWORK:** MAINNET
**TYPE:** Non-coordinated
**URGENCY:** ASAP
ECDSA migration is complete — bifrost keyverify is no longer needed, and leaving it on only makes nodes periodically drop availability (~every 10 min) and risk extra slashing. Node-launcher now disables it by default; please pull the latest and redeploy to pick it up (restarts bifrost):
```
make pull
make install
```
Restart-required, local-only — it does NOT halt signing/observing or affect keyverify elsewhere. (To keep keyverify on, set `BIFROST_SIGNER_KEYVERIFY_DISABLED: "false"`.)
@everyone
## DISABLE BIFROST KEYVERIFY
**NETWORK:** MAINNET
**TYPE:** Non-coordinated
**URGENCY:** ASAP
ECDSA migration is complete — bifrost keyverify is no longer needed, and leaving it on only makes nodes periodically drop availability (~every 10 min) and risk extra slashing. Node-launcher now disables it by default; please pull the latest and redeploy to pick it up (restarts bifrost):
```
make pull
make install
```
Restart-required, local-only — it does NOT halt signing/observing or affect keyverify elsewhere. (To keep keyverify on, set `BIFROST_SIGNER_KEYVERIFY_DISABLED: "false"`.)
@everyone
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
## MIMIR VOTE — UNHALT TCY CLAIMING
**NETWORK:** MAINNET
**TYPE:** Coordinated (mimir vote)
**URGENCY:** ASAP
TCY claiming has been halted (`TCYCLAIMINGHALT=1`) since the claiming fix landed; that patch has been live on mainnet since v3.18.0 (current mainnet 3.19.1), so claiming can safely resume. Vote to clear the halt:
```
make mimir
```
key: `TCYCLAIMINGHALT` value: `0`
Operational mimir — clears once ~3 active nodes vote `0` (operational quorum, not a full supermajority).
@everyone
## MIMIR VOTE — UNHALT TCY CLAIMING
**NETWORK:** MAINNET
**TYPE:** Coordinated (mimir vote)
**URGENCY:** ASAP
TCY claiming has been halted (`TCYCLAIMINGHALT=1`) since the claiming fix landed; that patch has been live on mainnet since v3.18.0 (current mainnet 3.19.1), so claiming can safely resume. Vote to clear the halt:
```
make mimir
```
key: `TCYCLAIMINGHALT` value: `0`
Operational mimir — clears once ~3 active nodes vote `0` (operational quorum, not a full supermajority).
@everyone
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
# THORNODE ❗ MAINNET ❗ BASE daemon — v1.1.1 (fork)
**NETWORK:** MAINNET
**TYPE:** Non-coordinated
**URGENCY:** ASAP
base-daemon is updated to **v1.1.1**. If you self-host a BASE daemon, pull node-launcher and redeploy:
```
make pull
make install
```
Base hardforked at L2 block **47806543** (~16:00 UTC today). Daemons not on v1.1.1 stall at that block and stop observing/signing BASE — update now to cross the fork. (Base release: github.com/base/node/releases/tag/v1.1.1)
@everyone
# THORNODE ❗ MAINNET ❗ BASE daemon — v1.1.1 (fork)
**NETWORK:** MAINNET
**TYPE:** Non-coordinated
**URGENCY:** ASAP
base-daemon is updated to **v1.1.1**. If you self-host a BASE daemon, pull node-launcher and redeploy:
```
make pull
make install
```
Base hardforked at L2 block **47806543** (~16:00 UTC today). Daemons not on v1.1.1 stall at that block and stop observing/signing BASE — update now to cross the fork. (Base release: github.com/base/node/releases/tag/v1.1.1)
@everyone
GitHub
Release v1.1.1 · base/node
What Changed
ImportantBase Mainnet: Operators must upgrade to this release by June 25th at 18:00:00 UTC for the Beryl hardfork. See here for more information.
Base Sepolia: Recommended upgrade to i...
ImportantBase Mainnet: Operators must upgrade to this release by June 25th at 18:00:00 UTC for the Beryl hardfork. See here for more information.
Base Sepolia: Recommended upgrade to i...
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
# 📢 Dynamic Fee Experiment Update & Expansion
I know we've had several announcements like this recently. We don't want to create churn for the community or node operators, but there has been a lot happening lately—which is both exciting and, at times, operationally challenging.
I wanted to provide a quick update on the Symbiosis experiment and announce that we're expanding the dynamic fee experiment to another affiliate: **ShapeShift** (`ss`).
---
## Symbiosis Update
We ran into an immediate issue with the Symbiosis rollout. Because we were receiving essentially **zero trading volume**, the dynamic fee mechanism never had an opportunity to "spin up."
This is a relatively small edge-case bug. Under normal conditions it isn't an issue, since it only takes a single swap for a given trading pair to initialize the feature. However, Symbiosis wasn't sending any swaps our way. We generally win larger trades ($50k–$100k+), which occur less frequently, so this left the experiment with no meaningful data.
While investigating, I also noticed an inefficiency in how Symbiosis routes swaps through THORChain that inflates our quoted price.
For example, for an **ETH → BTC** swap, Symbiosis currently:
1. Swaps **ETH → USDC** through Kyber or 0x.
2. Sends the resulting **USDC** to THORChain.
3. THORChain then swaps **USDC → BTC**.
This results in an unnecessary extra swap before reaching THORChain.
A more efficient flow would be to send **ETH directly** to THORChain and allow THORChain to perform the native double swap internally. This reduces unnecessary overhead and produces a more competitive quote.
This isn't an issue for Chainflip since **USDC is their base asset**, meaning they only perform a single swap.
I've opened a pull request in the Symbiosis codebase to address this. There's no ETA yet on when it will be reviewed, merged, or deployed.
In the meantime, it makes sense to continue the experiment with another affiliate that has meaningful flow.
---
## ShapeShift
ShapeShift has consistently been a strong partner for THORChain. Their team is responsive, cooperative, and easy to work with.
During **June**, THORChain captured **5.8%** of ShapeShift's routing volume, compared to:
- **Chainflip:** 54%
- **NEAR:** 33.4%
There is clearly meaningful volume available for THORChain to compete for here.
I'd like to ask **three node operators** to enable ShapeShift for this experiment using the following operational Mimir:
```text
DYNAMICFEE-WHITELIST-SS = 1
```
Since this is an operational Mimir, we only need **three nodes** to enable it.
Once enabled, we'll begin collecting data and evaluate how the dynamic fee performs within this specific routing market.
# 📢 Dynamic Fee Experiment Update & Expansion
I know we've had several announcements like this recently. We don't want to create churn for the community or node operators, but there has been a lot happening lately—which is both exciting and, at times, operationally challenging.
I wanted to provide a quick update on the Symbiosis experiment and announce that we're expanding the dynamic fee experiment to another affiliate: **ShapeShift** (`ss`).
---
## Symbiosis Update
We ran into an immediate issue with the Symbiosis rollout. Because we were receiving essentially **zero trading volume**, the dynamic fee mechanism never had an opportunity to "spin up."
This is a relatively small edge-case bug. Under normal conditions it isn't an issue, since it only takes a single swap for a given trading pair to initialize the feature. However, Symbiosis wasn't sending any swaps our way. We generally win larger trades ($50k–$100k+), which occur less frequently, so this left the experiment with no meaningful data.
While investigating, I also noticed an inefficiency in how Symbiosis routes swaps through THORChain that inflates our quoted price.
For example, for an **ETH → BTC** swap, Symbiosis currently:
1. Swaps **ETH → USDC** through Kyber or 0x.
2. Sends the resulting **USDC** to THORChain.
3. THORChain then swaps **USDC → BTC**.
This results in an unnecessary extra swap before reaching THORChain.
A more efficient flow would be to send **ETH directly** to THORChain and allow THORChain to perform the native double swap internally. This reduces unnecessary overhead and produces a more competitive quote.
This isn't an issue for Chainflip since **USDC is their base asset**, meaning they only perform a single swap.
I've opened a pull request in the Symbiosis codebase to address this. There's no ETA yet on when it will be reviewed, merged, or deployed.
In the meantime, it makes sense to continue the experiment with another affiliate that has meaningful flow.
---
## ShapeShift
ShapeShift has consistently been a strong partner for THORChain. Their team is responsive, cooperative, and easy to work with.
During **June**, THORChain captured **5.8%** of ShapeShift's routing volume, compared to:
- **Chainflip:** 54%
- **NEAR:** 33.4%
There is clearly meaningful volume available for THORChain to compete for here.
I'd like to ask **three node operators** to enable ShapeShift for this experiment using the following operational Mimir:
```text
DYNAMICFEE-WHITELIST-SS = 1
```
Since this is an operational Mimir, we only need **three nodes** to enable it.
Once enabled, we'll begin collecting data and evaluate how the dynamic fee performs within this specific routing market.
New Discord Announcement from THORChain Devs #🚨thornode-mainnet
## Mimir Vote Request: `STREAMINGLIMITSWAPMAXAGE = 5256000`
Requesting **3 node operators** to cast an operational Mimir vote.
| Field | Value |
|---|---|
| **Key** | `STREAMINGLIMITSWAPMAXAGE` |
| **New value** | `5256000` (~1 year) |
| **Current default** | `43200` (~3 days) |
| **Votes needed** | 3 (`OperationalVotesMin`) |
### What it does
Raises the max lifetime of a limit swap from ~3 days to ~1 year. Long-dated limit orders are a frequently requested feature, and a 3-day ceiling is too short to be useful for most traders.
### Why it's safe now
The previous blocker was performance: `processExpiredLimitSwaps` scanned every height from `currentHeight - maxAge` forward on each block, so a 1-year TTL meant millions of KVStore lookups per block.
That was fixed — expiry entries are stored at their exact expiry height, so the handler now does a **single lookup for the current block**. Cost per block is constant regardless of how large this value is.
### No admin key or hard fork required
`StreamingLimitSwapMaxAge` is in the operational-mimir list, so three matching node votes activate it.
### How to vote
From your node-launcher directory:
```bash
make mimir
Enter when prompted:
- Key: STREAMINGLIMITSWAPMAXAGE
- Value: 5256000
```
## Mimir Vote Request: `STREAMINGLIMITSWAPMAXAGE = 5256000`
Requesting **3 node operators** to cast an operational Mimir vote.
| Field | Value |
|---|---|
| **Key** | `STREAMINGLIMITSWAPMAXAGE` |
| **New value** | `5256000` (~1 year) |
| **Current default** | `43200` (~3 days) |
| **Votes needed** | 3 (`OperationalVotesMin`) |
### What it does
Raises the max lifetime of a limit swap from ~3 days to ~1 year. Long-dated limit orders are a frequently requested feature, and a 3-day ceiling is too short to be useful for most traders.
### Why it's safe now
The previous blocker was performance: `processExpiredLimitSwaps` scanned every height from `currentHeight - maxAge` forward on each block, so a 1-year TTL meant millions of KVStore lookups per block.
That was fixed — expiry entries are stored at their exact expiry height, so the handler now does a **single lookup for the current block**. Cost per block is constant regardless of how large this value is.
### No admin key or hard fork required
`StreamingLimitSwapMaxAge` is in the operational-mimir list, so three matching node votes activate it.
### How to vote
From your node-launcher directory:
```bash
make mimir
Enter when prompted:
- Key: STREAMINGLIMITSWAPMAXAGE
- Value: 5256000
```