SKIP TO CONTENT
ETHEREUM STANDARDS6 minSmart Accounts / Ep. 1 · Stage 1-3

ERC-7579 Modules Under Native AA: What Still Works?

Say your smart account caps spending at 100 USDC a day. Under the EIP-8141 draft, could one frame send 500 USDC without the cap ever seeing it?

XIN
Pixel-art night harbor: a crane lifts glowing modular cargo crates from an old floating barge onto a new stone pier built into the harbor wall. Most crates glow teal as they cross; one dim crate stays behind on the barge.

IN 30 SECONDS

An ERC-7579 module is a plug-in for a modular smart account. In my reading of the EIP-8141 draft, most module types carry over, validators need a new entry point, and hooks can be skipped unless the account forbids it.

KEY TAKEAWAYS · 3

  • In my reading of the 8141 draft, ERC-7579 executors, fallback handlers and ERC-1271 signature checks carry over unchanged.
  • In my reading, validators need a new entry point, and their settings belong in the account’s own storage.
  • Hooks only see calls routed through the account. My rule: the account’s check makes every SENDER frame go through them.
On this page

Do ERC-7579 modules keep working under native AA?

IN SHORT In my reading, partly: executors and fallback handlers carry over, validators need a new entry point, and hooks need care.

The sort below is my reading of the EIP-8141 Draft of 7 October 2026, not production.

WORDS TO KNOW

Module
A plug-in for a modular smart account under ERC-7579. A validator checks signatures, a hook wraps calls, an executor acts for the account.
Hook
A module that runs a check before and after a call, or batch of calls, made through the account’s execute functions.
Frame transaction
The transaction type EIP-8141 proposes: a list of calls, called frames. VERIFY frames check, SENDER frames act as the account.

ERC-7579, still a Draft, defines each Module A plug-in for a modular smart account under ERC-7579. A validator checks signatures, a hook wraps calls, an executor acts for the account. See the glossary type. It saw this coming:

This standard has a strict dependency on ERC-4337 for the validation flow.

ERC-7579 (Draft)

Its proposed path is to move that dependency into a separate extension once native account abstraction exists.

Native means built into Ethereum, as the EIP-8141 Draft proposes with the Frame transaction The transaction type EIP-8141 proposes: a list of calls, called frames. VERIFY frames check, SENDER frames act as the account. See the glossary. Here is how I sort a modular account like Nexus against it.

STEP BY STEP

Layered stack diagram: 6 layers, top to bottomLayered stack diagram: 6 layers, top to bottom. Layer 1, SIGNATURE CHECKERS: Main check: new way in, Checks for other apps: unchanged, Settings in the module: refused by the public mempool. Layer 2, CALL GUARDS: Wrap calls through the account, Skipped by a direct frame. Layer 3, HELPERS THAT ACT: Ordinary call: unchanged. Layer 4, EXTRA FUNCTIONS: Routing: unchanged. Layer 5, STORAGE: ERC-7201 namespaces carry over. Layer 6, 4337 PLUMBING: Deposits, stake, request hash: no role.SIGNATURE CHECKERSMain check: new way inChecks for other apps:unchangedSettings in the module:refused by the publicmempoolCALL GUARDSWrap calls through theaccountSkipped by a direct frameHELPERS THAT ACTOrdinary call: unchangedEXTRA FUNCTIONSRouting: unchangedSTORAGEERC-7201 namespaces carryover4337 PLUMBINGDeposits, stake, requesthash: no role
Validators (type 1). validateUserOp takes a PackedUserOperation; isValidSignatureWithSender (ERC-1271) is unchanged. Hooks (type 4): preCheck and postCheck around execute and executeFromExecutor. Executors (type 2), through executeFromExecutor. Fallback handlers (type 3): they answer calls the account itself doesn’t recognize.

Step 1. Validators. The main check needs a new way in. Signature checks for other apps stay.

Pick a step to see it move
  1. Validators The main check needs a new way in. Signature checks for other apps stay.
  2. Hooks They wrap calls made through the account, so a direct frame skips them.
  3. Executors and handlers Ordinary calls: unchanged.
  4. Storage and plumbing Namespaced storage carries over; the 4337 deposits and stake have no role.
My sort of an ERC-7579 account against EIP-8141 as drafted on 7 October 2026 (Draft: it can still change). The highlighted layer is where the rewrite lands.

Validators are the rewrite: keep the signature logic, replace the entry point around it. Their validateUserOp takes a PackedUserOperation and its hash (a short fingerprint), and a frame transaction has neither. The account’s VERIFY code reads the signature hash through a new TXPARAM opcode, then ends with APPROVE.

WATCH OUT

Check where each validator keeps its settings. Owners stored in a table inside the validator are outside the sender’s storage, and the draft’s public mempool rejects that. Keep them in the account’s own namespaced storage, reached by DELEGATECALL (module code run on the account’s storage).

That ERC-7201 namespaced storage is what we used on Nexus, for a different reason: safe upgrades.

A worked example: a spending limit a frame can skip

IN SHORT A hook only runs when the call goes through the account, and a frame can aim straight at the token instead.

A WORKED EXAMPLE

Illustrative numbers

PASSA daily limit enforced by a hook, call routed through the account

INPUT

Account
ERC-7579 account with a spending-limit hook
Limit
100 USDC a day
Frame
account frame to the account: send 80 USDC

WHAT HAPPENS

  1. The frame calls the account’s execute function.
  2. The hook checks first: 80 USDC is under the limit.

OUTPUT

Result
transfer runs, limit enforced

BYPASSEDSame account, a frame aimed straight at the token

INPUT

Frame
account frame to the token: send 500 USDC

WHAT HAPPENS

  1. The token sees the account as the caller.
  2. execute never runs, so the hook never runs.

OUTPUT

Result
500 USDC leaves, limit never checked

The draft names the root issue: once execution is approved, “every subsequent SENDER frame executes with caller set to tx.sender”.

IN PLAIN WORDS

Once execution is approved, every later SENDER frame acts as your account, not only the one you had in mind.

My rule: the VERIFY code either requires every SENDER frame to target the account and call an allowed function that runs the Hook A module that runs a check before and after a call, or batch of calls, made through the account’s execute functions. See the glossary, such as execute, or it inspects each frame itself with FRAMEPARAM and FRAMEDATALOAD.

Checking the address alone isn’t enough: the call’s input can hit another function or a fallback handler. Either way, the VERIFY code checks a signature over the canonical hash, which covers the full frame list.

ITEM GET

Check every SENDER frame

The account’s check either forces each SENDER frame through a hooked function or inspects each frame itself.

FAQ

No. ERC-7579 (Minimal Modular Smart Accounts), created in December 2023, is still a Draft, like EIP-8141. Both can change before they become Final.

Half of it, as far as I found. In the draft, the validUntil deadline maps to an expiry check, which runs in the protocol’s own frame. I found no equivalent for validAfter.

Sources: ERC-7579 (Draft), EIP-8141 (Draft), ERC-4337.

STAGE CLEAR

What you now know

  • Which ERC-7579 module types carry over to the 8141 draft, which need a new entry point, and why.
  • Why a hook can be skipped by a frame aimed straight at a target, and how the account’s check closes that gap.

Check yourself

Tap or click a question to see the answer.

A validator keeps each account’s owners in a table inside the validator contract. Will the draft’s public mempool accept a transaction that reads it?

No. Validation may only read the sender’s own storage, and that table sits in the validator’s. Move it into the account’s namespaced storage.

Next stage:What can go wrong with an EIP-7702 delegation, and what should a wallet check before signing?6 min
Adam Boudjemaa
Adam Boudjemaa

Web3 x AI engineer, former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft.

Have a project to ship or a role to fill?

Discuss your project or role

My work at the web3 x AI intersectionOpen-source tools I build

LinkedInTwitterGitHub
Follow the engineering notes

Get new articles on production AI and smart contracts by email.