Blog

On the morning of October 30, the crypto market woke up to yet another theft of historic proportions. This time, Binance was the target.According to the preliminary investigation, the attack may have begun with the compromise of a DevOps engineer’s laptop. From there, the attacker gained access to a service container and submitted unauthorized withdrawal transactions.Binance estimated the incident’s total impact at approximately $6.3 billion. Around $3 billion in related assets has since been frozen through joint efforts with industry partners.Major exchange security incidents have become uncomfortably frequent over the past year.Bybit lost approximately $1.46 billion last year. In September, Bitget suffered roughly $387.5 million in unauthorized transfers. Now Binance has become embroiled in another major incident.Viewed together, these events reveal a clear trend: attackers are increasingly avoiding direct attacks on cryptography and private keys. Instead, they are targeting the entire chain of trust—from employee devices and third-party security products to software supply chains, service containers, and transaction-authorization workflows.A single crack anywhere along that chain can compromise the entire defense.The rapid development of AI is magnifying this risk.On October 22, Ethereum co-founder Vitalik Buterin offered a new assessment: cybersecurity’s long-term endgame may ultimately favor defenders, but the transition to that future will be extraordinarily difficult.1. From Bybit to PHP2Shell: Attackers Are Compromising the Entire Chain of TrustLet us begin by reviewing these incidents.Their attack paths differed, but they had one thing in common: the attackers did not simply crack private keys or compromise the underlying blockchain protocol. Instead, they found a component that the system implicitly trusted.In the Bybit incident, attackers used social engineering to compromise a Safe developer’s device, obtained relevant access credentials, and subsequently gained control of front-end resources within Safe’s wallet infrastructure.In the Bitget incident, attackers exploited a vulnerability in a third-party security product to obtain highly privileged internal credentials. They then bypassed existing risk controls with forged withdrawal instructions.In the latest Binance incident, the attack path may once again have begun with a compromised DevOps engineer’s laptop.The three incidents involved third-party wallet infrastructure, a third-party security product, and an internal development and operations environment, respectively.This helps explain why cold wallets and multisig mechanisms are not universal solutions. The attackers exploited trusted components capable of influencing the final execution of transactions but lacking sufficient independent verification.And this crisis in the chain of trust is not limited to crypto exchanges.One week before the Binance incident, Binance founder CZ specifically warned users to exercise extreme caution when visiting any website over the coming days. At the time, two critical vulnerabilities in the PHP core engine—CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell—were causing widespread alarm.Both received a CVSS v4.0 score of 9.2.PHP is an open-source server-side language used by roughly 70% of websites whose server-side programming language can be identified. Major platforms such as WordPress, Magento, and Drupal are built on it.The two vulnerabilities, which had gone undetected for more than a decade, involved flaws in memory management and the resetting of global state. Under certain conditions, an unauthenticated attacker could send a specially crafted web request and achieve remote code execution before the website’s application code even began running, potentially taking control of the server, installing a backdoor, or stealing user credentials.Scans by cybersecurity organizations including Palo Alto Networks and Censys suggested that between 22.6 million and 36.7 million internet-exposed instances could be at risk.Even more strikingly, security researchers disclosed that AI tools had played an important role in uncovering these deep, long-hidden flaws in PHP’s memory and state handling.In other words, AI has significantly lowered the barrier to turning obscure, low-level logic flaws into usable attack techniques.We have previously discussed three fundamental ways in which AI is transforming cyberattacks. Further reading: “When Hackers Scale Up with AI: The Next Level of Web3’s Security Arms Race.” Industrialized zero-day discovery: Finding deep memory vulnerabilities in a core engine such as PHP or in device firmware once required elite security researchers to spend months on manual code review and fuzzing. AI can now scan global open-source codebases around the clock at far lower cost, potentially turning bugs that have remained hidden for a decade into exploitable weapons at scale. A drastically compressed patch window: Once vulnerability details leak or a patch is committed, malicious actors can use AI to reverse-engineer the fix, generate exploit variants, and automate internet-wide scanning and injection within minutes. Traditional operations teams that schedule upgrades over days or weeks may find themselves facing AI-powered attack scripts operating at machine speed. Software supply chains and DevOps as primary entry points: Modern Web3 and financial systems do not exist in isolation. Front-end interfaces, backend containers, third-party NPM and PyPI dependencies, and engineers’ local development environments form a vast and vulnerable open-source supply chain. The reported compromise of a Binance DevOps environment and the front-end supply-chain attack behind the Bybit incident illustrate why the crypto industry is among the first to experience what could become a “pandemic-scale global wave of AI-enabled hacking.” Onchain attacks offer attackers an unusually direct path to monetization.Of course, not every attack described above was launched or executed directly by AI. But AI is amplifying the capabilities of both attackers and defenders. Under today’s software engineering model, that amplification may initially intensify the structural asymmetry between the two sides.2. Vitalik: The Endgame May Favor Defenders, but the Transition Will Be BrutalAmid the industry discussion sparked by AI-assisted discovery of vulnerabilities such as PHP2Shell, Vitalik Buterin offered a measured assessment on October 22: cybersecurity may ultimately reach an end state that favors defenders, but the transition will be extraordinarily difficult.Why?Because the current software engineering model contains an inherent asymmetry between attackers and defenders.A large software system may contain millions of lines of legacy code, hundreds of external dependencies, and countless complex permission and execution paths.Defenders must secure every critical component. Attackers need to find only one undiscovered weakness.Vitalik emphasized that simply relying on security researchers to find vulnerabilities in released software before hackers do cannot create a true defensive advantage. If both sides use increasingly powerful AI, the contest remains one of who can discover vulnerabilities faster.What needs to change is how software itself is built.He highlighted two core directions: formal verification and minimizing the Trusted Computing Base, or TCB.Formal Verification: Replacing Trial-and-Error Testing with Mathematical ProofTraditional software testing can show that no bugs were found in the scenarios tested. It cannot prove that a program contains no bugs under every possible input and state transition.Formal verification takes a different approach. It uses rigorous mathematical logic to prove that software satisfies a defined security specification across all modeled inputs and state transitions.This can help rule out classes of failures such as memory corruption, stale state—like the flaws involved in PHP2Shell—and logical reentrancy.Historically, formal verification was prohibitively expensive. The mathematical specifications and proofs could require several times as much work as the underlying application code, making the technique practical mainly for aerospace systems, foundational cryptographic protocols, and other exceptionally critical software.In the AI era, however, AI can do more than discover vulnerabilities. It can also become a powerful assistant for writing and checking formal proofs.Vitalik therefore expects AI-assisted formal verification to become a central model for future software development. AI could eventually help generate end-to-end, machine-checkable security proofs for systems ranging from encrypted communication protocols such as the Signal Protocol and TLS to ZK-EVMs and application-layer smart contracts before their code is released.When critical security properties have been mathematically proven, more powerful offensive AI cannot simply discover a violation that the proof has already ruled out.Minimizing the TCB: Reducing the Attack Surface to Its Smallest Possible CoreA system’s Trusted Computing Base is the complete set of hardware and software components that must behave correctly for the system to remain secure.The Binance incident and the compromise of Bybit’s multisig transaction process demonstrate why assets can still be stolen even when the underlying private-key cryptography remains intact: the TCB has become too large.Container clusters, complex DevOps permission pipelines, developers’ laptop operating systems, and JavaScript libraries used to render transaction interfaces can all become part of a trust chain where a single compromise may ultimately lead to asset loss.Minimizing the TCB means reducing the number of trusted components and isolating critical functions.Functions directly responsible for private-key protection, signature verification, and critical authorization should be confined to a small, clearly defined security environment that can withstand rigorous auditing and verification.More complex functionality should operate at the perimeter with limited permissions.Even if a browser, plugin, front-end service, or AI agent is compromised, it should not automatically gain unrestricted authority over user assets.From this perspective, the same principle also helps explain the value of non-custodial wallets such as imToken.When users rely on a centralized exchange, their assets pass through platform accounts, custodial wallets, and internal withdrawal systems. With imToken, users hold their own private keys, manage onchain assets directly, and initiate transactions themselves, removing the centralized custodian from the trust chain.A shorter trust chain means less exposure to platform-level risks, including exchange withdrawal suspensions and account-balance freezes.Users must, of course, take responsibility for protecting their private keys and devices. But control over their assets no longer depends entirely on the internal operations of a centralized platform.3. From Technological Acceleration to Defensive Acceleration: Why d/acc MattersFormal verification and TCB minimization address the question of how technology can be made safer.Vitalik’s long-standing advocacy of d/acc addresses a broader question:As AI and other frontier technologies rapidly reshape the world, which forms of technological development should society prioritize?d/acc stands for Defensive Accelerationism. Vitalik first presented the idea systematically in 2023 and expanded on it in his 2025 essay, “d/acc: one year later.”The concept does not oppose technological progress. Instead, it advocates selective acceleration: society should prioritize technologies that strengthen defensive capabilities, distribute power, and reduce systemic risk.Where e/acc emphasizes broad acceleration, d/acc asks whether a technology primarily strengthens offensive power or improves society’s ability to defend itself. Further reading: “When Web3 Meets d/acc: What Can Crypto Do in an Age of Accelerating Technology?”Within the d/acc framework, defense spans four dimensions: Cyber defense: Using cryptography, formal verification, software isolation, and vulnerability detection to reduce the success rate of cyberattacks and protect digital assets and data. Biological defense: Improving society’s ability to respond to biological threats through pathogen detection, air monitoring, vaccine development, and public health technologies. Physical defense: Reducing the vulnerability of critical real-world infrastructure through decentralized energy, resilient communications networks, and hardened infrastructure. Information defense: Countering disinformation, deepfakes, and large-scale information manipulation through privacy protection, source verification, and decentralized coordination mechanisms. These fields may appear very different, but they share a common objective: as technology increases the capabilities of individuals and organizations, they should also gain a corresponding ability to protect themselves. More powerful technologies should not be concentrated exclusively in the hands of a small number of resource-rich actors.During the discussion surrounding the PHP vulnerabilities, Vitalik reiterated a forceful position consistent with the d/acc framework.When frontier AI creates asymmetric risks, society should take a cautious approach to the uncontrolled development of high-risk offensive AI. At the same time, more than 1% of GDP should be systematically invested in cybersecurity, biosecurity, and hardening the physical world.Why is investment on this scale necessary?Because markets can quickly price and commercialize the benefits of technological progress, while the value of security infrastructure is frequently underestimated.Companies are willing to spend enormous amounts on more powerful AI models, faster computing, and more efficient software-development tools. Yet they may be far less willing to provide comparable support for long-term maintenance of foundational open-source software, formal verification, and security audits.Unless this misallocation of resources is actively corrected, the digital world will continue to grow taller on top of an increasingly fragile open-source foundation.Final ThoughtsFrom PHP2Shell's exposure of systemic risks in global internet infrastructure to the major security incidents involving Bybit, Bitget, and Binance, recent events have delivered a costly warning:The security contest of the AI era is no longer only about who can discover vulnerabilities faster. It is about whether the entire software ecosystem can build a sufficiently reliable defensive architecture.Security can never be solved once and for all. But that does not mean it is an unwinnable war of attrition.Over the past several decades, cryptography has demonstrated that some defensive capabilities can be secured by mathematical principles rather than by endlessly adding more human defenders.The combination of AI, formal verification, and a minimized Trusted Computing Base could extend that principle across much larger software systems.For ordinary users, the same security philosophy can inform how they choose to manage their assets.Choosing a non-custodial wallet such as imToken means keeping control of assets in the user’s own hands and reducing dependence on the custody and internal operations of centralized platforms.This also means taking greater responsibility for protecting recovery phrases, securing devices, and reviewing every transaction authorization. But at the very least, the user’s ability to control their assets no longer depends entirely on whether a centralized platform continues to operate normally.Perhaps this is what Vitalik truly means when he says that cybersecurity’s endgame may favor defenders.The goal is not to wait for a day when AI can no longer find any vulnerabilities. It is to steadily build critical systems that can continue operating reliably against increasingly capable attackers by relying on smaller trusted cores, stricter permission boundaries, and more verifiable security mechanisms.Technological progress deserves to accelerate. So does our ability to protect its benefits—and the assets of every individual.

If an institution holds millions of ETH and decides to stake most of it, does Ethereum become more centralized as a result?The answer may seem obvious.Under proof-of-stake (PoS), if an increasing amount of ETH is held by a small number of large institutions, it would appear that influence over the network is becoming concentrated among fewer participants.The reality, however, is more complicated.Over the past year, as more institutional capital has entered Ethereum staking and EIP-7251 has raised the maximum effective balance of a single validator from 32 ETH to 2,048 ETH, the staking ecosystem has undergone two changes that may look similar but are fundamentally different.On the one hand, large pools of capital are indeed becoming more concentrated. On the other, more ETH is being consolidated into fewer validators.Do these two trends necessarily increase Ethereum’s centralization risk?1. As More Institutional ETH Enters Staking, Is Centralization Increasing?Let us begin with the data.According to Lido’s report for the first half of 2026, the Ethereum staking market grew from approximately 36.3 million ETH at the beginning of the year to 43.1 million ETH by the end of June—an increase of roughly 19% in six months.This measurement includes ETH waiting in the entry queue but excludes ETH already in the exit queue.More noteworthy, however, was the change in where the capital came from.During the same period, institutional staking’s share of the market increased from 25.9% to 35.3%, a rise of almost 10 percentage points.In other words, an increasing proportion of newly staked ETH is coming from corporate treasuries, exchanges, custodians, and other professional market participants.The shift is equally visible in market share.As of June 30, 2026, Lido remained Ethereum’s largest staking protocol, accounting for approximately 21.2% of all staked ETH. Yet its share had declined from 23.9% at the beginning of the year.Over the same period, BitMine, Coinbase, and Binance accounted for approximately 11.5%, 10.9%, and 7.9% of the market, respectively. BitMine’s growth was particularly significant: its share increased by roughly 10 percentage points in just six months.This reveals an interesting change in Ethereum staking.For years, discussions about staking centralization focused primarily on liquid staking protocols such as Lido. The concern was that, as more users staked through a single protocol, consensus power could become increasingly concentrated.Now, a different trend is emerging.As large institutional ETH holders participate in native staking at scale, the structure of staking capital is changing. Liquid staking protocols are no longer the primary destination for newly staked ETH.That raises several questions.If one institution holds more than 10% of all staked ETH, does it also directly control more than 10% of Ethereum’s validators? If hundreds of thousands of validators are consolidated into a smaller number of high-balance validators, is Ethereum deliberately moving toward centralization?To answer these questions, we first need to separate several concepts that are often conflated.2. Does Owning Millions of ETH Mean Controlling an Equivalent Amount of Validation Power?One of the most common mistakes when assessing staking centralization is treating ownership of the capital and operation of the validators as the same thing. Further reading: “With 34% of ETH Staked, How Should You Stake in the Era of Native Compounding?”They are not. In practice, control exists at three distinct levels.The first is asset control: who owns the staked ETH and who has the authority to exit staking, withdraw the assets, or switch service providers.The second is validator operations: who runs the nodes, manages the validator signing keys, proposes blocks, and performs attestations and other consensus duties.The third is infrastructure and decision-making power: whether a large number of validators depend on the same client software, cloud provider, or MEV relay—and how much influence a platform’s governance structure or management team has over the coordination of those validators.The degree of concentration can differ across these three levels.Consider an institution that owns one million ETH and stakes all of it, but distributes the stake across more than a dozen independent node operators.From the perspective of asset ownership, the one million ETH is clearly concentrated in the hands of a single institution. From the perspective of validator operations, however, the validators may be managed by different service providers, deployed across multiple regions, and run with different client software.The reverse situation can be equally concerning.Suppose tens of thousands of users each own 32 ETH but all rely on the same node operator to perform their validation duties.Asset ownership would be widely distributed, while validator signing, operations, and infrastructure could remain highly concentrated.The key question, therefore, is who ultimately performs consensus duties for the ETH—and whether different participants share common points of failure or depend on the same decision-makers.This does not mean that large institutional holdings present no centralization risk.If an institution both owns a large amount of ETH and controls the signing keys for all the corresponding validators, its influence over Ethereum’s consensus cannot be ignored.Even when external node operators are used, the asset owner may still influence validator behavior indirectly through service agreements, capital allocation, withdrawals, reallocations, and decisions to switch operators.Ethereum’s consensus weight is also allocated according to effective staked balance. If one participant—or a coordinated group—controls enough of that balance, it may be able to affect the network’s finality.For example, under certain conditions, a coordinated group controlling more than one-third of the active stake could prevent the network from reaching finality.Whether large-scale staking threatens decentralization cannot therefore be determined solely by looking at how much ETH an institution owns. Nor can the risk be dismissed simply because the institution uses several service providers.Assessing staking concentration requires more than comparing market shares. It requires examining the actual distribution of asset ownership, signing authority, validator operations, infrastructure dependencies, and coordination power.3. From 32 ETH to 2,048 ETH: What Has Changed for Large-Scale Staking?At the same time that institutional capital has been entering staking at scale, Ethereum's Pectra upgrade has significantly changed how large ETH stakes are managed.In particular, EIP-7251 raised the maximum effective balance of a single validator from 32 ETH to 2,048 ETH while preserving the minimum activation threshold of 32 ETH. Further reading: “As 8 Million ETH Starts Moving, Is Ethereum Staking Undergoing a Structural Shift?”Why was this change necessary?Under the previous model, an operator with 1,024 ETH would generally need to divide it into 32 separate deposits and create 32 validators.Each validator had its own signing identity, participated independently in consensus duties, and introduced additional costs related to key management, message propagation, and state maintenance.After EIP-7251, the same 1,024 ETH can, subject to protocol rules, be consolidated into a single 0x02 validator. This can significantly reduce operational overhead and the additional burden placed on the consensus layer.Another major change is native compounding.The effective balance of a traditional 0x01 validator is capped at 32 ETH. Rewards above that amount do not increase the validator’s effective weight. If users want those rewards to participate in native staking, they must make separate arrangements to reinvest them.This was not an insurmountable problem for large staking pools. They could aggregate rewards generated by many validators, accumulate another 32 ETH, and create a new validator.For long-term holders operating only one or several validators, however, the process was far less convenient. Staking rewards do not arrive as a single 32 ETH payment—they accumulate gradually over a long period.EIP-7251 allows consensus-layer rewards to remain within a compounding validator’s balance. Its effective balance can then increase in 1 ETH increments under the protocol’s rules, allowing additional ETH to contribute to reward calculations until its effective balance reaches the cap of 2,048 ETH.In other words, a process that previously required users to withdraw rewards, accumulate them, and stake them again can now take place natively within the Ethereum protocol.For large institutions, this can significantly reduce the number of validators they need to operate, together with the associated costs of key management and infrastructure maintenance.For ordinary long-term holders, it also removes the need to accumulate another 32 ETH before smaller amounts of earned ETH can begin contributing to native staking rewards.Ethereum is therefore making large-scale, institutional, and professional staking more flexible at the protocol level. Capital can be organized more efficiently, rewards can compound more naturally, and operators can manage stake without mechanically splitting it into countless 32 ETH validators.The added convenience, however, also brings new operational requirements.Unlike traditional validators, 0x02 validators do not automatically withdraw rewards above 32 ETH by default. If users want to spend, trade, or otherwise manage those rewards, they must initiate a partial withdrawal under the protocol’s rules.Converting a traditional 0x01 validator into a 0x02 validator is also irreversible. Large holders managing their own validators need to exercise particular caution when consolidating them. An incorrect target validator or improperly configured authorization information could lead to serious losses.Final ThoughtsLooking back at the evolution of large-scale Ethereum staking, two trends are advancing at the same time.The first is happening at the market level. As institutional capital continues to enter, ETH staking is becoming an increasingly important part of long-term asset management.The second is happening at the protocol level. Through upgrades such as EIP-7251, Ethereum is moving away from the mechanical fragmentation of stake into large numbers of 32 ETH validators, allowing substantial positions to participate in consensus more efficiently.But greater efficiency does not necessarily mean greater decentralization.A decline in the number of validators does not, by itself, prove that the network is becoming more centralized. Conversely, a large validator count does not guarantee decentralization if the underlying signing authority and operational control remain concentrated.Ultimately, decentralization depends on how control is actually distributed—and whether the network can avoid becoming excessively dependent on a small number of operators, clients, cloud providers, and other infrastructure providers.For users, this is also a reminder that APR should no longer be the only consideration when comparing ETH staking solutions.In practice, imToken’s non-custodial ETH staking service offers both Compounding Validators and Auto-Withdrawal Validators. Users can choose between them depending on whether they want to accumulate ETH over the long term or receive staking rewards through automatic withdrawals.The non-custodial model also keeps withdrawal control with the user while professional service providers handle validator signing and operations. This allows users to retain control of their staked assets without having to maintain the underlying infrastructure themselves.From this perspective, the next stage of Ethereum staking is about enabling users with different amounts of ETH to participate with greater clarity, control, and efficiency.That may be the most important long-term change in the era of large-scale staking.

Over the past few days, discussions about whether AI could potentially break cryptography have sparked a fresh wave of anxiety across the crypto community. It began on October 7, when Justin Drake called on the blockchain industry to calmly begin planning for “Bunker Mode” to prepare for possible future cryptographic risks. His central concern is that, as AI becomes increasingly capable of conducting mathematical research, the elliptic-curve cryptography widely used by networks such as Bitcoin and Ethereum could face new forms of mathematical attack even before cryptographically relevant quantum computers arrive. In his worst-case scenario, such a breakthrough could occur within months rather than years. He therefore suggested that large holders and institutions begin considering an orderly asset migration, reducing the potential risks associated with already-exposed public keys wherever possible. Vitalik Buterin subsequently joined the discussion. Interestingly, Vitalik did not dismiss the possibility that AI could accelerate cryptographic research. He went even further, noting that some cryptographic schemes currently considered resistant to quantum attacks could still be affected by future mathematical breakthroughs. However, when it came to whether ordinary users should immediately move their assets, he warned that the very real losses caused by rushed upgrades and migrations may deserve more attention today than a cryptographic attack that has not yet materialized. This raises a long-standing question for the entire crypto industry: when the cryptographic assumptions protecting onchain assets begin to face new challenges, how far in advance should public blockchains prepare—and when should ordinary users take action? 1. Where Does the Risk Come From? Understanding the Gap Between an Address and a Public Key To understand the focus of this debate, we first need to return to the basic account and signature mechanisms used by public blockchains. In a non-custodial wallet, the private key is the critical credential that controls the assets. More specifically, wallets use digital signature algorithms to prove that a transaction has been authorized by the corresponding key holder without revealing the private key itself. One of the most widely used technologies is elliptic-curve cryptography, or ECC. On Ethereum, ordinary externally owned accounts, or EOAs, use ECDSA to sign transactions. Bitcoin’s traditional signature system also makes extensive use of ECDSA, while Taproot uses Schnorr signatures based on the same elliptic curve. The long-term reliability of these systems depends on an important mathematical assumption: deriving a public key from a private key is easy, but deriving the private key from the public key is practically infeasible using currently known classical computing methods. We can think of it as a mathematical problem that is easy to verify but extremely difficult to reverse. Anyone on the network can use a public key to verify whether a signature is valid, but they cannot easily calculate the signer’s private key from it. This asymmetry is one of the foundations of asset ownership on modern blockchains. There is, however, an easily overlooked detail: the wallet address we see in everyday use is not always the complete public key. For an ordinary Ethereum EOA, the wallet address is created by hashing the public key with Keccak-256 and taking part of the resulting output. On Bitcoin, common address types such as P2PKH and P2WPKH similarly use designs based on public-key hashes. This creates an important security distinction. For an ordinary Ethereum account that has never initiated an onchain transaction—or revealed its public key through some other channel—outside observers will generally see only the hashed wallet address. Because current computing methods cannot feasibly recover the full public key from this address hash, the public key effectively benefits from an additional layer of protection. Once the account initiates a transaction and submits an ECDSA signature, however, nodes can recover the corresponding public key from the signature data. Since onchain transaction records remain publicly accessible, that public key also remains exposed. For accounts that use public-key-hash addresses, this means that an account whose public key has never been revealed may face a different level of risk from one whose public key is already public under certain future cryptographic attacks. That does not mean every blockchain follows the same rules. A Bitcoin Taproot output, for example, directly contains a visible elliptic-curve public key. Even if the funds in a Taproot address have never been spent, it would be incorrect to assume that its public key remains concealed behind a hash function. Public-key information can also be exposed in advance through address reuse, public signatures, extended public keys, and other channels. In other words, “never spent from” does not necessarily mean “public key never exposed.” Nor is a newly generated address automatically quantum-resistant. Once this distinction is understood, the potential challenges posed by quantum computing and AI become easier to examine. In theory, a sufficiently large and fault-tolerant quantum computer could use Shor’s algorithm to efficiently solve the elliptic-curve discrete logarithm problem, deriving a private key from a public key and thereby threatening signature schemes such as ECDSA and Schnorr. At present, however, there is no evidence that any quantum computer can practically break the mainstream signature systems used by Bitcoin or Ethereum. Justin Drake’s concern focuses on another possibility: AI could help researchers discover mathematical shortcuts that existing algorithms have not yet found, even without a cryptographically relevant quantum computer. As AI has made rapid progress over the past year in mathematical reasoning, algorithm search, and formal proof, some researchers have begun reconsidering whether computational problems tested over decades could one day be reassessed in light of new mathematical discoveries. 2. Justin and Vitalik Do Not Fundamentally Disagree Once the underlying mechanics are clear, the discussion between Justin and Vitalik looks less like a direct disagreement. They are largely assigning different priorities to different risks. Consider Justin Drake’s position first. Cryptographic transitions have traditionally been lengthy processes. Identifying a potential vulnerability, developing a new standard, completing the engineering work, and coordinating compatibility across public blockchains, wallets, exchanges, custodians, and hardware devices can easily take years. For decentralized networks as large as Bitcoin and Ethereum, where upgrades require broad coordination, replacing foundational cryptography is not something that can be completed through an ordinary software update. Justin’s concern is that this extended upgrade cycle may not be able to keep pace with future breakthroughs in mathematical research. If AI were to help researchers discover a new cryptographic attack, existing elliptic-curve signature systems could face a threat before quantum computers become capable of breaking them in practice. Once such a breakthrough appeared, the migration window available to public blockchains and wallet ecosystems could be much shorter than previously expected. His position is therefore precautionary. Exchanges, major institutions, and large asset holders should begin considering contingency plans now rather than waiting until a practical attack emerges. That could include identifying addresses whose public keys have already been exposed, gradually moving some long-term holdings to fresh addresses whose public keys have not yet been revealed, and reducing unnecessary signatures and address reuse. From a technical perspective, this recommendation has some merit. If a future attack depends on deriving private keys from exposed public keys, reducing public-key exposure in advance could provide additional time for defense under certain conditions. But moving assets to a fresh address with an unrevealed public key does not constitute a genuine migration to post-quantum cryptography. As long as the new address still relies on a traditional signature scheme such as ECDSA, its underlying security assumptions remain unchanged. Once that address initiates a transaction, its public key may be exposed again. If the attacking capability is powerful enough, even the brief period between transaction broadcast and confirmation could become a new attack window. This is therefore a transitional risk-mitigation measure, not a permanent solution. More importantly, reducing theoretical cryptographic exposure does not necessarily make asset management safer in practice. This is the point Vitalik particularly emphasized. Under currently known technical conditions, there is still no practical method for directly recovering an ECDSA private key from a public key. By contrast, users lose onchain assets every day through incorrect addresses, faulty key backups, malicious approvals, and other operational mistakes. Vitalik even noted that he had personally lost more from migration configuration mistakes than from hacks. For an ordinary user holding a small amount of ETH, moving funds may involve little more than creating a new address, backing up the key, and making several transfers. The situation becomes far more complicated, however, for users who have long participated in DeFi, staking, or cross-chain activities—or who manage funds through multisig wallets. Their assets may be distributed across several networks. Some funds may still be deposited in staking or lending protocols. Old addresses may retain smart contract administrator privileges, withdrawal rights, or other critical permissions. If users launch a large-scale asset migration simply because they have seen a headline claiming that “AI may break wallets,” they may instead suffer irreversible losses by selecting the wrong network, misusing a bridge, signing a malicious transaction, or making an error during multisig coordination. Worse still, once panic spreads around claims that wallets are about to be compromised, scammers are likely to distribute fake post-quantum upgrade links, asset-protection tools, and migration services. Vitalik's caution does not mean that he takes a conservative stance on upgrading the underlying cryptography. On the contrary, he also believes that the mathematical progress enabled by AI deserves serious attention. He has even urged the industry to reassess some lattice-based post-quantum schemes rather than assuming that an algorithm labeled “quantum-resistant” will automatically withstand every future mathematical breakthrough. Where possible, he favors giving greater consideration to cryptographic structures based on hash functions and using more conservative security parameters for other approaches. Justin and Vitalik therefore should not be reduced to an “aggressive” camp and a “conservative” camp. They do not fundamentally disagree. Justin is emphasizing the long lead time required for protocol and ecosystem preparation. Vitalik is emphasizing that preparation at the system level does not mean ordinary users should rush into an immediate migration. 3. From Protocol Upgrades to Wallet Migration: How Far Has Post-Quantum Preparation Progressed? Many users may now be asking: if foundational cryptography faces long-term risks, can a wallet app simply be upgraded into a “quantum-resistant wallet”? Updating the wallet app alone is not enough. For a blockchain, a cryptographic migration affects more than private-key generation and transaction signing. The entire network must be able to recognize and verify the new signatures, while existing accounts must be given a safe path to transition. Even before the recent debate around AI, major public blockchains and cryptographic research organizations had already begun preparing for the post-quantum era. Ethereum’s preparations, for example, already span several layers. In addition to the ECDSA signatures used by ordinary accounts, Ethereum must eventually reassess or replace the BLS signatures used by validators, the KZG commitments involved in data availability, and cryptographic components used in certain zero-knowledge proof systems. The Ethereum Foundation has established a dedicated Post-Quantum Security team and is exploring technologies such as leanXMSS and leanVM to provide new signature and proof mechanisms for the consensus layer. At the user-account layer, account abstraction offers another promising path. Unlike traditional EOAs, whose signature-verification mechanism is tightly coupled to the underlying protocol, account abstraction and replaceable verification logic could eventually allow user accounts to adopt different signature algorithms, creating a more flexible path for post-quantum upgrades. EIP-8141, or Frame Transactions, is currently under discussion as part of Ethereum’s work on native account abstraction. It could become important infrastructure for more flexible signature verification in the future, although its deployment timeline and final implementation remain subject to further community discussion and testing. Bitcoin faces a different set of challenges. Because Bitcoin uses the UTXO model, supports several historical address types, and contains large amounts of long-dormant funds, the network must not only consider new signature algorithms and output structures but also determine how existing assets can be migrated. Relevant proposals remain at the drafting and coordination stage. Other public blockchains have begun pursuing more direct implementations. In July 2026, for example, NEAR announced that its mainnet upgrade had added support for ML-DSA, a post-quantum signature scheme standardized under FIPS 204, allowing accounts to add quantum-resistant keys. Supporting one post-quantum signature scheme, however, does not mean that an entire blockchain—together with all its accounts, applications, and infrastructure—has completed a post-quantum migration. Taken together, these developments reveal the variety of challenges the industry must address. A new cryptographic scheme must be sufficiently secure in theory. Its implementation must also take into account signature size, onchain verification costs, node performance, hardware compatibility, and the orderly transition of a vast number of existing accounts. All of these protocol-level changes will ultimately reach the wallets that users interact with every day. For a multichain non-custodial wallet such as imToken, a future cryptographic migration cannot be reduced to a simple version update. On the one hand, the wallet will need to adapt gradually to new account and address types, key-management methods, and transaction signing and verification mechanisms as different blockchains upgrade. It may also need to maintain compatibility with hardware wallets, smart contract accounts, and multisig systems. On the other hand, the wallet must translate complex technical changes into a migration process that ordinary users can understand. If a blockchain officially introduces a new post-quantum signature scheme, users will want practical answers. Can they continue using their existing addresses? Do they need to create new accounts? Will their current seed phrases and hardware devices remain compatible? What happens to the tokens, NFTs, staked assets, and DeFi positions they already hold? Wallet products may be able to resolve some of these questions. Others will require support from the underlying blockchain protocol, smart contracts, and the broader ecosystem. The more complex the foundational security upgrade, the more thoroughly the user-facing migration process must be tested. This is not the kind of transition that should be handled through a hastily launched “one-click quantum protection” feature. So what should ordinary users do today? First, there is no need to move all assets solely because of this discussion. There is currently no evidence that the mainstream signature algorithms used by major public blockchains have been practically broken. Users should be particularly wary of unfamiliar links and migration tools promoted in the name of “post-quantum upgrades.” Any service asking users to import a seed phrase or private key—or to sign an unclear transaction—should be treated as highly suspicious. Second, holders of large, long-term positions can begin improving their address-management practices. This means understanding the blockchain and address types they use, avoiding unnecessary reuse and signatures from high-value addresses, and carefully verifying wallet and network compatibility before changing how assets are stored. Any necessary migration should begin with secure key backups, careful recipient-address checks, small test transfers, and staged execution. Finally, one distinction is easy to overlook: whether wallets will be able to support post-quantum signatures in the future and whether users need to move their assets today are two different questions. Final Thoughts In the blockchain world, we use mathematics and code to establish trust. From this perspective, no one can guarantee that a cryptographic system considered secure today will never need to be changed over the coming decades—particularly if open financial networks are expected to secure trillions of dollars in assets over the long term. But that does not mean every breakthrough in frontier research should cause ordinary users to immediately rearrange their holdings. Cryptographic researchers must examine the worst-case possibilities. Public blockchain developers must design new security mechanisms well in advance. Wallet teams must provide reliable support for future upgrades and migrations. Ordinary users, meanwhile, should understand the actual risks and avoid making rushed decisions based on unverified claims. We should neither assume that the crisis has already arrived nor overlook the fact that continued evolution is inevitable. Stay clear-headed and proceed carefully. For every crypto holder, that remains the best way to face an uncertain future.

Once you hold ETH, what else can you do with it?A few years ago, the answer was almost disappointingly simple: move it to a cold wallet, leave it there, and wait for the next bull market.But now that Ethereum has transitioned to proof of stake and onchain lending markets have matured, ETH no longer has to sit idle. The two most common options are native staking to earn protocol rewards or depositing ETH as collateral to borrow stablecoins—unlocking liquidity without selling the underlying asset.At first glance, both approaches put idle ETH to work. But comparing only their APRs obscures their most fundamental difference:Native staking addresses how long-term holders can earn protocol rewards on assets they intend to hold. Borrowing addresses how holders can unlock liquidity and improve capital efficiency without selling.They serve two entirely different financial needs.1. Native Staking: Turning a Long Holding Period Into Productive CapitalConsider the simplest scenario.Suppose you hold 32 ETH or more and are almost certain you will not need it for the next two or three years. You have already accepted the short-term price volatility. The only remaining variable you can put to work is the time you know you will spend holding it.That is precisely what native staking does: it turns time into productive capital.Since Ethereum transitioned to proof of stake, validators have staked ETH to participate in network consensus. They perform duties such as submitting attestations and proposing blocks, receiving rewards according to protocol rules.These rewards do not come from interest paid by another borrower or from additional tokens distributed by a DeFi protocol. They come from Ethereum’s protocol-level incentives for participants who help secure and operate the network.For long-term holders, the logic of native staking is therefore straightforward: if the ETH is going to remain untouched anyway, it can participate in securing Ethereum and accumulate additional ETH during that period.Pectra made this approach even more capital-efficient. (Further reading: “As 8 Million ETH Starts Moving, Is Ethereum Staking Undergoing a Structural Shift?”)The new 0x02 compounding validator increased the maximum effective balance of a single validator from 32 ETH to 2,048 ETH. Rewards above 32 ETH can increase the effective balance in 1 ETH increments and continue generating rewards, giving native staking a more complete compounding mechanism.Native staking, however, has one clear limitation: it addresses rewards but does not directly provide liquidity.Once ETH enters the validator system, its primary role is to serve as economic security for the network. New validators must pass through the activation queue, while a full exit may also require waiting, depending on network conditions. Staked ETH therefore cannot be spent, traded, or redeployed as freely as an ordinary wallet balance. (Further reading: “Why Does Native Ethereum Staking Come With a Month-Long Queue?”)Liquid staking partially addresses this limitation. When users stake through a protocol such as Lido, for example, they receive stETH, which can still be transferred, lent, or used elsewhere in DeFi. From a structural perspective, however, this adds another protocol and token layer on top of native staking.Abstracted to its core purpose, native staking is best suited to one particular need: making a long-term ETH position productive during the time you already intend to hold it.2. Borrowing: Unlocking Purchasing Power Without Giving Up Your PositionBorrowing solves a very different problem.Suppose you remain highly bullish on ETH and have no intention of selling, but suddenly need cash—or a compelling new onchain opportunity appears.Selling spot ETH would be the simplest option, but it also means surrendering the position. If ETH subsequently enters a major rally, rebuilding that position at a reasonable cost may be difficult.DeFi lending offers another approach: keep the ETH, deposit it as collateral, and borrow the stablecoins you need through an overcollateralized loan.On a protocol such as Aave, users can supply eligible assets as collateral and borrow other assets within the applicable loan-to-value limits. The borrowed funds can then be used for payments, investments, or other liquidity needs, while the original ETH remains deposited as collateral.At this point, ETH is serving a completely different role.In native staking, ETH is productive capital that earns protocol rewards by participating in network consensus. In lending, it functions more like collateral on a balance sheet, with its primary value lying in the liquidity it allows the holder to access.Strictly speaking, borrowing does not create free additional yield.Once users borrow assets, they take on debt and must pay a variable borrowing rate. At the same time, if the price of ETH falls substantially, the position’s Health Factor will decline. Once the position reaches its liquidation threshold, part of the collateral may be sold by the protocol.Borrowers on Aave must therefore monitor their loan-to-value ratio, Liquidation Threshold, and Health Factor.If the borrowed stablecoins are used to purchase more ETH, the position goes one step further: what began as liquidity management becomes leverage. If ETH rises, the strategy magnifies returns. If ETH falls, it accelerates the deterioration of the collateral position.This marks an important risk boundary between borrowing and native staking.The primary risks of staking involve validator operations, slashing, and delays in exiting or withdrawing staked ETH.Collateralized borrowing introduces additional risks associated with debt, variable interest rates, market prices, and liquidation.For long-term holders, borrowing answers a practical question: if you do not want to sell your ETH but need access to funds, can you unlock its liquidity?Yes—but that liquidity is not free.3. One Earns From Time; the Other Unlocks LiquidityViewed from this perspective, native staking and borrowing are not absolute substitutes. In portfolio management, they are better understood as complementary tools for different needs.A core position that is unlikely to be sold for several years may naturally fit native staking. It can earn Ethereum protocol rewards without introducing external debt or market-driven liquidation risk.A more tactical allocation with a clear short-term liquidity requirement—and whose holder is willing to monitor the position—may use borrowing as a buffer that avoids selling spot ETH.Put simply, when liquidity is not needed, ETH can go to work as productive capital. When liquidity is needed, ETH can serve as collateral. The former improves yield efficiency during a long holding period; the latter improves balance-sheet capital efficiency.DeFi also offers more aggressive ways to combine the two. A user might convert ETH into stETH, use it as collateral, borrow additional funds, and build a looping position in an attempt to capture both staking rewards and leveraged returns.But the more tightly a strategy optimizes capital efficiency, the longer its chain of risks and dependencies becomes.For long-term holders, removing one layer of smart contract risk is often more valuable than adding another two percentage points of projected yield.In practice, many users avoid native staking not because they reject its economics, but because it seems too complicated.Running a validator independently remains beyond the practical reach of most users. It requires setting up hardware, configuring clients, protecting against downtime, and handling ongoing maintenance. Those operational demands remain even after Pectra. Yet handing ETH to a centralized exchange for convenience undermines the original purpose of non-custodial staking.This is the gap that mature wallet products can fill by turning complex validator operations into an accessible service.With imToken’s non-custodial native staking service, for example, users can create a dedicated validator with at least 32 ETH and choose between a compounding validator using 0x02 withdrawal credentials and an automatic withdrawal mode.Professional infrastructure providers handle hardware deployment, validator operations, and continuous monitoring, while users retain control of their private keys and the withdrawal address specified in the validator’s Withdrawal Credentials.In other words, an operational process that was once highly technical and cumbersome is condensed into a native staking experience that remains intuitive and under the user’s control.Final ThoughtsFor long-term ETH holders, this is becoming an increasingly important question.In the past, the primary decision was whether to continue holding ETH.As staking, lending, and other onchain financial tools mature, the question becomes: if you intend to hold ETH for the long term, what role should it play?Should it become a productive long-term asset that continuously earns protocol rewards, or collateral that can unlock liquidity whenever capital is needed?Answering that question may matter far more than comparing a few percentage points of APR.

What Is Pay Protocol?Pay Protocol is a decentralized digital asset payment protocol for merchants. It supports address-based and order-based payments for e-commerce, commodity settlement, and digital services. Merchants can accept payments via links, QR codes, or API integration and manage funds in the admin dashboard.Pay Protocol is non-custodial, with dedicated on-chain smart contracts for each merchant. Merchants control their executive (admin) wallets and manage contract permissions and funds through multisignature approval.👉 Learn more: Pay Protocol Product OverviewThis guide covers registration and payment management without API integration. To automate orders and callbacks through your website, app, or business system, integrate the Merchant API separately.Core Features Receiving address management: Create deposit sub-contract addresses in batches for separate allocation and reconciliation by customer, project, or business channel. Multiple networks and tokens: Supports Ethereum, TRON, BNB Chain, Base, and other networks, with tokens including USDT, USDC, ETH, BNB, and TRX. Permissions and multisignature management: Both Standard and Pro plans support permission controls, including multisignature approval. 💡 Fees: A 0.1% service fee applies only to successful withdrawals from the cold contract to the treasurer wallet/hot wallet (1 USDT per 1,000 USDT withdrawn). Check the official Pay Protocol page for applicable fees.Register a Pay Protocol Merchant AccountBefore You Register (Standard Merchant Example):Prepare four separate wallet addresses: 3 executive wallets: To log in to the dashboard, change settings, and initiate or approve multisignature operations. 1 treasurer wallet: Only to receive funds withdrawn from the cold contract vault. ⚠️ All four addresses must be unique, and must not be derived from the same mnemonic phrase. Back up each wallet’s mnemonic phrase or private key separately and keep it safely. Use supported self-custodial wallets, such as imToken or TronLink. Do not use exchange deposit addresses.Step 1: Get an Invitation Code Visit the Pay Protocol application page and submit your email address. The system will send an invitation code and relevant instructions to that email address. Tap the registration link in the email to begin registration. Step 2: Complete Registration Open the registration link and enter your company name. Select the blockchain network you commonly use, such as Tron/TRC20, then enter the three executive wallet addresses and one treasurer wallet address on that network. Review and accept the service agreement, check your details, then tap “Submit Registration”. Wait for Pay Protocol to review your application, deploy your dedicated on-chain contracts, and initialize permissions. Learn more: Pay Protocol Smart Contract Factory Once deployment is complete, you can log in to the admin dashboard using one of the executive wallets provided during registration. Log In to the Pay Protocol Admin Dashboard and Manage PaymentsAfter registration, connect an executive wallet to log in to the Pay Protocol admin dashboard. The following example uses imToken with a Tron wallet:Step 1: Connect Your Wallet and Log In Open the corresponding Tron account in imToken, switch to the “Browser” tab, and go to the admin dashboard: https://adm.payprotocol.network/login.     2. Tap “Connect Wallet”, select “imToken Wallet” → “Login”, approve the request to connect your wallet address, then tap “Sign” to complete login.Step 2: Create Receiving AddressesMerchants can create multiple separate receiving addresses (sub-contract addresses) in batches for user deposits and incoming payments: Tap the menu in the top left corner, go to “Funds” → “Sub-contracts”, then tap “Create”. Enter the number of addresses to create, such as 10, select “Recharge” as the sub-contract type, then tap “Submit”. Step 3: Make a Test PaymentBefore using the service for live payments, we recommend making a test payment to confirm that the network, token, and flow of funds work as expected: Swipe left in the sub-contract list, select one of the deposit sub-contracts you just created, then tap “View” and copy its address. Send at least 1 USDT to that address from another wallet. Once the transfer is complete, go to “Reconciliation” → “Recharge Report” to check whether the deposit has arrived. Step 4: Manage Received FundsAfter a user’s payment arrives, funds move in two stages: sweep (from the sub-contract to the cold vault) and withdrawal (to the treasurer/hot wallet).Method 1: Manual Sweep and WithdrawalBefore manually sweeping or withdrawing funds, make sure the executive wallet signing the transaction has enough of the network’s gas token, such as TRX on Tron.Fund Sweep (Sub-contract → Cold Contract Vault): Go to “Funds” → “Sweep” and select the sub-contracts you want to collect funds from in the “To Be Swept” list. Tap “Bulk Sweep”, buy Energy as needed (automatic Energy purchasing must be configured in advance), then sign to confirm the sweep transaction. Fund Withdrawal (Cold Contract Vault → Treasurer Wallet): Once the sweep is successful, open the “Asset Details” page. Tap “One-Click Fund Withdrawal”, buy Energy as needed, then sign to confirm the transaction. Once the transaction is complete, the funds will be transferred to the treasurer wallet. You can view the operation in “Fund Withdrawal Records”. 👉 View the official Pay Protocol guide: Non-API Merchant Quick Start GuideMethod 2: Enable Automatic Sweep and Withdrawal (Optional)To enable automatic sweep, automatic withdrawal, or KYT (transaction risk screening), you must first activate and fund a prepaid account:Fund Your Gas Prepaid Account: Go to “Configuration” → “Strategy Setting” → “Prepaid Account”, then tap “Deactivated” → “Deposit”. Deposit USDT into the prepaid account as a reserve for on-chain gas fees, which the system deducts automatically. Configure Automation Rules: Under “Strategy Settings”, enable sweeping strategy and/or fund withdrawal strategy and set the trigger thresholds, such as the single-transaction amount or cumulative amount.💡 Automatic checks: By default, the system checks automatic sweep conditions every 5 minutes and automatic withdrawal conditions every 30 minutes.👉 View the official Pay Protocol guide: Self-Service Payment Collection & Fund Automation Guide for Non-API MerchantsMore Resources and Official ChannelsRelated Documentation Merchant Registration Instructions Merchant API Guide Frequently Asked Questions (FAQ) Official Channels Website: https://payprotocol.network/ Admin dashboard: https://adm.payprotocol.network Official documentation: https://doc.payprotocol.network/

Can assets still be stolen from a hardware wallet built with an intact, genuine chip, running official firmware, and capable of passing the manufacturer’s Genuine Check?The recent Ledger security incident exposed precisely this seemingly impossible risk.According to Ledger’s subsequent investigation, attackers had installed an additional malicious electronic module inside the affected devices. The implant could intercept the recovery phrase displayed on the screen and transmit it to the attackers over a cellular network.In other words, the original Secure Element was never compromised. Yet the moment the recovery phrase first appeared on the screen, it could already have fallen into the attacker’s hands.And this was not the only recent security incident worth examining.Since September, incidents ranging from the exploitation of a vulnerability in a third-party security product used by Bitget, to the compromise of Trezor’s email provider Brevo, and a security incident affecting part of MetaMask’s infrastructure have delivered the same warning: as crypto products grow more complex, security can no longer be reduced to protecting private keys and preventing smart contract vulnerabilities.Risks hidden in device distribution, third-party services, internal permissions, and user communications can be just as attractive to attackers.1. Ledger Sounds a New Alarm for Supply Chain SecurityLet us first unpack what happened to Ledger.When purchasing a hardware wallet, users generally worry about two things: receiving a counterfeit device or getting one that someone has already initialized.Historically, one of the most common scams involved malicious intermediaries generating a recovery phrase in advance, printing it on a scratch card, and placing it back inside the package, hoping an inexperienced user would deposit funds without realizing the danger.The scam was serious, but the defensive logic was straightforward: buy through official channels, inspect the device’s status, let the device generate a new recovery phrase in front of you, and never use a recovery phrase supplied in the box.The recent Ledger attack was considerably more sophisticated.Attackers installed an additional electronic module inside the casing, equipped with a microcontroller, an eSIM, and cellular connectivity. When users initialize a hardware wallet for the first time, they must read the recovery phrase from its screen and write it down.The malicious implant did not interfere with the process that generated the phrase. It simply monitored the display and transmitted the phrase elsewhere.That is why saying “the private key was never extracted directly from the Secure Element” does not necessarily mean the wallet’s recovery information remained secure.More troublingly, a tampered device may still pass Ledger's official Genuine Check without the added hardware being detected. Genuine Check primarily verifies the identity of the Secure Element and the authenticity of its firmware. The check cannot detect unauthorized physical modifications such as spying implants when the original Secure Element remains intact.The incident therefore exposed a serious but often overlooked form of supply chain risk: hardware-wallet security depends not only on the chip and firmware, but also on the device’s entire journey from the manufacturer to the user.A device may pass through regional distributors, third-party warehouses, logistics providers, and retailers. Any party with physical access to it may become another risk point that needs to be assessed.The broader lesson is clear: a genuine device can still be physically modified after leaving the manufacturer's control2. From Trezor to Bitget: How Attackers Bypass the Strongest DefensesOnce the Ledger incident is understood, the recent security events affecting Bitget and Trezor reveal a remarkably similar pattern. Instead of attacking the strongest defenses head-on, the attackers entered through third-party services at the perimeter.Consider Trezor first.In early September, some Trezor users received an email titled “Critical Security Alert: STM32 Entropy Vulnerability,” claiming that their hardware wallets contained a serious vulnerability and required immediate action.Such a message could easily alarm users. Few people would remain calm after receiving a warning about a critical flaw in the hardware wallet protecting their assets.The attackers exploited Brevo, the third-party email marketing platform used by Trezor, allowing malicious content to reach users through legitimate email infrastructure.According to Brevo’s incident report, the attacker exploited an authorization-boundary flaw in its single sign-on system and gained unauthorized access to 138 customer accounts. Some of these accounts were used to send phishing emails or export contact data.Trezor subsequently confirmed that 347,149 marketing email addresses had been exported. The phishing message attempted to persuade users to download a malicious application and enter their recovery phrase.There is no evidence that Trezor’s hardware wallets or private-key protection systems were compromised. What the attacker initially obtained was user information and the ability to misuse an official communication channel.For an ordinary recipient, however, that made the attack more difficult to identify. The message could arrive from a familiar official domain and pass normal email authentication checks, while its content had already been replaced with phishing instructions.If a user then entered their recovery phrase, a breach involving a third-party email provider could escalate into an actual loss of assets.Now consider Bitget.On September 24, unauthorized asset transfers occurred from some of Bitget’s hot and warm wallets. The final confirmed amount involved was approximately $388 million.According to Bitget’s published investigation, the attacker exploited a vulnerability in a third-party security product to obtain high-level internal credentials. Those credentials were then used to access wallet-related backend systems, forge withdrawal instructions, and bypass existing risk controls, allowing fraudulent transfers to enter the normal execution process.Bitget stated that no private keys were compromised and that its cold wallets were unaffected.At first glance, this may sound contradictory. If the private keys were not stolen, how could the funds still be transferred?The answer lies in how custodial exchanges operate.When a user requests a withdrawal, an employee does not manually retrieve a private key and sign every transaction. The request moves through a complete internal workflow that includes account verification, risk review, transaction generation, and wallet signing.It is similar to a bank vault. Even if the vault key is protected with extreme care, someone who can impersonate a highly privileged employee and submit a forged transfer instruction that appears to have passed approval may still cause funds to be sent out incorrectly.The Bitget incident demonstrated how a failure in upstream access control and instruction validation could compromise the systems responsible for executing fund transfers.“No private keys were leaked” and “funds cannot be transferred without authorization” are therefore two different security claims.The infrastructure security incident disclosed by MetaMask in late September illustrated another dimension of operational risk.As a precaution, MetaMask began exiting some affected staking validators. In its October 1 update, the company said it had found no indication that MetaMask wallets or customer funds had been affected. It also emphasized that its staking operations were non-custodial and that it did not manage withdrawal keys on behalf of customers.That does not mean an infrastructure incident can have no other consequences. Non-custodial architecture primarily addresses asset control; it does not automatically eliminate the operational risks of external infrastructure.When these incidents are viewed together, the pattern becomes clear. Ledger exposed the risk of physical tampering during hardware distribution, potentially leading to recovery-phrase theft. Trezor and Brevo demonstrated the risk of user data exposure and the misuse of an official communication channel, which does not mean the wallet itself was compromised. Bitget showed how a vulnerability in a third-party product could propagate into highly privileged internal systems and directly affect the execution of fund transfers. MetaMask reminded us that asset control and operational risks associated with services are not the same thing. Crypto products today are no longer isolated islands.Wallets rely on external RPC nodes to read blockchain data and aggregation services to retrieve market information. Exchanges depend on third-party security monitoring, KYC providers, and risk-control components. Beyond these sit node operators, cloud providers, customer-support platforms, and email systems such as Brevo.These services improve efficiency and user experience. But every new external dependency also introduces another trust relationship that must be managed:What can the third party access? How much authority does it have? If it is compromised, can the resulting risk propagate into other critical systems?3. How Should Products and Users Respond?With third-party dependencies becoming more complex and interconnected, it would be unrealistic—and commercially impractical—to expect every product team to return to a model that uses no external services whatsoever.The real test of security architecture is whether it can minimize every potential attack surface.Why, for example, should a SaaS provider used only to send marketing emails retain a complete database of user contact details indefinitely? Why should a third-party security monitoring tool be able to reach a core production environment without independent, multilayer authorization? Sensitive actions involving the movement of funds must never rely on implicit trust between internal systems. They require strict permission isolation and independent cross-checks.These principles are commonly known as least privilege and separation of duties.An email platform should possess only the permissions necessary to send emails. A security monitoring tool should not be able to initiate asset transfers. A large withdrawal should not be approved solely because a single internal system submitted an instruction.The Ledger incident further demonstrates that hardware-wallet manufacturers must extend security management into the physical distribution process.From manufacturing and warehousing to logistics and reseller delivery, manufacturers need traceable procedures, methods for detecting abnormal disassembly or device substitution, and the ability to identify affected batches and users when something goes wrong.For a hardware device designed to protect private keys, delivery is not merely a channel-management issue. It is part of the security architecture itself.Ordinary users cannot audit a wallet’s software supply chain or investigate every warehouse and logistics provider that handles a hardware wallet.But that does not mean users can only accept these risks passively. Several habits can meaningfully reduce exposure.First, minimize unnecessary intermediaries when purchasing a hardware wallet.Whenever possible, order through the manufacturer’s official website and choose direct fulfillment from the manufacturer or an official warehouse. This generally reduces the opportunities for third parties to access, open, modify, or replace the device after it leaves the manufacturer’s control.From a risk-management perspective, the more independent parties that physically handle a device, the more trust assumptions the user must accept. After receiving the device, users should still inspect the packaging and casing for irregularities, verify it using official software, and follow the correct initialization procedure.Second, reconsider what it means for a message to be “official.”The Trezor incident showed that even when an email is sent through infrastructure legitimately used by the company, the links and instructions inside it are not automatically safe.Messages involving wallet upgrades, account freezes, asset migrations, or vulnerability fixes should be treated with particular caution. Instead of clicking a link inside the message, open the official website from a saved address or use the official app already installed on your device to verify the information independently.Users of non-custodial wallets such as imToken should likewise rely on official channels. Downloads should be obtained through token.im, while unusual messages should be verified through official entry points such as “Support and Feedback” within the app.No matter whether someone claims to represent customer support or a security team—or presents a highly technical explanation of a vulnerability—they should never be given a recovery phrase or private key.Finally, users need to distinguish between different types of security incidents and their actual impact.An exposed email address primarily means that the user may face more targeted phishing attempts in the future. Clicking a suspicious link requires determining whether any malicious file was downloaded or executed. If a user has entered their recovery phrase into a suspicious website or application, they should treat the wallet as compromised and act immediately.If a suspicious transaction or approval has been signed, the user must examine the specific onchain action and determine whether an ongoing contract-approval risk remains.For failures involving third-party services or infrastructure, users should refer to official disclosures and determine whether the incident affects their assets, service availability, or earnings.Hearing about a “wallet security incident” does not automatically mean that private keys have been compromised. Nor should users move assets to an unfamiliar address merely because they received an urgent security notice.In many cases, attackers are not trying to defeat the strongest technical defense themselves. They are trying to frighten users into completing the final step on their behalf.Further reading: “Can AI “Challenge” Cryptography? Web3 Must Prepare Early—but Migration Must Not Be Rushed.”Final ThoughtsFor years, one of the crypto industry’s most repeated principles has been: “Not your keys, not your coins.”That principle remains important. Control of the private keys determines whether users can truly control their own assets.But as wallets, exchanges, and onchain financial products mature, we must recognize that private-key protection is only one part of the broader security system.A genuine hardware wallet can still be physically modified during distribution. A message genuinely sent through an official email system can still be exploited by an attacker. A third-party tool originally introduced to improve security may even become an entry point into a core asset-management system.These incidents do not mean that we should stop trusting every wallet and external service. On the contrary, they show that the industry must extend security beyond individual products to cover the entire lifecycle of supply chains, permission management, user communications, and incident response.A mature crypto security architecture must do more than prevent private keys from being exposed.Even when an external component fails, the system should contain the risk before it crosses the final boundary protecting the user’s assets.

After buying ETH, many people keep a close eye on its price, but rarely look back and ask a different question: has the amount of ETH they hold changed over the past year?For ETH you plan to hold long term and do not currently need to use, there is another often-overlooked source of return: staking, which allows you to accumulate more ETH while you hold.This return comes from the Ethereum network itself. Staking is Ethereum’s native mechanism for helping secure the network. Validators participate in block validation, support the network’s operation, and receive ETH rewards according to protocol rules. Through staking, your ETH can take part in this process too.Let your ETH work for Ethereum, and for you.For long-term holders, staking adds another layer of meaning to holding ETH: you can continue holding your ETH while participating in the network and accumulating rewards. By choosing a staking model that supports compounding, eligible rewards can continue to be staked, allowing accumulation to carry on over time.And participating does not mean every user has to become a node operations expert. imToken Stake brings access to both non-custodial staking and liquid staking into the wallet experience users already know, helping ETH holders with different needs find the option that works best for them.Non-Custodial StakingNon-custodial staking is designed for users who hold 32 ETH or more and want to participate in Ethereum’s native staking while avoiding the complexity of running validators themselves.With imToken Stake, users can complete the ETH staking process directly in their wallet while retaining withdrawal control. Validator deployment, operation, monitoring, and maintenance are handled by imToken together with professional node infrastructure providers.This means users do not need to prepare their own servers or configure execution-layer and consensus-layer clients. They can participate in ETH staking with a lower technical barrier, while avoiding the need to hand withdrawal control over to a third-party custodian.This is the core value of non-custodial staking:Asset control remains with the user, while validator operations are handled by professional infrastructure providers.For long-term ETH holders, this offers a more balanced way to participate. It preserves the direct connection to Ethereum’s native staking protocol, while reducing the technical and operational burden of running validators independently.Notably, imToken’s non-custodial staking now supports a compounding mode, allowing staking rewards to accumulate within the validator and be automatically restaked, further improving capital efficiency for long-term ETH staking.Why Does Non-Custodial Staking Require Professional Operations?Non-custodial staking may look like simply depositing 32 ETH, but behind it is a validator system that needs to run continuously.Validators need to stay reliably online and correctly participate in block proposals and attestations. Node clients need to be upgraded in a timely manner. The operating environment must remain stable. Key management, monitoring, alerts, and incident response all require long-term maintenance.If a validator remains offline for an extended period, it may incur inactivity penalties. If serious violations such as double signing occur, it may face slashing risk. For most users, running a validator independently is therefore not a low-barrier option.imToken Stake’s non-custodial staking is designed to hand this operational complexity over to professional infrastructure providers. Users can focus on asset allocation and staking decisions, while service providers take responsibility for validator operation and maintenance. Each side takes on the role it is better suited for.This is not simply handing ETH over to a platform. It is a way to lower the barrier to non-custodial staking through professional node services, while preserving the user’s withdrawal control.Liquid StakingFor users who care about liquidity, imToken Stake also provides access to liquid staking. Through the liquid staking service provider Lido, users can participate in staking with smaller amounts of ETH. Lido issues stETH, a liquid token representing the user’s staking position, allowing users to retain a degree of on-chain liquidity while participating in staking.The advantage of liquid staking is its lower entry threshold and greater flexibility. It is suitable for users who want to stake smaller amounts of ETH, or who want their staked assets to continue participating in DeFi.That said, liquid staking is not a native Ethereum protocol feature. It is provided by third-party protocols. Before participating, users should understand the potential smart contract, liquidity, and other risks associated with the relevant protocol.Home StakingFor users with the technical ability and a desire to participate more deeply in building the Ethereum network, home staking remains an important option.Users can refer to Ethereum’s official documentation on home staking and validator setup, prepare their own hardware, configure the network environment, run clients, and complete validator creation and maintenance themselves.This approach requires users to take responsibility for hardware, network conditions, key backup, client upgrades, uptime maintenance, and risk management. It has the highest barrier to entry, but also gives users the greatest degree of autonomy.Home staking is better suited for users who are willing to learn over the long term, maintain their own nodes, and personally participate in Ethereum’s consensus process.One Entry Point, Three PathsThere is no single right answer to ETH staking. What imToken Stake aims to provide is not just a staking entry point, but a clearer framework for choosing how to stake ETH. It helps users understand the asset control, operational responsibilities, liquidity conditions, and risk assumptions behind each option, so they can make decisions based on their own needs.Going forward, imToken Stake will continue to focus on security, autonomy, and transparency, providing more users with a clear and reliable ETH staking experience.Stake, under your control.

For years, discussions about AI threats remained largely hypothetical. The prevailing concern was that a model inside a chat window might become a strategist for hackers, helping them write devastating malware.Looking back, such fears were often dismissed as something still far in the future. Yet the turning point in the real world has arrived sooner than many expected.In early October, while investigating a campaign targeting South Korean financial institutions, CrowdStrike found that the attackers had integrated agentic AI directly into their operational pipeline. By connecting multiple large language models, including DeepSeek, GLM, and Grok, the attackers allowed AI to perform concrete tasks such as reconnaissance, penetration testing, and attack execution.This was not an isolated development.Anthropic’s September threat intelligence report found that multi-agent frameworks had recently been used for reconnaissance, vulnerability exploitation, and data theft. These systems could operate continuously for hours or even days, while humans retained only a small number of critical decisions, such as selecting targets and reviewing results.In other words, AI is visibly changing the nature of cyber offense and defense. Automated attacks once relied mainly on predefined rules and scripts. Now, agents are beginning to take over reconnaissance, judgment, and strategy adjustment as well, making attacks cheaper, easier to scale, and capable of operating autonomously for extended periods.As more of these autonomous entities are deployed throughout production systems—and embedded more deeply in our work and daily lives—a more difficult question is emerging:What happens if agents learn to “collude” with one another?1. From Helping Hackers Write Code to Agents Finding Ways to Act on Their OwnThe most important difference between agents and traditional chatbots is not simply that the underlying models are more capable. It is that agents are beginning to acquire real-world agency.A mature agent today can browse the web, execute code, read emails, call APIs, operate cloud services, and connect to a growing range of external tools through MCP, Skills, and other infrastructure. For further reading, see “When Hackers Scale Up with AI: The Next Level of Web3’s Security Arms Race.”The more capable these agents become, the more useful they are. But from a security perspective, their capabilities are also eroding a boundary that once mattered enormously. A series of incidents this year has made that shift particularly clear.On October 1, Salt Labs disclosed a previously patched vulnerability in Manus. At its core, it was an indirect prompt-injection vulnerability. Researchers only needed to send an ordinary email containing hidden malicious instructions to the target’s inbox. When the user later asked Manus to check their email, the agent could process those instructions and ultimately execute code planted by the attacker.The attack required neither a click on a malicious link nor the prior theft of a password. Manus’s security guardrail eventually detected the abnormal behavior and warned the user—but too late. By the time the warning appeared, the malicious code had already run.This once again exposed an important difference between agent security and traditional software security.When a browser detects a dangerous download, it can display a warning and let the user decide whether to continue. When a bank detects a suspicious transaction, it can freeze the transfer before sending it for manual review.An agent, however, is designed to minimize human involvement at every step. It is expected to read information, make decisions, and proceed with the next action on its own.As AI gains more autonomy, simply “detecting danger” may no longer be enough. Security controls must be capable of stopping dangerous actions before they are executed.That is why more discussions about agent security are moving beyond prompts, content moderation, and the model itself. We should not only ask whether an AI knows that it should not perform a particular action. We must also ask whether the system can make that action impossible, even if the AI attempts it.The emergence of multi-agent systems makes this problem even more complicated. The next generation of security controls may need to constrain not just one agent, but the relationships among several agents.2. More Dangerous Than One Agent Overstepping Is Several Agents “Colluding”In early September, an incident inside OpenAI’s model training and evaluation environment attracted considerable attention from AI safety researchers.Several agents that were supposed to complete their tasks independently discovered a public wiki and gradually turned it into a shared message board. One agent could leave information there, while other agents could later read and use it to continue their own work.OpenAI subsequently confirmed the behavior. Disclosures from other training runs also showed agents using an internal Artifactory instance as a shared message board and passing results to other collaborating agents through public file-hosting services.What makes these incidents interesting is that coordination among agents does not need to look particularly dramatic.One agent discovers somewhere it can leave information. Another happens to read it. A third realizes that the information helps it complete its task.Collaboration among agents is not inherently harmful. Multi-agent systems are explicitly designed to improve efficiency through specialization and information sharing.The risk emerges when that collaboration bypasses existing information barriers, independent reviews, or permission controls—or when agents that were supposed to keep one another in check instead form a de facto alliance. At that point, normal cooperation may evolve into harmful collusion.Consider a financial institution that operates several agents simultaneously. One analyzes markets, another assesses risk, a third generates trading strategies, and a fourth has the authority to execute trades and move assets.From the perspective of traditional access control, this design appears reasonable. The research agent cannot transfer funds. The execution agent cannot independently decide what to invest in. The risk agent can reject strategies that appear excessively dangerous. Responsibilities have been separated, which should theoretically be safer than giving a single super-agent every permission.But if these agents share long-term memory, read one another’s outputs, and continually adapt their behavior based on one another’s responses, will these supposedly independent roles gradually become a single system in practice?The research agent may learn how to describe a trade in ways that are more likely to pass risk review. The review agent may develop predictable preferences based on historical data. The execution agent may then infer, from a long record of prior approvals, which boundaries are unlikely to trigger intervention.No individual step necessarily looks malicious. Yet the system’s overall behavior may already have diverged from the user’s original objective.This is what makes collusion so difficult to address. The risk may not exist in the action of any individual agent. It may instead emerge from the relationships agents form with one another.On September 13, Vitalik Buterin connected this problem with the field of mechanism design, which he has studied for many years. He suggested that adversarial governance could ultimately become an important application of mechanism-design theory in AI safety.The two problems share a deep similarity.In traditional mechanism design, a relatively simple and static institution attempts to constrain a group of participants who are far more intelligent than the institution itself and who actively search for loopholes in its rules. In future AI systems, humans and less capable AIs may similarly need to govern groups of more advanced agents.One important lesson from mechanism design is that systems are often more likely to produce desirable outcomes when collusion among participants can be effectively constrained.The same principle may apply to AI.3. Agent Wallets May Need More Than Permission ManagementInstead of assuming that a perfectly safe super-model will one day be able to detect every dangerous behavior, we can approach the problem from another direction:How can we make it structurally harder for different agents to form dangerous alliances?This is where adversarial governance differs from the access-control systems we use today.Traditional permission systems address a relatively straightforward question: who is allowed to do what?Can an agent read emails? Can it call a trading API? How much may it spend per day? Which contracts may it access? Above what threshold must the user confirm an operation again?These controls remain essential. In fact, once agents begin controlling real assets, they may become more important than ever.But adversarial governance goes one step further. It asks how a system can prevent several agents—with different permissions, objectives, and information—from combining their capabilities to obtain capabilities that no single agent was ever granted.Simply adding another “security agent” may not solve the problem.Suppose the trading agent and the agent responsible for reviewing its trades use the same model, consult the same data sources, share the same context, and optimize for similar reward signals. Although the system appears to contain two layers of review, it may simply be duplicating the same judgment.Effective checks and balances may instead require deliberate differences between agents.The agent that creates a strategy and the one that reviews it could rely on different information sources. Different roles could be restricted from sharing certain memories. High-risk operations could require independent verification mechanisms. The final asset-execution layer could accept only requests that satisfy predefined rules, rather than trusting the judgment of upstream agents.The underlying principle is not new.Banks do not allow one employee to initiate, approve, and settle the same payment. Public companies do not allow business units to generate revenue and independently audit their own financial results.A resilient system should never base its security on the assumption that participants will neither make mistakes nor collude.This principle becomes particularly important when applied to Agent Wallets.Traditional wallet security revolves around a human. The user reviews the transaction, decides whether to authorize it, and signs it personally. Agent Wallets are designed to move in the opposite direction: AI can automatically claim rewards, rebalance positions, swap assets, bridge funds, and even manage an entire portfolio in response to market conditions.If every step must be presented back to the user for confirmation, much of the value of automation disappears.The challenge for future wallets may therefore extend beyond safely delegating signing authority to an agent. They will also need to give agents enough autonomy to be useful while ensuring that they can never exceed the scope the user genuinely authorized.Authorization needs to evolve from a simple "Allow/Deny" switch into a much more granular governance framework.Such a framework may define which assets an agent can manage during a given period, which protocols it may access, and the maximum amount it can spend per transaction or in aggregate. It may determine whether different agents can call one another or share context, which agent proposes an operation, which one reviews it, and which one ultimately executes it. It must also distinguish between actions that can proceed automatically and those that require human authorization, regardless of how confident the agents may be.Even the independence of an agent responsible for security review may need to become part of the permission model.The good news is that blockchain infrastructure is particularly well suited to enforcing this institutional layer.Smart contracts can apply limits on transaction amounts, asset scope, and authorization periods directly at the execution layer. Account abstraction, multisig wallets, and session keys also provide much greater flexibility for limited delegation than traditional single-key wallets.But blockchain can solve only part of the problem. It can record what happened on-chain, yet it cannot inherently determine why an agent took a particular action—or what communication, review, and coordination occurred among several agents before the decision was made.That may be the missing security layer in the next generation of Agent Wallets.Final ThoughtsFor years, one of the most common questions in AI safety was how to make models more “obedient.”Models should not produce dangerous content, execute malicious instructions, or cross boundaries established by users. But as agents acquire long-term memory, tool access, real accounts, and the ability to execute asset transactions, making models more obedient may no longer be enough.Events over the past few months have repeatedly demonstrated this shift.Attackers are already using multiple agents to conduct parallelized operations. Agents in experimental environments have independently discovered new communication channels. And an agent with access to external tools can transform a malicious email into a real-world action before its security controls have time to intervene.Vitalik’s idea of adversarial governance offers another way to think about AI safety. Instead of assuming that every future agent will be sufficiently reliable, we can design the broader system to remain secure even when it contains highly capable agents and increasingly complex permission structures.From this perspective, the intersection of AI agents and security will inevitably remain a long-term challenge.After all, as we delegate more of our work and lives to AI, the most important question is whether we can still be certain that the powers that matter most remain within the boundaries humans deliberately set.

On the evening of September 22, a user sent an ATOM transfer.The next morning, the transaction was still marked “Pending.”The user had not lost their private key, and the wallet showed no abnormal signing activity. Yet multiple public RPC endpoints showed Cosmos Hub stalled at block height 33,086,740.No new blocks were being produced, so there was nowhere for the transaction to be included.Only after Cosmos Hub resumed block production roughly a day later did the pending ATOM transfer finally succeed.For an ordinary user, this may have been one of the clearest possible lessons in how blockchain consensus actually works.We often say that no central authority can shut down a public blockchain. The reality is more complicated. A sufficiently decentralized blockchain may have no physical “off switch” sitting in a company’s server room, but it can still stop.The Cosmos Hub halt exposed this normally invisible part of the system to everyday users.1. Why Did Cosmos Hub Suddenly Stop Producing Blocks?First, it is important to clarify a common misunderstanding: Cosmos Hub itself was not directly attacked.The incident began on Neutron.On September 22, a Neutron governance proposal titled “AIATO: AI Agent Takeover” passed. The attacker exploited chain-level governance permissions and used privileged instructions provided by the wasmd framework to reassign the administrators of application contracts associated with Astroport, Drop, and other protocols to attacker-controlled addresses.This was not a conventional code vulnerability or protocol bug.A simple analogy is that each application had its own door lock, but Neutron’s chain-level governance still held a more powerful master key. Once the attacker gained control of the governance outcome, they effectively obtained that master key. They could appoint new administrators, migrate contracts, and ultimately move the assets controlled by those contracts.Cosmos Hub became involved when some of the stolen assets were transferred across chains.According to Cosmos Labs’ incident report, the attacker moved assets to several networks before Neutron stopped operating. Approximately 1.7 million ATOM was transferred to Cosmos Hub, where the attacker began exchanging it through cross-chain liquidity.Cosmos Hub itself had not been exploited, and ordinary Hub users did not lose funds directly because of the Neutron attack.However, the stolen ATOM had already reached the Hub. To prevent the remaining funds from leaving, a group of Cosmos Hub validators began taking their nodes offline.By approximately 7:18 p.m. Singapore time on September 22, the validators that had stopped participating represented more than one-third of the network’s total voting power. Cosmos Hub could no longer reach consensus on new blocks and halted at height 33,086,740.This distinction matters.No company clicked a “Pause” button, nor did the network first conduct an onchain governance vote to stop. Cosmos Hub halted because enough validators ceased participating in consensus.What happened next is even more revealing.Approximately four hours after the halt, validators received a complete recovery plan. It proposed a one-time state change at the halted height that would move the remaining ATOM from the attacker’s address to a multisignature address managed jointly by community validators.Cosmos Labs then developed, tested, and distributed the Gaia v28.3.0 patch based on the plan accepted by validators.At the designated recovery height, the patched Gaia software would execute a single state transition, moving 1,227,121 ATOM from the attacker’s address to a 4-of-6 multisig controlled by Nansen, Keplr, Enigma, Silknodes, Kiln, and Polkachu.By early September 23, validators representing more than 67% of total voting power had confirmed that they had installed Gaia v28.3.0.Cosmos Hub coordinated its restart at 12:00 UTC that day. Approximately six minutes later, the one-time state change was executed at block height 33,086,741, and the network resumed normal block production.From halt to recovery, the sequence was clear: validators first caused the network to lose liveness. Then more than two-thirds of the voting power adopted a new state-transition rule, allowing that rule to become part of the canonical state after the restart.This leads to a deceptively simple question: if Cosmos Hub is decentralized, why can more than one-third of its voting power stop it? And why does restarting it require enough validators to accept and run the same software?The answer lies in the meaning of consensus itself.2. Consensus Does Not Mean “The Network Can Never Stop”One of the most common misunderstandings about blockchain is treating “decentralized” and “incapable of going offline” as synonyms.Consensus mechanisms actually solve a different problem: how can many independent nodes agree on transaction ordering and the state of a ledger without relying on a central bookkeeper?Different blockchains answer that question in different ways.Bitcoin’s best-known mechanism is proof of work. Miners compete to produce blocks using computational power. If two valid branches temporarily emerge, nodes continue building on the chain with the greatest accumulated proof of work.Bitcoin therefore has no explicit moment at which 67% of participants vote and a block becomes permanently finalized. Instead, it offers probabilistic finality: the more blocks that are built on top of a transaction, the more computationally expensive it becomes to reorganize that transaction out of the chain.This is why users have traditionally been advised to wait for six confirmations before treating a Bitcoin transaction as sufficiently settled. Even a miner with substantial computing power cannot simply bypass the consensus rules enforced by full nodes.That does not mean Bitcoin’s state is absolutely unchangeable under every imaginable circumstance. If the broader ecosystem adopted new client software and new consensus rules through a hard fork, a state transition that was invalid under the old rules could theoretically become valid under the new ones.The real question is who could persuade enough miners, full nodes, exchanges, wallets, and users to accept those new rules together.In practice, almost no one can.Bitcoin developers cannot unilaterally determine the network’s consensus rules, nor can miners or exchanges easily do so. The social coordination threshold is extremely high. After Binance lost 7,000 BTC in a 2019 hack, there was brief discussion of contacting major miners to reorganize the chain, but the idea went nowhere.Ethereum offers another well-known model.Since moving to proof of stake, Ethereum has used Gasper, a consensus mechanism that combines Casper FFG with the LMD-GHOST fork-choice rule.In simplified terms, one component determines which chain validators should follow, while the other allows checkpoints to achieve finality.A checkpoint must receive votes representing at least two-thirds of the total staked ETH before it can progress toward finalization. Conversely, if more than one-third of the stake fails to participate correctly for an extended period, Ethereum may temporarily stop finalizing blocks.Ethereum also includes an inactivity leak. If the network cannot finalize for long enough, the effective balances of inactive validators gradually decline, eventually allowing the participating majority to regain the two-thirds threshold and restore finality.Changing an otherwise finalized outcome would again require changes to protocol rules and client software.The 2016 DAO incident is the classic example. Through a hard fork at block 1,920,000, the Ethereum community executed what the Ethereum Foundation explicitly described as an “irregular state change,” transferring the affected ETH to a recovery contract.Not everyone accepted that decision. Some miners and community members refused to upgrade and continued maintaining the original state, ultimately creating Ethereum Classic.Cosmos Hub uses yet another model. Its CometBFT consensus is closer to a conventional Byzantine fault-tolerant (BFT) system.In simplified terms, a block requires a commit signed by more than two-thirds of the total voting power before it can be accepted.The advantage is clear finality. Once a block receives sufficient voting power and is committed, users do not need to keep waiting for additional blocks to accumulate probabilistic confidence, as they do with proof of work.The trade-off is equally direct. If validators representing one-third or more of the voting power stop providing the votes required for a commit, the remaining validators cannot reach the more-than-two-thirds threshold, no matter how hard they try.Under those conditions, the safest response is to stop producing blocks—as Cosmos Hub did during this incident.From a distributed-systems perspective, the halt was therefore not mysterious. Once validators controlling enough voting power stopped participating, the consensus protocol followed its rules: it sacrificed availability rather than confirming new blocks without sufficient agreement.This reflects two concepts that ordinary users often conflate. Safety: preventing different nodes from finalizing conflicting states. Liveness: ensuring the network can keep progressing and processing new transactions. When too few nodes participate in a BFT consensus system, temporarily losing liveness may be the price of preserving safety. Put plainly, a decentralized ledger would rather stop than allow different groups of validators to maintain conflicting versions of the truth.Seen from this perspective, many apparently unrelated incidents in public blockchain history revolve around the same question:When distributed nodes can no longer agree on the correct state, what should the network do?3. From Bitcoin to Solana: Where Are the Real Risk Boundaries of Public Blockchains?Cosmos is not the first network to expose this question.Bitcoin experienced a classic chain-split incident in 2013.Bitcoin 0.8 had switched its underlying database from Berkeley DB to LevelDB. When a block containing an unusually large number of transaction inputs appeared, version 0.8 nodes processed it normally, while some older nodes rejected it because of Berkeley DB’s lock limits.Everyone was still running Bitcoin software, but old and new clients now produced different answers to the same question: was this block valid?The network split into two chains. The version 0.8 chain temporarily held roughly 60% of the total hash power, preventing the normal proof-of-work process from quickly resolving the split on its own.Major mining pools ultimately coordinated a downgrade to version 0.7, restoring greater hash power to the chain following the older rules. The network then converged again. The incident was later documented in BIP 50.Ethereum’s 2016 DAO incident pushed the question one step further.As discussed above, the Ethereum community adopted a hard fork that executed a special state change at block 1,920,000 and transferred the affected ETH into a recovery contract.But part of the mining and user community rejected this intervention and continued following the original rules, creating the chain now known as Ethereum Classic.The DAO fork demonstrated that in an extreme event, social consensus exists alongside consensus encoded in software. If participants cannot reach sufficient agreement, one blockchain can genuinely split into two.Solana’s 2021 outage demonstrated a different failure mode.In September of that year, a flood of bot-generated transactions overwhelmed the network. Validator processes exhausted their memory and crashed, leaving the network unable to agree on the current state or confirm new blocks for approximately 17 hours. Validators then coordinated a network restart.These incidents did not have the same cause.Bitcoin’s 2013 fork occurred because different client versions began enforcing different validity rules.Solana’s 2021 outage occurred because large numbers of validators could no longer participate normally in consensus, causing the network to lose liveness.Ethereum’s DAO fork concerned whether the community should actively alter state by adopting new protocol rules.The Cosmos Hub incident added another variation. Validators first coordinated to intentionally remove enough participation for the network to lose liveness, preventing stolen assets from continuing to move. A sufficiently large share of voting power then adopted new software and a recovery state, allowing the network to reach agreement again.Rather than reducing these events to “blockchains can be switched off” or “decentralization is a lie,” it is more useful to recognize a less convenient but more accurate reality:A consensus mechanism is not a machine that can never fail. It is a decentralized set of rules defining who determines the canonical chain when disagreement occurs, how much participation is required for a state to become final, whether a network should continue or halt during a failure, and what kind of collective action can change the rules governing what happens next.This leaves ordinary users with a question more important than whether the chain should have been halted.Final ThoughtsThe crypto industry often says, “Not your keys, not your coins.”That principle remains valid. It describes control over assets: if you hold your own private key, a wallet, exchange, or other third party cannot normally sign a transfer on your behalf.But it assumes the underlying blockchain can process the signed transaction.On the day Cosmos Hub stopped producing blocks, users still held their private keys, and their assets did not disappear. Yet even a correctly signed transaction could not be processed because there was no new block to include it.The recovery process revealed something else. When a sufficient share of consensus participants accepts a new state rule, the state of a particular account can change without a transaction signed by that account’s original private key.This does not invalidate “Not your keys, not your coins.” It reminds us that sovereignty over private keys and authority over the underlying consensus are not the same thing.The same distinction applies to wallets.A wallet can ensure that users retain control of their private keys and signing authority. It can identify chain-level anomalies quickly, display transaction status accurately, maintain redundant RPC and node connections, and verify the final outcome of a transaction after the network recovers.But a wallet cannot restore consensus on behalf of a blockchain. It cannot guarantee that the underlying network will never be interrupted, nor can it guarantee that the chain’s rules and state will never change through consensus-level decisions.A mature decentralized system should therefore not pretend that nothing can ever change.Instead, it should make its imperfect boundaries as clear as possible: who can cause consensus to halt, how much voting power is required, and under what circumstances emergency intervention is permitted.True decentralization cannot guarantee that a system will never encounter a crisis.What matters is whether, when a crisis does occur, we can still determine who decided how the ledger would proceed, under which rules, and with how much consensus behind them.