Trust assumptions and responsibilities by participant
Development status: Being explored — The design is being explored; its public interface and support are not settled. The intended trust model is described in qualitative terms only: layered defences against misbehaving validators and certificate-based trust in validators with optional hardware attestation are being explored, and policy-governed key handling with hardware-backed custody is planned, but none of these is implemented. In the experimental implementation, which exists for internal development only, nothing is confidential, finality is not connected and key handling must not be relied on for security, so everything rests on whoever runs it, and nothing is publicly available for live use.
Before you read: Security model, trust and limitations.
What does each participant rely on others for, and what remains my responsibility today? This is the primary page for trust assumptions in this documentation. It explains what a trust assumption is, says plainly what the experimental implementation does not provide, describes for each participant what it would rely on others for and what others would rely on it for, and lists the practical responsibilities that fall on you today. Every statement is qualitative: no quantitative assumptions or attack analyses are given.
What a trust assumption is
A trust assumption is something a participant has to rely on another party, or on hardware or software, to do or not to do, because the system itself does not enforce it.
- Every system has them. Stating them is more useful than claiming that no trust is needed.
- They differ by participant. What an application user relies on is not what a node operator relies on.
- They are described qualitatively here. How much misbehaviour the intended design would tolerate is not published, and assumptions that are common on other networks should not be assumed to apply.
A practical way to read each assumption on this page is to ask what you would be depending on if you took part in that role, and what others would be depending on you for.
Today: what the experimental implementation does not provide
Status of this section: Experimental implementation exists — internal development only; not a release.
- No confidentiality protection. Confidentiality and proving features are simulated or switched off, so whoever runs it can see all data it holds.
- No finality. An experimental status query reports nothing as final, because finality is not connected; see Agreement and finality status.
- No established crash safety for saved node state; see State persistence, snapshots and recovery.
- No key handling to rely on. Key handling in experimental software, including the experimental wallet prototype for local testing, must not be relied on for security.
- No published independent audit results. It is internal and is not a release.
In short, everything today rests on whoever runs the experimental implementation, and nobody should rely on it for security. The complete list is on Known limitations of the experimental prototype.
Intended trust by participant
Status of this section: Being explored — qualitative only; none of the intended defences, trust roots or key-custody arrangements is implemented.
- Application developers and their users would rely on the network to process and record their transactions, and on wallets and key holders to protect keys. Others would rely on applications to handle their users’ data and keys responsibly.
- Organisations would rely on their own approvers and on whoever holds their keys. Planned policy-governed key handling with hardware-backed custody is not implemented; see Key lifecycle: creation, rotation and revocation.
- Node operators would be relied on to run nodes that receive, pass on, execute and record work, and to keep them available. Confidential computation over encrypted data is a design goal and is simulated today; see Confidential computation.
- Validators would be relied on to take part honestly in the network’s agreement on results. Layered defences against collusion and misbehaviour, including redundancy, bonded evidence and challenge periods, are being explored, and none is implemented; see Threat model and misbehaviour defences.
- Trust in validators. Certificate-based trust in validators is being explored. Where optional hardware attestation were used, participants would also rely on that hardware and its maker; see Cryptographic foundations and trust roots.
- Governance and emergency participants would be relied on to change the protocol only through governed steps, and to use emergency controls only within their intended limits, which are being explored; see Emergency controls and protocol safeguards.
Table: intended trust by participant — what each would rely on, what others would rely on it for, and its status today. The table adds no figures or requirements.
| Participant | Relies on | Is relied on for | Status today |
|---|---|---|---|
| Application developers and their users | The network to process and record transactions; wallets and key holders to protect keys | Handling users’ data and keys responsibly | Not open; nothing can be relied on today |
| Organisations | Their own approvers; whoever holds their keys | Their own approval, custody and visibility policies | Being explored; planned key handling with hardware-backed custody is not implemented |
| Node operators | The node software and its documentation, once released | Running nodes that receive, pass on, execute and record work, and keeping them available | Planned role, not open; confidential computation is simulated today |
| Validators | Not yet described publicly | Taking part honestly in the network’s agreement on results | Planned role, not open; defences being explored, none implemented |
| Trust in validators | Certificates checked against a trust root; where optional hardware attestation were used, that hardware and its maker | Letting others check that a validator’s key belongs to it | Being explored; not implemented |
| Governance and emergency participants | Not yet described publicly | Changing the protocol only through governed steps; using emergency controls only within intended limits | Being explored; no governance process or emergency controls operate |
Who could see what
- Today, whoever runs experimental software can see all data it holds, because nothing is confidential.
- In the intended design, confidential computation is meant to limit what the parties that process data can see. Who would process confidential work and hold the keys that protect it is not yet specified publicly.
- Even then, some information about activity is expected to remain observable to the parties running the network and to observers; see What remains observable.
- Applications would need to tell their own users what remains observable.
Your responsibilities today
- Use only synthetic data and test keys with any experimental software. Never use real personal data, credentials or funds.
- Treat any key used with experimental software as disposable, and never reuse it elsewhere.
- Treat every recorded result as not final, and every confidentiality or proof output as simulated.
- Do not cite the experimental implementation as evidence of security, confidentiality, performance or availability.
- Check the as-of date on status statements before relying on them.
Responsibilities that would remain with you
Status of this section: Planned — conditional on a release; none of it applies to anything available today.
- Once a release exists, application developers would remain responsible for the security of their own applications, including how they handle their users’ keys and data.
- Organisations would remain responsible for their own approval policies, custody choices and obligations. Compliance matters are addressed on Compliance position and data-protection intent rather than on this page.
- Operators would remain responsible for protecting their nodes and keys. Operator procedures are not yet specified; see Operating a node: intended roles and what exists today.
These responsibilities are listed so that readers do not assume a future network would take them over. Nothing in this documentation says it would.
What is not yet described about trust
- Quantitative assumptions, such as how much misbehaviour the design would tolerate before its intended properties fail, are not published.
- Who would process confidential work and hold the keys that protect it, and what users would rely on them for, is not yet specified publicly.
- How trust in validators would be issued, governed and withdrawn is not described.
- Research questions about these assumptions are collected on Assumptions and open questions.
Assumptions, trust and limitations
- Everything on this page is qualitative and intended, and it may change as the design develops.
- Intended defences are not implemented, and experimental behaviour is not evidence of future trust properties.
- Where a row says “not yet described publicly”, no assumption should be read into the gap.
Not yet available, and how this page will grow
Further technical reference is not yet available. Once a reviewed statement of assumptions is approved for publication, this page would state it with its scope and date, and each participant row would link to it. Changes would be recorded in the Documentation change log.
What this page does not claim
This page does not claim:
- trust-free operation;
- any tolerance figure;
- any attack analysis;
- any security assurance;
- any legal or compliance claim.
Anything not stated here as available or assured should be treated as neither.
Related pages
- Participants and roles — the roles whose trust is described here.
- Known limitations of the experimental prototype — what the prototype does not provide.
- Threat model and misbehaviour defences — the intended defences behind trust in validators.
- What remains observable — what observers could still see.
- Cryptographic foundations and trust roots — how trust in validators is intended to be established.
- Emergency controls and protocol safeguards — the limits intended for emergency authority.
Glossary
- Trust assumption
- Validator
- Node operator
- Key custody
- Hardware attestation
- Trust root
- Certificate
- Redundancy
- Bonded evidence
- Challenge period
- Finality
References
No approved public references yet.
