You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
edit: I am no longer a big fan of this proposal, but I have already ideas for a new one. Other write-ups will follow
Overview:
Uniswap liquidity injection orders (uli-orders) are a new type of orders placable for the solution provider with the intention to bridge atomically liquidity from uniswap pools into the auctions.
Background:
While batch auctions are an excellent tool for facilitating fair price finding, the main drawback in the current construction is that they can not connect atomically to the liquidity of all other on-chain exchanges. This liquidity is only available with long time delays of over 5 minutes and risky to bridge for market makers. This proposal will make sure that liquidity from the uniswap exchange can be included in the auction fairly.
Description
The solution providers of a batch are the only actors being allowed to submit uli orders. Uli orders have the following constraints:
they must have a higher limit price than the uniswap price at the time of mining a solution proposal. (E.g., an uli-order selling ETH for USDC at 100, is only valid if the uniswap price is higher than 100 ETH/USDC and an uli-order selling USDC for ETH at 100 is only valid if the uniswap price is lower than 100 ETH/USDC)
the auction clearing price must be between the 5-min time-weighted average prices (TWAP) uniswap price and the uli-orders' limit price if the solver places an uli-order.
their utility is 0
they are only allowed between specific whitelisted, liquid tokens
While the current optimization criterion is well defined and does not change over time, the new system does change over time, as a changing uniswap price constrains uli orders' limit prices. Hence, the solution finding becomes a probabilistic process.
Uli-orders are a game-changer for solution providers. Suddenly, the solution provider will become arbitrage traders to include uniswap liquidity. It is expected that solutions providers need to considered uli-orders to craft the optimal solution, as competing solution providers can use the uli-orders to improve the utility of their solutions. Even though uli-orders itself have 0 utility, their liquidity fills other orders and hence prevents negative utility.
Probably, a good solution provider strategy would be to search deterministically for the optimal solution without uli-orders and then try to optimize the solution by inserting sporadic uli-orders and then solve the problem again. Each uli-order should have a buffer between the current uniswap price and its limit price, due to the constraints and the fact that uniswap prices could still change, until the transaction is minted.
Once a solution with uni-orders is found, the solver will submit it together with an arbitrage-trade on uniswap.
Let's take a look at how uli-orders can influence the system. The following diagrams show on the top a Gnosis-core scenario followed by a uniswap exchange state:
For such a situation, an uli-order could be used to inject liquidity from uniswap without a price change, but a profit for the solution provider:
But if the uli-orders are big enough and generate sufficient utility, they can also influence the clearing price:
Uli orders could also be used to match completely unmatched orders:
The solution provider can not easily manipulate prices in an auction to abuse market orders, as long as he is not able to manipulate the 5-min TWAP. In the following example, the price is not accepted for the auction, as the clearing price is not between the uniswap price and 5min TWAP
(Though this protection with the TWAP might not be working in very quickly raising or falling markets)
Uli-orders will be reverted with a newer and better solution submission. Hence, solution providers do carry some inventory risk.
Summary:
Pros:
more liquidity
price closer to prevailing uniswap price
Provides additional income from arbitrage for the solution providers
As long as uniswap prices are not manipulated, the auctions can consider liquidity from uniswap without compromising the fairness.
Counters the race for the "last order" in the batch - might even make sealed orders unnecessary in the short term.
Cons:
Solution providers are no longer only "computation slaves" but carry inventory risk.
More complex mechanism:
Especially if the uniswap price can be manipulated, this method could be abused. Hence, this mechanism should only be enabled for "liquid" tokens, where manipulating 5-min TWAP is expensive.
The auction fairness should still be given under normal circumstances, as the new possibilities of the solution provider do not grant them the power to influence clearing prices after closing of the auction arbitrarily. They are forced to add "uniswap" liquidity in a specific manner. If they don't comply with the optimal liquidity copying from uniswap, they will be out-competed by a better solution provider.
Initially, the intention was to find a mechanism that would yield always better prices than people are getting on uniswap. While this intention was unrealistic, at least this proposal would ensure that prices between uniswap and gnosis protocol are close together. This is already great, considering that customers bear always the additional risk of high slippage on uniswap.
The text was updated successfully, but these errors were encountered:
@josojo this is a really nice proposal! I wold love if you could present these slides for me at some point to get some better intuition from the illustrations.
As long as uniswap prices are not manipulated, the auctions can consider liquidity from uniswap without compromising the fairness.
I guess after the imBTC (ERC777) hack this weekend, this assumption is no longer a given.
edit: I am no longer a big fan of this proposal, but I have already ideas for a new one. Other write-ups will follow
Overview:
Uniswap liquidity injection orders (uli-orders) are a new type of orders placable for the solution provider with the intention to bridge atomically liquidity from uniswap pools into the auctions.
Background:
While batch auctions are an excellent tool for facilitating fair price finding, the main drawback in the current construction is that they can not connect atomically to the liquidity of all other on-chain exchanges. This liquidity is only available with long time delays of over 5 minutes and risky to bridge for market makers. This proposal will make sure that liquidity from the uniswap exchange can be included in the auction fairly.
Description
The solution providers of a batch are the only actors being allowed to submit uli orders. Uli orders have the following constraints:
While the current optimization criterion is well defined and does not change over time, the new system does change over time, as a changing uniswap price constrains uli orders' limit prices. Hence, the solution finding becomes a probabilistic process.
Uli-orders are a game-changer for solution providers. Suddenly, the solution provider will become arbitrage traders to include uniswap liquidity. It is expected that solutions providers need to considered uli-orders to craft the optimal solution, as competing solution providers can use the uli-orders to improve the utility of their solutions. Even though uli-orders itself have 0 utility, their liquidity fills other orders and hence prevents negative utility.
Probably, a good solution provider strategy would be to search deterministically for the optimal solution without uli-orders and then try to optimize the solution by inserting sporadic uli-orders and then solve the problem again. Each uli-order should have a buffer between the current uniswap price and its limit price, due to the constraints and the fact that uniswap prices could still change, until the transaction is minted.
Once a solution with uni-orders is found, the solver will submit it together with an arbitrage-trade on uniswap.
Let's take a look at how uli-orders can influence the system. The following diagrams show on the top a Gnosis-core scenario followed by a uniswap exchange state:
For such a situation, an uli-order could be used to inject liquidity from uniswap without a price change, but a profit for the solution provider:
But if the uli-orders are big enough and generate sufficient utility, they can also influence the clearing price:
Uli orders could also be used to match completely unmatched orders:
The solution provider can not easily manipulate prices in an auction to abuse market orders, as long as he is not able to manipulate the 5-min TWAP. In the following example, the price is not accepted for the auction, as the clearing price is not between the uniswap price and 5min TWAP
(Though this protection with the TWAP might not be working in very quickly raising or falling markets)
Uli-orders will be reverted with a newer and better solution submission. Hence, solution providers do carry some inventory risk.
Summary:
Pros:
more liquidity
price closer to prevailing uniswap price
Provides additional income from arbitrage for the solution providers
As long as uniswap prices are not manipulated, the auctions can consider liquidity from uniswap without compromising the fairness.
Counters the race for the "last order" in the batch - might even make sealed orders unnecessary in the short term.
Cons:
Especially if the uniswap price can be manipulated, this method could be abused. Hence, this mechanism should only be enabled for "liquid" tokens, where manipulating 5-min TWAP is expensive.
The auction fairness should still be given under normal circumstances, as the new possibilities of the solution provider do not grant them the power to influence clearing prices after closing of the auction arbitrarily. They are forced to add "uniswap" liquidity in a specific manner. If they don't comply with the optimal liquidity copying from uniswap, they will be out-competed by a better solution provider.
Initially, the intention was to find a mechanism that would yield always better prices than people are getting on uniswap. While this intention was unrealistic, at least this proposal would ensure that prices between uniswap and gnosis protocol are close together. This is already great, considering that customers bear always the additional risk of high slippage on uniswap.
The text was updated successfully, but these errors were encountered: