727 FinanceAn incident takes away not just assets, but also trust. Crypto cannot go on like this; we must save ourselves.
Author: Robert Mao, Founder and CEO of ArcBlock
This article is authorized for anyone to freely reproduce and forward, in the hope that more people will see this call for the industry to save itself.
Crypto cannot continue like this. Again and again, massive thefts take away not only assets, but also participants' trust in the entire industry. We must save ourselves.
On October 29, 2026, a major security incident occurred at Binance. Its preliminary announcement estimated that approximately $6.3 billion in assets were affected, and approximately $3 billion of the affected assets had been frozen; the investigation initially pointed to a DevOps engineer's laptop, and subsequently other possible intrusion points were also discovered. Binance also stated that no evidence of wallet private key leakage had been found. The affected amount is not the final net loss, and the full attack chain remains under investigation. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
This initiative is addressed to the builders of blockchain projects such as Ethereum and Solana, and also to Binance, Coinbase, Kraken, and all exchanges, wallets, protocols, and security builders willing to participate: let us rebuild the foundation for protecting assets together. I am willing to participate, and I hope more people will act together.
This is already heavy enough. But what worries me more is how much confidence in Crypto this incident will destroy, and how many attackers it will lead to view this industry as a target still worth continuing to attack. Even if someone ultimately bears the losses, compensation cannot automatically repair users' trust, nor can it stop the same kind of destruction from happening again.
Binance is only the entry point that forces us to face the problem today. Looking away, exchanges, bridges, on-chain protocols, and wallets have long left a long trail of wounds. New networks and products keep appearing, yet old failure modes repeat over and over. We cannot issue an announcement, wait a while, and then treat the next incident as routine.
We must also acknowledge that scams and the practice of merely creating concepts without taking responsibility for building have harmed this industry for too long. Teams that seriously build technology and infrastructure must also bear the consequences of lost trust together. By the time people see all of Crypto as a scam, the technology and exploration truly worth preserving may also be abandoned along with it.
As the founder of ArcBlock and a practitioner in Crypto and Blockchain, I am unwilling to accept such an outcome. I believe this industry has value worth protecting, and I also believe we must take responsibility for our own security foundation. If we continue to passively wait for the next incident, repeated bleeding may ultimately destroy everything we have built together.
So, I want to issue this initiative: builders of exchanges, wallets, and blockchains should jointly rebuild the foundation of asset control and security verification, so that the scope of damage from a single intrusion is constrained. The timeline below explains why change is necessary; the technical proposal that follows is the work I believe we can begin doing.
In 2008, Satoshi Nakamoto proposed a peer-to-peer electronic cash system, attempting to make payments less dependent on trusted intermediaries. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) Yet major incidents since then have repeatedly exposed the problem of funds, authorization, and software dependencies becoming concentrated again.
Below is a chronological list of representative incidents in areas such as centralized exchanges (CEX), decentralized exchanges (DEX), bridges, and wallets. It is not a complete incident database, nor a year-by-year loss statistic. Where amounts are listed, they refer to the approximate gross impact at the time of the incident; theft, freezing, and subsequent recovery are described separately and cannot be added together as permanent losses.
2008 · Bitcoin Whitepaper
Starting point
The Bitcoin whitepaper proposed peer-to-peer payments without financial institutions as intermediaries.
Source
2011–2014 · Mt. Gox long-term theft
CEX
Mt. Gox suffered long-term theft and eventually ceased operations. A later U.S. Department of Justice indictment alleged that approximately 647,000 BTC were stolen between 2011 and 2014. This was not a single-day attack in 2014.
Source
2012 · Bitcoinica and Bitfloor
CEX / custodial infrastructure
Bitcoinica's Linode hosting environment was compromised; in the same year, Bitfloor's unencrypted wallet backup became an attack entry point. The servers and backups behind the platform are also part of the asset security boundary.
Source
2015 · Bitstamp hot wallet
CEX
Bitstamp's hot wallet was compromised, and the operating environment was subsequently rebuilt. The official distinction between the scope of the incident and offline reserves showed that isolation can limit the scope of exposure.
Source
2016 · Bitfinex
CEX
Approximately 120,000 BTC were stolen from Bitfinex. Multisignature arrangements still require end-to-end independent authorization and verification.
Source 1 · Source 2
2016 · The DAO
On-chain protocol
The DAO contract suffered a reentrancy attack, and approximately 3.6 million ETH were transferred into a sub-DAO, subsequently triggering an Ethereum fork. A legitimate execution path can produce catastrophic business outcomes.
Source 1 · Source 2
2017 · Parity shared wallet library
Contract wallet
The Parity shared wallet library was destroyed, and approximately 513,000 ETH were frozen. Even if not transferred away, funds can become unusable because of shared code dependencies.
Source
2018 · Coincheck
CEX
Coincheck's NEM hot wallet was stolen. The boundary between offline reserves, hot wallet permissions, and business needs once again became a problem.
Source
2019 · Binance
CEX
Binance announced that 7,000 BTC were withdrawn in a single transaction. Large-scale asset outflows need to be constrained before signing.
Source
2020 · KuCoin
CEX
KuCoin hot wallet incident, with a large amount of assets subsequently recovered through multi-party collaboration. The gross stolen amount and the final loss are not the same number.
Source
2021 · Poly Network
Cross-chain protocol
Approximately $612 million in assets were transferred out of Poly Network and subsequently returned in stages. Cross-chain authorization and asset control cannot hold only through normal business paths.
Source
2022 · Ronin bridge
Bridge
Ronin validator permissions were compromised, and 173,600 ETH and 25.5 million USDC were transferred out. The keys of multiple validators can also fall into the same attack chain.
Source
2022 · Slope wallet
Wallet
The Slope wallet incident in the Solana ecosystem. Solana officially stated that private key information was accidentally transmitted to an application monitoring service; it was not a compromise of Solana consensus.
Source
2023 · Euler
Lending protocol
Approximately $197 million in assets were transferred out of Euler due to a protocol vulnerability and subsequently recovered. Complex combinations in a single transaction can amplify business logic flaws.
Source
2023 · Ledger Connect Kit
Wallet connection tool
Ledger Connect Kit suffered a supply chain attack, and malicious code entered the application frontend. Hardware device security cannot replace transaction content verification.
Source
2024 · DMM Bitcoin
CEX
Approximately $308 million was stolen from DMM Bitcoin. The FBI and other agencies subsequently disclosed social engineering attacks targeting relevant personnel and the signing chain.
Source
2024 · Radiant Capital
Lending protocol / signing
Approximately $50 million was stolen from Radiant Capital, and multiple developer devices were compromised. Multi-party signing can still collectively depend on contaminated transaction information.
Source
2025 · Bybit / Safe
CEX / wallet frontend
The approximately $1.5 billion Bybit incident involved the Safe developer environment and frontend, and signers approved a transaction that changed wallet control logic.
Source 1 · Source 2
2025 · Cetus DEX
DEXThe approximately $223 million incident at Cetus on Sui, with researchers pointing to a flaw in a math library. Non-EVM environments must likewise examine their code and the scope of asset exposure.
Source
2026-07 · COLDCARD random number flaw
Hardware wallet / seed generation
A firmware flaw weakened seed generation, allowing attackers to reconstruct the relevant private keys while the device was offline. Upgrading cannot fix weak seeds that have already been generated; migration according to the advisory is still required.
Source
2026-10 · Ledger hardware implant
Hardware wallet / distribution attack
Ledger confirmed that genuine devices were modified and circulated through distribution channels in Southeast Asia, with implanted components stealing recovery phrases during initialization. The vendor says its chips, operating system, and servers were not compromised.
Source
2026 · Binance multi-chain incident
CEX / multi-chain
Binance initially estimated that approximately $6.3 billion in assets were affected, and investigations into other possible intrusion points are still ongoing. A single operating system can expose assets across multiple networks simultaneously.
Source 1 · Source 2 · Source 3
Here there are CEXs, but also decentralized exchanges, lending protocols, and bridges; there are assets stolen, and assets frozen. Attacks occur at different layers, and remediation methods differ. I oppose reducing all of this to the single sentence "users failed to safeguard their private keys." How can users know that a certain tool's development environment, a certain shared library, or an incomprehensible authorization will become the entry point to all of their assets?
Distributed networks have already done a great deal, yet fault isolation for asset control is far from sufficient. On-chain execution faithfully completes a transaction, but it cannot answer for us why that transaction has the right to move so much.
Ethereum's contribution is significant. It enabled more people to write on-chain applications and fostered a rich set of tools and development experience. But today, many new chains and L2s (layer-2 scaling networks) treat EVM compatibility as their primary goal. The EVM, the virtual machine that executes Ethereum smart contracts, is becoming a widely replicated technical premise. Compatibility does make application migration convenient; the documentation of projects such as Unichain explicitly cites reusing Ethereum tooling as the value of an equivalent execution environment. [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)
I believe that treating EVM compatibility as the industry's default answer is creating structural risk concentration. There can be many network names, and validators can differ, but developers may repeatedly deploy the same contracts, use the same authorization habits, and rely on the same software libraries. Errors in shared dependencies do not disappear just because deployment happens on another chain. This is a judgment about the technical path, not a claim that every EVM implementation necessarily has the same vulnerability.
This is also where my criticism of Ethereum lies. General-purpose contract execution capability connects directly to transferable assets, placing enormous responsibility on application code and wallet interactions. Contracts can call contracts, authorizations can persist for a long time, and a seemingly ordinary confirmation may change the subsequent control mode of an account. Security increasingly depends on every development team correctly understanding these combinations, and on every user correctly understanding what they have signed.
EIP-7702 makes this problem very clear. An ordinary transfer is "how much to whom this time"; a delegation authorization may be "from now on, let this piece of code execute operations on behalf of my account." It has the goals of improving user experience and refining permissions, but setting up a delegation itself grants broad execution capability, and fine-grained permissions still have to be correctly implemented by the delegated code. [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) The preprint "EIP-7702 Phishing Attack" by Minfeng Qi et al. studies the path of persistently controlling an account after inducing the signing of such authorizations. [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) As convenience increases, security responsibility increases as well; the former cannot simply be handed to users.
This Binance incident spans multiple chains, and the investigation is not yet complete, so the entire impact cannot be directly attributed to EIP-7702 or the EVM. Reentrancy, compromise of signing services, and front-end tampering are also not the same vulnerability. But such distinctions should not become an excuse to stop questioning the architecture: why does the underlying layer not retain more constraints that cannot be easily bypassed, on behalf of errors in the upper layers?
MEV also dissatisfies me. It refers to the space in which participants obtain extra value through the inclusion, exclusion, and ordering of transactions. To me, using ordering power to sandwich user transactions and worsen their execution results should be treated as a bug that needs fixing, not packaged as a feature worth preserving just because someone can profit from it. Ethereum's own documentation also explicitly acknowledges the harm of transaction sandwiching to users and the risk of MEV to network stability. [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV is not unique to Ethereum and also includes different activities such as arbitrage and liquidation; the industry already has mitigation research. My criticism is that the incentive to maintain the network cannot become a reason to sacrifice users' transaction conditions. A better transaction system should write the minimum delivery result and allowable fees into the authorization, and limit the space for orderers to use unfilled information to harm users.
I have always felt that Ethereum's impact on Crypto is somewhat like PHP's impact on the Internet: it enabled many people to build things, and it also left engineering debt that will take a long time to repay. PHP still needed to fix a severe remote code execution vulnerability in October 2026. Maturity and popularity cannot replace continuous hardening. [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) What is valuable about the Internet is that languages, frameworks, and cloud services can evolve separately. We should also allow different asset models and execution methods to continue developing, rather than treating "compatibility with the same virtual machine" as the ticket to participate in the ecosystem.
Therefore, I call on the Bitcoin, Solana, and Ripple/XRP Ledger ecosystems, as well as builders including ArcBlock, to seriously participate in building a common security foundation. Participating in standards and interoperability does not require first remaking oneself into Ethereum. Diversity must be implemented in asset control and verification methods and be open to public scrutiny. The Slope and Cetus incidents have already reminded us that non-EVM does not have a security exemption either.
What I hope to see take shape is a security specification that different execution environments can all adopt: the same asset limits and verification requirements can be implemented separately by the EVM and other paths, and then the guarantees and costs of each can be publicly examined.
1. Let underlying risk controls constrain the power to dispose of assets
Large wallets should be able to set recipient whitelists, cumulative spending caps, and waiting periods for new recipients. The key is that these rules cannot be immediately canceled by the same everyday transaction key. Modifying the rules requires independent authorization and must leave time for monitoring and revocation.
Existing smart accounts already have an implementation basis, for example Safe Guards can add transaction restrictions beyond multisig. [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) We need to make this an easier-to-adopt foundational capability that covers all asset control paths. If only direct transfers are restricted while bypasses through unlimited approvals, modules, or upgrades are allowed, the protection will fail. Whether the whitelist contract can be upgraded and whether the recipient's permissions have changed must also enter the verification scope.Apple's Activation Lock offers an everyday-life inspiration: it restricts the reactivation of stolen devices and limits the calibration of certain stolen parts, with the goal of reducing the value that can be exploited after theft. [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) Wallets are also worth designing in this direction. If an attacker obtains a key, the range of assets that can be cashed out remains limited, and the expected return from an attack may decline; risks such as disrupting services still need to be handled separately.
This is what I call the "constitution" of asset security: operational authority may be compromised, but the authority to modify boundaries should remain independent. Recovery processes must also be constrained, to prevent a single misconfiguration from permanently locking up assets.
II. Make wallets bear security responsibility, rather than merely handing over mnemonic words
I have a strong dissatisfaction with today's wallet systems: if a product asks an ordinary person to copy down a set of words, requires that they never leak, lose, or be tricked out of them, and then attributes all subsequent failures to user responsibility, I consider this an irresponsible design. Self-custody should give people control, and it should also give people usable protection and recovery capabilities. It should not require every user to first become a security expert. This is also a threshold that Crypto must cross to reach more ordinary users.
Recent incidents have put this problem squarely on the table. In October 2026, Ledger confirmed that attackers modified genuine devices and then sent them back to market through distribution channels in Southeast Asia, with implanted components stealing recovery words during initialization. Ledger defined this as a localized distribution attack after the device left the factory, rather than a compromise of its chip, operating system, or servers. [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) COLDCARD's July incident involved firmware weakening seed generation: the device did not need to be remotely controlled for an attacker to reconstruct the relevant private keys. Updating the firmware fixes the generation process going forward, but weak seeds that have already been generated still need to be migrated. [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)
These two incidents are not the same kind of vulnerability, yet together they show: even if users carefully copy down the words and keep the device offline, they cannot verify randomness and the integrity of the supply chain on behalf of the manufacturer. Having the device display backup words has the purpose of offline recovery, but it also causes the complete recovery secret to pass through a display and backup path that needs protection. Chip security cannot replace verification of the entire device and the delivery process.
The goal of improvement should be the complete wallet lifecycle: how keys are generated, how transactions are explained, how permissions are separated, and how recovery works after a device is lost. Account abstraction, that is, allowing accounts to verify authorization through programmable rules, and threshold backups such as SLIP-39, both already have standards and implementation foundations, so it cannot be said that no one in the industry is working on them. [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) But we need to make these capabilities tested, easy-to-use protections, rather than having users assemble complex schemes on their own.
Simple obfuscation of mnemonic words is not enough. More reliable directions include reviewed encrypted backups, threshold recovery, and independent device authorization, and having users complete recovery drills before depositing large amounts of assets. Backup shards and multisig are different layers: the former may recombine into the same secret during recovery, while the latter requires multiple independent signers to approve a transaction. Recovery services must not quietly become a new master key, nor should an extra password become another trap where losing it means unrecoverable loss.
Personal wallets and exchange wallet systems can share security specifications for transaction descriptions, signing requests, asset restrictions, and recovery processes, while adopting different limits and approval policies. Bitcoin's PSBT already provides a format for passing unsigned transactions across tools, and this common interface is worth continuing to build. [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) What is common is the checkable security requirements; each chain still needs to clarify its own adaptation rules. Wallets should clearly present what this signature will transfer and how much subsequent authority it grants to whom, and independent policies should reject out-of-bounds operations; a prettier confirmation page is not enough.
III. Achieve verifiability with minimal necessary disclosure
Proving that a condition holds should not always require users to disclose all underlying data. Selective disclosure, zero-knowledge proofs, and audit access granted on demand should become normal options in infrastructure. This is also related to asset security: public identity and asset relationships may provide clues for targeted deception; data that the business does not need should be exposed as little as possible.
The W3C's verifiable credential system already has a technical path for selective disclosure; however, proving that inputs are authentic, that credentials remain valid, and how status is revoked still needs to be clarified. [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) Adopting zero-knowledge proofs (ZK) does not automatically hide transaction amounts and relationships; scaling proofs and privacy protection are different goals.
For example, when a business only needs to verify eligibility to participate, a user can present a valid eligibility conclusion issued by a trusted institution without disclosing complete financial materials. When it is necessary to prove that a hidden value satisfies a condition, an appropriate proof mechanism can then be used. The trusted source of the credential and its revocation status still need to be verified.
My initiative is to first clarify "who needs to verify what," and then design the data that must be made public. Those verifying eligibility may only need the eligibility conclusion; those bearing specific audit responsibilities can obtain restricted evidence. Publicly verifiable constraints should minimize personal information permanently exposed to everyone.
IV. Make transaction services as free from centralized custody as possible
Trade matching, path finding, and asset settlement should be designed separately. A service providing a trading entry point should obtain only the permissions necessary to complete the current settlement as far as possible, so that user assets remain under their respective control the rest of the time. Existing intent-based transaction protocols have already explored part of the path, and the industry can continue to complete it. [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)
What users agree to should be clear settlement conditions, including what is paid, what is received at minimum, when it expires, and the permitted fees. After a trading service is compromised, the attacker may deny service, but cannot arbitrarily change these conditions. Businesses that still require centralized custody should also separate reserve and operational permissions, and limit hot wallet exposure and automatic replenishment limits.
IBIT is iShares' bitcoin exchange-traded product, and what trades on the market are its shares. Its arrangement provides an example of partial isolation: shares and the underlying Bitcoin are recorded separately, and the relevant private keys for the Vault Balance (custody balance) are placed in cold storage. Changes in the share trading record do not require the underlying Bitcoin to move with each transaction. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) What can be learned from this is the separation of trading rights and reserve disposal rights. Its Trading Balance (trading service balance) has a different arrangement, and custody itself also carries risks; cold storage must be paired with independent instruction and signature verification.
I compare the trading entry point to a router in the hope that it can be replaced without carrying a master switch over all users' assets. Settlement is more complex than packet forwarding, and asset delivery and authorization still need to be independently verified. Making a service non-custodial and then granting it unlimited withdrawal rights will only bring centralized risk back.
V. Use a layered architecture to isolate failures and preserve replaceability
We need identity and authorization interfaces, asset policies, and settlement verification methods that can evolve independently. Different chains can retain their own execution models and connect through clear interfaces. Interfaces should state the security guarantees and their conditions, not merely say "the call succeeded."Internet experience supports this approach. In RFC 9518, "Centralization, Decentralization, and Internet Standards," Mark Nottingham specifically discusses situations in which centralization can be helpful, and also analyzes the power and risks it brings. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) This is exactly the attitude worth learning from: let the architecture answer which responsibilities can be centralized, to what degree, and how to prevent that power from expanding. A service can be allowed to centrally identify anomalies while its permission to touch assets is limited; users should be able to switch services without losing their own asset policies and verification records.
The most important acceptance question is: after a business service is compromised, which independent layer can still reject it? If all layers share one administrative key, so-called layering is only layering on a deployment diagram.
This goal can be viewed as five layers of responsibility: the transaction service submits requests, the wallet expresses user intent, independent policy limits authority over asset disposition, the verification component checks operations and evidence, and the settlement layer enforces constraints and provides verifiable records. They can be implemented by different teams, and their dependencies and failure conditions must also be described separately.
The target architecture advocated in this article. The settlement layer must enforce asset policy; prompts in the wallet cannot replace this constraint. Daily signing, rule changes, and recovery authority need to be isolated and subjected to bypass testing.
6. Let users lightly verify their own assets
Ordinary people should not have to store and execute the entire history of the whole chain in order to verify their own balances and receipts; nor should they have to trust only a single server behind the wallet. Satoshi Nakamoto already proposed SPV, simplified payment verification, in Section 8 of the whitepaper. Bitcoin's BIP-157 continues to explore letting clients download filters and find blocks related to themselves; Ethereum also has light client designs. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) So the problem is not that no one has ever thought of it, but that we still need to build verification capability with clear security conditions into the wallets users use every day.
Take a chain that supports account state proofs as an example: when querying a balance, the server should return both the balance and a proof. The wallet first verifies a short block digest, that is, the block header, according to the rules of that chain, and then checks whether this balance is consistent with the data committed to by the digest. The server provides the answer, and the wallet can verify the answer. Bitcoin's SPV verifies evidence that relevant transactions were included; it cannot be directly copied as a balance proof. The wallet should also clearly display where it has synchronized to and which information has been verified; when proofs are missing, data is stale, or sources conflict, it should warn or stop high-risk operations that rely on this information, and must not quietly fall back to blind trust.
Light verification still has conditions. Proving that a transaction was included in a block is not the same as checking by oneself that all transactions in the block are valid. Different schemes may rely on a majority of hash power being honest, or on a trusted initial record, that is, a checkpoint; they must also guard against servers withholding data or isolating users on a stale chain record. Whether the query itself exposes the addresses a user cares about also needs to be handled. Full nodes and block producers are not the same role; Ethereum today uses validators rather than miners for block production.
More importantly, proving that "this transfer really happened on-chain" cannot prove that "this is exactly the transfer the user wanted." Light clients cannot replace the earlier asset limits and signature checks. They let users rely less on an unverifiable answer, while asset policy ensures that even a valid signature cannot dispose of assets without limit. Only by building both layers together can verification capability be distributed among participants.
7. Build anomaly identification and security verification as public infrastructure
Before a transaction, someone should check whether the operation complies with asset policy and whether it suddenly changes historical behavior. Obvious anomalies can trigger a pause or escalated review; expanding permissions requires another independent path. AI can participate in judgment, but should not receive a pass that overrides hard rules.
At the same time, we need to jointly maintain attack cases, permission tests, and verification tools that can be run repeatedly. Only by sharing specifications and preserving independent implementations and independent verification can common-mode failures be reduced. Foundations and exchanges already have security investments, such as the Ethereum Foundation's Trillion Dollar Security Initiative. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) The next question to ask is whether the investment can be transformed into public infrastructure that other teams can also adopt and inspect.
None of these seven work items can guarantee absolute security. What they need to deliver is inspectable boundaries: under what conditions of permission compromise, how much assets are exposed at most, how quickly anomalies can be discovered, and whom recovery still depends on.
At this point, some may say: the direction sounds right, but the industry has already gone on for so many years; how many people and how much time would reconstruction require? Isn't this still idealism?
If estimated according to the past mode of software production, this doubt is very realistic. But by 2026, I believe coding agents and AI-enabled software engineering have already changed the construction capacity we can mobilize. The coding agents mentioned here are AI programming assistants that can read and write code, call tools, run tests, and continue working based on feedback in a development environment. Builders set goals, define security boundaries, use these tools to implement and check systems, and take responsibility for the results.
Work that previously required large teams to repeatedly implement, adapt, and maintain can now be attempted by small teams with this new engineering approach. One team holds one layer, delivers components around clear interfaces, and then other teams inspect and combine them. Organizing human architectural judgment, the implementation capacity of coding agents, and independent security verification is, in my view, the construction path worth seriously reassessing.
Research by Anthropic and PNNL gives a concrete example: in a limited critical infrastructure simulation environment, researchers reported that attack reconstruction was shortened from possibly several weeks to about three hours. [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) It cannot prove that a small team can already safely rewrite the entire industry, but it shows that previously expensive verification and offense-defense work can have new cost conditions.
One organizational approach that can be started now is to jointly build a Build in Public AI Factory. Industry experts, scholars, and practitioners openly write requirements and acceptance specifications (spec), explaining what is to be protected, which operations are allowed, and what boundaries must still hold after which permissions are compromised, and then turn these requirements into acceptance tests. Groups of coding agents take on the main coding, testing, and debugging work; different teams inspect designs and results, and humans bear judgment and acceptance responsibility.
Participants can contribute ideas, machines, computing power, and model invocation quotas, that is, AI tokens. AI and cloud computing companies can also support this public construction through model quotas, computing resources, and tools. Specs, prototype code, agent workflows, test environments, and verification results can all become commonly maintained infrastructure, allowing the next team to continue directly from there. The goal is to build development capacity into reusable public facilities and reduce dependence on any one person's time or any one team.
Attackers are also using AI, and we no longer have reason to leave defense in the production methods of the past. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) But code generation being fast is only the starting point. Only by writing constraints clearly, making tests repeatedly runnable, and making a component inspectable and replaceable can AI capability be transformed into infrastructure improvement.
Independent builders work together with the help of coding agents and AI tools. The space workshop is a metaphor for public construction.I especially want to address this call to those who still love to build. The "hacker" here refers to someone willing to figure out how a system works, willing to share what they find, and willing to let others test their work. That spirit once drove the Internet forward, and today it can drive Crypto forward too.
I don't believe this industry lacks smart people, and I don't believe the Crypto and AI industries can't find the resources to support this work. What's harder is organizing talent, funding, and sustained responsibility together. Foundations and capable companies should be willing to bear the long-term cost of foundational work that doesn't directly generate revenue but benefits everyone.
I hope everyone can work together to build a globally shared cryptographic infrastructure. Different networks and teams can collaborate under shared security constraints, each implementing their own solutions and testing each other's, and users can choose and migrate. It can start with a single component, but the direction should be big enough to accommodate the entire industry building together. All participants, including ArcBlock, should contribute verifiable work.
We should jointly build a kind of infrastructure where, even if some part has been compromised, assets still have boundaries, other systems can still reject errors, and users still have paths to recovery and exit. Borrowing the name from Star Wars, this is our A New Hope. [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) The hope comes from ordinary builders willing to act, and also from this moment when coding agents and new engineering methods enable them to take on more building work.
I want to extend an invitation to the builders of projects such as Ethereum, Solana, Bitcoin, and XRP Ledger, to exchanges such as Binance, Coinbase, and Kraken, and also to wallet, protocol, security research, AI, and cloud computing teams: start with a clearly scoped pilot and jointly produce improvements that other teams can adopt and test.
The names listed are examples only, in no particular order. Regardless of size or which technical path you take, you are welcome to participate. This invitation also includes the builders of the technical paths criticized in this article; jointly improving asset security is worth crossing the boundaries of our respective ecosystems.
I myself am willing to participate and contribute our existing infrastructure, software engineering, and AI collaboration practices. We are just a small team in the industry, and what we can do is limited. I hope to start with a prototype and a set of repeatable tests.
People with practical operational experience can provide desensitized attack scenarios, wallet and protocol teams can implement protections, and independent researchers can try to bypass them. Each team takes on the part it can handle, jointly testing the solution and deciding the next step.
I am willing to participate in organizing the asset limitation and recovery requirements in this article into the first public spec, and I am also willing to contribute relevant technical and engineering practices to build, together with other participants, a public AI Factory for this pilot. First choose a very specific problem: once the everyday transaction key has been compromised, how can the attacker still be prevented from draining the wallet all at once? Write the allowed loss range, the authority to modify rules, and the recovery conditions into acceptance tests, then have development agents implement a prototype, and have another group of agents and independent researchers look for bypass paths. Data servers returning incorrect balances, and recovery after device loss, can also be gradually added to the tests. What the prototype achieves, where it fails, and what dependencies remain should all be publicly explained, and the next step should be decided based on evidence.
Those willing to participate are welcome to publicly repost or quote this initiative on X and @mave99a, and talk about the problem you want to solve, desensitized attack cases, or the resources you can contribute. I hope the discussion proceeds publicly, so that more builders can see it and join in.
Crypto cannot continue like this. Those willing to work together, let us act now, starting with one improvement that can be built and can withstand testing.
Binance, initial announcement official post and follow-up investigation official update, 2026-10-30; TRM multi-chain analysis. This draft was verified as of 2026-10-30; investigation and recovery status may change. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)
Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)
Uniswap, Unichain EVM Equivalence. The risk concentration of shared dependencies is the author's judgment in this article, not a conclusion of that document. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)
Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, created 2024-05-07. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)
Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, arXiv v1 preprint; not an identification of this Binance incident. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
Ethereum, Maximal extractable value (MEV), ordering mechanisms, different types, and negative effects; "should be fixed as a bug" is the author's engineering position on behavior that harms users. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
PHP official 2026 news archive; CISA 2026-10-26 Known Exploited Vulnerabilities update, CVE-2026-109618, CVE-2026-109619. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)
Safe, Guards and Modules, description of functionality and permission risks. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)
Apple, Apple to expand repair options with support for used genuine parts, 2024-04-11; current parts pairing support description. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger, Ledger's Response to the Hardware Implant Attack, 2026-10, vendor statement on an attack in the distribution chain; Joe Grand, reverse engineering research on hardware implants. Do not present unverified network loss estimates as definitive conclusions. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
Coinkite, Current COLDCARD Security Status, accessed 2026-10-30, continuously updated record of the July 2026 incident and remediation; upgrading and seed migration are two distinct operations. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: Account Abstraction Using Alt Mempool; Trezor, SLIP39 FAQs, threshold recovery, compatibility, and additional passphrase risks. Existing mechanisms are a foundation for building, and do not mean every deployment is reliable. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)
BIP-174: Partially Signed Bitcoin Transaction Format, an exchange format for unsigned transactions, not a cross-chain general asset strategy specification. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)
W3C, Verifiable Credentials Overview v1.0, 2026-07-30 Group Note; Ethereum privacy notes. The standards status of the technologies described in the overview is independent in each case. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
CoW Protocol documentation, transaction intents and solver mechanisms; this article does not provide a comprehensive security endorsement for any specific deployment. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)
iShares, IBIT 2025 Annual Report, PDF pages 8–10 custody arrangements and page 45 risk disclosures. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)
Mark Nottingham, RFC 9518: Centralization, Decentralization, and Internet Standards, 2023-12, independently submitted, informational RFC, not a standards-track specification. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
Bitcoin whitepaper Section 8 Simplified Payment Verification; BIP-157: Client Side Block Filtering; Ethereum, Light clients. Different light clients have different verification scopes and trust conditions. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
Ethereum Foundation, Announcing the Trillion Dollar Security Initiative, 2025-05-14. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic, AI to defend critical infrastructure, 2026-01-08, limited-environment research in collaboration with PNNL. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic, Mapping AI-enabled cyber threats, research on actual abuse samples. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm, Star Wars: A New Hope (Episode IV), 1977; this article borrows the title and the imagery of joint self-rescue. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)