Transaction Lifecycle
The journey of a transaction from submission to finalization, through the mempool, AnteHandler validation, and block inclusion.
Understanding the transaction lifecycle on Maroo is key to building reliable applications. When a user submits a transaction, it doesn't immediately get included in a block. Instead, it passes through a series of critical stages including mempool acceptance, rigorous validation by the AnteHandler chain, and finally, execution by the EVM and inclusion in a block by a validator. This process ensures the integrity, security, and proper ordering of all state changes on the network.
1. Mempool Submission and Propagation
A transaction's journey begins when it is submitted to a Maroo node's RPC endpoint. The node first performs basic sanity checks. If it passes, the transaction is added to the node's local mempool, which is a waiting area for pending transactions. The node then gossips the transaction to its peers, propagating it across the network so other validators also become aware of it. Maroo's mempool, configured in
app/mempool.go, is EVM-aware and can prioritize transactions based on the gas price (tip).2. AnteHandler Validation
Before a validator includes a transaction in a proposed block, it runs the transaction through the
If any of these checks fail, the transaction is rejected and not included in a block.
AnteHandler chain. This is a critical, stateful validation step. The chain, constructed by NewAppAnteHandler in ante/ante.go, performs a series of checks in order:- Signature Verification: Confirms the transaction was signed by the claimed sender.
- Nonce Check: Ensures the transaction has the correct sequence number to prevent replay attacks.
- Fee Deduction: Checks if the sender has enough
aokrwto cover the gas fees and deducts them. - Gas Limit Validation: Verifies that the transaction's gas limit is within acceptable bounds.
If any of these checks fail, the transaction is rejected and not included in a block.
3. Block Proposal and Execution
A validator chosen to propose the next block selects a set of valid transactions from its mempool, usually prioritizing those with higher fees. These transactions are ordered and included in a new block proposal, which is then broadcast to the rest of the network for consensus.
4. Consensus and Finalization
Other validators receive the proposed block, re-run the transactions to verify the resulting state changes, and vote on the block's validity. Once a supermajority (2/3+) of validators agree, the block is committed to the blockchain. At this point, the transaction is considered finalized, and its state changes (e.g., token transfers, smart contract state updates) are permanently recorded.