Only use score and not quality as a term

docs/cow-protocol/reference/core/auctions/competition_rules.md

@@ -20,7 +20,7 @@ All solvers participating in the solver competition must abide by certain rules.
 
 - Uniform clearing prices (UCP): this rule is an integral component of the protocol, and specifies that there is one clearing price per token per batch.
 
-- A solution is valid only if it contains at least one user order.
+- A solution is valid only if it contains at least one user or CoW AMM order.
 
 - 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. 
 
@@ -92,12 +92,12 @@ At CoW DAO's discretion, systematic violation of these rules may lead to penaliz
 
 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).
+- Inflation of the score ([CIP-11](https://snapshot.org/#/cow.eth/proposal/0x16d8c681d52b24f1ccd854084e07a99fce6a7af1e25fd21ddae6534b411df870)). Using tokens for the sole purpose of inflating the score of a solution or maximizing the reward is forbidden (e.g., by creating fake tokens, or wash-trading with real tokens).
 
-- Illegal use of internal buffers ([CIP-11](https://snapshot.org/#/cow.eth/proposal/0x16d8c681d52b24f1ccd854084e07a99fce6a7af1e25fd21ddae6534b411df870)). The internal buffers may only be used to replace legitimate AMM interactions available to the general public for the purpose of saving transaction costs, and also to allow for the successful execution of settlements that occur some slippage. However, systematic and intentional buffer trading with tokens that are not safe, although will be accounted for as slippage, is discouraged as it poses a significant inventory risk to the protocol, and solvers that do so can be flagged and potentially slashed. In general, any attack vector to the internal buffers that is created by a solver can be considered a malicious and illegal behavior.
+- Illegal use of internal buffers ([CIP-11](https://snapshot.org/#/cow.eth/proposal/0x16d8c681d52b24f1ccd854084e07a99fce6a7af1e25fd21ddae6534b411df870)). The internal buffers may only be used to replace legitimate AMM interactions available to the general public for the purpose of saving transaction costs, and also to allow for the successful execution of settlements that incur some slippage. However, systematic and intentional buffer trading with tokens that are not safe, although will be accounted for as slippage, is discouraged as it poses a significant inventory risk to the protocol, and solvers that do so can be flagged and potentially slashed. In general, any attack vector to the internal buffers that is created by a solver can be considered a malicious and illegal behavior.
 
 - 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)). 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 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.

docs/cow-protocol/reference/core/auctions/rewards.md

@@ -14,7 +14,7 @@ For the interested reader, the main source of truth for the weekly payments to s
 
 ## Solver competition rewards (CIPs 20, 36, 38, 48, 57)
 
-Solver rewards are computed using a mechanism akin to a second-price auction. First, each solver commits a solution, which includes a price vector and a list of trades to execute. The solver proposing the solution with the highest quality wins the right to settle their submitted solution on chain, where quality is the sum of surplus delivered to users and fees paid to the protocol.
+Solver rewards are computed using a mechanism akin to a second-price auction. First, each solver commits a solution, which includes a price vector and a list of trades to execute. The solver proposing the solution with the highest score wins the right to settle their submitted solution on chain, where, as a reminder, score is the sum of surplus delivered to users and fees paid to the protocol.
 
 :::note
 
@@ -25,10 +25,10 @@ From the protocol's perspective, the solution executed on chain must equal the s
 The payment to the winning solver is
 
 $$
-\textrm{payment} = \textrm{cap}(\textrm{observedQuality} - \textrm{referenceQuality}).
+\textrm{payment} = \textrm{cap}(\textrm{observedScore} - \textrm{referenceScore}).
 $$
 
-Here, $$\textrm{referenceQuality}$$ refers to the quality of the second-best solution, and $$\textrm{observedQuality}$$ denotes the settlement's quality as observed on chain. More precisely, in case of a successful settlement, the $$\textrm{observedQuality}$$ is equal to the sum of the surplus generated for users and fees paid to the protocol, while in the case of a failed settlement (e.g. one that reverted), the $$\textrm{observedQuality}$$ is zero.
+Here, $$\textrm{referenceScore}$$ refers to the score of the second-best solution, and $$\textrm{observedScore}$$ denotes the settlement's score as observed on chain. More precisely, in case of a successful settlement, the $$\textrm{observedScore}$$ is equal to the sum of the surplus generated for users and fees paid to the protocol, while in the case of a failed settlement (e.g. one that reverted), the $$\textrm{observedScore}$$ is zero.
 
 :::note
 
@@ -41,11 +41,11 @@ The payment is capped from above and below using the function $$\textrm{cap}(x)
 - 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.
+Submitted scores that are non-positive will be ignored. If only one solution is submitted, $$\textrm{referenceScore}$$ is set to zero. Formally, this corresponds to always considering the empty solution which does not settle any trades and has a score equal to zero as part of the submitted solutions.
 
 :::note
 
-There is no guarantee that the per-auction rewards are greater than the gas costs of executing a transaction. Hence, solvers cover these costs by adjusting their reported quality. Of course, a solver who adjusts quality downward too aggressively is then at a disadvantage in the auction. The mechanism, therefore, incentivizes the accurate estimation of gas costs.
+There is no guarantee that the per-auction rewards are greater than the gas costs of executing a transaction. Hence, solvers cover these costs by adjusting their reported score. Of course, a solver who adjusts their score downward too aggressively is then at a disadvantage in the auction. The mechanism, therefore, incentivizes the accurate estimation of gas costs.
 
 :::
 
@@ -55,23 +55,23 @@ In addition to paying for gas, the winning solver might incur additional costs,
 
 ### Solver bidding strategies
 
-After finding optimal routes, solvers must decide what solution to report. Call $$\textrm{successQuality}$$ the quality of the reported solution, which the solver can freely choose as long as it is smaller than some theoretical maximum, which we call $$\textrm{maxQuality}$$, with $$\textrm{maxQuality} - \textrm{successQuality} $$ constituting revenues to the solver.
+After finding optimal routes, solvers must decide what solution to report. Call $$\textrm{successScore}$$ the score of the reported solution, which the solver can freely choose as long as it is smaller than some theoretical maximum, which we call $$\textrm{Score}$$, with $$\textrm{maxScore} - \textrm{successScore} $$ constituting revenues to the solver.
 
-Suppose $$c_u$$ is large and can be ignored. In this case, the winning solver's expected payoff is
+Suppose $$c_u$$ is large and can be ignored. Let $$p$$ be the (estimated) probability of successfully landing a solution on chain and within the deadline. In this case, the winning solver's expected payoff is
 
 $$
-p  (\textrm{maxQuality} - \textrm{referenceQuality} - \textrm{successCost}) - (1 - p)  (\min(c_l,\textrm{referenceQuality}) + \textrm{failCost}).
+p  (\textrm{maxScore} - \textrm{referenceScore} - \textrm{successCost}) - (1 - p)  (\min(c_l,\textrm{referenceScore}) + \textrm{failCost}).
 $$
 
-The key observation is that $$\textrm{successQuality}$$ doesn't affect the expected payoff in case of a win, and it only affects whether the solver wins. In particular, note that the above expression is strictly decreasing in $$\textrm{referenceQuality}$$. Hence, by choosing $$\textrm{successQuality}$$ such that
+The key observation is that $$\textrm{successScore}$$ doesn't affect the expected payoff in case of a win, and it only affects whether the solver wins. In particular, note that the above expression is strictly decreasing in $$\textrm{referenceScore}$$. Hence, by choosing $$\textrm{successScore}$$ such that
 
 $$
-p \cdot (\textrm{maxQuality} - \textrm{successQuality}- \textrm{successCost}) - (1 - p) \cdot (\min(c_l,\textrm{successQuality}) + \textrm{failCost})=0
+p \cdot (\textrm{maxScore} - \textrm{successScore}- \textrm{successCost}) - (1 - p) \cdot (\min(c_l,\textrm{successScore}) + \textrm{failCost}) = 0
 $$
 
-a solver wins if and only if $$\textrm{referenceQuality}$$ is such that the solver's expected profit from winning is strictly positive. Note that the above equation either has no solution (in which case a solver shouldn't participate in the auction) or it has a unique solution. Such a solution is simple to compute and, in a second-price logic, does not depend on the behavior of other solvers.
+a solver wins if and only if $$\textrm{referenceScore}$$ is such that the solver's expected profit from winning is strictly positive. Note that the above equation either has no solution (in which case a solver shouldn't participate in the auction) or it has a unique solution. Such a solution is simple to compute and, in a second-price logic, does not depend on the behavior of other solvers.
 
-The presence of the cap on rewards $$c_u$$, however, makes the problem more complex as it introduces a "first-price auction" logic: if the difference between the best and second-best solution is very large, then the winning solver wins more when it underreports its quality. However, determining the optimal amount of underreporting is very complex, and requires each solver to make strong assumptions regarding the performance of competing solvers.
+The presence of the cap on rewards $$c_u$$, however, makes the problem more complex as it introduces a "first-price auction" logic: if the difference between the best and second-best solution is very large, then the winning solver wins more when it underreports its score. However, determining the optimal amount of underreporting is very complex, and requires each solver to make strong assumptions regarding the performance of competing solvers.
 
 To summarize, there is a simple strategy that guarantees positive expected profits to solvers. This strategy may not be optimal in uncompetitive auctions when the difference between the best and second best solution may be large. However, in these cases, deriving the optimal strategy is a very complex problem. We conclude by noting that most CoW Protocol batches are very competitive: the cap of on rewards is binding only in about 9% of auctions.
 

docs/cow-protocol/reference/core/auctions/schema.md

@@ -37,7 +37,7 @@ This key lists all tokens that appear in some order or AMM in the batch auction
 
 - `decimals`: an integer equal to the number of decimals of the token.
 - `symbol`: a string denoting the shorthand name of the token (e.g., "WETH", "DAI").
-- `referencePrice`: a float that corresponds to the price of the smallest denomination of the token with respect to a _reference token_ (for mainnet, the reference token is WETH, and its referencePrice is 1000000000000000000). Only tokens that are traded by at least a user order will necessarily have non-null referencePrice, while the rest of the tokens are allowed to have a `null` referencePrice. These prices are used when evaluating the quality of a given solution, and can be thought of as a way of converting and expressing all relevant quantities in WETH (note that, initially, the surplus of different orders can be denominated in different tokens), and aggregating them all in a single value, denominated in WETH.
+- `referencePrice`: a float that corresponds to the price of the smallest denomination of the token with respect to a _reference token_ (for mainnet, the reference token is WETH, and its referencePrice is 1000000000000000000). Only tokens that are traded by at least a user order will necessarily have non-null referencePrice, while the rest of the tokens are allowed to have a `null` referencePrice. These prices are used when evaluating the score of a given solution, and can be thought of as a way of converting and expressing all relevant quantities in WETH (note that, initially, the surplus of different orders can be denominated in different tokens), and aggregating them all in a single value, denominated in WETH.
 - `availableBalance`: a stringified integer that describes the amount (in the token's lowest denomination) of the token currently stored in the settlement contract ([internal buffers](/cow-protocol/reference/core/definitions#buffers)). This information is relevant when a solver attempts to [internalize an interaction](#using-internal-buffers).
 - `trusted`: this is a boolean flag that specifies whether the contract is willing to store the token as part of an [internalized interaction](#using-internal-buffers).
 

docs/cow-protocol/reference/core/auctions/the_problem.md

@@ -81,10 +81,10 @@ At CoW DAO's discretion, systematic violation of these rules may lead to penaliz
 :::
 
 
-From the protocol viewpoint, each solution that satisfies the above constraints has a _quality_ given by the total surplus generated and the fees paid to the protocol:
+From the protocol viewpoint, each solution that satisfies the above constraints has a _score_ given by the total surplus generated and the fees paid to the protocol:
 
 $$\sum_o U(o)+p\cdot \sum_of(o)$$,
 
 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 that generates the most amount of surplus for the user(s). 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 largest possible score. The [solver that wins the auction is rewarded](rewards) by the protocol.