You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cardano uses a sidechain for its treasury system. One needs to "register" to participate on this sidechain by submitting a registration transaction on the mainnet chain. This CIP details the registration transaction format.
27
+
This CIP details a transaction metadata format, used by Cardano's [Project Catalyst](https://projectcatalyst.io) for voter registrations.
15
28
16
-
## Motivation
29
+
## Motivation: why is this CIP necessary?
17
30
18
-
Cardano uses a sidechain for its treasury system ("Catalyst"). One of the desirable properties of this sidechain is that even if its safety is compromised, it doesn't cause loss of funds on the main Cardano chain. To achieve this, instead of using your wallet's recovery phrase on the sidechain, we need to use a brand new "voting key".
31
+
Project Catalyst uses a sidechain for it's voting system.
32
+
One of the desirable properties of this sidechain is that even if its' safety is compromised, it doesn't cause a loss of funds on Cardano mainnet.
33
+
To achieve this, instead of using Cardano wallets' recovery phrase on the sidechain, we introduce the "voting key".
19
34
20
-
However, since 1 ADA = 1 vote, a user needs to associate their mainnet ADA to their new voting key. This can be achieved through a registration transaction.
35
+
However, since Catalyst uses stake-based voting, a user needs to associate their mainnet Ada to their voting key.
36
+
This can be achieved through a voter registration transaction.
21
37
22
-
We therefore need a registration transaction that serves three purposes:
38
+
We therefore need a voter registration transaction that serves three purposes:
23
39
24
-
1. Registers a "voting key" to be included in the sidechain
25
-
2. Associates mainnet ADA to this voting key
26
-
3. Declare an address to receive Catalyst rewards
40
+
1. Registers a voting key to be included in the sidechain
41
+
2. Associates Mainnet ada to this voting key
42
+
3. Declare an address to receive Catalyst voting rewards
27
43
28
44
## Specification
29
45
30
46
### Voting key format
31
47
32
-
A voting key is simply an ED25519 key. How this key is created is up to the wallet.
33
-
34
-
### Associating stake with a voting key
35
-
36
-
This method has been used since Fund 2.
37
-
For future fund iterations, a new method making use of time-lock scripts may
38
-
be introduced as described [below][future-development].
39
-
40
-
Recall: Cardano uses the UTXO model so to completely associate a wallet's balance with a voting key (i.e. including enterprise addresses), we would need to associate every payment key to a voting key individually. Although there are attempts at this (see [CIP-0008]), the resulting data structure is a little excessive for on-chain metadata (which we want to keep small)
41
-
42
-
Given the above, we choose to only associate staking keys with voting keys. Since most Cardano wallets only use base addresses for Shelley wallet types, in most cases this should perfectly match the user's wallet.
48
+
A voting key is simply an ED25519 key.
49
+
How this key is created is up to the wallet, although it is not recommended that the wallet derives this key deterministicly from a mnemonic used on Cardano.
43
50
44
51
### Registration metadata format
45
52
@@ -48,7 +55,8 @@ A Catalyst registration transaction is a regular Cardano transaction with a spec
48
55
Notably, there should be four entries inside the metadata map:
The entries under keys 1, 2, 3, and 4 represent the Catalyst voting key,
65
-
the staking key on the Cardano network, the address to receive rewards,
66
-
and a nonce, respectively. A registration with these metadata will be
67
-
considered valid if the following conditions hold:
68
-
69
-
- The nonce is an unsigned integer (of CBOR major type 0) that should be
70
-
monotonically rising across all transactions with the same staking key.
71
-
The advised way to construct a nonce is to use the current slot number.
72
-
This is a simple way to keep the nonce increasing without having to access
73
-
the previous transaction data.
74
-
- The reward address is a Shelley address discriminated for the same network
75
-
this transaction is submitted to.
76
-
77
-
To produce the signature field, the CBOR representation of a map containing
78
-
a single entry with key 61284 and the registration metadata map in the
79
-
format above is formed, designated here as `sign_data`.
80
-
This data is signed with the staking key as follows: first, the
81
-
blake2b-256 hash of `sign_data` is obtained. This hash is then signed
82
-
using the Ed25519 signature algorithm. The signature metadata entry is
83
-
added to the transaction under key 61285 as a CBOR map with a single entry
84
-
that consists of the integer key 1 and signature as obtained above as the byte array value.
72
+
The entries under keys 1, 2, 3, and 4 represent the Catalyst voting key, the staking key on the Cardano network, the address to receive rewards, and a nonce, respectively.
73
+
A registration with these metadata will be considered valid if the following conditions hold:
74
+
75
+
- The nonce is an unsigned integer (of CBOR major type 0) that should be monotonically rising across all transactions with the same staking key.
76
+
- The advised way to construct a nonce is to use the current slot number.
77
+
- This is a simple way to keep the nonce increasing without having to access the previous transaction data.
78
+
- The reward address is a Shelley address discriminated for the same network this transaction is submitted to.
79
+
80
+
To produce the signature field, the CBOR representation of a map containing a single entry with key `61284` and the registration metadata map in the format above is formed, designated here as `sign_data`.
81
+
This data is signed with the staking key as follows: first, the blake2b-256 hash of `sign_data` is obtained.
82
+
This hash is then signed using the Ed25519 signature algorithm. The signature metadata entry is added to the transaction under key 61285 as a CBOR map with a single entry that consists of the integer key 1 and signature as obtained above as the byte array value.
This CIP is not to be versioned using a traditional scheme, rather if any large technical changes require a new proposal to replace this one.
95
+
Small changes can be made if they are completely backwards compatible.
95
96
96
-
See the [schema file](./schema.cddl)
97
+
### Changelog
97
98
98
-
### Test vector
99
+
Catalyst Fund 3:
100
+
- added the `reward_address` inside the `key_registration` field.
99
101
100
-
See [test vector file](./test-vector.md)
102
+
Catalyst Fund 4:
103
+
- added the `nonce` field to prevent replay attacks;
104
+
- changed the signature algorithm from one that signed `sign_data` directly to signing the Blake2b hash of `sign_data` to accommodate memory-constrained hardware wallet devices.
105
+
106
+
It was planned that since Fund 4, `registration_signature` and the `staking_pub_key` entry inside the `key_registration` field will be deprecated.
107
+
This has been deferred to a future revision of the protocol.
108
+
109
+
## Rationale: how does this CIP achieve its goals?
101
110
102
-
### Rereference implementation
111
+
The described metadata format allows for the association of a voting key with a stake credential on a Cardano network.
Cardano uses the UTxO model so to completely associate a wallet's balance with a voting key (i.e. including enterprise addresses), we would need to associate every payment key to a voting key individually.
116
+
Although there are attempts at this (see [CIP-0008]), the resulting data structure is a little excessive for on-chain metadata (which we want to keep small).
117
+
118
+
Given the above, we choose to only associate staking keys with voting keys.
119
+
Since most Cardano wallets only use base addresses for Shelley wallet types, in most cases this should perfectly match the user's wallet.
105
120
106
121
### Future development
107
122
108
-
[future-development]: #future-development
123
+
A future change of the Catalyst system may make use of a time-lock script to commit ADA on the mainnet for the duration of a voting period.
124
+
The voter registration metadata in this method will not need an association with the staking key.
125
+
Therefore, the `staking_pub_key` map entry and the `registration_signature` payload with key `61285` will no longer be required.
109
126
110
-
A future change of the Catalyst system may make use of a time-lock script to commit ADA on the mainnet for the duration of a voting period. The voter registration metadata in this method will not need an association
111
-
with the staking key. Therefore, the `staking_pub_key` map entry
112
-
and the `registration_signature` payload with key 61285 will no longer
113
-
be required.
127
+
## Path to Active
114
128
115
-
##Changelog
129
+
### Acceptance Criteria
116
130
117
-
Fund 3 added the `reward_address` inside the `key_registration` field.
131
+
-[x] This metadata format is implemented by at least 3 wallets
132
+
- Deadalus <https://daedaluswallet.io/>
133
+
- Eternl <https://eternl.io/>,
134
+
- Flint <https://flint-wallet.com/>,
135
+
- Typhon <https://typhonwallet.io/>,
136
+
- Yoroi <https://yoroi-wallet.com/>
137
+
-[x] This metadata format is used by Catalyst for at least 3 funds
138
+
- This format has been used up to and included Catalyst fund 10
118
139
119
-
Fund 4:
120
-
- added the `nonce` field to prevent replay attacks;
121
-
- changed the signature algorithm from one that signed `sign_data` directly
122
-
to signing the Blake2b hash of `sign_data` to accommodate memory-constrained hardware wallet devices.
140
+
### Implementation Plan
123
141
124
-
It was planned that since Fund 4, `registration_signature` and the `staking_pub_key` entry inside the `key_registration` field will be deprecated.
125
-
This has been deferred to a future revision of the protocol.
142
+
-[x] Author(s) to provide a schema cddl file
143
+
- See the [schema file](./schema.cddl)
144
+
-[x] Author(s) to provide a test vectors file
145
+
- See [test vector file](./test-vector.md)
146
+
-[x] Author(s) to provide a npm package to support the creation of this metadata format
0 commit comments