How transactions settle
Submitted, confirmed, and indexed are different states. Learn what each state proves before you act on it.
Every on-chain action in Real goes through the same states. This is true in the investor portal, the issuer portal, the Business Validator dashboard, and your own application. This page explains the states once. Other pages link here.
The four states
| State | What happened | What it proves |
|---|---|---|
| Awaiting signature | The application prepared the transaction. Your wallet, or each required Safe owner, must approve it. | Nothing has happened on-chain. |
| Submitted | A node accepted the signed transaction and returned a transaction hash. | Only that someone sent the transaction. |
| Confirmed | The block is accepted and a receipt exists. | The receipt status tells you if the transaction executed or reverted. |
| Indexed | The indexer processed the block. Portals, dashboards, and APIs show the result. | The views caught up with the chain. |
Platform workflows can add a step before these states. For example, a request or a durable job can wait for an operator or for the platform. A queued job is not a submitted transaction.
A hash is not success
A transaction hash proves only that someone submitted the transaction. Wait for the receipt and check its status. A transaction that reverts is still recorded in an accepted block, and it can still use gas.
On Real Chain, an accepted block is final. See finality.
Allow for indexer delay
Portals, the dashboard, and the APIs read indexed data. The indexer can lag behind the chain. If the receipt shows success but a portal still shows old data, wait for the view to refresh. The chain state does not change while the view catches up.
On-chain time
Contracts check deadlines against the time of the latest block, not against your clock. On Real Testnet, the chain makes a block only when there is a transaction. So on-chain time can lag until a new transaction arrives. A read or preflight can show that a time has not passed yet, although it has on your clock.
Do not resubmit
Do not send a transaction again only because a view has not refreshed. First find the earlier transaction in the block explorer or in the portal's Activity page, and check its receipt.
If a platform request or job already exists, use it or its retry path. Do not create a duplicate. When the result of a submitted transaction is uncertain, an operator may have to resolve it.
A preflight is not a reservation
A preflight or a contract simulation checks a proposed transaction against the current state. It can explain a likely refusal. It does not reserve your balance, your eligibility, an order, or a quote. Another transaction or a rule change can alter the result before your transaction executes.
Only the executed transaction decides the outcome. Check again before you sign.
Safe threshold approvals
A Safe executes a transaction only after its configured threshold of owners approve it and someone submits the execution. When one owner signs in or signs, that does not count as every approval. Allow time for co-signatures. In the issuer portal, pending Safe proposals are on the Approvals page.