Custody options for organisations
Development status: Being explored — The design is being explored; its public interface and support are not settled. The intention is that an organisation could choose how the signing keys behind its funds are held, for example by one party or by a group of parties; custody choices do not exist in the experimental implementation, and this documentation does not describe any custody service or provider. Nothing is publicly available for live use.
Before you read: Identity, keys and access: concepts.
Could an organisation choose who holds the signing keys behind its funds? That is the intention being explored: the design would let an organisation choose how those keys are held — for example, by one party or by a group of parties. Nothing of this exists today, and this documentation describes no custody service or provider. This page describes the choice at concept level, the general considerations of each example arrangement, what the organisation would remain responsible for, and what this documentation does not describe Cubane doing.
The decision an organisation would make
An organisation’s funds are ultimately controlled through signing keys, so who holds those keys is a central risk decision. The design being explored would let an organisation choose how those keys are held, for example by one party or by a group of parties.
The custody choice concerns only who holds keys. It is separate from three other questions:
- Who the organisation is — its identity; see Participant identity.
- Who may approve actions — approval authority; see Approving actions: authority and multi-party approval.
- Who may see data — visibility; see Visibility controls and selective disclosure.
Holding keys would not by itself confer authority to approve actions.
Held by one party
Status of this section: Being explored — not implemented.
In this example arrangement, a single designated holder would control the signing keys.
The general considerations are straightforward. A single holder would be simpler to operate, but that holder would become a single point of failure or compromise, which the organisation would have to protect. How such an arrangement would be set up or protected is not described.
Held by a group of parties
Status of this section: Being explored — not implemented.
In this example arrangement, control of the signing keys would be shared among a group of parties.
The general considerations pull the other way. More coordination would be needed to use the keys, and any added protection would depend on the parties being genuinely independent of each other — parties who rely on the same device, the same system or the same person’s instructions may offer less protection than their number suggests. How a group would hold and use keys, and what protection that would provide, is not described.
What would remain the organisation’s responsibility
Whichever arrangement it chose, an organisation would remain responsible for:
- choosing an arrangement that fits its own risk policies, and reviewing that choice over time;
- selecting, protecting and supporting the people or devices that hold keys;
- making sure that parties sharing control are genuinely independent where independence matters;
- planning in advance for key loss, rotation and revocation — see Participant identity and Key lifecycle: creation, rotation and revocation;
- meeting its own legal, regulatory and contractual obligations — see Compliance position and data-protection intent.
How custody fits together with approvals and other organisational choices is described as an application pattern on Organisation workflows with shared approval and custody choices.
What this documentation does not describe Cubane doing
This documentation does not describe Cubane:
- holding organisations’ or users’ keys, or offering custody services;
- naming, recommending or endorsing custody providers.
It also does not describe whether, or how, a custody choice could be changed later.
What exists today
- Custody choices do not exist in the experimental implementation.
- Key handling in the experimental implementation must not be relied on for security.
- The decisions an organisation would make when joining, including custody, are previewed conditionally on Onboarding an organisation.
Assumptions, trust and limitations
- Protection from shared control depends on the independence of the parties and on arrangements that are not described here.
- How custody would be enforced, changed or reviewed is not described.
- The two arrangements on this page are examples used to explain the choice, not a list of supported options.
Not yet available, and how this page will grow
Further technical reference is not yet available. Once implemented and released, this page would describe the supported custody arrangements, their limits and the organisation’s responsibilities in more detail, with versioned reference. The status label would change only with evidence of implementation and release.
What this page does not claim
This page does not describe any custody service or provider, or the details of any arrangement, and it claims no protection or recovery guarantee for any arrangement. Anything not stated here as available should be treated as unavailable.
Related pages
- Key lifecycle: creation, rotation and revocation — how the keys under any custody arrangement would be created, rotated and revoked.
- Approving actions: authority and multi-party approval — approval authority, which holding keys does not confer.
- Organisation workflows with shared approval and custody choices — how custody fits with approvals and starting profiles in an organisation.
- Onboarding an organisation — where the custody decision would appear in the intended onboarding experience.
- Participant identity — the organisation’s identity, which custody does not change.
Glossary
References
No approved public references yet.
