VeChain Docs
  • Welcome to VeChain
  • Blockchain Basics
    • Introduction to blockchain
    • Introduction to digital property
    • The evolution of the internet
  • Introduction to VeChain
    • About the VeChain blockchain
      • Consensus Deep Dive
      • Governance
    • Dual-Token Economic Model
      • VeChain (VET)
      • VeThor (VTHO)
    • Acquire VeChain Assets
    • Sustainability
  • Core Concepts
    • Networks
      • Thor Solo Node
      • Testnet
      • Mainnet
    • Nodes
      • Node Rewards Programme
    • Blocks
      • Block Model
    • Transactions
      • Transaction Model
      • Transaction Fees
      • Transaction Calculation
      • Meta Transaction Features
        • Transaction Uniqueness
        • Controllable Transaction Lifecycle
        • Clauses (Multi-Task Transaction)
        • Fee Delegation
          • Multi-Party Payment (MPP)
          • Designated Gas Payer (VIP-191)
        • Transaction Dependency
    • Block Explorers
    • Wallets
      • VeWorld
        • User Guide
          • Setup
          • Wallet
          • Signing
          • Activities
          • Settings
        • FAQ
      • Sync2
        • User Guide
          • Setup
          • Wallet
          • Signing
          • Activities
          • Settings
        • FAQ
      • Sync
        • User Guide
          • Wallet
          • Ledger Device
          • Browser dApps and web
          • Interact with dApps
          • Activities
          • Settings
          • Report an Issue
          • Contributing
        • FAQ
    • EVM Compatibility
      • VeChain Modifications
      • Methodology
      • Test Coverage
        • Gas model
        • Raw transaction
        • hardhat specific
          • Ganache failures
          • evm_increaseTime
        • Failures in constructor
        • eth_sign
        • Contract address prediction
        • BadBeacon proxy address at 0x1
      • How to Recreate
      • Additional Information
        • Using Governance Contracts
        • ERC1820/ERC777 Testnet
        • Delegate Options
    • Account Abstraction
      • UserOperation
      • Bundler
      • EntryPoint Contract
      • Account Factory Contract
      • Paymaster Contract
    • Token Bound Accounts
  • How to run a node
    • Nodes
    • How to run a Thor Solo Node
    • Custom Network
    • Connect Sync2 to a Thor Solo Node
  • Developer Resources
    • Getting Started
    • How to build on VeChain
      • Connect to the Network
      • Read Data
        • Read Blocks
        • Read Transactions
        • Read Accounts
        • States & Views
        • Events & Logs
        • VET Transfers
      • Write Data
        • Transactions
        • Fee Delegation
      • Listen to Changes
        • Events
        • VET Transfers
        • Transactions
        • Blocks
        • Beats
      • Build with Hardhat
      • Utilities
        • BigInt and Unit-Handling
        • Name Service Lookups
    • Example dApps
      • Buy me a Coffee
      • Token Bound Accounts
      • PWA with Privy and Account Abstraction
    • EVM Compatibility for Developers
      • Key Architectural Differences and Optimizations
      • Practical Implications for Developers: Key Considerations
      • RPC Methods (Detailed Breakdown)
      • Frequently Asked Questions (FAQs)
      • VeChain Blockchain Specifications
      • Key Differences Between VeChain and Ethereum (Summary)
      • Best Practices for Developing on VeChainThor
    • How to verify Address-Ownership
      • Next.js Session Verification
    • Debug Reverted Transactions
    • Account Abstraction
    • VIP-191: Designated Gas Payer
      • How to Integrate VIP-191 (I)
      • How to Integrate VIP-191 (II)
      • How to Integrate VIP-191 (III)
    • Index with Graph Node
      • Setup with Docker
      • Index with OpenZeppelin
        • Create Subgraph Project
        • Configure Contracts
        • Deploy Subgraph and start Indexing
        • Track Subgraph Indexing
        • Access Subgraph
        • Update Subgraph
    • SDKs & Providers
      • SDK
        • Architecture
        • Accounts
        • Bloom Filter
        • Certificates
        • Contracts
        • Cryptography
        • Debug
        • Encoding
        • Polls
        • Subscriptions
        • Thor Client
        • Transactions
      • Thor DevKit
        • Installation
        • Usage
          • Cryptography
          • Accounts
          • Encoding
          • Transactions
          • Certificates
          • Bloom Filter
      • DApp Kit
        • v2
          • Installation
          • React
            • Installation
            • Usage
          • Vanilla JS
            • Installation
            • Usage
          • Core
            • Installation
            • Usage
          • Theme Variables
          • i18n
        • v1
          • Installation
          • React
            • Installation
            • Usage
          • Vanilla JS
            • Installation
            • Usage
          • Core
            • Installation
            • Usage
          • Theme Variables
          • i18n
          • Node Polyfills
          • V0 to V1
        • v0
          • Installation
          • Usage
          • React
            • Installation
            • Usage
          • Vanilla (UI)
            • Installation
            • Usage
          • Styles (UI)
          • i18n
      • DevPal
      • Web3-Providers-Connex
        • Installation
        • Usage
      • Connex
        • Installation
        • API Specification
    • Frameworks & IDEs
      • Hardhat
      • Remix
    • Built-in Contracts
    • VORJ
    • Useful Links
  • How to contribute
Powered by GitBook
On this page
  • TL;DR
  • Introduction
  • Traditional Blockchain Interaction: Externally Owned Accounts (EOAs)
  • Limitations of EOAs
  • The Solution: Account Abstraction
  • How Account Abstraction Works
  • Key Participants
  • Key Smart Contracts
  • Key Data Structure
  • ERC-4337 Workflow Overview

Was this helpful?

  1. Core Concepts

Account Abstraction

Programmable smart contract wallets for enhanced user experience and security.

The implementation of account abstraction is work in progress. The details provided here are subject to change as development progresses.

TL;DR

Account abstraction transforms traditional blockchain wallets by making them programmable through smart contract wallets. It abstracts the transaction-signing process, significantly enhancing user experience and security. This innovation aims to onboard a broader audience from Web2 to Web3 by normalizing blockchain interactions.

For hands-on exploration of account abstraction, refer to our https://github.com/vechain/vechain-docs/blob/main/start-building/tutorials/account-abstraction.md guide.

Introduction

Account abstraction is a new approach to make blockchain accounts programmable through smart contract wallets. To understand its significance, it's essential to grasp how users currently interact with blockchains.

Traditional Blockchain Interaction: Externally Owned Accounts (EOAs)

Most of the interaction with a blockchain, including VeChain, are initiated by externally owned account (EOA) through non-custodial wallets. People need to sign a transaction with their private key to spend their money. Possession of the private key grants control over the wallet’s assets, that once lost can't be recovered. Since it was error prone to write down a long hex string, a mnemonic seed phrase (mnemonic in brief) is usually the information that needs to be stored off-line in a safe location. A mnemonic is a set of words representing a random point on a cryptographic curve, usually 12 or 24, from which the key pair can be derived. The EOA will be created at the first usage. Just like with the pure private key, losing this seed phrase can result in permanent loss of access. This seed phrase is used to generate the private key, which is then used to sign transactions. Each and every blockchain transaction requires a signature proving to the blockchain that the user has initiated the transaction from its account. Examples of non-custodial wallets are VeWorld and MetaMask.

Limitations of EOAs

EOAs come with several drawbacks:

  • Lack of programmability/flexibility.

  • Poor user experience due to manual transaction signing.

  • Security risks due to the private key being unique point of failure with no recourse.

The Solution: Account Abstraction

Smart contract wallets offer an improved user experience by abstracting the signing of transactions which will offer a dramatic increase in the user experience. Abstracting away the necessity to sign each and every transaction combined with features such as trusted sessions, social recovery and batch transactions will transform the blockchain user experience.

Smart contract wallets also offer improved security through the ability to flexibly incorporate account recovery methods. Security improvements such as multisig authorization, sharing account security across devices or individuals and the use of whitelists to protect users accounts, just to name a few potential candidates.

Currently, the user experience and improved security benefits are not natively supported as only EOAs can initiate transactions. Account abstraction paves the way for smart contracts to initiate transactions, allowing users to code their desired logic directly into the smart contract wallet for execution on the blockchain.

How Account Abstraction Works

Account abstraction formalized through ERC-4337 introduces new participants, contracts, and data structures. If you wish to read more on how it works the following resources are a good starting point:

Key Participants

Account abstraction introduces new participants:

  • Users: Individuals/entities owning EOAs that interact with the blockchain through UserOperations.

  • Bundlers: Nodes that package UserOperations from a public mempool into transactions for execution.

  • Paymasters: Optional actors that sponsor transaction fees, enabling innovative mechanisms for fee payment.

  • Aggregators: Optimize transactions by compressing multiple signatures into one, reducing costs.

Key Smart Contracts

Account abstraction introduces several new smart contracts. These smart contracts and their roles are briefly described below:

  • EntryPoint Contract: A central contract that verifies and executes bundled UserOperations.

  • Account Factory Contract: Responsible for creating smart contract wallets.

  • Account Contract: Represents a user’s programmable wallet.

  • Paymaster Contract: Optionally facilitates transaction fee sponsorship.

Key Data Structure

Account abstraction introduces a new data structure:

  • UserOperation: A data object representing a user’s intent to perform a blockchain transaction with the smart account wallet. It includes the code to deploy the account if not yet onchain, data that should be executed, and a proof of ownership (usually a signature to be verified). A UserOperation is sent from a User via a Client into the alternative mempool through a specific RPC server, where it is collected by a Bundler. The Bundler then converts a UserOperation into a transaction.

ERC-4337 Workflow Overview

There are several participants and smart contracts involved in the account abstraction flow. Ultimately, the objective is to convert UserOperations into transactions through the ERC-4337 standards.

From the diagram below we can see that the first actor is a User who initiates a UserOperation. A UserOperation is a pseudo-transaction object which represents the Users intent to perform a transaction. An example of a UserOperation could be instructions to deploy a new Account contract, send a token or make a contract call.

The UserOperation is sent to a Bundler. The Bundler is an actor that packages UserOperations from a public mempool into a transaction which is sent to the EntryPoint contract on the blockchain for execution. The Bundler is a node and is rewarded for their work through a fee which is paid by the User to the Bundler.

The EntryPoint contract is the smart contract that handles the verification and execution logic of transactions. The EntryPoint contract interacts with the Account contract of the user. The purpose of this interaction is to verify the UserOperation and process the transaction.

There are some additional actors that we have not yet discussed. The Account Factory contract is a contract that is called when using a wallet for the first time. This is represented in a UserOperation through the initCode field which is used to specify the creation of a smart contract wallet. A Paymaster contract is an optional actor that can sponsor gas fees for smart contract wallets. An Aggregator is another actor, which is not represented on the image below, that can be used to compress multiple signature into a single signature with the purpose of minimising transaction fees.

PreviousDelegate OptionsNextUserOperation

Last updated 1 month ago

Was this helpful?

ERC-4337 Documentation
Official ERC-4337 Ethereum Site
Diagram from
Architecture from
erc4337.io/docs
erc4337.io/docs