Crypto Can’t Go On Like This: A Blockchain Builder’s Call for the Industry to Save Itself
You have my permission to republish and share this essay freely. I hope this call to save our industry reaches more people.
Crypto can’t go on like this. Repeated large-scale theft takes more than assets. It takes away people’s trust in the entire industry. We have to act to save it.
On October 29, 2026, Binance suffered a major security incident. Its preliminary disclosure estimated about $6.3 billion in affected assets, with roughly $3 billion frozen. Investigators initially pointed to a DevOps engineer’s laptop, then identified other possible breach points. Binance also said it had found no evidence of wallet private keys leaking. The amount affected is not a final net-loss figure, and the complete attack chain remains under investigation.[1]
This appeal is addressed to builders around Ethereum, Solana, and other blockchain projects, to Binance, Coinbase, Kraken, and every willing builder across exchanges, wallets, protocols, and security: let’s rebuild the foundations that protect assets together. I am willing to contribute, and I hope others will join the work.
That is devastating enough. I also worry about how many people this incident will turn away from crypto, and how many attackers it will encourage to keep targeting the industry. Covering losses cannot automatically restore trust or stop the same destruction happening again.
Binance is the immediate reason we have to confront this problem today. Beyond this incident lies a long history of damage across exchanges, bridges, onchain protocols, and wallets. New networks and products arrive while old failures repeat. We cannot issue another statement, wait a while, and accept the next incident as ordinary business.
Scams and projects that manufacture narratives without taking responsibility for building have damaged this industry for too long. Teams doing serious technical and infrastructure work bear the loss of trust as well. When people dismiss all of crypto as a scam, worthwhile technology and exploration can be abandoned with it.
As ArcBlock’s founder and a crypto and blockchain builder, I refuse to accept that outcome. I believe the industry has value worth protecting, and that we must take responsibility for its security foundations. If we passively wait for the next incident, recurring losses may eventually destroy what we have built together.
This is my appeal: exchange, wallet, and blockchain builders should rebuild the foundations of asset control and security verification together, so that an intrusion has enforceable limits. The history below explains why change is necessary. The technical proposals that follow describe work we can begin.
This history is already too long
In 2008, Satoshi Nakamoto proposed a peer-to-peer electronic cash system that would reduce dependence on trusted financial intermediaries.[2] Major incidents since then have repeatedly exposed concentrations of assets, authority, and software dependencies.
This timeline selects incidents across centralized exchanges (CEXs), decentralized exchanges (DEXs), bridges, and wallets. It is neither a complete database nor an annual loss series. Figures, where included, describe approximate gross impact at the time. Theft, frozen assets, and subsequent recoveries are distinguished; they must not be added together as permanent losses.
2008 · Bitcoin whitepaper
Starting point
The Bitcoin whitepaper proposes peer-to-peer payments without a financial institution in the middle.
2011–2014 · Mt. Gox: prolonged theft
CEX
Mt. Gox suffers prolonged theft and eventually ceases operating. Later US charges allege approximately 647,000 BTC stolen during 2011–2014, rather than in one day in 2014.
2012 · Bitcoinica and Bitfloor
CEX / hosting
Bitcoinica's Linode hosting environment is compromised; an unencrypted wallet backup becomes an entry point at Bitfloor. Hosting and backups are asset-security boundaries too.
2015 · Bitstamp hot wallet
CEX
Bitstamp's hot wallet is compromised and its operating environment rebuilt. Its disclosure distinguishes the affected funds from offline reserves.
2016 · Bitfinex
2016 · The DAO
2017 · Parity shared wallet library
Contract wallets
Destruction of Parity's shared wallet library freezes roughly 513,000 ETH. A common code dependency can make assets unusable without moving them.
2018 · Coincheck
CEX
Coincheck's NEM hot wallet is drained, again exposing the boundary between operational needs and custody controls.
2019 · Binance
CEX
Binance reports 7,000 BTC withdrawn in one transaction. Large outflows need constraints before signing.
2020 · KuCoin
CEX
KuCoin's hot-wallet incident is followed by substantial recoveries through industry cooperation. Gross theft and final loss differ.
2021 · Poly Network
Cross-chain protocol
Roughly $612 million leaves Poly Network and is subsequently returned in stages. Cross-chain authorization must remain secure outside expected business flows.
2022 · Ronin bridge
Bridge
Compromised Ronin validator authority enables withdrawals of 173,600 ETH and 25.5 million USDC. Several keys can fall to one attack chain.
2022 · Slope wallet
Wallets
The Slope incident affects Solana users. Solana's update identifies private-key material inadvertently transmitted to application monitoring, rather than a consensus failure.
2023 · Euler
Lending protocol
Approximately $197 million is extracted from Euler through a protocol flaw and later recovered. Complex operations can amplify a business-logic defect.
2023 · Ledger Connect Kit
Wallet connector
A supply-chain attack on Ledger Connect Kit brings malicious code into application frontends. Secure hardware cannot replace verification of what is signed.
2024 · DMM Bitcoin
CEX
Approximately $308 million is stolen from DMM Bitcoin. Authorities later describe social engineering targeting people and the signing workflow.
2024 · Radiant Capital
Lending / signing
Radiant Capital loses approximately $50 million after developer devices are compromised. Multiple signers can share corrupted transaction information.
2025 · Bybit / Safe
2025 · Cetus DEX
DEX
Researchers attribute the roughly $223 million Cetus incident on Sui to a mathematical library flaw. Non-EVM systems need the same scrutiny of code and exposure.
2026-07 · COLDCARD randomness failure
Hardware wallet / seed generation
Firmware weakened seed generation, enabling offline key reconstruction. An update does not repair an existing weak seed; affected seeds require migration.
2026-10 · Ledger hardware implants
Hardware wallet / distribution attack
Ledger confirms modified genuine devices circulated through Southeast Asian resellers, capturing recovery phrases during setup. It reports no compromise of its chip, operating system, or servers.
2026 · Binance across multiple chains
These incidents include centralized exchanges, decentralized trading, lending, bridges, and wallets. Different layers failed and need different repairs. Blaming users for failing to protect their keys cannot explain how a tool's development environment, a shared library, or an incomprehensible authorization becomes a route to all their assets.
Distributed networks have accomplished a great deal. Isolation of asset-control failures remains inadequate. Faithful execution of a transaction does not explain why it had authority to move so much.
Build shared security across different technical approaches
Ethereum contributed enormously to making onchain applications accessible. It produced useful tools and engineering experience. But many new chains and layer-2 networks (L2s) now treat EVM compatibility as a primary objective. EVM, the virtual machine that executes Ethereum contracts, is becoming a widely replicated technical premise. Compatibility helps applications move; documentation for projects such as Unichain explicitly emphasizes reuse of Ethereum tooling.[3]
I believe treating EVM compatibility as the default answer is creating a structural concentration of risk. Networks can have different names and validators while developers deploy the same contracts, reuse authorization patterns, and depend on the same libraries. A shared dependency's defect does not disappear when deployed on another chain. That is a criticism of the direction of architecture, not a claim that every EVM implementation necessarily contains the same vulnerability.
My criticism of Ethereum concerns the responsibility its design places on application code and wallet interaction. General contract execution connects directly to transferable assets. Contracts call other contracts. Permissions can persist. An apparently ordinary approval can change future account control. Safety comes to depend on each development team understanding those combinations correctly and each user understanding what they sign.
EIP-7702 illustrates the issue. A transfer says, in effect, “send this amount to this recipient.” Delegation can say, “let this code execute operations for my account in the future.” The proposal has useful goals, including narrower permissions. But setting delegation grants broad execution authority; the delegated code must implement the narrower rules correctly.[4] Minfeng Qi and colleagues' preprint EIP-7702 Phishing Attack studies persistent account control following deceptive authorization.[5] The added responsibility needs as much attention as the added convenience.
Binance's incident spans multiple chains and remains under investigation. Its full impact cannot be attributed directly to EIP-7702 or EVM. Reentrancy, a compromised signing service, and frontend tampering are different failures. Those distinctions should sharpen the architectural question: why does the infrastructure not preserve more constraints that survive mistakes above it?
MEV concerns me too: the additional value available through transaction inclusion, exclusion, and ordering. Using ordering power to sandwich users and worsen their execution should be treated as a bug to fix. Someone making money from it does not make it a feature worth preserving. Ethereum's own documentation acknowledges harm from sandwiching and risks to network stability.[6] MEV also exists elsewhere and covers different activities, including arbitrage and liquidations; mitigation work is underway. My objection is to accepting harm to users as a necessary reward for maintaining the network. Better trading infrastructure should enforce authorized settlement limits and constrain abuse of pending transaction information.
I see a resemblance between Ethereum's contribution to crypto and PHP's contribution to the web: both enabled people to build, while leaving engineering debt that requires sustained work. PHP still needed fixes for critical remote-code-execution vulnerabilities in October 2026.[7] Maturity and popularity cannot replace hardening. A strength of the internet is that languages, frameworks, and cloud services can evolve separately. Crypto should also allow asset models and execution designs to develop without compatibility with one virtual machine becoming the price of admission.
I am calling on builders around Bitcoin, Solana, Ripple and the XRP Ledger, and teams including ArcBlock to participate in shared security foundations. Cooperation on standards and interoperability should not require becoming Ethereum. Diversity needs to reach asset control and verification, with public tests of the results. Slope and Cetus already demonstrate that non-EVM systems receive no exemption from scrutiny.
I want security specifications that different execution environments can adopt. EVM and other approaches can implement the same asset limits and verification requirements independently, then publicly test their guarantees and tradeoffs.
Seven improvements we can begin
1. Put enforceable limits on asset authority
Large wallets should be able to set recipient allowlists, cumulative spending limits, and delays for new destinations. The ordinary transaction key must not be able to immediately remove those rules. Policy changes need independent authorization and time for monitoring and cancellation.
Smart accounts already provide a foundation. Safe Guards, for example, can impose restrictions beyond multisignature approval.[8] The work is to make protections easier to adopt and cover every path to asset control. A limit on direct transfers is ineffective if an allowance, module, or upgrade bypasses it. Changes to an allowlisted contract or its recipient’s permissions must also be checked.
Apple’s Activation Lock offers an everyday analogy: restricting reactivation of stolen devices and calibration of certain stolen parts is intended to reduce their usefulness after theft.[9] Wallets should pursue a similar principle. A stolen operating key should leave only a limited amount that can be extracted, reducing potential returns to the attacker. Disruption still requires separate defenses.
This is the asset-security “constitution” I want: operating permissions may fail while authority to change the boundaries remains separate. Recovery needs constraints too, so that mistakes do not permanently lock assets away.
2. Make wallets responsible for usable security
I have a strong objection to a product that hands ordinary people a list of words, requires them never to lose it, expose it, or be deceived, and then assigns every subsequent failure to the user. I consider that irresponsible design. Self-custody should provide usable protection and recovery alongside control. Requiring everyone to become a security specialist is a barrier to broader adoption.
Recent incidents make the problem concrete. In October 2026, Ledger confirmed that attackers modified genuine devices and returned them to Southeast Asian reseller channels, with implants capturing recovery phrases during setup. Ledger describes a localized distribution attack after devices left its control, rather than a compromise of its chips, operating system, or servers.[10] COLDCARD's July incident involved firmware weakening seed generation: attackers could reconstruct keys without remotely taking over devices. Updating firmware does not repair an existing weak seed; migration is still required.[11]
These are different failures. Both show why careful backup and offline storage cannot make a user responsible for validating a manufacturer's randomness or its entire delivery chain. Displaying recovery words serves an offline backup purpose, but exposes the complete recovery secret along a path that also needs protection. A secure chip does not establish the integrity of the whole device and its delivery.
The target should be the wallet's complete lifecycle: key generation, understandable transactions, separated authority, and recovery after device loss. Account abstraction lets accounts use programmable authorization rules, while threshold backups have foundations such as SLIP-39. Standards and implementations already exist.[12] The work is to turn them into tested, usable defaults rather than a complex system each user must assemble.
Simple mnemonic obfuscation is insufficient. Reviewed encrypted backups, threshold recovery, and independent-device authorization offer stronger directions, with recovery rehearsed before substantial assets are deposited. Backup shares and multisignature authorization serve different roles: shares may reconstruct one secret, while multisig requires independent signers to approve a transaction. Recovery providers must not become another master key, and an extra password must not quietly introduce another irrecoverable failure.
Personal wallets and exchange custody systems can share security specifications for transaction descriptions, signing requests, asset limits, and recovery, with different approval policies. Bitcoin's PSBT already standardizes exchanging transactions for signing.[13] Common requirements still need explicit adaptations for different chains. A wallet should explain both the immediate transfer and continuing authority a signature grants, while independent policy rejects violations. A better-looking confirmation screen is insufficient.
3. Verify with the minimum necessary disclosure
Proving that a condition holds should not routinely require disclosure of all the underlying information. Selective disclosure, zero-knowledge (ZK) proofs, and scoped audit access should become normal infrastructure options. This also concerns asset security: disclosed identity and asset relationships can supply clues for targeted deception. Services should minimize information they do not need.
W3C's verifiable-credential work already describes selective-disclosure mechanisms. Authentic input, current validity, and revocation still need explicit arrangements.[14] ZK technology also does not automatically hide transaction amounts or relationships; scaling proofs and privacy serve different purposes.
For example, a service checking eligibility could accept a current credential from a trusted issuer without receiving the person’s complete financial records. Proving a condition over hidden numbers calls for an appropriate proof mechanism. The source of the claim and its revocation status still need checking.
Start by specifying who needs to verify what. A verifier may only need a qualification result. An auditor with a defined responsibility may receive restricted evidence. Publish verifiable constraints while minimizing permanent exposure of personal information to everyone.
4. Separate trading services from concentrated custody
Order matching, path discovery, and settlement should be designed separately. A trading service should obtain as little authority as possible beyond what a particular settlement requires, with users controlling assets at other times. Intent-based protocols already explore part of this direction.[15]
Users should authorize explicit settlement conditions: what they give, what they must receive, expiration, and permitted fees. A compromised service may refuse to operate, but it should not be able to rewrite those conditions. Businesses that require custody should separate reserves from operating authority and constrain hot-wallet exposure, including automatic replenishment.
IBIT is iShares’ bitcoin exchange-traded product; investors trade its shares. It provides a limited example of separation: shares and underlying bitcoin have separate records, and keys for its Vault Balance, the custody balance, are kept in cold storage. A share trade does not require a corresponding bitcoin transfer.[16] Trading authority and authority over reserves can be separated. Its Trading Balance, held through its trading service, has different arrangements. Custody retains risks, and cold storage still needs independent instruction and signing verification.
My router analogy concerns replaceability: a trading entry point should not carry a master switch for everyone's assets. Settlement is harder than packet forwarding and still requires independent checks. Unlimited withdrawal approval can recreate concentrated authority inside an ostensibly noncustodial service.
5. Isolate failures through layers that can be replaced
Identity and authorization interfaces, asset policies, and settlement verification should be able to evolve independently. Chains can retain different execution models while connecting through explicit interfaces. Those interfaces must describe conditional security guarantees, beyond whether a call succeeded.
Internet experience supports that approach. Mark Nottingham’s RFC 9518, Centralization, Decentralization, and Internet Standards, explicitly examines helpful centralization alongside its power and risks.[17] That is an attitude worth adopting: identify which responsibilities can be concentrated, to what extent, and how that authority is constrained. A service can centralize anomaly detection while having limited access to assets. Users should be able to replace it without losing their policies or verification records.
The critical test is what independent layer can still refuse a request after the business service is compromised. Layers sharing one administrative key provide little separation.
Think of the target as five responsibilities: trading services submit requests; wallets express user intent; independent policies bound asset authority; verification components check operations and evidence; settlement enforces the constraints and supplies verifiable records. Different teams can implement these parts, with explicit dependencies and compromise conditions.
A proposed architecture. Settlement must enforce asset policy; a wallet warning cannot replace that constraint. Everyday signing, rule changes, and recovery need separate authority and tests for bypasses.
6. Let users verify their own assets with lightweight clients
People should not need to store and execute a chain's entire history to check a payment or balance. They should also have an alternative to trusting a wallet's server. Satoshi already proposed Simplified Payment Verification, or SPV, in section eight of the Bitcoin whitepaper. BIP-157 develops client-side filtering to locate relevant blocks, and Ethereum has light-client designs too.[18] The challenge is bringing verification with explicit security conditions into everyday wallets.
On a chain supporting account-state proofs, consider a balance query: the server should return both a number and a proof. The wallet first checks a compact block summary, or header, under the chain's rules, then checks that the balance matches the data committed to by that summary. The server supplies an answer the wallet can verify. Bitcoin SPV checks transaction inclusion instead; this balance-proof model cannot simply be copied across. Wallets should also show their synchronization state and what has been checked. Missing proofs, stale information, or conflicting sources should trigger warnings or suspend high-risk operations that depend on that information. Silently falling back to an unverifiable answer defeats the purpose.
The limits matter. Proving that a transaction was included does not check the validity of every transaction in its block. Different designs may depend on an honest majority of mining power or a trusted starting record called a checkpoint. They must also address withheld data, isolation onto a stale chain view, and queries that expose a user's addresses. Full nodes and block producers have different roles. Ethereum now uses validators for block production, rather than miners.
Above all, proof that a transfer happened cannot establish that the user intended it. Lightweight verification complements asset limits and signing checks. It reduces reliance on an unchecked answer; asset policy constrains what even a valid signature can authorize. Building both gives participants more independent means to protect themselves.
7. Make detection and verification shared infrastructure
Before execution, transactions should be checked against asset policy and significant deviations from expected behavior. Suspicious activity can trigger a pause or further review. Expanding authority needs a separate path. AI can contribute judgment without receiving permission to bypass hard constraints.
We also need maintained attack cases, permission tests, and repeatable verification tools. Share specifications while preserving independent implementations and verification. Existing efforts, including the Ethereum Foundation's Trillion Dollar Security Initiative, deserve recognition.[19] The question is whether investment produces foundations other teams can inspect and use.
These seven improvements have measurable deliverables: under specified compromised permissions, how much remains exposed, how quickly is a problem detected, and who is still needed for recovery?
AI-enabled software engineering: our A New Hope
A reasonable objection is that these are good intentions with an impossible staffing bill. Rebuilding after years of accumulated systems sounds idealistic.
That objection deserves a fresh answer in 2026. Coding agents and AI-enabled software engineering change the capacity available to builders. By coding agents, I mean AI programming assistants that work inside a development environment: reading and writing code, using tools, running tests, and continuing from the results. People set the goals, define security boundaries, and remain responsible for the systems they build with those tools.
Small teams can use this way of working to attempt implementation, adaptation, and maintenance that once demanded much larger teams. A team can focus on one layer, deliver components against explicit interfaces, and have other teams check and combine the results. Human architectural judgment, agent-assisted implementation, and independent security verification together make this path worth reassessing.
Anthropic's research with PNNL offers a concrete example. Within a bounded critical-infrastructure simulation, researchers reported reducing attack reconstruction from potentially weeks to about three hours.[20] That does not establish that a small team can safely rewrite an industry. It shows how the cost of previously expensive verification and security work can change.
One practical way to begin now is to build a shared AI Factory in public. Industry experts, researchers, and practitioners can write the specification, or spec, openly: what we protect, which actions are allowed, and which boundaries must survive compromised permissions. Turn those requirements into acceptance tests. Teams of coding agents can perform most of the implementation, testing, and bug-finding, while independent teams examine the designs and results. People remain responsible for judgment and acceptance.
Participants can contribute ideas, machines, compute, and model-call credits, or AI tokens. AI and cloud companies can support the effort through model credits, computing resources, and tools. The specs, prototype code, agent workflows, test environments, and verification results can become shared foundations that another team can build on directly. The aim is reusable public engineering capacity, with less dependence on any one person's time or any single team.
Attackers are using AI too.[21] Defenders cannot afford to keep working as though engineering capacity has stood still. Faster code generation is a starting point. Clear constraints, repeatable tests, and replaceable components are how that capacity becomes better infrastructure.
Independent builders working with coding agents and AI tools. The workshop is a metaphor for shared infrastructure work.
I especially want this appeal to reach people who still love building. By hacker, I mean someone who wants to understand how a system works, shares discoveries, and invites others to examine what they have made. That spirit helped build the internet. It has work to do in crypto.
I do not believe this industry lacks capable people, or that crypto and AI cannot find resources for this effort. Organizing talent, funding, and lasting responsibility is harder. Foundations and capable companies should fund the work that benefits everyone even when it produces no direct revenue.
I hope we can build shared global cryptographic infrastructure together. Different networks and teams should be able to cooperate under common security constraints, implement independently, and check one another’s work, while users retain choice and migration paths. It can begin with one component and still have a destination large enough for an industry to build toward. ArcBlock and every other participant should contribute work others can verify.
We should build infrastructure where assets retain boundaries after a compromise, other systems can refuse bad instructions, and users can recover or leave. Borrowing the Star Wars title, this is our A New Hope.[22] It comes from ordinary builders willing to act, at a moment when coding agents and new engineering practices let them take on more of the work.
Let’s act now
I invite builders around Ethereum, Solana, Bitcoin, XRP Ledger, and other projects; exchanges such as Binance, Coinbase, and Kraken; and teams working on wallets, protocols, security research, AI, and cloud computing: let’s begin with a bounded pilot and build an improvement other teams can adopt and test.
These names are examples, listed in no particular order. Teams of every size and technical approach are welcome. The invitation includes the builders of approaches I have criticized here; improving asset security together is worth working across our respective ecosystems.
I am willing to contribute our existing infrastructure, software engineering, and AI collaboration practices. We are a small team with limited capacity. We can begin with a prototype and a set of repeatable tests.
Operators can contribute sanitized attack scenarios. Wallet and protocol teams can implement protections. Independent researchers can try to bypass them. Each team can take on the part it can sustain, test the proposals, and decide the next step together.
I am willing to help turn the asset limits and recovery requirements in this essay into the first public spec, contribute relevant technology and engineering practices, and work with others to build a public AI Factory around that pilot. Start with one question: after an operating key is compromised, how do we prevent an attacker from emptying a wallet in one go? Express the exposure limit, authority to change the rules, and recovery conditions as acceptance tests. Have coding agents build the prototype, then have a different group of agents and independent researchers search for bypasses. False balance responses and recovery after device loss can follow. Report what works, what fails, and which dependencies remain, and use that evidence to decide the next step.
If you want to take part, share or quote this appeal publicly on X and tag @mave99a with the problem you want to address, a sanitized attack case, or resources you can contribute. I want the discussion to stay public so more builders can see it and join in.
Crypto can’t go on like this. If you are willing to build together, let’s act now, starting with one improvement we can deliver and put to the test.
- Binance, official preliminary statement and official investigation update, October 30, 2026; TRM multichain analysis. Investigation and recoveries remain provisional. ↩
- Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. Source 1. ↩
- Uniswap, Unichain EVM Equivalence. Concentration-of-risk analysis is the author’s judgment. Source 1. ↩
- Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, created May 7, 2024. Source 1. ↩
- Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, December 13, 2025, arXiv v1 preprint. Not a Binance root-cause report. Source 1. ↩
- Ethereum, Maximal extractable value (MEV), mechanisms, types, and adverse effects. Treating user-harming behavior as a bug is the author's engineering position. ↩
- PHP official 2026 archive; CISA October 26 update covering CVE-2026-109618 and CVE-2026-109619. Source 1. Source 2. ↩
- Safe Guards and Modules documentation, including authority and recovery risks. Source 1. Source 2. ↩
- Apple, April 11, 2024, repair options and Activation Lock; current locked-part support. ↩
- Ledger, Ledger’s Response to the Hardware Implant Attack, October 2026; Joe Grand, hardware-implant reverse engineering. Unverified loss estimates are not treated as established totals. ↩
- Coinkite, Current COLDCARD Security Status, accessed October 30, 2026; living record of the July incident and remediation. Firmware updates and seed migration are separate operations. ↩
- ERC-4337: Account Abstraction Using Alt Mempool; Trezor, SLIP39 FAQs, including thresholds, compatibility, and passphrase risks. These are building blocks, not guarantees for every deployment. ↩
- BIP-174: Partially Signed Bitcoin Transaction Format, a signing exchange format rather than a universal cross-chain asset-policy specification. ↩
- W3C Verifiable Credentials Overview v1.0, July 30, 2026, Group Note; Ethereum privacy documentation. Underlying specifications have their own standards status. Source 1. Source 2. ↩
- CoW Protocol documentation on intents and solvers. Not a comprehensive security assessment of a deployment. Source 1. ↩
- iShares, IBIT 2025 annual report, custody arrangements on PDF pages 8–10 and risks on PDF page 45. ↩
- Mark Nottingham, RFC 9518, December 2023. Independent submission, informational RFC, not a Standards Track specification. Source 1. ↩
- Bitcoin whitepaper, section 8, Simplified Payment Verification; BIP-157: Client Side Block Filtering; Ethereum, Light clients. Verification scopes and trust assumptions differ. ↩
- Ethereum Foundation, Announcing the Trillion Dollar Security Initiative, May 14, 2025. Source 1. ↩
- Anthropic, AI to defend critical infrastructure, January 8, 2026, bounded research with PNNL. Source 1. ↩
- Anthropic, Mapping AI-enabled cyber threats, observed misuse study. Source 1. ↩
- Lucasfilm, Star Wars: A New Hope (Episode IV), 1977; the title and theme of collective resistance inform this essay’s metaphor. ↩