---
AIP: 126
Title: Safer cold storage using Ark covenants
Authors: *Moazzam Abdullah Khan*
Status: *Draft*
Discussions-To: https://github.com/ArkEcosystem/AIPs/issues/126
Address: *Ark address used to collect votes for the specific AIP*
Type: *Standards*
Category: *Protocol*
Created: *2019-10-03*
Last Update: *2019-10-04*
---
Crytocurrencies are expected to gain adoption over time and with that their token value is expected to appreciate. As a result holders of these cryptocurrencies become juicy targets for hackers and malicious entities. Covenants are a special construct that allow specifying restrictions on how the covenant address can spend tokens in the future. This AIP proposes a new transaction type that can be used to implement covenants in Ark.
In order to understand the issue in depth we have to first discuss the current approaches to cold storage and the game theoretic incentives involved for malicious entities. In the current paradigm an individual must create an address from a randomly generated secret passphrase. This passphrase has to be stored safely and the owner may lose all control over their account in case the passphrase is leaked. As a result holders of cryptocurrencies become prime targets for hackers and in the event of a hack they have no recourse to protect themselves after the fact. From a hacker's perspective each holder of cryptocurrency represents potential profit sources as the chance of a hack succeeding is non-zero and once a target has been hacked they are unable to nullify the transaction.
This AIP, inspired by the bitcoin covenants approach introduced by Möser et al., introduces a new transaction type. This new covenant registration transaction contains parameters that allow the owner of the address upon creation of the covenant to set restrictions which specify how the address can spend outgoing transactions, or as a last resort burn a previously sent unconfirmed transaction in order to ensure that a potential hacker doesn't benefit from it. Since covenant addresses can be identified publicly any potential attacker will know that there is no profit to be made by attacking the address and that even in the case of a successful hack the amount extracted will be burned by the owner. This knowledge acts as a deterrent against hacking attempts and allows creation of a truly secure cold storage address.
Covenants can also be used to setup dead-man switches which are useful to pass on the owner's wealth to predefined heirs without involving any legal custodian or intermediary in the event of an untimely demise.
A new covenant registration transaction type is introduced containing the following data:
| Parameter | Description | Required |
|---|---|---|
| type | Number representing transaction type | ✅ |
| forced_timelock_duration | Minimum time duration all future outgoing transactions must elapse before they are considered confirmed | ✅ |
| poison_public_key | A "poison" public key which if used will nullify all unconfirmed outgoing transactions from the address | ✅ |
| deadman_trigger_duration | Positive number specifying duration since previous outgoing transaction after which address balance will be sent to inheritors, leave 0 to disable dead man switch | ❌ |
| heirs_list | A list of unique addresses specifying heirs | only if deadman_trigger_duration is non zero |
| heirs_share | A list of numbers representing weights of how to distribute the balance between the heirs | only if deadman_trigger_duration is non zero |
The following rules will apply:
- A covenant registration transaction is only considered valid if it's the first outgoing transaction from the address
- When an address makes a covenant registration transaction it becomes a covenant address and can no longer send normal non-timelocked transactions but it can send vote/unvote transactions
- A covenant address can not register as a delegate
- Any outgoing transaction from a covenant address are considered unconfirmed until the minimum
forced_timelock_durationis completed (similar to other HTLC transactions). Minimum recommended value is equivalent to 3 days. - If a transaction signed by the
poison_public_keyis sent from the covenant transaction all unconfirmed transactions from the address are nullified and the tokens in them are burned - If the
deadman_trigger_durationis non zero thenheirs_listandheirs_sharemust be specified and the number of elements in both lists should be the same - If the
deadman_trigger_durationis non zero and time elapsed since last outgoing transaction is greater than the specifieddeadman_trigger_durationthen it is assumed that the owner no longer has access to the address's private key and the entire balance of the address will be sent to inheriting addresses according to their defined weights.
By providing the owner with the choice to burn their hacked tokens after the hack is discovered we remove the incentive hackers have to try and hack token holders. Additionally the dead-man's switch create a non-custodial mechanism to safely transfer crypto inheritance to heirs. In addition there is no easy way to confer inheritance to heirs in the current crypto paradigm, covenant address can be used to specify a will that executes perfectly and automatically without any intermediaries.
(Will be updated once appropriate) All AIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The AIP must explain how the author proposes to deal with these incompatibilities. AIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
(Will be updated once appropriate) The reference implementation must be completed before any AIP is given status "Final", but it need not be completed before the AIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.
The final implementation must include test code and documentation appropriate for the Ark protocol.