šŸŸ©Slashing & liquidation mechanisms

How can Lockers get slashed?

Slashing mechanisms force Lockers to behave honestly and responsibly; otherwise, their locked collateral will be slashed, and the affected users will be compensated with the slashed collateral. Slashing mechanics are applied in two cases:

Slashing thief Locker

If a Locker moves its Bitcoin assets without a valid reason, the Locker would be slashed. Lockers are responsible for securely holding Bitcoin assets and should not move them on Bitcoin unless there is an unwrap request that requires them to do so. If they move Bitcoin assets for any other reason, such as being hacked or attempting to steal assets, they will be slashed.

Suppose the Locker moves some of the Bitcoin assets to their address. Anyone can take this transaction, generate an inclusion proof for it, and submit it to the TeleSwap contract. The contract then checks if this transaction matches any of the previous unwrap requests. If it doesn't match, the contract accepts this evidence as proof of the Locker's theft and slashes the Locker's collateral. The contract finds the amount of moved Bitcoin assets and slashes a multiple of that from the Locker's collateral.

Other users can then send their wrapped Bitcoin assets to the TeleSwap contract and receive slashed collateral in return. They receive a discount when purchasing slashed collateral. The contract then burns the collected wrapped assets. This ensures that all wrapped Bitcoin assets are backed by sufficient collateral and native Bitcoin assets.

Slashing lazy Locker

Lockers are responsible for processing users' unwrap requests on time; otherwise, they will get slashed. If they neglect a request by failing to send the native assets to the user or processing it with significant delay, their collateral will be slashed.

To prevent a Locker from getting slashed due to laziness, they need to process unwrap requests very quickly by sending the requested native assets to users and providing proof of payment. The contract verifies the proof and marks the request as processed. If there is an unprocessed request, anyone can call the contract to slash the Locker. Based on the unwrap request amount, the contract slashes a multiple of the Locker's collateral and sends it to the user whose unwrap request is not processed.

Can Locker's collateral be liquidated?

Lockers' collateral can be liquidated to ensure that the value of the locked collateral exceeds the value of their Bitcoin assets. If the value of the collateral falls below that of the managed Bitcoin assets, the Locker has an incentive to steal all Bitcoin assets. Liquidation ensures the security of the protocol by guaranteeing that there is always enough collateral available to be slashed in case of theft or laziness.

For locked collateral, we define a health factor. This factor indicates whether the collateral is healthy or not. If the health factor falls below 100, then anyone can trigger the contract to liquidate the Locker. Users can send wrapped Bitcoin assets to buy the Locker's collateral at a discount. The collected wrapped assets are then burnt, and the Locker receives an equivalent amount of native assets in Bitcoin. The health factor is calculated as follows:

HealthFactor=LockedCollateralValue/(BitcoinAssetsValueāˆ—LiquidationRatio)HealthFactor = LockedCollateralValue/(BitcoinAssetsValue*LiquidationRatio)

To avoid liquidation, Lockers can add extra collateral if there is a risk of liquidation. Since liquidation results in financial loss for Lockers, they should aim to avoid it by adding sufficient collateral. In the event of collateral liquidation, we allow the liquidator to liquidate the collateral up to the point where the health factor of the remaining collateral remains below the upper health factor. This limits the amount that users can liquidate, thus protecting Lockers from the liquidation of a significant portion of their assets.

So, in summary, liquidation is activated if:

HealthFactor<100HealthFactor < 100

And after liquidation, the following should hold:

NewHealthFactor<UpperHealthFactorNewHealthFactor < UpperHealthFactor

Otherwise, the contract rejects the liquidation, indicating that the user is attempting to liquidate more than the allowed limit.

Last updated