Should Gnosis Build Gnosis Protocol v2?
UPDATE 2 (Jan 12, 2021): There has recently been team discussion surrounding the possibility of making the Allowance Manager “upgradable” in the sense that token approvals would only ever have to be submitted once and thus, independent of version upgrades to the settlement contract. This means that the Allowance Manager reserves the right to transfer user allowances to an upgraded version of the settlement contract. It has been proposed that such an upgrade would be subject to a time-lock, giving users the opportunity to revoke allowances. While opening up this possibility introduces potential security risks, there is the very handy UX benefit that users would only every have to approve tokens once ever.
For more active discussion on the matter, please visit the open issue on github: Consider porting prior allowances · Issue #298 · gnosis/gp-v2-contracts · GitHub
- Yes: Lets make Allowance Manager “Upgradable”
- No: This is a bad idea.
0 voters
UPDATE: As of Jan. 5 2021, the status of this is “Phase 1” (Discussion only). We have received plenty of good feedback and are now putting together a formal specification in preparation for Phase 2 of the governance process. This will hopefully be ready by the end of the month.
We at Gnosis would like to open and encourage discussion for the proposal of Gnosis Protocol v2 (GPv2) by initiating phase 1 of GnosisDAO community consulting. Gnosis Protocol v1 was released by the Gnosis team at the beginning of 2020. Half a year later, we were well aware of its weak points: its non-atomicity doesn’t allow connectivity to existing on-chain liquidity, the gas cost of placing on-chain orders would prevent market makers from offering tight spreads, and most operations (e.g. trading, withdrawing) take too long, making them too cumbersome for a good user experience. Until now, the protocol has mostly been used for IDOs, as its batch trading service was recognized as a fair price finding mechanism. Now, we are excited to present our fresh new ideas for v2, which eliminate the most substantial weaknesses described above.
To participate in this proposal, we recommend background knowledge of Defi, Auction Theory and Gnosis Protocol v1.
Introduction for v2
Gnosis Protocol v2 is a DEX platform facilitating ERC20 token trading. The unique selling points of Gnosis Protocol are gasless order placement and the ability to match retail traders with each other, hence offering better prices than pure dex-aggregators.
With a very simple (Uniswap-like) UX, users will submit off-chain orders to an order service. An algorithm based on the number of orders and their timestamps will be used to split the users’ orders into distinct batches. Each batch of orders will be processed by several (competing) solvers. Each solver internally uses an optimization process to find the best uniform clearing price for orders from that batch. Solvers will then submit their clearing price along with the corresponding batch of orders to the Ethereum blockchain for settlement. The settlement can involve many on-chain liquidity resources such as Uniswap, Curve, Kyber, etc. If solvers are not serving in the interest of customers and calculate unbeneficial prices, they will be out-performed by other solvers. If they do not conform to pre-defined fairness criteria, they can even be slashed by a DAO, a decentralized entity governing the Gnosis Protocol.
Main Objectives
The Gnosis Protocol v2 will be built for retail customers who prefer a simple and smooth user experience and private market makers competing with Uniswap spreads. The targeted customers are currently trading mostly on Uniswap. Gnosis Protocol v2 is expected to regularly offer better prices than Uniswap. The main objectives of this protocol are described as follows:
-
Gasless UX: User orders only need to be signed and can be submitted off-chain, so there will be no gas estimations or any possibility of failed transactions. This alone will be a major contributor to a smoother user experience than existing DEX aggregators.
Note: The user would still be required to submit one transaction approving the Gnosis settlement contracts to access funds. -
Better prices than existing dex-aggregators: This is a result of competing solvers along with accounting for coincidences of wants between retail customers before invoking other on-chain liquidity sources. For example, two “overlapping” orders could be matched directly with each other before incurring any fees that would be imposed if the traders had traded on Uniswap. The more customers that are trading on Gnosis Protocol, the more likely are the coincidences of wants. Hence, the protocol has a strong network effect.
-
Easy market maker integration: The protocol is built in a way such that it minimizes the volatility risk for market makers by settling their off-chain signed orders quickly. This allows them to offer tight spreads.
-
No deposits or withdrawals into an exchange contract: For a settlement of orders, there is only one Ethereum transaction required from the solver. This means that all trades are matched and balances are credited directly to the users’ accounts atomically in a single Ethereum transaction.
-
Access to on-chain liquidity: This protocol is built to natively interact with any contract in the Ethereum blockchain; this allows trading with any existing atomic exchanges. Thanks to this ability, users have access to existing liquidity pools and hence can expect to get prices that are at least as good as what they would receive elsewhere on-chain.
Technical Description
Involved Parties
-
Retail customers: A retail customer can submit off-chain orders to the protocol, which will be matched directly with other retail customers (or the best available on chain liquidity otherwise) when possible. Technically speaking, a retail customer is an externally owned account (EOA).
-
Market makers: The platform is built such that market makers can operate with minimized risk. They are able to create an order valid only for a short period of time without revealing its details to anyone but the solver, reducing the risk of being front-run. Only after the solver has found a solution, the solvers will ask for confirmative bids from market makers and then settle them quickly.
-
Order services: The order service will receive orders from retail customers and provide them to the solvers. This service could be decentralized, but it will likely be centralized in the beginning.
-
Solvers: A solver will receive the retail order batches from the order service and will further enrich this trading data with existing on-chain liquidity data. Having this, they will generate valid settlements for all orders with uniform clearing prices. If no other solver has found a better solution, they will be settled on-chain. Technically, solvers will be accounts from a curated list of contracts or EOAs. At some point, we envision a permissionless GNO staking mechanism that would entitle anyone to become a solver.
-
A decentralized autonomous organization (DAO): A DAO plays multiple roles:
- Appoint and dismiss solvers
- Enforce the correct behavior of solvers by imposing appropriate measurements
- Manage solver fee allocation and distribution
Technical Infrastructure
Smart Contract(s)
The contracts are capable of settling users’ off-chain signed orders by executing arbitrary ring trades and tapping into various on-chain liquidity sources. The smart contract protects all users by ensuring that their limit prices are met, and it is optimized for settling orders at a given uniform clearing price.
Order Service
The off-chain services expose an endpoint for posting signed orders. These orders are timestamped, stored, filtered for spam (i.e. invalid or economically inviable), and orders are made available to the solvers.
API
- Interface for users to post signed orders
- Interface to query current orderbook
- Interface to query the current estimated prices
- Query the “tip”: Any order that does not meet the protocol’s minimum trade threshold must include a tip to make it economically viable for a solver to settle. Note that the tip will be roughly equivalent to the expected gas cost of settling the order.
Solver
Solvers fetch the retail orders from the order service, find “solutions,” and invoke the settlement transaction. Solvers are also responsible for:
-
Order enrichment: In order to find the best prices, the solvers are querying the current state of the on-chain liquidity and merge this information into one optimization problem together with the retail orders.
-
Integration with market makers: Solvers will query indicative quotes from market makers and include them in their optimization problem. When an indicative quote from a market maker is suitable, solvers will request a firm quote from the market maker, amend the solution if needed, and then immediately submit this along with the settlement. This behavior limits the risk for market makers.
-
Finding the best solution: Solvers are tasked to find solutions in favor of retail orders. Technically, this means that the solutions should be envy-free for retail traders. Furthermore, all different solutions from the various solvers will be graded by a metric, such as the traders’ utility or the overall trading volume.
-
Monitoring the mempool for other existing solutions:
-
When a solver’s own solution is significantly better than those existing in the mempool, they would submit their solution with a higher gas price in order to “outbid” the current best solution. Solvers would do that to gain more rewards from the DAO.
-
The notion of “significantly better” is to be defined by the DAO (and verified retroactively after solutions have been submitted). Initially, solver addresses have to allowlist themselves by staking GNO, and it will be the case that no solution should be significantly better than any other correct solution. Hence, when v2 is first deployed, the first solution provided by a solver will be chosen and settled.
-
Frontend
The web interface will provide the user with a simple swap interface, focusing on a smooth user experience. Likely, it will be quite similar to the Uniswap interface. Upon “swapping” tokens, instead of creating an Ethereum transaction, it should ask the user to sign a message using their EOA and submit this message to the service endpoint.
In the unlikely event that an order is not matched within its specified validity time frame, it would be marked as cancelled.
The frontend queries the required tip from the order service and displays this to the users. During the order signing process, the user will allow the Gnosis Protocol contract to withdraw the tip amount additional to the sell amount of the order. The tips will later be distributed by the DAO to the solvers, in order to cover their gas costs.
The web interface will be decentrally hosted via IPFS and owned by a DAO.
GNO Holder Benefits
Eventually, becoming a solver will be open to the public as a permissionless GNO staking mechanism, and the DAO will operate a fee management system that converts some fraction of the collected fees into GNO and burns this GNO.
Open Ideas
Currently, the infrastructure is designed in a quite generic way. The smart contracts are very flexible and could serve a variety of use cases.
Two particular avenues of interest are to build infrastructure
-
Focusing primarily on guaranteeing better or equal prices than Uniswap: Via external wrapper contracts one could check that the submitted solutions by the solvers are indeed, at the time of submission, resulting in better prices for the retail users than a single trade on Uniswap.
-
As a generic gasless DEX aggregation service. This approach will focus on inclusion, as quickly as possible, of several additional liquidity sources other than Uniswap and curve.
We are looking forward to the input of the community and their thoughts on shaping the Gnosis Protocol version 2!
References
For more detail on some of the topics covered above, we have included some additional references as links
