Closed nicholaspai closed 4 years ago
We don't neccessarily want to set a maximum, but setting a minimum makes sense.
One way to reconcile both concerns while preventing liquidations infinitesimally less than 100% is to enforce minimum increment sizes (1 token (1e18 wei)). In other words, only allow partial liquidations with the input maxTokensToLiquidate
divisible by 1 unit.
Any positions with less than the minimum increment must be fully liquidated.
We don't necessarily want to set a maximum, but setting a minimum makes sense.
One way to reconcile both concerns while preventing liquidations infinitesimally less than 100% is to enforce minimum increment sizes (1 token (1e18 wei)). In other words, only allow partial liquidations with the input
maxTokensToLiquidate
divisible by 1 unit.Any positions with less than the minimum increment must be fully liquidated.
This solution could work but what if the created position a unit number of tokens? Or the sponsor retroactively creates additional debt with non-whole numbers. This fraction will be impossible to reconcile given this restriction.
Alternatively we can bound the liquidation to be larger than some arbitrary amount (say 1e18 wei units) and then the upper bound is disjoint: either the full token position or nothing between tokensOutstanding * 0.95
and tokensOutstanding
. This way you cant liquidate 99.99999% of a position, leaving dust as the remainder.
This solution could work but what if the created position a unit number of tokens? Or the sponsor retroactively creates additional debt with non-whole numbers. This fraction will be impossible to reconcile given this restriction.
I agree we shouldn't use %'s/fractions to determine the min size, but instead use raw amounts (i.e. 1e18 wei).
the upper bound is disjoint: either the full token position or nothing between tokensOutstanding * 0.95 and tokensOutstanding. This way you cant liquidate 99.99999% of a position, leaving dust as the remainder.
Wouldn't this be accomplished equally by requiring the amount to be divisible by the min-increment? Example: min-increment = 1e18. Imagine the position has 1.2e18 collateral, then createLiquidation(input)
can only be called with input=1,2
.
As discussed IRL, we refined thinking and latest proposal is to set a minimum liquidation size M
, and moreover forcing the liquidation to leave at least M
collateral in the contract.
If the contract has C
collateral in it, then the liquidated amount L must be (M < L < (C - M))
or L = C
.
We think we can dynamically determine T
(the amount of tokens to liquidate) given P
(the maximum amount of collateral per token to liquidate), D
, the dispute reward, and F
(the final fee). A valid liquidation is one that can be disputed, but a disputer can only be economically incentivized to dispute a liquidation if the dispute reward (a function of D
, T
, and P
) is greater than the cost of disputing (F
).
Closed by #1155 which adds incentive for liquidators not to create small liquidations below a final fee stake
We don't want liquidators liquidating close to (but not equal to) 0% or 100% of the collateral amount for various reasons
Possible solutions
See discussion on "Auction Lot Sizes" for a similar discussion: https://forum.makerdao.com/t/auction-parameter-derivations/781