About the Cubane developer documentation
Development status: Overview — Cubane is under development, and nothing described here is publicly available for live use. An experimental implementation exists for internal development only; in it, confidentiality, proving and several features of how the network agrees on results are simulated or not yet active, so it must not be relied on for security. Capabilities are intended, planned or being explored, and maturity differs between them.
Before you read: nothing — this page is a starting point.
What this documentation is for
This documentation explains what Cubane is intended to let developers and organisations do, why each capability matters, where its boundaries lie and how mature it is, for readers who want to understand the platform before anything can be used. It describes intent and current status, not released software; its previews of a future developer experience are conditional and are never instructions.
The platform aim, in one sentence: Cubane is a blockchain platform under development that aims to let organisations process sensitive data while producing results others can verify. The aim is being explored; What Cubane is designed to do explains it and its boundaries.
The documentation serves developers evaluating fit or preparing future applications, tools or wallets; researchers; organisations planning a possible adoption; prospective infrastructure operators; and readers assessing claims and evidence.
How to read status on every page
The site-wide notice appears in the same place on every page. In substance, it says that Cubane is under development and nothing described is publicly available; that maturity differs by feature; that an experimental implementation exists for internal development, in which confidentiality, proving and several features of how the network agrees on results are simulated or not yet active, so it must not be relied on for security; that pages describe intended capabilities; and that no dates, releases, hardware requirements, performance, prices or compatibility are promised.
The status line under each title gives the page’s status label, an as-of date and a next-review date. A block whose maturity differs from the page carries its own label immediately before it.
The labels, in brief:
- Experimental implementation exists — internal prototype work exists, always with a stated scope limit, such as internal use only, simulated parts or not released.
- Planned — the design is specified, and the developer experience is described conditionally; it is not a commitment.
- Being explored — the design is unsettled; its public interface and support are not settled.
- Research — goals, assumptions and open questions; nothing is an assurance or a released feature.
- Status and changes — dated availability statements only.
- Overview — orientation pages that carry the site-wide notice and block labels.
“Experimental implementation exists” never means usable, released, reviewed or secure, and experimental work on one capability is not evidence that related planned capabilities exist. Status is always stated in words, never by colour or a sidebar badge alone. The exact label phrases are on Documentation conventions: status labels, dates and reviews.
What you will and will not find here
You will find explanations of intended capabilities, user-visible roles and lifecycles, trust assumptions, limitations, research goals and open questions, a Glossary and a Topic index.
You will not find installation commands, package names, interface signatures, endpoints, network identifiers, prices, performance figures, release dates or release plans. Where you would expect one, a notice says so — for example, “Exact installation commands and released tooling are not yet available.”
Every example is a labelled synthetic illustration, never a released interface or live-network result; see How illustrative examples work in this documentation. The documentation makes no comparisons with other platforms, and general words such as finality, validator and fee take their meaning from Cubane’s own Glossary rather than from other platforms.
Where to start
- Evaluating fit: Development status: what exists today and what does not, then What Cubane is designed to do and the Capability map.
- Preparing an application, tool or wallet: System model: how Cubane is intended to work for its users.
- Researching intended properties and assumptions: Research: problems, properties and open questions.
- Planning adoption in an organisation: What you could build: intended application patterns.
- Preparing to operate infrastructure: Operating a node: intended roles and what exists today.
- Assessing claims and evidence: Known limitations of the experimental prototype.
Full reading orders are on Choose your path.
How the documentation is organised
Sections follow this order: orientation; what you could build; system model; data and state; identity, keys and access; privacy and confidentiality; security, trust and limitations; operations and participation; governance, compliance and assurance; future developer experience; conceptual reference; research; and availability and changes. Each section opens with a landing page, and there are no deeper levels than section and page.
Each capability has one primary page; other pages link there rather than repeat it, and terms are defined only in the Glossary. Every page lists what to read before it and its related pages.
How this documentation changes
- The documentation is revised independently of any protocol version; no version, release channel or compatibility promise is shown until a release exists.
- Dated changes, including status-label changes and superseded pages, are recorded in the Documentation change log.
- Each page shows when it was last reviewed and when its next review is due.
- Feedback on this documentation explains how comments would be accepted once a public channel exists.
Assumptions, trust and limitations
- Capability descriptions are design intent: they may change, be deferred or be withdrawn, and none commits to a feature, date or level of service.
- Intended properties are goals. The experimental implementation is internal, is not a release, provides no confidentiality protection and must not be relied on for security.
- Check the as-of date of a status statement before using it in your planning.
Not yet available, and how this page will grow
Once a supported release exists, this page would state which release the documentation describes, where versioned technical reference lives and how released material is marked. Exact installation commands, released tooling and network details are not yet available. Approved public references would be listed on Public references; none are listed yet.
Related pages
- Development status: what exists today and what does not — the status hub behind the site-wide notice.
- Choose your path — the full recommended reading path for each audience.
- What Cubane is designed to do — the platform aim and its boundaries.
- Glossary — the single place where terms are defined.
- Documentation conventions: status labels, dates and reviews — full definitions of labels, dates and review markers.
- How illustrative examples work in this documentation — what example labels mean and what examples never show.
Glossary
References
No approved public references yet.
