Validium Docs
  • Overview
  • Connect to Validium
  • Start Coding 🚀
    • Quickstart
      • Overview
      • Deploy using Validium CLI
      • Deploy using Quickstart Repository
      • Deploy your first contract
      • Create an ERC20 token
  • Tooling
    • Block Explorers
    • Hardhat-Validium
      • Overview
      • Installation
      • Guides
        • Getting started
        • Migrating Hardhat project to Validium
        • Compiling non-inlinable libraries
      • Plugins
        • hardhat-zksync
        • hardhat-zksync-solc
        • hardhat-zksync-vyper
        • hardhat-zksync-deploy
        • hardhat-zksync-upgradable
        • hardhat-zksync-verify
        • hardhat-zksync-verify-vyper
        • hardhat-zksync-ethers
        • hardhat-zksync-node
        • Hardhat Community Plugins
    • Foundary
      • Overview
      • Installation
      • Getting Started
      • Migration Guide
        • Overview
        • Compilation
        • Deployment
        • Testing
  • Test and Debug
    • Getting Started
    • Docker L1 - L2 Nodes
    • In-Memory Node
    • Continuous Integration
    • Hardhat
    • Foundry
  • API Reference
    • Overview
    • Conventions
    • ZKs JSON-RPC API
    • Debug JSON-RPC API
    • Ethereum JSON-RPC API
    • PubSub JSON-RPC API
  • Concepts
    • Transaction Lifecycle
    • Blocks and Batches
    • Validium Network Fee Mechanism
    • Finality
    • System Upgrades
    • ZK Chains
    • Data Availability
      • Overview
      • Recreating L2 state from L1 pubdata
      • Validiums
    • Account Abstraction
    • L1 <-> L2 Communication
  • Components
    • Overview
    • Smart & System Contracts
      • Smart Contracts
      • System Contracts
    • Shared Bridges
    • Sequencer / Server
    • Validium Network EVM
      • Overview
      • Bootloader
      • Precompiles
      • Virtual Machine Specification
        • ZKsync Virtual Machine primer
        • VM Formal Specification
    • Prover
      • Overview
      • ZK Terminology
      • Running the Prover
      • Circuits
        • Overview
        • Circuit Testing
        • CodeDecommitter
        • DemuxLogQueue
        • ECRecover
        • KeccakRoundFunction
        • L1MessagesHasher
        • LogSorter
        • Main VM
        • RAMPermutation
        • Sha256RoundFunction
        • StorageApplication
        • Sorting and Deduplicating
          • Overview
          • SortDecommitments
          • StorageSorter
          • LogSorter
      • Boojum Gadgets
      • Boojum Function - `check_if_satisfied`
    • Compiler
      • Compiler Toolchain Overview
        • Compiler Toolchain Overview
        • Solidity Compiler
        • Vyper Compiler
        • LLVM Framework
      • Specification
        • Overview
        • Code Separation
        • System Contracts
        • Exception Handling
        • EVM Legacy Assembly Translator
        • Instructions
          • Instruction Reference
          • EVM
            • Native EVM Instructions
            • Arithmetic
            • Bitwise
            • Block
            • Call
            • Create
            • Environment
            • Logging
            • Logical
            • Memory
            • Return
            • Sha3
            • Stack
          • Extensions
            • Overview
            • Validium Network Extension Simulation (call)
            • Validium Network Extension Simulation (verbatim)
          • EVM Legacy Assembly
          • Yul
        • EraVM Binary Layout
    • Fee Withdrawer
    • Portal - Wallet + Bridge
    • Block Explorer
    • Transaction filtering
Powered by GitBook
On this page
  • Account versioning
  • Nonce ordering
  • Returned magic value
  1. Concepts

Account Abstraction

Explore the nuances of account abstraction in Validium Network, including account versioning, nonce ordering, and the significance of returned magic values in transaction validation.

PreviousValidiumsNextL1 <-> L2 Communication

Last updated 7 months ago


Account abstraction (AA) is a pivotal feature in Validium Network that allows for greater flexibility and functionality in how accounts operate and interact with transactions.

For a comprehensive understanding, it is recommended to review the detailed .

Account versioning

Account versioning in Validium Network facilitates future updates and changes to the account abstraction protocol by allowing accounts to specify which version of the protocol they support. This capability ensures backward compatibility and supports evolutionary development without disrupting existing account functionalities. The versions supported currently are:

  • None: Indicates a basic contract that is not designed to initiate transactions. Such accounts are passive and should not be used as the from field in a transaction.

  • Version1: Supports the initial version of the account abstraction protocol, incorporating all foundational features and specifications.

Nonce ordering

Nonce ordering is a critical aspect that dictates how transactions from accounts are processed concerning their sequence. Accounts in Validium Network can choose between two types of nonce ordering:

  • Sequential: Nonces must follow a strict sequential order similar to externally owned accounts (EOAs). This setting ensures that transactions are processed in a specific sequence, requiring transaction X to be processed before transaction X+1.

  • Arbitrary: Allows transactions to be processed in any order, regardless of their nonce values. While this mode offers flexibility, it currently may lead to transactions being rejected or stuck in the mempool due to nonce mismatches.

It's important to note that these settings serve as guidelines to the operator for managing the mempool and are not enforced by system contracts. However, they provide a framework for expected transaction handling.

Returned magic value

Both accounts and paymasters in Validium Network are required to return a specific magic value during transaction validation. This magic value is critical for ensuring the integrity and correctness of transactions on the mainnet:

  • Validation Enforcement: On the mainnet, the magic value is strictly enforced to confirm that transactions meet all protocol criteria before execution.

  • Fee Estimation: During fee estimation, the magic value is not considered, focusing solely on the computational costs associated with executing the transaction.

To aid in accurate fee estimations, accounts are advised to execute all operations during validation as they would under normal circumstances but return an invalid magic value only at the end of the validation process. This approach helps in approximating the transaction's cost more accurately.

AA protocol documentation