Two Asset Linear Auction Liquidator Math
The Linear Auction Liquidator uses a modified version of a Dutch Auction to swap assets from the old allocation to assets required for the new allocation. Set's Dutch Auctions differ from traditional Dutch Auctions in that settlement is immediate and not all participants receive the same price. RebalancingSetTokens are collateralized by static SetTokens that encode allocation amounts. The SetToken currently collateralizing the RebalancingSetToken is aptly called the currentSet, while any new proposed allocation is called the nextSet. The auction is priced based on the ratio of nextSet to currentSet, or how many currentSets make up one nextSet, given by the following equation:
Like a traditional Dutch Auction, prices change linearly going from less advantageous to bidders to more advantageous. In this instance, this means that the price of the linear auction is increasing because the buying power of the currentSet is getting worse and thus bidders have to create less nextSet in return for the same amount of currentSet as time passes. See below for example:
Before digging too deep into the math of the auction curve it's worth briefly discussing the limitations of math on Solidity. The biggest limitation one runs into is that Solidity does not allow for floating point numbers, and thus any decimal amounts are rounded down. As such, oftentimes constructs that work in continuous space must be adapted to a discrete space. Quite often this takes the form as having to define the amount of error one is willing to take with a calculation.
Furthermore due to gas costs, Set uses all unsigned integers, which have a domain of [0, 2^256), thus any calculation where there can be an expectation of a negative output must have some sort of switch statement.
All calculations are made with these limitations in mind, and limits the domain over which some calculations can be executed without causing a revert in the transaction.
As stated in previous sections the auction price, , is defined as the ratio of nextSet's created per currentSet. However, it would be impractical and capital inefficient to expect liquidity providers to mint the nextSet and then inject those nextSets into the RebalancingSetToken in return for some amount of currentSets. Thus, a better approach is to relate the amount of nextSets created per currentSet to the net amount of component tokens needed to create that amount of next Sets from a currentSet.
By way of example, say you have currentSet made of components [A, B] with respective amounts [1,1] and nextSet made of components [A,B] with respective amounts [1,2]. By way of simplicity lets assume components A and B are equally valued. If we wanted to calculate a fair auction price we would say it is 1.5 since the value of nextSet is 1.5x currentSet. If the RebalancingSetToken is collateralized by 21 currentSets, then we would expect there to be 14 nextSets after the auction if the auction cleared at fair value. The matching total token flows would be as such [-7, 7] where 7 units of component A would have to be removed from the RebalancingSetToken in exchange for 7 units of component B. If however the auction price slipped to 1.75 then only 12 nextSets would be created and the token flows would be as such [-9, 3], representing a 6 unit profit for liquidity providers.
Since most auctions take a couple bids to settle, a general equation is required to compute the token flows for a given amount of currentSets being rebalanced. That equation is defined as such: