Summary
A transaction passes through three states: submitted, included in a block (Aura), and finalized (GRANDPA). Only a finalized transaction is safe to treat as irreversible.
The three real states
EmpoorioChain's consensus splits block production and finality into two separate mechanisms, and a transaction's lifecycle follows that split:
- Submitted — the extrinsic has been sent to a node and accepted into its transaction pool. It has not yet been included in any block and can still be dropped (invalid nonce, insufficient balance, pool eviction).
- Included — Aura (the block production mechanism) has included the extrinsic in a produced block. The block exists on some fork of the chain, but that fork is not yet guaranteed to be the one the network settles on.
- Finalized — GRANDPA (the finality mechanism) has finalized the block containing the extrinsic. A finalized block, and everything in it, cannot be reverted by a later reorganization.
An included-but-not-finalized transaction should never be presented to a user as final. Wait for finality (or a confirmed number of blocks past inclusion, per your risk tolerance) before treating a transaction's effects as permanent — for example, before releasing goods for an on-chain payment.
Other consensus components
- BEEFY and an MMR (Merkle Mountain Range) are also compiled into the runtime, used for compact bridge and light-client finality proofs. They are not the primary finality mechanism a typical application should watch — GRANDPA is.
- The runtime's source tree also contains research-stage HotStuff and Bullshark DAG-BFT consensus modules. These compile as part of the runtime crate but are not referenced by block production or the node's import queue — they are not live in production and should not be described as such in application-facing documentation.
Checking transaction status
Use the standard Substrate JSON-RPC surface to track a transaction through
these states — for example, subscribing to author_submitAndWatchExtrinsic
(or the equivalent method in your SDK of choice) reports status transitions
including inclusion in a block and, separately, finalization. Because this
is generic Substrate RPC behavior rather than something EmpoorioChain
customizes, see the Polkadot SDK RPC
reference for the exact method signatures.
EmpoorioChain also runs an Ethereum-compatible JSON-RPC surface (eth_*)
through its EVM pallet for Solidity tooling. Transactions submitted through
that surface follow the same underlying submitted → included → finalized
lifecycle, reported using Ethereum's own transaction-receipt conventions.
Is this page helpful?