Summary
After careful consideration, we propose to formally remove Vault theft reporting through governance.
Main motivation:
- No impact on the ecnomic security of the bridge.
- Reduced attack surface (Bitcoin transaction parsing functionality is complex and difficult to maintain / test against Bitcoin Core code). Two critical bugs were already detected (https://medium.com/interlay/kintsugi-released-urgent-security-patches-aebf969ee087)
- Significantly improved Vault flexibility (enables cold/hot storage, easy exit, leveraged positions, …)
On Kintsugi, theft reporting is currently deactivated to fix the two critical bugs. However, this emergency fix did not yet go through formal governance. This proposal suggests a patch to remove theft reporting properly.
Proposal: Remove Theft Reporting
This proposal removed the theft reporting functionality completely from the Kintsugi parachain
Code changes: https://github.com/interlay/interbtc/releases/tag/1.18.0
Why was Theft Reporting implemented in the first place?
Theft reporting was first introduced to enforce a 1:1 peg between BTC and iBTC. The goal was to reduce potential attack surfaces by restricting how Vaults could move the BTC: only when instricuted by the parachain. This came at the cost of flexibility and - as we observed in practice - ended up achieving the opposite of what was intended.
Analysis: No Impact on Economic Security
The following applies before and after removing of theft reporting:
Each minted kBTC is backed by collateral, e.g KSM. The system collateralization rates are set higher than the value of BTC locked (over-collateralization) to ensure Vaults never have incentive fail user redeem requests. In case of a failed redeem or if a Vault’s collateralization rate drops below a pre-defined threshold (still above 100%), the system executes a liquidation: Vault collateral is confiscated and used to reimburse users (Vault gets to keep the BTC).
The following changes (without impact on security):
Using thresholds of the current KSM/kBTC Vauklts on Kintsugi
| With theft reporting
|
Without theft reporting
|
Issue:
- 1 BTC deposited in Vault
- 260% worth Vault KSM collateral locked
- 1 kBTC minted
|
Unchanged
|
| kBTC exists:
|
kBTC exists:
|
Redeem (success):
- User returns 1 kBTC
- Vault sends 1 BTC to user
- 260% worth of Vault KSM collateral is unlocked
|
Unchanged
|
| Redeem (fail):
|
Unchanged
|
Liquidation due to under-collateralization:
- Vault drops below 150% collateralization rate
- 150% worth of Vault KSM collateral is confiscated
- Anyone can burn 1 kBTC to receive the 150% worth of KSM collateral
- Vault keeps BTC and is removed from active Vault list
|
Unchanged
|
As you can see, the only difference is that the Vault can freely move BTC while kBTC exists.
As such, economic security remains unaffected: The decision for a Vault to keep BTC or return it back to the user is still wholly ensured by the collateral at the time of redemption.
Improved Implementation Security
Theft reporting requires parsing BTC addresses from BTC transactions. This is very difficult to implement on-chain as no existing Bitcoin libraries can be used (not compatible with parachain wasm).
This led to two critical bugs identified (see critical bugs: https://medium.com/interlay/kintsugi-released-urgent-security-patches-aebf969ee087 ) and future compatibility issues with Taproot (see technical issues here: https://github.com/interlay/interbtc/issues/606).
Removing theft reporting significantly reduces code complexity and helps avoid aforementioned issues in the future.
Removing Theft Reporting: Enabled, New Product Features
As a positive side-effect, removing theft reporting enables a bunch of new product features, improving the user experience for Vault operators:
BTC cold storage At any given time, it’s unlikely that 100% of the BTC will be redeemed at once. By being able to move BTC freely, Vaults can secure BTC to a cold storage location and only keep part of the BTC in a hot wallet. Each Vault must assess the risk / benefit of keeping BTC in cold storage, e.g. in case of bank runs.
Extra yield from BTC: As Vaults are free to move BTC, they can also use this BTC to earn yield on other platforms (mostly centralized as of now, however). The defaul implementation of the Vault client will keep the BTC in the wallet. Any actions outside the Kintsugi network are at the sole risk and discretion of the Vault operators.
Cost-efficient system exit: A new, more capital efficient way for Vaults to exit the system is made available. Vaults can use the BTC to acquire kBTC over multiple steps, e.g. sell BTC for USDC on a CEX, buy kBTC with USDC on a DEX, use kBTC to self-redeem and close Vault.
Levaraged positions / synthetic minting: The same 1 BTC can now be used to issue multiple kBTC, as long as the collateral backing is in place. This enabled Vaults to take up leveraged positions: mint more kBTC than they have BTC to earn more rewards (locking up the necessary collateral), at the risk of being liquidated if they cannot source the necessary BTC to fullfill redeem requests.
Simplified Vault Operation: We had incidents on Kintsugi where Vault operators were flagged for theft without malicious intent. Rather, due to Bitcoin congestion or operational issues, Vault operators got liquidated. Removing theft reporting will prevent such cases from happening in the future.
—-----------------------------------------------------------
As always, we appreciate your time reviewing this proposal and welcome comments and feedback.
The failed redeem portion of this proposal seems a bit vague. I remember (hopefully accurately) that a user has two choices:
a) try again
b) get reimbursed
In both cases, I believe the premium is only 10%. In case a), 10% is paid in KSM. In case b), you get 110% worth of KSM, not 150%.
I was not aware that the user's choice would affect the amount of KSM being slashed.
Could you clarify the expected behavior? Perhaps it would make sense to also consider collateralization ratio at the time of the failed redeem request.