Vault Liquidation Recovery about interbtc HOT 5 CLOSED

I'd be happy for you to start working using the to_be_issued, issued, to_be_redeemed approach.

from interbtc.

I initially assumed all of the vault state on the chain would need to be cleared, but on second thought, it may not have to. We might even be able to resume normal operation even when there are still open redeems if the extrinsic locks sufficient new collateral

However, this introduces a dependency on the internal representation of Vault state, which may change in the future.

I don't think that's relevant - if the internal representation were to change, the check could be just be changed as well. It's far more difficult to determine there are no more open requests than to check the issued tokens, since you'd have to iterate over all of the requests

from interbtc.

I second @sander2 on this one.

Instead of ensuring there are no more pending requests associated with the VaultId, the recover_vault_id(...) extrinsic could check that the to_be_issued, issued, to_be_redeemed fields in the Vault struct are all zero. However, this introduces a dependency on the internal representation of Vault state, which may change in the future. Relying on finalized requests encapsulates this internal representation. Correctness is still preserved by the proposed solution, because the fields mentioned above can only be changed by new and pending requests.

This is the better solution since the to_be_issued, issued, to_be_redeemed format is extremely unlikely to change (I don't have anything in mind that would change this). It's also more foolproof than checking for open requests since ultimately this is our core source of truth w.r.t. Vaults.

Slight modification would be: recover_vault_id(vault_id, active_status, Option<collateral>)

If all of to_be_issued, issued, to_be_redeemed are zero, the vault can directly be activated. If these are non-zero, the function checks if enough additional collateral is added to be above the secure collateral threshold and then reactivate the vault.

from interbtc.

@nud3l Allowing a vault to recover while to_be_redeemed is non-zero creates an edge case where collateral may remain frozen indefinitely. It would happen when a vault is reported for theft with to_be_redeemed tokens; the vault calls recover_vault_id(...) and then redeem::execute_redeem(...). In this scenario, decrease_liquidated_collateral() no longer gets called here, since the execution branch is different.

If you want to avoid this edge case and require zero to_be_redeemed, then liquidated vaults have zero issued and to_be_issued anyway, so it wouldn't make sense to keep the Optional<collateral> parameter.

from interbtc.

Closed by #647

from interbtc.