Glossary
Development status: Overview — Each entry carries the status of the concept it names. Definitions are documentation-level and in plain language; they are not protocol identifiers or specifications. Some entries are general words given a Cubane-scoped definition that is marked for review. Nothing described is publicly available for live use.
Before you read: nothing — entries can be read on their own.
What does a term mean in this documentation? The glossary is the single place where terms are defined. Each entry gives a short plain-language definition, the status of the concept it names and a link to the page that explains the concept. Other pages link to these entries instead of redefining terms.
How entries are written
- Term and definition. Each entry gives the term, then a definition of one or two plain sentences.
- Status. Each entry states the status of the concept it names, using the documentation’s status labels. Terms that describe the documentation itself, rather than a capability, say so.
- See link. A “See” link leads to the page that explains the concept. Stage-term entries link to Lifecycle stages used in this documentation, which holds their full definitions.
- Flags. Where needed, an entry is marked for review or carries a not to be confused with note.
- Order and anchors. Entries are alphabetical. Each entry heading is a stable anchor that other pages can link to.
- Link, don’t redefine. Other pages link a term to its entry and do not redefine it.
General words defined with care
- Words whose meanings vary across platforms — for example finality, agreement, validator, staking, fee, penalty, custody, governance, dispute, multi-party approval, confidential computation, admission control and backpressure — carry Cubane-scoped definitions marked for review.
- Other platforms’ meanings are not imported. Where a word is used differently elsewhere, the entry says so without comparing platforms.
- Not to be confused with notes separate easily confused pairs, such as audit trail and independent audit, tamper-evident and tamper-proof, recorded and final, and validated and authenticated.
- Definitions marked for review may change; any change would be recorded in the Documentation change log.
Jump to a letter: A · B · C · D · E · F · G · H · I · K · L · M · N · O · P · R · S · T · U · V · W
A
Admission control
Deciding whether to accept new work when it is submitted. Status: Experimental implementation exists — internal prototype components only; no service is offered. Marked for review. See Service levels and admission control.
Admitted
Stage term: accepted by a node for further processing; under load, admission could be delayed or refused. Status: Experimental implementation exists — internal prototype only. See Lifecycle stages used in this documentation.
Agreement
The network’s process of agreeing on results. Its design is not described in this documentation. Status: Planned — in the experimental implementation, several features of how the network agrees on results are simulated or not connected. Marked for review. See Agreement and finality status.
Alert
A notification that something on a node needs attention. Status: Planned. See Node monitoring and observability.
Appeal
Asking for a contested protocol decision, or the outcome of a dispute, to be reconsidered through a governed process. Status: Being explored — none operates. Marked for review. See Disputes and appeals.
Application logic
The part of an application that would run on the network, processing transactions according to the application’s rules. Status: Experimental implementation exists for deterministic execution only — internal prototype; how logic would be written and deployed is not yet documented. See Application logic, execution and storage.
Application pattern
An intended way of using Cubane’s capabilities to meet a recurring need, such as sharing selected results with auditors. Status: Being explored — none can be built today. See What you could build: intended application patterns.
Approval authority
The right to approve a sensitive action, kept separate from holding the keys used for day-to-day signing and from who may see data. Status: Being explored. See Approving actions: authority and multi-party approval.
Audit trail
A record of actions that lets someone review later what was done. “Audit” here means records of actions, not security review. Status: Experimental implementation exists — an experimental logging library, internal only. Not to be confused with an independent audit. See Audit trails and tamper-evident logging.
Auditor
A party that could be given time-limited access to selected data by its owner, in order to review it. Status: Being explored — no role is open. See Participants and roles.
Authentication
Checking who is acting or calling. Status: Planned — the experimental implementation must not be treated as providing it. Not to be confused with validated: passing a node’s initial checks is not authentication. See Approving actions: authority and multi-party approval.
Authorisation
Checking what an identified party is allowed to do, such as approve an action. Status: Planned. See Approving actions: authority and multi-party approval.
Authority
See Approval authority.
B
Backpressure
Signalling submitters to slow down when the system is busy, rather than accepting work it cannot handle. Status: Experimental implementation exists — internal prototype components only. Marked for review. See Service levels and admission control.
Backup
A copy of data kept separately so that it can be restored after loss. Status: Planned — no backup procedures are specified. Not to be confused with a snapshot, which is a node’s own saved state. See Deployment, backup and recovery: what operators would plan for.
Block
A unit of the network’s record in which transactions are recorded and can be looked up. Status: Experimental implementation exists — blocks can be browsed through an internal testing interface; none is reported as final. See Querying network data and browsing activity.
Bonded evidence
An intended defence in which consequences for misbehaviour rest on evidence and on value that participants have committed in advance. Status: Being explored — not implemented. See Threat model and misbehaviour defences.
C
Cancellation
Stopping a confidential job at the application’s request before it completes; a refund could follow. Status: Being explored. See Confidential jobs: tracking, cancelling and retrieving results.
Cancelled
Stage term for jobs: stopped at the application’s request before completion. Status: Being explored. See Lifecycle stages used in this documentation.
Capability
Something Cubane is intended to let developers or organisations do, documented with its own status label. Status: Documentation term. See Capability map.
Certificate
A signed statement that binds a key to a participant, so that others can check it against a trust root. Status: Being explored for trust in validators — none operates on any network. See Cryptographic foundations and trust roots.
Challenge period
A set window of time during which a claim could be contested. Status: Being explored — not implemented. See Threat model and misbehaviour defences.
Collusion
Several participants acting together against the protocol’s rules. Status: Defences being explored — none is implemented. See Threat model and misbehaviour defences.
Committed state
Node state summarised by a cryptographic commitment, so that it can be referred to compactly and values can be checked against it. Status: Experimental implementation exists — internal prototype only. See Committed state and inclusion proofs.
Community treasury
A shared fund whose use would be decided through governance. Status: Being explored — none exists. Marked for review. See Treasury and governed economic settings.
Completed
Stage term for jobs: processing has finished, and a result exists for the parties entitled to it. Status: Being explored. See Lifecycle stages used in this documentation.
Compliance position
This documentation’s statement on legal and regulatory matters. Status: Documentation term. See Compliance position and data-protection intent.
Conceptual sketch
An illustration that describes in words or a plain table what goes in and what comes out, without code. Status: Documentation term. See How illustrative examples work in this documentation.
Confidential application
An application that would process sensitive data using confidential computation. Status: Being explored. Marked for review. See Using outside data in confidential applications.
Confidential computation
Computation over encrypted data, a design goal of the project. Status: Experimental implementation exists — internal interfaces that simulate the behaviour; no real encrypted computation is performed. Marked for review. See Confidential computation.
Confidential data
Data that an application or organisation wants processed without revealing it to everyone who runs or observes the network. Status: Being explored. See Querying confidential data.
Confidential job
A long-running confidential computation that an application would submit, track and come back to for its result; it could be cancelled and refunded. Status: Being explored — no job can be run. See Confidential jobs: tracking, cancelling and retrieving results.
Confidentiality
Keeping information from parties not entitled to see it. Status: Being explored — simulated or switched off in the experimental implementation, which provides no confidentiality protection. See Privacy and confidentiality: intent and current limits.
Cost estimate
An estimate of the price of a piece of work, requested before submitting it. Status: Being explored — not available. Marked for review. See Fees and cost estimates.
Crash safety
Whether saved state survives an unplanned stop, such as a process crash or power loss, intact. Status: Not established for the experimental implementation. See State persistence, snapshots and recovery.
Custody
How the signing keys behind funds are held — for example by one party or by a group of parties. This documentation describes no custody service or provider. Status: Being explored. Marked for review. See Custody options for organisations.
D
Data availability
Data that should be retrievable can actually be retrieved. Status: Being explored for encrypted data — not available. Not to be confused with persistence or backup. See Keeping encrypted data available.
Data owner
The party that provides or controls data, such as an application or an organisation, and would decide who can see it. Status: Being explored. See Visibility controls and selective disclosure.
Demand-based fee
A fee that would be higher when demand on the network is high and lower when it is low. Status: Experimental implementation exists — an experimental calculator that charges nothing. Marked for review. See Fees and cost estimates.
Deployment
Installing and running node software in an environment. Status: Planned — no production deployment procedures are specified. See Deployment, backup and recovery: what operators would plan for.
Deterministic execution
Processing transactions so that nodes processing the same input are intended to reach the same result. Status: Experimental implementation exists — internal prototype only; no published evidence establishes it across nodes. See Application logic, execution and storage.
Digital signature
A value that lets others check that a message was authorised by the holder of a particular key and has not been altered. Status: Experimental implementation exists — established algorithms in an internal prototype. See Cryptographic foundations and trust roots.
Dispute
Contesting a protocol decision or a penalty through a governed process, intended to be considered on the basis of evidence. Status: Being explored — none operates. Marked for review. See Disputes and appeals.
E
Economic setting
An adjustable value that shapes the network’s economics, intended to be controlled through governance. Status: Being explored — no values are described. Marked for review. See Treasury and governed economic settings.
Emergency controls
Scoped, time-limited powers to limit damage during an incident, requiring several approvers. Status: Experimental implementation exists — a library not connected to any network; no emergency controls operate. See Emergency controls and protocol safeguards.
Encrypted data
Data held in a form that cannot be read without the appropriate key. Status: Keeping encrypted data retrievable is being explored. See Keeping encrypted data available.
Encrypted-data availability
See Data availability.
Evidence
Information on which a penalty, dispute or appeal would be decided; what counts as evidence and how it would be handled are not described. Status: Being explored. See Disputes and appeals.
Executed
Stage term: processed deterministically, so that nodes processing the same input are intended to reach the same result. Status: Experimental implementation exists — internal prototype only. See Lifecycle stages used in this documentation.
Experimental implementation
Internal prototype work used for protocol development. The label “Experimental implementation exists” never means usable, released, reviewed or secure. Status: Documentation term. See Documentation conventions: status labels, dates and reviews and Development status: what exists today and what does not.
Explorer
A human-readable view of blocks and transactions. Status: Experimental implementation exists — a browsing interface for internal testing; richer explorers are being explored. See Querying network data and browsing activity.
F
Failed
Stage term for jobs: ended without producing a result. Status: Being explored. See Lifecycle stages used in this documentation.
Faucet
A service that gives out test funds so that developers can try a test network. Status: Status and changes — none exists; an experimental library for issuing test funds exists in internal code only. See Networks and environments.
Fault-injection testing
Deliberately introducing faults to observe how a system behaves. Status: Being explored for confidential workloads — no results are published. See Security assurance status and reporting problems.
Fee
A charge that would be paid for using the network. Status: Experimental implementation exists — an experimental calculator that charges nothing; no fees are charged anywhere. Marked for review. See Fees and cost estimates.
Final
Stage term: the point after which a recorded result is intended not to change. Status: Nothing is reported as final today, because finality is not connected. See Lifecycle stages used in this documentation.
Finality
Cubane’s term for a recorded result having reached the point after which it is intended not to change. Status: Experimental implementation exists — a status query that reports nothing as final, because finality is not connected. Marked for review. Not to be confused with recorded. See Agreement and finality status.
Finality status
What a node would report about whether a result is final. Status: Experimental implementation exists — reports nothing as final, because finality is not connected. See Agreement and finality status.
G
Governance
The process by which protocol decisions would be proposed, voted on and executed through auditable steps. Status: Being explored — no governance process operates on any network. Marked for review. See Governance proposals and decisions.
Governance participant
A participant that would propose, vote on or carry out protocol decisions. Status: Being explored — no role is open. Marked for review. See Participants and roles.
Governance proposal
A protocol change put forward in a form that can be reviewed before any decision is taken. Status: Being explored. Marked for review. See Governance proposals and decisions.
Governed parameter
An adjustable protocol setting intended to change only through an accountable, versioned governance process. Status: Being explored — no names or values are published. Marked for review. See Governed parameters and policies.
H
Hardware attestation
A way for specialised hardware to vouch for the software it is running. Status: Being explored as an optional addition — none operates on any network. See Cryptographic foundations and trust roots.
Hardware-backed custody
Keeping keys in dedicated hardware designed to protect them. Status: Planned — not implemented. See Key lifecycle: creation, rotation and revocation.
Hash
A compact fingerprint of data, so that any change to the data can be detected. Status: Experimental implementation exists — established algorithms in an internal prototype. See Cryptographic foundations and trust roots.
I
Illustrative example
Illustrative local demo
The label on every example: “Illustrative local demo — not a released Cubane API, protocol schema or live-network result.” Examples are synthetic and run nothing. Status: Documentation term. See How illustrative examples work in this documentation.
In progress
Stage term for jobs: accepted and being worked on. Status: Being explored. See Lifecycle stages used in this documentation.
Incident
An event such as a software defect, failure or attack that can cause harm faster than ordinary governance can respond. Status: Emergency controls for incidents are being explored. See Emergency controls and protocol safeguards.
Inclusion proof
A proof that a particular value is part of committed state. It shows membership, not finality. Status: Experimental implementation exists — internal prototype only. See Committed state and inclusion proofs.
Independent audit
A security review carried out by a party independent of the project. Status: Planned — no independent audit results are published. Not to be confused with an audit trail or an auditor. See Security assurance status and reporting problems.
Interface
A way in which applications, tools and operators would interact with nodes and the network. Status: Experimental implementation exists — a developer-facing node interface for internal testing; the broader developer API is being explored. See Interfaces and their status.
K
Key
A cryptographic key used to act for an identity, for example to sign. A key is not the identity it acts for, and holding one does not by itself confer approval authority. Status: Planned — a managed key lifecycle is not implemented. See Identity, keys and access: concepts.
Key custody
How keys are held and protected, and by whom. Status: Planned — policy-governed key handling with hardware-backed custody is not implemented. See Cryptographic foundations and trust roots.
Key management
Creating, storing, rotating and revoking keys under policy. Status: Planned — for confidential computation, key handling is only simulated. See Key lifecycle: creation, rotation and revocation.
Key revocation
Withdrawing a key so that it can no longer be used to act. Status: Planned. See Key lifecycle: creation, rotation and revocation.
Key rotation
Replacing a key with a new one without changing the identity it acts for. Status: Planned. See Key lifecycle: creation, rotation and revocation.
L
Lifecycle stage
A documentation term naming a point in the life of a transaction or confidential job, such as submitted or final. It is not a protocol status value. Status: Documentation term. See Lifecycle stages used in this documentation.
Local development environment
An environment on a developer’s own machine that would behave like the network, with debugging aids for confidential workloads. Status: Planned — not available, and not the same as the internal multi-node test setup. See Local development environment.
M
Main chain
The network’s primary shared record. Storing encrypted data away from it, with checks that the data stays retrievable, is being explored. Status: Being explored. See Keeping encrypted data available.
Message propagation
Passing messages between nodes. Status: Experimental implementation exists — internal prototype only; its design is still being explored, and there is no public network. See Peer-to-peer networking.
Metadata
Information about data or activity, as opposed to the contents themselves. Status: Some protocol metadata remains observable even with confidential execution; ways to bound it are being explored. See What remains observable.
Metering
Measuring the work a computation performs so that its cost could reflect it; confidential computation would be metered by the cryptographic work performed. Status: Being explored — no units, formulas or prices are published. See Fees and cost estimates.
Metrics
Counts and measurements collected over time, used to spot trends and problems. Status: Experimental implementation exists — basic node status and metrics surfaces, internal only. See Node monitoring and observability.
Misbehaviour
A participant acting against the protocol’s rules. Status: Defences being explored — none is implemented. See Threat model and misbehaviour defences.
Monitoring
Watching a node’s health and behaviour over time. Status: Experimental implementation exists for basic status and metrics; broader monitoring is planned. See Node monitoring and observability.
Multi-party approval
Requiring several authorised approvers for a sensitive action, separately from the key used for day-to-day signing. Status: Being explored — nothing in the experimental implementation enforces it. Marked for review. See Approving actions: authority and multi-party approval.
N
Node
A computer running the network’s software that receives and processes transactions and keeps state. Status: Experimental implementation exists — internal prototype only; no node software is released. See Operating a node: intended roles and what exists today.
Node operator
A participant that would run nodes that receive, pass on and execute transactions and keep state. Status: Planned — no role is open, and no requirements are published. See Participants and roles.
O
Observability
Being able to understand a node’s condition from what it reports, such as status and metrics. Status: Experimental implementation exists for basic surfaces, internal only; broader observability is planned. See Node monitoring and observability.
Observable metadata
Metadata that remains visible to others even when data contents are protected. Status: Being explored — no bounding measures exist in the experimental prototype. See What remains observable.
Outside data feed
A source of data from outside the network that a confidential application could use. Status: Being explored — none is available. See Using outside data in confidential applications.
P
Participant identity
A stable identity for a person or organisation, kept separate from the keys, wallets and readable names that act for it. Status: Being explored — not implemented. See Participant identity.
Peer-to-peer networking
Nodes connecting directly to one another to exchange messages, without a central server. Status: Experimental implementation exists — internal prototype only; no public network. See Peer-to-peer networking.
Penalty
A consequence applied to a participant for misbehaviour. Status: Experimental implementation exists — an experimental library; no penalties are enforced on any network. Marked for review. See Penalties for misbehaviour.
Persistence
Keeping state across restarts. Status: Experimental implementation exists — node state is saved and restored on restart in an internal prototype; crash safety is not established. See State persistence, snapshots and recovery.
Policy
A rule that determines how a setting or permission applies. Protocol policies are intended to change only through governance; organisations would set their own policies for approvals, custody and visibility. Status: Being explored. See Governed parameters and policies.
Programming model
How application logic would be written, deployed, updated and invoked, and which limits would apply. Status: Being explored — not yet documented; nothing can be written or deployed today. Marked for review. See Application logic, execution and storage.
Propagated
Stage term: passed between nodes. Status: Planned as a lifecycle stage. See Lifecycle stages used in this documentation.
Protocol safeguard
One of a small set of protocol constraints that governance could not override, as design intent. Status: Being explored. See Emergency controls and protocol safeguards.
R
Rate limiting
Limiting how often each caller can make requests. Status: Experimental implementation exists — internal prototype only. Not to be confused with admission control, which concerns accepting work under load. See Request abuse and replay protection.
Readable name
A label that points to an identity and carries no funds or permissions; changing it would not change the identity. Status: Being explored. See Participant identity.
Recorded
Stage term: a transaction’s effects are reflected in node state. Recorded is not final. Status: Experimental implementation exists — internal prototype only. See Lifecycle stages used in this documentation.
Recovery
Restoring a node or service to working order after a failure. Status: Planned — no recovery procedures are specified. Not to be confused with a recovery path for an identity. See Deployment, backup and recovery: what operators would plan for.
Recovery path
A way, arranged in advance, to regain the ability to act for an identity after a key is lost. It does not recover encrypted data. Status: Being explored. See Participant identity.
Redundancy
Avoiding dependence on any single participant for important work. Status: Being explored — not implemented. See Threat model and misbehaviour defences.
Refund
A return of what was paid for a confidential job after it is cancelled; conditions and amounts are not described. Status: Being explored — no fees are charged today. See Confidential jobs: tracking, cancelling and retrieving results.
Refused
Stage term: not accepted by a node. Status: Experimental implementation exists — internal prototype only. See Lifecycle stages used in this documentation.
Release
A published version of Cubane software or interfaces, with a version identity, made available for use. Status: Status and changes — no release exists. See Versioning, compatibility and deprecation.
Relying party
A person or organisation that depends on a result and needs confidence in it. Status: Being explored. Marked for review. See Processing sensitive data with verifiable results.
Replay
A previously valid request or message being sent again so that it is processed twice, or used in a context or at a time it was not meant for. Status: General concept; protections are described under replay protection. See Request abuse and replay protection.
Replay protection
Measures that stop a valid request or message from being reused. Status: Experimental implementation exists — basic replay checks in an internal prototype; no complete protection against replay is claimed. See Request abuse and replay protection.
Request interface
The part of a node that accepts requests from callers. Status: Experimental implementation exists — internal testing only; it must not be treated as authenticated. See Request abuse and replay protection.
Residency controls
Optional controls over where data is kept. Status: Planned — not implemented, and not a claim of compliance with any law or regulation. See What remains observable.
Resilience testing
Testing how well a system keeps working, or recovers, when parts of it fail. Status: Planned — no measurements are published. See Security assurance status and reporting problems.
Restart
A node stopping and starting again in a controlled way, as distinct from a crash. Status: Experimental implementation exists — state is saved and restored on restart in an internal prototype. See State persistence, snapshots and recovery.
Retention
Keeping encrypted data retrievable over time. Status: Being explored — no retention period is published or offered. See Keeping encrypted data available.
Retrieved
Stage term for jobs: an entitled party has obtained the result. Status: Being explored. See Lifecycle stages used in this documentation.
Rollback
Returning to an earlier version if an upgrade causes problems. Status: Being explored, as a safeguard for staged upgrades. See Time-delayed execution and staged upgrades.
S
Scoped credential
A short-lived, narrowly scoped credential that an automated process could use instead of a participant’s main key, limiting what it could do if misused. Status: Being explored. Marked for review. See Approving actions: authority and multi-party approval.
SDK
Software development kit: a library for using a platform from a programming language. Planned language SDKs would let applications submit confidential jobs and retrieve results. Status: Planned — no SDK is available. See Submitting work and retrieving results.
Security assurance
Evidence about how far a system can be relied on for security, such as independent review and resilience testing. Status: Planned — no results are published. See Security assurance status and reporting problems.
Security model
The overall account of what a system is intended to protect, the assumptions it rests on and its limits. Status: Being explored — the experimental implementation must not be relied on for security. See Security model, trust and limitations.
Security problem report
A report of a suspected security problem in Cubane. Status: Status and changes — a route for such reports has not yet been announced. See Security assurance status and reporting problems.
Selective disclosure
Sharing selected results, rather than all the underlying data, with authorised parties. Status: Being explored — the step that would reveal results is only simulated in the experimental prototype. See Visibility controls and selective disclosure.
Service level
The treatment an application would request for its transactions. Status: Planned — none is offered. Marked for review. Not to be confused with a service-level objective. See Service levels and admission control.
Service-level objective
A stated target for how a service should behave, used to judge whether it is healthy. Status: Planned — no values are published. See Node monitoring and observability.
Signing key
A key used to sign transactions or approvals, including the keys behind an organisation’s funds. Status: Planned as part of a managed key lifecycle; custody choices are being explored. See Identity, keys and access: concepts.
Simulation
Software that imitates intended behaviour without performing it. Status: In the experimental implementation, encrypted computation and proving are simulated, so no data is protected. See Confidential computation.
Snapshot
A node’s own saved copy of its state at a point in time, used when resuming after a restart. Status: Experimental implementation exists — internal prototype only. See State persistence, snapshots and recovery.
SQL-style query
A familiar, SQL-style way to declare and query confidential data, as intended. Status: Being explored — no syntax or interface is published. See Querying confidential data.
Staged upgrade
Introducing a protocol upgrade in steps, with safeguards for rolling it back. Status: Being explored — no upgrade mechanism operates. Marked for review. See Time-delayed execution and staged upgrades.
Staking
Committing something of value as a condition of taking part in the network’s agreement on results, as validators would in the planned design. Status: Planned — not available on any network; amounts, terms and rules are not described. Marked for review. See Staking and validator participation.
State
The information the network records and keeps up to date as transactions are executed. Status: Experimental implementation exists — node state in an internal prototype; not confidential and not final. See Data and state: how information is recorded and retrieved.
State commitment
A compact cryptographic value that summarises the whole state; this documentation calls it a root. Status: Experimental implementation exists — internal prototype only. See Committed state and inclusion proofs.
State root
The root of committed state: the compact value against which an inclusion proof is checked. Status: Experimental implementation exists — a root from the experimental implementation is not final. See Committed state and inclusion proofs.
Status label
The label stating a page’s or block’s maturity: Experimental implementation exists, Planned, Being explored, Research, Status and changes or Overview. Labels describe maturity, not availability. Status: Documentation term. See Documentation conventions: status labels, dates and reviews.
Storage primitive
A basic storage operation that application logic could use directly. Status: Being explored — none exists. See Application logic, execution and storage.
Submitted
Stage term: for a transaction, sent by an application or wallet to a node; for a confidential job, handed over for confidential processing. Status: Experimental implementation exists for transactions, internal only; being explored for jobs. See Lifecycle stages used in this documentation.
Synthetic data
Invented data used in examples, such as fictional names, values and outputs. Status: Documentation term. See How illustrative examples work in this documentation.
T
Tamper-evident log
A log in which later alteration would be detectable. Tamper-evident is not tamper-proof: it makes changes detectable rather than impossible. Status: Experimental implementation exists — an experimental library, internal only. See Audit trails and tamper-evident logging.
Test network
A public network for trying out software without real value at stake. Status: Status and changes — no public test network exists; internal setups are not test networks. See Networks and environments.
Threat model
A description of what a system is meant to resist, from whom, and under which assumptions. Status: Being explored — no detailed threat model is published. See Threat model and misbehaviour defences.
Time-delayed execution
Carrying out an approved governance decision only after a delay, so that it can be reviewed before it takes effect. Status: Being explored. Marked for review. See Time-delayed execution and staged upgrades.
Time-limited access
Access to selected data granted by its owner for a limited time, for example to an auditor. Status: Being explored. See Visibility controls and selective disclosure.
Transaction
An ordinary request to change recorded state, sent by an application or wallet. Status: Experimental implementation exists — submission, initial checks, execution and recording in an internal prototype. See Transaction lifecycle: from submission to result.
Transaction batch
A group of transactions processed together by the execution environment. Status: Experimental implementation exists — internal prototype only. Marked for review. See Application logic, execution and storage.
Trust assumption
Something a party must rely on others to do correctly for a property to hold; every system has some. Status: Being explored — described in qualitative terms only. See Trust assumptions and responsibilities by participant.
Trust root
The starting point that must be trusted without further proof, so that other things can be checked against it. Status: Being explored. See Cryptographic foundations and trust roots.
U
Upgrade
Moving a node or the protocol to a new software version. Status: Planned for operators, with no procedure published; staged protocol upgrades are being explored. See Deployment, backup and recovery: what operators would plan for.
Use-case profile
An opinionated starting profile that would help teams choose confidentiality and performance settings for a common use case. Status: Being explored — no profile is defined. See Use-case profiles.
V
Validated
Stage term: passed a node’s initial checks. This does not by itself mean that the sender was authenticated or that the transaction cannot be repeated. Status: Experimental implementation exists — internal prototype only. Not to be confused with authenticated. See Lifecycle stages used in this documentation.
Validation
The initial checks a node runs on a submitted transaction; see Validated. Status: Experimental implementation exists — internal prototype only. See Transaction lifecycle: from submission to result.
Validator
A participant that would take part in the network’s agreement on results; the planned design would let validators stake to take part. Status: Planned — no role is open. Marked for review. See Participants and roles.
Verifiable result
A result that parties other than the one who produced it could check, rather than take on trust. How results would be made checkable is not described. Status: Being explored. Marked for review. See Processing sensitive data with verifiable results.
Versioning
Identifying releases by version so that compatibility, changes and deprecations can be tracked. Status: Status and changes — no versions exist yet. See Versioning, compatibility and deprecation.
Visibility
Who can see which data. Data owners would decide, and who may see data would be controlled separately from who may act on it. Status: Being explored — no access-controlled data exists in the experimental prototype. See Visibility controls and selective disclosure.
Vote
The governance step in which eligible participants decide whether to approve a proposed change. Status: Being explored — no vote can be cast. Marked for review. See Governance proposals and decisions.
W
Wallet
Software that uses keys to act for an identity, for example to sign transactions. Status: Experimental implementation exists — a wallet prototype for local and internal testing; not released or supported. See Wallets and the experimental wallet prototype.
What the glossary does not contain
- Internal names, product names and component names are not used in this documentation and do not appear here.
- Terms for topics this documentation does not cover are not listed. A missing term means the topic is not covered here, not that it does or does not exist.
- No entry is a protocol identifier, status value, field name or specification.
- A term’s presence in the glossary does not mean that the concept is available.
Assumptions, trust and limitations
Definitions are documentation-level and may change as designs settle; any change would be recorded in the Documentation change log. No entry claims availability, a protocol identifier or compatibility with any other platform.
Not yet available, and how this page will grow
New entries are added as pages are added, and entries for released interfaces would carry a version identity. The glossary is complete when every term linked from any page has an entry and every entry links to the page that explains it.
Related pages
- Capability map — the documented capabilities and their status.
- Lifecycle stages used in this documentation — full definitions of the stage terms.
- Topic index — an alphabetical route to pages rather than terms.
- About the Cubane developer documentation — how the documentation is organised.
Glossary
Not applicable — this page is the glossary; each entry links to the page that explains its concept.
References
No approved public references yet.
