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
  • Overview
  • Role
  • Security and Decentralization
  • Implementation

Was this helpful?

  1. Core Concepts
  2. Account Abstraction

Bundler

The core infrastructure component that packages UserOperations into transactions.

Overview

A Bundler plays a crucial role in the account abstraction architecture. Its primary responsibility is to collect these UserOperations from a public mempool, bundle them together, and pass them to the EntryPoint contract for execution.

The EntryPoint contract serves as a "global trusted singleton," meaning it is a single, universally trusted smart contract within the blockchain ecosystem. In reality it's not like that, in a public blockchain anyone can create and promote its EP, do your own research and trust the EP you can find on trusted websites only. This contract handles incoming transactions, validates them, and manages the execution of UserOperations. The Bundler acts as the intermediary between users and the EntryPoint contract, ensuring UserOperations are properly packaged and processed.

Unlike Paymaster or Account contract entities, which require individual smart contracts for each instance, the Bundler does not have its own smart contract. Instead, the Bundler uses an externally owned account (EOA) to execute on-chain transactions. This design simplifies its operation while maintaining its critical role in the system.

Role

The Bundler’s role in the account abstraction system is analogous to that of a miner or validator in traditional blockchain networks. It performs the following functions:

  • Monitoring and Aggregating: Continuously scans the public mempool for UserOperations submitted by users.

  • Packaging Transactions: Groups multiple UserOperations into a single transaction to optimize execution.

  • Submitting to EntryPoint: Passes the packaged transactions to the EntryPoint contract, ensuring they are executed in a reliable and timely manner.

  • Compensation: Receives rewards for successfully executing UserOperations. These rewards are paid by users as fees within the bundled transactions.

To perform these functions, a Bundler must:

  • Remain online consistently to monitor the mempool.

  • Maintain sufficient funds in its EOA to cover the cost of gas fees required for executing transactions.

Security and Decentralization

The decentralized nature of Bundlers contributes to the robustness and security of the account abstraction ecosystem. By allowing multiple independent Bundlers to operate, the system ensures:

  • Fault Tolerance: No single point of failure.

  • Fairness: Competition among Bundlers prevents monopolization.

  • Reliability: Ensures continuous availability of services for UserOperation execution.

Implementation

  • Open-Source Flexibility: Developers can adapt and customize the implementation for specific use cases.

  • Community Support: Backed by a community of contributors improving and maintaining the codebase.

PreviousUserOperationNextEntryPoint Contract

Last updated 1 month ago

Was this helpful?

Several Bundler implementations are available, with the most notable being the . This implementation was developed by the team behind the EIP-4337 proposal and is widely regarded as the standard for Bundler operations. It provides:

Infinitism Bundler