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
Transaction Submission : Users submit transactions to DA Builder’s RPC endpointCollection : DA Builder collects multiple transactions in a mempoolValidation : Each transaction is validated for correctness and fundingBatching : Valid transactions are combined into a single aggregated transactionExecution : The aggregated transaction executes all user operations in sequenceSettlement : 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 minimum10 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 submissionStandard transactions : For contract calls and transfersBundle 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 costSpeed : Faster inclusion through premium positioningProtection : MEV protection and dual layer revert protectionRequirement : EIP-7702 setup and GasTank funding
Direct Submission
Cost : Full execution overhead per transactionSpeed : Standard mempool inclusion timeProtection : Standard Ethereum protectionRequirement : 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 executionBlob aggregation : Combines multiple blobs into one blob transactionCombined : 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 costsFaster inclusion : Aggregated transactions gain priority positioningBetter positioning : Favorable positioning in blocksMEV protection : Protection from frontrunning and sandwich attacksDual layer revert protection : Multi-layered protection against transaction reverts
Next Steps 
