Transaction Flow

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.

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.

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 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.

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.