Transaction statuses

The Consensus v0.6 contracts define 14 numeric status values. A transaction has one stored, materialized status. Time-dependent lifecycle projection and the next resolution action are separate fields; finalization readiness is never synthesized as another status.

CodeStatusMeaning
0UninitializedNo transaction is initialized for this ID.
1PendingThe transaction is queued and waiting for activation.
2ProposingA leader is assigned and must propose an execution receipt.
3CommittingThe committee is submitting encrypted vote commitments.
4RevealingCommittee members are revealing their committed votes.
5AcceptedThe committee accepted the proposed receipt; the appeal window is open.
6UndeterminedThe round did not reach a result and no funded rotation remained; a leader appeal is possible.
7FinalizedThe appeal process is complete and finalization was recorded.
8CanceledThe transaction was canceled before completing consensus.
9AppealRevealingA fresh validator-appeal committee is revealing votes.
10AppealCommittingA fresh validator-appeal committee is committing votes.
11ValidatorsTimeoutA validator majority reported that validation timed out; the appeal window is open.
12LeaderTimeoutThe leader reported an execution timeout; the appeal window is open.
13LeaderRevealingThe leader must reveal execution data and keys before committee vote reveals.

Status is not execution success

Accepted means the validator committee reached consensus on the receipt. The receipt itself can represent a successful return, a user error, a GenVM error, or a timeout. Inspect the receipt's execution result in addition to its consensus status.

Similarly, Finalized means the decided receipt is no longer appealable. It does not convert an error result into a successful contract call.

Stored status and lifecycle projection

gen_getTransactionStatus returns only the exact stored status. A deadline passing does not change that response until a protocol action materializes a transition.

Advanced tooling can use gen_getTransactionLifecycle to read the stored status, its time-dependent projection, the active decision, and the resolution kernel's next action from one snapshot. When an appeal window has elapsed, the stored and projected statuses can both remain Accepted while resolutionAction is Finalize. There is deliberately no ReadyToFinalize status and no parallel canFinalize boolean.

Use the numeric codes for program logic and display the names to users. Bind decision-scoped actions only when the lifecycle response reports an active, non-null decisionId.