Summary
TechFlow reports that the FBI has asked THORChain node operators to help review and block funds linked to a recent Binance hack, while THORChain and Maya Protocol have continued to be portrayed as resisting transaction-level censorship. The dispute is testing where anti-money-laundering obligations, node-operator liability and permissionless finance meet.
A dispute over more than one protocol
According to a report published by TechFlow on November 2, 2026, the Federal Bureau of Investigation has asked THORChain node operators to assist with reviewing and blocking suspicious transactions connected to a recent Binance hacking incident. The report presents THORChain and its affiliated protocol, Maya Protocol, as among the few major cross-chain decentralized trading systems that have not publicly accepted transaction-level censorship in response to the request.
The available material is primarily a TechFlow report and commentary. It does not include a complete public copy of the alleged law-enforcement notice, nor does it provide independent confirmation of the request’s legal form, recipients or scope. Those details matter. A formal order, an informal request for cooperation and a public warning would create very different obligations for node operators. The claims should therefore be treated as reported developments pending additional documentation.
Even with that qualification, the dispute raises a broader question for permissionless finance: what happens when a protocol is designed to process transactions without discretionary approval, but the people operating its nodes remain identifiable individuals or entities subject to real-world law? The answer could shape how cross-chain infrastructure is built, operated and accessed by institutional users.
Should a DEX be responsible for stolen funds?
The immediate background is familiar across digital-asset markets. Attackers steal assets from a centralized exchange, bridge, application or wallet, then use on-chain venues to exchange those assets for other tokens or move them across networks. Law-enforcement agencies and victims may seek to slow that process through address blacklists, transaction refusals or asset freezes. Protocol advocates respond that a DEX did not necessarily participate in the original theft and may not have the account controls, customer relationship or administrative authority associated with a conventional financial intermediary.
Those positions reflect two different theories of responsibility. The first focuses on outcomes. If an infrastructure layer enables the rapid movement of criminal proceeds, its operators should arguably take reasonable steps to identify and restrict suspicious activity. This is broadly consistent with the expectations placed on many regulated financial institutions and service providers.
The second focuses on authority. If a protocol does not custody assets, open conventional accounts or maintain a central administrator capable of changing settlement outcomes, then requiring it to screen every transaction may effectively require the reintroduction of centralized control. From this perspective, an address blacklist is not merely a compliance feature. It changes the basic operating model of the network.
Neither theory resolves the issue by itself. Permissionless architecture does not automatically create immunity from legal obligations, and decentralization does not mean that no one can be identified. Developers, node operators, front-end providers, cloud hosts, governance participants and liquidity infrastructure may all occupy different legal and operational positions. Once authorities begin approaching those participants directly, code-level neutrality and real-world enforceability come into conflict.
The line drawn by THORChain and Maya
TechFlow says that other cross-chain systems, including NEAR Intents and Chainflip, have imposed restrictions on some stolen funds, while THORChain and Maya have not publicly made the same concession. The significance is not limited to whether a particular transfer can complete. The deeper issue is whether an external authority, a node operator or a governance process can selectively refuse transactions based on address labels or law-enforcement requests.
Supporters of censorship resistance argue that accepting an externally imposed blacklist turns a permissionless network into a conditional service. An address associated with a hack may be the immediate target, but the policy could later be extended to sanctioned entities, privacy tools, mixers or other users considered controversial by a particular jurisdiction. Once selective access is normalized, they argue, the boundaries may expand beyond the original case.
The opposing concern is equally practical. If a network refuses to respond to any suspicious-funds request, its node operators may face subpoenas, investigations, asset restrictions or criminal exposure. A protocol’s technical design cannot automatically absorb those consequences on behalf of the people who operate it. For institutional wallets, custodians and regulated financial firms, the ability to establish provenance, screen counterparties and preserve audit records may be more important than the theoretical availability of unrestricted routing.
That distinction is material for institutional custody. A custodian may be able to access a decentralized venue technically, yet still be unable to use it within internal policy if the venue does not provide adequate controls, documentation or incident-response procedures. Conversely, the presence of screening tools does not eliminate smart-contract, counterparty or operational risk. The practical question is increasingly whether a system can demonstrate responsible controls without creating a single party that can arbitrarily rewrite settlement.
Reliability can intensify the compliance problem
The TechFlow article also points to THORChain’s node count, outages and technical fragility as important parts of the debate. Discussions about permissionless finance often emphasize openness and censorship resistance, but continued use also depends on basic reliability: transactions must settle consistently, liquidity must remain available and users need a credible response when the network fails.
If ordinary users leave because of outages or unstable execution, high-risk activity could make up a larger proportion of the transactions that remain. The article refers to a “10% criminal-funds rule,” but the source material does not establish this as a universally recognized regulatory threshold. It is better understood as a warning scenario: if illicit or high-risk activity becomes a visibly significant share of a network’s usage, banks, custodians, analytics firms and infrastructure providers may respond by applying broader restrictions.
That response could isolate an entire network rather than resolve one disputed transaction. The question would then move from whether a node should honor a single request to whether the protocol can continue connecting to mainstream financial and technical services. This is especially relevant to institutions that require clear risk policies, transaction monitoring, segregation of duties and documented escalation procedures.
Engineering architecture also affects the trade-off. A more distributed system may reduce the risk that one administrator can censor users, but it can make upgrades, coordination and emergency response more difficult. A more concentrated model may handle incidents quickly while creating a clearer control point for regulators. Cross-chain systems therefore face a combined design problem involving security, availability, liability and access—not a binary choice between decentralization and compliance.
Possible paths for cross-chain infrastructure
If pooled liquidity and identifiable node networks remain concentrated enforcement targets, developers may explore more fragmented approaches. These could include peer-to-peer intent matching, non-pooled liquidity, layered routing or settlement arrangements in which users choose counterparties more directly. Such designs might reduce pressure on a single protocol to act as a universal screening gate.
They would not remove the underlying risks. Money laundering, fraud, malicious routing, smart-contract vulnerabilities and user-protection problems could move to solvers, front-end operators, wallet providers, data services or individual users. A fragmented architecture may also make accountability less clear and incident response more difficult. Reduced central control is not the same as reduced risk.
For institutional wallet and custody operations, the implications are concrete. Access decisions may increasingly depend on node geography, governance structure, transaction traceability, uptime, incident procedures and the ability to document source-of-funds risks. The label “decentralized” will not substitute for those assessments, just as a compliance interface will not eliminate protocol-level vulnerabilities.
It remains unclear whether THORChain and Maya will change their position, or whether authorities will take further action involving node operators, websites, code repositories or cloud infrastructure. Further public documentation will be needed to establish the facts. What is already clear is that cross-chain DEXs are no longer debating censorship resistance in isolation. They are confronting a combined institutional challenge involving anti-money-laundering expectations, cybersecurity, personal liability and the practical limits of open financial infrastructure. The future of permissionless finance will depend not only on whether a network can resist censorship, but also on whether it can remain secure, usable and accountable without recreating the centralized gatekeepers it was designed to avoid.
Source: link