Kernel v4 Modular Smart Account Framework

repository·dev·Indexed 42 days ago

https://github.com/zerodevapp/kernel

A modular smart account framework based on ERC-4337 and ERC-7579. Kernel v4 enables the creation of highly customizable accounts with pluggable validation, execution, and hook modules, supporting granular permission systems and EOA delegation via EIP-7702.

Tokens
11.2K
Snippets
24
Records
37
Agent score
51%

What's inside Kernel

  1. Certora repository layout

    dev

    The certora/ directory is organized as follows:

    • conf/: Contains certoraRun configuration files in JSON format.
    • specs/: Contains CVL (Certora Verification Language) rules and invariants.
    • harnesses/: Contains Solidity wrappers used when storage or inheritance tricks are required for verification.
  2. How the Hook System works

    dev

    Hooks allow for pre/post execution checks and bind to different components independently:

    • Validator hook: Runs around executeUserOp when a non-root validator with a hook is used.
    • Executor hook: Runs around executeFromExecutor for any installed executor.
    • Fallback hook: Runs around fallback selector dispatch.

    Sentinel values for hook addresses:

    • address(0): Not installed.
    • address(1): Installed with no hook.
  3. Understand the Kernel v4 Architecture

    dev

    Kernel v4 is built on a modular architecture following the ERC-7579 standard. It uses a hierarchical manager system to separate concerns like validation, execution, and hooks.

    Core Components

    • Kernel (Abstract): The base account logic.
    • ModuleManager: Orchestrates the lifecycle of various managers:
      • ValidationManager: Handles validator/permission lifecycles, enable-mode, and nonce management.
      • ExecutorManager: Manages executor installation/uninstallation and hook binding.
      • HookManager: Manages hook installation/uninstallation and dispatches pre/post checks.
      • SelectorManager: Routes fallback handlers by function selector.
    • ExecutionManager: Implements ERC-7579 execution modes (single, batch, or delegatecall).
    • ERC1271: Provides standard signature verification (ERC-1271 / ERC-7739).

    Concrete Implementations

    Depending on your use case, you should use one of the following implementations:

    • KernelUUPS: A UUPS upgradeable proxy.
    • KernelImmutableECDSA: A minimal clone with an immutable signer.
    • Kernel7702: An EIP-7702 variant for EOA delegation.

    Supporting Contracts

    • KernelFactory: Used for deterministic ERC-1967 proxy deployment.
    • Staker: Manages EntryPoint staking and factory approval.
  4. Core Components of the Account Abstraction Library

    dev

    The library provides several core contracts and utilities for ERC-4337 development:

    • EntryPoint Contract (contracts/core/EntryPoint.sol): The central contract that processes UserOperations. It validates operations, handles account creation, executes operations, and manages gas.
    • BaseAccount (contracts/core/BaseAccount.sol): Base implementation for smart contract accounts.
    • BasePaymaster (contracts/core/BasePaymaster.sol): Helper class for creating a paymaster.
    • StakeManager (contracts/core/StakeManager.sol): Manages deposits and stakes for accounts and paymasters.
    • NonceManager (contracts/core/NonceManager.sol): Handles nonce management for accounts.
    • UserOperationLib (contracts/core/UserOperationLib.sol): Utilities for working with UserOperations.
    • Helpers (contracts/core/Helpers.sol): Common constants and helper functions.
  5. How the Permission System works

    dev

    Beyond standard validator modules, Kernel v4 uses a Permission System to enable granular session keys. A permission is a composition of:

    1. One Signer
    2. One or more Policies

    This allows a dapp to be granted a signer that is restricted by specific policies (e.g., spending caps, time windows, or target restrictions) without requiring access to the account's root validator.

  6. Understand Kernel v4 Modular Architecture (ERC-7579)

    dev

    Kernel v4 is a modular smart account implementing ERC-7579. It uses six pluggable module types that can be installed or uninstalled at runtime to extend account functionality:

    • Validator: Validates UserOps and signatures; owns a specific nonce key namespace.
    • Executor: Performs actions on behalf of the account via executeFromExecutor.
    • Fallback: Extends the account with new function selectors using call or delegatecall.
    • Hook: Performs pre/post execution checks on validators, executors, and fallback selectors.
    • Policy: Part of a permission; enforces rules like spending limits or target allowlists.
    • Signer: Part of a permission; provides signature verification (e.g., passkey, multisig).
  7. Choose the right Kernel account variant

    dev

    Kernel v4 provides three distinct account deployment patterns depending on your use case:

    • KernelUUPS: A UUPS upgradeable proxy. Deployed via KernelFactory.deploy(). Supports the full module lifecycle and proxy upgrades via UserOp.
    • KernelImmutableECDSA: An ERC-1967 clone with a fixed ECDSA fallback signer set at deployment. Users can call setRoot to change the validator, and the proxy remains UUPS-upgradeable. Deployed via KernelFactory.deployECDSA().
    • Kernel7702: An EIP-7702 variant for EOA delegation. The EOA itself acts as the fallback signer (ECDSA.recover == address(this)). No initialization is required, and it supports raw ERC-1271 signatures.
  8. Install OpenZeppelin Contracts via git (Foundry)

    dev

    To install the library using Foundry, run the following command.

    Warning: Avoid using the master branch as it is a development branch and does not guarantee the same security measures as tagged releases. Additionally, subsequent forge update commands may default to the master branch.

    After installation, you must add the following line to your remappings.txt file to ensure correct imports:

    ```bash
    $ forge install OpenZeppelin/openzeppelin-contracts

    Add @openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/ in remappings.txt.

  9. Generate Code Coverage Reports

    dev

    To generate and view coverage reports, use forge coverage with specific exclusions to focus on core logic, then use genhtml to create a visual report.

    forge coverage \ 
      --no-match-coverage "(script|test|Foo|Bar|validator|sdk|signer)" \ 
      --report lcov
    
    genhtml lcov.info \ 
      --output-directory coverage \ 
      --ignore-errors inconsistent \ 
      --ignore-errors corrupt
    
    open coverage/index.html
  10. Run Certora formal verification for Kernel v4

    dev

    Certora is used as a formal verification harness for Kernel v4 to verify properties requiring multi-step traces or unbounded-array quantification. To run the verification, follow these steps from the repository root:

    1. Activate the virtual environment containing the certora-cli:
      source ~/.certora-venv/bin/activate
    2. Export the API key. Certora requires the environment variable CERTORAKEY. If your local machine uses CERTORA_KEY, alias it:
      export CERTORAKEY="$CERTORA_KEY"
    3. Verify Java 21+ is available on your PATH (Temurin is recommended):
      java --version
    4. Execute the run using the certoraRun command pointing to a specific configuration file:
      certoraRun certora/conf/Kernel.conf

    Running the command uploads the job to the Certora cloud and prints a job URL. You can open this URL in a browser to view the full verification report.

    source ~/.certora-venv/bin/activate
    export CERTORAKEY="$CERTORA_KEY"
    java --version
    certoraRun certora/conf/Kernel.conf