Note: This page outlines the flow of transactions on Abstract, not including how they are batched, sequenced and verified on Ethereum. For a higher-level overview of how transactions are finalized, see Transaction Lifecycle. Since all accounts on Abstract are smart contracts, all transactions go through the same flow:
1

Submitting transactions

Transactions are submitted to the network via JSON-RPC and arrive in the transaction mempool. Since it is up to the smart contract account to determine how to validate transactions, the from field can be set to a smart contract address in this step and submitted to the network.
2

Bootloader processing

The bootloader reads transactions from the mempool and processes them in batches.Before each transaction starts, the system queries the NonceHolder system contract to check whether the provided nonce has already been used or not. If it has not been used, the process continues. Learn more on handling nonces.For each transaction, the bootloader reads the tx.from field and checks if there is any contract code deployed at that address. If there is no contract code, it assumes the sender account is an EOA and converts it to a DefaultAccount.

Bootloader system contract

Learn more about the bootloader system contract and its role in processing transactions.
3

Smart contract account validation & execution

The bootloader then calls the following functions on the account deployed at the tx.from address:
  1. validateTransaction: Determine whether or not to execute the transaction. Typically, some kind of checks are performed in this step to restrict who can use the account.
  2. executeTransaction: Execute the transaction if validation is passed.
  3. Either payForTransaction or prepareForPaymaster: Pay the gas fee or request a paymaster to pay the gas fee for this transaction.
The msg.sender is set as the bootloader’s contract address for these function calls.

Smart contract wallets

Learn more about how smart contract wallets work and how to build one.
4

Paymasters (optional)

If a paymaster is set, the bootloader calls the following paymaster functions:
  1. validateAndPayForPaymasterTransaction: Determine whether or not to pay for the transaction, and if so, pay the calculated gas fee for the transaction.
  2. postTransaction: Optionally run some logic after the transaction has been executed.
The msg.sender is set as the bootloader’s contract address for these function calls.

Paymasters

Learn more about how paymasters work and how to build one.