Participants and roles
Development status: Planned — The planned design names external roles: application developers, users and organisations; node operators, validators and specialised compute workers; auditors and governance participants. Experimental code for some supporting functions exists internally, but no role is open to the public: there is no public network on which to operate a node, validate, stake, act as a specialised compute worker or take part in governance. Nothing is publicly available for live use.
Before you read: System model: how Cubane is intended to work for its users.
Who are the participants in Cubane, and what is each expected to do? This page names the external roles in the planned design, describes what each role would be responsible for and what others would rely on it for, and makes clear that no role is open today. It describes responsibilities only, not the network’s internal workings.
Why roles matter
Knowing who does what tells you whom an application would rely on, for what, and what it remains responsible for itself. A developer deciding whether Cubane could fit an application needs to know which parts of the outcome depend on the network’s participants and which depend on the application and its users. An organisation planning adoption needs to know which policies it would set for itself. A prospective operator needs to know which roles exist before asking what running one would involve.
The roles on this page are external, user-visible responsibilities. They describe what a participant would do from the outside, not how the network organises its participants internally. The trust placed in each role, and the defences intended against misbehaviour, are covered on Trust assumptions and responsibilities by participant and Threat model and misbehaviour defences.
Each role below carries its own status label where it differs from the page label.
Roles that build on and use the platform
Application developers would build the applications and tools that submit transactions and confidential jobs on behalf of their users and present the results. They would decide what their application asks the network to do, what it shows its users and how it handles their data. The planned developer experience would allow applications to submit confidential jobs and retrieve results through language SDKs; no SDK is publicly available. That planned experience is described on Submitting work and retrieving results.
Users are the people and systems acting through applications and wallets. Being explored: a participant’s identity is intended to be separate from the keys and wallets that sign for it, so that changing a key or a wallet need not change who the participant is. Users would be responsible for the keys and wallets that act for them and for approving only what they intend. See Participant identity and Wallets and the experimental wallet prototype.
Organisations would set their own policies. Being explored: an organisation would decide which sensitive actions need several approvers, how the keys behind its funds are held — for example by one party or by a group of parties — and who may see which data. Who an organisation is, which keys sign for it, who may approve an action and who may see a result are separate questions, and this documentation keeps them apart. See Approving actions: authority and multi-party approval, Custody options for organisations and Visibility controls and selective disclosure.
Roles that run the network
Node operators would run the nodes that receive, pass on and execute transactions and keep the network’s recorded state. Operator procedures, such as production deployment, backup and recovery, are not yet specified. Operating a node: intended roles and what exists today describes the operator’s view in more depth.
Validators would take part in the network’s agreement on results, which is what would eventually allow a result to be treated as final. The planned design would let validators stake to take part, and staking is not available on any network. See Staking and validator participation and, for what finality would mean to an application, Agreement and finality status.
Specialised compute workers. Being explored: the design being explored includes the use of specialised hardware workers for encrypted computation. This documentation calls that role specialised compute workers. No specialised compute worker is available, and no hardware requirements are published. Where such workers would fit in the job experience is described on Confidential jobs: tracking, cancelling and retrieving results.
Penalties for misbehaviour apply to the roles that run the network rather than forming a role of their own. The penalty design is being explored; an experimental library exists for internal use, and no penalties are enforced on any network. See Penalties for misbehaviour.
Roles that oversee and govern
Auditors. Being explored: auditors could be given time-limited access to selected data by the owners of that data. Access would be granted by the data owner, limited in time and to the selected data, so that an auditor could review what it has been shown without that data being made visible to others. See Visibility controls and selective disclosure.
Governance participants. Being explored: protocol decisions would be proposed, voted on and executed through auditable steps, so that anyone able to review the record could see what was proposed, what was decided and what was carried out. See Governance proposals and decisions and Governance, compliance and assurance.
Emergency controls for exceptional situations are a protocol safeguard rather than a role, and are described on Emergency controls and protocol safeguards.
What is open today
- No role is open. There is no public network on which to operate a node, validate, stake, act as a specialised compute worker or take part in governance, and there is no public application platform to build on.
- Experimental code for some supporting functions, such as penalties and emergency controls, exists internally. None of it is connected to a public network, and none of it means a role is available.
- No eligibility rules, requirements or hardware specifications are published for any role.
Responsibilities at a glance
The table summarises the sections above. It adds no requirements, rewards or figures.
Responsibilities and status by role:
| Role | Would be responsible for | Others would rely on it for | Status today | More |
|---|---|---|---|---|
| Application developers | Building applications and tools that submit work and present results | Applications that behave as described and report status and results accurately | Planned; not open; no SDK is available | Submitting work and retrieving results |
| Users | Acting through applications and wallets, and looking after the keys that act for them | Approving only what they intend | Planned; identity separation being explored; not open | Participant identity |
| Organisations | Setting approval, custody and visibility policies | Policies that reflect who may approve, hold keys and see data | Being explored; not open | Approving actions: authority and multi-party approval |
| Node operators | Running nodes that receive, pass on and execute transactions and keep state | Keeping nodes running and processing as the protocol specifies | Planned; not open; procedures not specified | Operating a node: intended roles and what exists today |
| Validators | Taking part in the network’s agreement on results | Honest participation in that agreement | Planned; not open; staking not available on any network | Staking and validator participation |
| Specialised compute workers | Encrypted computation using specialised hardware, in the design being explored | Trust assumptions not yet specified | Being explored; not open; none available | Confidential jobs: tracking, cancelling and retrieving results |
| Auditors | Reviewing selected data they have been given time-limited access to | Independent review within the access granted | Being explored; not open | Visibility controls and selective disclosure |
| Governance participants | Proposing, voting on and carrying out protocol decisions through auditable steps | Decisions that follow the auditable process | Being explored; not open | Governance proposals and decisions |
Assumptions, trust and limitations
- Roles and responsibilities are intended and may change, be merged or be withdrawn as the design develops.
- This page describes responsibilities, not the network’s internal workings, and it does not describe the trust model for any role; the security pages cover trust and misbehaviour.
- A role existing in the design does not mean the capabilities behind it exist. Each role’s status is stated separately, and experimental supporting code is internal only.
Not yet available, and how this page will grow
Once roles open on a public network, this page would link to the eligibility rules, requirements and responsibilities for each role, together with versioned reference. Further technical reference is not yet available. Approved public references would be listed here once approved; none are listed yet.
What this page does not claim
This page does not claim that any role is open today, and it does not state eligibility rules, requirements, hardware, rewards or returns for any role. Anything not stated here as available should be treated as unavailable.
Related pages
- Trust assumptions and responsibilities by participant — what each role would be trusted for.
- Operating a node: intended roles and what exists today — the operator’s view in more depth.
- Staking and validator participation — the planned staking concept and its status.
- Governance, compliance and assurance — governance participation and assurance.
- Participant identity — identity kept separate from keys and wallets.
- Confidential jobs: tracking, cancelling and retrieving results — where specialised compute workers would contribute.
- Threat model and misbehaviour defences — defences against misbehaviour by participants.
Glossary
References
No approved public references yet.
