- Discussions/
- #7/
Next Steps: Burning kBTC for 0 KSM
It’s great to see the community actively engaging with Kintsugi. We would like to point out that in a decentralized bridge, users need to be careful with the trades they are executing against the chain. Please be advised that it is at all times the responsibility of users to ensure that their interactions on the chain are in their interest.
When executing a burn operation, users burn kBTC for collateral of a Vault. This is ideally a beneficial arbitrage trade for users. You can read more here: https://docs.interlay.io/#/Vault/overview?id=burn-event-restoring-a-11-physical-peg
Due to an error in a migration (read more in the post-mortem below), the system was left with an imbalance of kBTC that needed to be burned but 0 KSM that would be returned.
The UI shows users the amount of collateral (right now only KSM) they would receive. Before burning kBTC, users should please check that there is an amount of collateral that would be received in return.
Although the UI showed that 0 KSM would be returned, two users burned their kBTC and consequently received 0 KSM in return.
We advise that the community decides if the two users that burned kBTC for 0 KSM in return should be refunded.
Proposal
- User A: One user burned 0.0575407 kBTC without getting KSM in return. However, the same user received 0.06347786 BTC from the initial liquidation of the Vault that was causing the kBTC available to burn.** This user has thus made a profit of 0.00593716 BTC. Since this user still made a profit overall we advise to not open a treasury proposal to refund the burn amount.**
- User B: This user burned 0.006 kBTC in total and did not receive any KSM or BTC. Since this user burned kBTC without receiving anything in return, we encourage the community to open a treasury proposal to reimburse user B for 0.006 kBTC in KINT.
Detailed Post-Mortem
A user did a redeem with a Vault that had 2 instances running. This caused the Vault to send the Bitcoin twice, resulting in the Vault getting liquidated. The Vault did not execute the redeem. After the redeem expired, the user was able to call cancel_redeem.
However, there was a bug in the code that caused the cancel_redeem function to take the wrong code path, which caused the user to not receive any funds in the cancel_redeem. This was not seen as a problem for the user, since they had already received twice the bitcoin amount, and they got to keep their kBTC as well. Essentially, they got 300% of the value they should have received.
Additionally, there was a bug that caused some collateral to remain in the liquidation Vault if the liquidated Vault had toBeRedeemed tokens.
After the cancel_redeem, the liquidation Vault had tokens that couldn't be burned, and some amount of collateral. To restore the system to a valid state, we did two things: we fixed the reward calculation for liquidation_redeem, and we wrote a storage migration to decrease the liquidation Vault's toBeRedeemed tokens such that users could burn 0.064 KBTC in exchange for 30.5 KSM.
However, when we deployed this, the storage migration failed to run. We later found out that this was because substrate only runs storage migrations when the spec version changes, which we hadn't done. This caused the fix in the liquidation_redeem amount to be deployed before the storage migration ran. When another liquidation took place, the collateral was thus drained from the liquidation Vault. When the storage migration eventually did take place, the result was the liquidation Vault containing 0.06 KBTC but no collateral. This caused the reward for liquidation redeems to be zero. While the UI correctly showed the expected reward was 0, users still chose to do the liquidation redeem, causing them to effectively burn kBTC for no reward.
The user that burned most of the kBTC in this liquidation redeem is the same user that received 300% of the redeem earlier (User A). The kBTC that this user burned in the liquidation redeem is the KBTC that should have been burned in the cancel_redeem in the first place. As such, we do not feel this user needs to be compensated for the loss of funds in liquidation_redeem.
There was, however, another user (User B) that burned 0.006 KBTC:
SubSquare recently had an issue with their decentralized bridge where users burned kBTC for collateral of a Vault but did not receive any KSM in return. This happened because of an error in a migration that caused an imbalance of kBTC. The UI showed that 0 KSM would be returned, but two users still burned their kBTC and received 0 KSM in return. One user made a profit overall, so no refund is advised. However, the other user burned kBTC without receiving anything in return, so the community is encouraged to open a treasury proposal to reimburse them. A post-mortem was conducted, and it was found that there were bugs in the code that caused the cancel_redeem function to take the wrong code path, resulting in the user not receiving any funds. Additionally, there was a bug that caused some collateral to remain in the liquidation Vault. To restore the system to a valid state, they fixed the reward calculation for liquidation_redeem and wrote a storage migration. However, the storage migration failed to run, causing the liquidation Vault to contain 0.06 KBTC but no collateral.
"same user received 0.06347786 BTC from the initial liquidation of the Vault that was causing the kBTC available to burn.** "
If the conditions for burning the KBTC were met for the purpose of obtaining the KSM from the pledge, what does this have to do with the error that occurred during the update?