Smart Contract Risks

• The PermissionsManager contract storing each Safe’s registered delegate address was fully public on-chain — the attacker read it directly to enumerate real delegates per target Safe
• For each target Safe, the attacker crafted a call payload encoding the real delegate address, along with three chained actions: APPROVE, PERMIT2 authorization, and SWAP targeting attacker-controlled pools (amountOutMin set to 0)
• The module verified the caller with: require(sourceAddress == squidRouter) — but sourceAddress was a parameter the caller supplied themselves, with no binding to msg.sender
• The module then ran: require(hasPermission(safe, delegate, APPROVE)) — but the delegate address was decoded from the caller’s own payload, not derived from msg.sender
• The attacker passed the string “squidRouter” and encoded the real registered delegate. Both checks passed. The actual caller was never verified
• The single missing line that stops the entire attack: require(msg.sender == delegate)
• With both checks cleared, the module executed all three actions: approved token balance, authorized Permit2, then forced a full-balance swap through attacker’s Uniswap V3 pool into a worthless “u” token
• Attacker removed liquidity, consolidated cross-chain via Relay, and swept everything to a single holding wallet as DAI

Root cause: Confused deputy vulnerability in SquidRouterModule. The module inherited expressExecuteWithToken() from Axelar’s gateway interface — built for relayers, not for vault execution — and placed no additional access control behind it. The contract verified that a valid delegate existed. It never verified that the caller is that delegate. A documented, well-understood pattern entirely preventable with a single require check.

• March 23 (T-9 days): Attacker created four durable nonce accounts — two for Drift Security Council signers, two attacker-controlled
• March 27 (T-5 days): Drift team executed planned multisig migration. Attacker adapted by creating new nonce account for signer (6UJbu9...Pvu924) on the updated multisig
• March 31 (T-1 day): Attacker re-established access to 2-of-5 signers on the migrated multisig
• April 1, 16:04 UTC: Drift team executed routine test withdrawal from insurance fund
• April 1, 16:05 UTC (~1 min later): Attacker executed two pre-signed durable nonce transactions in rapid succession

• Durable Nonce Mechanism: Solana feature allowing transactions to bypass standard blockhash expiration (~1 minute). Signatures collected in advance, executed later
• Social Engineering: Attacker obtained pre-signatures by misrepresenting actual transaction contents to legitimate signers
• Single Transaction Dismantled Three Defenses: In transaction 4a5962R...st82X, the attacker simultaneously:
  • Called initializeSpotMarket to create Spot Market #63 for CVT, setting initial_asset_weight and maintenance_asset_weight to maximum via bundled updateSpotMarketMarginWeights
  • Assigned attacker-controlled SwitchboardOnDemand oracle (oracle_source=11)
  • Called updateWithdrawGuardThreshold five times, raising limits on USDC, wETH, dSOL, JLP, and cbBTC markets to ~500 trillion (effectively infinite)
• Deposited ~785M CVT as collateral. Attacker-controlled oracle valued it at hundreds of millions; maxed weights recognized nearly full valuation as collateral
• Borrowed against inflated CVT collateral, draining real assets. JLP vault: 99.9997% drained (41.7M → 133 JLP)

Root cause: A 9-day social engineering campaign against a 2-of-5 multisig using durable nonces. But critically: the protocol’s privilege architecture allowed market creation, oracle assignment, weight configuration, and guard neutralization in a single transaction. The contracts functioned exactly as audited — initializeSpotMarket, updateWithdrawGuardThreshold, and oracle assignment all worked as designed. The flaw was architectural: no upper bounds on new market weights, no timelock for weight changes, no separation between market creation and risk parameter modification. This falls outside code auditing into privilege architecture and parameter constraints. Two transactions dismantled the entire security architecture.

• requiredDVNCount: 1
• requiredDVNNames: [LayerZero Labs]
• optionalDVNCount: 0
• optionalDVNThreshold: 0
• Destination OApp: rsETH OFT Adapter on Ethereum (0x85d456B2DfF1fd8245387C0BfB64Dfb700e98Ef3)

• Step 1: Attacker prepared infrastructure (funded via Tornado Cash months in advance)
• Step 2: Forged a cross-chain message that was never emitted on source chain (Unichain)
• Step 3: Single required DVN (LayerZero Labs) signed attestation for the non-existent packet
• Step 4: No optional DVNs or threshold to challenge the fraudulent attestation
• Step 5: Message passed verification: commitVerification → lzReceive → peer check → OFT decode → rsETH mint
• Result: 116,500 rsETH materialized on Ethereum with no corresponding lock on source chain

Root cause: Not a LayerZero protocol bug — a configuration failure. KelpDAO chose a 1/1 DVN setup, the cross-chain equivalent of a 1-of-1 multisig on a treasury. LayerZero V2 is modular by design; projects pick their own X-of-Y-of-N security stack. The protocol provided the toolkit; KelpDAO failed to use it.

• Attacker gained access to executive team devices (likely via phishing email)
• Transferred stake authorization from Step’s treasury wallets to attacker-controlled address
• Unstaked 261,854 SOL (requires direct wallet permissions on Solana)
• Withdrew all SOL to attacker wallet in single transaction
• Bridge-hopped funds via THORChain to Bitcoin (66.77 BTC parked in 4 wallets)
• Step recovered $4.7M via Token22 protections on Remora assets

Root cause: Weak key management with insufficient access controls. No multi-sig requirement for treasury operations. Single points of failure in signing authority. No monitoring/offline alerting during APAC hours when attack occurred.

• Target: 5-year-old contract with unverified bytecode (Solidity v0.5.3)
• Attacker reverse-engineered bytecode to find overflow vulnerability
• Called getPurchasePrice() with absurdly large mint amounts
• Unprotected addition overflowed, wrapping to near-zero
• Cost to mint 240M TRU: essentially zero ETH
• Burned tokens for ETH at 12.5% buyback rate (bonding curve mechanic)
• Five iterations in single transaction extracted 8,535 ETH

Root cause: Pre-Solidity 0.8.x compiler without automatic overflow protection. Unverified bytecode meant no community audit. Contract sat dormant for 5 years — a “relic hunter” target. No supply cap or per-transaction limits.

• USTRY/USDC market on SDEX had <$1 in hourly volume, effectively a ghost town
• Attacker placed sell offer for 1.2 USTRY at 107 USDC (100x real price)
• Bought 0.05 USTRY against their own offer — that 50¢ trade became the VWAP
• Reflector oracle reported $106.74 (poisoned) vs real $1.06
• Deposited 153K USTRY (~$160K real) as collateral worth $16M per oracle
• Borrowed 1M USDC + 61M XLM against inflated collateral
• No circuit breaker fired; no deviation check; no staleness flag on dead market

Root cause: Four stacked failures: (1) Illiquid collateral listed without liquidity thresholds, (2) Single-source VWAP oracle with no median/deviation checks, (3) Oracle adapter passed raw last price without validation, (4) No circuit breakers for dead markets. Auditors checked contract logic but never scoped the economic reality of the collateral market.

• Attacker compromised validator owner EOA (0x6dd...148e) after 6-18 months of reconnaissance
• Called upgrade() on TransferValidatorWithPayload contract
• Deployed malicious contract with all validation checks stripped
• No multisig, no timelock, no second signature required for upgrade
• With ownership secured, transferred TokenSafe and MinterPool control
• Drained 9 tokens from reserves: USDC, USDT, WBTC, WETH, IOTX, DAI, PAXG, BUSD, UNI
• Minted 821M CIOTX across 10 transactions via MinterPool

Root cause: Single EOA held unchecked upgrade authority over contracts custodying millions. No multisig requirement, no timelock, no circuit breaker. Architecture assumed the key would never be compromised. IIP-55 (decentralized validator set) was drafted in December 2025 — two months before the hack — but not prioritized until after the vault emptied.

• Contract used doSafeTransferIn() to receive NFT deposits during minting
• This triggered onERC721Received callback in attacker’s contract
• Callback minted BRO tokens BEFORE execution returned to original mint()
• Original mint() then minted BRO tokens again
• Same deposit minted twice (double-mint)
• Attacker started with 135 BRO, ended with 567 million BRO after 22 loops
• Swapped BRO for 38.05 SolvBTC (~$2.73M), exited via Tornado Cash

Root cause: Missing reentrancy guard and improper ordering of state updates vs. external calls. The BRO contract was unaudited and explicitly excluded from bug bounty coverage (which only covered Web2 infrastructure and Solana contracts). Security theater: five audits on other contracts created false confidence while the new product shipped without review.

• Supply cap enforced only in mint() function, not in direct transfer()
• Attacker accumulated 84% of supply cap via normal deposits (12.2M THE)
• Transferred 49.5M THE directly to vTHE contract (bypassing cap)
• Exchange rate inflated 3.81x because contract balance increased without new vTokens minted
• Same position now represented $12M+ in collateral vs original $3.3M
• Borrowed against inflated collateral in recursive loop
• Pumped THE price via buy pressure, borrowed more as oracle caught up
• Got greedy, liquidation triggered, $30M nominal collateral → $0

Root cause: Supply cap only checked in mint(), bypassable via direct ERC-20 transfers. Code4rena flagged this in May 2023 as M-10; Venus dismissed as “supported behavior with no negative side effects.” February 2025 exploit on ZKSync deployment (same vector) was not patched on BNB Chain. This is the 4th Venus exploit in 5 years — institutional memory failure.

• Attacker compromised infrastructure access (likely via phishing/social engineering)
• Gained control of SERVICE_ROLE key with unilateral mint authority
• No multi-sig requirement on mint function — single key could mint unlimited supply
• No circuit breaker to auto-pause when mint volume exceeded thresholds
• No anomaly detection on mint rate (historical avg vs. attack volume)
• Minted ~$80M in tokens before manual intervention stopped the drain

Root cause: Single point of failure in key management (no SERVICE_ROLE redundancy) combined with complete absence of circuit breakers. The protocol relied entirely on manual monitoring and response, which was too slow to prevent massive dilution.

• CAPO initialized in 2024 with snapshotRatio of ~1.15 for wstETH/stETH
• Off-chain engine computed correct update: snapshotRatio ~1.2282, timestamp 7 days ago
• On-chain rate limiter capped single updates at 3% per 3 days
• Ratio could only update to ~1.1919, but timestamp updated to 7 days ago
• Formula extrapolated from wrong base: computed ceiling ~1.1939 vs market ~1.2285
• Aave priced wstETH 2.85% below actual value
• E-Mode (high leverage) positions liquidated despite being healthy in real markets
• Similar misconfiguration nearly triggered a month earlier but agent wasn’t connected

Root cause: Configuration mismatch between snapshotRatio and snapshotTimestamp parameters. Rate limiter prevented correction as effectively as it prevented manipulation. Stale 2024 anchor couldn’t catch up to two years of yield growth. Near-miss a month earlier wasn’t investigated thoroughly — institutional memory failure.