Remove Vault Theft Reporting

Democracy
3 Comments
Executed
  • Content
  • AI Summary
Reply
Up
Share
Votes
AyePassing thresholdNay
78%22%
Aye
75vKINT
Nay
21.01vKINT
Turnout
96.01vKINT
Electorate
0vKINT
Passed
How Kintsugi Governance Works.
  • Call
  • Metadata
  • Timeline3
  • Votes Bubble
Comments
Sort by
Oldest

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