July 2026 Protocol Recap: Capacity, Consensus, Confidentiality

TL;DR: Executive Summary

• • Enshrined Proposer-Builder Separation: EIP-7732 decouples execution validation from consensus validation -> implement for Glamsterdam, planned for H2 2026, to enable trust-free exchange between proposers and builders and remove full payloads from consensus blocks.

• • Block-Level Access Lists: EIP-7928 enforces commitments to all accessed accounts and storage locations -> adopt to enable parallel transaction execution and allow state reconstruction without full execution. Geth v1.17.5 implements EIP-7928.

• • Mandatory Client Security: Nethermind v1.39.2 updated to .NET 10.0.10, addressing 17 CVE fixes -> upgrade immediately as it is a mandatory security patch. Prysm v7.1.8 also provides fixes for state corruption during Fulu-to-Gloas forks.

• • OP Stack Node Synchronization: op-node v1.19.3 syncs embedded configs for Karst gas compatibility -> mandatory upgrade for Mode, Metal, and Zora operators using built-in –network configs to maintain canonical behavior. All other operators are recommended to upgrade.

• • Firedancer Mainnet Readiness: Frankendancer Mainnet v0.1007.40100, released July 30, 2026, reduced memory consumption to approximately 350 GiB -> deploy “mainnet ready” versions for testing while utilizing offline replay services for consensus consistency. No official July Firedancer mainnet TPS or stake metrics have been disclosed.

• • Solana Capacity Expansion: Alpenglow, currently in review, targets a finality latency of roughly 150ms -> prepare for its Q3 2026 mainnet activation. The 100M CU block limit, which increased capacity by 66%, was activated on July 29, 2026.

• • Confidential Compute Architecture: Inco TEE utilizes attested flows for decryption and compute -> integrate the Smart Contract Library for encrypted types and verify covalidator signatures on-chain via inco.incoVerifier().isValidDecryptionAttestation.

• • Solidity Compiler Integrity: Version 0.8.36 fixes unsound spills in mutual recursion, preventing Yul optimizer misclassifications, and resolves inheritance order reversal warnings that corrupt the inheritance hierarchy -> update to Solidity v0.8.36 to mitigate these medium-severity vulnerabilities.

• • Infrastructure Security Hardening: Ostium lost 23,752,746 USDC on July 15, 2026, due to compromised off-chain price reporting via a registered forwarder contract -> implement multi-party approvals for production environments and monitor registered forwarder contracts for unauthorized activity. The specific method of off-chain infrastructure access remains unconfirmed.

Ethereum Glamsterdam: ePBS and BALs Rewire the Block Pipeline

The Ethereum Glamsterdam upgrade, targeted for H2 2026, represents a fundamental reorganization of the network’s block production and execution architecture. As of July 2026, development has progressed through DevNet 7, which successfully onboarded 3,000 validators to test the new consensus logic.

Enshrined Proposer-Builder Separation (ePBS)

EIP-7732 introduces ePBS to remove reliance on third-party relays by integrating the proposer-builder hand-off directly into the protocol. This Draft EIP establishes a dual-deadline pipeline and a Payload Timeliness Committee (PTC). The PTC validates the timeliness of the builder’s execution payload without requiring full execution, allowing the propagation window to expand from 2 seconds to approximately 9 seconds.

Block-Level Access Lists (BALs)

EIP-7928, currently in Review, introduces Block-Level Access Lists (BALs), which provide an upfront map of all accounts and storage locations accessed during block execution. BALs enable parallel disk reads and transaction execution by identifying non-overlapping dependencies before processing begins. While the average compressed BAL size is approximately 72.4 KiB, the structure is constrained by the block gas limit rather than a fixed item count.

Pipeline Specifications and Constraints

Feature	Specification	Source
PTC Validation Window	~9 seconds total propagation
BAL Item Cost	2000 gas per item
Target Gas Limit	100M (with 200M floor potential)

Security and Failure Cases

The ePBS framework ensures “Proposer unconditional payment,” meaning proposers receive payment even if a committed payload is not revealed. To prevent malicious BALs from forcing unnecessary I/O, clients enforce a gas-budget feasibility check: the remaining block gas must always be greater than or equal to the number of declared storage reads multiplied by 2000.

Glamsterdam’s structural changes are designed to sustain a 100M gas limit while maintaining decentralized hardware requirements. Developers utilized DevNet 7 to identify and fix small bugs with an 80-90% participation rate before moving toward public testnets.

Ethereum Clients and L2s: July Releases Prepare for Higher Load

Ethereum execution and consensus clients, alongside major Layer 2 stacks, issued critical updates in July 2026 to enhance throughput and security ahead of the Glamsterdam upgrade. These releases focus on optimizing state management and preparing for the integration of EIP-7928 Block-Level Access Lists (BALs).

Execution and Consensus Client Updates

Nethermind released v1.39.2 on July 21, 2026, which is a mandatory security patch addressing 17 CVEs in .NET dependencies. This version also introduces an explicit, configurable eth_getLogs block-range limit to prevent node exhaustion. Geth (go-ethereum) followed with v1.17.5 “Grav-Torque Pad” on July 27, 2026, implementing several Amsterdam EIPs, including EIP-7928 for BALs and EIP-8037 for state creation gas cost increases. Geth also bumped the default GOGC from 20 to 50 to reduce garbage collection overhead at the cost of higher memory usage.

Consensus clients also saw critical updates. Lighthouse v8.2.1, released July 21, 2026, is a high-priority release addressing security vulnerabilities and optimizing proposer preparation. Prysm v7.1.8 followed on July 27, 2026, fixing libp2p bugs to improve the propagation of early attestations. Teku v26.7.1 was released on July 11, 2026, as a strongly recommended update containing security fixes and SSZ output for the validator balances API.

Client	Version	Key Feature	Priority
Nethermind	v1.39.2	17 CVE Security Fixes	Mandatory
Geth	v1.17.5	Amsterdam EIPs (BALs)	Recommended
Reth	v2.4.1	Alloy Dependency Updates	High
Lighthouse	v8.2.1	Security Fixes	High
Prysm	v7.1.8	Early Attestation Handling	Recommended
Teku	v26.7.1	Security Fixes	Recommended

Benchmarks and Execution Limits

Reth v1.11.0, released in February 2026, utilized a sparse trie as a cache to reduce mean newPayload latency by 25% and increase throughput to 1G gas/s. By June 2026, Reth v2.3.0 demonstrated further performance gains through parallel execution work and BAL prewarming. These improvements are part of a broader effort to establish a 200M gas limit floor post-Glamsterdam.

L2 Stack Evolution: OP Stack and Nitro

The OP Stack introduced the Karst fork, which activated on OP Mainnet on July 8, 2026. This fork includes precompile input-size caps and Engine API capability gating. A notable case study is the removal of Base mainnet and Sepolia configurations from bundled Nethermind profiles in v1.38.1, requiring operators to provide their own chainspecs. Arbitrum’s Nitro stack reached v3.11.2 on June 30, 2026, adding support for retiring chains off AnyTrust and optimizing address filtering to prevent OOM errors.

Deployment Guidance

Node operators must distinguish between mandatory security patches and optional performance features. Nethermind v1.39.2 is mandatory due to Microsoft servicing updates. Operators seeking higher efficiency should opt into experimental features like Nethermind’s Flat DB, which swaps the pruning-trie for flat account records to improve random read speeds. For Geth users, upgrading to Pebble v2 via geth db pebble-upgrade is recommended for improved key-value store performance.

Solana Validator Stack: Firedancer 1.0 Needs Metric Discipline

Client	July 16	July 23	July 30
Agave	v4.1.1	v4.1.2	v4.2.0-rc.0
Firedancer	v1.1.1	v1.1.2	v1.1.2
Frankendancer	v0.1005.40100	v0.1006.40100	v0.1007.40100

Frankendancer is an intermediate milestone that enables testing by using an Agave process for replay, gossip, and repair, while Firedancer is built from the ground up in C. Firedancer Testnet v1.1.0, released July 15, materially reduced memory consumption to approximately 350 GiB with a new accounts database. This release also included network optimizations such as XDP busy polling and improved DZ/GRE tunnel support to enhance packet handling.

Firedancer is a new validator client for Solana written entirely in C. Synthetic benchmarks for Firedancer reached 278,380 transactions per second (txn/s) on a 32-core AMD EPYC 7513 processor, though Solana protocol consensus limits cap the network at approximately 81,000 TPS. Official July mainnet TPS or stake share data for these clients has not been disclosed. An offline replay service is being developed to test replay correctness and ensure consistency between Agave and Firedancer implementations.

To minimize kernel interference, operators are recommended to use irq-affinity, kworkers, and cpuset to isolate CPU cores. These configure stages, introduced in Firedancer Testnet v1.1.0, prevent the operating system from taking time from validator tiles. Proper hardware tuning is crucial because signature verification remains a primary bottleneck for performance.

Alpenglow and 100M-CU Blocks: Faster Finality Meets Higher Load

Solana is undergoing its most significant consensus transformation since TowerBFT with the introduction of Alpenglow. This upgrade replaces Proof-of-History and TowerBFT with Votor, a new voting and block finalization algorithm. While Votor handles consensus, a later phase is expected to introduce Rotor to replace Turbine as the data dissemination protocol, utilizing a single relay layer to minimize network hops.

Consensus and Finalization Mechanics

Alpenglow targets a median finality of 150ms, a significant reduction from the 12.8-second TowerBFT finality. The protocol utilizes integrated one-round and two-round voting modes: * Fast-finalization: A block is finalized in a single round if 80% of the stake notarizes it. * Slow-finalization: If the 80% threshold is not met, finalization occurs after two rounds of votes from 60% of the stake. * Resilience: The protocol maintains safety and liveness by tolerating up to 20% adversarial stake and 20% non-responsive stake.

Unlike TowerBFT, votes in Alpenglow are not on-chain transactions; they are sent directly between validators to eliminate gossip overhead.

100M-CU Blocks and Fee Reform

On July 29, 2026, SIMD-0286 activated on mainnet, raising the maximum block compute limit from 60M to 100M CUs. This 66% increase provides headroom for high-volume spikes without altering the 12M CU per-account write limit.

Accompanying these changes are new fee structures. SIMD-0553, which moved to accepted status in July 2026, proposes splitting the base fee into a 2500-lamport Base Inclusion Fee (100% to leader) and a Resource Fee based on requested cost units (100% burned).

Comparison and Status

Feature	TowerBFT (Legacy)	Alpenglow (Votor)
Finality Latency	12.8 seconds	150ms (Design Target)
Voting Method	On-chain Transactions	Direct Validator Communication
Block CU Limit	60M CUs	100M CUs (Active July 29, 2026)
SIMD-0326 Status	N/A	Review

Failure/Trade-off Analysis: Alpenglow trades the 33% byzantine fault tolerance of two-round protocols for 40% crash resilience and lower latency. Higher-load blocks (100M CU) increase the risk of longer execution times, which can slow block replay for validators and lengthen catchup times for nodes that fall behind. The primary drawback is the implementation risk of a total consensus replacement.

TEE Privacy: Attestation Becomes the New Consensus Boundary

The security of Trusted Execution Environments (TEEs) is increasingly defined by the IETF Remote Attestation Procedures (RATS) framework, which separates the roles of the Attester, Verifier, and Relying Party. In this model, the Attester produces Evidence-cryptographic claims about its hardware and software state-which a Verifier appraises against appraisal policies and Reference Values to produce Attestation Results. For decentralized networks, the Relying Party is often an onchain smart contract that must verify these results before allowing the Attester to participate in the consensus boundary or access sensitive state.

Inco implements this framework through a modular architecture that extends the EVM with encrypted data types like ebool and euint256. Its Confidential Compute Server acts as the Attester, executing operations within a TEE enclave. The system utilizes “Attested Decrypt” and “Attested Compute” mechanisms, where the TEE generates signed cryptographic proofs of offchain execution. These proofs are then submitted to an onchain incoVerifier contract, which acts as the Relying Party to validate signatures and ensure the results match the expected onchain handles.

Programmable Access Control Lists (ACLs) govern this boundary, using functions like e.allow to grant specific addresses or contracts the right to compute over or decrypt ciphertexts. The network’s public keys are used by client-side libraries to encrypt inputs, while the TEE manages the corresponding private keys within the secure enclave to prevent exposure. This ensures that even if the host blockchain is public, the underlying data remains confidential until an authorized attestation triggers a reveal.

TEE Threat Model and Mitigation

Threat Category	Description	Mitigation/Status
Hardware Vendor	Compromise of CPU manufacturer root keys (Intel/AMD)	Use of multi-vendor TEEs or MPC wrapping; documentation gap on vendor key revocation
Physical	Bus interposition or DRAM probing (e.g., TEE.fail)	Datacenter physical security and Platform Ownership Endorsements (PoE)
Side Channel	Information leakage via timing or cache analysis	Constant-time cryptographic libraries and hardware-level isolation
Rollback	Replaying old TEE states or outdated firmware	Nonce-based freshness and TCB recovery mechanisms
Verifier/Policy	Malicious appraisal policy or compromised Verifier	Onchain verification of DCAP quotes and auditable appraisal logic
Key Compromise	Extraction of attestation or decryption keys	Hardware-backed key protection and PUF-based regeneration (future)

Actionable Recommendations

• • Implement Freshness Mechanisms: Use nonces or synchronized clocks to prevent replay attacks on Evidence and Attestation Results.

• • Enforce Onchain Verification: Ensure all TEE outputs are validated by an onchain verifier contract before state transitions.

• • Adopt Platform Ownership Endorsements: Use PoE to cryptographically bind hardware identity to a specific operator’s physical environment.

Smart-Contract Tooling and Security: July’s Failures Cross Trust Boundaries

Tooling Component	Version	Release Date
Solidity Compiler	0.8.36	2026-07-09
Hardhat	v3.10.0	2026-07-16
Hardhat	v3.11.0	2026-07-20
Hardhat	v3.11.1	2026-07-23

Solidity 0.8.36 addressed two medium-severity bugs. SOL-2026-2 (UnsoundSpillInMutualRecursion) occurred when the Yul optimizer misclassified mutually recursive functions as non-recursive, causing local variables to be moved to fixed memory offsets and corrupted during recursion Solidity 0.8.36 Release Announcement. SOL-2026-3 (InheritanceOrderReversalOnStorageEndWarning) involved a warning for storage layouts near the end of the address space that unintentionally reversed the linearizedBaseContracts AST annotation in place, affecting inheritance resolution in later compiler phases Release: Version 0.8.36.

On July 15, 2026, the Ostium exchange lost 23,752,746 USDC from its public OLP vault. The attacker, using wallet 0x321Df194646029e7A6193Ea05573d4B9c398bfD9, executed a test at 14:18:23 UTC followed by a main batch transaction 25 seconds later that extracted over 11.8 million USDC. The drain concluded at 14:23:52 UTC after eight transactions.

The exploit utilized compromised off-chain infrastructure to submit unauthorized BTC-USD price reports of $5,000 and $60,000. By manipulating these reports to appear valid, the attacker executed atomic open-and-close cycles to generate artificial profit. While the off-chain entry method is unconfirmed, on-chain contracts functioned as designed by trusting authorized signers.

Third-party analysis noted that the risk of compromised forwarders was documented in a November 2025 audit, yet remained outside the protocol’s bug bounty scope. Ostium contained the incident by freezing contracts by 15:14 UTC and migrated to a new production environment with multi-party approvals before resuming trading on July 23.

Protocol security depends on off-chain integrity. Developers should upgrade to Solidity 0.8.36 Solidity 0.8.36 Release Announcement and implement multi-party approvals for infrastructure.

Synthesis: Two Scaling Philosophies, One Verification Problem

Feature	Ethereum (Glamsterdam)	Solana (Alpenglow/Firedancer)	TEE Privacy (Inco)
Mechanism	ePBS and BALs	Votor and Rotor	Enclaves and attested flows
Scope	L1 efficiency and MEV reform	Throughput and latency	Confidentiality and state
Evidence Base	EIP drafts and client releases	Synthetic benchmarks and SIMDs	Architecture and attested flows
Failure Mode	Payload withholding	Consensus inconsistency	ACL misconfiguration
Operator Burden	Client diversity and patching	Hardware tuning and isolation	Attestation management
Time Horizon	H1 2026	Q3 2026	Active development

Ethereum’s Glamsterdam upgrade, targeted for H1 2026, centers on EIP-7732 to decouple execution from consensus. This introduces a “free option problem” where builders might withhold payloads for profit. Simultaneously, EIP-7928 introduces Block-Level Access Lists (BALs) to enable parallel execution, though it increases average block size by approximately 70 KiB.

Solana’s Alpenglow consensus, currently under review in SIMD-0326, replaces TowerBFT with Votor and Rotor components. The protocol targets a median finality of 150ms by sending votes directly between validators. Achieving high performance with Firedancer requires extreme tuning, including 9 gigantic pages and CPU isolation via nohz_full.

Inco provides confidentiality through a Confidential Compute Server within a TEE, extending the EVM with encrypted types like euint256. While L1s face consensus risks, TEE architectures are susceptible to ACL misconfigurations where e.allow can grant permanent access to ciphertext. Operators must verify attestations on-chain using the isValidDecryptionAttestation function.

Operators should prioritize client diversity and mandatory security updates, such as Nethermind v1.39.2 which addresses 17 .NET CVEs. Solana operators must monitor consistency between Agave and Firedancer using new offline replay services. The 100M CU block limit, activated July 29, 2026, further increases capacity but demands robust hardware.

Web3 Security Incidents: The Complete July 2026 Hack Ledger

July 2026 was one of the most active months on record for Web3 security incidents. Cross-referencing rekt.news, DeFiLlama’s hacks database, SlowMist’s Hacked Zone, BlockSec Weekly, CertiK Alert, Blockaid, and each protocol’s own on-chain and X/Twitter disclosures identified 33 distinct, independently verified incidents spanning DeFi lending and stablecoin protocols, cross-chain bridges, DAO governance, and hardware-wallet firmware, across Ethereum, Solana, BNB Chain, Arbitrum, Base, Hedera, Cardano, Bitcoin, and other ecosystems. Aggregate confirmed and reported losses across these incidents total approximately $253,318,886 (using the midpoint of any reported range per incident) — not counting the still-escalating Coldcard hardware-wallet seed-theft campaign, whose true final total was not yet known as of month’s end. Each entry below is independently sourced from at least one primary disclosure (official project statement, on-chain transaction data, or a named security firm’s incident report) and includes a dedicated analysis of the concrete controls that would have prevented it.

At a Glance

Date (2026)	Incident	Chain	Est. Loss	Primary Attack Vector
07-01	Edel Finance	Ethereum	$403,000	Wrapped-token exchange-rate manipulation (flash loan)
07-02	Hinkal Protocol	Ethereum	~$797K	ZK shielded-pool nullifier double-spend
07-06	BonkDAO	Solana	$20M	Zero-timelock governance takeover
07-06	Summer.fi (Lazy Summer Protocol)	Ethereum mainnet	$6.04M	Stale NAV / share-price donation attack
07-11	Bonzo Finance	Hedera	$9.05M	Oracle signature validation bypass
07-13	Chi Protocol (USC)	Ethereum	$8,500	Mint/burn peg-check asymmetry
07-13	Lumi Finance	Arbitrum	~$264K–$270K	Smart-account auto-approval abuse
07-14	Drips Network	Ethereum	$24.9K	Unsafe integer cast (uint128→int128)
07-15	Ostium	Arbitrum	$23.75M	Compromised off-chain price signer
07-15	TeleSwap	Bitcoin	$735,000	Hot-wallet key compromise (suspected)
07-15	BarnBridge Governance Takeover	Ethereum	$776K	Dormant-DAO governance takeover
07-16	DefiTuna	Solana	$569,601	Broken health-check on illiquid pool
07-17	Across Protocol	Solana	$4.5M	Forged relayer deposit (fully recovered)
07-19	Zilliqa	Zilliqa	~$1.7M-$1.8M	Biased nonce in hardware-wallet signing app
07-19	Allbridge Core	Solana	$1.66M	Flash-loan pool-ratio (pool-aliasing) manipulation
07-20	Wanchain Cardano↔BNB Chain Bridge	Cardano	$9M–$13M	Bridge signature-reuse forgery
07-21	FlashTrade	Solana	$98,000	Rollup SDK undelegation-validation flaw
07-22	AFX Trade Bridge Validator Key Compromise	Arbitrum	$24.15M	Bridge validator key compromise (social engineering)
07-22	BSquared Network (B²)	BNB Chain	$3.86M	Staking contract upgrade-authority abuse
07-22	42DAO / Balance Coin (BLC)	BNB Chain	$915K	Oracle manipulation / unbacked minting
07-23	Solido Cash	Supra	~$73,400	Oracle fallback misassignment
07-23	Verus-Ethereum Bridge	Ethereum	$7.54M	Repeat bridge logic flaw
07-24	Triple-A	Multi-chain	$11.8M	Multi-chain hot/treasury wallet compromise
07-24	Lien Finance	Ethereum	$542K	Bond-exchange multiset validation gap
07-25	Projekt Reward Vault	Ethereum	$560K	Fabricated purchase-delta accounting
07-25	Bankrbot / $BNKR	Base	$479,885	X-account takeover + unprotected wallet
07-26	ChainConnect Bridge Exploit	Multi-chain	~$650K	Broken access control on proxy callback
07-26	Garden Finance	Multi-chain	450K|HTLCsolver−databasecompromise||07−26|WEMIX	WEMIX3
07-28	LULA recycle() Exploit	BNB Smart Chain	$578K	Privileged reserve/price manipulation
07-28	Crypto DAO Pro Token	BNB Chain	$52K	Unprotected privileged function (exec())
07-30	Set Protocol (Index Coop ExchangeIssuance)	Ethereum	$9,600	TOCTOU valuation exploit
07-30	Coldcard (Coinkite)	Bitcoin	$114M–$116M	Hardware-wallet RNG fallback flaw

1. Edel Finance — $403,000 Lost to wGOOGLx Exchange-Rate Manipulation

Date: 2026-07-01  |  Chain: Ethereum  |  Estimated Loss: $403,000

Edel Finance’s Edel Lending V1 — a DeFi margin/lending protocol for tokenized equities (“xStocks”) on Ethereum — suffered a $403,000 bad-debt exploit on July 1, 2026. The attacker deployed fresh exploit contracts, drew a 180,000 USDC flash loan (confirmed on-chain via Etherscan event logs), and ran 41 rapid supply-and-borrow/deposit-redeem cycles against the wGOOGLx/GOOGLx vault in a single atomic transaction. wGOOGLx wraps GOOGLx, a tokenized Alphabet share from the xStocks family; Edel priced it not via an external feed for the wrapped token but via the wrapper’s own internal convertToAssets() share-to-asset exchange rate — a ratio derived from the wrapper contract’s self-reported GOOGLx balance and total supply. The 41-cycle loop distorted that balance-to-supply ratio, inflating the computed wGOOGLx price to roughly 78x its correct value, even though Edel’s Chainlink oracle continued to correctly report Alphabet’s real share price (~$357) throughout — SlowMist’s post-incident analysis traced the root cause specifically to Edel’s price source calling latestAnswer() against the ERC-4626-style vault’s convertToAssets() output rather than a manipulation-resistant feed. Using the inflated wGOOGLx collateral, the attacker borrowed across six lending markets — a single on-chain event alone shows a 384,215.57 USDC draw — plus wrapped wSPYx, wQQQx, wMSTRx, wNVDAx, and wTSLAx, producing the $403,000 total bad debt Edel itself confirmed. Blockaid flagged the exploit on-chain in real time as it executed. Independent trackers split on sub-figures by accounting basis: Cyvers ~$353,000 net drain (~224 ETH), CertiK ~$204,000 in drained funds (an earlier/partial estimate), and GoPlus ~$403,000 gross loss / ~$305,000 net attacker profit after flash-loan repayment — Edel’s own $403,000 bad-debt figure, corroborated by the on-chain 384,215.57 USDC borrow event, is used here per the protocol’s own disclosure. Stolen funds were swapped to ~224 ETH and moved through Tornado Cash shortly after.

Edel detected and paused all Edel Lending V1 contracts the same day, stated it will absorb the full bad debt itself and restore depositor balances 1:1, and extended a whitehat settlement offer to the attacker — who nonetheless routed the funds through Tornado Cash. The team announced a redesigned “Edel V2” oracle/pricing architecture but, as of this writing (over a month post-incident), has published no full technical post-mortem, no V2 launch, and no completed depositor restoration.

How It Could Have Been Avoided: The break was specifically that Edel’s price source called latestAnswer() on an ERC-4626-style convertToAssets() rate — a wrapper’s self-reported balance/totalSupply ratio — and composed it directly into collateral pricing without checking whether that ratio could move atomically. Fixes that map directly to this: (1) never price a vault/wrapper share by its instantaneous convertToAssets() output; use a TWAP or checkpointed exchange rate (an N-block or time-windowed average of balance/totalSupply) so a same-transaction flash-loan loop cannot move the price used for collateral valuation; (2) add a deviation circuit breaker on the wrapper exchange rate itself — reject or pause borrows if the computed wGOOGLx price moves more than a small threshold (e.g., 1-2%) between checkpoints, which would have caught a 78x same-block swing long before 41 cycles completed; (3) decouple “correct underlying price” from “correct wrapper accounting” — since Chainlink’s ~$357 GOOGL feed was accurate throughout, the fix isn’t a better price feed for GOOGLx but an independent attestation of the wrapper’s actual GOOGLx holdings (a proof-of-reserve or issuer-signed balance from the xStocks/Ondo custody layer) cross-checked against the wrapper’s self-reported totalSupply before that ratio is trusted as a price input; (4) cap borrow-per-transaction or per-block against any collateral type deposited within the same transaction, which would have bounded exposure to the single 384,215.57 USDC borrow event regardless of the inflated price; (5) require flash-loan-atomicity-aware invariant tests before listing any ERC-4626-style wrapped asset as collateral — specifically an invariant asserting “wrapper share price cannot change beyond X% within one transaction absent a real mint/burn corroborated externally,” which is testable pre-deployment via Foundry fuzzing against repeated deposit-redeem cycles and is the exact invariant that failed here; (6) wire real-time on-chain monitoring (what Blockaid did reactively) to an automatic protocol-level pause/circuit-breaker rather than an alert-only system, so containment happens within the same block as the anomaly instead of after $403K is already borrowed out.

2. Hinkal Protocol — ~$797K USDC Drained via Legacy-Note Nullifier Double-Spend

Date: 2026-07-02  |  Chain: Ethereum  |  Estimated Loss: ~$797K

Hinkal, a Stanford-based ZK shielded-pool privacy protocol for stablecoins on Ethereum/Solana/Tron (raised ~$5.5M from Draper Associates, Quantstamp, NGC Ventures), lost funds to a nullifier-binding flaw isolated to its Ethereum pool (contract 0x25e5e82f5702a27c3466fe68f14abdbbadfca826). Attacker (0xbB3f01a1b1C68F3DEB36C55342b5F5706c32fc20) probed the system with a Tornado Cash test withdrawal on 2026-07-01 and a vulnerability test swap at 2026-07-02 19:05 UTC, then ran the main theft over 85 transactions from 2026-07-02 22:11:35 UTC to 2026-07-03 00:19:23 UTC (2h7m48s). Root cause: Hinkal represents balances as Merkle-tree note commitments spent via a ZK proof plus a nullifier, but the contract only checks nullifier non-reuse — it does not itself verify a nullifier is cryptographically bound to one specific note, delegating that binding entirely to the circuit. A legacy note format (flagged on-chain by extraRandomization’s top bit = 0, i.e. getPointSign = 0) failed to uniquely bind the secret-key component nk to its commitment: nk entered the spend proof only as the product e*nk, while the nullifier derives from nk directly, so one note could yield unlimited distinct valid nullifiers. The attacker abused prooflessDeposit() — which registers a deposit without normal proof verification — to seed a 100 USDC legacy note (tx 0xfbedf0cd7ffb36b17cb963789ec68529a9125bb891aa3bede9fd66e9ce8c2f11), then repeatedly called transact() against the same note/Merkle root with fresh (e, nk) pairs, extracting 100 USDC per call to ~25,000 USDC, consolidated that into a larger legacy note via a second prooflessDeposit() (tx 0xbf7252af56be8867a12e27cc332f85e8f39e906756e559d6a076dc8bd9d50008), and repeated the double-spend at scale. Total withdrawn: ~797,000 USDC per Hinkal’s own post-incident figure (vs. ~$820K in PeckShield/CertiK’s earlier on-chain alert that most press repeated, and ~772,000 USDC per AML Crypto’s forensic reconciliation, which nets out one apparently-failed extra 25,000 USDC withdrawal attempt at 00:07:23 UTC). Proceeds were laundered immediately: 410 ETH into Tornado Cash across 14 deposits and 44.67 ETH bridged to BTC via THORChain, 2026-07-03 ~00:43–03:20 UTC. Hinkal confirmed the incident publicly on 2026-07-03, paused contracts across all chains as a precaution (despite the flaw being confined to the single Ethereum pool), engaged external security firms, reported to US federal law enforcement, pledged 1:1 user reimbursement, and sent an on-chain white-hat offer (90% return to 0xBdc77a0c69f13207aCB70a6981Cad60B4c1D1942, 10% kept as bounty, no civil action, deadline 2026-07-11 23:59 UTC) — attacker acceptance remains unconfirmed. On 2026-07-20 Hinkal announced it would fully refund users who completed its recovery-application process regardless, targeting completion by 2026-07-22, proceeding with self-funded reimbursement independent of the attacker’s cooperation. No detailed technical postmortem from Hinkal had been published as of end-July 2026.

How It Could Have Been Avoided: The chain of failure was two independent gaps that both needed to hold, and either one closing would have stopped the attack: fix the circuit constraint, or fix the deposit-path validation. On the circuit side, nk must be bound as an independent public input to both the note commitment and the nullifier — not merely folded in as a multiplicative factor (e*nk) — which is exactly the class of bug that under-constrained-signal analysis tools (circomspect, Picus, ZKAP, or manual R1CS/witness-completeness review specifically targeting “is every witness signal independently constrained, or only reachable via a product with another signal”) are built to catch; this should be a mandatory pre-deployment check on any ZK circuit governing spend authorization, not a general “get the circuit audited” pass. On the contract side, prooflessDeposit() and transact() both needed to reject any note whose format flag (extraRandomization top bit / getPointSign) marks it as the legacy, non-nk-bound scheme — a single format-allowlist check at every entry point that can create or spend a note would have blocked the entire attack chain regardless of the underlying circuit flaw, and more fundamentally, legacy and current note formats should never coexist as spendable in the same live pool once a circuit is known to be superseded — deprecated verifiers need to be fully retired, not left reachable via a low-friction bypass path like prooflessDeposit(). A redundant on-chain binding check — deriving and verifying a commitment-tied tag alongside the nullifier at the contract level, rather than trusting circuit soundness alone for nullifier-to-note binding — would have added defense in depth. Finally, a pool-level circuit breaker keyed to withdrawal velocity against a single Merkle root or note (e.g., auto-pause after N spends of the same leaf, or a per-pool $-per-hour cap) would have capped losses well short of ~$797K even if the underlying flaw went undetected, since the attack required 85 sequential transact() calls against a small number of seeded notes over just over two hours.

3. BonkDAO — $20M Treasury Drained in a Zero-Timelock Governance Attack

Date: 2026-07-06  |  Chain: Solana  |  Estimated Loss: $20M

BonkDAO, the Solana Realms/SPL-Governance DAO controlling roughly 15% of BONK’s circulating supply as treasury, lost 4,426,104,450,305 BONK (~$19.3M-$21.2M; BonkDAO’s own statement calls it “an estimated $20M”) on July 6, 2026. An anonymous wallet submitted proposal “BIP #76 – Sowellian BonkDAO” on June 30, 2026, publicly framed as a governance-reform initiative but carrying a buried second instruction: an unconditional treasury transfer to attacker-controlled wallet 9bxWkNf3BtJ6iehq9KbX9uCWMjem4TFiPZ19T2sYJHvQ. Across the 6-day voting window — concentrated over the low-attention July 4th weekend — a separate wallet spent ~$4-4.4M (via Bybit/Binance purchases plus some marginfi borrowing) to accumulate ~1% of BONK supply, enough to clear Realms’ 1% quorum by a razor-thin margin (882.38B vs. 879.95B threshold) with only 7 of 18,000+ DAO members voting (~2.9% turnout) and attacker-linked wallets holding ~99.87-99.9% of votes cast. Because BonkDAO’s Realms configuration set “instruction hold-up time” (timelock) to zero seconds, the treasury-transfer instruction executed automatically in the same block the vote closed — no review window, no veto. Within about an hour the attacker began selling ~$5.3M of the voting-power BONK; ~9 hours post-drain ~$188K moved to a centralized exchange and the remaining ~$19M was consolidated into a newly created 3-key “BONK 2.0” multisig (signers tied to both the voting wallet and the exploiter wallet, per Chainalysis), where it remains “flagged and monitored” but unrecovered as of BonkDAO’s July 13-14, 2026 update. No smart contract was exploited and no private key was compromised — every instruction executed exactly per the DAO’s own configured rules (QuillAudits: “a loaded gun” of 1% quorum + 100M BONK proposal threshold + zero-second timelock + direct treasury-transfer instructions). BonkDAO confirmed the incident via @bonk_inu at 5:59 PM UTC on July 6, said it identified the exchange accounts used to buy voting power, notified law enforcement, and stated a formal post-mortem is still forthcoming; Upbit and Kraken temporarily suspended BONK deposits/withdrawals. As of the latest reporting: no funds frozen or recovered, no arrests, no reimbursement.

How It Could Have Been Avoided: The root cause was a Realms configuration stack, not a code bug, so the fix is configuration and process, not a patch. First, enforce a non-zero instruction hold-up time (timelock) — 24-72 hours minimum — on any proposal instruction that transfers treasury assets or changes authorities, giving the community and/or a designated emergency multisig veto council a window to inspect and block execution before it fires; BonkDAO’s zero-second setting is the single change that would have stopped this attack outright, echoing the lesson Beanstalk Farms ($182M, 2022) already established for timelock-free treasury governance. Second, size quorum to the dollar value at risk instead of a flat percentage of token supply: a fixed 1% threshold that cost ~$4M to acquire against a ~$20M treasury was a rational trade for the attacker, so quorum (or a treasury-transfer-specific supermajority tier) should scale with the treasury value a given proposal can move. Third, require the Realms UI to surface a mandatory human-readable decode/simulation of every instruction in a proposal at creation and voting time, not just the free-text description — this would have exposed the buried treasury-drain instruction hidden inside “BIP #76” well before the vote closed. Fourth, snapshot voting power at a block height or timestamp predating proposal creation (or use time-weighted/vote-escrowed balances) rather than letting tokens purchased mid-vote count immediately — this defeats both flash-loan attacks and the patient, real-capital accumulation used here, since post-snapshot purchases wouldn’t register. Fifth, cap the maximum treasury value a single proposal instruction can move per epoch, forcing large transfers through a second, higher-quorum confirmation step and bounding worst-case blast radius even for a proposal that does pass. None of these are flash-loan-specific defenses — the attacker held real capital across the full 6-day window — the fix is procedural friction (timelock plus veto) and economic recalibration (quorum cost versus treasury value), not detection of financing method.

4. Summer.fi (Lazy Summer Protocol) — $6.04M Lost to a Stale-Valuation NAV Donation Attack

Date: 2026-07-06  |  Chain: Ethereum mainnet  |  Estimated Loss: $6.04M

On July 6, 2026 at 05:17:59 UTC, a single atomic transaction drained $6.04M from Summer.fi’s Lazy Summer Protocol on Ethereum mainnet: ~$5.64M from LazyVault_LowerRisk_USDC (0x98C4…cF17) and ~$0.40M from LazyVault_HigherRisk_USDC (0xE9cD…0cB06). The attacker flash-borrowed ~$65.4M USDC (+~$1M USDT) from Morpho, deposited ~$64.8M into the LowerRisk vault at the honest ~1.0665 USDC/share price to fill it to cap, then transferred — donated, no shares minted — a stash of Silo “Varlamore USDC Growth” share tokens accumulated since April 9, 2026 directly into a Silo Ark inside that vault. That Ark’s deposit cap had been zeroed post-Stream-Finance-collapse (Nov 2025) as the first step of an offboarding process but was never swept from totalAssets(), and the Silo tokens’ valuation had never been marked down since that collapse. The donation pushed NAV/share ~9.5% to ~1.1678 USDC/share (briefly showing a ~2.08M% APY artifact). Because vault redemptions drain Arks in ascending size order and stop once covered, the large manipulated Ark was sorted last and never actually paid out; the attacker’s ~$70.9M redemption was funded entirely from the vaults’ genuinely liquid Morpho/Spark/Sky positions — other depositors’ capital. After repaying the flash loan, the attacker netted $6.04M, swapped it to ~6.017M DAI on Curve, and routed a portion through intermediary wallet 0x46e0…eBa7 into Tornado Cash. Summer.fi’s own post-mortem confirms no reentrancy, oracle bug, or key compromise: contracts “behaved exactly as written.” The Guardian Module (SIP0.2) responded same-day — zeroing caps, pausing Ethereum/Base/Arbitrum/Sonic vaults (the HyperEVM pause reverted since the Guardian multisig lacked the role there, though no exposure existed). Recovery failed; ~$4M in depositor capital remained outstanding per the post-mortem, and no DAO compensation vote had passed as of early August 2026. On July 15, 2026 Summer.fi announced a full wind-down of the protocol and its Labs company, running in withdraw-only mode through August 31.

How It Could Have Been Avoided: The root cause was a two-part gap that concrete controls would have closed. First, offboarding a strategy Ark must be a single atomic operation, not a two-step process: zeroing deposit cap and excluding the position from totalAssets()/NAV should happen in the same governance action, formally verified against the invariant “cap == 0 implies excluded from NAV computation” — this alone would have prevented a zero-cap Ark from ever counting toward share price. Second, NAV should never move on raw, instantaneous balanceOf() donations: computing share price from a pre-transaction snapshot, or capping per-transaction/per-block NAV deltas (e.g., reject or clamp any single-tx share-price move above a fixed threshold like 1-2%), would have blocked the 9.5% single-atomic-transaction inflation outright and is a direct analog to oracle TWAP-plus-deviation-check protections applied to internal vault accounting instead of external price feeds. Third, an automatic circuit breaker keyed to anomalous NAV delta (not manual Guardian response after the fact) should pause deposits/redemptions the instant share price jumps outside historical bounds in one block. Fourth, positions sourced from a protocol already flagged as distressed (Stream Finance, Nov 2025) need a forced haircut or hard-coded devaluation triggered at the same time the deposit cap is zeroed, rather than remaining marked at stale par value indefinitely. Fifth, redemption pricing should be tied to the Arks actually drained to fund the payout, not a global share price that can be inflated by an untouched, illiquid, manipulated Ark — decoupling “what the redeemer is quoted” from “what other Arks actually pay out” is exactly the gap exploited here. Finally, guardian/pause roles must be provisioned and tested on every deployed chain before go-live, not discovered missing (as on HyperEVM) during a live incident, and large same-block deposit-then-redeem sequences funded by flash loans warrant a rate limit or short timelock on redemption eligibility to blunt atomic NAV-manipulation attacks structurally, independent of whether the specific accounting bug is ever found.

5. Bonzo Finance — $9.05M Drained on Hedera via a BLS Identity-Element Oracle Bypass

Date: 2026-07-11  |  Chain: Hedera  |  Estimated Loss: $9.05M

On July 11, 2026, Bonzo Finance (Bonzo Lend), an Aave v2-fork lending protocol on Hedera, lost $9.05M in principal to a forged price on a single low-liquidity pair. Root cause: Supra’s on-chain BLS pairing verifier for its Hedera pull-oracle (contract requireHashVerified_V2, 0.0.4323006) looked up a committee public key by ID; the attacker referenced committee ID 2, outside the range Supra had populated, and the lookup silently returned the zero/identity-element public key instead of reverting. The attacker paired that zero pubkey with a zero/identity-element signature; per EIP-197 the pairing equation for identity elements trivially evaluates true on Hedera’s pairing precompile (system contract 0.0.8), so the verifier accepted a price update with no valid committee signature behind it. Timeline (UTC): 00:39:53 attacker deposits 250 SAUCE (~$3) as collateral; 00:51:39.646 forged update for pair 425 (SAUCE/wHBAR) inflates SAUCE’s price ~12 orders of magnitude (real ~0.2 HBAR, injected value 1×10^30); 00:51:47 borrows 6,634,528.20 USDC; 00:51:57 borrows 34,518,389.36 WHBAR — 8 seconds from forged price to full drain, with no flash loan, reentrancy, or key compromise involved; Bonzo Lend’s contracts trusted the compromised oracle exactly as designed. A second wallet (“Wallet B,” Hedera 0.0.683607) borrowed ~$1.0M more during the still-abnormal window (~01:11–01:36 UTC), self-identified via Discord as a white-hat, and pledged to return funds; CoinDesk puts combined principal borrowed by both wallets at ~$10.06M before recovery. Legitimate pricing was restored at 01:36 UTC; Bonzo Lend was paused at 01:41 UTC and Bonzo Points at 05:50 UTC, while Vaults, Bridge, and staking ran unaffected throughout. The primary attacker (Hedera 0.0.10633526 / EVM 0x9a4966152f6e10b33cb7a37975e8619816d6a494) bridged stolen funds Hedera→Ethereum via LayerZero/Stargate through Arbitrum and Base to 0xaf20D792A19fD42dCf697ceBa6100291D96dD93e, an address originally funded with 1 ETH from Tornado Cash; tracked balances were reported inconsistently across snapshots ($3.7M → $5.25M → $5.8M per Specter/PeckShield/Whale Alert) as the attacker swapped ~15.58 WBTC to ETH — reflecting live tracking of a moving wallet, not a dispute over the core $9.05M/$10.06M figures. Supra confirmed its off-chain signing and aggregation infrastructure was never compromised, scoping impact to this one verifier bug, one pair, and one consuming protocol, and shipped a same-day mainnet fix. On July 16, 2026, Bonzo Finance Labs announced a Hedera Foundation-backed recovery facility to make Bonzo Lend users whole at pre-incident (00:51:39 UTC) valuations while pursuing recovery against the attacker separately; the stolen principal itself remained unrecovered in the attacker’s Ethereum-side wallets as of all sources reviewed.

How It Could Have Been Avoided: The single missing control was a non-zero/identity-element check before the pairing verification: Supra’s own report states it plainly — “The identity-element check alone would have prevented this attack.” That’s a one-line invariant (assert pubkey != G2::identity() && signature != G1::identity() before calling the pairing precompile) that belongs directly in the pull-oracle’s requireHashVerified path, and should be enforced by property-based/fuzz testing that specifically targets identity-element and out-of-range inputs to any EIP-197 pairing wrapper — the precompile is mathematically correct per spec but not application-safe against unvalidated callers. Second, the committee-ID lookup needed existence/bounds validation: reverting on any ID outside the populated committee range rather than defaulting to a zero-valued struct is a classic unvalidated-index bug, and a formal invariant (e.g., via Certora or Halmos: lookup(id) either reverts or returns a registered, non-identity key) would have caught it pre-deployment. Third, Bonzo Lend carried no independent circuit breaker at the consuming-protocol layer: a price-deviation check — rejecting or flagging any oracle update that moves a pair’s price beyond a bounded percentage from a short TWAP or the last accepted price, rather than accepting a 12-order-of-magnitude jump — would have caught the forged SAUCE/wHBAR update regardless of the upstream signature flaw, and can be enforced independent of oracle trust. Fourth, long-tail/low-liquidity pairs like SAUCE/wHBAR warrant explicit borrow caps or per-block/per-pair maximum newly-borrowable-value limits, so a successful price forgery can’t be monetized into an 8-second multi-million-dollar drain — limiting blast radius as a backstop to fault prevention. Finally, multi-oracle cross-validation — requiring agreement within tolerance from a second, independently-signed price source before accepting large valuation swings — adds redundancy outside a single verifier contract, which matters for any protocol delegating price truth to one external pull-oracle path as Bonzo Lend did here.

6. Chi Protocol (USC) — $8,500 Drained via Hardcoded Peg Price in ArbitrageV5.burn()

Date: 2026-07-13  |  Chain: Ethereum  |  Estimated Loss: $8,500

On July 13, 2026 (block 25520523, 01:47:23 UTC), an attacker (0xF7105F68085294B6A45DD7231A6987b070E1AbaF) extracted ~4.66 WETH (~$8,500) from Chi Protocol’s USC stablecoin system on Ethereum in a single transaction, using a contract deployed in the same tx (0xc97dfc27769cb0ac8266b301c935cb492c75668c). Root cause: Chi Protocol’s ArbitrageV5 contract enforced peg validation asymmetrically between mint() and burn(). mint() checked _almostEqualAbs(uscSpotPrice, USC_TARGET_PRICE) before issuing USC, but burn() computed reserveAmountToRedeem = amount * $1 / reservePrice off a hardcoded USC_TARGET_PRICE with no spot-price check at all. USC was already trading well below $1 on a thin Uniswap V2 USC/WETH pool by the time of the exploit. The attacker bought ~17,342.71 USC for ~0.1576 ETH on that depegged pool, sourced additional liquidity via a 1.71 weETH → 1.88 ETH swap on Uniswap V3, then burned the cheap USC through ArbitrageV5 against the ReserveHolder at the hardcoded $1 rate — redeeming full-value weETH/stETH/WETH collateral (1,655.03 USC per Burn event, several thousand USC total, confirmed via Burn(account, amount, reserveReceived, reserve) events on the USC token contract 0x38547d918b9645f2d94336b6b61aeb08053e142c) — before swapping the remainder back to ETH. DeFiLlama classifies the technique as a “Flashloan Accounting Logic Exploit”; secondary reporting (DefimonAlerts) attributes the initial buy leg to a ~5 WETH Balancer flash loan, though this is not directly visible in the fetched Etherscan trace. Protocol TVL was already only ~$883 immediately before the transaction, indicating USC was functionally defunct and this was a terminal dust-drain rather than the event that broke the peg. No official Chi Protocol post-mortem, pause, or reimbursement was issued — none was found across @ProtocolChi, SlowMist, DeFiLlama, or independent researcher write-ups.

How It Could Have Been Avoided: The defect is a single missing invariant: burn() must price redemptions the same way mint() prices issuance. Concretely, ArbitrageV5.burn() should have called the identical _almostEqualAbs(uscSpotPrice, USC_TARGET_PRICE, tolerance) guard used in mint(), sourcing uscSpotPrice from a manipulation-resistant feed (a Uniswap V3 TWAP over a multi-block window, or a Chainlink/redundant-oracle feed) rather than allowing a hardcoded $1 constant to stand in for market price on the redemption path — a thin, single-block-manipulable Uniswap V2 spot pool should never be trusted as ground truth for either leg. Beyond the direct fix, a redemption-side circuit breaker keyed to ReserveHolder collateralization ratio (computed from live spot prices, not the peg constant) would have halted burns once reserves could no longer back redemptions at par, and a per-block/per-tx redemption cap sized to actual pool depth would have capped the blast radius even if the price check were bypassed. Formal specification of the mint/burn symmetry invariant — “USC redeemable via burn() at time T can never exceed USC mintable for the same collateral at time T” — as a property test or Certora/Halmos rule would have caught this exact mint/burn asymmetry pre-deployment, since it’s a structural logic-consistency bug rather than an oracle-manipulation or access-control issue. Given the protocol’s near-zero TVL, ongoing peg monitoring with automated alerting on sustained deviation, paired with an automatic pause on the mint/burn module once deviation exceeds a defined band, would also have prevented a de facto insolvent contract from remaining redeemable at par long enough for this drain to occur.

7. Lumi Finance — ~$264K–$270K Drained via Sodium Smart Account Auto-Approval Exploit

Date: 2026-07-13  |  Chain: Arbitrum  |  Estimated Loss: ~$264K–$270K

On July 13, 2026, an attacker drained an estimated $264,000–$270,000 from users of Lumi Finance (Lumiterra ecosystem’s algorithmic stablecoin/token protocol) on Arbitrum One by abusing its “Sodium” ERC-4337 smart accounts (SlowMist and Olympix report ~$264K; Blockaid, GoPlus, and DeFiLlama report $270K — likely a token-price snapshot/scope difference, not a factual dispute). Root cause was two compounding bugs in Sodium’s validateUserOp path. First, an ERC-1271 signature-validation bypass: when ECDSA.tryRecover() failed to recover a valid owner signature, the code fell back to calling isValidSignature() on an attacker-supplied “signer” contract, which deliberately returned the ERC-1271 magic value (0x1626ba7e); the same malicious contract was also submitted as the session key, and Sodium’s isSafe check defaulted to true when no session was already configured, skipping external session validation entirely — so signer == sessionKey == attacker contract, with validationData = 0 (success) and no genuine owner authorization. Second, a validation-phase state mutation: Sodium’s validateUserOp() called an internal _approvePaymasterToken() helper against attacker-controlled paymasterAndData regardless of signature-check outcome; the malicious “paymaster” (the same contract) forced a type(uint256).max allowance with itself as spender, causing the account to call token.approve(attacker, max) on assets like USDT0 as a side effect of merely validating the UserOperation. The attacker set callGasLimit to 0 so the real execution step failed harmlessly out-of-gas without reverting the batch (EntryPoint v0.6’s innerHandleOp absorbs a failed subcall as “opReverted”), leaving the validation-phase approval intact since the fake signer check returned 0 (not 1) and never triggered an AA24 revert. This was repeated across many Sodium accounts (attacker EOA 0xCe1a3BB0b98D0D90C7Dd0620Ab86C9A771888d88; malicious paymaster/signer/session-key/sweeper contract 0x56362412AE17cac443AAFBAb4289946Ad958E8a1), then a separate sweeper contract batch-called transferFrom against the newly-approved accounts, swapped LUA, LUAUSD, USDT0 and other stablecoins to ETH via Uniswap V3, and moved proceeds to the attacker EOA. DeFiLlama classifies this as a “Silent Auto-Approval Hack” under “Protocol Logic.” Blockaid flagged the exploit in progress on July 13 (~$270K drained so far, per its real-time alert), SlowMist published a threat-intel alert the same day, and Lumi Finance’s core developers paused the protocol’s main vault (per CryptoTimes). Affected users were advised to use Revoke.cash to strip the malicious approvals. As of August 4, 2026, no official post-mortem, compensation plan, or negotiated fund recovery has been published; a LinkedIn-cited company statement says protocol assets cover liabilities and overall solvency was not threatened, but individual users whose smart-account approvals were drained lost those specific funds.

How It Could Have Been Avoided: The defining flaw was that Sodium’s validateUserOp() produced a durable state change (an ERC-20 approval) as a side effect of validation rather than execution — this should be enforced as a hard invariant (“signature/UserOp validation must be side-effect-free with respect to token allowances”) and checked via formal verification or symbolic execution of the validation path before deployment, exactly the gap Olympix’s own post-mortem highlights. The ERC-1271 fallback must fail closed: if ECDSA.tryRecover() cannot recover a valid owner signature, the account should revert immediately rather than querying isValidSignature() on an arbitrary, attacker-suppliable contract address — any ERC-1271 signer contract that can gate fund movement should be pre-registered/allowlisted by the owner in a separate, timelocked transaction, not accepted inline from UserOp calldata. The isSafe session-key default should fail closed (require an explicit owner-signed session-key registration) instead of defaulting to true when no session is configured, closing the path that let signer == sessionKey == attacker contract. Paymaster trust needs the same allowlisting treatment: validateUserOp should never let paymasterAndData dictate an arbitrary spender and allowance value that gets auto-approved by the wallet; only pre-vetted, protocol-governance-registered paymaster contracts should be callable, and any token approval should require multi-party/execution-phase confirmation rather than being derivable from validation-phase paymaster data. Approvals themselves should never be type(uint256).max by default — bound them to exact transaction amounts or short-lived, revocable allowances, which would have capped the blast radius even if the signature bypass succeeded. Finally, EntryPoint-level circuit breakers tuned to this exact pattern (a batch of UserOps with callGasLimit = 0 whose validation step alone mutates ERC-20 allowance state across many distinct smart accounts) would have caught the sweep in progress algorithmically rather than relying on Blockaid’s manual real-time detection and a reactive vault pause after the fact.

8. Drips Network — $24.9K Drained via Unsafe uint128→int128 Cast in Legacy give()

Date: 2026-07-14  |  Chain: Ethereum  |  Estimated Loss: $24.9K

On July 14, 2026, an attacker drained 24,882.995421947667857715 DAI (~$24,878.96 at time of tx, ~$24.9K) from Drips Network’s legacy DaiDripsHub deployment on Ethereum mainnet in a single transaction (0xc38a6e2259a85ced94238a0b0a49697992f2a6b8140c28f3fd2343d3d8434130). Funds moved from the DaiReserve (0xf9bbb2df44cfe46e501cf91c99b2f8fef9d9d44a) through the Hub proxy (0x73043143e0a6418cc45d82d4505b096b802fd365) into an attack contract (0x00c64B5a926ba1fceC30EfaD88C344c619F54F12) and out to the attacker’s EOA (0x84dA7a5e2315Eb798f04B75554AeB15047269CCE). A near-identical copycat drained ~108 DAI from the Polygon deployment roughly 27 minutes later. Root cause: DaiDripsHub.give(address receiver, uint128 amt) → _give() calls _transfer(-int128(amt)) without first checking amt <= type(int128).max. The attacker computed A = 2^128 − B, where B is the reserve’s exact balance (24,882,995,421,947,667,857,715 wei-DAI), and passed A as amt. Casting that valid-but-oversized uint128 to int128 reinterprets its bit pattern as −B; the contract’s own negation then flips it to +B, so _transfer() executes a full-balance withdrawal instead of a deposit — a sign-boundary crossing that silently reverses transfer direction. No access control was bypassed and no oracle was touched; Solidity 0.8.x’s checked arithmetic does not cover explicit narrowing casts, so this class of bug passes compilation cleanly. No official Drips team post-mortem, advisory, or reimbursement was found on their blog, X account, or GitHub — the incident is documented entirely by third-party researchers (SlowMist, Olympix, Verichains/TK) and on-chain data, consistent with the affected Hub being a deprecated legacy component left unmonitored.

How It Could Have Been Avoided: The fix is a bounds check on exactly one line: replace the raw -int128(amt) cast in _give()/_transfer() with OpenZeppelin’s SafeCast.toInt128(uint256(amt)) (or an explicit require(amt <= uint128(type(int128).max)) guard) so any uint128 above the signed boundary reverts instead of silently flipping sign — Solidity 0.8’s checked-arithmetic guarantees never cover explicit type conversions, so this cannot be caught by compiler defaults alone. That specific invariant — “_transfer()’s effective sign must match the caller’s deposit intent for every uint128 input, including values > 2^127−1” — is narrow enough to formally verify (Certora/Halmos) or cover with a Foundry invariant/fuzz test that sweeps amt across the full uint128 range and asserts reserve balance never decreases on a call to give(). Static analysis (Slither/Semgrep) should flag unchecked signed/unsigned narrowing casts feeding into any balance-moving call as a standing CI rule, not a one-time audit finding. As defense in depth, a per-transaction or per-block cap on DaiReserve outflows (a circuit breaker sized to typical streaming/tipping volume) would have limited a single-tx full drain even had the sign flip gone undetected, and an on-chain monitor alerting on give() calls with amt exceeding int128 max — or on reserve-balance drops disproportionate to normal activity — would have enabled a pause within the block. Finally, since this was a “legacy” Hub superseded by newer infrastructure, it should have been formally deprecated and paused (or had withdrawals timelocked/multisig-gated) rather than left live and unmonitored indefinitely.

9. Ostium — $23.75M OLP Vault Drain via Off-Chain Price-Signer Compromise

Date: 2026-07-15  |  Chain: Arbitrum  |  Estimated Loss: $23.75M

On July 15, 2026, 14:18:23–14:23:52 UTC, an attacker drained 23,752,746 USDC (~$23.75M) from Ostium’s public OLP liquidity vault on Arbitrum in 8 transactions over roughly 5.5 minutes. Ostium’s pull-oracle Verifier contract checks only that a submitted price report’s signature recovers to an allow-listed signer address — it does not validate price plausibility or freshness. The attacker compromised Ostium’s off-chain signing infrastructure, used a beneficiary wallet (0x321Df194…) to call setDelegate on OstiumTrading, then had an operator EOA (0xD1794196…) call executeBatch on a registered forwarder (0xfE12F636…) that alternated calls between OstiumTrading (open/close) and OstiumPrivatePriceUpKeep (price delivery). Each atomic batch opened a leveraged BTC/USD long at a fabricated ~$5,000 and closed it moments later near the real ~$60,000 price, both legs carrying validly-signed-but-false reports. A test trade (~898 USDC) preceded the main batch (five cycles, $11.86M) and six further standalone cycles, before the vault’s circuit breaker halted withdrawals. Trader collateral, held in isolated contracts, was unaffected. Live estimates ranged from Blockaid’s $18M to CertiK’s $22M to PeckShield’s ~$24M before Ostium’s post-mortem (July 29) reconciled the figure at $23,752,746 and explicitly ruled out a smart-contract logic bug or multisig compromise. Ostium’s own Immunefi scope had excluded “compromised keeper” scenarios from bounty coverage. Stolen funds were swapped via KyberSwap into ~12,084 ETH (~$1,966 avg.) and dispersed across ~30 wallets, largely into Tornado Cash. Ostium paused all trading contracts within 60 minutes, engaged Mandiant, zeroShadow, Collisionless, and SEAL 911, migrated to a new price-signing environment, and resumed phased trading July 23; as of August 2, no LP reimbursement plan had been executed.

How It Could Have Been Avoided: The single point of failure was that on-chain trust terminated at “does this signature recover to an allow-listed key,” with no independent sanity check on the price content itself — this is fixable without abandoning the pull-oracle model. First, the Verifier should enforce a bounded-deviation check against a fallback reference (e.g., Chainlink/Pyth spot or a short on-chain TWAP) at settlement time, rejecting any report that moves price by more than a fixed percentage from the last accepted value in the same block/epoch — this alone would have blocked the ~92% implied BTC move used to open the fake long. Second, price-report signing should require M-of-N threshold signatures from geographically/infrastructurally separated signers rather than a single off-chain signer whose compromise yields an immediately valid report; HSM-backed, short-lived keys with least-privilege access reduce the blast radius of a credential compromise like this one. Third, forwarder registration and setDelegate-style account delegation are exactly the kind of privileged, rarely-used pathway that should sit behind a timelock or require a second-signer confirmation before becoming callable, so an attacker can’t self-register delegation and execute a drain in the same session. Fourth, a per-transaction/per-block outflow cap on the OLP vault (e.g., max X% of TVL withdrawable per block) would have capped the $11.86M single-batch leg regardless of whether the price check passed, buying time for the circuit breaker that only tripped after $23.75M was already gone. Fifth, real-time automated monitoring that diffs each incoming signed price report against an independent reference feed — alerting or auto-pausing at the >1% deviation threshold — would have caught this before Blockaid’s external alert, since a $5,000 BTC print vs. ~$60,000 market is trivially detectable pre-settlement, not just post-hoc. Finally, the explicit Immunefi exclusion of “compromised or malicious keeper” scenarios removed exactly this failure mode from external red-teaming; bounty and audit scope should treat off-chain signer/forwarder compromise as an in-scope, first-class threat model, not a carve-out.

10. TeleSwap — $735,000+ Bitcoin Hot Wallet Drain, Five Days of Silence

Date: 2026-07-15  |  Chain: Bitcoin  |  Estimated Loss: $735,000

On July 15, 2026, TeleSwap’s Bitcoin hot wallet (bc1q5wnpn4k99wc587maaaa6eqnx27g4r6mduxg2s5) leaked over $735,000 in BTC-denominated value. TeleSwap is a self-described “Bitcoin DeFi hub”/cross-chain bridge that uses SPV light-client verification to mint wrapped BTC. On-chain investigator ZachXBT flagged the outflows and, shortly after, the hot wallet stopped processing transactions entirely — behavior consistent with either a private-key compromise or an emergency halt, but neither has been confirmed. No public statement, technical explanation, or post-mortem followed; TeleSwap’s docs site (teleswap.xyz/docs) still carried only generic security-model content and its official X account (@Tele_Swap) stayed silent through late July checks. SlowMist’s tracker lists the attack method simply as “Unknown.” ZachXBT’s finding, posted via Telegram (t.me/investigations/356), was picked up by BlockBeats/Odaily on July 20 and spread across Protos, KuCoin, BingX, Binance Square, Phemex, CoinEx, RootData, and BeInCrypto, most outlets explicitly calling out the five days of protocol silence. A Chinese-language BlockBeats/Odaily report syndicated via CoinEx’s feed (July 20) named specific addresses tied to the theft — BTC bc1pz95zv3qhpmt52yezs84a5zrddrk5jsxm8a60rln5kzlk06e87a3q8pf79l and ETH addresses 0x2448cbaee50a67030692b7519a954e5550dc2718, 0xfc5048fbba2f74ed482ffcd7663601f818c5bb47, and 0xf8706a51f8df01a71f408e50c901dd14916a12c7. IndagoLabs’ independent technical trace (July 23) corroborated one of these: it identified 0xF8706a51F8dF01a71f408E50c901dd14916a12c7 as the attacker’s ETH consolidation wallet, reached by swapping the stolen BTC to ETH through the non-custodial, no-KYC Chainflip protocol roughly five days after the theft, before the funds were deposited into Tornado Cash to break the trail. The hit landed inside a cluster week for bridges: Protos reported Across Protocol ($3.35M) and Allbridge ($1.65M) exploited within days of TeleSwap, for ~$5.7M in combined weekly bridge losses, against a running 2026 tally of over $355M across 20 bridge hacks.

How It Could Have Been Avoided: The pattern here — a single Bitcoin hot wallet able to move $735,000+ before anything stopped it, and only stopping after the fact — is a custody-concentration and detection-latency failure, not (as far as disclosed) a smart-contract logic bug. The direct mitigation is threshold-signature/MPC custody for the BTC hot wallet in place of a single signing key, so no one compromised key or device can authorize an outbound transfer; pair this with a tiered hot/warm/cold structure that caps hot-wallet balance at a small operational float and auto-sweeps anything above threshold to cold, geographically-separated, HSM- or air-gapped-signed storage, bounding the maximum loss any single compromise can produce. Because the wallet kept transacting for an unknown period after the anomalous outflows began, an automated circuit breaker tied to outflow-velocity and destination-anomaly monitoring (e.g., halting minting/withdrawal the moment cumulative outflow in a rolling window exceeds a historical baseline or a fixed absolute/percentage-of-reserves threshold) would have capped exposure far below $735,000 instead of relying on the operator or an external researcher to notice. Given TeleSwap’s SPV light-client design mints wrapped BTC against this same hot wallet’s reserves, a public, real-time proof-of-reserves/proof-of-liabilities feed would let outside parties — not just ZachXBT after the fact — detect a reserve/liability mismatch within minutes rather than days. Finally, since the laundering leg specifically exploited Chainflip’s no-KYC, no-account-record design to break the BTC→ETH trail before Tornado Cash, exchanges and bridge-adjacent liquidity venues that can screen for TeleSwap’s disclosed wallet cluster (bc1q5wnpn…, bc1pz95zv3q…, 0x2448cbae…, 0xfc5048fb…, 0xf8706a51…) via address-screening/allowlisting at withdrawal would narrow the laundering window that let five days pass before consolidation. None of this substitutes for TeleSwap actually publishing a post-mortem — its multi-week silence, independently confirmed by direct checks of its docs and X account, is itself a governance failure a pre-committed incident-disclosure SLA would address.

11. BarnBridge Governance Takeover — $776K Drained From a Dormant DAO

Date: 2026-07-15  |  Chain: Ethereum  |  Estimated Loss: $776K

On July 15, 2026 at 02:39:47 UTC, an attacker drained 776,600 USDC (~$776K) from BarnBridge’s SmartYield CompoundProvider contract on Ethereum — a governance takeover, not a smart-contract bug. BarnBridge’s DAO had sat dormant since a 2023 SEC settlement wound down its pools, leaving BOND voting power thin. The attacker spent ~0.335 ETH to buy ~32,795 BOND, locked 32,000 BOND to reach ~43% of active voting power, and submitted a proposal disguised as a routine proxy upgrade. After the DAO’s standard 2-day warm-up plus 2-day timelock queue elapsed unopposed, the attacker executed it, reassigning the CompoundProvider’s Controller role to an attacker-owned proxy. With that privilege, the attacker called the now-authorized _takeUnderlying() to pull USDC directly from ~50 wallets still holding outstanding, unrevoked approvals to BarnBridge contracts granted years earlier, then called transferFees() to route the funds to the attacker’s address. The USDC was swapped for ~415 ETH via Uniswap at 02:52:35 UTC and moved to a separate holding address at 06:45:47 UTC — the whole operation completing within about four hours of the exploit transaction. BlockSec’s Phalcon monitoring detected and reconstructed the attack sequence; Blockaid separately flagged two legacy governance proposals (#14/#15) as risky the same day. With no active protocol team since 2023, there was no official incident response: Blockaid and Revoke.cash publicized the risk and shipped an exploit-checker tool urging affected wallets to revoke old approvals, while other BOND holders launched a contested “counter-governance” campaign over the following 24–48 hours attempting to lock the attacker out. No confirmed user reimbursement has been reported.

How It Could Have Been Avoided: The failure was structural, not cryptographic, so the fixes are process and architecture controls rather than code patches. First, sunset discipline: a protocol that stops operating must strip or renounce privileged setters (here, the Controller-assignment path on CompoundProvider) rather than leaving them live and reachable by whatever governance quorum remains — either burn the upgrade/controller-setting authority or migrate it to a hardware-multisig timelock with no path back to token-vote control. Second, the stale-approval vector needs a structural fix, not user vigilance: adopt expiring, capped approvals (Permit2-style time-boxed allowances) instead of infinite ERC20 approve(), and for a protocol that has announced shutdown, proactively batch-revoke or sunset outstanding allowances rather than leaving ~50 wallets with years-old unlimited approvals as a standing attack surface. Third, governance-security controls that would have blocked this specific path: an absolute-quorum floor (minimum BOND supply participating, not just percentage of active voters) so a ~43%-of-thin-turnout capture becomes economically infeasible; a guardian/veto multisig empowered to cancel proposals during the 2-day warm-up + 2-day timelock window, paired with automated calldata simulation (Blockaid/Forta-style pre-execution proposal scanning) that flags any proposal touching setController, proxy implementation slots, or other privileged setters for mandatory human review before the timelock even starts; and an on-chain allowlist enforced inside setController() itself — restricting valid Controller addresses to a pre-vetted set — so that even a passed malicious proposal cannot redirect the role to an arbitrary attacker-deployed proxy. Timelock delay alone is not a control if nobody is watching the queue; it only works paired with an active monitor-and-cancel capability.

12. DefiTuna — $569,601 Drained via a Zero-Value Health-Check Bypass on Solana

Date: 2026-07-16  |  Chain: Solana  |  Estimated Loss: $569,601

On July 16, 2026 at 05:48:12 UTC, attackers drained $569,601 USDC (~$570K) from DefiTuna, a Solana lending/leverage protocol, in a single on-chain transaction (124ibr7NU7AtJdeZ1WJjJy5YathNiBtCnV554uwJtkc7qEXeF64dmCziv4QoiEEMRG6EmCRx8ec2LkARpWH3kvEG). The attackers first created a near-empty TUNA/USDC Fusion pool and seeded it with two limit-order positions at tick 208,640 holding a combined 0.001052 TUNA. They then called open_and_increase_tuna_spot_position_jupiter to open a leveraged spot position with zero real collateral, borrowing 569,601 USDC from the lending vault. A 47-byte embedded-Jupiter-router instruction routed that entire borrowed sum through the attacker’s own illiquid pool rather than a real venue, returning only ~0.000494 TUNA. DefiTuna’s solvency check, TunaPosition.is_healthy() via compute_total_and_debt(), used Rust fixed-point to_num() truncation on this negligible return, rounding total position value to exactly zero — and a flawed branch that implicitly assumed “the leverage of an empty position is always 1.0x” classified the zero-asset, $570K-debt position as healthy. The attackers then decreased the two limit-order positions, each withdrawing 284,280.483231 USDC. Proceeds were bridged Solana-to-Ethereum via Mayan; by July 20, 140 ETH had been deposited into the Railgun privacy protocol, with 291,696 DAI and 5 ETH still sitting in a traced wallet (0x509B9D094A6C26D716aaC131E8aDee5B16B86d3e). DefiTuna disclosed via X roughly 7 hours after the attack (initial estimate: $580,000), patched the flaw, paused borrowing as a precaution, and confirmed its AMM and spot-trading functions were unaffected — only the USDC lending pool carries the deficit. A day-later follow-up revised the loss to a “$570,000 deficit” and endorsed CertiK’s incident analysis — the source of the attacker addresses and fund-flow trace above — as accurate; CertiK’s account is contradicted on one point by BlockSec Weekly, which disputes that the fake pool passed the price-deviation check by being “close to oracle price,” instead attributing the pass to the check validating a separate, legitimate pool. As of late July 2026, no reimbursement plan for lending-pool depositors had been confirmed, and DefiLlama data showed the lending market still operating at reduced scale (~$557,911 active loans, TVL down 29-33.5% over 30 days).

How It Could Have Been Avoided: This exploit reduces to one broken invariant — a debt-laden position with truncated-to-zero collateral value being classified healthy — compounded by trusting caller-controlled swap routing. Fixing the invariant directly means rejecting the implicit “empty position = 1.0x leverage” branch in compute_total_and_debt()/is_healthy() and instead hard-failing any position where computed asset value is zero (or below a dust floor) while outstanding debt is nonzero, with property-based/fuzz testing specifically targeting fixed-point rounding-to-zero edge cases before deploy. Second, the protocol must stop accepting caller-supplied Jupiter RouteV2 output data at face value: minimum acceptable swap output should be derived on-chain from the oracle price and borrowed amount (with a TWAP-based deviation bound), not trusted from routing calldata the attacker controls. Third, swap-routable pools used inside leveraged-borrow instructions need admission criteria — a minimum liquidity depth and/or minimum pool age (e.g., rejecting any pool created in the same transaction or block as the swap that consumes it) — so a freshly minted, attacker-seeded Fusion pool can never qualify as a routing venue for borrowed funds. Fourth, a per-transaction or per-block borrow cap on the lending vault acts as a circuit breaker, capping the blast radius of any single exploit transaction well below $570K even if the health check is later found to have another edge case. These four controls map directly to the CertiK-confirmed mechanism — the truncation bug, the untrusted routing data, the illiquid pool’s eligibility as a swap venue, and the absence of any transaction-level loss ceiling — rather than generic “get audited” advice.

13. Across Protocol — $4.5M Forged-Deposit Exploit on Solana Relayer (Fully Recovered, Net Loss ~10% Bounty)

Date: 2026-07-17  |  Chain: Solana  |  Estimated Loss: $4.5M

On July 17, 2026, between 05:07 and 06:14 UTC, an attacker forged 1,627 fake Solana FundsDeposited events from 1,627 single-use wallets, requesting payouts worth $41.7M face value across 18 destination chains on Across Protocol. The root cause was an off-chain bug, not a contract compromise: Risk Labs’ Solana relayer software, which reads deposit events off-chain and fronts its own capital before optimistic settlement, never verified the 8-byte Anchor event discriminator on incoming events. The attacker deployed a wrapper program that performed a CPI into a benign, read-only SpokePool helper (get_unsafe_deposit_id) and appended forged FundsDeposited payloads to that call; because the discriminator went unchecked, the relayer treated these as genuine deposits even though no real Solana state ever changed. Risk Labs’ relayer filled 581 of the 1,627 forged requests before catching it, paying out ~$4.5M of real capital against fabricated deposits — Across’s on-chain SpokePool and EVM contracts behaved correctly throughout. Response was fast: attacker addresses blacklisted by 06:16 UTC, Solana disabled as origin/destination by 08:23, SpokePool paused on-chain by 08:35, root-cause fix merged by 09:37 and deployed by 10:26, and Solana routed back through Circle’s CCTP fallback by 17:05 the same day. Zero user funds were lost. After ~$500K of attacker funds were trapped/clawed back, Across’s July 24 post-mortem stated net loss “under $4 million.” On July 27 the attacker proactively contacted Across to negotiate a return; Across agreed to a 10% bounty, and the attacker returned 331.8 ETH (~$624K) on July 28 and the remaining ~$3.7M by July 30, leaving Risk Labs’ real final loss at roughly the bounty amount alone (order of ~$400K, inferred from the 10% rate — not an Across-published figure).

How It Could Have Been Avoided: The single missing control was discriminator validation: every off-chain Anchor event parser handling Solana relayer decisions must reject any log/CPI payload whose 8-byte discriminator doesn’t match the exact expected event type before trusting it as a genuine FundsDeposited record — this one check would have blocked the entire attack. Beyond that point-fix, the design should stop trusting emitted event bytes at all as the source of truth for releasing capital: relayers should re-derive deposit legitimacy from actual committed on-chain state (the SpokePool’s deposit PDA/account data or real token balance deltas) rather than scraping logs/CPI output that any caller can forge. Read-only helper functions like get_unsafe_deposit_id should not be CPI-reachable in a way that lets their invocation be conflated with authoritative state-changing events — segregate log namespaces or restrict CPI callers to an allowlist of trusted programs. A velocity-based circuit breaker on relayer payouts (e.g., auto-pause after N fills or $X cumulative outflow within a rolling window) would have caught 581 fills in roughly 67 minutes well before $4.5M left the relayer, and a second independent validation path (cross-checking deposit events against an independent Solana indexer or full-node read, separate from the code path that was exploited) would have caught the forged/no-state-change discrepancy. Large single-block payouts above a threshold should require staged/multi-party confirmation rather than fully automated single-relayer release. Finally, since this bug sits in the same problem class as an earlier (April 2026) Solana event-handling issue reportedly flagged by Asymmetric Research, discriminator validation should become a standing regression/property test — formally specifying and continuously fuzzing the invariant “a filled deposit implies a discriminator-valid, on-chain-state-confirmed FundsDeposited event” — rather than a one-off patch to the single instance that was found.

14. Zilliqa — ~$1.7M-$1.8M Stolen via Biased-Nonce Bug in Ledger’s Native Signing App

Date: 2026-07-19  |  Chain: Zilliqa  |  Estimated Loss: ~$1.7M-$1.8M

On 19 July 2026, on-chain activity consistent with active exploitation began draining a cold wallet belonging to a Zilliqa exchange partner; Zilliqa issued a brief public acknowledgment on 20 July, isolated and reproduced the root cause on 21 July, and published a full technical disclosure on 22 July at 8:33 AM. The bug lived in the Zilliqa Ledger app’s EC-Schnorr signing routine for native (non-EVM) transactions, present in every shipped version since 2019. The signer generated 40 bytes of RNG output, reduced it mod the curve order via cx_math_modm, but then copied the wrong 32-byte range into the final nonce buffer (os_memcpy(T->K, nonce, size)), retaining 8 zero-padding bytes and discarding 8 bytes of real entropy — fixing the top 64 bits of every nonce k to zero (k < 2^192). A biased nonce leaks structured key information per signature; with roughly 5+ native signatures from the same account, an attacker can solve the resulting Hidden Number Problem via lattice reduction and recover the private key in seconds on commodity hardware. Exploitation was purely off-chain: historical, publicly visible on-chain Schnorr signatures were harvested, private keys derived, and funds moved via ordinary transfers — no smart-contract exploit, no multi-step on-chain sequence. EVM-based Zilliqa transactions and the official SDKs (zilliqa-js, gozilliqa-sdk, pyzil) were unaffected. Zilliqa’s official incident page (last updated 31 July 2026) is the first source to quantify losses, stating “the total amount stolen is estimated at ZIL 683,130,969.66,” which converts to roughly $1.7M-$1.8M at prevailing ZIL/USD prices — superseding BlockSec’s earlier independent estimate of ~$400K “known losses” published a day prior (30 July), which reflected only losses traceable at that snapshot. Zilliqa halted all legacy native transactions immediately on root-cause confirmation, prepared a corrected Ledger app build with Ledger, credited KuCoin with discovering and confirming the flaw by reproducing key recovery from public signatures, and on 31 July published a nine-point plan centered on permanently retiring the legacy native chain in favor of Zilliqa EVM, opening migration to all legacy wallet holders (affected or not), and restoring balances via a tokenomics-based recovery mechanism rather than a negotiated fund return, since no attacker address was ever identified.

How It Could Have Been Avoided: The proximate bug — an off-by-range os_memcpy that copied the zero-padded high bytes of a post-reduction buffer instead of the true low-order 32 bytes — should have been caught by a property-based test asserting nonce uniformity across the full 2^256 range (e.g., statistical bit-distribution tests over thousands of generated nonces, specifically checking that the top byte is not degenerate) run in CI against the actual firmware binary, not just reviewed by eye. More structurally, raw RNG-then-reduce nonce generation is a known footgun; switching to deterministic nonce derivation (RFC 6979-style, or a synthetic nonce = hash(privkey, message, fresh randomness)) removes the entire class of “leftover buffer bytes” bugs since the nonce is computed as a single fixed-width output with no oversized intermediate buffer for a copy-offset error to exploit. Given the specific failure mode — a small number of biased signatures leaking the key via lattice attacks — hardware-wallet vendors should run their own HNP/lattice-reduction attack as a pre-release canary against sample signature sets from every firmware build, treating “can we recover the key from N of our own signatures” as a release gate, not just post-hoc incident response. An independent third-party cryptographic implementation review focused specifically on nonce-generation code paths (a narrow, high-leverage audit scope distinct from general app review) would likely have flagged the cx_rng/cx_math_modm/os_memcpy copy pattern, especially since the bug survived seven years and multiple app releases unnoticed. Finally, because historical public signatures permanently encode the bias once discovered, incident response for this class of bug requires proactive key rotation/migration architecture (retiring exposed accounts, not just patching the signer) and, for wallet providers/exchanges, anomaly detection that flags accounts approaching the ~5-signature exposure threshold on legacy signing paths so extra confirmation friction or forced migration can be triggered before enough signatures accumulate for a lattice attack to succeed.

15. Allbridge Core — $1.66M Drained via Solana Pool-Aliasing Flash Loan Exploit (July 19, 2026)

Date: 2026-07-19  |  Chain: Solana  |  Estimated Loss: $1.66M

On July 19, 2026, an attacker drained Allbridge Core’s Solana USDC/USDT liquidity pool for a final surplus of 1,118,239 USDC + 538,692 USDT (~$1.66M per Allbridge’s own post-mortem; ~$1.65M as rounded by PeckShield, CertiK, and most secondary press) in a single atomic transaction executed at 17:51 UTC. Allbridge posted a public pause notice at approximately 19:58 UTC the same day. Per BlockSec’s byte-level reconstruction of the deployed program (source was unavailable; the reconstruction was done from a 1,770,736-byte ELF binary, SHA-256 40f776…346bb6), the attacker flash-borrowed ~1.12M USDC from Kamino Finance, swapped it through Allbridge into ~949K USDT, then issued five back-to-back ~100K-USDT “self-swaps” passing identical mint, Pool, vault, and user-token accounts as both send_pool and receive_pool. The program deserialized the same mutable Pool account into two separate 176-byte local objects — one per role — and serialized the receive-side object last, silently discarding the send-side accounting update at the same byte offset (function_8300 called on send_pool, then again on receive_pool, second write wins) even though the underlying SPL Token vault transfers for both legs had already settled via separate CPIs. Across the five self-swaps the implied vUSD/USDT price rose from ~5.24 to ~16.6, ~57.2, ~190, and finally ~563, with ~500K USDT flowing into the vault against only ~93.8K USDT returned in pool accounting. With the pool badly mispriced, the attacker supplied just ~3.99K USDT for ~2.24M vUSD, converted that to ~2.24M USDC via the paired pool, repaid the ~1.12M USDC Kamino loan plus an ~11.2 USDC fee, and walked away risk-free within the same transaction. The root cause was a single missing check — require_keys_neq!(send_pool.key(), receive_pool.key()) — absent despite 16 other 32-byte account comparisons (mint, vault, owner, PDA, authority, Token-program bindings) being present and passing; Allbridge’s own post-mortem states the swap logic simply “treated a same-token input/output pair like any other swap pair,” with the pool’s imbalance safeguard “configured permissively.” Architecturally this is identical to a classic ERC-20 self-transfer bug (transferFrom where from == to), and it directly reintroduces the exact precondition — USDC and USDT sharing one pool — that Allbridge’s own 2023 post-mortem (following a ~$570K-650K BNB Chain flash-loan exploit) had committed to eliminate under a “one asset per chain” single-pool architecture, a fix that never reached the Solana deployment. Proceeds were bridged to a single Ethereum consolidation address, dispersed across multiple wallets, and reportedly routed toward privacy-pool infrastructure. Allbridge paused Core protocol-wide within hours, urged LPs to withdraw immediately, asked opportunistic arbitrageurs (distinct from the attacker) to voluntarily return dislocation profits to a designated address, published a technical post-mortem, stood up a compensation program, and announced it will discontinue pool-based swaps entirely in favor of routes that don’t depend on shared liquidity pools. No recovery of the stolen funds had been reported as of the latest sources reviewed.

How It Could Have Been Avoided: The fix is a single missing invariant check, and the mitigations map directly to it. First, enforce require_keys_neq!(send_pool.key(), receive_pool.key()) (or equivalent) as a mandatory guard on every instruction that accepts two account references meant to be distinct — not just validating each account individually against its expected mint/vault/owner/PDA/Token-program bindings, which Allbridge already did for 16 other fields and which produced false confidence. Second, eliminate the deserialize-twice/serialize-twice pattern that caused the aliasing: when an instruction can legally receive the same underlying account in two roles, load it once into a single mutable reference (Anchor’s shared-mutable-borrow discipline, or an explicit same-account branch that nets both legs’ deltas before one serialize) rather than creating two independent in-memory copies where a last-write-wins serialize silently discards one side’s state update. Third, treat “one pool per asset” as a deployment-time invariant enforced by CI/on-chain config validation across every chain deployment, not a design principle documented once in a 2023 post-mortem and left to per-chain implementation discretion — a combined USDC/USDT pool is the structural precondition that makes same-transaction flash-loan repricing possible at all. Fourth, tighten the pool-imbalance safeguard from “permissive” to a hard per-instruction and per-transaction price-deviation circuit breaker (a TWAP-style reference price plus a bounded max-deviation-per-swap check) that would have halted the attack after the first or second self-swap, well before the implied price reached ~563x. Fifth, add a same-pool operation cap or intermediate-state re-validation between chained swap instructions within one atomic transaction, since the exploit depended on stacking five consecutive self-swaps against the same pool inside a single Kamino-flash-loan-wrapped transaction. Finally, because BlockSec had to reverse-engineer this bug from a 1.77MB deployed ELF binary since source was unavailable, the program should have carried an audit (and post-deployment fuzz/property-based test suite) that formally specifies send_pool != receive_pool as a protocol invariant and includes send_pool == receive_pool as a required negative test case for every swap instruction — rather than relying on a checklist of individual field-level key comparisons to implicitly, and in this case incompletely, guarantee it.

16. Wanchain Cardano↔BNB Chain Bridge — 515M NIGHT ($9M–$13M) Drained via Signature-Reuse Bug

Date: 2026-07-20  |  Chain: Cardano  |  Estimated Loss: $9M–$13M

On July 20, 2026 (14:46–14:55 UTC), an attacker drained 515.2M NIGHT — ~97% of the ~527M-token Cardano-side treasury of Wanchain’s Cardano↔BNB Chain bridge — across 4 transactions in roughly 8 minutes, confirmed by Wanchain’s own July 30 X statement and BlockSec Phalcon’s incident date (2026/07/20); public disclosure followed July 21 via BlockSec’s alert and Wanchain’s security notice. Loss estimates cluster at $9M–$13M (centered ~$9–10M at attack-time NIGHT price of ~$0.0175–$0.0195; SlowMist logs a flat $10M, DeFiLlama an outlier $6.5M, BlockSec’s blog a further outlier ~$500K — both outliers attributable to later, lower spot-price snapshots rather than attack-time pricing). Root cause: Wanchain’s Cardano-side TreasuryCheck Plutus validator hashed 14 variable-length redeemer fields by raw concatenation with no delimiters or length prefixes — no CBOR/SerialiseData — making the encoding non-injective. A validly-signed authorization for a legitimate ~3,110 NIGHT BSC burn packed to byte string b8a103c0126a10; the attacker crafted a distinct redeemer (amount=203,001,692,164,714, adaAmount=16) that packed to the identical byte string by shifting the field boundary, producing a signature that verified correctly but authorized a withdrawal ~65,000x larger than what was actually signed. No cryptographic primitive was broken — the flaw was purely in message construction/serialization. The attacker laundered stolen NIGHT through freshly created Cardano wallets and dumped ~290M tokens on Cardano DEXs, crashing NIGHT 27–43% to an ATL near $0.015–$0.016. Midnight’s own L1, consensus, and validator set were unaffected — the bug lived entirely in Wanchain’s third-party bridge logic — and total NIGHT supply (~24B) was unchanged; only bridge-held NIGHT was drained, leaving wrapped NIGHT on BNB Chain largely unbacked. Response: Wanchain took the bridge offline within hours and posted a security notice (~5:51 AM UTC, July 21); Midnight Foundation publicly separated its core protocol from the incident; KuCoin, Kraken, Binance, Bybit, OKX, MEXC, and Gate froze/monitored NIGHT flows and blacklisted flagged addresses; BlockSec published forensic root-cause analysis and Wanchain published its own postmortem. On July 30, Wanchain offered the attacker a white-hat deal — return 90% of stolen NIGHT to designated Cardano/Ethereum addresses by August 6, 2026, 12:00 UTC, keep the remaining ~10% (well over $1M) as bounty, no civil pursuit if honored. As of the latest reporting (Aug 3–4, 2026), this remains an open, unresolved negotiation with no confirmed fund return.

How It Could Have Been Avoided: The proximate, fixable defect is a non-injective message encoding, and the mitigations map directly to it. First, replace raw field concatenation in TreasuryCheck with Plutus-native SerialiseData (CBOR) or another length-prefixed/delimited, unambiguous encoding — this alone eliminates the field-boundary-shift collision class entirely, since two distinct field tuples can no longer serialize to the same byte string. Second, adopt domain-separated, type-tagged message construction (an EIP-712-style structured hash, or a Plutus datum with a fixed schema) so signatures are bound to semantically distinct, non-collidable representations rather than a hashable blob. Third, decouple amount validation from signature validation: have the validator independently re-derive and bounds-check the withdrawal amount and adaAmount against the decoded struct fields — not just accept whatever amount the byte string happens to imply — so a signature passing cryptographic verification is necessary but not sufficient for execution. Fourth, add a treasury-level circuit breaker: a per-transaction cap and a rolling-window (e.g., per-hour) outflow cap as a percentage of treasury reserves would have halted the drain after the first ~65,000x-inflated transaction instead of permitting 4 transactions to empty 97% of reserves in 8 minutes. Fifth, require multi-party/threshold sign-off for any single withdrawal exceeding a modest multiple (e.g., 5–10x) of recent transfer norms, with an automatic pause-and-alert rather than silent execution on outlier amounts. Sixth, this specific invariant — “the redeemer-to-bytestring encoding is injective across all valid field-value combinations” — is exactly the kind of property that property-based fuzzing or formal verification of the validator (generating adversarial field-boundary-shift inputs and asserting no two distinct semantic inputs hash identically) would have caught pre-deployment, and should be a standing test in the bridge’s CI for any change to the redeemer schema. Finally, real-time anomaly monitoring on bridge treasury balance deltas per transaction (alerting/auto-pausing on any single withdrawal an order of magnitude above historical norms) would have provided a last line of defense even if the encoding bug shipped.

17. FlashTrade — $98,000 Drained via a MagicBlock Ephemeral Rollup Undelegation-Validation Flaw

Date: 2026-07-21  |  Chain: Solana  |  Estimated Loss: $98,000

On 2026-07-21 (00:21 SGT July 22 per FlashTrade’s and MagicBlock’s own posts — same instant, UTC vs. SGT framing), an attacker pulled 98,000 USDC ($98,000) out of FlashTrade (Flash.Trade), a Solana perpetuals protocol built on MagicBlock’s Ephemeral Rollup SDK for sub-50ms off-chain trade execution. Root cause, per MagicBlock’s own postmortem: an incomplete validation path in the SDK’s #[ephemeral] Anchor macro, which generates the callback integrators use to process undelegation requests when rollup state settles back to Solana mainnet. The macro checked that the “buffer” account accompanying an undelegation was a signer owned by the delegation program, but never verified that the buffer’s seeds actually derived the expected PDA. The attacker exploited this in a single transaction: deploy a program, delegate a manufactured account representing a fake “user deposit” (satisfying the signer+owner check), then reuse that same account as the buffer for a sibling undelegation instruction — producing an invalid withdrawal receipt the macro accepted as legitimate. Per FlashTrade co-founders (Solana.com “Pirates Parley” podcast), the attacker had done reconnaissance beforehand, watching FlashTrade’s own Monday livestream to learn the exact per-transaction withdrawal cap, then building and deploying the exploit program in roughly five minutes via Triton’s RPC/transaction-sending service. FlashTrade’s newly deployed withdrawal-batching and AI-assisted monitoring flagged the anomalous withdrawal within about a minute; the team paused trading, deposits, and withdrawals immediately, with trading back to normal within six to seven hours and deposits/withdrawals reopened after roughly 24 hours once funds were fully reconciled. Segregated, non-co-mingled collateral token accounts confined the loss to the exploited path — pool TVL was untouched. MagicBlock audited other integrator programs using the same macro, notified affected teams, and shipped patched SDK v0.16.2 enforcing the missing PDA check. FlashTrade and MagicBlock jointly reimbursed 100% of the $98,000, for zero net user impact. The attacker’s funds moved through a Monero swap → ChangeNow → Mayan bridge → Ethereum; no wallet address or identity was ever publicly disclosed, and there is no report of on-chain freezing or clawback — the loss was made whole via reimbursement, not recovery.

How It Could Have Been Avoided: The break was a missing seeds-to-PDA derivation check on the undelegation buffer account — Anchor’s macro validated signer status and program ownership but never called the equivalent of find_program_address/create_program_address against the buffer’s claimed seeds, so any account that merely passed through delegation (including an attacker-manufactured one) could impersonate a legitimate withdrawal buffer. The direct fix is enforcing full PDA-derivation constraints (seeds = […], bump, checked against the account’s actual key) on every account consumed by the undelegation callback, not just signer+owner checks — and, since the flaw lived in SDK-generated macro code rather than integrator application code, it needed an audit scope that explicitly covers macro-expanded/SDK-injected instruction logic, not just the protocol’s own on-chain program, plus property-based fuzzing or formal verification of the specific invariant that broke (“every buffer presented at undelegation must derive from the seeds committed at delegation time”) across the delegate→undelegate lifecycle. Two controls FlashTrade already had in place are worth calling out as the reason this stayed a $98K incident instead of a protocol-draining one: per-transaction withdrawal caps paired with real-time anomaly detection (caught the exploit in ~1 minute) and strict fund isolation via non-co-mingled, per-user collateral token accounts (capped blast radius to the exploited path, leaving pool TVL untouched) — both are directly transferable controls for any protocol integrating third-party SDKs for account delegation. A softer but concrete lesson from the attacker’s own tradecraft: the exact numeric withdrawal cap was learned from a public livestream, so treat precise threshold values for caps/circuit-breakers as operationally sensitive rather than broadcasting them, since publishing exact limits hands an attacker their target budget. Finally, because the vulnerability lived in shared SDK infrastructure rather than one protocol’s code, a bug-bounty program scoped explicitly to the delegation/undelegation macro itself (not just downstream integrator contracts) would have priced in the multiplier risk of a single validation gap propagating to every protocol built on the same Ephemeral Rollup primitives.

18. AFX Trade Bridge Validator Key Compromise — $24.15M Lost to a Forged Quorum

Date: 2026-07-22  |  Chain: Arbitrum  |  Estimated Loss: $24.15M

On July 22, 2026, AFX Trade — an Arbitrum-based perpetuals DEX that routes USDC deposits through a third-party custodial bridge it operates — lost 24,150,000 USDC (~$24.15M) to a validator-key compromise, not a smart-contract bug. The intrusion began July 9 via Telegram social engineering: an attacker posing as a recruiter for a fictitious “Oddium Lab” induced a developer to clone a repo whose.git/config fired a malicious post-checkout hook, planting first-stage malware. On July 16 the attacker escalated by loading a rogue Groovy plugin (“ops_maintenance.groovy”) into AFX’s JFrog artifact repository, gaining code execution that was misdiagnosed as routine infra flakiness — engineers looped in JFrog support and restarted the box, which silently reloaded the malware. By July 22 the intruders had pivoted to validator infrastructure and pushed a payload to targeted nodes. At 21:26:55 UTC, the attacker submitted a withdrawal through the bridge contract (0xCb3B9A3E5668AFE84DC7A864B36b845dCE062e67) carrying five hot-validator co-signatures totaling 7,142 of 10,000 voting-power units (71.42%), exceeding the 6,667-unit (two-thirds) quorum — a cryptographically valid signature set produced by compromised keys, exploiting trust rather than code. The 200–210 second dispute window elapsed unchallenged, and the contract auto-finalized at 21:30:25 UTC. The attacker split the USDC into six CCTP transfers (5,895,000 / 655,000 / 7,500,000 / 5,000,000 / 5,000,000 / 100,000) via the shared “BridgingKit” router to Ethereum, then swapped to 12,467.43703738 ETH across eight UniswapX Dutch-auction fills (solver “Rizzolver”), consolidating into wallet 0x627654B2782BFc57580ecd11d40869B350b6EBaC. Roughly 655 ETH was later laundered through THORChain into ~18.86 BTC, with the remainder fragmented across ~24 addresses. AFX’s own post-mortem ties forensic indicators — C2 traffic, shell execution, in-memory code execution in SELinux logs — to UNC4899/TraderTraitor, a DPRK-linked group tracked by Mandiant, Microsoft Threat Intelligence, the FBI, and CISA. In response, AFX paused the bridge within hours, offered a 70/30 white-hat deal (attacker keeps ~$7.2M), engaged SlowMist and Zellic (the bridge’s original auditor), reported to the Crypto Defense Alliance, rotated credentials, and migrated production to a zero-trust-segmented environment — segmentation that, notably, did not exist at the time of the breach. As of July 31, a “goodwill plan” for affected users was announced for August 3 with no figures disclosed yet.

How It Could Have Been Avoided: The root failure was that a single supply-chain foothold on a developer workstation was allowed to walk, unimpeded, all the way to validator signing authority — every subsequent control should have broken that chain. Git-hook execution should be disabled by default on any machine touching bridge infrastructure (git config –global core.hooksPath pinned to a reviewed, non-executable path, or hooks stripped on clone) and unsolicited external contacts (recruiter DMs, Telegram pitches) should trigger a policy requiring any third-party repo to be cloned and built only inside a disposable, network-isolated sandbox — never on a workstation with any path to build or signing infrastructure. The JFrog artifact repository needed signed-plugin enforcement and a deploy allowlist so an unreviewed Groovy plugin could not load and execute; the repeated OOM crashes it caused were a detection opportunity missed by treating them as ops noise instead of triaging with EDR/behavioral monitoring for anomalous outbound (C2-pattern) traffic. Most critically, validator signing keys should never have been reachable from general corporate/build network segments in the first place: HSM-backed or MPC/threshold signing, air-gapped from CI-CD and artifact infrastructure, with out-of-band (non-network) co-signer approval, would have made a JFrog-host compromise insufficient to co-sign a withdrawal — this is effectively the zero-trust segmentation AFX only adopted after the loss. The bridge design itself offered no defense-in-depth once signatures were valid: a circuit breaker keyed to withdrawal size/velocity anomalies (a single $24.15M request against typical flow) should require a mandatory hold or step-up approval independent of quorum math, and the 200–210 second dispute window is too short for any human or automated reviewer to act on — extending it materially, and wiring real-time detection (Blockaid-class monitoring) directly into an automatic pause authority rather than a passive alert, would have converted a missed alert into a blocked finalization. Finally, distributing the five hot-validator signers across organizationally and geographically independent operators — rather than infrastructure reachable via one compromised build pipeline — would have made a single social-engineering campaign structurally incapable of reaching the 66.7% quorum.

19. BSquared Network (B²) — $3.86M Staking Contract Upgrade-Authority Exploit

Date: 2026-07-22  |  Chain: BNB Chain  |  Estimated Loss: $3.86M

On July 22, 2026 (11:47 PM UTC-adjacent, per BSquared Network’s own X post), an attacker took unauthorized control of the upgrade-authority role on the upgradeable proxy contract governing B² Network’s $B2 token staking service on BNB Chain. BSquared confirmed the root cause directly: “unauthorized access to the staking contract’s upgrade authority” — an access-control/admin-key failure, not a logic bug. The attacker (0xEc443f7D79835B464FBEAC798d3f92B62d6Ff433, BscScan-labeled “B2 Network Exploiter 1”) drained 8.591M $B2 and immediately swapped it for 5,409 WBNB (~$3.11M) plus 156 BNB (~$89.68K), a precise on-chain loss of $3.86M independently corroborated by PeckShieldAlert, Lookonchain, and BscScan’s exploiter-address label. Proceeds were converted to ~1,128 ETH, bridged to Ethereum, and routed toward Zcash via NEAR Intents and HOT Protocol to launder the trail. On-chain analyst Specter noted the compromised account had held upgrade authority since 2025 and was revoked only after the drain — an unconfirmed insider-access theory. This was one of three unrelated hacks in a roughly 6-hour “Hackers Day” window on July 22 (AFX Trade ~$24.15M, Verus Ethereum bridge ~$7.54-7.55M, BSquared ~$3.86M), flagged jointly by Blockaid and PeckShield. BSquared suspended $B2 staking pending review, pledged full compensation via Discord-ticketed verification (1-business-day turnaround), and — per Specter — offered the attacker amnesty from legal action in exchange for returning just 10% (~$386K) within 24 hours. $B2 price fell 15-44% depending on snapshot timing. Through the latest reviewed follow-up (Aug 1, 2026), no funds had been returned and no revised loss figure had been published.

How It Could Have Been Avoided: The single point of failure was a long-lived, apparently unrotated EOA-style upgrade-authority key on a standard upgradeable proxy — held since 2025 with no evidence of periodic review. That directly maps to concrete fixes B² skipped: (1) move proxy admin rights off a single key entirely, onto an OpenZeppelin TransparentUpgradeableProxy/UUPS pattern gated by a TimelockController with a 48-72h delay, so any upgradeTo/upgradeToAndCall call is publicly visible and vetoable before it executes; (2) require the timelock’s proposer/executor roles to be a Gnosis Safe multisig (3-of-5 or similar) rather than a solo address, eliminating single-key compromise as a total-loss event; (3) enforce mandatory key rotation and quarterly access-control audits specifically for privileged proxy-admin roles, since this authority sat unrotated and unreviewed for over a year; (4) wire on-chain monitoring/alerting (e.g., Forta or an equivalent bot) to fire on any transaction touching the proxy’s admin slot or upgrade function, paired with a circuit breaker that auto-pauses staking withdrawals/token transfers on anomalous outflow volume — which would have capped the drain far below 8.591M $B2; and (5) where upgradeability isn’t operationally required, renounce it or migrate to immutable staking logic, removing the upgrade-authority attack surface altogether. None of this is generic “get audited” advice — it targets the exact broken invariant here: an unconstrained, unmonitored, single-key proxy-admin role that should never have been able to redirect the contract’s logic (and by extension its staked funds) unilaterally and undetected.

20. 42DAO / Balance Coin (BLC) — $915K Lost to Oracle Manipulation and Unbacked Minting

Date: 2026-07-22  |  Chain: BNB Chain  |  Estimated Loss: $915K

On July 22, 2026 (per SlowMist’s Hacked Zone database and the bulk of press; 42DAO’s own preliminary statement pins the actual on-chain event at 21:00:01 UTC July 21, 2026), Balance Protocol — a Maker-style CDP stablecoin system on BNB Chain governed by 42DAO, taking BCH/BTCB/USDT collateral to mint BLC — was drained of roughly $912K–$915K (SlowMist and PeckShield alerts diverge on $912K vs $915K; SlowMist’s own database lists $915,000; 42DAO itself has not confirmed a dollar figure). The protocol’s Median Oracle fed BTCB price into a Spotter contract via poke() with no TWAP, no price-deviation/bounds check, no max-drawdown limit, and no minimum price floor. The attacker (0x9d8dd9f2d734675e2bfcc142d1c7a45609ca213c) submitted an abnormally low BTCB price through poke(), writing it straight into the Vat accounting contract; the Dog liquidation module’s bark() then acted on that price instantly — no liquidation delay, no independent validation — liquidating multiple healthy, overcollateralized BTCB vaults at the falsified price in a single transaction, with the attacker acting as liquidator to acquire BTCB cheaply. In a related move, a flaw in the GemJoin contract let the attacker mint ~4.5 million unbacked BLC from a null address, which was routed through PancakeSwap V2 and swapped for Binance-Peg USDT and BTCB (tx 0xe7abe6416e386332b41d63cf5f16903251dc178942cd79bf080fe61058587628 on BscScan). A near-identical second transaction roughly two hours later minted a further ~5,900 BLC and pulled more liquidity, with no circuit breaker or pause triggered between the two hits. The unbacked BLC flood collapsed the peg 99.75–99.97%, from ~$0.9954–$0.997 down to ~$0.001–$0.0025, with market cap falling to roughly $12,000. Security firms (SlowMist, PeckShield, TenArmor) uniformly attribute root cause to the missing oracle safeguards — the analogue of MakerDAO’s Oracle Security Module was absent — a class of bug a prior CertiK audit of the BLC minting contract did not cover, since standard audits treat oracle inputs as trusted (OWASP’s 2026 Smart Contract Top 10 lists oracle manipulation as SC-03). 42DAO went silent for about a day, issuing no pause, compensation plan, or bug bounty; on ~July 23, 2026 it posted a preliminary statement on X confirming the 21:00:01 UTC July 21 anomaly and emergency-response activation, but explicitly deferred any confirmed loss figure until “investigation is complete.” As of early August 2026, no further disclosure, fund recovery, freeze, or compensation plan has surfaced, and BLC’s peg remains uncollapsed.

How It Could Have Been Avoided: Every failure here traces to a single-source, single-transaction price feed with no economic friction between input and action, so the fixes are specific: (1) replace the raw poke() spot write with a TWAP over a minimum multi-block sampling window sourced from multiple independent feeders, plus an on-chain deviation/bounds check in the Spotter that rejects any update moving price beyond a fixed max percentage from the last recorded value — this alone would have blocked a single abnormal BTCB quote from ever reaching the Vat; (2) insert a MakerDAO-style Oracle Security Module delay (e.g., a one-hour buffer) between a price update and its consumption by the Dog module’s bark(), giving governance or keepers a window to freeze an anomalous feed before any liquidation executes — this directly closes the “atomic manipulate-then-liquidate in one transaction” path used here; (3) wire an automatic circuit breaker that halts further poke()/bark() calls after any liquidation triggered by a price move exceeding the deviation threshold, since the absence of exactly this control is why the attacker could replay a near-identical exploit roughly two hours later for another ~5,900 BLC; (4) harden GemJoin with a hard invariant — enforced ideally via formal verification — that total BLC minted can never exceed collateral value actually joined, with the null-address/zero-collateral mint path structurally impossible rather than merely access-controlled; and (5) scope future audits (unlike the prior CertiK review) to explicitly cover oracle-input trust boundaries and liquidation-module invariants as first-class attack surface, not just the token-minting contract logic in isolation, since treating oracle data as trusted input is precisely the gap that let this pass audit.

21. Solido Cash — Oracle Fallback Misassignment Nets ~$73,400 (293.7M SUPRA) on Supra

Date: 2026-07-23  |  Chain: Supra  |  Estimated Loss: ~$73,400

On July 23, 2026, Solido Cash — the largest DeFi protocol on Supra mainnet — lost 293,705,544.97 SUPRA in net attacker proceeds (809,051.55 CASH minted as bad debt) to an oracle-selection/fallback misassignment, independently corroborated at ~$73,400 by SlowMist, DefiLlama, and cross-checked against eight SUPRA price trackers clustered at $0.0001937–$0.00022 for the window (a competing “~$900K” figure from two outlets appears to price the CASH bad-debt at its $1 peg rather than the SUPRA actually extracted at its real, depressed market price, and is contradicted by every contemporaneous price source). Root cause: SOLID, added as CDP backstop collateral in the November 2025 tokenomics update, had its dedicated price feed go stale; the protocol’s standard fallback — applied uniformly across every listed collateral, not just SOLID — repriced it via get_fa_collateral_price_raw at 0.99919999 (near 1:1 with CASH, effectively ~$1) while SOLID’s actual executable price was only ~22.2 SUPRA/unit. Solido’s own forensic report classifies this as a pricing-path defect, explicitly not reentrancy and not classic open-market oracle manipulation — the bad valuation pre-existed in protocol logic. Wave A (18:21:35 UTC) was a single atomic Move transaction chaining 121+ events across nine buy-SOLID/deposit/mint-CASH/sell-CASH loops on Atmos, ending with a Trove of 702,500 SOLID against 470,677 CASH debt (67.0003% ratio) and netting 266,778,767.97 SUPRA from ~228,213 SUPRA starting capital. The team pulled only the Atmos front-end before 22:12 UTC, but the permissionless contracts stayed fully live — pool-pause flags still read false and all collateral operations remained enabled. Wave B exploited exactly that gap: starting 21:12 UTC (before the front-end takedown) and continuing after it, five relay wallets — the first funded by 398,044 SUPRA from an exchange-omnibus-pattern address — manually escalated Trove sizes 5,000→30,000→100,000→180,000→183,000 units across five loops, netting 26,926,777 SUPRA paid to a customer exchange deposit address in three tranches between 21:39 and 22:06 UTC. Full contract-level containment (operation flags disabled on all six collateral listings) landed 23:05–23:12 UTC, roughly five hours after the first exploit transaction and two hours after Wave B began. Solido confirmed the CASH depeg publicly on July 24, stated depositor/borrower funds were unaffected (both waves opened new positions rather than draining existing ones) and liquidations continued normally, then published a detailed forensic report on July 25 tracing ~220M SUPRA (74.9%) to a suspected Gate.io deposit and 26.9M SUPRA (9.2%) through an omnibus-then-customer-deposit path, with 46.8M SUPRA (15.9%) still unmoved. PeckShield and CoinGabbar both note ~90% of the LP-side losses fell on Solido/Supra Foundation’s own liquidity rather than third-party users. No fund recovery or reimbursement had been reported as of early August 2026.

How It Could Have Been Avoided: The single point of failure was a fallback pricing path that defaulted a stale feed to near-par ($1-equivalent CASH pricing) instead of failing closed — that one design choice should never exist: a feed-staleness check must suspend minting against the affected collateral entirely rather than substitute any default value, let alone one 4-5x above the asset’s real 22.2-SUPRA executable price. Layered on top of that, per-collateral and per-transaction mint caps would have bounded Wave A’s single 121-event atomic transaction to a fraction of its actual 470,677 CASH debt, and a deposit-to-borrow cooldown would have broken the atomic buy-SOLID→deposit→mint→sell-CASH loop that made same-block compounding possible. Liquidity-aware collateral haircuts — sizing max-mintable CASH against a collateral’s actual on-chain DEX depth rather than its oracle-quoted value — would have flagged SOLID’s thin Atmos liquidity long before a 702,500-unit Trove could form. A secondary oracle cross-check (TWAP from Atmos/Dexlyn spot price with a deviation threshold against the primary feed, triggering an automatic pause rather than a par-value fallback on divergence) would have caught the ~99919999-vs-22.2-SUPRA gap outright. Most consequentially, the incident shows front-end takedown is not containment: Wave B ran for roughly two hours through the still-live, permissionless contracts after the Atmos UI was pulled, so a protocol-level circuit breaker — automatically halting mint operations on anomalous debt/collateral-ratio spikes (the 67.0003% Trove) or anomalous mint velocity (the 5,000→183,000-unit escalation) — needs to be wired to the contract itself, with an emergency-pause multisig or guardian role capable of disabling collateral operation flags globally within minutes, not hours, of detection.

22. Verus-Ethereum Bridge — $7.54M Drained in Second Exploit of the Same Bug Class in 90 Days

Date: 2026-07-23  |  Chain: Ethereum  |  Estimated Loss: $7.54M

On July 23, 2026 at 03:45:59 UTC (Ethereum block 25,592,836), an attacker drained ~$7.54M from the Verus-Ethereum bridge in a single transaction (0xa1f1e65c1cea4dba4ae439cd4dcdba6cc2dbda0ed1228e61f29ae9c9324eb099), the bridge’s second exploit in 66 days following a $11.58M drain on May 18. Root cause: VerusProof.checkExportAndTransfers (deployed separately from the bridge proxy at 0x54e03a1682fd0bb065b669f6296f97028dcfd4ce) verified that a submitted transfer list matched its own committed hash but never verified the transfers were backed by assets actually locked on the Verus side — a self-referential proof, not a provenance proof. The attacker first pushed a trivial 0.01 VRSC transfer through the bridge to register as the “most recent export,” then spent that output in a Verus transaction embedding a hand-crafted export committing to eight fraudulent transfers payable to their own address. Submitting this forged export via submitImports() → _createImports(bytes) (selector 0x2babda4c) → TokenManager.processTransactions triggered unbacked payouts of 1,137.45 ETH, 71.50 tBTC, 149,275 USDC, 78,300.5 USDT, 31,475.7 EURC, 59.43 MKR, 92,784.4 scrvUSD, and 220,357 DAI — the DAI leg freshly minted by drawing directly against the bridge’s own MakerDAO/Sky CDP position via the DSR/DaiJoin exit path rather than pulled from reserves. Proceeds were consolidated into ~3,916 ETH and routed through Tornado Cash starting ~90 minutes post-exploit. Critically, May’s exploited function (checkCCEValues, missing source-amount validation) had been patched — but the fix addressed only that specific function’s flaw, not the broader “commitment-checked-but-not-backing-checked” class it belonged to, leaving the sibling function checkExportAndTransfers exploitable via a different entry path. Verus had redeposited ~1,192 ETH recovered from May’s negotiated 75% clawback into this same contract on July 8 (v1.2.17 restoration) — 15 days before the July 23 repeat drain. Unlike May, where Verus publicly negotiated and recovered funds via Discord/X, this time Verus issued no statement, made no on-chain pause, and did not respond to The Block’s request for comment; the loot wallet (0xCFd0A20703cD11E0b9f665e1C3F1Ef989C142D54) was swept to ~0.09 ETH by the time researchers checked. Verus TVL fell from ~$90–100M in early 2025 to under $5–9M by late July 2026 across both incidents. Documented independently by Backward Labs (reproducible PoC), Blockaid, CertiK, QuillAudits, rekt.news, The Block, and CoinDesk, with PeckShield tracking the Tornado Cash flows.

How It Could Have Been Avoided: The break is a classic proof-of-format vs. proof-of-validity gap: checkExportAndTransfers confirmed a transfer list hashed to its own claimed commitment, but nothing tied that commitment back to actual locked collateral on Verus. Closing this requires an explicit cross-chain backing invariant enforced at the TokenManager.processTransactions release point — sum(transfer values in an import) must be checked against a verifiably-locked reserve delta on the source chain, not merely against a self-supplied hash — and that invariant needs to be formally specified and verified across every import entry path (submitImports, and any future sibling functions), not patched function-by-function as happened after May, where fixing checkCCEValues left checkExportAndTransfers’s identical flaw untouched. Second, single-relayer/self-attested exports should be replaced with M-of-N independent validator attestation on each export before Ethereum-side acceptance, so no single crafted commitment (built end-to-end by the attacker themselves) can pass unilaterally. Third, the DAI leg exposed a second-order failure: the bridge’s own Maker/Sky CDP mint authority (DSR/DaiJoin exit) was reachable from an arbitrary attacker-supplied import with no separate gate — CDP draw-down/mint actions of this kind should require a timelocked, governance-signed step decoupled from the generic import-processing path, not be a side effect of TokenManager consuming “accepted” transfers. Fourth, per-transaction and per-epoch withdrawal caps (circuit breakers) on the bridge’s reserve contract — capping total USD value releasable in a single import or block — would have limited an eight-asset, $7.5M single-tx drain to a fraction of that, buying time for a pause. Fifth, given Blockaid’s detection fired in real time yet no on-chain response followed, the bridge needed a pre-wired emergency multisig pause callable directly off that alert class. Finally, since the May incident’s clawed-back funds were redeposited into this exact contract on July 8 without an intervening full audit of the entire import-verification module, any post-incident fund restoration to a previously-exploited bridge should be gated on independent re-verification of the whole proof-checking surface, not just the specific function implicated in the prior exploit.

23. Triple-A — $11.8M Hot/Treasury Wallet Compromise Across Seven Chains

Date: 2026-07-24  |  Chain: Multi-chain  |  Estimated Loss: $11.8M

Triple A Technologies (Singapore, MAS MPI license PS20200525) had its own operational/treasury hot wallets — not client-custodied funds — drained across seven chains (Ethereum, TRON, Polygon, Arbitrum, Solana, TON, and Bitcoin) starting July 24, 2026. On-chain analyst Specter flagged the first large outflows at 5:18pm ET; PeckShield amplified an ~$9.7M estimate roughly 4.5 hours later tied to an Ethereum consolidation address holding 5,226.67 ETH; Specter revised the total to ~$11.8M early July 26 after tracing a further ~$1.8M in newly-implicated BTC/TRON outflows, over a cumulative ~31-hour draining window during which new deposits into the compromised wallets were still being swept as late as July 26. Stolen assets were swapped (mostly via DEXs) and bridged into a single Ethereum address, 0x01F83B5d4fb30E8AA3daC1681B4048D9135253b1, which received ~5,227–5,287 ETH across 8–12 tranched inbound transfers (largest single tranche ~4,140 ETH) — a pattern consistent with methodical, purpose-built draining infrastructure rather than one opportunistic transaction. Triple-A says it “identified unauthorized access” on July 25 and contained the incident the same day, placing services into maintenance mode for ~3 hours before restoring normal processing; its official July 27 statement discloses no loss figure, no wallet addresses, and no root cause, stating only that impact is “limited to specific operational accounts” and will be absorbed from treasury reserves. Client funds were unaffected because they sit in segregated trust accounts with third-party safeguarding institutions, structurally separate from the compromised hot wallets. TechTimes’ independent technical analysis characterizes the pattern as the attacker having obtained “persistent authenticated access to Triple-A’s wallet management layer — not a one-time key theft” — and notes Triple-A’s Fireblocks/MPC signing infrastructure does not stop a transaction request coming from an already-authenticated, compromised session. No source has confirmed the specific entry vector (leaked credentials, session hijack, insider, or exploited vulnerability); as of August 4, 2026 no root cause disclosure or recovery has followed.

How It Could Have Been Avoided: The reported failure mode is a compromised authenticated session against the wallet-management/API layer sitting in front of MPC signing — MPC distributes key shares but still executes whatever a validly-authenticated caller instructs it to sign, so the fix has to target session and policy integrity, not key custody. Concretely: bind wallet-management API/console sessions to short-lived, narrowly-scoped tokens rather than long-lived bearer credentials, require hardware-bound re-authentication (FIDO2/hardware token) per session and per high-value transaction batch, and enforce device/IP allowlisting plus automatic session termination on anomalous concurrency or geography. Layer a Fireblocks-style Transaction Authorization Policy (or equivalent) requiring N-of-M human co-approval from physically and organizationally separate approvers for any withdrawal above a low threshold, independent of whatever session initiated the request, so a single compromised credential cannot unilaterally move funds. Add destination-address allowlisting with a mandatory cooldown/timelock (24–48h) on any first-time withdrawal address per chain — this alone would have blocked rapid consolidation into a brand-new address like 0x01F8…53b1 across 8–12 tranches in hours. Cap hot-wallet float per chain with automatic sweep of anything above the operational minimum into a cold/quorum-gated vault, so a compromised session on any one of the seven chains exposes only a bounded balance rather than the full treasury. Finally, since draining continued for ~31 hours with new deposits still being swept as late as July 26 — well after Triple-A’s own July 25 “containment” — the incident-response runbook needs a global kill-switch: on first indication of unauthorized wallet access, immediately revoke and rotate all wallet-management credentials and pause inbound-sweep automation across every chain simultaneously, not just place customer-facing “services” into maintenance mode while the underlying treasury wallets on other networks keep transacting. Real-time internal transaction-velocity monitoring with auto-freeze (rather than relying on external analysts like Specter/PeckShield, who caught the first outflow hours before Triple-A’s own detection) would have caught the anomalous multi-chain, multi-tranche drain pattern well inside the 31-hour window.

24. Lien Finance — $542K Drained via a Bond-Exchange Multiset Validation Gap

Date: 2026-07-24  |  Chain: Ethereum  |  Estimated Loss: $542K

On July 24, 2026 at 01:26:47 UTC, an attacker drained 542,144.628604 USDC (~$542,000) from Lien Finance’s bond-issuance protocol on Ethereum in a single transaction (0xb96d572b557a12f5ef193e88cca86123a6ae1b6e98b0eeee265870c85848e0e7). The attacker deployed an orchestration contract and permissionlessly registered a new bond group on BondMakerCollateralizedEth (0xda6fc5625e617bb92f5359921d43321cebc6bef0 / 0x843225cf6e663e4454732d6b551a737ac7b47de0) — no governance approval required — then called exchangeEquivalentBonds(), which lets users swap one basket of bonds for an “equivalent” basket by matching each entry against a per-group multiset, including designated exception bondIDs. The validation only tallied the aggregate count of exception occurrences across the group rather than checking each individual bondID’s required count; duplicating one exception bondID in the output group satisfied the aggregate check while a different bond that should have been supplied as input was never burned. This minted new, non-exception BondTokens with no real collateral backing — confirmed on-chain via the LogExchangeEquivalentBonds and LogExchangeBondToErc20 event trace. The uncollateralized bonds were then routed into Lien’s GeneralizedDotc OTC pool (0x656e5e976d523a427f05B0c212A22A89ccD9eF18), whose _calcRateBondToErc20 pricing function valued them as if fully collateralized, and swapped through three pre-authorized endpoints for USDC drawn from pool address 0xA961684a3a654fb2cCA8F8991226C0CEfc514d80 to attacker address 0x0D7d9023531aD1A88414E216Ee2715F63561808a. SlowMist and on-chain analysts (DefimonAlerts, exvulsec) attributed the blast radius to three compounding factors: the multiset check gap itself, permissionless bond-group registration (attacker-controlled payoff structures with no review), and a pricing function that trusted mint accounting without verifying real collateral backing. Notably, Lien’s predecessor BondMaker system had a structurally similar equivalence-function weakness flagged by whitehat Samczsun in September 2020 (~$10M at risk, no loss then); this is reported as the first time the flaw class produced an actual loss. As of August 4, 2026, Lien Finance has released no official postmortem, no statement on pausing affected contracts, and no reimbursement plan — all technical detail traces to third-party security-firm analysis rather than protocol-authored disclosure.

How It Could Have Been Avoided: The root defect is an aggregate-vs-per-key counting bug: fix requires replacing the single exception-count tally in exchangeEquivalentBonds() with a per-bondID multiset check — a map of bondID → required occurrences that must be decremented to exactly zero for every unique ID in the group, with the transaction reverting on any nonzero remainder, so duplicating one ID can no longer mask the omission of another. This specific invariant — “BondToken supply minted in a group == collateral actually locked/burned for that group” — should have been encoded as a formal property (Certora rule or Foundry invariant/fuzz test) and checked on every exchange call, since it is exactly the class of bug Samczsun flagged in the original BondMaker in 2020; maintaining a regression suite from prior audit findings would have caught the reintroduction. Permissionless bond-group registration let the attacker unilaterally craft the exception-heavy group used in the exploit; gating registration behind a timelocked or multisig-reviewed allowlist (even a short delay window) would have given time to flag anomalous payoff/exception structures before they became exploitable. On the pricing side, _calcRateBondToErc20 should not trust a BondToken’s face validity — GeneralizedDotc’s settlement path needs to independently verify the token’s collateral lock against the vault’s actual locked-ETH balance before quoting or executing a swap, decoupling OTC pricing from mint-supply trust. Finally, a mint-rate circuit breaker (per-block/per-tx cap on newly minted non-exception BondTokens, or a mandatory delay before freshly minted bonds are swappable in the OTC pool) would have limited the single-transaction blast radius even if the multiset check had still been bypassed.

25. Projekt Reward Vault — $560K Drained via Fabricated Purchase-Delta Accounting

Date: 2026-07-25  |  Chain: Ethereum  |  Estimated Loss: $560K

On July 25, 2026 at ~01:11:59 UTC, an attacker drained 301.704684684555317704 ETH (~$560,000) from Projekt’s unverified “buy-to-earn” reward vault (0x574Fc478bc45cE144105fa44D98b4B2e4BD442cB) on Ethereum in a single atomic transaction (0x90f40d3c3b60370f7287d51d972ef54596c46e98f21af91b03a4e84c5e410f64). The attacker (0x61e7AD696215688D274c729a4Cd0FBbc88fC4F85) flash-loaned ~14,000 WETH from Morpho, then routed it through dozens of Uniswap V2 memecoin pairs (including Kirby Inu and ROTTSCHILD), calling each pair’s permissionless skim() to sweep artificially-inflated token balances into disposable CREATE+SELFDESTRUCT helper contracts — near-zero-cost, no genuine swap involved. The attacker then called the vault’s permissionless trackPurchase(buyer), which sized an ETH reward allocation purely from the caller’s raw token-balance delta, with no check that ETH had actually been spent, that a real market purchase occurred, or that the underlying activity hadn’t already been claimed. The fabricated skim()-derived deltas registered as legitimate purchase volume, inflating the attacker’s stored allocation; a final call to the unguarded massWithdraw() paid that inflated balance straight to msg.sender. The Morpho loan was repaid within the same transaction, making the exploit fully capital-free. Forta Network’s Forta Firewall reportedly flagged the transaction, but it still executed to completion. Root cause: a business-logic/accounting flaw, not reentrancy or access control — trackPurchase() trusted a raw token-balance delta as a proxy for verified real spend, and massWithdraw() paid out that unverified figure with no additional gate. As of Aug 4, 2026 (11 days post-incident), no Projekt/GREEN/GOLD team statement, post-mortem, or compensation plan has surfaced on any official channel; the vault remains unverified on Etherscan and no rekt.news writeup exists. Figures are corroborated across five independent sources — Defimon Alerts, SlowMist Hacked, AUTOSEC.DEV, DefiLlama’s hacks database, and direct Etherscan transaction data — with no discrepancies found.

How It Could Have Been Avoided: The single broken invariant here is “reward issued must equal value actually spent,” and every mitigation should enforce it directly rather than generically. trackPurchase() must never derive a reward allocation from a passive balanceOf() read; it should only be callable through a trusted, allowlisted purchase router that itself executes the swap, checks msg.value or verified ETH/WETH input against slippage-bounded output, and forwards that verified spend amount atomically — arbitrary EOA calls to trackPurchase(buyer) should be rejected outright. Any contract that reads Uniswap V2 pair state for economic significance must reconcile against getReserves(), not raw token balanceOf(), since skim() is permissionless-by-design and lets anyone inflate a pair’s balance without a swap ever occurring; treating balance deltas as purchase proof is the exact anti-pattern to formally verify against (assert cumulative rewards allocated <= cumulative ETH actually received by the vault, checked in-transaction). massWithdraw() needed a circuit breaker independent of the upstream accounting bug: a per-block/per-tx withdrawal cap, plus a timelock or multisig-gated pause triggered automatically when a single allocation or withdrawal exceeds a defined threshold relative to the vault’s historical average, would have stopped the payout even after trackPurchase() was already corrupted. Given that Forta’s Firewall detected the transaction pattern but had no enforcement authority, the vault should have been wired so a flagged-transaction signal triggers an automatic pause rather than a passive alert. Finally, shipping an unverified contract holding user-facing reward liquidity removed the basic pre-condition for any of this to be caught pre-launch — source verification plus a pre-deployment audit targeting the specific claim “trackPurchase allocations must correspond to real, non-replayable ETH spend” is the control that should have existed before mainnet funds were at risk.

26. Bankrbot / $BNKR — $479,885 Drained via X-Account Takeover and an Unprotected Project Wallet

Date: 2026-07-25  |  Chain: Base  |  Estimated Loss: $479,885

On July 25, 2026, Bankr (the $BNKR agent project on Base) suffered two linked failures. First, the @bankrbot X account — nominally secured by an on-device passkey — was taken over; developer @0xDeployer reported the team locked out at 18:09 UTC and confirmed the account compromised and posting fake airdrop links at 23:11 UTC. Second, a Bankr project-linked wallet that had no MFA protection was drained of roughly 1.5 billion $BNKR in a reported ~22-second on-chain event; the tokens were immediately dumped on the market, crashing price. SlowMist’s third-party valuation puts the loss at $479,885, independently corroborated same-day by blog.autosec.dev — Bankr itself has not published a reconciled loss ledger. Independent on-chain analysis (@the_smart_ape) traced the attacker’s funding wallet to a creation date of July 23, 2026, roughly 45 minutes after Robinhood CEO Vlad Tenev’s X account was separately compromised, suggesting a possible multi-target “hijack the account, run the scam” campaign against high-profile crypto/finance handles. Recovery was slow: the account remained under attacker control past 72 hours, with fake airdrop posts recurring days later. On July 27, @0xDeployer issued a follow-up (corroborated by KuCoin/PANews, Bitget, RootData) stating Bankr’s infrastructure and smart contracts were not breached — only the X account — isolating root cause to account-security and wallet-hygiene failure rather than a protocol exploit. No attacker address, affected wallet address, transaction hashes, or liquidation path has been publicly disclosed, and no formal reimbursement program has been announced for this incident, unlike Bankr’s earlier, unrelated May 2026 user-wallet incident.

How It Could Have Been Avoided: The root cause was single-point-of-failure custody on two fronts, and both are fixable with standard controls Bankr didn’t apply here. The project wallet holding ~1.5B BNKR should never have been a single-signer EOA with no MFA — it needed multisig custody (Safe with N-of-M hardware-key signers) so a single compromised credential can’t move the full balance, plus a velocity-based circuit breaker or withdrawal rate limiter (e.g., a max-percentage-of-balance-per-transaction cap, or a timelock on transfers above a threshold) that would have interrupted a 22-second full-drain regardless of how access was obtained. Post-launch token allocations of this size (the 85%-to-pool/15%-team-vesting structure from the July 19 redeployment) belong in a timelocked or vesting contract rather than a hot wallet reachable by any single compromised session. On the account-security side, a device passkey alone was insufficient; a FIDO2 hardware security key as an unphishable, non-device-bound second factor, combined with a periodic audit of connected/authorized third-party apps and OAuth grants on the X account, would close the exact bypass channel that was never disclosed. Bankr should also pre-register an escalation contact with platform Trust & Safety before an incident (rather than relying on ad hoc public appeals to staff like Nikita Bier) to cut recovery time well below the 72+ hours observed here, and should structurally separate public-facing comms accounts from any wallet-signing trust chain so that a social-account compromise can never be a stepping stone to on-chain fund access — the fact that both failures happened in the same window, whether coordinated or coincidental, argues for treating them as one combined threat model rather than two independent risks.

27. ChainConnect Bridge Exploit — ~$650K Drained via Broken Access Control in Alien Proxy Callback

Date: 2026-07-26  |  Chain: Multi-chain  |  Estimated Loss: ~$650K

On July 26, 2026, an attacker exploited a missing sender-verification check in the onCheckAccumulatedFee callback of ChainConnect’s ProxyMultiVaultAlien_V10 bridge contract on Venom 2.0. The unauthenticated callback let an unauthorized caller trigger minting of unbacked “Alien” TIP-3 tokens, which were then bridged to Ethereum through ChainConnect’s standard bridge flow. From there, liquidity was drained from EVM-side bridge contracts across Ethereum, BNB Chain, Avalanche C-Chain, and Polygon in 23 transactions before ChainConnect paused all bridge operations. ChainConnect — a cross-chain bridge built by Broxus within the Venom/Octus Bridge ecosystem, spanning TVM chains (Venom, TON, Everscale, Hamster Network) and EVM chains — lost approximately $650,000, independently confirmed by both SlowMist’s hacked.slowmist.io database and DefiLlama’s hacks database (both dated July 26, 2026, “Protocol Logic/Unauthorized Access”). Venom Foundation confirmed the Venom network, TVM, TIP-3 standard, relay/validator infrastructure, and all private keys remained uncompromised — the bug was isolated to ChainConnect’s application-layer proxy contract. ChainConnect took responsibility, patched the vulnerability across affected deployments, and negotiated fund recovery: per Venom Foundation’s post-mortem (published July 31, 2026 — corrected from an initially cited Aug 1 date), 82.9% of affected funds (~$615,000) were returned by the attacker, with 17.1% (~$105,000–$127,000) retained as a negotiated “bounty,” a whitehat-style settlement. Notably, $615,000 / 0.829 implies a base of ~$741,900, not the $650,000 headline figure — a reconciliation gap present within Venom Foundation’s own post-mortem text itself, not an artifact of secondary reporting. No attacker wallet address has been publicly disclosed in any source.

How It Could Have Been Avoided: The root cause is a single missing check: the onCheckAccumulatedFee callback on ProxyMultiVaultAlien_V10 never verified its caller before allowing state changes that fed into mint logic. The fix that matters is enforcing a strict onlyBridge/onlyRelay msg.sender allowlist on every externally-callable hook that touches accumulated-fee state or mint paths — not just the obviously “privileged” entrypoints, since this bug hid in what looked like an accounting callback. Beyond the allowlist, the deeper invariant that should have been formally specified and continuously checked is supply-backing: minted Alien TIP-3 token supply must never exceed the value actually locked or burned on the origin chain, verified on every mint and monitored per-epoch rather than assumed from control flow. A real-time invariant monitor watching that ratio would have flagged the unbacked mint the instant it occurred, before the tokens were bridged to Ethereum and liquidity started draining across four EVM chains. Per-transaction and per-epoch mint/withdrawal caps with an automatic circuit breaker would have capped the blast radius well short of 23 drain transactions across Ethereum, BNB Chain, Avalanche, and Polygon. Because the vulnerable contract was a versioned proxy (_V10), each proxy upgrade needs mandatory differential review specifically targeting access-control regressions — this is the exact class of bug that gets silently reintroduced when callback logic is refactored across versions. Finally, a timelock or delay window on large outbound transfers from EVM-side vaults would have given the team a response margin before funds left the contracts, rather than relying entirely on manual detection-and-pause after the fact.

28. Garden Finance — $450K HTLC Solver-Database Exploit (July 26, 2026)

Date: 2026-07-26  |  Chain: Multi-chain  |  Estimated Loss: $450K

On Sunday, July 26, 2026, security firm Blockaid flagged an active exploit draining ~$450,000 in USDT from Garden Finance’s HTLC-based cross-chain swap infrastructure, simultaneously across Ethereum, Base, Arbitrum, and BNB Smart Chain. Blockaid published the exploiter’s address (0x25b224c05f6cc5e132165c1621de1a4c3b316999) and example transaction hashes the same day. Garden took its front-end offline within hours, posting via @gardenfi that it had “identified unusual activity.” Root cause, per Garden’s spokesperson (Cointelegraph, updated Jul 27, 02:16 UTC): compromise of one independent solver’s off-chain database, not the HTLC smart contracts or core protocol. The attacker inserted fabricated swap records into that solver’s backend; the solver’s automated release logic read those records as legitimate completed counterparty deposits and released its own USDT from the HTLC contracts on all four chains against deposits that never actually occurred. DefiLlama’s hacks database classifies the incident as “Solver Exploit” / “Private Key Compromised,” consistent with a solver credential/backend compromise rather than a contract bug. Only solver-owned funds were lost; Garden states no user deposits were lost or placed at risk, since user funds remained governed by unaffected HTLC escrow logic. KuCoin (Aug 1, 2026) reports the attacker consolidated ~$425,000 across the four chains shortly after Blockaid’s alert. Garden engaged zeroShadow, Quantstamp, and Blockaid for tracing and recovery support, cited its recently completed SOC 2 Type II attestation, and said it expected to restore service pending further security review, without a firm timeline. This is Garden’s second solver-layer incident: a different solver’s operating environment was compromised in October 2025 for an estimated $10.8M–$11.4M, also without user-fund loss. As of August 4, 2026, no recovery/freeze amount, no dedicated postmortem blog post, and no service-restoration date had been announced for the July incident.

How It Could Have Been Avoided: The failure mode here is authorization-by-mutable-state: the solver’s release trigger treated a row in its own writable database as proof of a counterparty deposit, instead of requiring a verifiable, tamper-evident attestation tied to actual chain state. Concrete fixes that map directly to this root cause: (1) require on-chain-verifiable deposit proof before release — an SPV/light-client proof, a direct on-chain event listener with N-confirmation depth, or a signed independent-oracle attestation — never a plain DB boolean, so fund release is provably conditioned on the counterparty’s real transaction rather than an internal record; (2) make “deposit completed” records append-only and cryptographically signed at write time, with the release path verifying that signature chain, so a compromised credential or forged SQL insert cannot mint a valid completed-deposit event; (3) gate high-value or multi-chain-simultaneous releases behind M-of-N multi-party approval (e.g., 2-of-3 independent signers, or cross-verification from a second, independently-operated solver/indexer) rather than single-solver unilateral release authority, eliminating the single point of compromise; (4) add a circuit breaker on each solver’s hot-wallet release path — per-chain rate/volume caps with manual or multisig sign-off above a threshold — which alone would have capped the simultaneous four-chain drain instead of letting it complete before detection; (5) segment and cap per-solver hot liquidity per chain so one compromised backend can never expose the full HTLC balance across all deployed chains at once; (6) harden the solver’s database layer itself with least-privilege service credentials, secret rotation, mTLS/network segmentation between solver services and the DB, and real-time anomaly alerting on unexpected inserts or status flips in swap tables — the fabricated records should have tripped a write-pattern anomaly detector before any release executed. Garden’s SOC 2 Type II attestation is an infrastructure/process compliance control and would not by itself catch this kind of application-logic trust bug; the actual fix has to be architectural — cryptographically-verified release conditions, not database-trust — not organizational.

29. WEMIX$ — $5.23M Unauthorized Mint via Re-Initializable Proxy Contracts

Date: 2026-07-26  |  Chain: WEMIX3  |  Estimated Loss: $5.23M

At 18:17 KST (09:17 UTC) on July 26, 2026, an attacker seized owner authority over two WEMIX3.0 upgradeable-proxy contracts backing the WEMIX$ stablecoin: DIOS (price-stability/minting logic) and AMA (1:1 collateral redemption). Both used the standard pattern of setting the owner via a one-time initialize() call — but per Wemade’s own July 30 root-cause report, the initialization counter was never properly locked after the first call, leaving initialize() callable a second time by any address with zero access control. In one transaction, the attacker deployed a malicious contract, re-invoked initialize() on DIOS and AMA to overwrite the owner, authorized the malicious contract to call mint/redeem, then alternated AMA’s redeem function against DIOS’s price-adjustment minting logic across nine rounds of flash loans and swaps. Net result: 5,225,524.9997 WEMIX$ minted without backing (~$5.23M face value at the ~1peg;KuCoin′son−chainreadputsgrossmintingat 10.47Mwith 5.246Mburnedsame−tx,nettingtotheofficialfigure).Wemadeexplicitlyrulesoutaleakedprivatekeyorinternal−systemcompromise—thiswasapuresmart−contractaccess−controlgapintwolegacycontractsstilllivedespiteaSeptember2025−announcedWEMIX-to-USDC.e sunset. Proceeds were converted to WEMIX/USDC.e and bridged off WEMIX3.0 via Chainlink CCIP and the PLAY Bridge to Ethereum and BSC, then swapped to ETH/USDT with some reaching CEXs; the confirmed at-risk transfer was 723,244.4936 USDC.e + 34,752.3199 WEMIX (~$735K–760K),versusthemuchlargerunbacked−mintfacevalue.WemaderespondedbysuspendingallWEMIX3.0bridges,haltingtheWEMIX Module and PNIX DEX, freezing trading across WEMIX-USDC.e, WEMIX-WEMIX,CROW−WEMIX, TIPO-WEMIX,PLAY−WEMIX and related USDC.e pools, pulling Foundation liquidity, revoking WEMIX$ minting authority, requesting exchange/issuer freezes on identified attacker addresses (none publicly disclosed), and filing a criminal report July 28 at 13:00 KST. This is Wemade’s second major security incident in under 18 months, following the ~$6.1–6.2M Play Bridge Vault exploit of Feb–March 2025 (a stolen NILE-platform auth key — an unrelated attack surface). As of August 4, 2026, no compensation plan or bridge-reopening timetable has been published.

How It Could Have Been Avoided: The root failure is a re-initializable proxy: initialize() on DIOS and AMA had no guard against being called twice, so the “one-time setup” that assigns owner could be replayed by any caller post-deployment. The direct fix is OpenZeppelin’s Initializable pattern used correctly — an initializer (or versioned reinitializer(n)) modifier that checks and permanently flips an _initialized flag/version on first successful call, combined with calling _disableInitializers() in the implementation contract’s constructor so the logic contract itself can never be initialized outside the proxy’s delegatecall context. That single missing modifier check is the whole incident; a unit test asserting initialize() reverts on second invocation, plus a Slither/static-analysis rule for unprotected-initializer and uninitialized-proxy patterns, would have caught it pre-deploy. Beyond patching the primitive: owner/authority changes on stability-critical contracts like DIOS and AMA should require multi-sig or timelocked governance rather than being settable in a single unguarded call, and should use two-step ownership transfer (Ownable2Step) so a hijacked initialize() can’t unilaterally finalize control. Mint/redeem paths need economic circuit breakers independent of access control — per-transaction and per-block mint caps, and same-block mint-then-redeem or flash-loan-triggered-mint detection — so that even a compromised owner can’t mint 5M+ tokens in one atomic sequence; the nine-round flash-loan/swap chain that produced this exploit is exactly the pattern such a rate limiter or reentrancy-aware supply-invariant check (minted supply vs. verified collateral, enforced on-chain, auto-pausing on breach) is designed to stop. Finally, contracts formally slated for deprecation (WEMIX$→USDC.e was announced in September 2025) should have privileged functions revoked or the contracts paused immediately, not left live with dormant mint/redeem authority for eleven months — deprecation without authority revocation is itself the residual attack surface here.

30. LULA recycle() Exploit — $578K Lost to Privileged Reserve Manipulation on BSC

Date: 2026-07-28  |  Chain: BNB Smart Chain  |  Estimated Loss: $578K

On 2026-07-28 UTC, the LULA token contract on BNB Smart Chain (0x72ad494fda63d2b91b9d7290737e8ef1194a0c47) was drained for ~$578,100 via a privileged recycle() function tied to its “Rental” contract. Per CertiK Alert (3:39 AM UTC Jul 29) and BlockSec Phalcon (2:55 AM UTC Jul 29), both independently linking tx 0xa219ab9d57e520e5235b15a8801f4ebac8cc45551be0430ce4e49caea0411d7c, the attacker pre-staged ~12-13 days ahead of time, deploying helper contracts and accumulating referral/team rewards. On attack day, the attacker took a ~$237M flash loan, swapped a large USDT amount into LULA on the PancakeSwap V2 LULA/USDT pair to inflate its USDT reserve, then repeatedly called claimReward() -> recycle(). recycle() — restricted to the Rental contract but reachable via the reward path — computed a max take of ~1/3 of the pair’s LULA balance per call, moved LULA straight out of the pair via an internal _basicTransfer(), and then called sync() to force the pair’s on-chain reserves to match the post-drain balances, letting the attacker set the pool’s price directly rather than through organic swap-based price discovery. A final small LULA-to-USDT swap against the now-imbalanced pool extracted the profit, and the flash loan was repaid atomically in the same transaction, netting ~$578,100. Root cause: an unrestricted/privileged function capable of pulling tokens directly out of a live AMM pair and force-resyncing reserves, compounded by a reward-accrual mechanic gameable with flash-loan-funded volume. No official LULA statement, pause, or recovery effort has surfaced as of this writing; coverage remains limited to CertiK, BlockSec Phalcon, and TenArmor alerts plus secondary aggregation, and no attacker address has been publicly attributed.

How It Could Have Been Avoided: The break here is structural, not a typo: a contract other than the pair itself (the Rental contract, via recycle()) had standing authority to pull tokens out of the LP and call sync(), which lets a privileged caller set reserves instead of letting the constant-product formula derive them from actual swaps. That authority should never have existed — recycle() should only ever move tokens the Rental contract itself custodies, never tokens sitting in the PancakeSwap pair, eliminating the direct-transfer-then-sync pattern entirely. If a resync mechanic is truly required, it needs a TWAP-plus-max-deviation guard (reject any post-sync price that diverges more than a fixed percentage from an N-block time-weighted average) so no single transaction can reprice the pool outright. The claimReward()->recycle() path also needed a hard per-transaction/per-block call cap or cooldown and a circuit breaker that halts further privileged calls once reserve deltas within one transaction exceed a threshold — this specifically would have stopped the repeated intra-transaction draining that compounded a single flash-loaned block into $578K. Because the entire chain (flash loan -> swap -> repeated recycle() -> reverse swap -> repayment) executed atomically, a guard disallowing recycle() invocation in the same transaction as a large swap against the same pair, or basing recycle()’s eligible amount on pre-transaction reserves rather than the current (attacker-manipulated) balance, would have broken the exploit’s economics. Finally, this is exactly the kind of invariant formal verification exists for: “no function outside the pair’s own swap/mint/burn path may alter reserves reported by sync()” is a checkable property, and a Rental-contract authorization change of this consequence should have required multi-party/timelocked approval rather than being a standing, always-on privilege.

31. Crypto DAO Pro Token — $52K Drained via Unprotected exec() on BNB Chain

Date: 2026-07-28  |  Chain: BNB Chain  |  Estimated Loss: $52K

On July 28, 2026, an attacker exploited a missing access-control check on the exec function of the Pro ($Pro) token’s proxy/vault contract (0xc44f2acCAc20598A3F2b4D489A970Fcf52a04A3C) on BNB Chain, operated by Crypto DAO (@CryptoDAOGlobal). exec had no caller/authorization check, so any external contract could invoke it directly. The attacker deployed an attack contract (0xf00bC28D22d71Be74Bc8aB0d11Fe77F6D77850ac) and, within a single transaction, repeatedly called exec; each call swapped 50 $Pro into $USDT against the Pro/USDT pair. The repeated swaps progressively pushed up Pro’s price relative to USDT, and the attacker then sold remaining $Pro holdings into the inflated market, netting an estimated $52,000 profit. The exploited contract lost 167,200 $Pro in total — GoPlus Security’s on-chain forensic figure, matching the official “Amount of loss: $52,000” listed on SlowMist’s hacked.slowmist.io database. Each swap’s USDT proceeds routed to “receiver” addresses hardcoded in the exploited contract itself rather than directly to the attacker’s wallet, which is why Blockaid’s separate monitoring reported ~$8.2 million in USDT sitting across the attacker’s and receiver addresses as of July 29 — a balance snapshot of a multi-address cluster, not a stolen-funds total, as SlowMist explicitly caveats and an independent Gate.com/PANews citation of Blockaid corroborates. The team patched the exploited proxy via an on-chain upgrade to a new implementation (0xF9129AB3CBFccDfE7F39Ab0B2be79EEBA6420059, tx 0x17550c2d01774e4115761d54ddb344ec7e2c120532c0b4696bf060ed94b6073c) adding a caller-address check, per GoPlus’s thread. No public post-mortem, attacker negotiation, or reimbursement plan from Crypto DAO itself has surfaced; disclosure and analysis came entirely from third-party security firms (GoPlus, SlowMist, Blockaid) and news aggregators.

How It Could Have Been Avoided: The single missing line of code was a caller check on exec — the fix Crypto DAO shipped only after the fact should have shipped at deployment: an explicit require(msg.sender == authorizedCaller) or an OpenZeppelin AccessControl EXECUTOR_ROLE gate restricting exec to a named, allowlisted router/caller contract, not “any external contract.” Because the exploit worked by hammering one function dozens of times inside a single transaction to walk the Pro/USDT price, a per-transaction or per-block call-count cap on exec (or a minimum-interval/cooldown enforced in storage) would have capped the attacker’s price impact regardless of the access-control gap. The swap logic itself should never have priced off a manipulable in-block spot AMM rate for an internal vault operation — pricing exec’s Pro→USDT conversion off a TWAP (e.g., a 30-minute Chainlink or on-chain TWAP oracle) with a hard max-deviation circuit breaker (revert or auto-pause if single-transaction price impact exceeds ~2-3%) removes the arbitrage surface entirely. Since this was a proxy/vault contract, the upgrade-review process should include a standing checklist invariant — “every externally-reachable proxy function has an explicit, tested caller restriction” — enforced via Foundry/Echidna invariant fuzzing that specifically tries calling every public/external function from an unprivileged contract and asserts it reverts; this exact class of bug (forgotten modifier on a newly exposed proxy entrypoint) is what invariant and differential testing against the intended access-control spec is built to catch pre-deployment. Finally, routing exec’s privileged path through a timelocked multisig rather than a bare function call, paired with an automated on-chain pause switch wired to real-time anomaly monitoring (the same class of tooling GoPlus/Blockaid used post-hoc to detect this), would have given the team a window to halt the drain mid-attack instead of only patching afterward.

32. Set Protocol (Index Coop ExchangeIssuance) — $9,600 Lost to a TOCTOU Valuation Exploit

Date: 2026-07-30  |  Chain: Ethereum  |  Estimated Loss: $9,600

On July 30, 2026 (08:57:23 UTC, block 25644621), an attacker drained ~$9,600 in WETH and UNI from Index Coop’s ExchangeIssuance contract (0xc8c85a3b4d03fb3451e7248ff94f780c92f884fd) on Ethereum. No keys or governance were compromised. The attacker deployed a fully self-controlled stack: a malicious SetToken (“Batch Hooked Set” / BHSET, 0xf7c2d0a2bf81bf803ed6e1d97c89fe3b30b06948), a malicious manager contract with a pre-issue hook (0x8f449d85f728c1dd6596880ba28a0b80b6a26c58), and a malicious Valuer (0x388a3da33825e1f44ac71b8fd543523cdf994802), attacker EOA 0x0736930ae35eafefa789f11edf41d7b799e7c99d. Root cause: ExchangeIssuance.issueSetForExactToken reads a target SetToken’s components and unit weights to compute a quote, then later uses those same values to execute transfers — without locking state in between (a TOCTOU gap). The attacker issued a small amount of BHSET using 0.05 WETH; its pre-issue hook then called into the Custom NAV Issuance Module’s issue/redeem path with a falsified valuation from the malicious Valuer, inflating BHSET’s positionMultiplier by roughly 93.66x. When BasicIssuanceModule.issue subsequently read the now-inflated per-unit amounts and pulled them from ExchangeIssuance via transferFrom, it extracted far more real WETH/UNI than the original quote justified. No official post-mortem, pause, or reimbursement statement from Set Labs or Index Coop was found, including on gov.indexcoop.com. The incident surfaced entirely through third-party monitoring — SlowMist (TI alert plus its Hacked tracker), Olympix (biweekly exploit report), DeFiLlama’s hacks database, and news aggregators (Guavy, Coinfomania, Binance Square citing Foresight News, Woofun) — all independently corroborating the date and $9,600 figure with zero discrepancies. The small loss size likely kept it below the threshold for a formal protocol incident response.

How It Could Have Been Avoided: This is a textbook TOCTOU gap between quote and settlement, and closing it requires binding the two reads to one atomic state, not just “more audits.” issueSetForExactToken should snapshot the SetToken’s components, unit array, and positionMultiplier once and thread that snapshot through to the transfer step, then assert post-transfer amounts match the snapshot within a fixed tolerance — reverting on drift instead of trusting a second live read. Because the attack hinged on ExchangeIssuance permissionlessly interacting with an attacker-deployable SetToken/manager/Valuer/pre-issue-hook stack, it should restrict issuance to an allowlist of vetted SetToken–manager–module combinations rather than accepting any caller-supplied SetToken address. Manager-controlled pre-issue hooks and custom Valuers must be treated as untrusted external calls: enforce checks-effects-interactions so the quote is finalized before any hook-triggered NAV issue/redeem can run, and add a reentrancy guard scoped across the entire read-then-transfer sequence of issueSetForExactToken so a hook cannot mutate positionMultiplier mid-call. A hard circuit breaker — capping the ratio between quoted and actually-transferred amounts and reverting if the executed transfer exceeds the quote by more than a few percent — would have caught the 93.66x inflation outright regardless of how the valuation was manipulated. Finally, since the root cause reduces to one precisely nameable invariant (“units quoted equal units transferred, and positionMultiplier cannot change between quote and transfer”), it’s a strong candidate for formal verification or invariant fuzzing (e.g., Certora/Echidna rules) targeting that exact property in issueSetForExactToken and any other ExchangeIssuance function sharing the same read-then-transfer pattern.

33. Coldcard (Coinkite) — $114M–$116M Bitcoin Seed Theft via RNG Fallback Flaw

Date: 2026-07-30  |  Chain: Bitcoin  |  Estimated Loss: $114M–$116M

On 2026-07-30, 01:10:20–01:51:26 UTC (Bitcoin blocks 960,183–960,191), attackers swept 1,082.65 BTC ($70.2M) from 1,196 single-sig Coldcard wallets in a 41-minute automated sweep — identical 30.0 sat/vB fee, no change outputs, Galaxy Research’s Alex Thorn calling the pattern “deliberate and programmatic, probably orchestrated with a large language model.” Root cause: a March 1, 2021 firmware commit (b18723dd) migrated seed generation to the libngu library, whose guard in random.c checked only whether MICROPY_HW_ENABLE_RNG was defined, not its value — Coldcard’s production build sets that macro to 0 (relying on its own STM32 hardware-RNG wrapper), so the preprocessor guard silently linked builds to MicroPython’s deterministic Yasmarang software PRNG, seeded from the non-secret MCU unique ID plus timer/clock state, instead of true hardware entropy. First shipped in firmware v4.0.1 (March 17, 2021), affecting Mk2/Mk3 through 4.1.9. A separate, narrower bug — a 32-bit-only secure-element reseed added March 2022 that mixes entropy into just one of Yasmarang’s four state words rather than fully re-initializing the DRBG — capped effective entropy at ~72 bits (Mk4/Mk5/Q) or ~40 bits (Mk3) against an intended 128, affecting all tracks up to Mk 5.6.0/Q 1.5.0Q. Attackers reproduced the deterministic PRNG stream entirely offline, brute-forced candidate seeds/addresses, and checked them against on-chain balances before sweeping — no device compromise or phishing required. Block’s Security team root-caused the flaw from user reports and disclosed to Coinkite on 2026-07-30, publishing a preliminary advisory same-day given active exploitation. Coinkite shipped fixed firmware for all tracks by 2026-07-31 (Mk 5.6.0, Mk3 4.2.0, Q 1.5.0Q) but firmware updates cannot repair already-generated weak seeds — affected users must migrate to freshly generated seeds. Three further waves followed as the vulnerability circulated: Wave 2 (~76.16 BTC, 1,478 addresses, cumulative $75.1M/2,673 addresses), Wave 3 (~207.73 BTC, cumulative $88.6–89M/1,367.05 BTC/4,585 addresses), and Wave 4, detected 2026-08-03 and still running, pushing the cumulative total to ~1,816 BTC / $114M–$116M across 5,200+ addresses — DefiLlama independently lists $115M. Later waves shifted tactics toward smaller balances, batched multi-victim transactions, P2WSH outputs, fresh non-clustered destination addresses (versus Wave 1’s four consolidation addresses holding 562.02, 398.48, 89.62, and 32.45 BTC, unmoved through early August), reused aged addresses to defeat heuristic clustering, and, in Wave 4, RBF-tagged transactions that briefly let victims outbid the attacker in the mempool. Multisig wallets were unaffected — the flaw is specific to single-key seed generation. No attacker has been identified; ~600 suspected addresses were referred to investigators; no reimbursement has been reported; the incident remained explicitly “ongoing” as of the last confirmed reporting (2026-08-03).

How It Could Have Been Avoided: The defect is a single preprocessor guard, #ifdef MICROPY_HW_ENABLE_RNG where the code needed #if MICROPY_HW_ENABLE_RNG — treating a macro’s definedness as a proxy for its boolean value silently flipped hardware-RNG builds onto a software fallback with zero compile-time or runtime signal. This class of bug is directly preventable: (1) ban #ifdef/#if defined() for any macro that is assigned 0/1 rather than left undefined — enforce via a linter rule (clang-tidy bugprone-, a custom Semgrep pattern matching #ifdef MICROPY_HW_ENABLE_RNG) that flags definedness checks on macros with numeric values anywhere in the build; (2) add a build-time static assertion (_Static_assert or equivalent) that fails the firmware build if the code path resolves to the software PRNG on hardware-RNG-capable targets, so a misconfigured submodule (as libngu was here — “arrived through a submodule” per Coinkite) cannot silently override intended entropy source selection; (3) add a runtime self-test at first boot / key-generation time that samples the actual RNG output and runs entropy health checks (e.g., NIST SP 800-90B repetition-count and adaptive-proportion tests) before permitting seed generation, catching a deterministic Yasmarang stream even if the build-time check is bypassed; (4) treat reseed operations as full DRBG re-initializations, not partial state mixing — the Mk4/Mk5/Q bug of reseeding only one of four 32-bit state words is a textbook partial-entropy-injection flaw fixable by requiring reseed functions to overwrite/mix all internal state words and pass through a formally specified re-init routine rather than an ad hoc patch; (5) since seed generation is a single irreversible trust boundary with no on-chain circuit breaker possible after the fact, treat any change to entropy-source code as requiring mandatory differential testing against known-answer vectors and independent reproducible-build verification before release, exactly the kind of check that would have caught five years of shipped firmware silently using deterministic seeds; (6) as defense-in-depth independent of firmware correctness, users generating high-value single-sig wallets should supplement device RNG with ≥50 fair dice rolls or a strong unique BIP-39 passphrase — both of which Coinkite confirmed remained safe against this exact class of flaw.