Operator Delegator Vault Split Tracking issue

[sander2]

Introduction

Currently (v1), Vaults combine two roles:

1. Vaults provide collateral in different assets (DOT, USDT,...) to secure the bridged BTC
2. Vaults run infrastructure to maintain the BTC-Relay and automate cross-chain transactions on Bitcoin and Interlay

In Interlay v2, these two roles are split into Operators and Delegators.

• Operators, like v1 Vaults, run the Vault software and can provide collateral to increase their capacity.
• Delegators, a new role, can delegate collateral to Operators without running software themselves.

This feature will be rolled out gradually.

• Phase 1: Trusted Operator-Delegator Model (B2B). Assumes Operator and Delegator agree on setup outside of the Interlay Dapp UI. Operators DO NOT have access to the collateral provided by Delegators. Operators DO maintain & have access to the BTC wallets and can move (parts of the) BTC into cold storage.
• Phase 2: Social Delegation (B2C). Phase 1 is extended with a delegation UI and Operator stats/karme scores so end-users can pick Operators they wish to delegate to. Look & feel similar to PoS nomination/delegation.
• Phase 3: Improved BTC Management (active research / call for feedback). Phase 3 will focus on improving BTC management by Operators, reducing the risk of Operators mismanaging BTC. Current areas of research include:
  • Multi-operator Vaults. Multiple operators co-running Vaults, managing BTC wallets via multisigs (plain multi-sig, muSig, TSS, MPC).
  • Hot Operator/Cold Delegator wallet split. Delegators specify e.g. 10% of BTC is sent to Operator's hot wallet, 90% is sent to the Delegator-controlled BTC cold wallet. Delegators decide between security (100% of BTC in Delegator wallet, Delegator must sign every redeem transaction) and UX (100% BTC in Operator wallet, Delegator does not need to come online).

Detailed requirements are specified below.

Phase 1: Trusted Operator-Delegator Model

Requirements

Users/BTC Funds: Send BTC to mint kBTC/iBTC to a LP. No change in requirements.

Delegators: Provide liquidity in the form of collateral.

• MUST delegate collateral to operators to become a delegator
• MUST NOT withdraw more collateral than allowed by the secure collateral
• MUST earn rewards for deploying their capital if the commission set by the operator is less than 100% and the distributed rewards to the operator are greater than 0
• MUST be able to withdraw rewards whenever they want
• MUST NOT operate any infrastructure/server/maintain applications.

Operators: Operate the Vault software and maintain the BTC wallet.

• MUST register Vault
• MUST NOT have any custody of collateral of delegators
• MUST opt-in to accept delegated collateral from Delegators
• MUST specify how much delegated collateral they want to accept (absolute number suffices as starting point)
• SHOULD set a custom commission to earn a part of the Delegrator’s fees
• MAY operate the latest version of the Vault client software
• MAY deposit and withdraw collateral

Tracking

• (feat: configurable nomination limit #728) remove secure-threshold based nomination limit
• (feat: configurable nomination limit #728) implement per-vault configurable nomination limit
• (Feat: nomination commission #760) implement a configurable commission for the operator (absolute number)
• add additional tests
  • Feat: nomination commission #760
  • add tests that include slashing and explicit withdrawals
• ([BREAKING] Refactor: remove vault collateral interface #781) see how much effort it would be to migrate to removing VaultRegistry::deposit_collateral in favor of exclusively using the nomination interface
• double check that no migration is required & test on testnet

Phase 2: Social Operator-Delegator Model

Requirements

Users/BTC Funds: Send BTC to mint kBTC/iBTC to a LP. No change in requirements.

Delegators: Provide liquidity in the form of collateral.

• All of the above (Phase 1)
• SHOULD be able to view stats for each Vault before delegating, allowing to determine whether the Vault is reliable or not
• MAY request to be replaced
• MAY accept other replace requests

Operators: Operate the Vault software and maintain the BTC wallet.

• All of the above (Phase 1)
• SHOULD set a custom identity using the identity pallet, which will be then shown on public dashboards
• SHOULD be staked (vKINT/vINTR) on initial registration to the system
• MAY go through legal KYC to be marked as a KYCd/”verified” Vault by a partner of Interlay
• MAY change their commission on the fly
• MAY change their nomination limit

Tracking

• Require certain amount of vINTR to be staked when opting in for nomination

Phase 3: Improved BTC Management

Under active research. Requirements tbc

[gregdhill]

Related: #724 #1110