Dear Community:
Over the last month, we have been doing more research for our GP v1.5 protocol. We were especially trying to find a quickly implementable fix for the market order challenge: Currently, market orders are not very well protected. Especially, reading again all the economic papers on envy-free exchange markets offered a lot of insights and enlightenment. Here are the 3 different routes, which we are considering:
- Fixing only market order challenge:
-
Idea:
Change the objective metric to only maximize utility. At the same time, enforce that each solution must have disregarded utility = 0 on all touched orders. This would protect market orders if the right market maker orders are touched. On top of just considering touched orders, we can in the short term also exhibit a limited amount of order pointers (e.g. 50) which can point to arbitrary orders for which we also enforce 0 disregarded utility (assuming they are on token pairs for which prices exist in the current solution).
These “pointers” would initially be owned by us. Ownership could be handed over to some smart contract logic later (everything from predefined selection rules, auctioning the right to set these, staking GNO, moderated by an admin voted by a DAO) -
Vision:
Fix market mechanism now. The focus is to learn more about the envy-free (disregarded utility ==0) solutions and order pre-filtering with “marking important orders”, scale the system later.
Order pointers would be the first step; later solutions could aggregate orders into slots (cf. “bucketing” prefiltering approach).
In addition to being a remedy to the market order attack issue, this approach would set the auction mechanism onto a more theoretically sound foundation. In the literature, disregarded utility = 0 is an important ingredient for achieving fair equilibria. -
Concerns
- No user-perceived improvement (hidden protection)
- Uncertainty about how hard it is for the solver to enforce envy-free solutions
- Relation between our account model (i.e., uncovered orders) to standard market models (Arrow-Debreu) and the definition of disregarded utility in this situation is ambiguous
-
Changes:
-
Smart-contract:
- Utility calculation should enforce disregarded utility < epsilon on all submitted and pointed to orders,
- Solutions are still ranked by the utility or volume if several solutions exist
-
Solver
- Find envy-free solutions
-
Driver:
- Highlight which orders need to be envy free
-
Timeline:
- 11th of December doable (deployed on mainnet so code freeze would have to be mid November)
-
-
Product market fit:
IDO’s (We will build an IDO “order pointing system” that would objectively mark the highest buying orders right before the solution submission period)
- Focus on improving the liquidity with AMMs ( and have a suboptimal fix for market orders):
-
Idea:
Introduce the uniswap AMM as an order type into our system. Especially, we would enforce that for adding a token XYZ, someone has to add liquidity to the OWL-XYZ pool. These specific OWL-tokens pools have to be traded in each auction, where the token is touched. Their “utility” doesn’t count towards objective function. This allows moderate protection against market order exploits: The deeper the AMM liquidity, the more volume in a malicious price move would have to be “absorbed” by the AMM rather than an attacker (more explanation in appendix). Also, a mandatory pool between every token and OWL would make fake tokens tradable for other traders than only the attacker. -
Vision:
AMMs have proven to be a very effective way to boost liquidity on blockchains. They will allow us to onboard a lot of liquidity with liquidity mining. They will continue to play an important role and hence we should get more experience with them. -
Concerns:
- AMM is at most as good as uniswap, only in combination with orders and uniform clearing prices it is better
- Components such as price estimation and open solver might be hard to implement
- Regarding “having a suboptimal fix for market orders”: IDO project owner must “fund” the AMM as well, and possibly the size of funding must be significant to offer significant protection.
-
Changes:
- Smart-contract:
- Incorporate only the new type of order for AMM and the settlement of AMM
- Deposit and withdraw into the pools (it’s non-trivial)
- Every solution needs to settle the OWL-TOKEN AMM for all tokens touched in the solution
- Solver:
- Find solutions always considering the AMM (relatively easy for standard solver, difficult for open solver)
- Driver:
- Only adaptations to AMM orders and solutions
- Adjust price estimation to incorporate AMMs
- Frontend
- Allow some way of participating in these pools
- Timeline:
- 1st of December doable
- Smart-contract:
-
Product market fit:
Decentralized trading in the long tail
- Go back into research:
-
Idea:
None of the current ideas feels sufficiently good to achieve a viable product on ethereum. We should continue researching scaling solutions like bucketing solutions, zk-protocols. -
Vision:
We would assume that the orderbook based system is currently not viable on ethereum. We could do more research into other blockchain or scaling solutions via zk-protocols, in order to bring the costs of order placements down. To continue learning about auctions with customers, we just build a 2-dimensional approach. -
Changes:
- Prototype only a version 2 with scaling
-
Concerns
- Timeline:
- Delaying and decoupling from user-feedback is like shooting into the dark
- Timeline:
We are very much looking for your feedback!