# Spec of solution-judge and solution submission

## About

This specification describes a system for multi-**semi-trusted** solver setup for the Gnosis Protocol. This specification is quite simple, still requires some trust from the solvers, and allows us to learn more about the solver competition before we commence to the more decentralized staker-only solution.

There are 3 main objectives for introducing this solution-judge:
One is to build a platform for other solvers in order to have a more scalabe platform. Secondly, to easily onboard new liquidity sources and ensurring that orders are matched with the best available on-chain liquidity. And lastly, to decentralize the price finding mechanism and to ensure its fairness via a fair competition.

The solution-judge is a server-instance that receives different solutions for settling order within the Gnosis Protocol. Solutions are found by different solver instances and send to the judge via an API. Each solution of a solver will be investigated for certain acceptance criteria by the solution-judge and ranked with an objective criteria. Best solutions will be submitted on-chain to the Gnosis-Protocol.

## Actors

- **Orderbook-host**: This actor will store and serve all user orders received via an API. This host will also perform the critical part of categorizing orders into market or non-market orders. Market orders are orders that are settable against the AMM immediately and have sufficient fees for covering gas costs.
- **Solution-judge**: The solver-judge will be a centralized server, elected by the GP-DAO, that will host an endpoint for judging settlement proposals. It will judge these solutions on several criteria, such as whether they are settlable and well-formed. It will also save the solution and provide the currently best solution via an API to the solution submitter.
- **Solution-submitter**: This actor receives the currently best solution from the Solution-judge's API and will settle it within the ethereum network.
- **State-giving-node**: The state-giving-node is a selected ethereum node being used for judging the current state of the ethereum chain. This node will be used to check whether solutions are settable, whether approvals for trades are set, and so on.
- **Solvers**: Solvers will create settlements for each batch by finding solutions to an optimization problem.

## Solution-judging:

### Objective criteria:

This specification describes the objective criteria by which settlements for the gnosis protocol should be ranked and the best/final solution should be picked.

Solution Surplus + (collected fees from orders - settlement tx costs)[ETH]

This is the same as currently implemented.

### Solution acceptance criteria

1. **Settlable against 'state giving node'**
Solutions must be settable without the consumption of buffers unless the trades are explicit trades against buffers.
The reason is that buffers are only in the protocol to deal with variations of AMMs induced by txs out of the same block, but executed before the settlement tx.
2. **Profitable solution**: `Collected fees - gas costs > \kappa`:
If we set \kappa = 0, we ensure that the system is viable and earns money
4. **AMM envy-freeness**: Certain AMM's - initially only uniswap v2 - should not have offered a better price + gas cost for a user compared to any other interaction that settles against on-chain liquidity.
This ensures some basic guarantees about the price compared to the on-chain liquidity and provides some level of protection for market orders.
5. **Buffer Settlement Rule**: For solution settling within the buffers of the settlement contract, the price must be exactly the current uniswap v2 or curve price.
This is required to protect the buffers within the system.
5. **Well-formed Interactions**: All interactions must be wellformed and do not have malicious code that allows the solution creator to steal buffers. In particular, it is to be checked that: No approvals are set beside the necessary ones, no tokens are transferred out any new approvals, and only interacts on tokens part of the solution.

A reader might think that it would be also beneficial to require a solution having (quasi-)uniform clearing prices.
Though the objective criteria for the ranking solution will be chosen in such a way that the best solution should always have uniform clearing prices, assuming no losses are made on the settlement contract - ensured by 1).

## Solution submission:

### Batching algorithm - chugging or cow-mode

Solutions provided from the solution-judge will be submitted on-chain by the solution-submitter.
In order to prevent a jam of orders to be settled, there are two different modes in which the solution submitter will operate:
- **CoW mode**: Here the focus is to find cows and have fair competition between solvers
- **chugging mode**: This mode overtakes, in case there is too many tx in the backlog, and they need to be submitted quickly. It avoids complicated rules and just focues on settling quickly orders preventing congestions.

All orders will be market by the orderbook-host as either "market orders", which means they are immediately settlable according to the current AMM state and have a reasonable fee specified, or "non-market orders".

### Cow Mode
If there are not more than 50 market orders, the system focuses on finding cows.
Solvers are only allowed to settle specific orders:
- Close to expiry date orders (expiry orders): Orders that expire within MAX_DELAY_FOR_SETTLEMENT secs.
- Improvement orders: orders that contribute to the surplus of a current batch of expiry orders.
Of course, solvers can always add their private liquidity via private orders.
In the cow mode, the solution-submitter asks for the best solution of the solution-judge only every 30 secs.

### Chugging Mode
If there are more than 50 market orders, the system gets into a chugging mode in order to prevent order jams:
Solvers can pick up to 50 orders for finding their solution and the solution only needs to fullfill the criteria on this subset of solutions.
The solution submitter will ask for the best solution for all 10 seconds (or quicker if even more orders need to be settled) and then submit these to the ethereum chain.

## Spec considerations

### Questions:

- Legally, would this be sufficiently decentralized? -> Yes, as price determination is happening in the solver competition? Though the solution picking is happing centralized?
- Will this have any impact on canceling orders?

### Problems with the current spec:

- Highly depends on AMM prices and they can be manipulated with flash boats: A malicious actor could make a trade the end of the block to leave an AMM in a certain state and then trade it back immediately afterward in the next block. This might be used to manipulate prices and exploit the system’s buffers or orders. Hopefully, such a behaviour can be observed and countered by solvers.

### Problems in general:

- Envy freeness is the best concept for fair prices, though it’s hard to find envy-free solution. There is also no assurance that envy-free solutions exist in a system with kill and fill orders and limited order settlement capacity
- A little bit better solution can always be created from the work of others. Maybe we need to keep the solution private.
- Spamming of the orderbook can isolate orders no matter how the batching algorithm is designed
- AMM prices could be manipulated and can not effectively be used as price oracles.