docs: draft adr-001-keychain-slashing-locking

docs/docs/developers/architecture/adr-001-keychain-slashing-locking.md

@@ -0,0 +1,83 @@
+# 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 behaviours, part of the collateral is
+burned.
+
+Bad behaviours 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 suppoed 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.
+
+## References
+
+* https://github.com/warden-protocol/wardenprotocol/issues/26