Our team has been heads down building the smart contracts, a first swap interface and solver infrastructure for Gnosis Protocol v2 (GPv2) in the last couple of months.
As we are getting closer to a beta launch, we’d like to share with you some of the compromises we made for our initial version in terms of decentralization and how we are going to address them going forward as we find adoption and validate the general product idea.
First off, let’s start with some of the hard guarantees the smart contract logic is making:
- Funds can only be transferred if a trader has approved GPv2 and signed an order to sell the given token for another
- Limit prices and amounts of the order are satisfied
- Orders have an expiry date, can be cancelled on chain, and not be replayed
- Only “authenticated” solvers can submit settlements
The last point seems like a large centralization factor. The challenge we face is that solvers have the possibility to extract value from the protocol to some extent:
While the limit price of a user order is guaranteed by the smart contract, one of the core values of GPv2 is to create a “trader surplus” (achieve a better price than the limit price asked for) and have that surplus be captured by the user rather than the miner or solver.
It is impossible for the smart contract to know the maximum achievable surplus (as it doesn’t know about all possible on & off-chain liquidity). A simple exploit would therefore be to always match orders at their limit price (which usually includes a slippage tolerance on top of the current spot price) rather than giving them the best available liquidity (similar to how front-runners extract value from Uniswap).
To prevent this from happening the protocol needs some form of control over who can submit solutions.
Initially, the smart contract curates a list of trusted solvers (e.g. an account running the solver implementation in gp-v2-services).
In a first step towards decentralization (phase 0) the control over this list would be given to the Gnosis DAO. People that want to implement solver strategies in this phase are invited to submit PRs to our repository to include their logic.
We understand that solvers might not want to open source their logic for finding solutions. In phase 1 we will allow competition between different independent solver accounts that communicate via some central channel. Each solver would announce the “objective value” (what should be optimised for is a separate topic) they have computed for the current auction and agree on who obtains the right to settle this auction. In order to compute the objective value there needs to be consensus on what the state of the auction is (all valid orders for which surplus should be achieved). This is done via a central off-chain orderbook API (more on how to decentralize this part below). We should maybe mention here that for an order to be considered valid by the Orderbook API it needs to pay a “sufficient fee” (to be discussed in a separate topic) to the protocol.
In this phase the DAO would still pay close attention to who becomes an authenticated solver and should be held accountable for any damage to traders that is caused by a malicious solver. Furthermore we expect the DAO to payout rewards (transaction costs + a % taken from accrued fees) to solvers based on their contribution.
While the core GPv2 settlement contract is not upgradable, the logic of how solvers are authenticated is upgradeable. In phase 2, we envision the DAO to put in place a permissionless model, where anyone can become an authenticated solver as long as they stake a sizable amount of GNO. For this phase, the DAO would agree on a set of rules (e.g. under what circumstances batches are allowed to be split into multiple ones, which set of on-chain liquidity has to be at least considered for a solution, etc).
Upon violation the DAO can vote to slash a solver’s stake. The set of rules could be coded into a “verifier client” that members of the DAO run in order to indicate when a slashing vote should be casted.
The second, arguably less crucial, piece of infrastructure that is centralized in the current version is the off-chain orderbook API (also part of gp-v2-services). In order to judge over malicious behavior by a solver, participants need to agree on the state of the auction at the time of solution finding (e.g. the set of valid orders at this point in time). Furthermore, the entity hosting the API could theoretically censor traders or fool solvers into seeing an inconsistent state.
In phase 3 we hope the centrally hosted orderbook changes to a distributed p2p client network. Consensus could be reached:
- by a native client implementation,
- by making GP a first party citizen in Ethereum nodes (e.g. OpenEthereum) or
- by piggy-backing on a cheap side chain or test network (e.g. xDAI) for data availability
I hope this gives a good overview of our thought process with regards to how to decentralize GPv2 going forward. Permissionless innovation is one of the core values at Gnosis, which we don’t compromise on lightheartedly. However, from GPv1 we learned that building a completely permissionless protocol from the ground up takes a lot of effort which does not pay off if the product itself doesn’t find market fit.
With GPv2 we therefore prioritize market validation while at the same time giving a path forward on how decentralization can be achieved eventually.
Looking forward to questions, thoughts and concerns…