Skip to main content
Transaction aggregation combines multiple user transactions into a single onchain transaction, sharing execution costs across participants and reducing per-transaction overhead.

​
How Transaction Aggregation Works

DA Builder collects transactions from multiple users, validates them, and combines them into a single aggregated transaction that executes all operations atomically.

​
The Aggregation Process

  1. Transaction Submission: Users submit transactions to DA Builder’s RPC endpoint
  2. Collection: DA Builder collects multiple transactions in a mempool
  3. Validation: Each transaction is validated for correctness and funding
  4. Batching: Valid transactions are combined into a single aggregated transaction
  5. Execution: The aggregated transaction executes all user operations in sequence
  6. Settlement: Costs are calculated and charged to each participant

​
Execution Model

The aggregated transaction uses a multicall pattern where:
  • Each user’s transaction is executed as a call to their EIP-7702 account code
  • The ProposerMulticall contract orchestrates execution
  • All calls execute in a single atomic transaction
  • Gas costs are shared across all participants

​
Cost Benefits

​
Shared Execution Costs

The minimum transaction overhead (21,000 gas) is paid once and split across all aggregated transactions. For example:
  • Single transaction: Pays full 21k gas minimum
  • 10 aggregated transactions: Each pays ~2.1k gas (21k / 10)
  • Savings: 90% reduction in per-transaction overhead

​
Proportional Gas Sharing

Execution gas is charged based on actual usage:
  • Each transaction pays for its own gas consumption
  • Intrinsic gas costs are shared proportionally
  • Large transactions pay more, small transactions pay less
  • Fair cost distribution based on actual resource usage

​
Security Model

Transaction aggregation maintains security through:

​
EIP-7702 Account Code

Users set EIP-7702 account code that implements the IProposer interface. This allows:
  • DA Builder to execute transactions on behalf of users
  • Users to maintain control through cryptographic signatures
  • Trustless execution through signature verification

​
Trustless Proposer

The recommended TrustlessProposer implementation requires:
  • EIP-712 signatures for each transaction
  • Nonce protection to prevent replay attacks
  • Deadline protection to prevent stale transactions
  • Gas limit enforcement to prevent excessive consumption
Only transactions signed by the account owner can be executed, ensuring security while enabling aggregation.

​
Transaction Types Supported

DA Builder aggregates various transaction types:
  • Blob transactions (EIP-4844): For rollup data submission
  • Standard transactions: For contract calls and transfers
  • Bundle transactions: Simplified bundle format with single transaction
All transaction types benefit from shared execution costs when aggregated.

​
Aggregation vs. Direct Submission

​
Aggregated Transactions

  • Cost: Shared execution overhead, lower per-transaction cost
  • Speed: Faster inclusion through premium positioning
  • Protection: MEV protection and dual layer revert protection
  • Requirement: EIP-7702 setup and GasTank funding

​
Direct Submission

  • Cost: Full execution overhead per transaction
  • Speed: Standard mempool inclusion time
  • Protection: Standard Ethereum protection
  • Requirement: Standard wallet setup
Aggregation provides cost savings whenever multiple transactions can be combined, with no additional cost if aggregation isn’t possible.

​
Relationship to Blob Aggregation

Transaction aggregation and blob aggregation work together:
  • Transaction aggregation: Combines multiple transactions into one execution
  • Blob aggregation: Combines multiple blobs into one blob transaction
  • Combined: Multiple blob transactions can be aggregated together
See Blob Aggregation for details on blob-specific aggregation.

​
Benefits Summary

Transaction aggregation provides:
  • Cost reduction: Shared execution overhead reduces per-transaction costs
  • Faster inclusion: Aggregated transactions gain priority positioning
  • Better positioning: Favorable positioning in blocks
  • MEV protection: Protection from frontrunning and sandwich attacks
  • Dual layer revert protection: Multi-layered protection against transaction reverts

​
Next Steps