Operating a node: intended roles and what exists today
Development status: Overview — Each block on this page carries its own label. No node software has been released, no operator requirements are published and no public network exists, so nobody can operate a Cubane node today; production deployment, backup and recovery procedures are not yet specified. Experimental onboarding, operations and simulation tooling, a local multi-node test setup, peer-to-peer networking layers, basic node status and metrics surfaces, and saving and restoring node state on restart exist for internal development and testing only — crash safety of saved state has not been established — and nothing is publicly available for live use.
Before you read: Participants and roles.
What would running Cubane infrastructure involve, and can you prepare for it now? This page starts with the second half: you cannot run a node today. It then describes the intended operator responsibilities, the experimental tooling that exists for internal use only, what prospective operators can and cannot prepare, and where each topic is covered. It gives no requirements, commands, configuration or hardware guidance, because none is published.
The short answer
- You cannot run a Cubane node today. No node software has been released, no operator requirements are published and no public network exists to connect to.
- Experimental tooling exists for internal development and testing only. It is not a product, it is not available outside the project and it is not a preview of a supported release.
- Preparing today means understanding, not installing. You can learn the intended responsibilities described below and follow the availability pages. There is nothing to install or configure.
- No requirements are stated anywhere in this documentation. That includes hardware, software, network and capacity requirements.
What operating a node would involve
Planned. The responsibilities below describe the intended operator role. They are not requirements, they may change as the design settles, and each linked page carries its own status label.
- Running and connecting node software. A node operator would run node software that receives, passes on and executes transactions and keeps the network’s recorded state, and would keep the node connected to other nodes. See Peer-to-peer networking.
- Watching the node’s health. Operators would watch their node’s status and health over time so that problems are noticed early. See Node monitoring and observability.
- Protecting state and planning for failure. Operators would store and protect node state, plan backups and recover from failures. See State persistence, snapshots and recovery and Deployment, backup and recovery: what operators would plan for.
- Applying upgrades safely. Operators would move their nodes to new software versions as the protocol changes. How protocol changes would be staged and reviewed is being explored; see Time-delayed execution and staged upgrades.
- Responding to incidents within the network’s safeguards. The design is exploring scoped, time-limited emergency controls and a small set of protocol constraints that governance could not override. See Emergency controls and protocol safeguards.
- Protecting the operator’s own keys. The planned design would allow keys to be created, rotated and revoked under policy; this is not yet implemented. See Key lifecycle: creation, rotation and revocation.
- For validators, taking part in agreement on results. Validators would take part in the network’s agreement on results. The planned design would let validators stake to take part, but staking is not available on any network, and the design of penalties for misbehaviour is being explored. See Staking and validator participation and Penalties for misbehaviour.
Applications and other participants would rely on node operators to keep nodes running and processing as the protocol specifies. Trust assumptions and responsibilities by participant describes that reliance in qualitative terms.
What exists today
Experimental implementation exists — for internal development and testing only. The following exists to support protocol development:
- Onboarding, operations and simulation tooling for internal testing. Simulations imitate intended behaviour; their output is not evidence of how any network would behave.
- A local multi-node test setup for internal development. It is not a network and cannot be joined.
- Peer-to-peer networking and message-propagation layers in an internal prototype. Their design is still being explored.
- Basic node status and metrics surfaces exposed by the experimental implementation.
- Saving and restoring node state on restart. The experimental implementation saves node state to disk and restores it when the node restarts. Its crash safety has not been established; see State persistence, snapshots and recovery.
None of this is released, and none of it means that an operator role is open. There is no public network and no public distribution of test funds; see Networks and environments.
What you can and cannot prepare
You can:
- read the pages in this section and Participants and roles, and note which of the intended responsibilities above your organisation would expect to own;
- follow Networks and environments, Tools, SDKs and wallet availability and the Documentation change log for status changes.
You cannot:
- obtain node software, requirements, configuration or hardware guidance;
- join a network, run a validator or stake.
Treat with caution any operator instructions, requirement lists or offers of node access attributed to Cubane that do not come from this documentation; none are published here. When a supported release exists, its requirements and procedures would accompany it.
Pages in this section
- Peer-to-peer networking — how nodes would find each other and pass messages; experimental layers exist internally.
- Node monitoring and observability — what an operator could observe; basic surfaces exist experimentally.
- Deployment, backup and recovery: what operators would plan for — the concerns a release would address; procedures are not yet specified.
- Emergency controls and protocol safeguards — intended limits on emergency action; an experimental library exists that is not connected to a running network.
- Staking and validator participation — planned; not available on any network.
- Penalties for misbehaviour — an experimental library exists; no penalties are enforced on any network.
- Treasury and governed economic settings — being explored; not available.
Assumptions, trust and limitations
- The responsibilities on this page are intended and may change. They are not requirements, and they are not a commitment that any operator or validator role will open.
- Experimental tooling is internal. Its existence is not evidence of production readiness, reliability or security, and simulation output is not a test result for any network.
Not yet available, and how this page will grow
Exact installation commands and released tooling are not yet available. Once node software is released, this page would link to the supported requirements and procedures and to the networks they apply to. Status changes would be recorded in the Documentation change log.
What this page does not claim
This page does not claim:
- any hardware, software, network or capacity requirement for operators;
- any installation command, configuration or deployment layout;
- any cost or other economic term for operators or validators;
- that a public network exists, or that any operator or validator role is open.
Anything not stated here as available should be treated as unavailable.
Related pages
- Peer-to-peer networking — how nodes would connect and pass messages.
- Node monitoring and observability — what an operator could observe.
- Deployment, backup and recovery: what operators would plan for — operational concerns a release would address.
- Emergency controls and protocol safeguards — intended limits on emergency action.
- Staking and validator participation — the planned staking concept and its status.
- Networks and environments — which environments exist (none publicly).
- Tools, SDKs and wallet availability — the status of operator and developer tooling.
Glossary
References
No approved public references yet.
