Transaction lifecycle: from submission to result
Development status: Experimental implementation exists — An experimental implementation exists; this page describes the intended public developer capability. In an internal prototype, transactions can be submitted, given initial checks, executed deterministically and recorded in node state, and their status can be queried; finality is not connected, so no transaction is reported as final. The prototype is internal only, and nothing is publicly available for live use.
Before you read: System model: how Cubane is intended to work for its users.
What happens, at a level a developer could see, between submitting a transaction and seeing its result? This page follows a transaction through the intended stages, states which of them the experimental implementation exercises, explains what a submitter could observe and gives conditional guidance for designing applications around the lifecycle. It describes what a submitter would see, not how the network processes transactions internally.
Two kinds of work
Cubane’s design distinguishes two kinds of work, and each has its own user-visible lifecycle:
- Transactions — ordinary requests to change recorded state. A transaction moves from submission to a recorded result, and this page follows it.
- Confidential jobs — long-running confidential computations that an application would follow over time, with results retrieved later. Their intended lifecycle is on Confidential jobs: tracking, cancelling and retrieving results.
The stage names in italics below — submitted, validated, admitted, refused, propagated, executed, recorded and final — are documentation terms defined on Lifecycle stages used in this documentation. They are not protocol status values, receipt contents or interface fields, and they are listed in reading order only.
The intended stages
Submission
Status of this stage: Experimental implementation exists — internal prototype only.
An application or wallet sends a transaction to a node. The transaction is then submitted: it has been handed over, but nothing has yet been decided about it. The planned developer experience would let applications and wallets submit transactions through a released interface. No interface, message format or client library is published, and none is described here.
Validation and admission
Status of this stage: Experimental implementation exists — internal prototype only.
The node runs initial checks on the transaction and decides whether to accept it for further processing. A transaction that has passed the initial checks is validated; one that has been accepted for further processing is admitted; one that has not been accepted is refused, and the reasons fall into the categories on What can go wrong: failure and error concepts.
Passing the initial checks does not by itself mean that the sender was authenticated or that the transaction cannot be repeated. The checks themselves are not described.
When a node is busy, it may slow down or refuse new submissions rather than accept work it cannot handle. This behaviour, and the absence of any service level today, are described on Service levels and admission control.
Propagation
Status of this stage: Planned — part of the intended lifecycle; this page does not describe it as exercised by the internal prototype.
In the intended design, admitted transactions are passed between nodes, so that the network rather than a single node can process them; a transaction that has been passed on is propagated. A submitter would not normally observe this stage directly. Experimental networking between nodes is described separately on Peer-to-peer networking.
Execution
Status of this stage: Experimental implementation exists — internal prototype only.
Transactions are processed deterministically, so that nodes processing the same input are intended to reach the same result; a transaction that has been processed is executed. For developers, deterministic execution means that results are meant to be reproducible: the same transaction applied to the same state is intended to have the same effect wherever it is processed. No published evidence yet establishes deterministic execution across nodes. How execution is organised internally is not described, and no compatibility with any other platform’s execution environment is claimed.
Recorded state
Status of this stage: Experimental implementation exists — internal prototype only.
The effects of an executed transaction are reflected in node state, and the transaction is then recorded. Node state can be committed under a cryptographic root, and an inclusion proof can show that a particular value is part of that committed state; Committed state and inclusion proofs explains both. Recorded is not final: an inclusion proof shows that a value is part of recorded state, not that the state can no longer change.
Status and finality
Status of this stage: Experimental implementation exists — a finality status query exists, but finality is not connected, so nothing is reported as final.
A submitter would be able to query a transaction’s status. A result is final at the point after which it is intended not to change. Today no result is reported as final: an experimental finality status query exists, but it reports nothing as final because finality is not connected. What final would mean in practice is described on Agreement and finality status.
The stages at a glance
The table below lines up each documentation-level stage with what a submitter provides or observes, what the experimental implementation exercises today and what is intended.
Illustrative local demo — not a released Cubane API, protocol schema or live-network result.
Table: transaction stages, as illustrative documentation text only.
| Stage | What the submitter provides or observes | What the experimental implementation exercises today | What is intended |
|---|---|---|---|
| Submission (submitted) | Provides a transaction through an application or wallet | Submission to a node, in an internal prototype | Submission through a released interface |
| Validation and admission (validated, admitted or refused) | Observes whether the transaction was accepted or refused | Initial checks and an accept-or-refuse decision, in an internal prototype | Initial checks before acceptance, with documented behaviour when the network is busy; passing the checks is not an assurance about the sender or against repetition |
| Propagation (propagated) | Nothing directly | Not described on this page | Admitted transactions passed between nodes |
| Execution (executed) | Observes whether the transaction has executed | Deterministic execution, in an internal prototype | Deterministic execution, so that nodes processing the same input reach the same result |
| Recorded state (recorded) | Observes the effect that was recorded | Effects recorded in node state committed under a cryptographic root, with inclusion proofs | Recorded effects that could be checked against committed state |
| Status and finality (final) | Queries status, and sees that nothing is reported as final | A finality status query that reports nothing as final, because finality is not connected | A documented point after which a recorded result is intended not to change |
The table is hardcoded documentation text written for this page, not output from any system. It demonstrates how the documentation’s stage terms relate to what a submitter would see, what the internal prototype exercises and what is intended. Nothing was submitted, checked, passed between nodes, executed, recorded or finalised, and no encryption, authorisation, proof or agreement between nodes took place. Finality is not connected in the experimental implementation. Stage and column names are documentation terms, not interface fields or status values.
What the experimental implementation exercises
Status of this section: Experimental implementation exists — internal prototype only; not released.
- The internal prototype exercises submission, initial checks and admission, deterministic execution and the recording of state on a node, and a transaction’s status can be queried. The finality component is not connected.
- It is a prototype for protocol development, not a release. Its behaviour, limits and interfaces may change without notice.
- Confidentiality and proving features are simulated, and several features of how the network agrees on results are simulated or not connected. The full list is on Known limitations of the experimental prototype.
- No fees are charged; see Fees and cost estimates.
What a submitter would observe, and what not
In the intended experience, a submitter would be able to observe:
- whether a submission was accepted or refused;
- whether the transaction has executed, and what effect was recorded;
- that finality is not yet reported.
Refusals and failures would fall into the documented categories on What can go wrong: failure and error concepts; no error codes are published. Message contents, status values and internal processing steps are not described.
Designing for the lifecycle
Once this capability is implemented, enabled and publicly released, developers are expected to design around the lifecycle as follows. The same advice applies to planning today.
- Treat results as provisional until a documented finality status exists, and make that distinction visible to your users — for example, by showing a recorded result differently from a final one.
- Expect refusal and delay. Submissions may be refused or slowed when the network is busy. Handle that case explicitly rather than assume success.
- Confirm before you rely on it. Do not assume a submission succeeded until its status confirms it, and check the status of an earlier submission before sending it again.
- Depend only on documented behaviour. Do not build on any behaviour of the experimental implementation that is not documented here; it may change without notice.
Assumptions, trust and limitations
- Passing the initial checks is not an assurance about the sender and not a protection against replay.
- Deterministic execution is a design intent of the experimental implementation; no published evidence establishes it across nodes.
- The experimental implementation provides no finality and no confidentiality protection, and it charges no fees.
- The stages describe what a submitter could observe; they are not a description of the network’s internal processing.
Not yet available, and how this page will grow
Exact interfaces, message formats, status values and error codes are not yet available. Once released, this page would link to versioned interface reference and to documented finality semantics. Further technical reference is not yet available.
What this page does not claim
This page does not claim that any part of the lifecycle is available for use, that any result is final, any performance or capacity figure, or compatibility of any kind with other platforms or their interfaces. Anything not stated here as available should be treated as unavailable.
Related pages
- Lifecycle stages used in this documentation — definitions of the stage terms used here.
- Confidential jobs: tracking, cancelling and retrieving results — the lifecycle for long-running confidential work.
- Agreement and finality status — the finality status query and its limitation.
- Service levels and admission control — what happens when the network is busy.
- Committed state and inclusion proofs — how recorded state can be checked.
- What can go wrong: failure and error concepts — failure categories to design for.
- Known limitations of the experimental prototype — the full list of current limits.
Glossary
- Transaction
- Node
- Validation
- Admission control
- Backpressure
- Deterministic execution
- Inclusion proof
- Finality
References
No approved public references yet.
