Native account abstraction and post-quantum readiness for Ethereum. One transaction type, multiple frames, programmable validation.
Pick the route that matches why you're here.
A frame transaction (0x06) consists of multiple frames, each with a mode that tells the protocol what the frame does:
| Mode | Name | Purpose |
|---|---|---|
DEFAULT | Deployment | Deploy accounts, run post-operation hooks |
VERIFY | Verification | Authenticate the sender, authorize payment. Read-only, must call APPROVE. |
SENDER | Execution | Execute the user's intended operations (calls, transfers, contract interactions) |
No bundler, no EntryPoint contract, no off-chain infrastructure. The protocol handles validation, gas payment, and execution natively through frames. SENDER frames execute with msg.sender = tx.sender, so existing contracts see the original account as the caller. Token approvals, NFT ownership, and all on-chain state work as-is.
EOAs benefit directly without EIP-7702. The protocol has built-in fallback behavior for codeless accounts: VERIFY frames verify signatures (ECDSA or P256) and call APPROVE natively. Multi-call sequences come from the frame list (one SENDER frame per call) instead of a payload inside a single frame, with native ETH transfers via frame.value. No code is ever deployed to the EOA. With the atomic batch flag set in the flags field on consecutive SENDER frames, they become all-or-nothing, protecting users from partial execution.
A user approves and swaps tokens in a single atomic transaction. The sponsor pays all gas; the user pays nothing:
| Frame | Mode | Target | What it does |
|---|---|---|---|
| 0 | VERIFY | sender | Verify sender signature, approve execution |
| 1 | VERIFY | sponsor | Verify sponsor, approve payment |
| 2 | SENDER | ERC-20 | approve(DEX, amount) — allow DEX to spend tokens |
| 3 | SENDER | DEX | swap(...) — execute the swap |
| 4 | DEFAULT | sponsor | Post-op: refund overcharged gas fees to sponsor |
An EOA at address A rebalances a Uniswap v4 liquidity position, paying for gas in USDC instead of ETH:
| Frame | Mode | Target | What it does |
|---|---|---|---|
| 0 | VERIFY | A | Protocol verifies ECDSA signature, approves execution |
| 1 | VERIFY | sponsor | Sponsor authorizes gas payment |
| 2 | SENDER | Position Manager | decreaseLiquidity(...) — remove from old range |
| 3 | SENDER | Position Manager | collect(...) — collect tokens |
| 4 | SENDER | USDC | transfer(sponsor, fee) — pay sponsor in USDC |
| 5 | SENDER | Position Manager | increaseLiquidity(...) — add to new range |
| 6 | DEFAULT | sponsor | Post-op: refund overcharged gas fees |
This example is the permissionless ERC-20 paymaster (onchain) variant, where the sponsor's VERIFY frame introspects the next SENDER frame to confirm the USDC transfer before approving payment. That introspection reads external contract state, so this specific shape is consensus-valid but does not propagate through the public (restrictive) mempool; wallets route it through the expansive tier, a private mempool, or direct-to-builder. A separate live ERC-20 paymaster (offchain) pattern, in which a paymaster service pre-signs the transaction, does propagate through the public mempool as a non-canonical paymaster (one pending tx per paymaster). Both patterns are native to EIP-8141 and independent of ERC-4337. See Mempool Strategy → ERC-20 gas repayment: two paymaster patterns.
EIP-8141 introduces five new opcodes that give frame transactions their power:
| Opcode | Purpose |
|---|---|
APPROVE | Terminates a VERIFY frame and sets transaction-scoped approval flags. Scope 0x1 approves payment, 0x2 approves execution, 0x3 approves both. |
TXPARAM | Reads transaction parameters (sender, nonce, fees) from inside a frame. Replaces ORIGIN for introspection. |
FRAMEDATALOAD | Loads 32 bytes from the current frame's data field. How account code reads signatures and calldata passed to a frame. |
FRAMEDATACOPY | Copies frame data to memory. Bulk version of FRAMEDATALOAD for larger payloads. |
FRAMEPARAM | Reads frame-level metadata (mode, flags, resolved target). Enables frame code to introspect its own execution context. |
APPROVE is the central innovation: it's how account code tells the protocol "I've verified this transaction, proceed." The other four opcodes give frame code access to the transaction and frame context it needs to make that decision.