Attackers are starting to skip the code and go straight after the trust chain itself.
In an article published by TechFlowPost, author Fu Gui argues that several of crypto’s biggest recent losses did not come from undisclosed smart contract 0days. They came from compromised permissions, manipulated interfaces, poisoned RPC data, backend approval systems, and supply-chain weaknesses.
One of the latest examples came on Sept. 24, 2026, when Bitget lost about $387.5 million from its hot and warm wallets. According to the article, the attacker breached backend systems, inserted fake transaction data, and triggered the exchange’s own approval process. The CEO later said in a notice: 「自家系统批准了转账。」 The private keys were not leaked, and the cold wallet was untouched.
Five months earlier, on April 18, 2026, KelpDAO saw about $290 million worth of rsETH minted out of thin air after an RPC node returned manipulated data. The article says the contracts themselves were not written incorrectly. The attacker obtained the RPC list used by LayerZero’s Decentralized Verifier Network, compromised two independent clusters, and replaced op-geth with a malicious version. Those nodes returned false data only to DVN IPs while serving correct data to monitoring tools. A DDoS attack then pushed the system into failing over to the poisoned nodes. The DVN confirmed a transaction that never happened, and the bridge released 116,500 rsETH without a real burn.
Two weeks before that, on April 1, 2026, a Drift protocol security committee member pre-signed a blank transaction, and about $285 million was drained in 12 minutes. The article says the attacker had posed as a quantitative trading firm since the autumn of 2025, met core contributors in person at international conferences, and deposited more than $1 million of real capital into the Ecosystem Vault. After building trust, the attacker persuaded a signer to approve what looked like a harmless governance transaction. Using Solana’s durable nonce, the transfer of control was hidden inside it. Drift had just changed its multisig to zero delay and removed the timelock, leaving no time to reverse course.
Going back further, on Feb. 21, 2025, about $1.45 billion was moved out of a Bybit cold wallet in what the article describes as the largest publicly acknowledged theft in crypto to date. The attacker did not break Ethereum cryptography, did not find a bug in the Safe multisig contract, and did not directly touch the private keys. Instead, the attacker compromised a Safe{Wallet} developer machine and injected JavaScript into the signing interface. The three signers saw what appeared to be a routine cold-to-hot wallet transfer and approved it.
Taken together, the four incidents add up to more than $2.4 billion. The article’s point is blunt: none of them relied on an undiscovered contract 0day. The code had been reviewed, formal verification had been done, multisigs were in place, cold wallets were separated, and the money still disappeared.
The numbers look better, but the attack pattern has changed
The article notes that some people say security improved in 2026. Industry-wide losses in the first half of the year were estimated at $956 million to $1.39 billion, roughly half the prior year. But once Bybit’s $1.45 billion loss in 2025 is removed as an outlier, the picture changes. CertiK’s figures show a 28% year-over-year increase, SlowMist’s event count rose 50%, and the median loss per incident climbed 60.6% to $169,000.
The article argues that the cleaner headline number does not mean attackers backed off. It means there was no single record-setting event on the scale of Bybit. Instead, attacks became more numerous, more distributed, and more expensive on a per-incident basis.
Its metaphor is simple: the industry kept reinforcing the front door while the thieves started climbing through the window.
Beyond signatures: compromising people pays more than breaking code
The article says cryptography can prove that a signature is genuine, but it cannot explain why the signer approved the transaction in the first place.
In the first half of 2026, 33 wallet compromise incidents caused $445 million in losses, while 204 code-vulnerability incidents caused $152 million. Citing Hacken’s Q2 report, the article says 88% of losses came from operational compromise, while smart contract flaws accounted for 11%. Of 67 incidents, 44 were contract bugs, but together they produced less than one-tenth of the money lost.
Drift is presented as the clearest example. The attacker spent half a year building trust, then convinced a security committee member to sign what looked like a routine administrative transaction. The article describes Solana’s durable nonce in this context as a signed blank check that could be cashed later. In 12 minutes, 31 withdrawals were executed and more than half of the locked assets were gone.
The article also says North Korea’s Lazarus has industrialized this model: fake resumes, fake companies, polished LinkedIn profiles, entry into target firms, access to SSO and VPN systems, months of quiet movement, and then gradual progress toward the machines used for signing. According to figures attributed to SlowMist, North Korea-linked groups stole $2.837 billion between January 2024 and September 2025. In 2025 alone, they stole $2.02 billion, equal to 76% of service-provider losses. Only 13.2% was recovered. One year after the Bybit theft, just 3.54% had been frozen.
The article’s conclusion is that these groups are not primarily looking for code bugs. They are looking for people with authority to sign, because finding a person is cheaper than finding a bug.
The chain was not hacked. The systems around it were.
The article argues that blockchain itself was not broken in these cases. The weak points were the systems around blockchain.
KelpDAO’s contracts were not written incorrectly, yet the incident became what the article calls the first major loss directly caused by an RPC node returning false data. That exposed a dependency the industry already knew about but often treated lightly: many so-called decentralized applications still rely on a small number of cloud providers and RPC services for reads. MetaMask uses Infura by default. dApp backends often rely on Alchemy and QuickNode. L2 sequencers depend on the same class of providers, many of them running on AWS us-east-1. A chain can have a thousand validators, the article says, but if everyone trusts data returned by two or three cloud providers, decentralization is thinner than it looks.
TRM Labs data is used to sharpen that point. Infrastructure and operations incidents account for about 15% of events but roughly 76% of losses. SlowMist’s first-half data, as cited in the article, says supply-chain attacks ranked third by incident count but first by dollars lost at about $298 million, with KelpDAO alone making up $290 million.
The article says traditional hackers are also using blockchain itself as part of the attack infrastructure. A September 2026 Chainalysis report called this pattern Blockchain Dead Drops. Malicious code and command instructions are no longer hosted only on servers. They are written into BSC smart contracts and Bitcoin transactions. Taking down domains or unplugging servers does not solve the problem because on-chain data cannot be deleted. Any infected machine that can still query the chain can fetch fresh instructions. Over the past 12 months, this activity rose 420%, and groups linked to North Korea and Iran accounted for about two-thirds of new activity.
Google Threat Intelligence also observed UNC5342 using the EtherHiding technique from February 2025 onward, targeting crypto developers through fake recruiting campaigns and hiding code in smart contracts on TRON, Aptos, and BNB Chain.
The article’s point is that blockchain’s immutability, one of its strongest features, can also become a durable command-and-control layer for attackers.
From a bug economy to a permission economy
The article says Web3 has moved from a bug economy to a permission economy.
The old sequence was straightforward: find a bug, exploit the bug, move the money. The new sequence is different: find the person with signing authority, persuade that person to sign, then move the money in a way that looks fully legitimate.
Bybit and Bitget are paired as the clearest examples. In the Bybit case, signers believed they were moving funds to a hot wallet for liquidity. In reality, they signed a transfer to the attacker. In the Bitget case, the attacker did not even need to alter the frontend. The backend approval system itself was fed fake transaction data, recognized it as a normal internal transfer, and signed the funds out.
Both losses looked legal on the surface. The multisig process completed. The signatures were real. The contracts executed according to the rules. The problem was not whether someone could break the system. It was who had the authority to approve the transfer and what data those people or systems were relying on. If three signers all read from the same poisoned RPC and all depend on the same cloud provider, then 3-of-5 is decentralized only on paper.
The article calls this pseudo-decentralization. A protocol may achieve mathematical 3-of-5 decentralization at the contract layer while the infrastructure layer runs on one cloud provider, depends on one RPC source, and is operated through one browser environment. That, it argues, is the most dangerous kind of single point of failure.
It lists several 2026 incidents in that frame: KelpDAO used a 1-of-1 single DVN setup, Drift had a 2-of-5 zero-delay multisig plus a blank-check style transaction, Resolv Labs relied on a single AWS KMS key, and Wasabi had one external account holding all admin privileges. None of those were new vulnerabilities. They were known configuration problems and, in each case, a single point of failure.
Dune data cited in the article says 47% of applications in the LayerZero ecosystem still use a 1-of-1 single DVN setup, 45% use two, and only 5% use three or more. The article says a developer had warned KelpDAO on the Aave governance forum 15 months before the incident to add more validators, but no change was made. After the incident, LayerZero announced it would no longer sign for any application using a 1-of-1 configuration.
The article’s warning is that the most dangerous transactions often look the most compliant.
AI changed the economics by making attacks scalable
The article says AI did not suddenly make attacks intelligent. It made them scalable for the first time.
In the past, a scammer targeting one victim with one social-engineering campaign might spend a month on the setup, which made the process expensive. That is why phishing often relied on broad spam. Now AI can generate fake identities, fake websites, phishing copy, code scans, target lists, and attack attempts automatically.
The article says the North Korea-linked group HexagonalRodent stole 26,584 wallets from 2,726 developer machines in three months. Its backend reportedly included a live infostealer view, VNC-style remote control, a browser file manager, and a wallet performance dashboard organized by team and member. Delivery relied on VS Code’s tasks.json with runOn: 「folderOpen」, so simply opening a project folder triggered execution without any click. The article says the operators used ChatGPT and Cursor to write malicious code, used AI to generate fake companies and executive profiles, and even used AI to test whether the backdoor could evade antivirus tools.
TRM Labs’ AI crime index, according to the article, rose from 28 in 2024 to 54. Losses from deepfake scams in 2026 had already reached 263% of the full-year 2025 total.
The article also cites SCONE-bench, a benchmark created by researchers from Anthropic and MATS using 405 real smart contracts that had been attacked. AI agents reproduced attacks worth $4.6 million in a simulator. When screening 2,849 new contracts with no known vulnerabilities, they found two 0days worth $3,694, at an API cost of $3,476, for an ROI of about 1.06x. The article says that return is only slightly above break-even, but it is an early result. If model capability improves by another generation, or if contract scale grows by another order of magnitude, the economics could change quickly.
Defenders are using AI too. One day after Claude Opus 4.8 was released, someone used it to find a soundness flaw in the ZK circuit of Zcash’s Orchard privacy pool, a bug that had been present for four years. An attacker could have used it to mint unlimited ZEC without detection. Zcash responded by activating an emergency hard fork to isolate the risk. The article notes that Zcash has a turnstile mechanism, a cross-pool accounting check that prevents total supply from inflating without bound even if the Orchard pool itself fails. That is presented as an example of runtime protection catching what cryptography alone did not.
The article says AI is pushing costs onto defenders. A highly customized phishing email can now be written in seconds. A convincing fake video meeting can be assembled in minutes. Scanning thousands of old contracts is no longer expensive. Defenders have to secure every entry point. Attackers need only one success. Four social-engineering attacks caused $310 million in losses, equal to 85% of all phishing losses cited in the article.
Old code has become a target again. In the second quarter of 2026, code-vulnerability incidents rose from 78 in the first quarter to 126. Attackers began systematically revisiting contracts that had been deployed for years and never re-audited. On BNB Chain, the article says, there were 33 attacks on old tokens in the first half, with losses ranging from tens of thousands to hundreds of thousands of dollars per incident, and those were described as AI-assisted bulk scans. An audit, the article says, is a snapshot from deployment day. The attack surface keeps moving after that.
AI agents are also becoming a new target class. Because agents can read context, call tools, and sign transactions, a malicious instruction hidden inside normal input can turn into a real financial loss. After EIP-7702 went live, a USENIX 2026 study found that 63% of malicious delegations pointed to malicious contracts. Account abstraction made things easier for users, the article says, but it also widened the opening for attackers. In the past, the threat model focused on hackers. Going forward, it also has to include agents that can legally and efficiently send money to the wrong party after receiving a poisoned prompt.
Audits still matter, but they cover less of where losses happen
Citing CoinGecko’s 2026 Crypto Security Report, the article says 245 incidents caused $3.63 billion in total losses, and 147 independently audited protocols accounted for 88.44% of that amount. Only 11% of attacks hit contract defects that were within audit coverage. Supply-chain and infrastructure flaws caused more than $1.8 billion.
The article does not argue that audits are useless. It argues that audits increasingly examine a shrinking share of the places where attackers strike. Audits review contract code at the moment of deployment. The 2026 attacks described in the piece hit deployment keys, RPC dependencies, multisig workflows, supply chains, and code added after the audit was complete.
Supply-chain attacks were the largest loss category in 2026, at $298 million by the article’s SlowMist-based figure. A malicious npm package with billions of weekly downloads can enter frontends, SDKs, and wallets and cause users to sign the wrong transaction. The article says North Korean operators set up a fake company called Veltrix Capital, sent job offers to open-source maintainers, and planted 24 malicious packages on npm and 12 on PyPI. Its line is memorable: the best backdoor is the one the user installs personally.
The older security playbook was simple: write code, audit it, run a bug bounty, deploy, and pause the contract if something goes wrong. That model assumed the biggest risk was a bug in the code. The article says that assumption no longer holds.
Defense has to follow the attack surface
The article says the first diagram a security team should draw is no longer the smart contract architecture. It should be the full path of money from entry to exit: from user wallet to treasury, through which signing nodes, which administrators, which oracles, and which bridges. At each point, the questions are practical: if this node is compromised, how much can be moved; how many signatures are required; can it execute automatically; is there a timelock; is there a second place to verify the action; and can the system be stopped immediately if something goes wrong.
It also argues against concentrating everything in one failure domain. The real question is not how many signers exist, but whether they all depend on the same trust source. If five signers all use the same cloud provider, the same browser, the same hardware wallet, and the same RPC feed, then 3-of-5 still collapses into one point of failure in practice. Real multisig resilience, the article says, requires hardware diversity, network diversity, keys spread across jurisdictions, and separation between offline and online signing.
As an example from infrastructure, the article points to a flawed interconnect route released by TeraSwitch in July 2026 and propagated through a route reflector in Amsterdam. About 28.83% of staked SOL on Solana went offline at the same time, only about 4.5 percentage points below the 33.34% finality threshold. Ninety validators were affected, and recovery took about 40 minutes. Solana had 699 staked validators, but a single autonomous system, AS20326, carried about 27.34% of staked SOL. The article uses that incident to argue that validator decentralization does not automatically mean infrastructure decentralization.
That is why, in the article’s view, decentralization has to extend from the consensus layer into the dependency layer. Shared sequencers, multiple DVNs, and failure-domain independence are presented as the mechanisms that actually break single points of failure.
RPC data should not be trusted by default. For systems that touch large amounts of money — oracles, bridges, liquidations, governance, treasuries — the article says decisions should not be made from a single RPC response. At least three providers should be cross-checked, and any disagreement should be treated as an attack rather than a network hiccup. Large-value paths should run their own full nodes instead of relying entirely on third parties. After KelpDAO, the article says, verifiable RPC services that can return cryptographic proofs are likely to move from a nice feature to an institutional requirement.
Wallets should not stop at checking whether a signature is valid. They should check whether the transaction matches the user’s intent. The article gives a simple example: if the user wants to swap 1,000 USDC for ETH with slippage capped at 0.5%, the wallet should simulate the transaction, run it through a risk engine, and confirm that the transaction actually does that before asking for a signature. Malicious calldata, unlimited approvals, address substitution, and frontend tampering can often be blocked at that layer.
A four-layer defense model and shared risk
The article proposes a four-layer defense structure.
Layer one is permission governance. Ban 1-of-1 configurations, whether for DVNs, multisigs, or ADMIN_ROLE. Force timelocks on all high-privilege actions. Separate deployment keys from runtime keys, and transfer the deployer EOA immediately after deployment instead of leaving it with long-term admin power.
Layer two is infrastructure hardening. Production systems should connect to at least two RPC providers on different cloud platforms for failover. Critical actions such as withdrawals, minting, and oracle updates should verify block headers or Merkle proofs rather than trusting eth_call responses directly.
Layer three is runtime protection: circuit breakers, rate limits, and alerts for abnormal amounts. The article says the goal is to reduce maximum loss from total value locked to a function of time window multiplied by limit. It points to THORChain’s Solvency Checker and Outbound Delay as a model. Observer nodes compare actual balances on the underlying native chains with the protocol’s own state-machine accounting in real time. Even if chain logic or RPC nodes are compromised and assets are fabricated inside the state machine, a mismatch in reconciliation can suspend large withdrawals immediately and use time as a physical brake.
Layer four is continuous review instead of one-off auditing. Attack methods evolve faster than deployment-day reviews. Monitoring matters because it observes what the system is doing now, not what the code looked like three months ago.
The article also says teams should accept that intrusion is possible and design around that fact. The goal should not be to stop every attack. It should be to prevent a single breach from emptying the treasury in one move. A treasury should not allow a $100 million transfer in one transaction. Small transfers can be automatic, larger ones should trigger a timelock, and very large ones should require manual review. On-chain monitoring should continuously watch transaction behavior, permission changes, oracle deviations, RPC disagreement, and gas anomalies. Security, in the article’s framing, is not one thing. It is prevention, detection, blocking, and tracing together.
On shared risk, the article notes that Aave froze the rsETH market within hours of the KelpDAO incident and that several protocols helped absorb bad debt. It argues that decentralized insurance is not only about paying claims after the fact. It spreads risk across network participants and gives token holders a reason to care about protocol security. Nexus Mutual is said to be planning OpSec Failure Cover, while OpenCover has launched Covered Vaults that embed risk transfer directly into vault products. The article also points to a more intertwined capital structure in which the same restaked capital both secures networks and insures DeFi treasury risk. If something goes wrong, the paired capital can be slashed automatically to compensate depositors.
Insurance pricing, the article says, will become the market price of security architecture. An insurer deciding whether to cover a protocol will ask how many multisig signers it has, whether there is a timelock, whether RPC is a single point of failure, how many independent oracle sources exist, what the treasury’s maximum transfer size is, and whether circuit breakers are in place. That is not just a security team checklist. It is capital markets assigning a value to the design.
Attackers are no longer looking for bugs. They are looking for trust.
The article closes by tracing the shift over the past three years.
In 2024, total losses reached $2.36 billion, and phishing overtook private-key leakage as the largest threat, pushing the industry to confront the human factor. In February 2025, Bybit’s $1.45 billion theft helped drive the annual total to $3.35 billion and turned frontend supply chains and signing interfaces into the most dangerous entry points. In 2026, KelpDAO, Drift, and Bitget together accounted for more than $900 million in losses, with RPC dependencies and permission configuration becoming the main battleground. AI, the article says, turned attacks into an assembly line, and even traditional hackers started using blockchain as infrastructure.
Across those three years, the route taken by attackers became clear: from attacking code to attacking people, from attacking on-chain logic to attacking off-chain infrastructure, and from hunting vulnerabilities to hunting trust relationships. The article says direct losses at the consensus and execution layers of seven major public chains were close to zero over that period. The chains themselves became harder targets. The big money was lost around the chain — in people, processes, configurations, and infrastructure.
Its final argument is that Web3 did not simply become less secure. The most valuable attack surface moved from inside the code to outside it. Cryptography can prove that a signature is real, that a transaction was not altered, and that on-chain records cannot be erased. It cannot prove that the signer was not deceived, that the data shown to that signer was accurate, that an approval request was genuine, or that an RPC-reported balance actually existed on-chain. Those are not cryptography problems. They are trust problems.
That is why the article says future security will not be only about code. It will be about the whole system, and more deeply, about the entire trust chain. It will not be a task that ends after code is written and audited once. It will be a continuously running system that covers people, permissions, infrastructure, supply chains, and AI, with independent verification at each layer and controls that stop one compromised point from blowing through the entire system.
The design goal, in the article’s final formulation, is not: we will never be breached. It is: even if one person is compromised, one RPC feed is poisoned, one dependency is infected, one signer is deceived, or one agent makes the wrong decision, the whole treasury still cannot be drained directly.
The real test is whether the rest of the system can stay standing after one part falls.
The old question was whether a contract had a vulnerability. The article says the next question should be different: who can move the money, what data are they using to decide, can that data be trusted, and who catches the failure if something goes wrong?
Ask the right questions, and the defenses end up in the right place.