Bundler

A bundler is a permissionless actor that:

• Accepts operations from users
• Batches them together
• Submits them onchain
• Gets reimbursed for gas costs + commission

How Bundlers Work

Step 1: Bundler Configuration

Anyone can run a bundler. When launching, the bundler defines:

1. Accepted gas assets:

   • Which tokens they'll accept as payment (e.g., USDC, WETH, USDT)
   • Conversion rate oracles relative to native gas token

2. Commission structure:

   • Base gas cost (actual ETH spent onchain)
   • Fixed commission markup (e.g., 2 USDC)

Step 2: User Submits Operation

The user generates an operation, a zk-SNARK proof that authorizes a transaction (e.g., transferring tokens, interacting with a DApp).

What the operation includes:

• The action to perform (transfer, contract call, etc.)
• Input notes being spent
• Output notes being created
• Gas payment note: A commitment to pay the bundler in a specified asset

Key property: The operation is cryptographically valid and the bundler doesn't need to trust the user, they can verify everything onchain.

The user then sends this operation to their chosen bundler (offchain, via RPC or relayer network).

Step 3: Bundler Simulates the Operation

Before accepting the operation, the bundler simulates it onchain to verify:

Gas cost estimation:

• How much gas will this operation consume?
• Is the user paying enough to cover gas + commission?

Validity checks:

• Does the proof verify?
• Are the input notes unspent?
• Is the gas payment note sufficient?

Step 4: Batching and Execution

The bundler collects multiple operations and batches them into a single onchain transaction and then submits the batched transaction to the Master Account.

Future Work

• Route payments via Unified ERC-4337 Mempool.
• Replace fixed commission with a priority fees.
• Current limitations with exisiting bundlers:
  • Most bundlers currently support only one EIP-7702 authorization per userOp.
  • Censorship resistance is not guaranteed: can be solved with FOCIL.