Crypto Can’t Go On Like This: An Industry Self-Rescue Initiative from a Blockchain Practitioner

Author: Robert Mao, Founder and CEO of ArcBlock

This article is authorized for free reproduction and forwarding by anyone, hoping to let more people see this call for industry self-rescue.

Crypto can’t go on like this. Repeated large-scale thefts have taken away not only assets but also participants' trust in the entire industry. We must rescue ourselves.

On October 29, 2026, Binance experienced a major security incident. Its preliminary announcement estimated that approximately $6.3 billion in assets were affected, with about $3 billion in affected assets frozen; investigations initially pointed to a DevOps engineer's notebook, and later other potential points of intrusion were 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 complete attack chain is still under investigation.[[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/ " \l "fn-binance)

This initiative is addressed to builders of blockchain projects like Ethereum and Solana, as well as to exchanges, wallets, protocols, and security builders like Binance, Coinbase, and Kraken: let us rebuild the foundation that protects assets together. I am willing to participate and hope more people will take action.

This is already heavy enough. But I am more concerned about how many people's confidence in Crypto this incident will shatter, and how many attackers will see this industry as a target worth continuing to exploit. Even if someone ultimately bears the losses, compensation cannot automatically restore users' trust, nor can it stop the same kind of destruction from happening again.

Binance is just the entry point that forces us to face the problem today. Looking away, exchanges, bridges, on-chain protocols, and wallets have long left a string of wounds. New networks and products keep emerging, yet old failure patterns repeat. We cannot just issue an announcement, wait for a while, and then treat the next incident as routine.

We must also acknowledge that scams and practices that only create concepts without taking on construction responsibilities have harmed this industry for too long. Teams that seriously work on technology and infrastructure must also bear the consequences of lost trust. By the time people see the entire Crypto as a scam, the truly valuable technologies and explorations may also be abandoned.

As the founder of ArcBlock and a Crypto and Blockchain practitioner, I refuse to accept such an outcome. I believe this industry has values worth protecting, and I think we must take responsibility for our security foundation. If we continue to passively wait for the next incident, the repeated bloodletting may ultimately destroy everything we have built together.

Therefore, 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 illustrates why change is necessary; the technical solutions that follow are what I believe can be started.

This Incident Timeline Has Been Too Long

In 2008, Satoshi Nakamoto proposed a peer-to-peer electronic cash system, attempting to reduce reliance on trusted intermediaries for payments.[[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/ " \l "fn-bitcoin) However, subsequent major incidents have continuously exposed the issues of re-concentration of funds, authorizations, and software dependencies.

Below is a chronological list of representative events in the fields of centralized exchanges (CEX), decentralized exchanges (DEX), bridges, and wallets. It is not a complete incident database, nor is it a yearly loss statistic. Amounts listed are approximate gross impacts at the time of the incident; thefts, freezes, and subsequent recoveries are explained separately and cannot be summed as permanent losses.

2008 · Bitcoin White Paper

• Starting Point
• The Bitcoin white paper proposed peer-to-peer payments without the need for financial institutions as intermediaries.
• Source

2011--2014 · Mt. Gox Long-Term Theft

• CEX
• Mt. Gox was subject to long-term theft and ultimately ceased operations. The subsequent indictment by the U.S. Department of Justice alleged that approximately 647,000 BTC were stolen between 2011 and 2014. This was not a single attack that occurred in 2014.
• Source

2012 · Bitcoinica and Bitfloor

• CEX / Custodial Infrastructure
• Bitcoinica's Linode hosting environment was breached; the same year, Bitfloor's unencrypted wallet backup became an attack entry point. The servers and backups behind the platform are also the boundaries of asset security.
• Source

2015 · Bitstamp Hot Wallet

• CEX
• Bitstamp's hot wallet was hacked, and the operating environment was subsequently rebuilt. The official statement distinguished the scope of the incident from offline reserves, indicating that isolation can limit exposure.
• Source

2016 · Bitfinex

• CEX
• Approximately 120,000 BTC were stolen from Bitfinex. Multi-signature arrangements still require end-to-end independent authorization and verification.
• Source 1 · Source 2

2016 · The DAO

• On-Chain Protocol
• The DAO contract was subjected to a reentrancy attack, with approximately 3.6 million ETH transferred to a child DAO, subsequently triggering a fork of Ethereum. Legitimate execution paths can lead to catastrophic business outcomes.
• Source 1 · Source 2

2017 · Parity Shared Wallet Library

• Contract Wallet
• The Parity shared wallet library was destroyed, freezing approximately 513,000 ETH. It was not transferred away, but it may have lost usability due to 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 became an issue again.
• 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 subsequent recovery of a large amount of assets through multi-party collaboration. The gross stolen amount and final loss are not the same figure.
• Source

2021 · Poly Network

• Cross-Chain Protocol
• Approximately $612 million in assets were transferred out of Poly Network, which were subsequently returned in stages. Cross-chain authorization and asset control cannot rely solely on normal business paths.
• Source

2022 · Ronin Bridge

• Bridge
• The Ronin validator permissions were compromised, with 173,600 ETH and 25.5 million USDC transferred out. Keys from multiple validators may also have fallen into the same attack chain.
• Source

2022 · Slope Wallet

• Wallet
• The Slope wallet incident in the Solana ecosystem. Solana officials pointed out that private key information was accidentally sent to application monitoring services; it was not a breach of Solana consensus.
• Source

2023 · Euler

• Lending Protocol
• Approximately $197 million in assets were transferred out of Euler due to protocol vulnerabilities, which were subsequently recovered. Complex combinations of single transactions can amplify business logic flaws.
• Source

2023 · Ledger Connect Kit

• Wallet Connection Tool
• The Ledger Connect Kit was subjected to a supply chain attack, with malicious code entering the application frontend. Hardware device security cannot replace transaction content verification.
• Source

2024 · DMM Bitcoin

• CEX
• Approximately $308 million were stolen from DMM Bitcoin. The FBI and other agencies subsequently disclosed social engineering attacks targeting relevant personnel and signature links.
• Source

2024 · Radiant Capital

• Lending Protocol / Signature
• Approximately $50 million were stolen from Radiant Capital, with multiple developer devices compromised. Multi-signatures may still rely on contaminated transaction information.
• Source

2025 · Bybit / Safe

• CEX / Wallet Frontend
• Approximately $1.5 billion incident at Bybit, with attacks involving the Safe developer environment and frontend, where signers approved transactions that changed wallet control logic.
• Source 1 · Source 2

2025 · Cetus DEX

• DEX
• Approximately $223 million incident at Cetus on Sui, with researchers pointing out defects in the math library. Non-EVM environments must also verify code and asset exposure.
• Source

2026-07 · COLDCARD Random Number Defect

• Hardware Wallet / Seed Generation
• Firmware defects weakened seed generation, allowing attackers to reconstruct relevant private keys while the device was offline. Upgrades cannot fix already generated weak seeds, and migration must still follow announcements.
• Source

2026-10 · Ledger Hardware Implant

• Hardware Wallet / Distribution Attack
• Ledger confirmed that genuine devices were modified and circulated through Southeast Asian distribution channels, with implanted components stealing recovery phrases during initialization. The manufacturer claimed that its chips, operating systems, and servers had not been breached.
• 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 potential points of intrusion are ongoing. A single operational system can expose assets across multiple networks simultaneously.
• Source 1 · Source 2 · Source 3

Here we have CEX, decentralized exchanges, lending protocols, and bridges; there are stolen assets and frozen assets. Attacks occur at different layers, and repair methods vary. I oppose attributing all of this to a single statement: "Users didn’t manage their private keys well." How can users know that a certain tool's development environment, a certain shared library, or an incomprehensible authorization will become the entry point for all their assets?

Distributed networks have done a lot, but fault isolation in asset control is far from enough. On-chain execution faithfully completes a transaction but cannot answer why this transaction has the right to move so many things.

Let Different Technical Routes Jointly Build a Security Foundation

Ethereum has made significant contributions. It has enabled more people to write on-chain applications, resulting in a wealth of tools and development experience. However, today, many new chains and Layer 2 (L2) networks prioritize EVM compatibility as a primary goal. The EVM, which is the virtual machine that executes Ethereum smart contracts, is becoming a widely replicated technological prerequisite. Compatibility indeed facilitates application migration; projects like Unichain explicitly highlight the value of reusing Ethereum tools as an equivalent execution environment.

I believe that treating EVM compatibility as the industry 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 will not disappear simply because they are deployed on another chain. This is a judgment on the technological route, not to say that every EVM implementation necessarily has the same vulnerabilities.

My criticism of Ethereum lies here. The universal contract execution capability directly connects transferable assets, placing immense responsibility on application code and wallet interactions. Contracts can call other contracts, authorizations can persist long-term, and a seemingly ordinary confirmation can alter subsequent account control methods. Security increasingly relies on each development team correctly understanding these combinations, as well as each user correctly understanding what they have signed.

EIP-7702 illustrates this issue clearly. A regular transfer is about "how much to send to whom"; delegated authorization may mean "allow this piece of code to perform operations on my account in the future." It aims to improve user experience and segment permissions, but setting up delegation itself grants broad execution capabilities, and fine permissions must be correctly implemented by the delegated code. Minfeng Qi and others' preprint "EIP-7702 Phishing Attack" studies the pathways that allow continued control of accounts after signing such authorizations. As convenience increases, security responsibilities also rise; we cannot solely place the former on users.

The recent Binance incident spans multiple chains, and the investigation is ongoing; we cannot directly attribute all impacts to EIP-7702 or EVM. Reentrancy, signature service breaches, and front-end tampering are not the same vulnerabilities. However, this distinction should not serve as an excuse to stop questioning the architecture: why does the underlying layer not retain more constraints that cannot be easily bypassed to protect against upper-layer errors?

MEV also frustrates me. It refers to the space where participants exploit transaction inclusion, exclusion, and ordering to gain additional value. To me, using ordering rights to squeeze user transactions and worsen their execution outcomes should be treated as a bug that needs fixing; it cannot be packaged as a feature worth preserving just because someone can profit from it. Ethereum's own documentation also clearly acknowledges the harm of sandwich trading to users and the risks MEV poses to network stability. MEV is not unique to Ethereum; it includes various activities such as arbitrage and liquidation, and the industry has already conducted mitigation research. My criticism is that maintaining network incentives cannot justify sacrificing user transaction conditions. A better trading system should incorporate minimum settlement outcomes and allowed fees into authorizations and limit the space for orderers to exploit unexecuted information to harm users.

I have always felt that Ethereum's impact on Crypto is somewhat akin to PHP's impact on the internet: it has enabled many people to create things but has also left a long-term engineering debt to repay. PHP still needs to fix serious remote code execution vulnerabilities as of October 2026. Maturity and popularity cannot replace ongoing fortification. The value of the internet lies in the separate evolution of languages, frameworks, and cloud services. We should also allow different asset models and execution methods to continue developing, rather than treating "compatibility with the same virtual machine" as a ticket to participate in the ecosystem.

Therefore, I call on the Bitcoin, Solana, Ripple/XRP Ledger ecosystems, and builders including ArcBlock to seriously engage in the construction of a shared security foundation. Participation in standards and interoperability does not require first transforming oneself into Ethereum. Diversity must be realized in asset control and verification methods, accepting public scrutiny. The incidents involving Slope and Cetus have already reminded us that non-EVM also has no safety exemptions.

What I hope to form is a security standard that can be adopted by different execution environments: the same asset restrictions and verification requirements can be implemented separately by EVM and other routes, and their respective guarantees and costs can be publicly scrutinized.

Seven Reinforcement Measures to Start

1. Let the underlying risk control constrain asset disposal rights

Large wallets should be able to set up recipient whitelists, cumulative spending limits, and waiting periods for new recipients. The key is that these rules cannot be immediately canceled by the same daily transaction key. Modifying rules requires independent authorization and must leave time for monitoring and revocation.

Existing smart accounts already have a foundation for implementation; for example, Safe Guards can add transaction restrictions beyond multi-signature. We need to make this easier to adopt and capable of covering all asset control paths. Limiting direct transfers while allowing circumvention through unlimited authorization, modules, or upgrades will void the protection. Whether whitelisted contracts can be upgraded and whether the recipient's permissions have changed must also fall within the verification scope.

Apple's Activation Lock provides an everyday inspiration: it restricts the reactivation of stolen devices and limits the calibration of certain stolen parts, aiming to reduce the value that can be exploited after theft. Wallets should also be designed in this direction. If an attacker obtains one key, the range of assets that can be liquidated remains limited, which may reduce the expected returns from the attack; risks such as service disruption still need to be addressed separately.

This is what I refer to as the "constitution" of asset security: operational permissions can 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 assets.

2. Hold wallets accountable for security, not just for handing over mnemonic phrases

I have a strong dissatisfaction with today's wallet systems: if a product requires ordinary people to write down a set of words, demanding that they never leak, lose, or be deceived, and then attributes all subsequent failures to user responsibility, I believe this is an irresponsible design. Self-custody should give people control, but it should also provide usable protection and recovery capabilities. It should not require every user to first become a security expert. This is also a hurdle that Crypto must overcome to reach more ordinary users.

Recent incidents have highlighted this issue directly. Ledger confirmed in October 2026 that attackers modified genuine devices and sent them back to the market through Southeast Asian distribution channels, implanting components that stole recovery phrases during initialization. Ledger defined this as a localized distribution attack after the device left the factory, rather than a breach of its chips, operating systems, or servers. The July incident involving COLDCARD involved firmware weakening seed generation: the device did not need to be remotely controlled, and attackers could also reconstruct relevant private keys. Updating the firmware fixes the generation process going forward, but already generated weak seeds still need to be migrated.

These two incidents are not the same vulnerability, but they both illustrate that even if users carefully write down the words and keep the devices offline, they cannot replace manufacturers in verifying random numbers and the integrity of the supply chain. Allowing devices to display backup phrases has offline recovery purposes, but it also exposes the complete recovery secret through a path that needs protection for display and backup. Chip security cannot replace the verification of the entire device and delivery process.

The goal of improvement should be a complete wallet lifecycle: how keys are generated, how transactions are interpreted, how permissions are separated, and how recovery is conducted after device loss. Account abstraction, which allows accounts to verify authorizations through programmable rules, and threshold backups like SLIP-39 already have standards and implementation foundations; we cannot say that no one in the industry is working on this. However, we need to make these capabilities verified and easy to use protections, rather than forcing users to assemble complex schemes themselves.

Simple confusion of mnemonic phrases is not enough. More reliable directions include reviewed cryptographic backups, threshold recovery, and independent device authorization, allowing users to complete recovery drills before depositing large assets. Backup sharding and multi-signature are different layers: the former may recombine the same secret during recovery, while the latter requires multiple independent signers to approve transactions. Recovery services cannot quietly become a new master key, nor can additional passwords become another trap that cannot be recovered if lost.

Personal wallets and exchange wallet systems can share security standards for transaction descriptions, signature requests, asset restrictions, and recovery processes, adopting different limits and approval strategies. Bitcoin's PSBT has already provided a format for transmitting pending signed transactions across tools, and this common interface is worth further development. What is common is the verifiable security requirements, and each chain still needs to clarify its own adaptation rules. Wallets should clearly present what this signature will transfer, how much subsequent authority is granted to whom, and independent strategies should reject boundary-crossing operations; a more attractive confirmation page is not enough.

3. Achieve verifiability with minimal necessary disclosure

Proving a condition should not always require users to disclose all underlying data. Selective disclosure, zero-knowledge proofs, and on-demand audit access should become standard options in infrastructure. This also relates to asset security: publicly available identity and asset relationships may provide clues for targeted deception; data that businesses do not need should be minimally exposed.

The W3C's verifiable credential system already has technical pathways for selective disclosure; however, it still needs to clarify how to prove the authenticity of inputs, the validity of credentials, and how to revoke states. Adopting zero-knowledge proofs (ZK) does not automatically hide transaction amounts and relationships, as scaling proofs and privacy protection are different goals.

For example, when a business only needs to verify participation eligibility, users can present valid eligibility conclusions issued by trusted institutions without disclosing complete financial materials. When it is necessary to prove that hidden values meet conditions, appropriate proof mechanisms should be used. The credible source of credentials and revocation status still need verification.

My proposal is to clarify "who needs to verify what" first, and then design the data that must be disclosed. Those verifying eligibility may only need eligibility conclusions; those with specific audit responsibilities can obtain limited evidence. Publicly verifiable constraints should minimize the permanent exposure of personal information to everyone.

IV. Decentralizing Transaction Services from Central Custody

Transaction matching, pathfinding, and asset delivery should be designed separately. A service providing transaction entry should only obtain the permissions necessary to complete the current delivery, allowing user assets to remain under their control at other times. Existing transaction-intent-based protocols have explored some paths, and the industry can continue to complete this work.

Users should agree to clear delivery conditions, including what is given, what is at least received, when it expires, and the allowed fees. If a transaction service is compromised, attackers may deny service but cannot arbitrarily change these conditions. Businesses that still require centralized custody should also separate reserve and operational permissions, limiting hot wallet exposure and automatic replenishment limits.

IBIT is an exchange-traded product for Bitcoin by iShares, and the market trades its shares. Its arrangement provides a partially isolated example: shares and underlying Bitcoin are recorded separately, and the private keys related to the Vault Balance (custodial balance) are stored in cold storage. Changes in share trading records do not require the underlying Bitcoin to move with each transaction. The separation of trading rights and reserve disposal rights can be referenced. Its Trading Balance has different arrangements, and custody itself carries risks; cold storage must be paired with independent instructions and signature verification.

I liken the transaction entry to a router, hoping it can be replaced without carrying a master switch for all user assets. Settlement is more complex than data packet forwarding, and asset delivery and authorization still require independent verification. Once services are made non-custodial, granting them unlimited withdrawal rights will only reintroduce centralized risks.

V. Isolating Failures with Layered Architecture to Retain Replacement Capability

We need identity and authorization interfaces, asset strategies, and settlement verification methods that can evolve independently. Different chains can retain their execution models and connect through clear interfaces. The interfaces should specify security guarantees and their conditions, not just state "call successful."

Internet experience supports this thinking. Mark Nottingham specifically discusses in RFC 9518 "Centralization, Decentralization, and Internet Standards" the situations where centralization can be helpful and analyzes the power and risks it brings. This is precisely the attitude worth emulating: allowing architecture to answer which responsibilities can be centralized, to what extent, and how to prevent the expansion of that power. A service can centrally identify anomalies while limiting its access to assets; users should be able to change services without losing their asset strategies and verification records.

The most important acceptance question is: after a business service is compromised, which independent layer can still refuse it? If all layers share a management key, the so-called layering is merely a deployment diagram.

This goal can be viewed as five layers of responsibility: transaction services submit requests, wallets express user intent, independent strategies limit asset disposal rights, verification components check operations and evidence, and the settlement layer executes constraints and provides verifiable records. They can be implemented by different teams and must specify dependencies and failure conditions separately.

The proposed target architecture of this article. The settlement layer must enforce asset strategies; prompts in the wallet cannot replace this constraint. Daily signatures, rule changes, and recovery permissions need to be isolated and subjected to bypass testing.

VI. Enabling Users to Lightly Verify Their Assets

Ordinary people should not have to save and execute the entire history of the chain just to verify their balances and receipts; nor should they have to rely solely on a single server behind their wallet. Satoshi Nakamoto proposed SPV, or Simplified Payment Verification, in section eight of the white paper. Bitcoin's BIP-157 continues to explore allowing clients to download filters and find blocks relevant to them; Ethereum also has light client designs. So the issue is not that no one has ever thought of it, but that we still need to incorporate verification capabilities with clear security conditions into the wallets that users use daily.

Taking chains that support account state proofs as an example, when querying balances, the server should return both the balance and the proof simultaneously. The wallet first verifies a short block summary according to the rules of this chain, which is the block header, and then checks whether this balance is consistent with the data promised in the summary. The server provides an answer, and the wallet can verify the answer. Bitcoin's SPV verifies evidence that relevant transactions have been included, which cannot be directly copied as balance proof. The wallet should also clearly display where it has synchronized, which information has been verified; when proof is missing, data is outdated, or sources are contradictory, it should prompt or stop high-risk operations that depend on this information, rather than quietly reverting to blind trust.

Light verification still has conditions. Proving that a transaction has been included in a block does not equate to checking that all transactions in the block are legitimate. Different schemes may rely on a majority of honest computing power or a trusted initial record, which is a checkpoint; it must also guard against servers concealing data or isolating users on an outdated chain record. Whether querying itself will expose the addresses of interest to users also needs to be addressed. Full nodes and block producers are not the same role; Ethereum's current block production uses validators, not miners.

More importantly, proving "this transfer indeed occurred on-chain" does not prove "this is exactly the transfer the user wanted." Light clients cannot replace the previous asset restrictions and signature checks. They reduce reliance on unverifiable responses, while asset strategies ensure that even a valid signature cannot dispose of assets indefinitely. Building both layers together is how we decentralize verification capabilities to participants.

VII. Establishing Public Foundations for Anomaly Detection and Security Verification

Before transactions, someone should check whether the operation complies with asset strategies and whether it suddenly changes historical behavior. Obvious anomalies can trigger pauses or escalated reviews; expanding permissions requires another independent path. AI can participate in judgment but should not receive a pass to bypass hard rules.

At the same time, we need to jointly maintain attack cases, permission tests, and repeatable verification tools. Sharing standards while retaining independent implementations and verifications can reduce common failures. Foundations and exchanges have already made security investments, such as the Ethereum Foundation's Trillion Dollar Security Initiative. The next step is to question whether these investments can be transformed into public foundations that other teams can also adopt and verify.

These seven tasks cannot guarantee absolute security. What they deliver are verifiable boundaries: under what conditions permissions are compromised, how much assets are exposed at most, how long anomalies can be detected, and who recovery still depends on.

AI-Powered Software Engineering: Our A New Hope

By this point, some may say: the direction sounds right, but the industry has been on this path for so many years; how many people and how much time will it take to reconstruct? Isn’t this still idealism?

If we estimate according to past software production methods, this question is very realistic. But by 2026, I believe that coding agents and AI-powered software engineering will have changed the construction capabilities we can mobilize. The coding agents referred to 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, and use these tools to implement and check systems, taking responsibility for the results.

Work that previously required large teams to repeatedly implement, adapt, and maintain can now be attempted by small teams using this new engineering approach. One team guards a layer, delivering components around clear interfaces, while other teams check and combine them. Organizing human architectural judgment, the implementation capabilities of coding agents, and independent security verification is the construction path I believe is worth serious reevaluation.

Research from Anthropic and PNNL provides a concrete example: in a limited critical infrastructure simulation environment, researchers reported that attack reconstruction time was reduced from potentially weeks to about three hours. It does not prove that a small team can safely rewrite the entire industry, but it indicates that the previously costly verification and offensive-defensive work can emerge under new cost conditions.

One way to start now is to collaboratively build a Build in Public AI Factory. Industry experts, scholars, and practitioners openly write requirements and acceptance specifications (specs), explaining what needs to be protected, what actions are allowed, and what boundaries must be maintained even if certain permissions are compromised, and then turn these requirements into acceptance tests. Grouped coding agents take on the main tasks of coding, testing, and debugging; different teams check the design and results, with individuals bearing the responsibility for judgment and acceptance.

Participants can contribute ideas, machines, computing power, and model invocation quotas, which are essentially 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, testing environments, and validation results can all become a collectively maintained foundation, allowing the next team to pick up where the last one left off. The goal is to build development capabilities into reusable public infrastructure, reducing reliance on any one person's time or any one team's efforts.

Attackers are also using AI, and we have no reason to leave defense in the past production methods. But code generation is just the starting point. Clearly writing constraints, allowing tests to be run repeatedly, and enabling a component to be checked and replaced will transform AI capabilities into improvements in infrastructure.

Independent builders work together with coding agents and AI tools. The space workshop serves as a metaphor for public construction.

I especially want to send this call to those who still love building. Here, the hacker is someone who is willing to understand how systems work, willing to share discoveries, and willing to let others verify their work. This spirit once drove the internet and can drive Crypto today.

I do not believe this industry lacks smart people, nor do I believe that the Crypto and AI industries cannot find the resources to support this work. The more challenging task is to organize talent, funding, and ongoing responsibility together. Foundations and capable enterprises should be willing to bear the long-term costs of foundational work that does not directly generate revenue but benefits everyone.

I hope we can collectively create a globally shared crypto infrastructure. Different networks and teams can collaborate under common security constraints, each implementing and verifying their parts, allowing users to choose and migrate. It can start with a single component, but the direction should be broad enough to accommodate the collective construction of the entire industry. Participants, including ArcBlock, should contribute verifiable contributions.

We should build an infrastructure together: even if one area is compromised, assets still have boundaries, other systems can still reject errors, and users still have paths to recover and exit. Borrowing the name from "Star Wars," this is our A New Hope. Hope comes from ordinary builders willing to act, and from coding agents and new engineering methods that enable them to take on more construction work at this moment.

Act Now

I want to invite builders from projects like Ethereum, Solana, Bitcoin, XRP Ledger, as well as exchanges like Binance, Coinbase, Kraken, and teams in wallets, protocols, security research, AI, and cloud computing: let’s start with a clearly defined pilot project to collaboratively create improvements that other teams can adopt and verify.

The names listed are just examples, not in any particular order. Participation is welcome regardless of scale or technology path. This invitation also includes builders of the technical paths criticized in this article; improving asset security is worth crossing the boundaries of our respective ecosystems.

I 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; we hope to start with a prototype and a set of repeatable tests.

Those with practical operational experience can provide desensitized attack scenarios, wallet and protocol teams can implement protections, and independent researchers can attempt to bypass them. Each team takes on what they can handle, collectively verifying solutions and deciding on the next steps.

I am willing to participate in organizing the asset restrictions and recovery requirements from this article into the first public spec, and I am also willing to contribute relevant technologies and engineering practices to build a public AI Factory for this pilot. Let’s first select a very specific problem: if the daily trading key has been compromised, how can we ensure that attackers still cannot empty the wallet in one go? Write the allowed loss range, the permissions for modifying rules, and the recovery conditions into acceptance tests, then have development agents implement the prototype, allowing another group of agents and independent researchers to find bypass paths. Data servers returning incorrect balances and recovery after device loss can also be gradually added to the tests. What the prototype achieved, where it failed, and what dependencies remain should all be publicly explained, and the next steps should be decided based on evidence.

Those willing to participate are welcome to publicly share or reference this initiative on X, and @mave99a, discussing the problems they want to solve, desensitized attack cases, or resources they can contribute. I hope discussions will be public, allowing more builders to see and continue to participate.

Crypto cannot continue like this. For those willing to work together, let’s act now, starting with a feasible and verifiable improvement.

1. Binance, preliminary announcement of official posts and subsequent updates on investigations, 2026-10-30; TRM multi-chain analysis. This article is verified as of 2026-10-30; the status of investigations and recoveries may change. \↩\
2. Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. \↩\
3. Uniswap, Unichain EVM Equivalence. The concentration of interdependent risks is the author's judgment, not a conclusion of this document. \↩\
4. Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, created on 2024-05-07. \↩\
5. Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, arXiv v1 preprint; not an assessment of the Binance incident. \↩\
6. Ethereum, Maximal extractable value (MEV), sorting mechanisms, different types, and negative impacts; "should be treated as a bug fix" is the author's engineering stance on harmful user behaviors. \↩\
7. PHP official 2026 news archive; CISA 2026-10-26 known exploited vulnerabilities update, CVE-2026-109618, CVE-2026-109619. \↩\
8. Safe, Guards and Modules, explanation of functions and permission risks. \↩\
9. Apple, Apple to expand repair options with support for used genuine parts, 2024-04-11; current parts locking support explanation. \↩\
10. Ledger, Ledger's Response to the Hardware Implant Attack, 2026-10, vendor's explanation of attacks during distribution; Joe Grand, hardware implant reverse engineering. Do not write unverified network loss estimates as conclusions. \↩\
11. Coinkite, Current COLDCARD Security Status, 2026-10-30 review, ongoing updates of the July 2026 incident and repair records; upgrades and seed migrations are two different operations. \↩\
12. ERC-4337: Account Abstraction Using Alt Mempool; Trezor, SLIP39 FAQs, threshold recovery, compatibility, and additional passphrase risks. Existing mechanisms are foundational, not every deployment is reliable. \↩\
13. BIP-174: Partially Signed Bitcoin Transaction Format, format for exchanging unsigned transactions, not a cross-chain universal asset strategy specification. \↩\
14. W3C, Verifiable Credentials Overview v1.0, 2026-07-30 Group Note; Ethereum privacy explanation. The standard status of the technologies described in the overview is independent. \↩\
15. CoW Protocol documentation, transaction intent and solver mechanisms; this article does not provide comprehensive security endorsement for specific deployments. \↩\
16. iShares, IBIT 2025 annual report, PDF pages 8-10 custodial arrangements and page 45 risk explanation. \↩\
17. Mark Nottingham, RFC 9518: Centralization, Decentralization, and Internet Standards, 2023-12, independent submission, explanatory RFC, not a standard track specification. \↩\
18. Bitcoin white paper section 8 Simplified Payment Verification; BIP-157: Client Side Block Filtering; Ethereum, Light clients. The verification scope and trust conditions of different light clients vary. \↩\
19. Ethereum Foundation, Announcing the Trillion Dollar Security Initiative, 2025-05-14. \↩\
20. Anthropic, AI to defend critical infrastructure, 2026-01-08, research in a controlled environment in collaboration with PNNL. \↩\
21. Anthropic, Mapping AI-enabled cyber threats, research on actual abuse samples. \↩\
22. Lucasfilm, Star Wars: A New Hope (Episode IV), 1977; this article borrows the title of the work and the imagery of mutual rescue. \↩\