| CIP | Title | Status | Category | Authors | Implementors | Discussions | Created | License | |
|---|---|---|---|---|---|---|---|---|---|
105 |
Conway era Key Chains for HD Wallets |
Proposed |
Wallets |
|
2023-09-22 |
CC-BY-4.0 |
The Conway Ledger era introduces many new features to Cardano, notably features to support community governance via CIP-1694.
This includes the introduction of the new first class credentials; drep_credential, committee_cold_credential and committee_hot_credential.
We propose a HD wallet key derivation paths for registered DReps and constitutional committee members to deterministically derive keys from which credentials can be generated. Such keys are to be known as DRep keys, constitutional committee cold keys and constitutional committee hot keys. Here we define some accompanying tooling standards.
Note this proposal assumes knowledge of the Conway ledger design (see draft ledger specification) and CIP-1694.
In the Conway ledger era, DRep credentials allow registered DReps to be identified on-chain, in DRep registrations, retirements, votes, and in vote delegations from ada holders. Whilst constitutional committee members can be recognized by their cold credentials within update committee governance actions, authorize hot credential certificate and resign cold key certificates. Constitutional committee hot credential can be observed within the authorize hot key certificate and votes.
CIP-1694 terms these DRep credentials as DRep IDs, which are either generated from blake2b-224 hash digests of Ed25519 public keys owned by the DRep, or are script hash-based. Similarly, both the hot and cold credentials for constitutional committee members can be generated from public key digests or script hashes.
This CIP defines a standard way for wallets to derive DRep and constitutional committee keys.
Since it is best practice to use a single cryptographic key for a single purpose, we opt to keep DRep and committee keys separate from other keys in Cardano.
By adding three paths to the CIP-1852 | HD (Hierarchy for Deterministic) Wallets for Cardano, we create an ecosystem standard for wallets to be able to derive DRep and constitutional committee keys. This enables DRep and constitutional committee credential restorability from a wallet seed phrase.
Stakeholders for this proposal are wallets that follow the CIP-1852 standard and tool makers wishing to support DReps and or constitutional committee members. This standard allows DReps and constitutional committee members to use alternative wallets whilst being able to be correctly identified. By defining tooling standards, we enable greater interoperability between governance-focussed tools.
Here we describe DRep key derivation as it pertains to Cardano wallets that follow the CIP-1852 standard.
To differentiate DRep keys from other Cardano keys, we define a new role index of 3:
m / 1852' / 1815' / account' / 3 / address_index
We strongly recommend that a maximum of one set of DRep keys should be associated with one wallet account, which can be achieved by setting address_index=0.
Tools and wallets can generate a DRep ID (drep_credential) from the Ed25519 public DRep key (without chaincode) by creating a blake2b-224 hash digest of the key.
As this is key-based credential it should be marked as entry 0 in a credential array.
Here we describe constitutional committee cold key derivation as it pertains to Cardano wallets that follow the CIP-1852 standard.
To differentiate constitutional committee cold keys from other Cardano keys, we define a new role index of 4:
m / 1852' / 1815' / account' / 4 / address_index
We strongly recommend that a maximum of one set of constitutional committee cold keys should be associated with one wallet account, which can be achieved by setting address_index=0.
Tools and wallets can generate a constitutional committee cold credential (committee_cold_credential) from the Ed25519 public constitutional committee cold key (without chaincode) by creating a blake2b-224 hash digest of the key.
As this is key-based credential it should be marked as entry 0 in a credential array.
Here we describe constitutional committee hot key derivation as it pertains to Cardano wallets that follow the CIP-1852 standard.
To differentiate constitutional committee hot keys from other Cardano keys, we define a new role index of 5:
m / 1852' / 1815' / account' / 5 / address_index
We strongly recommend that a maximum of one set of constitutional committee hot keys should be associated with one wallet account, which can be achieved by setting address_index=0.
Tools and wallets can generate a constitutional committee hot credential (committee_hot_credential) from the Ed25519 public constitutional committee hot key (without chaincode) by creating a blake2b-224 hash digest of the key.
As this is key-based credential it should be marked as entry 0 in a credential array.
These are also described in CIP-0005 | Common Bech32 Prefixes, but we include them here for completeness.
Note we also include the prefixes for script-based credentials in the following subsections, for completeness.
DRep keys and DRep IDs should be encoded in Bech32 with the following prefixes:
| Prefix | Meaning | Contents |
|---|---|---|
drep_sk |
CIP-1852’s DRep signing key | Ed25519 private key |
drep_vk |
CIP-1852’s DRep verification key | Ed25519 public key |
drep_xsk |
CIP-1852’s DRep extended signing key | Ed25519-bip32 extended private key |
drep_xvk |
CIP-1852’s DRep extended verification key | Ed25519 public key with chain code |
drep |
Delegate representative verification key hash (DRep ID) | blake2b_224 digest of a delegate representative verification key |
drep_script |
Delegate representative script hash (DRep ID) | blake2b_224 digest of a serialized delegate representative script |
Constitutional cold keys and credential should be encoded in Bech32 with the following prefixes:
| Prefix | Meaning | Contents |
|---|---|---|
cc_cold_sk |
CIP-1852’s constitutional committee cold signing key | Ed25519 private key |
cc_cold_vk |
CIP-1852’s constitutional committee verification signing key | Ed25519 private key |
cc_cold_xsk |
CIP-1852’s constitutional committee cold extended signing key | Ed25519-bip32 extended private key |
cc_cold_xvk |
CIP-1852’s constitutional committee extended verification signing key | Ed25519 public key with chain code |
cc_cold |
Constitutional committee cold verification key hash (cold credential) | blake2b_224 digest of a consitutional committee cold verification key |
cc_cold_script |
Constitutional committee cold script hash (cold credential) | blake2b_224 digest of a serialized constitutional committee cold script |
Constitutional hot keys and credential should be encoded in Bech32 with the following prefixes:
| Prefix | Meaning | Contents |
|---|---|---|
cc_hot_sk |
CIP-1852’s constitutional committee hot signing key | Ed25519 private key |
cc_hot_vk |
CIP-1852’s constitutional committee verification signing key | Ed25519 private key |
cc_hot_xsk |
CIP-1852’s constitutional committee hot extended signing key | Ed25519-bip32 extended private key |
cc_hot_xvk |
CIP-1852’s constitutional committee extended verification signing key | Ed25519 public key with chain code |
cc_hot |
Constitutional committee hot verification key hash (hot credential) | blake2b_224 digest of a consitutional committee hot verification key |
cc_hot_script |
Constitutional committee hot script hash (hot credential) | blake2b_224 digest of a serialized constitutional committee hot script |
Supporting tooling should clearly label these key pairs as "DRep Keys".
Examples of acceptable keyTypes for supporting tools:
keyType |
Description |
|---|---|
DRepSigningKey_ed25519 |
Delegate Representative Signing Key |
DRepExtendedSigningKey_ed25519_bip32 |
Delegate Representative Extended Signing Key |
DRepVerificationKey_ed25519 |
Delegate Representative Verification Key |
DRepExtendedVerificationKey_ed25519_bip32 |
Delegate Representative Extended Verification Key |
For hardware implementations:
keyType |
Description |
|---|---|
DRepHWSigningFile_ed25519 |
Hardware Delegate Representative Signing File |
DRepVerificationKey_ed25519 |
Hardware Delegate Representative Verification Key |
Supporting tooling should clearly label these key pairs as "Constitutional Committee Cold Keys".
Examples of acceptable keyTypes for supporting tools:
keyType |
Description |
|---|---|
ConstitutionalCommitteeColdSigningKey_ed25519 |
Constitutional Committee Cold Signing Key |
ConstitutionalCommitteeColdExtendedSigningKey_ed25519_bip32 |
Constitutional Committee Cold Extended Signing Key |
ConstitutionalCommitteeColdVerificationKey_ed25519 |
Constitutional Committee Cold Verification Key |
ConstitutionalCommitteeColdExtendedVerificationKey_ed25519_bip32 |
Constitutional Committee Cold Extended Verification Key |
For hardware implementations:
keyType |
Description |
|---|---|
ConstitutionalCommitteeColdHWSigningFile_ed25519 |
Hardware Constitutional Committee Cold Signing File |
ConstitutionalCommitteeColdVerificationKey_ed25519 |
Hardware Constitutional Committee Cold Verification Key |
Supporting tooling should clearly label these key pairs as "Constitutional Committee Hot Keys".
keyType |
Description |
|---|---|
ConstitutionalCommitteeHotSigningKey_ed25519 |
Constitutional Committee Hot Signing Key |
ConstitutionalCommitteeHotExtendedSigningKey_ed25519_bip32 |
Constitutional Committee Hot Extended Signing Key |
ConstitutionalCommitteeHotVerificationKey_ed25519 |
Constitutional Committee Hot Verification Key |
ConstitutionalCommitteeHotExtendedVerificationKey_ed25519_bip32 |
Constitutional Committee Hot Extended Verification Key |
For hardware implementations:
keyType |
Description |
|---|---|
ConstitutionalCommitteeHotHWSigningFile_ed25519 |
Hardware Constitutional Committee Hot Signing File |
ConstitutionalCommitteeHotVerificationKey_ed25519 |
Hardware Constitutional Committee Hot Verification Key |
This CIP is not to be versioned using a traditional scheme, rather if any large technical changes are required then a new proposal must replace this one. Small changes can be made if they are completely backwards compatible with implementations, but this should be avoided.
By standardizing derivation, naming, and tooling conventions we primarily aim to enable wallet interoperability. By having a standard to generate DRep and constitutional committee credentials from mnemonics, we allow wallets to always be able to discover a user’s governance activities.
This approach mirrors how stake keys were rolled out, see CIP-0011 | Staking key chain for HD wallets. We deem this necessary since these credentials sit alongside each other in the Conway ledger design.
The alternative would be to define a completely different derivation paths, using a different index in the purpose field, similar to the specification outlined within CIP-0036, but this could introduce complications with HW wallet implementations.
We believe the overhead that would be introduced by multi-DRep accounts or multi-constitutional-committee is an unjustified expense. Future iterations of this specification may expand on this, but at present this is seen as unnecessary. This avoids the need for DRep, cc hot or cc cold key discovery.
We model this on how stake keys are generally handled by wallets. If required, another CIP could, of course, introduce a multi-DRep/CC method.
For simplicity, we have omitted network tags within the encoding. This is because we have modeled DRep IDs and CC credentials on stake pool operator IDs, which similarly do not include a network tag.
The advantage of including a network tag would be to reduce the likelihood of mislabelling a DRep’s network of operation (eg Preview v Cardano mainnet).
See Test Vectors File.
- The DRep derivation path is used by three wallet/tooling implementations.
- The consitutional committee derivation paths are used by two implementations.
- Author to provide an example implementation inside a HD wallet.
This CIP is licensed under CC-BY-4.0.