Date: October 19, 2026
Chain: Ethereum
Loss: about $59,800
Class: a recovery deadline that could be wrapped into the past, plus signed payloads that were never marked as used
Smart wallets built on Argent's design give owners a safety net for lost keys. Guardians the owner picks can approve a recovery that hands the wallet to a new owner key, and in Argent's own wallets that recovery only completes after a 48-hour waiting period, which Argent's support guide describes as time for the real owner to cancel an attempt they didn't start.
On October 19, 2026, according to SlowMist's alert, an attacker drained about $59,800 from an Argent-style smart wallet system on Ethereum by breaking two pieces of it. An unrestricted setter in the recovery module accepted a crafted recovery period that wrapped the deadline into the past, which let a guardian-backed recovery finalize in the same transaction and change the wallet's owner with no waiting period at all. And the execution module never rejected a signed payload it had already run, so the same payload executed 19 times in one transaction and 9 times in another.
A smart wallet of this kind splits its logic into modules. The recovery module manages guardians and owner changes, and its central rule is time: a recovery can't finalize until its deadline has passed, so the owner always has a window to object. The execution module carries out actions the owner has signed, often submitted by a relayer, and its central rule is that one signature authorizes one action.
Both rules depend on state the module keeps for itself. A deadline only protects anyone if it actually lands in the future, and a signature only authorizes one action if the module records that it's been used, usually with a nonce, a counter that goes up after every execution, or a stored set of payload hashes it has already seen.
SlowMist reports that the recovery module exposed an unrestricted setter (function selector 0x254a2e49) that accepted a crafted recovery period, and that the deadline calculated from it wrapped to a timestamp in the past. An integer in a smart contract has a fixed maximum, and arithmetic that runs past that maximum without a check starts over from zero, the way a car odometer rolls over to all zeros. A deadline computed that way can come out earlier than the current time even though it was meant to be days away.
The result was a recovery whose waiting period had, in the contract's eyes, already ended. According to SlowMist, a recovery backed by a valid guardian signature was then finalized in the same transaction and changed the wallet's owner, so the one feature designed to give an owner time to react was gone before the recovery began.
The execution module had the second gap. It verified that a payload was signed, but it never marked that payload as consumed, so submitting the same signed bytes again looked exactly like submitting them the first time. SlowMist counts 19 successful executions of one identical signed payload (selector 0xaacaaf88) in one transaction and 9 in a second.
SlowMist says the attacker used those repeated executions to trade around a low-liquidity MARK/WETH pool, and its alert links both transactions, sent from 0xc106...2b02 through an unverified contract at 0x3C58...B310. The first, at 09:42:35 UTC, runs 19 rounds of one sell and two buys in the MARK/WETH Uniswap V2 pool at 0x6f23...b6F3, and the second, at 09:43:35 UTC, runs 9. In the first, the contract borrows 0.5 WETH from Balancer as a flash loan, and inside the same trace a smart wallet at 0xe545...8f66, called through an upgradeable module proxy, sends about 1.06 ETH through the Uniswap V2 router to buy MARK.
The idea to take from this case is that any safety rule built on time or on one-time use is only as strong as the state that enforces it. A deadline has to be computed so it can't wrap, and a signature has to be spent the moment it's used, or the rule exists in the design and nowhere in the contract.
Olympix reads a contract the way an attacker does, as states, transitions and entry points, and takes in the design around the code, here a wallet whose recovery depends on a waiting period and whose execution depends on single-use signatures. From that it infers the invariants the system depends on. This case has two, each one sentence long: a recovery deadline set now is always later than now, and a signed payload can execute at most once.
Signals tell the engine which paths to attack first, and Olympix's static analysis surfaces both here. In the recovery module, the signal is a caller-influenced value flowing into deadline arithmetic with no bound on the result. In the execution module, it's a signature check on a path that never writes a nonce or a used-payload record afterward. Each one narrows the search from every path, to the feasible ones, to the few that can touch the invariant.
With both paths flagged, BugPoCer goes after the two rules the wallet's design promised its owner. Running Counterexample-Guided Invariant Refutation from the wallet system outward, it executes paths until each rule fails. In the recovery module the failing run is an input that produces a deadline earlier than the current block, followed by a recovery that finalizes at once, and in the execution module it's one signed payload submitted twice and accepted twice. BugPoCer returns each as a concrete sequence with the minimal conditions that trigger it and a generated Forge test that replays it, which is this exploit produced in development.
Olympix has flagged this class before in other codebases, where signed messages could be replayed because nothing recorded that they'd been used. The engine runs in development, at every merge and before release, so a module change that drops a nonce write or alters a deadline calculation gets tested against these rules on the day it's made.
This wallet system had the right protections on paper, a waiting period for recovery and signatures for every action, and lost about $59,800 because a deadline could land in the past and a signature could be spent 28 times. Wallet and account abstraction teams should treat every time lock and every signature check as an invariant with its own test, including the inputs nobody expects. To see Olympix infer the safety rules in your own modules and hand back a runnable counterexample for any that break, book a technical walkthrough.
Protocol: Argent-style smart wallet system (recovery and execution modules)
Chain: Ethereum
Date: October 19, 2026
Loss: about $59,800 (SlowMist)
Attacker EOA: 0xc106...2b02
Attack contract: 0x3C58...B310
Exploit tx (19 rounds, 09:42:35 UTC): 0xbfed...a795
Exploit tx (9 rounds, 09:43:35 UTC): 0xa0ee...571b
Victim wallets (per SlowMist): 0xe545...8f66, 0x5a79...5440
Vulnerable module proxy (per SlowMist): 0xF490...8ef5
Vulnerable module proxy (per SlowMist): 0x4e50...7394
MARK/WETH pool (Uniswap V2): 0x6f23...b6F3
Block: 26225798 (first exploit tx)
SlowMist on X: Argent-Style Smart Wallet Exploit Alert
Argent Support: How to Recover My Wallet With Guardians (Onchain)