May 2026 Protocol Engineering Recap

TLDR

  • Glamsterdam Integration: Ethereum’s May protocol update reports a multi-client Glamsterdam devnet, an external-builder ePBS pipeline tested across nearly all clients, and a 200M gas limit floor -> treat Glamsterdam as an integration and operations program, not just a research roadmap item.
  • ePBS Relay-Risk Refactor: EIP-7732 separates consensus and execution responsibilities and introduces a Payload Timeliness Committee, while ethereum.org frames ePBS as a way to remove reliance on third-party relays such as MEV-Boost -> staking teams should test payload withholding, builder payment, and timing edge cases before mainnet activation.
  • Block-Level Access Lists Move Parallelism Into The Block Format: EIP-7928 records account and storage accesses at block level, enabling parallel disk reads, parallel validation, and executionless sync patterns -> execution-client and L2 teams should test database, tracing, and proof-system assumptions against BAL-enabled blocks.
  • Ethereum Clients Are Shipping Fork-Readiness Fixes: Geth v1.17.3 prepared Amsterdam EIPs and ETH/70, Nethermind v1.37.2 fixed health/archive issues and disabled ParallelWorldState, and Erigon v3.4.1 fixed a commitment-layer segfault -> node operators should stage these releases in fork-simulation and archive-node environments before production rollout.
  • L2s Are Already Absorbing L1 Fork Surface Area: OP Stack/Kona releases referenced Glamsterdam-related FPVM work, Arbitrum Nitro shipped security and stability fixes around ArbOS upgrades, and zkSync Era advanced Airbender proof support -> rollup operators should budget L1-fork compatibility work before Glamsterdam activation.
  • Solana’s Primary Evidence Supports A Gradual Firedancer Path: Official GitHub releases verify May Frankendancer mainnet-ready releases, while secondary reporting says Firedancer was producing blocks on mainnet, official primary pages scanned did not expose validator-share or block-production metrics -> describe the rollout as gradual and metric-limited unless official dashboards are available.
  • Alpenglow Remains Pending, Not Activated: Solana’s network-upgrades page marks Alpenglow as under development, expected in Agave 4.1, and targets 150ms finality, the same page tracks SIMDs including 123, 286, 296, and 268 -> validators should follow version gates rather than assume consensus changes are live.
  • Developer Tooling Shifted Security Left: Foundry May nightlies added lints for reentrancy-events, unprotected-initializer, arbitrary-send-erc20, weak-prng, delegatecall-loop, and return-bomb, Hardhat v3.7.0 dropped the beta designation -> Solidity teams should run May-era lints and Solidity tests in CI, not only in pre-audit cleanup.
  • TEE Privacy Is Useful But Boundary-Limited: Oasis Sapphire documents encrypted confidential contracts, Flashbots Sirrah demonstrates a TEE coprocessor pattern, and Secret Network grant discussion highlights access-pattern leakage in TEE-based smart contracts -> use TEEs with explicit remote-attestation, metadata-leakage, and RPC/mempool threat models.
  • May Exploits Repeated Authorization Failures: BlockSec’s May reports identify authorization mismatch, missing canonical wallet verification, arbitrary calldata execution, and spot-price manipulation as root causes -> audits should prioritize authorization-key consistency, canonical asset verification, stale-contract decommissioning, and manipulation-resistant price references.

Ethereum L1: Glamsterdam Enters Integration Risk Territory

The main Ethereum signal in May was not a new whitepaper. It was the movement of Glamsterdam from specification gravity toward multi-client integration. The Ethereum Foundation’s May protocol update says the Svalbard core-developer interop focused on hardening and preparing Glamsterdam, with ePBS stabilized on a multi-client Glamsterdam devnet and an external-builder pipeline tested end-to-end across nearly all clients. The same update records a 200M gas limit floor, which matters because Glamsterdam’s scaling strategy only becomes useful if execution clients, consensus clients, builders, and L2 stacks can survive higher-throughput assumptions.

The ethereum.org roadmap page still frames Glamsterdam as an upcoming upgrade planned for H1 2026 and describes it as a scaling step that combines execution-layer Amsterdam work with consensus-layer Gloas work. As of the sources scanned for this recap, I found devnet and release-readiness evidence, but no primary source confirming May 2026 mainnet activation. The ethPandaOps Glamsterdam devnet repository is therefore the best operational artifact: it lists devnet-3 as active while earlier devnets are inactive, and it contains infrastructure for assigning validator ranges across client pairs.

The technical center of gravity is EIP-7732. The EIP separates the Ethereum block into consensus and execution components and adds a mechanism for a consensus proposer to choose an execution proposer. It also introduces the Payload Timeliness Committee, which attests to whether a builder revealed a payload on time and supports protocol-native builder payments. Ethereum.org states that ePBS removes dependence on third-party relays such as MEV-Boost and expands the data propagation window from 2 seconds to approximately 9 seconds, which is why ePBS is a scaling primitive as much as a MEV-market refactor.

The hard part is not only correctness under honest behavior. EIP-7732 explicitly discusses the free-option problem, where a builder may rationally withhold a payload, and it also discusses risks around malicious PTC behavior causing split views of payload availability. This is the case study for May: the same mechanism that removes external relay trust also imports new timing, payment, and payload-availability edge cases into the protocol. That trade is probably worthwhile, but only if devnets stress builders, proposers, PTC members, and clients under adversarial timing.

EIP-7928 is the second Glamsterdam primitive to watch. It defines Block-Level Access Lists that record all accounts and storage locations accessed during block execution. Ethereum.org describes the effect as removing sequential processing bottlenecks by giving clients an upfront dependency map, enabling parallel disk reads, parallel transaction validation, and executionless sync. EIP-7928 also discusses defenses against denial-of-service patterns using phantom storage reads, including feasibility checks at transaction boundaries.

Decision-ready insight: Ethereum teams should treat May as the month Glamsterdam became an end-to-end integration problem. The critical work is now adversarial devnet coverage for ePBS timing and database/proof-system testing for BAL-enabled execution.

Ethereum Clients And L2s: Fork Readiness Moves Downstream

Ethereum’s May client releases show a pattern: Amsterdam/Glamsterdam readiness is being embedded in ordinary maintenance releases rather than waiting for a single fork client drop. That matters for operators because release notes now mix future-fork logic, peer-handling changes, archive-node fixes, and crash fixes.

Layer

Release

May 2026 technical signal

Operational implication

Geth

v1.17.3, May 11

Prepared Amsterdam fork prerequisites for EIP-7928, EIP-8037, and EIP-7610, introduced ETH/70, included txpool concurrency and gas-calculation improvements, changed debug_trace* response fields and added MaxUsedGas to eth_simulate

Test tracing, simulation, peer-disconnect, and fork-config behavior before production rollout

Nethermind

v1.37.2, May 5

Fixed healthcheck and archive invalid-block issues, disabled ParallelWorldState

Prefer execution consistency over experimental parallelism in production archive and validator setups

Erigon

v3.4.1, May 11

Fixed a commitment-stage segfault caused by a branch slice returned by TrieContext.Branch

Prioritize crash-resistance in commitment and archive workflows

The L2 surface area tells the same story. OP Stack releases in May included op-proposer/v1.16.3 for future interop preparation and an op-geth dependency bump, kona-host/v1.5.2 with defense-in-depth verification of preimage bytes, and kona-client/v1.5.2, which bumps FPVM precompile oracle gas for Glamsterdam-related EIP-7904 and is required before Glamsterdam activates on L1. This is a concrete case study in downstream fork propagation: an L1 gas/precompile change can affect the fault-proof VM and therefore needs to be handled before the L1 fork, not after it.

Arbitrum’s May Nitro releases were more explicitly operational. Nitro v3.10.1 on May 19 included a configuration option for legacy zero base fees and fixed a BoLD staking bug, while v3.10.0 on May 11 shipped stability improvements and security fixes and was recommended before ArbOS 60-rc.5 activated on Arbitrum Sepolia on May 18. Arbitrum’s ArbOS documentation, updated May 22, emphasizes that ArbOS upgrades are equivalent to hard forks and require validator-node updates.

zkSync Era’s May releases point toward proof-system evolution. core: v29.19.0 on May 26 added snark proofs for Airbender and fixed missing call traces in debug_traceBlockByNumber, core: v29.18.0 implemented eth_fillTransaction, and core: v29.17.0 introduced Airbender commitment-variant work and support for the Era v29 to v31 upgrade path. The practical message is that L2 client teams are not just following L1 upgrades. They are simultaneously changing proof generation, tracing APIs, and upgrade automation.

Decision-ready insight: L2 operators should maintain a fork-readiness checklist that includes L1 precompile/gas changes, proof-VM compatibility, validator upgrade windows, tracing API diffs, and archive-node regression tests.

Solana: Agave 4.0, Frankendancer, And Alpenglow’s Pending Cutover

Solana’s May signal is best read as controlled client evolution. The official Agave release page shows Agave v4.0.0 released on May 16, and the Agave v4.0 changelog documents breaking changes, including removal of UDP support for transaction ingestion. The Solana network-upgrades page separately tracks roadmap items and warns that version numbers and timelines are subject to change.

Solana item

May 2026 or roadmap status

Engineering read

Agave

v4.0.0 released May 16

Validator operators need to review v4.0 breaking changes, including transaction-ingestion transport changes

Frankendancer

v0.910.40000 released May 21 and marked mainnet-ready, upgraded Agave submodule to v4.0.0

Firedancer rollout is being staged through a hybrid Agave plus Firedancer path

Firedancer architecture

Jump describes Firedancer as a new Solana validator client written in C and built for performance, Jump also describes Frankendancer as an intermediate client combining Agave and Firedancer components

Client diversity is the resilience objective, full migration should be measured by validator adoption and block-production share

Firedancer rollout metrics

Secondary reporting says Firedancer was producing blocks on mainnet in May, primary GitHub pages verify mainnet-ready releases but did not provide official validator-share or block-count metrics in the scanned sources

Treat May as gradual rollout evidence, not proof of full-client saturation

Alpenglow

Under development, expected by Agave 4.1, with 150ms target finality

Do not assume activation, track SIMD and Agave version gates

100M CUs

Expected by Agave 4.1 through SIMD-286, page describes a 66% compute-unit boost

Application teams should profile programs under higher per-block compute assumptions

Rent reduction

Expected by Agave 4.0, page describes up to 90% reduction

State-heavy applications should re-check account-cost models after activation

Vote Account V4

Under development and expected by Agave 3.1

Validator tooling should track account-layout and vote-account changes

The key case study is Frankendancer. Full Firedancer is strategically important because an independent C-based validator reduces correlated Rust-client risk, but the May primary artifacts show a hybrid client path: Frankendancer releases, Agave submodule bumps, and mainnet-ready labels. That is not a weakness. It is how high-risk validator-client replacement should work: narrow the blast radius, integrate incrementally, and expose the networking and block-production path before broader validator adoption.

Alpenglow is the other major Solana item, but the verified status remains pending. The network-upgrades page marks Alpenglow as under development and expected in Agave 4.1, and it groups related SIMDs including 123, 286, 296, and 268. The most important engineering distinction is between a roadmap target and a live consensus rule. Alpenglow’s 150ms target finality is a design and release-planning signal until official activation sources say otherwise.

Decision-ready insight: Solana validators should separate three workstreams: Agave v4.0 upgrade testing, Frankendancer canary evaluation, and Alpenglow/SIMD readiness. Mixing them into a single narrative of “Firedancer is live” hides the operational risk that matters most.

Smart Contract Engineering: Toolchains Push Security Checks Into CI

May’s smart-contract tooling theme was not a single new analyzer. It was the continued migration of security review from manual audit checklists into developer workflows. Foundry’s May nightlies are the clearest example: the May 20 release added lints such as weak-prng, delegatecall-loop, and return-bomb, the May 26 release added reentrancy-events, unprotected-initializer, and arbitrary-send-erc20, and the May 27 release added configurable collision-free EVM edge coverage.

Hardhat crossed a different threshold. Hardhat v3.7.0 on May 28 removed the beta designation from its initialization process, v3.6.0 on May 26 revamped Solidity hooks and added AGENTS.md files for AI-assisted development workflows, and v3.5.0 on May 20 added EIP-712 cheatcode support in Solidity tests and updated project templates to TypeScript 6. This matters because EIP-712 signing bugs remain a recurring source of authorization failures, adding cheatcodes to Solidity tests helps developers generate and test typed-data flows in the same environment as contract logic.

Tool

May 2026 signal

Security engineering implication

Foundry

New lints for reentrancy events, unprotected initializers, arbitrary ERC-20 sends, weak PRNG, delegatecall loops, and return bombs

CI can catch more audit-class bugs before external review

Foundry

Configurable collision-free EVM edge coverage

Fuzzing campaigns can measure path coverage with fewer coverage collisions

Hardhat

v3.7.0 removed beta designation, v3.5.0 added EIP-712 cheatcodes in Solidity tests

Teams can standardize Hardhat v3 for typed-data and Solidity-native testing flows

Slither

No May release was visible in the extracted release page, latest visible release was 0.11.5 from January

Keep Slither in CI, but do not treat May as a new Slither capability month

OpenZeppelin Contracts

No May release was visible in the extracted release page, latest visible version was v5.6.1 from February

Dependency pinning remains the main action, not migration to a new May release

Halmos

No May release was visible in the extracted release page

Formal-verification users should track later releases separately

The case study is Foundry’s lint expansion. unprotected-initializer and arbitrary-send-erc20 are not abstract style checks. They map directly to upgradeable-contract takeover and asset-transfer bugs. delegatecall-loop and return-bomb target execution-flow and gas griefing patterns that are difficult to reason about in review-only settings. The move from auditor memory to repeatable linting is the difference between a one-time audit finding and an always-on regression guard.

Decision-ready insight: contract teams should add May-era Foundry lints, Hardhat Solidity tests, typed-data fixtures, and coverage thresholds to pull-request gates. Treat these as build failures, not advisory warnings.

TEE Privacy Architectures: Confidential Execution Without Magical Confidentiality

TEE-based privacy work matters because public-chain confidentiality is no longer only about zero-knowledge proofs. Oasis documentation, updated May 7, describes a permissionless network of nodes that can power verifiable, auditable applications using TEEs. Chainstack’s Oasis Sapphire tutorial describes Sapphire as a confidential smart-contract environment in which transaction data and contract state remain encrypted while execution occurs through a ParaTime model and secure enclaves.

Flashbots Sirrah provides a different architectural case study. It is not presented as a May 2026 production release, it is a technical demo, published in 2024, of extending a blockchain with a TEE coprocessor for confidential computing. That distinction matters. Oasis Sapphire is a confidential-contract platform pattern, while Sirrah is a coprocessor pattern that shows how confidential execution can sit beside, rather than fully replace, base-chain execution.

Architecture

Confidentiality mechanism

Trust and leakage boundary

Developer implication

Oasis Sapphire

Encrypted transaction data and contract state in a TEE-backed ParaTime execution environment

Developers still rely on enclave security, RPC path handling, key management, and the platform’s attestation model

Use for EVM-compatible confidential contracts, but threat-model metadata and integration endpoints

Flashbots Sirrah

TEE coprocessor pattern for confidential computation connected to blockchain execution

Demonstrates architecture, not a general proof that all application metadata is hidden

Useful for designing off-chain confidential execution modules and MEV-aware privacy systems

Secret Network TEE rollups discussion

Identifies access-pattern leakage in TEE-based smart contracts, including token-transfer receiver privacy concerns

Even encrypted state can leak through which storage paths, accounts, or receivers are touched

Build privacy systems that hide or batch access patterns, not only values

The non-obvious lesson is that TEEs change the trust boundary rather than eliminating it. A confidential contract can protect values inside an enclave, but transaction origin, access pattern, receiver identity, or bridge/RPC metadata can still leak if the surrounding protocol exposes it. The Secret grant discussion makes this concrete by treating access-pattern leakage as a first-class privacy bug in TEE-based smart contracts.

Decision-ready insight: if a team uses TEEs for privacy, the security spec should include remote attestation, encrypted input handling, key rotation, side-channel assumptions, access-pattern leakage, and RPC/mempool metadata. “Runs in a TEE” is not a complete privacy argument.

Security Post-Mortems: Authorization Remains The May Failure Mode

The May incident pattern is repetitive in a useful way. The strongest technical reports point to authorization and validation failures rather than exotic cryptography. BlockSec’s May 10 and May 17 reports identify multiple cases where the contract accepted the wrong actor, the wrong wallet, the wrong calldata, or the wrong price reference.

Incident

Date in source

Root cause

Exploit mechanism

Engineering lesson

Trusted Volumes

May 7

Authorization mismatch in an RFQ order-fill function

Signer permission lookup referenced one order field while token transfer debited another, allowing forged orders to debit the protocol as maker

The identity that authorizes must be the same identity whose funds move

TAC

May 12

Missing canonical wallet verification in TON-side jetton deposit flow

Bridge accepted JettonNotify messages from a non-canonical wallet and treated fake deposits as valid

Derive and verify canonical token wallet addresses before cross-chain minting

Transit Finance

May 12

Arbitrary calldata execution in a legacy TransitMixSwapBridge contract plus persistent unlimited approvals

Attacker forwarded crafted calldata to invoke USDT.transferFrom() through an approval contract

Deprecated contracts must be fully decommissioned, and forwarding paths must validate target and selector

Boost Hook

May 13

Spot-price manipulation through direct use of Uniswap V4 slot0 as entry price

Attacker manipulated spot price with a flash loan and repeatedly opened positions against inflated pricing

Use manipulation-resistant references such as TWAPs, not instantaneous pool state, for leveraged entry logic

CrossCurve

May postmortem source

Missing access-control check in a cross-chain receiver path

Publicly callable receiver logic allowed unauthorized cross-chain message handling

Cross-chain receivers need explicit authorization, replay protection, and endpoint validation

The case study to internalize is Trusted Volumes. The bug was not that signatures were absent. It was that authorization checked one identity while asset movement used another. That is more dangerous than a missing onlyOwner modifier because it can pass superficial checks: the protocol appears to verify a permitted signer, but the check is not bound to the asset-paying party.

TAC shows the same class of bug across a bridge boundary. The TON-side bridge accepted a deposit notification without verifying that the sender was the canonical wallet derived from the official jetton master. The lesson is not “bridges are risky” in general. The actionable lesson is that every cross-chain mint must bind message source, asset identity, owner, and canonical wallet derivation into a single verification invariant.

Decision-ready insight: May’s postmortems should update audit checklists in four places: authorization key consistency, canonical cross-chain asset verification, stale approval and deprecated-contract cleanup, and price-oracle manipulation resistance.

May 2026 Web3 Hack Ledger: What Failed And How To Avoid A Repeat

To avoid mixing April postmortems with May incidents, this ledger uses DefiLlama’s hacks database filtered to May 1-31, 2026 as the incident spine, then cross-checks larger, ambiguous, or missing rows against BlockSec, Recoveris, Phemex, Crypto Briefing, Rekt, BeInCrypto, Cryptopolitan, and other incident reports. The DefiLlama rows for May sum to approximately $59.5M in listed losses, TAC, Boost Hook, and Huma Finance are added from the source-confirmed incident reports because they were covered in the May research set but did not appear in the filtered DefiLlama API rows. Some reports quote larger notional exposure for incidents such as Echo Protocol and StablR because attackers minted unbacked assets that could not all be cashed out, those cases are separated below as realized loss versus notional minted supply.

Date

Incident

Listed loss

Main failure mode

05-01

Bisq

$858K

Fake Bisq V1 client hack

05-01

Sharwa.Finance

$32.85K

Oracle price manipulation

05-04

SmartCredit

$72K

Flash-loan exploit

05-05

Ekubo

$1.4M

Improper access control in router/payment callback logic

05-07

TrustedVolumes

$6.7M on DefiLlama, ~$5.87M in BlockSec

Forged RFQ orders and authorization mismatch

05-10

Renegade

$209K

Unprotected initializer in dark-pool proxy deployment

05-11

INK Finance

$140K

Whitelisted-address impersonation / missing access control

05-11

Huma Finance

~$101.4K

Deprecated V1 BaseCreditPool credit-lifecycle flaw

05-12

Aurellion

$456K

Uninitialized proxy exploit

05-12

SQ Protocol

$346K

Access-control exploit

05-12

TAC

~$2.8M

Missing canonical TON jetton wallet verification

05-13

Transit Finance

$1.88M

Deprecated smart-contract exploit and arbitrary calldata path

05-13

Boost Hook

~$46.75K

Uniswap V4 spot-price manipulation

05-15

Thorchain DEX

$10M-$10.8M

Vault churn address poisoning / infrastructure-side validation failure

05-16

Adshares

$628K

Bridge verification bypass

05-17

SEA Token

$153K

Flash-loan price manipulation

05-17

Verus-Ethereum Bridge

$11.5M-$11.7M

Bridge verification bypass / source-destination value mismatch

05-18

Echo Bridge / Echo Protocol

~$821K realized, ~$76.6M notional eBTC minted

Admin/private-key compromise enabling unauthorized eBTC minting

05-19

Bankr

$170K

Compromised session keys

05-19

HermesVault

$30K

Algorand rekeying attack

05-20

MAP Protocol

$110K

Infinite mint and dump

05-20

RetoSwap

$2.7M

ACK-message frontrun / arbitrator hijack in P2P flow

05-22

Polymarket

$700K

Private-key compromise

05-23

Mure

$11.7K

Access-control exploit

05-23

StablR

$2.8M realized, ~$13.5M unbacked stablecoins minted in external reports

Private-key or multisig-control compromise

2026-05-24

Fractal Protocol

$13.7K

Flash-loan price manipulation

05-25

New Market Trading

$3.98M

Access-control failure in a Safe module

05-25

WUSD.fi/Glove

$200K

Sybil abuse

05-27

Stake DAO

$91K

Private-key compromise

05-28

DxSale

$7.3M

Ownership override / legacy locker backdoor

2026-05-30

Alephium Bridge

$815K

Guardian/private-key compromise and forged bridge messages

05-30

Gravity Bridge

$5.4M

Bridge signing-key compromise

Bisq: The fake-client incident could have been avoided with stronger release-channel integrity: signed and reproducible binaries, in-app update verification, explicit checksum verification in user flows, and rapid takedown monitoring for lookalike distribution paths. For user-facing crypto software, the client binary is part of the custody boundary, if attackers can replace the client, the protocol’s on-chain guarantees no longer protect the user.

Sharwa.Finance: The oracle-price manipulation row points to the usual thin-liquidity problem: a protocol trusted a price that could be moved faster than the protocol could defend. This class is avoidable with TWAPs or medianized oracle sources, liquidity-depth checks, per-block price-change caps, and tests that simulate flash-loan scale trades against the exact markets used for valuation.

SmartCredit: Flash-loan exploits are usually symptoms of state accounting that assumes capital is sticky inside one transaction. The prevention pattern is to snapshot balances before sensitive actions, use debt/share invariants rather than raw spot balances, add same-block manipulation tests, and reject state transitions that only work because borrowed liquidity appears for a single call path.

Ekubo: Phemex and Recoveris describe a custom router/extension path where payment callback authorization failed to prove that the payer was the lock initiator or an authorized payer. This could have been avoided by binding callbacks to a nonce-scoped lock context, checking payer authority inside the extension contract, minimizing long-lived ERC-20 allowances, and shipping router upgrades with approval-revocation guidance before activation.

TrustedVolumes: BlockSec’s analysis describes an RFQ authorization mismatch where the signer permission check and the transfer source referred to different order fields. The avoidable invariant is simple and strict: the signer, maker, transfer source, token owner, and replay domain must be bound in the same signed object, with tests that intentionally permute those fields and prove settlement reverts.

Renegade: The Renegade loss came from a deployment-level mistake: an initializer or owner path that stayed open on a legacy Arbitrum dark-pool proxy. This could have been prevented with deployment scripts that initialize and lock proxies atomically, automated scanners for uninitialized implementations, explicit owner assignment checks, and a post-deploy invariant that no public caller can rewrite implementation or resolver logic.

INK Finance: INK Finance was drained after whitelist or claimer logic let an attacker impersonate an authorized claimant. The fix is not only adding onlyRole to one function, the safer design is a canonical allowlist root or signed claim scheme, role-gated list mutation, per-drop amount caps, and negative tests showing that arbitrary contracts cannot register themselves for treasury claims.

Huma Finance: Huma Finance disclosed that deprecated V1 BaseCreditPool contracts on Polygon were exploited through a credit-lifecycle logic flaw, while user deposits and the newer Solana V2 system were unaffected. This should have been avoided by fully sunsetting legacy pools, removing residual fees from old contracts, adding access-control tests around drawdown state transitions, and treating deprecated deployments as active risk until every balance and approval is drained or revoked.

Aurellion: DefiLlama classifies Aurellion as an uninitialized proxy exploit, the same avoidable deployment class as many upgradeable-contract takeovers. Teams can prevent it by disabling initializers on implementations, initializing proxies in the same transaction that deploys them, monitoring for Initialized events, and treating any externally callable initializer on production contracts as a release blocker.

SQ Protocol: The SQ Protocol entry is an access-control exploit, which means the core failure was an unauthorized actor reaching a privileged state transition. The practical prevention path is complete role mapping, tests for every privileged function from a non-privileged caller, explicit admin-transfer workflows, and monitoring that alerts when sensitive functions are invoked outside expected operational windows.

TAC: TAC’s bridge accepted TON-side jetton deposit notifications without verifying that the sender was the canonical token wallet derived from the official jetton master. This could have been avoided by deriving the expected wallet address on-chain or in a verified bridge module, binding asset identity to the source wallet, rejecting non-canonical notification senders, and testing fake-deposit messages before cross-chain minting went live.

Transit Finance: BlockSec and Web3 is Going Great describe a legacy TRON swap-bridge contract that could still move funds from users who had never revoked approvals. This should have been avoided by fully decommissioning deprecated contracts, revoking or invalidating old approval paths where possible, enforcing target-and-selector allowlists on forwarding logic, and maintaining a public retirement checklist for every obsolete contract.

Boost Hook: Boost Hook was exploited through direct use of Uniswap V4 slot0 spot price as an entry reference for leveraged positions. This could have been avoided by using a TWAP or another manipulation-resistant price reference, enforcing price-deviation limits around position entry, and testing the hook against flash-loan-driven pool manipulation before allowing repeated leveraged opens.

Thorchain DEX: The THORChain incident was reported as a vault-churn or TSS-adjacent validation failure rather than a simple Solidity bug. Avoidance here means treating validator churn, vault address derivation, and threshold-signature membership as consensus-critical surfaces: require independent verification of new vault addresses, delay high-value outbound flows after churn, and run anomaly detectors that can pause signing before funds leave multiple chains.

Adshares: The Adshares bridge-verification bypass belongs to the same family as many cross-chain failures: destination-chain release logic accepted a message without enough source-chain proof. Prevention requires binding source chain, source amount, token identity, recipient, nonce, and finality proof into one verified message, then testing forged, replayed, partial, and type-confused bridge messages before mainnet liquidity is connected.

SEA Token: SEA Token’s flash-loan price manipulation could have been avoided by refusing to use a manipulable same-block AMM spot price for sensitive accounting. Protocols should prefer time-weighted or externally aggregated price feeds, enforce minimum liquidity and maximum price-impact bounds, and fuzz liquidation, mint, burn, and reward paths under adversarial reserve changes.

Verus-Ethereum Bridge: BlockSec and Recoveris both frame Verus as a bridge validation failure where destination-side value release was not tightly matched to the source-side event. This class is avoidable with source-destination value equality checks, strict message-type validation, multi-client proof verification, conservative rate limits, and emergency pause automation for any bridge message that releases assets without a matching burn or lock.

Echo Bridge / Echo Protocol: Echo’s headline looked like a ~$76.6M unauthorized eBTC mint, but several sources note that the realized extraction was closer to ~$816K because the attacker could not cash out the full fake supply. The root prevention is privileged mint hardening: no single admin key should grant mint authority, mint roles should sit behind multisig or MPC plus timelock, supply caps should halt impossible issuance, and bridge deployments should have isolated pause controls per chain.

Bankr: DefiLlama classifies Bankr as a compromised-session-key incident. Session keys should be treated as hot-wallet credentials with blast-radius limits: scoped permissions, short expirations, per-session spend caps, user-visible revocation, device binding, and server-side anomaly detection for actions that exceed normal agent or wallet behavior.

HermesVault: HermesVault’s Algorand rekeying attack highlights an account-model edge case that EVM-centric audits often miss. Avoidance requires explicit checks on authorized addresses after rekeying, transaction-group simulations that include malicious rekey operations, and wallet/protocol UX that warns users before they delegate signing authority in ways that let an attacker move assets later.

MAP Protocol: Infinite-mint-and-dump attacks are preventable with supply invariants that are enforced both in code and tests. Any mint path should have a clear authority, a cap or backing check, event monitoring, and a property test that total supply cannot increase without the corresponding locked asset, burned asset, governance action, or verified cross-chain message.

RetoSwap: BlockSec describes RetoSwap as a P2P-flow authentication failure where a forged ACK message let the attacker hijack the arbitrator role. This could have been avoided by signing every state transition with the expected participant keys, binding ACK messages to session IDs and nonces, rejecting role changes after trade initialization, and testing network-level message ordering and frontrun scenarios.

Polymarket: DefiLlama and BlockSec classify the Polymarket incident as a private-key compromise. The prevention playbook is operational rather than exotic: HSM or MPC custody for privileged keys, least-privilege contract roles, delayed withdrawals from admin-controlled addresses, key rotation drills, and alerts on new signer activity or unexpected high-value transfers.

Mure: Mure’s access-control exploit is the small-dollar version of a large-dollar pattern. Teams can avoid it by building an authorization matrix before deployment, requiring tests for unauthorized callers on every mutating function, avoiding default-open admin paths, and running static analyzers that flag public or external functions touching privileged state.

StablR: StablR reports are easiest to misread: external reporting describes roughly $13.5M in unbacked stablecoins minted, while DefiLlama lists a lower realized loss around $2.8M. The avoidable failure was issuer-control fragility: stablecoin minting should require a real multisig threshold, separation between mint and upgrade authority, per-epoch mint caps, real-time backing checks, and an emergency freeze process that is rehearsed before assets trade broadly.

Fractal Protocol: Fractal Protocol’s flash-loan price manipulation is avoidable with the same market-design discipline as SEA Token: do not let one-block liquidity define collateral, rewards, or redemption value. Add TWAPs, liquidity floors, oracle deviation checks, and tests that combine flash loans with the exact user flows that move value out of the protocol.

New Market Trading: Rekt’s writeup describes funds drained from many Gnosis Safes through a third-party module, which is a reminder that Safe modules are effectively wallet-level code execution permissions. This could have been avoided by auditing every enabled module, setting module allowlists and expiration dates, revoking stale module permissions, and requiring clients to approve module changes with the same seriousness as signer changes.

WUSD.fi/Glove: A Sybil-abuse loss usually means an incentive or claim system treated many attacker-controlled identities as independent users. Avoidance requires rate limits, stake or time-weighted eligibility, anti-Sybil scoring, per-entity reward caps, and pre-launch simulations where one actor controls thousands of wallets and tries to maximize extraction.

Stake DAO: DefiLlama classifies Stake DAO as a private-key compromise, which is almost always a process failure as much as a cryptographic one. Teams should use MPC or hardware-backed signing for treasury and strategy keys, enforce role-scoped keys instead of god-mode operators, monitor signing hosts, and maintain an incident runbook for immediate revocation and contract pausing.

DxSale: DxSale’s late-May exploit reportedly hit old BNB Chain liquidity lockers through an ownership override or hidden-backdoor pattern. The avoidable lesson is that legacy lockers must be verifiably immutable or explicitly sunset: ownership should be renounced or timelocked, code should be verified, backdoor-capable functions should not exist, and abandoned pools should have a migration path before old contracts become forgotten honeypots.

Alephium Bridge: Alephium’s TokenBridge was drained after forged bridge messages passed guardian validation, with reports pointing to compromised guardian keys and 13.76M unbacked wrapped ALPH minted. This could have been avoided with stronger guardian independence, hardware-backed key custody, threshold designs that do not concentrate compromise risk, per-message rate limits, and bridge monitors that halt minting when wrapped supply diverges from locked backing.

Gravity Bridge: Gravity Bridge was drained through what several reports describe as a bridge signing-key compromise rather than a contract-code bug. Prevention means validators and orchestrators need hardened signing environments, key rotation and compromise drills, transfer limits, independent co-signing checks, and automatic halts when signer behavior deviates from normal bridge flow.

Decision-ready insight: May’s Web3 hacks were not one category of bug. They clustered around five repeated control failures: bridge-message validation, privileged-key custody, legacy-contract decommissioning, proxy/initializer hygiene, and manipulable price or identity assumptions. A May-ready security program would turn those five controls into CI tests, deployment gates, monitoring rules, and incident drills.

Synthesis: Three Ecosystems Converged On Execution-Path Control

The May recap has one cross-cutting theme: each ecosystem is trying to control a different execution path. Ethereum is moving block construction and block validation deeper into protocol rules through ePBS and Block-Level Access Lists. Solana is controlling validator execution risk through Agave v4.0 and staged Frankendancer rollout. Smart-contract engineers are controlling application execution paths through lints, typed-data tests, TEE architectures, and incident-driven authorization invariants.

Dimension

Ethereum

Solana

Smart contract engineering

Mechanism

Enshrines builder/proposer separation and exposes block access dependencies

Ships validator-client upgrades and staged Firedancer/Frankendancer client diversity

Moves security checks into CI and shifts privacy computation into TEEs or coprocessors

Scope

L1 consensus, execution, and L2 compatibility

Validator software, consensus roadmap, compute/rent/vote-account changes

Application contracts, dev tooling, privacy architecture, exploit prevention

Main trade-off

Less external relay dependence, but more protocol-level timing and PTC complexity

More client diversity and performance headroom, but rollout metrics are harder to verify from primary sources

Faster detection and confidential execution, but false positives, enclave trust, and metadata leakage remain

Evidence quality

Strong primary evidence from EF, EIPs, ethereum.org, GitHub, and client releases

Strong primary evidence for Agave and Frankendancer releases, weaker public primary evidence for Firedancer block-production metrics

Strong release-note evidence for Foundry/Hardhat and strong security-research evidence for May incident root causes

Time horizon

Glamsterdam integration and fork readiness

Agave v4.0 now, Alpenglow and 100M CU roadmap gates later

Immediate CI adoption and ongoing architectural threat modeling

The tension is that Ethereum is reducing one trust dependency while TEEs intentionally add another. ePBS tries to remove reliance on external relays by embedding builder/proposer separation into the protocol, while TEE privacy systems rely on enclave integrity and attestation to hide data during execution. These are not contradictory moves. They show that modern blockchain engineering is becoming more explicit about where trust lives.

Solana exposes a different tension: performance roadmaps are easy to overstate. Agave v4.0 and Frankendancer releases are primary-source facts. Firedancer mainnet block production in May appears in secondary reporting, but the official pages scanned for this recap did not provide public validator-share or block-count metrics. The right engineering conclusion is not skepticism for its own sake. It is measurement discipline: publish version, validator share, block share, skipped-slot behavior, and rollback data before calling a rollout complete.

The final convergence is downstream responsibility. Ethereum L2s must track L1 fork semantics, Solana validators must track client and consensus version gates, and smart-contract teams must turn postmortem lessons into automated tests. The winners in the next upgrade cycle will not be the teams with the most roadmap awareness. They will be the teams with the best pre-production reproduction environments.

Share via:

Picture of Yannik Heinze

Yannik Heinze

CEO at softstack, Web3 veteran and mentor.

Further Insights

Dive into our in-depth analyses and discover how Web3 technologies are transforming the digital landscape,
unlocking new avenues for decentralized innovation.