A new report from Bybit’s Lazarus Security Lab suggests many major blockchains aren’t as trustless as they seem. In an industry built on decentralization, this looks suspicious.
Bybit’s researchers examined the codebases of 166 blockchains using AI-driven analysis plus manual review. They found that 16 networks already have built-in fund-freezing capabilities, and another 19 could enable them with only minor tweaks to their protocols.
While intended as a safeguard against hacks and illicit transfers, these findings have reignited a long-running question: how decentralized are the systems underpinning the crypto industry?
The investigation was spurred by a high-profile incident: earlier this year the Sui Foundation froze over $160 million in stolen assets after the Cetus DEX hack, a swift intervention that prompted intense debate.
If a foundation can block a hacker’s wallet to protect users, what’s to stop it from freezing anyone else’s?
This report comes on the heels of Bybit’s own security ordeal.
Just months ago, the exchange suffered a massive $1.5 billion hack, one of the largest in crypto history. In that case, centralized actors stepped in – partners like Circle and Tether froze about $42.9 million of stolen stablecoins, and other protocols helped recover additional funds.
The ability to hit pause in an emergency clearly has benefits. But it also underscores a paradox: the more crypto networks rely on such “kill switches” to contain threats, the more they begin to resemble the traditional centralized systems they aimed to replace.
Freezing Crypto Funds: Hack Defense vs. Decentralization Risk
On a blockchain, “freezing” an account means halting the movement of its funds – effectively rendering them immobile.
In practice, this is typically done by block producers (validators) or protocol rule changes that prevent a blacklisted address from transacting. Such emergency powers have emerged as a response to the rampant hacks and frauds plaguing DeFi.
The logic is straightforward: if thieves steal millions in crypto, stop them on-chain before they can launder it away.
For example, in the wake of the $160M Cetus exploit on Sui, the foundation swiftly implemented a deny-list at the protocol level to freeze the hacker’s wallets.
Likewise, BNB Chain’s developers hardcoded a blacklist to stop movement of $570M siphoned from a cross-chain bridge hack in 2022. Even as far back as 2019, VeChain enacted a similar blacklist after $6.6 million in tokens were stolen from its foundation’s wallet.
These interventions have proven pragmatically effective at containing losses.
“No one wants to see hundreds of millions vanish,” as one industry analyst noted.
By freezing stolen assets in place, projects buy time to investigate, recover funds, or negotiate with attackers. In Sui’s case, a community governance vote ultimately sanctioned the retrieval of the frozen Cetus hack funds, returning value to victims.
From a pure security standpoint, the ability to hit pause on transactions is a powerful tool in the disaster-response toolkit of blockchain operators.
However, the same power that can halt a heist can also undermine the core ethos of decentralization. Immutable, censorship-resistant transactions are supposed to be a foundational feature of public blockchains – “code is law.” The idea that a central group can retroactively stop or reverse transactions cuts against that principle.
Critics argue that if any authority can unilaterally freeze assets on a ledger, it calls into question the network’s neutrality.
After Sui’s emergency freeze, for instance, some in the community saw it as a “betrayal of decentralized ideals,” noting that an ostensibly permissionless network revealed a very permissioned control point. It raises uncomfortable questions: Who exactly has the authority to flip the kill switch on a “decentralized” chain? Under what circumstances? And could such powers be abused or expanded in the future?
The new Bybit report shines a light on this growing trade-off between security and sovereignty. Its key finding is that these freeze functions are not rare one-offs – they are more common (and quietly implemented) than most users realize. Out of 166 blockchains analyzed, 16 (nearly 10%) had native freeze mechanisms coded in. Crucially, those 16 include many of the world’s largest networks, which together account for over 80% of total DeFi value locked. In other words, the bulk of crypto activity today runs through systems that can be halted, filtered, or frozen by someone, at least under certain conditions. That reality clashes with the popular notion that blockchains are beyond anyone’s control.
From a governance perspective, the centralization risks are evident.
The Lazarus Lab researchers noted that nearly 70% of the freeze events they documented occurred at the validator or consensus layer – a deep level of the protocol not immediately visible to everyday users. In many cases these “emergency controls” were exercised by a small cohort of insiders: a project’s core developers, foundation council, or a group of top validators. Such entities are not always transparent in their decision-making. Unlike open blockchain code, these human governance processes often happen behind closed doors or on short notice.
That lack of visibility fuels the concern that trust is being reintroduced into supposedly trustless systems. As one observer put it, decentralization often ends where validator access begins.
How the Freeze Mechanisms Work
Bybit’s report identifies three main categories of on-chain freezing functionality.
Hardcoded Blacklists
Freeze logic written directly into the blockchain’s source code. Specific addresses can be blocked at a protocol level via code updates. This method – used by BNB Chain, VeChain and others – requires releasing new software (or a hard fork) to add or remove banned addresses. The blacklist is publicly visible in the codebase, but only the protocol developers or authorized parties can alter it with an update.
Configuration-File Freezing
A more behind-the-scenes approach, where validators or node operators load a private blacklist via config files (e.g. YAML, TOML) that the software checks during block production.
This “config-based” freeze doesn’t require altering the public codebase; instead, network operators quietly agree to update a settings file with the addresses to block, then restart their nodes. Aptos, Sui, and Linea are examples of layer-1 chains with this capability, managed essentially by validator consensus off-chain. Because these blacklists live in node configs, they’re typically not visible to the public, raising further transparency issues.
On-chain Contract Freezes
A system-level smart contract that can immediately blacklist or thaw accounts via on-chain commands. This acts as an administrative contract with authority over transaction processing.
The Heco (Huobi Eco) Chain is one notable case – it implements a contract that validators consult to determine if an address is forbidden from transacting. This model can be more dynamic (no node restart needed to update the list) but ultimately an admin key or privileged governance controls that contract’s entries.
Practical Implementations
Each approach, in effect, grants a small group the authority to stop transactions on the network – a role traditionally reserved for banks or regulators in the old financial system.
What’s remarkable is how quietly these controls have been inserted into various blockchains’ architectures. In many projects, there was little fanfare or clear documentation to inform users that such a “pause button” exists.
Often the functionality is buried in code repositories or config instructions, not highlighted in whitepapers or onboarding docs.
This means users and even many developers might be unaware of a chain’s freeze mechanism until it gets activated in a crisis.
According to the report, 10 of the 16 blockchains with freeze capabilities rely on the configuration-file method, giving validators the ability to impose private blacklists by updating node settings. Aptos, Sui, EOS and several others fall in this category.
Because the blacklist entries reside in local config, the network appears normal to outsiders – nothing in the public ledger explicitly flags the frozen addresses. Only the insiders coordinating the freeze (and any block explorers that later note the lack of transactions from those addresses) reveal that intervention took place.
Another five of the 16 chains have hardcoded freeze functions in their source code.
Bybit’s analysts pointed to Binance’s BNB Chain, VeChain, Chiliz, “VIC” (a smaller network identified in the report), and XinFin’s XDC Network as examples. In these systems, the developers built blacklist logic into the consensus rules themselves – a decidedly centralized failsafe. For instance, BNB Chain’s codebase contains an explicit list of blocked addresses that validators will not include in blocks. Changing that list requires a code update (typically orchestrated by Binance’s core team). VeChain similarly added a hardcoded “blacklist module” after its 2019 hack, though the project maintains that it was enabled via community vote and not a permanent backdoor (more on that later).
The remaining one of the 16 (Heco) uses the on-chain smart contract approach exclusively.
Notably, Tron – which was also flagged in the report – has a built-in permissioned blacklist module as well, which functions somewhat akin to a contract call initiated by the Tron Foundation to freeze accounts (Tron’s mechanism was not detailed in the Bybit summary, but it’s known from prior instances that Tron nodes can be instructed to reject transactions from certain addresses).
In all cases, whether the freeze is code-based, config-based, or contract-based, the end result is the same: specific addresses can be made unable to transact, at the discretion of those controlling the feature.
Quietly, a kind of template for freeze control has propagated across different blockchain ecosystems.
By combing through GitHub repos, the Bybit team found recurring patterns – hooks in the transaction processing code, references to “blacklist” variables, or checks against certain account lists. These were present in disparate projects and languages (for example, EVM-based chains like BNB and Chiliz vs. Rust-based chains like Sui and Aptos), suggesting that developers have independently converged on the idea that a blockchain should have an emergency brake. What started as ad-hoc reactions to crises is seemingly becoming a standard design consideration. And importantly, these controls often concentrate power in the hands of those who maintain the code or run the top validator nodes. As the report dryly notes, decentralization “often ends where validator access begins.”
16 Major Blockchains With Freeze Capabilities
Bybit’s research pinpointed sixteen public blockchains that currently have native functionality to freeze accounts or transactions. Below is the list of those networks and the known mechanism by which they can lock down funds:
- Ethereum (ETH) – Can enact an emergency pause via governance intervention (e.g. through a network upgrade or EIP hooks similar to proposed EIP-3074). While Ethereum doesn’t have a simple “blacklist” function baked in, developers could push a special fork or use contract logic to achieve a freeze in extraordinary situations, as demonstrated by the DAO rollback in 2016.
- BNB Chain (BNB) – Utilizes a validator-driven blacklist consensus. Binance’s exchange-backed chain has hardcoded freeze functions; its validators, coordinated by Binance’s core team, can refuse to process transactions from addresses on an internal blacklist.
- Polygon (POL) – Employs dynamic address filtering in transaction pools. Polygon’s nodes can be configured (via forks or updates) to filter out transactions involving certain addresses, effectively preventing blacklisted accounts from being included in new blocks.
- Solana (SOL) – Supports runtime configuration updates for blacklisting. Solana’s design allows the core team or governing entity to push network-wide configuration changes quickly. In theory, this could be used to deploy a blacklist at the validator software level or halt certain accounts.
- Avalanche (AVAX) – Features governance-triggered transaction halts. Avalanche can utilize its on-chain governance (via validator voting) to implement emergency halts or address-specific restrictions on its C-Chain and subnetworks, if a supermajority of validators agree.
- Tron (TRX) – Built-in blacklist module in its protocol. The Tron network, overseen by the Tron Foundation, has functionality that lets authorities freeze accounts (for example, to comply with law enforcement requests or protect against hacks, as seen in past incidents involving TRON-based assets).
- Cosmos (ATOM ecosystem) – IBC module pause and address bans. Cosmos and its SDK-based blockchains haven’t yet used global freezes, but the inter-blockchain communication (IBC) system and module accounts could be leveraged to halt transfers or blacklist addresses across zones with a coordinated upgrade.
- Polkadot (DOT) – Parachain-specific freezes via the Relay Chain. Polkadot’s governance can enact runtime upgrades on parachains. In an emergency, the relay chain could push a freeze or revert for a problematic parachain or address, subject to Polkadot’s on-chain voting.
- Cardano (ADA) – Hard forks with address exclusions. Cardano doesn’t have a simple freeze opcode, but through its hard fork combinator upgrades, the community could introduce rules excluding certain UTXOs or addresses (for instance, by not recognizing outputs controlled by a blacklisted key in a new epoch).
- Tezos (XTZ) – Governance votes enabling freezes. Tezos’ self-amending ledger could incorporate a freezing mechanism by protocol amendment. If the stakeholders voted to include a blacklist or pause feature in an upgrade (for emergency use), it would become part of Tezos’ protocol.
- Near Protocol (NEAR) – Shard-level transaction filters. NEAR’s sharded design might allow its coordinating nodes to filter or refuse transactions targeting specific addresses in a given shard – a capability that could be deployed via protocol governance in extreme events.
- Algorand (ALGO) – Atomic transfers with revocation keys. Algorand’s standard asset (ASA) framework includes an opt-in feature for asset freeze and clawback by the issuer. While ALGO itself cannot be frozen, many Algorand tokens have freeze controls. Algorand also supports forced transfer transactions (if authorized) which mimic freezing by moving funds out of a blacklist address.
- Hedera Hashgraph (HBAR) – Administrative token freeze controls. Hedera, governed by its corporate council, offers built-in admin functions for tokens. Approved administrators can freeze token transfers or even wipe balances. The network’s permissioned model means the council could likely also halt accounts at the ledger level if needed.
- Stellar (XLM) – Clawback and freeze clauses in asset issuance. Stellar allows issuers of assets (tokens) to enable a “clawback” feature, which lets them freeze or reclaim tokens from user wallets under certain conditions. This has been used by regulated stablecoin issuers on Stellar and amounts to a partial freeze mechanism in the ecosystem.
- Ripple XRP Ledger (XRP) – Escrow and line-freeze functionality. The XRP Ledger doesn’t allow freezing of the native XRP currency, but it does let issuers of IOU tokens (like stablecoins or securities on the ledger) to globally freeze assets or specific trust lines. Ripple’s network also supports locking XRP in escrow contracts (time-locked holds), which is related to restricting fund movement.
- VeChain (VET) – Authority-based transaction controls. VeChain’s authority masternode system enabled a blacklist in 2019 after a hack. The foundation, with community approval, activated consensus-level checks that caused validators to reject any transactions from the hacker’s addresses – effectively freezing those funds.
It’s important to note that not all projects agree with how their freeze capability has been characterized.
For instance, after Bybit’s report came out, VeChain’s team publicly refuted the notion that its protocol has a permanent hardcoded freeze per se.
The VeChain Foundation explained that in the 2019 incident, the community voted to issue a one-time patch – a consensus rule change – that blocked the hacker’s addresses at validator level.
“VeChainThor’s software includes consensus-level checks that, once enabled through community governance, rendered the assets immovable,” the team wrote, emphasizing that the measure was governance-approved and not an always-on feature. In other words, VeChain argues there isn’t a secret kill-switch in normal operation; they merely amended the code via proper procedure to freeze those stolen funds. This response highlights the sensitivity around the issue – no blockchain wants to be seen as centrally controlled, even if in emergencies they act that way.
Next in Line: 19 Networks a Few Clicks Away from Freeze Powers
Perhaps more startling than the 16 blockchains that have freeze functions is the report’s warning that 19 other networks could adopt similar controls with minimal effort. In many cases, the code scaffolding for blacklists or pausing transactions is already present or easily added. It might take just a few lines of code changed, or flipping a configuration flag, to turn on the feature.
How pervasive could this become? Potentially very – if developers decide the trade-off is worth it.
Bybit’s team did call out several specific projects in this “could easily freeze” category.
They noted that popular chains like Arbitrum, Cosmos, Axelar, Babylon, Celestia, and Kava are among those that could enable fund freezing with relatively minor protocol changes. These networks don’t currently advertise any freeze capability, yet their architectures are such that introducing one wouldn’t be difficult.
For example, many Cosmos-based chains use a module-account system (for things like governance or fee collection accounts).
As the researchers observed, those module accounts could be tweaked to refuse outgoing transactions from certain addresses. So far, no Cosmos ecosystem blockchain has employed this to blacklist a user – doing so would require a governance-approved hard fork with a small code change in the transaction handling logic. But the fact that it’s feasible with a straightforward update means the blueprint is there, waiting on a decision.
In practice, enabling a freeze feature on these additional chains would likely follow a familiar pattern: a major hack or regulatory pressure might prompt developers to say, “We need this tool.” Indeed, after Sui’s $162M hack and freeze, the Aptos network (a fellow Move-language chain) quietly added blacklisting capability into its code in the weeks that followed. They saw the writing on the wall: without a freeze mechanism, they’d have little recourse if a similar exploit hit their ecosystem.
This demonstrates how one project’s precedent can influence others. If even a few more high-profile incidents occur, it’s easy to imagine a cascade of chains quickly implementing latent freeze switches “just in case.”
The prevalence of similar code patterns suggests a degree of industry convergence on this issue. “It isn’t an anomaly – it’s becoming an industry template,” the report says of on-chain freeze logic. Many newer blockchains appear to have taken lessons (for better or worse) from previous hacks on older networks.
They may include hooks in their design that allow optional centralized actions, even if they don’t advertise them.
In some cases, those hooks were spotted by Bybit’s AI scanning tool: the team leveraged an AI model (Anthropic’s Claude 4.1) to scan hundreds of repositories for keywords and code structures related to blacklisting and transaction filtering.
This AI helper flagged dozens of potential instances across various projects.
Not all were true freeze functions – some false positives included user-level features that weren’t actually protocol-level controls. But the fact that automation was needed to sift through how widespread this might be underscores how murky the boundaries of “decentralized control” have become.
The researchers had to verify each case manually in the end , illustrating that even experts can struggle to discern where a blockchain has hidden levers of control.
Bybit’s report emphasizes that the existence of freeze capabilities in more networks is not hypothetical. It’s already the norm in spirit, if not letter. The difference is simply whether a project has flipped the switch yet. Many could do so with a hard fork or even a runtime config change, which means the ethos of absolute immutability is, in practical terms, compromised. We’re moving toward a landscape where a majority of chains have some degree of “stop button” – either active or waiting on standby. This raises the stakes for transparency: if these switches are pervasive, users and investors will want to know exactly who can pull them and how.
Pragmatic Security or Hidden Centralization?
The debate over these findings essentially boils down to a classic dilemma: do the benefits of emergency intervention outweigh the costs to decentralization?
Proponents of freeze functions argue they are a pragmatic security measure – a necessary option in a world where hacks, exploits, and thefts are rampant. Indeed, the report documents how freezes have saved substantial value. Sui’s swift action after the Cetus DEX hack potentially saved $162 million from being siphoned away forever.
BNB Chain’s blacklist during its 2022 exploit helped contain a $570 million breach, preventing further contagion across the Binance ecosystem. VeChain’s 2019 freeze of $6.6M in stolen tokens protected the project’s treasury and community funds from irretrievable loss. Each of those events could have been devastating; the ability to intervene turned them from fatal into merely painful.
“Without them, hacks like Cetus or the BNB bridge exploit would have wiped out investors,” as the report notes in defense of these mechanisms.
However, each time a blockchain exercises this kind of override, it chips away at the fundamental trustless ethos of blockchain technology. Censorship resistance – the guarantee that nobody can prevent valid transactions – is a big part of why people put faith in decentralized networks. If users come to feel that a foundation or committee can step in and freeze funds at will, the psychological (and legal) distinction from traditional banks begins to blur. The Bybit researchers warn that even well-intentioned freezes set a precedent:
“Once a chain freezes funds once, it’s hard to imagine it won’t again,” they write. The worry is that what starts as an exceptional measure could morph into a routine tool of control.
There’s evidence that the line is already moving.
According to the report’s data, nearly 70% of the documented freeze events occurred via actions at the consensus layer by validators or block producers. This is significant because it’s the deepest level of the system – meaning the censorship was baked into block production itself, not just at a superficial application layer. Average users wouldn’t even know it was happening; the chain simply stops processing transactions from certain addresses, no explanation given on-chain.
In a majority of cases the decisions to freeze were made by small governance councils, foundation teams, or core dev groups.
These are often unelected bodies, or if elected (like some validator sets), they tend to be insider-heavy and not directly accountable to millions of global users. Such freezes can thus resemble the actions of a central bank or government decree, executed without the kind of checks and balances decentralization was supposed to ensure.
The opacity around these emergency actions is a big part of the concern.
In Sui’s case, the coordination to freeze funds was done through behind-the-scenes agreements among validators orchestrated by the Sui Foundation. There was no on-chain proposal or prior user vote; it was an urgent response.
Similarly, Aptos’s newly added freeze feature is reportedly managed via validators’ private config files, and “only a handful of people know” who maintains the blacklist or how those decisions are made. This stealthy approach might be efficient in a crisis, but it sidelines the community and lacks transparency.
Even on BNB Chain, which is relatively open about its hardcoded blacklist, control “sits firmly with Binance’s developer core,” the analysis notes. That is, the ultimate decision of who gets blacklisted on BNB is effectively up to Binance’s leadership – an authority structure more akin to a corporation than a decentralized community project. And in the case of Heco’s contract-based freeze, an admin key held by the protocol’s operators can decide which addresses live or die on the network.
For critics, these realities validate long-standing suspicions that many so-called decentralized blockchains are decentralized in name only. “The lines between foundation, validator, and regulator are blurring fast,” as one commentary observed. When push comes to shove, most major networks can act very much like centralized intermediaries: they can freeze funds, reverse transactions, or otherwise govern user activity in ways users may not realize.
The crypto community has already seen analogous debates with issues like OFAC sanctions compliance, where Ethereum validators started censoring sanctioned addresses in blocks in 2022. That, too, was seen as a slippery slope where outside pressure led to de facto centralized behavior emerging in a decentralized system.
On the other hand, defenders of emergency powers argue that some ability to intervene is simply part of “growing up” for crypto. As blockchain platforms become mainstream and carry billions in value, the realities of hacks and crime can’t be ignored.
Even staunch decentralists might concede that if their own funds were stolen, they’d welcome a well-timed freeze to get them back. The key, perhaps, is ensuring proper governance and transparency around these capabilities.
David Zong, Bybit’s head of security who led the research, framed it this way: Blockchain may have been built on decentralization, “yet our research shows that many networks are developing pragmatic safety mechanisms to respond quickly to threats.”
The crucial thing, he says, is that “transparency builds trust” – meaning if such mechanisms exist, they should be openly disclosed and subject to oversight, not hidden in code.
The worst outcome would be secret backdoors or freeze buttons that users learn about only when it’s too late.
By contrast, if a project openly states that it retains an emergency brake and gives a clear policy on how and when it’s used (e.g. only for hacks above X amount, requiring multisignature approval, etc.), users and investors can judge the trade-off for themselves.
VeChain’s earlier-mentioned response is illustrative. They didn’t deny freezing funds – they defended how it was done, portraying it as a community-governed action rather than a unilateral move. This hints at a possible middle ground: any freeze should be enacted through some form of decentralized decision process. In VeChain’s case, they claim token holders approved the blacklist. In Sui’s case, after the fact, a community vote ratified the recovery plan. While these governance steps may be imperfect (critics will note that foundation influence can often sway votes or that emergency timing precludes lengthy debate), they at least attempt to align with decentralized principles. The alternative – a handful of core devs calling the shots – veers uncomfortably close to the centralized systems crypto sought to escape.
Nearly a year on from Ethereum’s historic “DAO fork” in 2016 – arguably the first on-chain fund intervention – the industry is still wrestling with the same core question: Should blockchains ever intervene in on-chain activity, even to correct a wrong?
There may never be a one-size-fits-all answer. Different networks are taking different stances, from Bitcoin’s absolutist immutability (even Satoshi-era thefts can’t be reversed) to more flexible, governance-heavy chains like Tezos or Polkadot that explicitly allow community-led alterations. What is clear is that the presence of these freeze mechanisms blurs the dichotomy of centralized vs decentralized.
Many networks occupy a gray zone in between – decentralized in daily operation, but with centralized override capabilities in extreme scenarios. Whether one views that as prudent risk management or a fatal compromise likely depends on their philosophy and perhaps whether they’ve ever been on the losing end of a hack.
Closing Thoughts
Bybit’s report has pulled back the curtain on an uncomfortable truth: the ability to freeze funds is now part of the blockchain landscape, especially among top networks.
The choice facing the industry is not simply “centralization vs. decentralization” anymore. It’s honest governance vs. hidden control.
Projects that come clean about their powers and put them under democratic checks may retain their credibility – they’ll be saying we are mostly decentralized, except in dire emergencies, and here’s exactly how that works.
In contrast, if such powers remain opaque and unchecked, it’s only a matter of time before they sow distrust or get misused. As regulatory scrutiny grows, some jurisdictions may even mandate on-chain freeze capabilities (the EU and Singapore have already floated ideas for “emergency brake” provisions in law ). Institutional investors, too, may prefer networks that can control risk, even if it means sacrificing some decentralization.
This could lead to a split between “compliant” chains that can intervene and “purist” chains that refuse, fundamentally reshaping the crypto ecosystem’s identity.
In the end, decentralization in crypto is not dying – but it is maturing and facing hard reality checks.