Account abstraction makes crypto wallets more flexible, but it also makes them easier to break if developers get the details wrong. That is the core message from a new Trail of Bits post, which outlines six recurring security mistakes found while auditing ERC-4337 smart accounts.
The blog post matters because ERC-4337 is no longer a niche concept. It is becoming a core wallet design model for features like social recovery, batching, gas sponsorship, and spending rules. Trail of Bits’ warning is simple: a bug in a smart account can be just as dangerous as leaking a private key.
Why ERC-4337 wallets are different
Trail of Bits explains ERC-4337 as a model where the smart account itself becomes the main user account. Instead of relying on a normal externally owned account to initiate every transaction, ERC-4337 uses an EntryPoint contract, bundlers, and optional paymasters to validate and execute a UserOperation.
That design unlocks better UX, but also changes the attack surface. In this model, mistakes in validation logic, gas handling, or signature verification can directly expose a wallet to theft or repeated fee draining.
Mistake 1 — Bad access control can expose the whole wallet
Trail of Bits says the most basic failure is still one of the most dangerous: letting anyone call the wallet’s execute function or another privileged path directly. In a safe ERC-4337 account, only the trusted EntryPoint contract should be able to trigger sensitive execution paths, unless a vetted module system is used.
In simple terms, if a public function can move funds and is not properly locked down, an attacker may not need any fancy exploit at all. They can just call it and drain the wallet.
Mistake 2 — Not signing gas fields can let attackers drain ETH
One of the most important findings in the post is about incomplete signature validation. Trail of Bits says some smart accounts validate only the intended action, such as callData, but fail to cryptographically bind the gas fields to the signature. Those fields include items such as preVerificationGas, verificationGasLimit, callGasLimit, and fee parameters.
Why does that matter? Because the EntryPoint uses those numbers to calculate and settle fees. If they are not signed or tightly validated, a bundler or attacker can inflate them and make the wallet overpay. Trail of Bits specifically points to preVerificationGas as an easy lever for direct ETH extraction.
The takeaway is clear: developers should sign the full UserOperation, ideally using the userOpHash from the EntryPoint, and add strict caps or sanity checks where needed.
Mistake 3 — Writing state during validation can create cross-operation bugs
Trail of Bits warns that modifying wallet state during validateUserOp is dangerous because the EntryPoint validates all operations in a bundle before executing any of them. That means one operation’s validation can overwrite temporary data written by another before execution starts.
The blog gives an example where a recovered signer is cached in storage during validation and then used later during execution. Another operation in the same bundle can overwrite that cached value, which may cause the wrong signer data to be used.
The practical lesson is simple: avoid writing temporary approval state during validation. If persistence is absolutely necessary, key it to the specific userOpHash and clean it up deterministically. But Trail of Bits’ preferred answer is not to persist validation state at all.
Mistake 4 — ERC-1271 signatures can be replayed across accounts or chains
The post also flags a recurring ERC-1271 replay issue. The problem appears when a smart account validates a raw hash signed by the owner, but does not bind that signature to the specific smart account address and chain. If the same owner controls multiple smart accounts, or the same setup exists on multiple chains, that signature may be replayed elsewhere.
Trail of Bits says the fix is to use EIP-712 typed data, which binds the signature to both the wallet address and the chainId. Without that domain separation, the same signature can effectively travel across accounts or networks.
For wallet teams, this is one of the most important real-world checks because replay problems often survive basic happy-path testing.
Mistake 5 — A later revert does not protect you from fee loss
Trail of Bits says many developers still think a revert in execution is a kind of safety net. In ERC-4337, it is not. Once validateUserOp succeeds, the bundler gets paid even if the later execution fails. That means a wallet can still lose gas repeatedly on operations that do nothing useful.
The post says a malicious bundler can exploit overly permissive validation by repeatedly submitting operations that are destined to fail during execution, while still collecting fees each time. Trail of Bits also warns about paymaster designs that try to settle costs after the fact in postOp, because postOp can fail without undoing the payment already made during validation.
The recommended design is stricter: secure fees before execution begins, and keep postOp minimal and non-reverting.
Mistake 6 — ERC-7702 creates new initialization risks for older account logic
The sixth issue in the post is about the interaction between older ERC-4337 account logic and ERC-7702. Trail of Bits says ERC-7702 lets an externally owned account temporarily behave like a smart account for one transaction, but this opens an initialization race. If wallet logic expects a later initialize(owner) call, an attacker may front-run that step and set themselves as owner first.
This is a newer and more subtle risk than the earlier examples, but it matters because it shows how wallet logic written for one account model may become unsafe when reused in another.
The bigger message from Trail of Bits
The common thread across all six mistakes is that ERC-4337 wallets are not “just smart contracts with nicer UX.” They are new security-critical account systems with new failure modes around validation, fees, bundling, and signature scope.
That makes audit discipline much more important. A wallet can look correct in normal usage, while still being exploitable by bundlers, frontrunners, or cross-operation edge cases that do not exist in standard EOA flows. This is an inference based on the six vulnerability classes Trail of Bits describes.
Why it matters for crypto
- ERC-4337 is making wallets more powerful, but also more complex, which increases the cost of getting security wrong.
- Several of the issues Trail of Bits highlights are not abstract bugs. They can directly lead to drained ETH, replayed approvals, or repeated fee extraction.
- The post reinforces that wallet security is no longer just about private keys; it is now also about validation logic, bundler assumptions, and contract design.
- As smart accounts become mainstream, these mistakes could scale from isolated bugs into ecosystem-wide wallet risks. This is an inference supported by Trail of Bits’ statement that these issues appeared repeatedly across audits.
What to watch next
- Whether major ERC-4337 wallet teams publish fixes, audit updates, or design changes in response to the issues Trail of Bits highlighted.
- More scrutiny on paymaster design, gas-field signing, and ERC-1271 validation patterns in wallet audits.
- How wallet developers adapt older account logic as ERC-7702 adoption grows.
- Whether the community starts treating
validateUserOpsecurity as a distinct audit category rather than a normal contract check. This is an inference based on the structure of the post.