Agreement and finality status
Development status: Experimental implementation exists — An experimental implementation exists; this page describes the intended public developer capability. An experimental finality status query exists in an internal prototype; at this stage it does not report finalised blocks, because the finality component is not yet connected. No finality assurance is offered, and how the network is intended to agree on results is not described. Nothing is publicly available for live use.
Before you read: Transaction lifecycle: from submission to result.
When can you treat a result as final? Not yet. Today no result should be treated as final, and no finality assurance is offered. This page explains what finality means in this documentation, what the experimental status query reports and why, and how to design applications that keep recorded and final results apart.
What finality means in this documentation
Finality is the point after which a recorded result is intended not to change. A result can be recorded — its effects reflected in node state — without being final; the Glossary gives Cubane’s own definition of finality, marked for review, and Lifecycle stages used in this documentation defines recorded and final as separate stages.
Agreement is the network’s process of agreeing on results. Its design is not described in this documentation; this page covers only the status an application would see.
This documentation does not adopt other platforms’ finality levels or terms. Words such as “confirmed” or “settled” are not used as stage names, because their meanings differ across platforms, and no confirmation counts or comparable measures apply.
What exists today
Status of this section: Experimental implementation exists — internal prototype only; finality not connected.
- An experimental finality status query exists in an internal prototype.
- It does not report finalised blocks, because the finality component is not yet connected.
- Nothing in the prototype is final in the intended sense, and the query is not available publicly.
The query existing does not mean that finality exists: it can only report that nothing has been finalised. No query name, interface or status value is published.
When can I treat a result as final? Not yet
- Today: no result should be treated as final, and no finality assurance is offered. The experimental finality status query reports nothing as final, because the finality component is not yet connected.
- Intended: once this capability is implemented, enabled and publicly released, applications would be expected to check finality status before treating a result as final.
- To be documented with a release: what “final” would mean in practice, how long it would take and which conditions would apply. None of this is published.
Designing applications around finality
The planned developer experience would let an application check a documented finality status. Until then, and afterwards, the same design principles apply:
- Keep recorded and final apart. Treat them as separate in application logic and in what users are shown — for example, label a recorded result as not yet final rather than presenting it as complete.
- Avoid irreversible external actions on non-final results. Do not trigger actions outside the network that cannot be undone, such as releasing goods or funds elsewhere, on results that are not reported final.
- Plan for results to stay non-final. For as long as finality is unavailable, results remain not final; design your application so that it still behaves sensibly in that state.
Where finality status would be watched
- Basic node status and metrics surfaces are described on Node monitoring and observability.
- Research questions about how the network would keep operating when some participants are unavailable are recorded on Design note: operating under partial failure and evolving participation.
- The failure categories an application should design for are on What can go wrong: failure and error concepts.
Assumptions, trust and limitations
- No finality assurance is offered, and the trust assumptions behind agreement are not described publicly.
- This page describes a status capability and its current limitation, not the agreement design.
- The experimental query is internal; its behaviour is not evidence of how finality would behave in a released network.
Not yet available, and how this page will grow
Exact status values, the query interface and finality semantics are not yet available. Once agreement is implemented and released, this page would explain what each finality status means and how applications should use it. Further technical reference is not yet available.
What this page does not claim
This page does not claim any finality time, any fault-tolerance or safety property, or any comparison with other networks. It does not claim that any result is final today. Anything not stated here as available should be treated as unavailable.
Related pages
- Transaction lifecycle: from submission to result — where the status stage sits in the lifecycle.
- Known limitations of the experimental prototype — finality among the prototype’s limitations.
- Node monitoring and observability — basic status and metrics surfaces.
- Design note: operating under partial failure and evolving participation — research questions on behaviour under failure.
- Lifecycle stages used in this documentation — definitions of stage terms, including recorded and final.
- What can go wrong: failure and error concepts — failure categories to design for.
Glossary
References
No approved public references yet.
