| KIP | Title | Author | Status | Type | Category | Created |
|---|---|---|---|---|---|---|
0012 |
Kadena Single-Key Accounts |
Stuart Popejoy stuart@kadena.io, Doug Beardsley doug@kadena.io |
Final |
Standard |
Chainweb |
2021-09-23 |
Define and implement a naming standard for accounts having guards in Kadena where for some single-key keyset with "keys-all" predicate, creating an account starting with "k:" followed by the public key of the keyset is enforced to only have a guard consisting of that keyset. This is called a "Single-Key Account Protocol".
This also reserves all accounts starting with "C:" where C is any latin-1 character. As such this is both a standard for "Kadena Account Protocol" as well as the Single-Key Account Protocol.
Kadena's account naming flexibility is more advanced than what wallets and dapps present to users today. The "old way" (really the Ethereum way, since Bitcoin HD wallets have long mastered multiple keys and multiple accounts) links a key irrevocably to a single account. On Kadena this manifests as an account where the public key acts also as the name of the account, or where the account name is a hash of the public key. Most wallets aren't designed for multi-account or multi-chain so they expect/demand that the key match the account name in some deterministic way.
In this world, multi-account flexibility creates a problem on multi-chain: accounts named after a given key can be "hijacked" on other chains. While it would be preferable that wallets simply grok a multi-chain world, they don't, which means somebody could think they're sending you money on a different chain, since it's the same account ID, but somebody else "squatted" on the account name. With the Single-Key Account Protocol you ensure that for a given keypair, that account cannot be "squatted" on another chain.
This approach "does no harm" as it merely reserves a namespace from the infinite pool of possible account names.
It also still allows multisig and other guards: it is only enforced on account creation. After you create the account, you are allowed to rotate the account keyset to include more than one key. This lets the reserved "k:" account name work for multi-sig while still guaranteeing that it was originally controlled by the expected key.
Again since this only impacts account creation, there are no backcompat issues for existing accounts.
This is implemented in v3 of the Kadena Coin Contract.
We also provide account-protocols-v1 as essentially a marker interface to indicate a fungible-v2 or other custody
ledger supports the protocols. Note that KDA/the coin contract does NOT export this interface at this time.
- Interface: account-protocols-v1.pact