Skip to main content

CIP-0105

Abstract

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.

Motivation: why is this CIP necessary?

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.

Specification

Derivation

DRep Keys

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.

DRep ID

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.

Constitutional Committee Cold Keys

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.

Constitutional Committee Cold Credential

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.

Constitutional Committee Hot Keys

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.

Constitutional Committee Hot Credential

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.

Bech32 Encoding

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

DRep keys and DRep IDs should be encoded in Bech32 with the following prefixes:

PrefixMeaningContents
drep_skCIP-1852’s DRep signing keyEd25519 private key
drep_vkCIP-1852’s DRep verification keyEd25519 public key
drep_xskCIP-1852’s DRep extended signing keyEd25519-bip32 extended private key
drep_xvkCIP-1852’s DRep extended verification keyEd25519 public key with chain code
drepDelegate representative verification key hash (DRep ID)blake2b_224 digest of a delegate representative verification key
drep_scriptDelegate representative script hash (DRep ID)blake2b_224 digest of a serialized delegate representative script

Constitutional Committee Cold Keys

Constitutional cold keys and credential should be encoded in Bech32 with the following prefixes:

PrefixMeaningContents
cc_cold_skCIP-1852’s constitutional committee cold signing keyEd25519 private key
cc_cold_vkCIP-1852’s constitutional committee verification signing keyEd25519 private key
cc_cold_xskCIP-1852’s constitutional committee cold extended signing keyEd25519-bip32 extended private key
cc_cold_xvkCIP-1852’s constitutional committee extended verification signing keyEd25519 public key with chain code
cc_coldConstitutional committee cold verification key hash (cold credential)blake2b_224 digest of a consitutional committee cold verification key
cc_cold_scriptConstitutional committee cold script hash (cold credential)blake2b_224 digest of a serialized constitutional committee cold script

Constitutional Committee Hot Keys

Constitutional hot keys and credential should be encoded in Bech32 with the following prefixes:

PrefixMeaningContents
cc_hot_skCIP-1852’s constitutional committee hot signing keyEd25519 private key
cc_hot_vkCIP-1852’s constitutional committee verification signing keyEd25519 private key
cc_hot_xskCIP-1852’s constitutional committee hot extended signing keyEd25519-bip32 extended private key
cc_hot_xvkCIP-1852’s constitutional committee extended verification signing keyEd25519 public key with chain code
cc_hotConstitutional committee hot verification key hash (hot credential)blake2b_224 digest of a consitutional committee hot verification key
cc_hot_scriptConstitutional committee hot script hash (hot credential)blake2b_224 digest of a serialized constitutional committee hot script

Tooling Definitions

DRep Keys

Supporting tooling should clearly label these key pairs as "DRep Keys".

Examples of acceptable keyTypes for supporting tools:

keyTypeDescription
DRepSigningKey_ed25519Delegate Representative Signing Key
DRepExtendedSigningKey_ed25519_bip32Delegate Representative Extended Signing Key
DRepVerificationKey_ed25519Delegate Representative Verification Key
DRepExtendedVerificationKey_ed25519_bip32Delegate Representative Extended Verification Key

For hardware implementations:

keyTypeDescription
DRepHWSigningFile_ed25519Hardware Delegate Representative Signing File
DRepVerificationKey_ed25519Hardware Delegate Representative Verification Key

Constitutional Committee Cold Keys

Supporting tooling should clearly label these key pairs as "Constitutional Committee Cold Keys".

Examples of acceptable keyTypes for supporting tools:

keyTypeDescription
ConstitutionalCommitteeColdSigningKey_ed25519Constitutional Committee Cold Signing Key
ConstitutionalCommitteeColdExtendedSigningKey_ed25519_bip32Constitutional Committee Cold Extended Signing Key
ConstitutionalCommitteeColdVerificationKey_ed25519Constitutional Committee Cold Verification Key
ConstitutionalCommitteeColdExtendedVerificationKey_ed25519_bip32Constitutional Committee Cold Extended Verification Key

For hardware implementations:

keyTypeDescription
ConstitutionalCommitteeColdHWSigningFile_ed25519Hardware Constitutional Committee Cold Signing File
ConstitutionalCommitteeColdVerificationKey_ed25519Hardware Constitutional Committee Cold Verification Key

Constitutional Committee Hot Keys

Supporting tooling should clearly label these key pairs as "Constitutional Committee Hot Keys".

keyTypeDescription
ConstitutionalCommitteeHotSigningKey_ed25519Constitutional Committee Hot Signing Key
ConstitutionalCommitteeHotExtendedSigningKey_ed25519_bip32Constitutional Committee Hot Extended Signing Key
ConstitutionalCommitteeHotVerificationKey_ed25519Constitutional Committee Hot Verification Key
ConstitutionalCommitteeHotExtendedVerificationKey_ed25519_bip32Constitutional Committee Hot Extended Verification Key

For hardware implementations:

keyTypeDescription
ConstitutionalCommitteeHotHWSigningFile_ed25519Hardware Constitutional Committee Hot Signing File
ConstitutionalCommitteeHotVerificationKey_ed25519Hardware Constitutional Committee Hot Verification Key

Versioning

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.

Rationale: how does this CIP achieve its goals?

Derivation

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.

Why add a new roles to the 1852 path?

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.

Why not multi-DRep/CC wallet accounts?

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.

Encoding

Why not allow network tags?

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).

Path to Active

Acceptance Criteria

  • The DRep derivation path is used by three wallet/tooling implementations.
  • The consitutional committee derivation paths are used by two implementations.

Implementation Plan

  • Author to provide an example implementation inside a HD wallet.

This CIP is licensed under CC-BY-4.0.

CIP Information

This null ./CIP-0105 created on 2023-09-22 has the status: Proposed.
This page was generated automatically from: cardano-foundation/CIPs.