diff --git a/docs/cow-protocol/reference/core/auctions/bonding_pools.md b/docs/cow-protocol/reference/core/auctions/bonding_pools.md index c2404590..0b1bcf0b 100644 --- a/docs/cow-protocol/reference/core/auctions/bonding_pools.md +++ b/docs/cow-protocol/reference/core/auctions/bonding_pools.md @@ -5,12 +5,12 @@ id: bonding-pools # Setting up a bonding pool The first step for setting up a bonding pool is to deploy a Gnosis safe on Mainnet with only [the CoW DAO safe](https://etherscan.io/address/0xcA771eda0c70aA7d053aB1B25004559B918FE662) as a signer, as is described in [CIP-7](https://snapshot.box/#/s:cow.eth/proposal/0x267edf7a0bd3c771cfca763322f011ee106d8d5158612c11da29183260d1dba7). -Once this safe has been confirmed by the CoW DAO team, the safe should be funded with $500,000 USD in (yield bearing) stable coins and 1,500,000 COW tokens. After this is done, the bonding pool can be used to vouch for solvers in the solver competition. +Once this safe has been confirmed by the CoW DAO team, the safe should be funded with \$500,000 USD in (yield bearing) stable coins and 1,500,000 COW tokens. After this is done, the bonding pool can be used to vouch for solvers in the solver competition. # Setting up a reduced bonding pool Solvers that are currently vouched under the CoW DAO Bonding pool may decide to set up a reduced bonding pool according to [CIP-44](https://snapshot.box/#/s:cow.eth/proposal/0x1b6f1171633ec3d20c4370db37074aa1bd830486d4d0d6c26165915cc42d9412), where the main benefit is that then they can fully control their calldata and the onchain submission process. Note that the interested solver team first needs to coordinate with the core team, that is currently managing the CoW DAO bonding pool, and the core team maintains the right to reject such a reduced pool setup. -Assuming that the core team does approve the creation of a reduced bonding pool, the first step for setting up a reduced bonding pool is to deploy a Gnosis safe on Mainnet that has only one signer (the CoW DAO Solver Payouts safe, that is, eth:0xA03be496e67Ec29bC62F01a428683D7F9c204930). After this is done and has been confirmed by the CoW DAO team, the solver needs to deposit $50,000 in (yield bearing) stable coins or ETH, and 500,000 COW tokens to the newly created safe, and gradually build the pool's size all the way to $100,000 in (yield bearing) stable coins or ETH, and 1,000,000 COW tokens. +Assuming that the core team approves the creation of a reduced bonding pool, the first step for setting up a reduced bonding pool is to deploy a Gnosis safe on Mainnet that has only one signer (the CoW DAO Solver Payouts safe, that is, eth:0xA03be496e67Ec29bC62F01a428683D7F9c204930). After this is done and has been confirmed by the CoW DAO team, the solver needs to deposit \$50,000 in (yield bearing) stable coins or ETH, and 500,000 COW tokens to the newly created safe, and gradually build the pool's size all the way to \$100,000 in (yield bearing) stable coins or ETH, and 1,000,000 COW tokens. We stress that the reduced bonding pool setup is just an arrangement within the CoW DAO bonding pool; meaning that the solver with a reduced bonding pool is still formally vouched under the CoW DAO bonding pool. diff --git a/docs/cow-protocol/reference/core/auctions/competition_rules.md b/docs/cow-protocol/reference/core/auctions/competition_rules.md index a51fd57b..b62d9cd3 100644 --- a/docs/cow-protocol/reference/core/auctions/competition_rules.md +++ b/docs/cow-protocol/reference/core/auctions/competition_rules.md @@ -22,11 +22,26 @@ All solvers participating in the solver competition must abide by certain rules. - A solution is valid only if it contains at least one user order. -- Every solution is associated with a score, and the solutions are ranked in decreasing order of their scores. The solver whose solution has the highest positive score is declared the winner of the batch auction, and gets the right to execute its solution on-chain. Moreover, specifically for Ethereum Mainnet, the solver that provided the winning solution is also rewarded according to the rules specified in [CIP-20](https://snapshot.org/#/cow.eth/proposal/0x2d3f9bd1ea72dca84b03e97dda3efc1f4a42a772c54bd2037e8b62e7d09a491f). On the other hand, on Gnosis Chain solvers are not rewarded, and thus the score associated with a solution is simply equal to the quantity "surplus + fees - costs". +- Every valid solution is associated with a score relative to the amount of surplus it generates for the users (as described in [CIP-38](https://snapshot.box/#/s:cow.eth/proposal/0xfb81daea9be89f4f1c251d53fd9d1481129b97c6f38caaddc42af7f3ce5a52ec). These solutions are ranked in decreasing order of their scores. The solver whose solution has the highest positive score is declared the winner of the batch auction, winning the right to execute its solution on-chain. -- Internalization of interactions (rule applies only on Ethereum Mainnet): a solver is allowed to "internalize" interactions whose buy token (i.e., the token that the AMM buys) is classified as a "trusted" token by the protocol. Concretely, if there is enough balance of the sell token of such an interaction in the settlement contract, then a solver can signal an internalization of such an interaction, which effectively means that the protocol is willing to buy and sell tokens stored in the settlement contract. The effect of such interactions is evaluated in what we call slippage accounting (see next point). +- Deadline: Solvers that win an auction will receive a deadline by which they must settle the auction on-chain. If the transaction is not observed on chain before the deadline block is mined, then the solution will count as not submitted and the solver will be penalized. -- Slippage accounting: With the exception of protocol, partner and network fees paid by users, any token imbalance within the settlement contract that is the result of a settlement is accounted for under the term "slippage accounting", and is fully owned by the corresponding solver, as specified in [CIP-17](https://snapshot.org/#/cow.eth/proposal/0xf9c98a2710dc72c906bbeab9b8fe169c1ed2e9af6a67776cc29b8b4eb44d0fb2). More information on the full accounting process, including slippage, can be found [here]((/cow-protocol/reference/core/auctions/accounting). +- The solver that provided the winning solution is rewarded according to a second-price auction mechanism that the protocol uses; for more information see [here](/cow-protocol/reference/core/auctions/rewards). + +- Internalization of interactions: a solver is allowed to "internalize" interactions. Concretely, if there is enough balance of the sell token of such an interaction in the settlement contract, then a solver can signal an internalization of such an interaction, which effectively means that the protocol is willing to buy and sell tokens stored in the settlement contract. The effect of such interactions is evaluated in what we call slippage accounting (see next point). + +- Slippage accounting: With the exception of protocol, partner and network fees paid by users, any token imbalance within the settlement contract that is the result of a settlement is accounted for under the term "slippage accounting", and is fully owned by the corresponding solver, as specified in [CIP-17](https://snapshot.org/#/cow.eth/proposal/0xf9c98a2710dc72c906bbeab9b8fe169c1ed2e9af6a67776cc29b8b4eb44d0fb2). More information on the full accounting process, including slippage, can be found [here](/cow-protocol/reference/core/auctions/accounting). + +:::note + +The deadline for solutions depends on the network and is set as a specific number of blocks after the current block at the time of sending the settle request to the solver: + +- Mainnet: 3 blocks +- Arbitrum: 40 blocks +- Gnosis chain: 5 blocks +- Base: 20 blocks + +::: ## Governance @@ -50,7 +65,7 @@ At CoW DAO's discretion, systematic violation of these rules may lead to penaliz
Ethereum mainnet baseline protocols and tokens - - **Protocols**: Uniswap v2/v3, Sushiswap, Swapr, Balancer v2 + - **Protocols**: Uniswap v2/v3, Sushiswap, Swapr, Balancer v2, Pancakeswap - **Base tokens**: [`WETH`](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2), [`DAI`](https://etherscan.io/token/0x6B175474E89094C44Da98b954EedeAC495271d0F), [`USDC`](https://etherscan.io/token/0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48), [`USDT`](https://etherscan.io/token/0xdAC17F958D2ee523a2206206994597C13D831ec7), [`COMP`](https://etherscan.io/token/0xc00e94Cb662C3520282E6f5717214004A7f26888), [`MKR`](https://etherscan.io/token/0x9f8F72aA9304c8B593d555F12eF6589cC3A579A2), [`WBTC`](https://etherscan.io/token/0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599), [`GNO`](https://etherscan.io/token/0x6810e776880C02933D47DB1b9fc05908e5386b96)
@@ -58,16 +73,23 @@ At CoW DAO's discretion, systematic violation of these rules may lead to penaliz Gnosis Chain baseline protocols and tokens - **Protocols**: Honeyswap, Sushiswap, Baoswap, Swapr, Balancer v2 - - **Base tokens**: [`WXDAI`](https://gnosisscan.io/token/0xe91D153E0b41518A2Ce8Dd3D7944Fa863463a97d), [`HNY`](https://gnosisscan.io/token/0x71850b7e9ee3f13ab46d67167341e4bdc905eef9), [`USDT`](https://gnosisscan.io/token/0x4ECaBa5870353805a9F068101A40E0f32ed605C6), [`USDC`](https://gnosisscan.io/token/0xDDAfbb505ad214D7b80b1f830fcCc89B60fb7A83), [`sUSD`](https://gnosisscan.io/token/0xB1950Fb2C9C0CbC8553578c67dB52Aa110A93393), [`WBTC`](https://gnosisscan.io/token/0x8e5bbbb09ed1ebde8674cda39a0c169401db4252), [`GNO`](https://gnosisscan.io/token/0x9C58BAcC331c9aa871AFD802DB6379a98e80CEdb), [`STAKE`](https://gnosisscan.io/token/0xb7D311E2Eb55F2f68a9440da38e7989210b9A05e), [`xOWL`](https://gnosisscan.io/token/0x0905Ab807F8FD040255F0cF8fa14756c1D824931), [`WETH`](https://gnosisscan.io/token/0x6A023CCd1ff6F2045C3309768eAd9E68F978f6e1) + - **Base tokens**: [`WXDAI`](https://gnosisscan.io/token/0xe91D153E0b41518A2Ce8Dd3D7944Fa863463a97d), [`HNY`](https://gnosisscan.io/token/0x71850b7e9ee3f13ab46d67167341e4bdc905eef9), [`USDT`](https://gnosisscan.io/token/0x4ECaBa5870353805a9F068101A40E0f32ed605C6), [`USDC`](https://gnosisscan.io/token/0xDDAfbb505ad214D7b80b1f830fcCc89B60fb7A83), [`sUSD`](https://gnosisscan.io/token/0xB1950Fb2C9C0CbC8553578c67dB52Aa110A93393), [`WBTC`](https://gnosisscan.io/token/0x8e5bbbb09ed1ebde8674cda39a0c169401db4252), [`GNO`](https://gnosisscan.io/token/0x9C58BAcC331c9aa871AFD802DB6379a98e80CEdb), [`STAKE`](https://gnosisscan.io/token/0xb7D311E2Eb55F2f68a9440da38e7989210b9A05e), [`xOWL`](https://gnosisscan.io/token/0x0905Ab807F8FD040255F0cF8fa14756c1D824931), [`WETH`](https://gnosisscan.io/token/0x6A023CCd1ff6F2045C3309768eAd9E68F978f6e1), [`wstETH`](https://gnosisscan.io/address/0x6c76971f98945ae98dd7d4dfca8711ebea946ea6), [`sDAI`](https://gnosisscan.io/address/0xaf204776c7245bf4147c2612bf6e5972ee483701), [`USDC.e`](https://gnosisscan.io/address/0x2a22f9c3b484c3629090FeED35F17Ff8F88f76F0)
Arbitrum baseline protocols and tokens - - **Protocols**: Uniswap v2/v3, Sushiswap, Swapr, Balancer v2 + - **Protocols**: Uniswap v2/v3, Sushiswap, Swapr, Balancer v2, Pancakeswap - **Base tokens**: [`WETH`](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1), [`USDC`](https://arbiscan.io/token/0xaf88d065e77c8cc2239327c5edb3a432268e5831), [`USDT`](https://arbiscan.io/token/0xfd086bc7cd5c481dcc9c85ebe478a1c0b69fcbb9), [`DAI`](https://arbiscan.io/token/0xda10009cbd5d07dd0cecc66161fc93d7c9000da1), [`GNO`](https://arbiscan.io/token/0xa0b862f60edef4452f25b4160f177db44deb6cf1)
+
+ Base chain baseline protocols and tokens + + - **Protocols**: Uniswap v2/v3, Balancer v2 + - **Base tokens**: [`WETH`](https://basescan.org/address/0x420000000000000000000000000000000000000), [`USDC`](https://basescan.org/address/0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913), [`DAI`](https://basescan.org/address/0x50c5725949A6F0c72E6C4a641F24049A917DB0Cb) +
+ More details about how a certificate of an EBBO violation is computed, and what are the steps taken in case such a violation occurs can be found in [this](/cow-protocol/reference/core/auctions/ebbo-rules) section. - Inflation of the objective function ([CIP-11](https://snapshot.org/#/cow.eth/proposal/0x16d8c681d52b24f1ccd854084e07a99fce6a7af1e25fd21ddae6534b411df870)). Using tokens for the sole purpose of inflating the objective value or maximizing the reward is forbidden (e.g., by creating fake tokens, or wash-trading with real tokens). @@ -76,6 +98,6 @@ More details about how a certificate of an EBBO violation is computed, and what - Local Token Conservation, aka illegal surplus shifts ([CIP-11](https://snapshot.org/#/cow.eth/proposal/0x16d8c681d52b24f1ccd854084e07a99fce6a7af1e25fd21ddae6534b411df870)). Due to the nature of batching, a solver can intentionally transfer surplus among orders that share a common token. This is not allowed, and non-trivial surplus shifts can be penalized and can lead to solver slashing. -- Pennying/overbidding ([CIP-13](https://snapshot.org/#/cow.eth/proposal/0x812273c78abe1cea303d8381e1fb901a4cb701715fd24f4b769d0a0b3779b3e2)) (rule applies only on Ethereum Mainnet). Pennying or the evolution of it in the context of CIP-20 known as overbidding, is the intentional inflation of the surplus, or the reported score, by a solver, with the hope that their solution will win and that solver rewards, and/or the possibility of positive slippage, will cover the loss that they seem to be committing to. Such behavior does not benefit anyone and thus, systematically doing so can lead to solver slashing. +- Pennying/overbidding ([CIP-13](https://snapshot.org/#/cow.eth/proposal/0x812273c78abe1cea303d8381e1fb901a4cb701715fd24f4b769d0a0b3779b3e2)). Pennying or the evolution of it in the context of CIP-20 known as overbidding, is the intentional inflation of the surplus, or the reported score, by a solver, with the hope that their solution will win and that solver rewards, and/or the possibility of positive slippage, will cover the loss that they seem to be committing to. Such behavior does not benefit anyone and thus, systematically doing so can lead to solver slashing. - Other malicious behavior ([CIP-11](https://snapshot.org/#/cow.eth/proposal/0x16d8c681d52b24f1ccd854084e07a99fce6a7af1e25fd21ddae6534b411df870)). Malicious solver behavior is not limited to the above examples. Slashing can still happen for other reasons where there is intentional harm caused to the user and/or the protocol at the discretion of the CoW DAO. A concrete example of such is a solver intentionally not including the [pre/post hooks](/cow-protocol/reference/core/intents/hooks) associated with an order. diff --git a/docs/cow-protocol/reference/core/auctions/rewards.md b/docs/cow-protocol/reference/core/auctions/rewards.md index 9d8132c3..79b371ba 100644 --- a/docs/cow-protocol/reference/core/auctions/rewards.md +++ b/docs/cow-protocol/reference/core/auctions/rewards.md @@ -38,7 +38,7 @@ The payment calculation can result in a negative figure, in which case the solve The payment is capped from above and below using the function $$\textrm{cap}(x) = \max(-c_l, \min(c_u, x))$$ that is chain-specific, and is determined by the following values: -- Ethereum mainnet and Arbitrum: $$c_l = 0.010 \;\textrm{ETH}$$ and $$c_u = 0.012 \;\textrm{ETH}$$, +- Ethereum mainnet, Arbitrum, and Base chain: $$c_l = 0.010 \;\textrm{ETH}$$ and $$c_u = 0.012 \;\textrm{ETH}$$, - Gnosis Chain: $$c_l = c_u = 10 \;\textrm{xDAI}$$. Submitted scores that are non-positive will be ignored. If only one solution is submitted, $$\textrm{referenceQuality}$$ is set to zero. Formally, this corresponds to always considering the empty solution which does not settle any trades and has quality zero as part of the submitted solutions. @@ -84,5 +84,6 @@ As specified in [CIP-27](https://snapshot.org/#/cow.eth/proposal/0x64e061568e86e - Ethereum mainnet: $$\min\{0.0006 ~\textrm{ETH}, 6 ~\textrm{COW}\}$$, - Arbitrum: $$\min\{0.0002 ~\textrm{ETH}, 6 ~\textrm{COW}\}$$, - Gnosis Chain: $$\min\{0.15 ~\textrm{xDAI}, 6 ~\textrm{COW}\}$$, +- Base Chain: $$\min\{0.0002 ~\textrm{ETH}, 6 ~\textrm{COW}\}$$, where, again, the conversion from ETH and xDAI to COW is done by using an up-to-date price (specifically, the average ETH/xDAI/COW Dune prices of the past 24h before the payout are used to determine these exchange rates). diff --git a/docs/cow-protocol/reference/core/auctions/schema.md b/docs/cow-protocol/reference/core/auctions/schema.md index f168d90c..3e670c9d 100644 --- a/docs/cow-protocol/reference/core/auctions/schema.md +++ b/docs/cow-protocol/reference/core/auctions/schema.md @@ -18,13 +18,12 @@ To avoid precision loss, some numerical literals are encoded as strings, referre ## Instances (input) -The instance json that solver engines currently receive contains six keys: +The instance json that solver engines currently receive contains five keys: - `id` - `tokens` - `orders` -- `liquidity` -- `effectiveGasPrice` - `deadline` +- `surplusCapturingJitOrderOwners` We now explain what each of these entries contains. @@ -79,12 +78,25 @@ This key maps to a list containing the set of orders in the batch. Each entry in - `buyToken`: a string denoting the address of the buy token. - `sellAmount`: a stringified integer denoting the limit amount that is being sold, measured in terms of the smallest denomination of the sell token. - `buyAmount`: a stringified integer denoting the limit amount that is being bought. Similar to the `sellAmount`, it is measured in terms of the smallest denomination of the buy token. -- `feeAmount`: a stringified integer denoting the signed fee attached to the order, which is always denominated in the `sellToken`. +- `created`: creation time of the order, denominated in epoch seconds. +- `validTo`: integer indicating the time until which the order is valid. - `kind`: a string of the set {"sell", "buy"}, describing whether the order is a `sell` or `buy` order. +- `receiver`: the address that should receive the bought tokens. +- `owner`: the address that created the order. - `partiallyFillable`: a boolean indicating whether the order may be partially matched (_true_), or if it is Fill-or-Kill order (_false_). -- `class`: a string of the set {"market", "limit", "liquidity"}, indicating the order class. - - We clarify here that all `market` and `liquidity` orders have a potentially non-zero predetermined fee, while all `limit` orders have necessarily a zero signed fee, and the actual fee charged to the order is computed and provided by the solvers when they propose an execution of such an order. More details are provided in the [solutions section](#solutions-output). +- `executed`: the token amount that has already been filled. +- `preInteractions: an array of interactions that must be executed before the order can be filled. +- `postInteractions: an array of interactions that must be executed after the order has been filled. +- `sellTokenBalance`: a string of the set {"erc20", "internal", "external"} +- `buyTokenBalance`: a string of the set {"erc20", "internal"} +- `class`: a string of the set {"market", "limit"}, indicating the order class. +- `appData`: 32 bytes encoded as hex with `0x` prefix. +- `signingScheme`: a string of the set {"eip712", "ethsign", "presign", "eip1271"}. +- `signature`: hex encoded bytes with `0x` prefix. +- `protocolFees`: array of any protocol fee policies that apply to the order. +- `quote`: the winning quote for that order. + + We clarify here that all `market` orders have a potentially non-zero predetermined fee, while all `limit` orders have necessarily a zero signed fee, and the actual fee charged to the order is computed and provided by the solvers when they propose an execution of such an order. More details are provided in the [solutions section](#solutions-output). An example Fill-or-Kill user limit buy order that sells 1000 [COW](https://etherscan.io/token/0xdef1ca1fb7fbcdc777520aa7f396b4e015f497ab) for at least 284.138335 USDC [USDC](https://etherscan.io/token/0xba100000625a3754423978a60c9317c58a424e3d) is given below: @@ -105,22 +117,6 @@ An example Fill-or-Kill user limit buy order that sells 1000 [COW](https://ether The above entry should be interpreted as follows. It is a Fill-or-Kill order since the flag `partiallyFillable` is set to `false`. Moreover, it is a sell order since its `kind` is set to `sell`. Finally, this is a `limit` order, meaning that it has a zero-signed fee, which implies that the solver is free to choose an appropriate fee to cover its execution cost. This means that, if executed, the user will send a total of 1000000000000000000000 COW atoms to the settlement contract and, no matter how much fee the solver will charge, the user is guaranteed to receive at least 284138335 USDC atoms. -### `liquidity` - -This key is a list of all the publicly available AMMs/limit orders that are made available for use by the default implementation of the Driver, available to the solver engines that request such liquidity. Internally, this is also known as _baseline_ liquidity. Each entry describes the current state of an AMM or an existing public limit order. Currently, there are 5 different types of liquidity provided by the Driver: - -- constant product pools, i.e., Uniswap v2 type pools on 2 tokens. -- weighted Product pools, i.e., Balancer type weighted product pools on N tokens. -- stable pools, i.e., Curve type stable pools on N tokens. -- concentrated liquidity pools, i.e., Uniswap v3 type concentrated liquidity pools on 2 tokens. -- foreign limit orders, i.e., external 0x type limit orders on 2 tokens. - -More information about the exact descriptions of these pools can be found [here](https://docs.cow.fi/cow-protocol/reference/apis/solver). - -### `effectiveGasPrice` - -This key is a single entry that is a stringified integer describing an estimate of the effective gas price for the winning solution, denominated in wei. - ### `deadline` This key is a single entry that is a string corresponding to a time stamp. This timestamp specifies the deadline by which a solution to the auction is required. Responses that go beyond this deadline are considered invalid. @@ -204,6 +200,6 @@ The score is a key that describes the "bid" a solver makes for the batch in the If we have `"kind": "solver"`, then there is a second entry, labeled `score`, that corresponds to a stringified float that specifies the score attached to the solution. On the other hand, if we have `"kind": "riskAdjusted"`, then there is a second entry, labeled `successProbability`, that is a stringified float that specifies the success probability of the proposed solution. -:::note -All solvers are encouraged to submit a score via `"kind": "riskAdjusted"` and `successProbability`, as it has been observed to be more accurate and fully protects solvers from overbidding (which is prohibited by social consensus rules; see [here](/cow-protocol/reference/core/auctions/competition-rules#governance) for more information). -::: +### `surplusCapturingJitOrderOwners` + +A list of all addresses that are allowed to capture surplus through JIT orders. At the moment, these are all Balancer CoW AMM's. diff --git a/docs/cow-protocol/reference/core/auctions/the_problem.md b/docs/cow-protocol/reference/core/auctions/the_problem.md index 16f84b3f..3d66cb2d 100644 --- a/docs/cow-protocol/reference/core/auctions/the_problem.md +++ b/docs/cow-protocol/reference/core/auctions/the_problem.md @@ -35,7 +35,7 @@ In both cases, the surplus function is defined as $$U(x,-y)=(x-y / \pi)p(b)$$, -where $$(x-y / \pi)$$ is the additional amount of buy tokens received by the user relative to the case in which they trade at the limit price, and $$p(b)$$ is the price of the buy token relative to a numéraire (in our case ETH) and is externally provided (i.e., by an oracle). The function $$U(x,-y)$$ is therefore expressed in units of the numéraire and is always non-negative. +where $$(x-y / \pi)$$ is the additional amount of buy tokens received by the user relative to the case in which they trade at the limit price, and $$p(b)$$ is the price of the buy token relative to a numéraire (in our case ETH) and is externally provided (i.e., by solvers). The function $$U(x,-y)$$ is therefore expressed in units of the numéraire and is always non-negative. A final observation is that orders can be valid over multiple batches. For a fill-or-kill, this means that an order that is not filled remains valid for a certain period (specified by the user). For a partially-fillable order, this also means that only a fraction of it may be executed in any given batch. @@ -53,7 +53,7 @@ Again, the surplus function is defined as $$U(\{x,-y\})=(x \cdot \pi-y)p(s)$$, -where $$p(s)$$ is the price of the sell token relative to a numéraire and is externally provided. Also here, orders can be executed over multiple batches. +where $$p(s)$$ is the price of the sell token relative to a numéraire. Also here, orders can be executed over multiple batches. ## Protocol Fees @@ -85,6 +85,6 @@ From the protocol viewpoint, each solution that satisfies the above constraints $$\sum_o U(o)+p\cdot \sum_of(o)$$, -where _p_ is a vector of externally-determined prices used to express all fees in terms of the common numéraire. +where _p_ is a vector of prices used to express all fees in terms of the common numéraire. -Finally, solvers compete for the right to settle a batch by participating in an auction, aiming to implement the solution with the highest quality at the lowest possible cost to the protocol. The [solver that wins the auction is rewarded](rewards) by the protocol. +Finally, solvers compete for the right to settle a batch by participating in an auction, aiming to implement the solution that generates the most amount of surplus for the user(s). The [solver that wins the auction is rewarded](rewards) by the protocol.