Should Gnosis Build Gnosis Protocol v2?

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:

    1. Appoint and dismiss solvers
    2. Enforce the correct behavior of solvers by imposing appropriate measurements
    3. 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

  1. 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.

  2. 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

  1. Comparison between GPv2 and other dex-aggregators

  2. Smart Contract development site

  3. Smart Contract Architecture Diagram

  4. Schematic Diagram of Technical Infrastructure

  5. Stakeholders Rubrik

15 Likes

Hey, @bh2smith thanks for the great write-up and proposal.

The main objectives of the proposal all seem to align very well with market demands!

From your first line, I assume this proposal aims to request budget/support from the GnosisDAO to Gnosis (the team/company) in order for Gnosis (team/company) to develop Gnosis Protocol v2, is this correct?

I’ve read through the blog posts but still have to familiarize myself with the different entities and their relationships to one and other :slight_smile:

5 Likes

welcome @Luuk

Yeah, soonish that is meant to be the process - that companies including (but not exclusively) Gnosis Ltd. will build infrastructures and products for the GnosisDAO and the DAO gives them funding and/or (vested) tokens in return.

In the past, the main companies that build things around Gnosis have been: Gnosis Ltd (Gibraltar), Gnosis Service GmbH (Berlin) but also ConsenSys and https://protofire.io/

Since Gnosis Ltd. is already a big GNO holder (~100k GNO) + 500k vested over the next 5 years this company has an intrinsic motivation to build things around GNO. So this concrete proposal is not (yet) asking for funding - but is meant to get a signal from the DAO whether or not the DAO believes that this direction makes sense.

Likely there will be fullow-up proposals to e.g. use DAO GNO funds for a liquidity mining program on GP v.2 (Gnosis Protocol) or from other companies to develop specific products ontop of GP

8 Likes

Thanks for clarifying - also in favor of that process!

1 Like

Nice Ben, thank you for the write up, enjoyed reading it.

It looks like there are network effects at play in the sense that the more orders there are, the more orders can be matched off chain and avoid GAS costs as well as providing solvers with more orders so hopefully the economically viable order size reduces. I’d imagine there would need to be some form of marketing plan whereby initial orders are given a governance token to get enough orders that a user has a pretty reliable chance of paying less costs than a uniswap or DEX aggravated trade.

It would be awesome to see a forecast of costs for the end user under different conditions and comparing those to existing tools. This would be helpful in understanding the degree in which V2 is better for the end user as well how those benefits manifest when more people use the service.

I don’t quite follow the terminology of a tip, it sounds more like a fee? As in a tip, at least in most countries other than the USA, is an optional payment to reward expectational service. A fee is mandatory. It sounds like the tip will be a mandatory fee if the order falls below a certain threshold. Is it fair to say that if a user has to pay a tip, they would be better off using a DEX aggregator or uniswap?

2 Likes

No, definitively not. The tip should be equivalent to the gas costs a user would have on uniswap or an dex-aggregator. The only difference is that the gas costs are paid in ETH, while the tip is paid in the sold ERC20 token.

Overall, there are some reasons why the gas costs on this proposed platform are smaller than on dex-aggregators, though the saved gas will likely not be significant.

  • settling orders against each other is quite gas efficient
  • on uniswap users trade quite often on longer paths: e.g. UNI-> ETH-> USDC. On our platform, if opposite orders can be matched, these longer paths can be avoided.
1 Like

Is GPv2 a layer 1 only technology, or could it (with or without modification) take advantage of any liquidity sources operating on layer 2?

Some scenarios I have in mind:

  • Could GPv2 execute exchanges between users & liquidity sources that are all living on the same l2?
  • Could GPv2 execute a transaction that involves sending funds from l1 to an l2, exchanging on l2 and sending funds back to l1? This might be a dumb use case, because my understanding is that moving funds between l1 and l2 usually involves big delays
4 Likes

GPv2 should work on any layer 2 that is EVM compatible with all the liquidity sources native to that layer.

As for cross l2 liquidity this will likely only work natively if some party is willing to “abstract away” the cross chain delay and offer the prices it can find on a different side chain for mainnet or whatever chain GPv2 runs (as the settlement itself has to happen atomically in one tx).

We might be able to design more complex “smart contract orders” for the system, where the sell tokens are locked for a certain amount of time and proceeds can only be claimed after some time (enough for a MM to move funds from another l2 while potentially posting a bond for fulfillment).

4 Likes

Should Gnosis Build Gnosis Protocol v2?

It is not a question, it is a goal!
After DutchX and GP V1 experiences Gnosis should moving forward. Gas less trading, smartphone integrations, predictions markets outcomes tokens trading, FOMO marketing and we will success!

8 Likes

Great to hear your support @ykplayer8. The mobile friendly aspect that was brought up yesterday was a nice new insight that is surely a great perk of these gasless interactions that just happens to be an awesome consequence of design.

3 Likes

The team did a first demo on the working of V2 on xDai. Wohooo, the screencast is available here.

5 Likes

I don’t see where the link is to get to the place where the voting takes place.

Also, it’d be super helpful if the first post, or somewhere, would explicitly state the timeframe for this vote. For all I know, I may be looking at this forum many days after the active opportunity to vote has ended.

Hi,

great to hear that you are eager to vote.
Currently the proposal is in phase 1, which is only a “discussion/evaluation” phase. But since we got quite some good feedback already from many players, we will soon push this proposal to phase 2 of the governance process. Then you can vote !

2 Likes

Thanks. Makes sense.

That information, explicit in the first post, would be awesome. Perhaps even as an update to the first post: "UPDATE: As of 1 Jan 2021, the status of blah is “Phase 1”, Discussion only. There has been good feedback from many persons however and we will [clarify soon] push the proposal to phase 2 of the governance process, likely before [timeframe estimate goes here].

~Gourdot

3 Likes

@bh2smith exciting proposal for gnosis!

There are some concepts here like ‘matching orders’ that seem like traditional dark pools. Is that a fair comparison? Of course, dark pools are fraught with controversy (i.e. Flash Boys), but also offer price advantages that you mention (settling outside of the exchange). Could the solver ever be a malicious actor in this protocol?

Also, what is the minimum trade threshold for the tip? Is that dynamic based on gas fees?

Beyond my questions, I really like the idea of paying a fee in the coin I’m swapping rather than ETH. Especially with gas prices and ETH prices where they now! That would be a huge improvement to Uniswap/1inch and definitely worth focusing on IMO. Could that be done as a v2 and the solver be v2.5 or v3? Or are they dependent on each other?

1 Like

Good information thanks for sharing
vmware

1 Like

@jcal - Very glad to hear you are excited and thanks for the great questions. I will make an attempt at answering them all as thoroughly as possible;

I am not sure how this reminds you of a dark pool as there is no privacy layer, however I can only imagine that the fact that the orders are placed off-chain means there is a lack of data availability. In this case, of course, in the long run we would strive to achieve a decentralized infrastructure for ensuring availability and accessibility for off-chain data.

In theory, the solvers could take a collection of orders and execute arbitrary code with the available liquidity as long as those limit orders are respected. This means that solvers could “act in their own interest” but in doing so, would often be outperformed by other competing solvers. It is the plan to have a staking mechanism for becoming a solver and DAO governance model that would punish solvers who are not acting appropriately.

Essentially yes, the tip corresponds to the gas needed to facilitate the order (i.e. what the solver will have to pay in gas to match their trade). However, we can imagine a model where the tip required is substantially reduced or even zero for large volume orders.

I believe it is entirely possible and planned in this version (v2) to have this feature. Note that the solvers will be expected to convert these fees into GNO, but this can all be done in the same transaction as the order matching!

1 Like

Hey @0x55, thanks for you suggestion. Please find your suggestion at the top of the original post!

Thx! Seems a wise way to help the noobs.