Date: July 13, 2026

‍Chain: Arbitrum

‍Loss: approximately $264K across multiple smart accounts

‍Class: state-changing side effect during ERC-4337 validation

Summary

On July 13, 2026, Lumi Finance lost roughly $264K when an attacker pulled tokens out of multiple user smart accounts without any of those users signing for it. Lumi's accounts are ERC-4337 smart accounts, and the exploit lived in the one phase of that standard that's supposed to be harmless: validation. In ERC-4337, validating a user operation is meant to only check whether the operation is authorized, never to change state. Lumi's validation logic broke that rule. It let an attacker-controlled paymaster trigger token approvals while an operation was merely being validated, so the act of validation itself handed the attacker an allowance on the victim's account. With those allowances in hand, the attacker used a sweeper contract to drain the approved tokens across many accounts at once, mostly LUA and USD₮0, swapped them to ETH, and moved the proceeds out. No user approved anything, and no key was stolen. The contract granted the allowances on its own, during a step that was never supposed to grant anything.

Background

Account abstraction, standardized as ERC-4337, replaces a simple externally owned wallet with a smart contract account. Instead of signing a raw transaction, a user submits a UserOperation, and the account contract runs it in two phases. First validation, where the account checks that the operation is legitimate, and then execution, where the operation actually does its work.

That split exists for a reason, and the standard is strict about it. Validation is supposed to be effectively read-only. It can verify a signature, check a nonce, and agree to pay for gas, but it must not perform state-changing actions like transfers or approvals. A paymaster, the contract that can sponsor gas for a user, participates in that validation phase, which makes the boundary even more important: a paymaster is a third party in the flow, and it must never be able to reach through validation and change the account's state.

The whole security model of a smart account rests on that boundary holding. If validation can change state, then the check that's supposed to gate an operation becomes an operation in its own right, one that runs before anyone has been authorized.

Root Cause

Lumi's smart-account validation logic allowed a state-changing side effect during the validation phase. Specifically, an attacker-controlled paymaster could trigger ERC20 approval operations while a UserOperation was being validated.

The consequence is that validation stopped being a check and became an action. When the attacker's operation was validated against a victim's smart account, the validation path granted the attacker's address an ERC20 allowance on that account. No signature from the account owner was involved, because granting the allowance wasn't the operation being authorized, it was a side effect of the machinery that decides whether to authorize. The victim never intended to approve anyone, and never did in any meaningful sense. The contract approved on their behalf as a byproduct of checking an operation it should have simply accepted or rejected.

Once the allowances existed, the rest was ordinary. A sweeper contract called transferFrom against each account that had been made to grant an approval, pulling the balances out across many accounts in a batch, and the collected tokens were swapped to ETH. The drain wasn't the clever part. The clever part was making the accounts approve the attacker during a phase that isn't allowed to approve anyone.

Attack Flow

1. The attacker constructed UserOperations paired with an attacker-controlled paymaster, targeting Lumi smart accounts.
2. During the validation phase of those operations, Lumi's logic allowed the paymaster to trigger ERC20 approvals, so validation granted the attacker's address an allowance on each targeted account without the account owner signing for it.
3. With allowances established across multiple accounts, the attacker's sweeper contract drained the approved tokens, primarily LUA and USD₮0, out of those accounts in a batch.
4. The extracted tokens were swapped to ETH and the proceeds were moved to the attacker's address.

Impact

Roughly $264K was drained across multiple user smart accounts. Because the approvals were granted through the accounts' own validation logic rather than through phished signatures, the theft required no interaction from the victims and left no trace of a user-authorized approval. Every affected account had, from its own perspective, done nothing. The loss spread across many accounts rather than one, which is the signature of a flaw in shared account logic rather than a single compromised wallet.

The Problem With Audit-Only Security

This exploit is a clean example of a vulnerability that isn't a bug in any single function, but a broken assumption about what a phase of execution is allowed to do. That's exactly the kind of defect a point-in-time review is structured to miss.

A reviewer reading Lumi's validation code sees functions that verify operations and a paymaster hook that participates in the flow. Each piece can look correct on its own. The approval call that fires during validation isn't malformed, it's a real approval that executes exactly as written. Nothing is wrong at the level of any individual line. The defect only appears when you hold the whole thing against the rule that validation must not mutate state, and then ask whether any path through validation, including one a hostile paymaster controls, can reach a state change. That's a property of the phase, not of a line, and verifying it means reasoning about every path an adversary can take through validation rather than reading the functions in sequence.

Account abstraction makes this harder, not easier, because it's newer. The invariant that validation is side-effect-free is well defined in the standard, but it's a young standard, and the failure modes are less worn-in than reentrancy or integer overflow. A manual reviewer working through a smart account under a deadline is far more likely to catch a classic pattern than to exhaustively prove that no paymaster-controlled path through validation can issue an approval. The assumption is easy to state and hard to check by reading, which is precisely the gap between an audit that looks at code and analysis that tests what the code is permitted to do.

How Olympix Would Have Prevented It

The property that broke here is an invariant, and invariants are what Olympix tests. The rule that validation must not perform token approvals or any external state mutation, and that a paymaster must not be able to induce an allowance change, is a precise, checkable property of a smart account. Olympix's analysis follows the paths through the validation phase and tests whether any of them, including adversary-controlled ones, can reach a state change like an approval. A path that grants an allowance during validation fails that test directly.

BugPOCer takes it past a flagged property to a demonstrated one. Rather than reporting that validation might mutate state, it constructs the operation and the hostile paymaster, runs them through the account's validation, and produces a proof-of-concept showing an allowance granted with no owner signature, followed by the sweep that drains the account. The output isn't a warning that a boundary could be crossed. It's a transaction that crosses it and takes the money, sitting in front of the team before the account is ever deployed.

That distinction matters most for a young standard. A finding that says validation performs a side effect is easy to under-rank when the reviewer isn't yet fluent in why that specific boundary is load-bearing in ERC-4337. A working exploit that empties a smart account through its own validation logic removes any room for that misjudgment. The team doesn't have to already understand the failure mode to take it seriously, because the proof-of-concept is the argument.

This isn't an argument against audits. A skilled reviewer familiar with account abstraction may well catch this. It's an argument that an audit alone isn't a security model, because whether a subtle, standard-specific invariant gets caught can't depend on which reviewer happened to look and how much time they had. Continuous, code-level analysis that tests the invariant directly, and proves the violation with an exploit, is what makes the catch reliable rather than lucky.

Takeaway

A smart account's safety rests on validation being a check and nothing more, and Lumi's validation quietly became an action, granting attacker allowances during a phase that's never allowed to grant anything. Roughly $264K left user accounts that had, by their own logic, authorized nothing. The flaw wasn't a broken line, it was a crossed boundary, the kind that a reader can miss and a path-level test catches, especially on a standard young enough that its failure modes aren't yet reflexes. Testing what a phase of execution is permitted to do, and proving what happens when that permission is exceeded, is the difference between a smart account that holds its own boundary and one that hands it away. You can see Olympix test the invariants of your own smart accounts and prove the violations against your code, with a working proof-of-concept for every finding, in a free demo.

On-Chain References

Protocol:                Lumi Finance (ERC-4337 smart accounts)
Chain:                   Arbitrum
Date:                    July 13, 2026
Loss:                    ~$264K across multiple smart accounts
Attacker EOA:            0xce1a3bb0b98d0d90c7dd0620ab86c9a771888d88
Malicious sweeper:       0x56362412ae17cac443aafbab4289946ad958e8a1
Exploit txs:             0x020995ec0b5daafe8fab481e33b1b52fdbd6423578060a1f73fd2a9b9fb0ea90
                        0x630654fb1c8914405cf81bb02f091b049f19403a152f624f7b8a00c7724c6604
Tokens drained:          LUA, USD₮0, swapped to ETH
Flaw:                    UserOp validation lets an attacker-controlled paymaster trigger ERC20
                        approvals as a validation-time side effect, granting allowances with no
                        user intent; sweeper then batch-drains the approved accounts


Validation-phase side effects are an invariant Olympix tests and proves. If you're building on account abstraction, or any system where a check must never become an action, see the same analysis run against your own contracts, with a proof-of-concept for the findings that carry real loss. Book a free demo.