Remove Vault Theft Reporting
Democracy
3 Comments
FastTracked

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:
  • User can move 1 kBTC
  • 1 BTC “locked” in Vault
  • 260% worth of Vault KSM collateral locked with parachain

    Total capital locked = 1 BTC (100%) + 260% collateral = 360%

kBTC exists:
  • User can move 1 kBTC
  • Vault can freely move 1 BTC
  • 260% worth of Vault KSM collateral locked with parachain

    Total capital locked = 260% collateral

Redeem (success):
  • User returns 1 kBTC
  • Vault sends 1 BTC to user
  • 260% worth of Vault KSM collateral is unlocked
Unchanged
Redeem (fail):
  • User returns 1 kBTC
  • Vault fails to send 1 BTC to user
  • 150% worth of Vault KSM collateral is confiscated and paid to user.
  • Vault keeps BTC and is removed from active Vault list

    Note: user can also retry with another Vault. In this case, only a small % of the Vault collateral is slashed and the Vault remains operational.

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Edited
Reply
Up
Share
Second
No current seconds
This proposal has been turned into referendum.
  • Call
  • Metadata
  • Timeline2
Comments

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.

Reply
Up

I think it's also important to point out that the 260% figure is by no means the expected collateralization of a vault. Vault operators may very well choose not to add new collateral when KSM drops in value (expressed in BTC) until hitting the premium redeem threshhold (currently 200%).
If we remove theft reporting, the game is about incentives (and penalties).
Is 5% premium enough penalty when collateralization ratio is between 150 and 200%? I don't think so.
Is 10% premium enough penalty when a vault does not reimburse on time? I don't think so.
I'd be voting NO without further changes to the model.

Reply
Up

@a3cF...AjJw

"Is 5% premium enough penalty when collateralization ratio is between 150 and 200%? I don't think so."
Why?
It's sufficient for someone developing a bot and sniping all vaults going below 200%, thus securing the collateralization level.
And what if no one snipes them what's the risk? Going below 150%? Then the vault is liquidated anyway

"Is 10% premium enough penalty when a vault does not reimburse on time? I don't think so."
Again why? I think it's already a significant risk taken by the vaults especially considering that can happen to well intended vaults due to congestions on BTC network.
It's already x20 higher than the guarantee users provide to vaults when issuing kBTC for locking the capacity of the vault (and associated rewards) until expiry of the request.

Considering that:

  • The guarantee a user gets for sending his BTC remains unchanged
  • The team is explaining that this feature is highly complex to develop while ensuring the security of the BTC in the vault (see critical vulnerabilities identified on the parsing of BTC tx).
    It seems to me that this is a no brainer "yes".

Plus, as a vault operator, I can tell that the new use cases this change enables, eliminates some of the risks as a vault, and might allow increasing collateral faster:

  • System exiting: until a few weeks ago kBTC was at full capacity, thus we did not have any guarantee to be able to leave the system without bringing the value of kBTC locked ourselves. This could potentially lead to people not running a vault, put less collateral to keep locked BTC value available, and/or self-issue only.
  • BTC cold storage: it's good to have the opportunity to look at this, as it might bring more security as a vault
Reply
Up 1