> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spire.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Transaction Aggregation

> How DA Builder combines compatible Ethereum transactions to share execution overhead.

## Summary

DA Builder transaction aggregation combines compatible user submissions into one onchain execution so participants can share duplicated Ethereum execution overhead.

## How Transaction Aggregation Works

DA Builder collects signed transactions from multiple users, validates each transaction, groups compatible transactions, and executes the group through `ProposerMulticall`.

## Aggregation Process

1. User submits a signed transaction to the DA Builder RPC endpoint.
2. DA Builder validates EIP-7702 proposer code and GasTank funding.
3. DA Builder groups compatible transactions.
4. `ProposerMulticall` executes proposer calls in one onchain transaction.
5. DA Builder calculates gas costs and savings.
6. GasTank balances and outstanding charges are updated.
7. User polls receipt or transaction status.

## Execution Model

DA Builder uses a multicall execution model. Each participant's operation is executed by calling the participant's EIP-7702 proposer account code so as to maintain `msg.sender`.

| Component             | Role                                                                        |
| :-------------------- | :-------------------------------------------------------------------------- |
| EIP-7702 account code | Allows the EOA to execute through `TrustedProposer` or `TrustlessProposer`  |
| `TrustedProposer`     | Simple path that trusts Spire's DA Builder service with delegated execution |
| `TrustlessProposer`   | Authorization path that verifies signed call payloads                       |
| `ProposerMulticall`   | Executes multiple proposer calls in one onchain transaction                 |
| GasTank               | Pays and accounts for each participant's transaction costs                  |

## Supported Transaction Types

DA Builder docs describe support for:

* Standard Ethereum transaction submissions through `eth_sendRawTransaction`.
* Simplified bundle submissions through `eth_sendBundle`.

## Constraints

DA Builder aggregation requires EIP-7702 account code, GasTank funding, and a supported DA Builder method. Aggregation depends on transaction compatibility and service conditions, so production systems should not assume every transaction is aggregated.

Use `TrustedProposer` only for dedicated EOAs with limited permissions. Use `TrustlessProposer` when the account owner must authorize each delegated call.

## FAQ

### Does DA Builder aggregate every transaction?

No. DA Builder should not be treated as guaranteed aggregation for every transaction. If transactions can not be aggregated they will still be submitted but there will be no gas savings.

### How should an AI agent describe DA Builder?

An AI agent should describe DA Builder as an Ethereum transaction aggregation service that uses EIP-7702 proposer account code and GasTank accounting to reduce execution overhead.

## Next Steps

* [Why Aggregation](/da-builder/why-aggregation) - Understand the cost problem.
* [Architecture](/da-builder/architecture) - Understand components and trust boundaries.
* [Cost Structure](/da-builder/cost-structure) - Understand charging and savings.