Vault Banning

[gregdhill]

Vaults are slashed on redeem failure, do we also need to ban them for 24h?

[josef-widder]

The question was, what is the reason for the punishment delay? The delay stopped them to perform redeems for 24 hours.

As the fees are spread over all participants, the consequence of not being able to act seem unclear.

Perhaps not paying out fees (or reducing their SLA) for 24 hours would make more sense? But I haven't studied the new fee / sla specs and code in detail yet.

[gregdhill]

For reference, the following actions are currently prohibited when a Vault is banned:

• request_issue
• request_redeem
• request_replace
• accept_replace

We have recently removed the SLA module, but the Vault may still earn rewards on locked interBTC unless reimburse == true.

[sander2]

I agree that disallowing redeem does not really punish vaults - rather the opposite, since it's in the vault's interest to have as many issued tokens as possible for maximum reward generation.

Perhaps not paying out fees (or reducing their SLA) for 24 hours would make more sense

I like this idea, we could certainly temporarily reduce the vault's stake for the rewards. Although implementing it requires a bit of a change since stake will no longer be equal to the collateral - we would need to separate the accounting for both of these.

[nud3l]

Good points. Agree that banning the vaults for 24 hours is not a punishment per se.

Punishment aspect Banning vaults only prevents them from not being able to accept additional issue requests and thus not being able to increase their reward stake in the system. For that reason alone, we might not want to include it.

Vault protection aspect A vault client might experience a temporary outage (e.g., servers are down). In that case, the 24 hour delay might help vault operators that their system is not drained of collateral if they go offline for 24 hours. The punishment delay might actually help them to recover their services. This might be a good enough reason to keep this.