#thorchain Community Insights & Market Sentiment

#THORChain #DeFi安全 $RUNE If a protocol can pause service when it comes under attack, does that mean it can also stop stolen funds on behalf of others? The debate between THORChain and OKX Star is a good opportunity to separate three questions: who can move funds, who can pause, and what pausing can actually solve.

My view is this: cross-chain protocols should clearly define both intervention powers and trigger rules. Saying everything is explained by “decentralization” is not enough to define the boundaries of responsibility; but simply pointing to a past shutdown and concluding that stolen funds can now be precisely recovered also goes beyond the evidence.

First, let’s get the timeline straight. At 02:17 on September 27 Beijing time, THORChain posted on X about the recent attack, emphasizing that it is decentralized and permissionless, like Bitcoin, Ethereum, and BNB Chain. At 02:57, Star responded with a rebuttal: the validators jointly control the TSS vault, and once the signature threshold is met, the underlying assets can be moved. Odaily followed up this morning. The reporting time differs from the time of the statements made by both sides; this update set does not mean another attack occurred.

The key point is that open access and asset custody answer two different questions. According to THORChain’s official documentation, cross-chain swaps involve vaults on external chains, with multiple nodes jointly handling withdrawals through threshold signatures. No single participant has full control, which is the point of distributed control; but users still need to understand the vault and node mechanism. “No account needed” cannot be directly interpreted as “there is no additional custody or execution risk at all.”

The second easily confused issue is pausing versus recovery. The official developer documentation separately lists controls such as pausing trading, stopping withdrawal signing, and pausing a specific external chain. Stopping signing can cause withdrawals to queue; pausing the service may also affect normal users. These capabilities show that the protocol has emergency measures, but they do not by themselves prove that there is a button that can freeze only specific stolen funds and retrieve assets that have already left the vault.

History provides a reference, but it cannot replace evidence in this case. THORChain’s Q2 report records that after a vault attack on May 15, automatic checks and node actions sequentially triggered a pause, with service resuming on June 22. That case was mainly about stopping the protocol’s own vulnerability from causing further losses. An external theft case also involves address attribution, standards of evidence, the scope of intervention, and timing of execution, so the two scenarios cannot be treated as identical.

So what I’d like to see next is a verifiable incident-handling explanation: which controls are available now, who can trigger them, what evidence is required, how many normal transactions would be affected, and whether the decision can be publicly audited. For swap users and liquidity providers, that information is much more useful than the labels each side attaches to the other. It determines how long your transaction may be delayed in a dispute, and who is deciding that delay.

If future disclosures can demonstrate an effective, auditable intervention mechanism that targets only specific funds without affecting unrelated users, I would revise my view that intervention mainly depends on broad-scope pause measures. Before that, we should not infer “not yet recovered” as “actively assisting,” and even less should we derive RUNE price movements directly from this dispute.

If intercepting suspected stolen funds requires pausing normal swaps as well, would you rather accept pre-announced, uniformly enforced pause conditions, or keep a no-downtime principle and let centralized platforms where funds enter bear the responsibility for interception?

thorchain

Trending Topics