"Fast" is the most abused word in this industry. A chain can author blocks quickly and still leave users waiting for a guarantee that their payment cannot be reversed. EmpoorioChain separates those two ideas on purpose, and asks every client in the ecosystem — Eoonia Wallet, EmpooScan, the SDKs — to show the difference.
Three states, not one
An operation on EmpoorioChain passes through three states:
- Submitted. The wallet or SDK sent the signed extrinsic to an RPC node. It is in the transaction pool. Nothing is guaranteed.
- Included. The extrinsic appeared in a block authored by Aura. It has been executed and its effects are visible in the latest state — but the block could still, in principle, be dropped in a reorganisation.
- Finalized. GRANDPA has finalized the block. For everyday UX this is the point of no return.
Eoonia shows a pending indicator until inclusion and a confirmed state only at finality. EmpooScan labels blocks as finalized or not. An included operation must never be presented as final. That rule is written into the consensus documentation, and the client audits check for it.
Six-second blocks
Aura authors one block per 6-second slot. That number is a design choice, not a limit: shorter slots increase the risk that validators far apart on the network miss each other's blocks; longer slots make the chain feel sluggish. Six seconds keeps the testnet's two validators — both currently in one hosting provider, which is itself a known limitation — comfortably in sync while leaving room for a geographically spread validator set later.
What was actually measured
In the May 2026 mixed-load benchmark on the testnet — native transfers, DEX swaps, lending, staking and read pressure, 700 transactions sent in bursts of 25 — the results were:
| Metric | Value |
|---|---|
| Transactions sent | 700 |
| Included | 700 |
| Finalized | 700 |
| Failure rate | 0.00 % |
| Inclusion latency p50 / p95 / p99 | 3.5 s / 4.2 s / 4.3 s |
| Finality latency p50 / p95 / p99 | 17.0 s / 17.7 s / 17.7 s |
Read that carefully. Inclusion inside a single block interval is what a 6-second slot buys you. Finality took about three blocks — GRANDPA votes on chains of blocks, not on each block individually, so this is expected behaviour, and it is the number a payment app should design around.
The same report is blunt about the rest: the sustained-throughput target (1,000 native transfers per second) was not demonstrated in that run, and the report states in its own words that it is not a mainnet-launch claim. Mainnet remains gated behind a readiness checklist that includes multi-validator runs under load.
Why this matters more than the headline number
A chain that reports "400 ms" without saying what state that refers to is not telling you anything you can build on. Six seconds to inclusion and roughly seventeen to finality, measured, with a zero failure rate, is a number a merchant integration can reason about: show the customer "received" at inclusion, release the goods at finality.
Based on CONSENSUS_STATUS.md and the testnet PERFORMANCE_REPORT.md (2026-05-30). Figures are testnet measurements, not mainnet claims.