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

# Transaction Flow

> Learn how Abstract processes transactions step-by-step using native account abstraction.

*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](/how-abstract-works/architecture/transaction-lifecycle).*

Since all accounts on Abstract are smart contracts, all transactions go through the same flow:

<Steps>
  <Step title="Submitting transactions">
    Transactions are submitted to the network via [JSON-RPC](https://ethereum.org/en/developers/docs/apis/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.
  </Step>

  <Step title="Bootloader processing">
    The [bootloader](/how-abstract-works/system-contracts/bootloader) reads transactions from the mempool
    and processes them in batches.

    Before each transaction starts, the system queries the [NonceHolder](/how-abstract-works/system-contracts/list-of-system-contracts#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](/how-abstract-works/native-account-abstraction/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](/how-abstract-works/native-account-abstraction/smart-contract-wallets#defaultaccount-contract).

    <Card title="Bootloader system contract" icon="boot" href="/how-abstract-works/system-contracts/bootloader">
      Learn more about the bootloader system contract and its role in processing transactions.
    </Card>
  </Step>

  <Step title="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.

    <Card title="Smart contract wallets" icon="wallet" href="/how-abstract-works/native-account-abstraction/smart-contract-wallets">
      Learn more about how smart contract wallets work and how to build one.
    </Card>
  </Step>

  <Step title="Paymasters (optional)">
    If a paymaster is set, the bootloader calls the following [paymaster](/how-abstract-works/native-account-abstraction/paymasters) 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.

    <Card title="Paymasters" icon="sack-dollar" href="/how-abstract-works/native-account-abstraction/paymasters">
      Learn more about how paymasters work and how to build one.
    </Card>
  </Step>
</Steps>