Implement Liquidation Contracts

[Chris-Hibbert]

What is the Problem Being Solved?

In order to support a chain with Vaults but without an AMM, we need a different approach to liquidation.

Description of the Design

VaultManagers will use an external liquidator per collateral type to sell underwater collateral via a (variation on a) descending clock auction. Since the auction bidders aren’t present in a physical space, their responses to clock ticks that reduce the offered price are not synchronous. To accommodate that, we accept orders early and hold them in a book. Bidders can configure a bidder agent to hold a large sum and a price schedule to be ready before liquidations occur. Liquidators and buyers can express prices using absolute numbers or as discounts to the current price according to an oracle.

The VaultManager tells the liquidator how much collateral it has to liquidate and how much outstanding debt (including penalties) there is, and hears back how much was paid and how much collateral was sold. It can then go to other buyers (e.g. Crescent via IBC) and look for other offers above the reserve price before dumping the remainder to the reserve. (Are there reasonable rules to follow on when to dump to the AMM for sale at any price? Dean suggested that the presence of other book offers that are out of the money indicates that collateral might be sold the next round. But this only works if those orders have an absolute price and aren't bids in terms of a discount from market.)

There is a liquidator instance per collateral. It keeps book orders and accepts market bids. Some of the orders may represent bidding agents. The agents may not have placed a Zoe offer to purchase, but will do so promptly when called. Other book orders represent actual Zoe offers, and can be satisfied as they are reached. Given this approach, some offers could represent the available price on an AMM. Since they can't respond as quickly, they should probably be in a fallback position.

The liquidator should be configured with the selling parameters either globally or per-asset so that vaults don't have to coordinate on timing or price ranges. It's okay if we have different discount schedules depending on the Econ Committee's evaluation of volatility or riskiness, but there should be one answer per collateral, so vaults offering different terms on the same collateral don't have to coordinate.

The auctioneer will be a separate contract, so can be re-used in other contexts. The auctioneer will sell multiple goods cyclically. The starting design is that it runs all its auctions on the same schedule, though that may change.

The auction has a book, which contains entries that represent standard Zoe offers. The auctioneer publishes the quantity and price level and serves orders as they are received. Bidding agents subscribe to the stream and send offers when they see a price they like, or a price that indicates that the price they want is coming up. Offers can have an exitRule.

Bidder's agents hold an amount of IST and bid in liquidation auctions according to a schedule listing quantity and discount for some collaterals. The bidding agent is a separate contract. It subscribes to a stream of price announcements so it can bid at the right time. The standard agent's strategy is to accept as much as configured of the next offer that arrives.

As the auctioneer ticks the clock forward, it publishes a new price, checks its book for existing orders that can be satisfied immediately, and waits for offers to arrive. Offers are resolved in the order received, selling collateral to bidders as they come in. The proceeds are held until the end of the descending round. At that point (or when the assets are exhausted) the proceeds are returned to the liquidator to be split pro rata among the liquidating vault managers. Each vault manager checks if proceeds exceeded debt plus penalties. If so, it returns collateral to vaults from best Collateralization Ratio to worst. At each step it finds all the vaults with the same best CR, and if there is sufficient collateral, they all get whatever the max refund is. If there isn't enough, it's pro rata for that group of vaults. If collateral remains, we do the same thing with the next group. If not, we're done. Any collateral remaining goes to the Reserve. Any IST remaining is burned to reduce debt or forwarded to the Reserve.

If the auctioneer receives a new tranche to be liquidated while an auction for that good is active, it increases the amount to be sold. We presume vaults are not strategic about joining auctions, so the payout is split as if all the amounts were available from the start. If a new tranche is received while there is no active sale in progress, it waits until the next common start time.

Task list (to be turned into sub-tasks)

• Liquidator
  • refactor to send all underwater vaults to auction simultaneously
  • disburse payout appropriately among Reserve and liquidated vaults
• Descending clock Auctioneer
  • configured for each collateral by start time, length of auction, time step, start price and stopping price
  • (price can be absolute or discount from quote)
  • A new contract (If bidding agents respond to notification, an instance per collateral; else one auctioneer to sell them all)
  • manage clock at each tick sell goods to book orders
  • Manage book orders
    • new orders may be satisfied at current price, or be added to the book
  • When the auction ends (depleted goods or out of time), return result to vaultManagers
• Bidding agent
  • manages IST for one bidder
  • configured according to price and quantity per collaterals
    • (price can be absolute or discount from quote)

Security Considerations

The usual for a critical contract: governance, legibility, fidelity, accounting, reporting.

Test Plan

extensive. Include details on sub-tasks.

[Chris-Hibbert]

The remaining issues (bidding agent) have been moved to #7449.