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 JSON-RPC endpoint (the same
eth_sendRawTransaction shape any EVM tool already speaks). The node performs basic sanity checks; if it passes, the transaction enters the node's local mempool — a waiting area for pending transactions. The node gossips the transaction to its peers so the rest of the network sees it. Maroo's mempool is EVM-aware and prioritizes by effective gas price (tip).2. AnteHandler Validation
Before a validator includes a transaction in a proposed block, it runs through the
Any single failure rejects the transaction with a typed error — either a stock SDK error (signature/nonce/fees) or a PCL ReasonCode (compliance).
AnteHandler — a chain of stateful checks executed in order:- Signature verification: confirms the transaction was signed by the claimed sender.
- Nonce check: blocks replays by requiring the correct sequence number.
- Fee deduction: confirms the sender has enough
aokrwfor the gas budget and deducts it. - Gas limit validation: bounds the per-tx gas at network params.
- PCL evaluation: every active GlobalPolicyConfig PolicySet is evaluated against the tx (denylists, KYC, volume, period). See
pcl-policy-enforcement.
Any single failure rejects the transaction with a typed error — either a stock SDK error (signature/nonce/fees) or a PCL ReasonCode (compliance).
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.