ADR 001: Keychain Slashing and Locking mechanism
Changelog
- 2024-03-26: Initial draft (@pitasi)
Status
DRAFT
Abstract
Introduce a "lock" mechanism for Keychains, similar to the staking delegations, where a Keychain can lock some funds as a collateral. If the Keychain is slashed, part of the collateral is burned.
Context
Keychain are custodians of user's private keys.
A Keychain can be victim of a security breach or could just go rogue and steal all users' funds.
How can a user decide what Keychain to trust?
How can we disincentivize bad behaviors from Keychain operators?
We propose a locking mechanism for Keychains, similar to the staking delegations, where users can lock some funds as a collateral to a Keychain. This ADR doesn't describe if there are incentives for locking funds, but it could be a possibility.
If the Keychain is slashed for bad behaviors, part of the collateral is burned.
Bad behaviors can be automatically identified by the protocol (e.g. signature requests are not being signed) or by governance (e.g. a user reports a Keychain for stealing funds).
Alternatives
We have considered the following alternatives:
No slashing mechanism
We could have a Keychain without a slashing mechanism. This would make it easier for bad actors to become Keychain operators, as there are no consequences for their actions.
However, we'll encourage the dMultiSig approach, where an address is composed by a threshold of multiple Keychains. This would make it harder for a single Keychain to steal all funds, as it would need to collude with other Keychains.
Backwards Compatibility
- The keychain-sdk is supposed to remain the same, as the locking mechanism is implemented in the protocol level.
Positive
- Users have a metric to use for deciding how much to trust a Keychain, as they have a collateral to lose if they misbehave.
Neutral
- The barrier to become a Keychain operator is higher, as the operator needs to lock some funds as a collateral. This could be seen as a positive consequence, as it would prevent bad actors from becoming Keychain operators.
Further Discussions
- Should we incentivize users to lock funds to Keychains? In a similar way to staking delegations, where users receive rewards for locking funds. The reward would come from the commissions that the Keychain receives for signing.
- Should there be a minimum amount of funds that a Keychain can lock? This would prevent users from locking a very small amount of funds, which would make the slashing mechanism less effective. Alternatively, the users can decide to NOT trust a Keychain that locks a small amount of funds.