Kernel v4 — release/v4

[leekt]

Kernel v4 — release/v4

Brings the Kernel v4 codebase into this repository as release/v4, alongside the existing release/v3.x lines.

Build: solc 0.8.33 · optimizer 200 runs · evm prague · via-IR off · deterministic CREATE2 (0x4e59…956C, salt 0x00).

---

What is Kernel v4

A ground-up rewrite of the ZeroDev modular smart account on ERC-4337 / ERC-7702, implementing ERC-7579 for standardized module interfaces. v4 collapses validation, execution, and hooks into a clean six-module architecture and adds a first-class permission system for granular session keys.

Six pluggable module types (ERC-7579)

Type	Role
Validator	Validates UserOps and signatures — owns a nonce-key namespace
Executor	Calls executeFromExecutor to act on behalf of the account
Fallback	Extends the account with new selectors (call or delegatecall)
Hook	Pre/post execution checks on validators, executors, fallback selectors
Policy	Half of a permission — enforces rules (spending caps, allowlists, time windows)
Signer	Half of a permission — provides signature verification (passkey, multisig, …)

Permission system (session keys)

A permission = one signer + one or more policies. A dapp can be handed a signer scoped to specific selectors under specific policies, without ever touching the root validator. Policies install/uninstall LIFO; the signature carries one entry per policy (install order) plus the signer's, last.

Three account variants

• KernelUUPS — UUPS upgradeable proxy; full module lifecycle + proxy upgrade via UserOp. Deploy via KernelFactory.deploy().
• KernelImmutableECDSA — ERC-1967 clone with an ECDSA fallback signer fixed in immutable args; still setRoot-able and UUPS-upgradeable. Deploy via KernelFactory.deployECDSA().
• Kernel7702 — EIP-7702 EOA delegation; the EOA itself is the fallback signer, no init needed, supports raw ERC-1271.

Enable mode

Install modules atomically with the first UserOp — no setup transaction. The nonce encodes an enable flag; the signature carries the install payload (root-validator-approved) + the UserOp signature. Chain-specific and replayable (chain-agnostic) variants.

Nonce-encoded validation

The 32-byte 4337 nonce selects the validator/permission, giving each its own nonce namespace:

| 1 byte | 1 byte | 20 bytes | 2 bytes  | 8 bytes |
| vMode  | vType  | vId      | nonceKey | seq     |

vType: 0x00 root · 0x01 validator (20-byte addr) · 0x02 permission (4-byte id). vMode flags enable / replayable-enable-sig / replayable-userOp-hash.

Hook system

Hooks bind independently to validators (executeUserOp), executors (executeFromExecutor), and fallback selectors. Sentinels: address(0) = not installed, address(1) = installed with no hook.

Signatures (ERC-1271 / ERC-7739)

isValidSignature supports raw (7702 only), chain-specific nested EIP-712, and replayable nested EIP-712 — selected by the first 21 bytes of the signature, for both validator- and permission-based verification.

Standards

ERC-4337 (EntryPoint v0.9) · ERC-7579 · ERC-7702 · ERC-7739 · ERC-7201 (namespaced storage) · ERC-1271.

---

Release notes — v0.4.0

• Initial v4 release: six-module ERC-7579 architecture, permission/session-key system, three account variants, enable mode, nonce-encoded validation, hook system, ERC-7739 signatures.
• EntryPoint v0.9 support; EntryPoint v0.8 paths removed.
• Security hardening from internal + Trail of Bits audits — e.g. signature-replay nonce, signature-bypass fix, _setRoot vType check, intersectValidationData aggregator fix, factory msg.value forwarding, root-validator uninstall protection, audit batch 1: 3 HIGH / 1 MEDIUM / 3 LOW.
• Deterministic CREATE2 release artifact at releases/v0.4.0.json.
• Test suite spans unit, integration, invariant/fuzz, and formal verification (Halmos / Kontrol / Certora).

---

Mergeability

v4 has an independent history from this repo's dev trunk. This branch records dev as a merge parent via git merge -s ours, so:

• the branch tree is exactly v0.4.0 (pure v4 code, no v3 files mixed in);
• dev is an ancestor → this PR merges cleanly, no unrelated-history conflicts;
• the diff below reflects the real v3 → v4 change.

Merging advances dev to the v4 codebase. v3 stays preserved on release/v3.0 / release/v3.1 / release/v3.3.