docs: audit metadata, SEO descriptions, and sidebar titles

bff/development/creating-services.mdx

@@ -1,11 +1,12 @@
 ---
 title: "Creating Services and Libraries"
+sidebarTitle: "Creating services"
 description: "Guide to scaffolding new services, applications, and libraries in the CoW Protocol BFF monorepo using NX generators"
 ---
 
 # Creating Services and Libraries
 
 The CoW Protocol BFF monorepo uses NX generators to scaffold new projects with proper TypeScript, Docker, and configuration setup.
 
 ## Available Generators
 
@@ -17,13 +18,13 @@
 | `yarn new:node`   | Background workers, CLI tools |
 | `yarn new:lib`    | Shared libraries             |
 
 ## Fastify API Services
 
 ```bash
 yarn new:fastify
 ```
 
 Running the Fastify generator creates a complete API structure with:
 
 - App configuration (`src/app/app.ts`)
 - Entry point (`src/main.ts`)

changelog.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Changelog"
-description: "Latest updates to CoW DAO documentation."
+description: "Latest updates and announcements for the CoW Protocol, CoW Swap, and CoW DAO documentation."
 ---
 
 <Update label="Documentation migrated to Mintlify" description="2025-03-04">

cow-amm.mdx

@@ -1,23 +1,24 @@
 ---
 title: "CoW AMM: The First MEV-capturing AMM"
-description: "CoW AMM protects LPs from LVR so they can provide liquidity with less risk and more return. CoW AMM achieves close to 5% more in TVL compared to reference pools, protects millions from LVR, and has captured over $100,000 in surplus for LPs to date."
+sidebarTitle: "CoW AMM"
+description: "CoW AMM is the first MEV-capturing AMM: it protects LPs from LVR, beats reference pools on TVL, and has captured over $100k in surplus for LPs."
 hidden: true
 ---
 
 ## AMMs don't want you to know about LVR
 
 Liquidity providers expect their tokens to earn yield, but the dirty little secret of AMMs is that most liquidity pools lose money. In fact, hundreds of millions of dollars of LP funds are stolen by arbitrageurs every year. These losses are known as loss-versus-rebalancing (LVR). LVR is a bigger source of MEV than frontrunning and sandwich attacks combined.
 
 ## An AMM designed with LPs in mind
 
 CoW AMM eliminates LVR once and for all by using batch auctions to send surplus to LPs
 
 1. Liquidity providers deposit tokens into protected CoW AMM liquidity pools, where traders can access the liquidity
 2. Solvers bid to rebalance CoW AMM pools whenever there is an arbitrage opportunity
 3. The solver that offers the most surplus to the pool wins the right to rebalance the pool
 4. CoW AMM eliminates LVR by capturing arbitrage value for LPs and shielding it from MEV bots
 
 ## Deploy liquidity on CoW AMM
 
 Thanks to CoW AMM's integration with Balancer, LPs can now [deploy their liquidity or create a brand new pool in just a few clicks](https://balancer.fi/pools/cow).
 

cow-amm/explanation/how-cow-amms-work.mdx

@@ -1,5 +1,6 @@
 ---
 title: "How CoW AMMs Work"
+description: "How CoW AMM uses function-maximizing batch auctions and solver competition to eliminate LVR and protect liquidity providers."
 ---
 
 ## FM-AMMs
@@ -14,27 +15,27 @@
 
 ## Contract architecture
 
 CoW AMM is built as a set of contracts that integrate natively with Balancer's infrastructure and CoW Protocol's solver competition:
 
 - **`BCoWPool`**: The AMM pool contract, which extends Balancer's `BPool`. Each CoW AMM pool is a `BCoWPool` instance that holds liquidity and defines the trading function. It implements the `IConditionalOrder` interface from [ComposableCoW](/cow-protocol/reference/contracts/periphery/composable-cow), which allows the CoW Protocol watchtower to poll the pool for tradeable orders.
 - **`BCoWFactory`**: The factory contract used to deploy new CoW AMM pools. It creates `BCoWPool` instances with the correct configuration for CoW Protocol integration.
 - **`BCoWHelper`**: A helper contract for solvers. Given a pool and the current on-chain state, it generates valid order parameters that solvers can include in their settlement batches.
 
 The end-to-end flow works as follows:
 
 1. **Pool deployment** — An LP deploys a new pool via `BCoWFactory` and adds liquidity.
 2. **Watchtower polling** — The CoW Protocol watchtower periodically calls each pool's `getTradeableOrderWithSignature` (via the `IConditionalOrder` interface) to discover when the pool has a tradeable order.
 3. **Solver queries** — When a solver identifies a CoW AMM order, it can use `BCoWHelper` to compute valid order parameters that move the AMM curve higher.
 4. **Batch settlement** — The solver includes the CoW AMM order in its settlement batch alongside user orders, enabling coincidence of wants.
 5. **Pool rebalances** — After settlement, the pool's reserves are updated and the AMM curve moves to reflect the new balances.
 
 <Note>
   CoW AMMs are **not** based on Safe (the old architecture). They are native Balancer pools with direct CoW Protocol integration via the ComposableCoW programmatic order framework.
 </Note>
 
 ## Getting Started with CoW AMM
 
 To facilitate easy liquidity providing, CoW DAO has partnered with Balancer to implement CoW AMMs into the Balancer ecosystem. LPs can [use the Balancer app](https://balancer.fi/pools/cow) to LP direclty on one of over a dozen liquidity pools.
 
 In the next section, LPs can learn how to create their own CoW AMM pools for brand new assets either on Balancer or outside the platform.
 

cow-amm/explanation/the-problem-of-lvr.mdx

@@ -1,21 +1,22 @@
 ---
 title: "The Problem of LVR (Loss-versus-rebalancing)"
-description: "First coined by a team of researchers from  LVR is a form of arbitrage that occurs whenever an AMM has an outdated (stale) price in comparison to some other trading venue."
+sidebarTitle: "The problem of LVR"
+description: "LVR (Loss-versus-Rebalancing) is a form of arbitrage that occurs when an AMM has a stale price compared to other venues — and how it harms liquidity providers."
 ---
 
 Arbitrageurs exploit this difference by trading from the AMM to the more liquid exchange (usually a centralized exchange like Binance), correcting the arbitrage and extracting value from LPs in the process.
 
 # How LVR Works
 
 Most AMMs (such as Uniswap) are examples of constant function automated market makers—CF-AMMs. These AMMs take in two assets and automatically re-calculate prices after each trade to ensure ample liquidity at all times. This means the AMMs experience asset price discovery as they are being traded against.
 
 However, since crypto assets trade on various platforms including centralized exchanges, the prices on a CF-AMM may be outdated compared to the more liquid prices on a centralized exchange. This discrepancy allows arbitrageurs to trade between the liquid exchange and the outdated AMM, correcting prices and capturing arbitrage in the process.
 
 "Loss-versus-rebalancing" is the scenario where an LP provides liquidity to a CF-AMM whose prices are stale compared to a more liquid venue like a centralized exchange. By leaving their funds in the liquidity pool, they are not making as much money as they could be if they were to constantly "rebalance" between the AMM and the exchange. Thus, they incur a "loss" compared to what they would have in a "rebalancing" strategy.
 
 # The Impact of LVR on LPs
 
 Many liquidity providers haven’t even heard of LVR, but it costs them 5–7% of their liquidity, resulting in hundreds of millions lost each year. In fact, when accounting for LVR, many of the largest liquidity pools are not profitable for LPs at all.
 
 Due to these losses, LVR is a type of MEV (maximal extractable value) that accounts for more price exploitation than frontrunning and sandwich attacks combined.
 

cow-amm/tutorials/cow-amm-deployer.mdx

@@ -1,35 +1,36 @@
 ---
 title: "Deploying a CoW AMM Using Balancer"
-description: "In this short tutorial, we describe how you can create and deploy their own Balancer CoW AMM."
+sidebarTitle: "Deploy with Balancer"
+description: "Step-by-step tutorial for creating and deploying your own Balancer-based CoW AMM pool, including pool parameters and post-deployment checks."
 hidden: true
 ---
 
 **You may also deploy a CoW AMM through the Balancer UI using [this guide.](https://cow.fi/learn/how-to-create-a-lvr-protected-liquidity-pool-on-cowamm)**
 
 The proposed transactions and interactions can be executed through any smart contract or EOA transaction builder, Etherscan "Write Contract," from other UI mechanisms, or directly from the console.
 
 The current factory contract addresses are the following:
 
 * Ethereum Mainnet: [`0xf76c421bAb7df8548604E60deCCcE50477C10462`](https://etherscan.io/address/0xf76c421bAb7df8548604E60deCCcE50477C10462#code)
 * Gnosis Chain: [`0x703Bd8115E6F21a37BB5Df97f78614ca72Ad7624`](https://gnosisscan.io/address/0x703Bd8115E6F21a37BB5Df97f78614ca72Ad7624#code)
 * Arbitrum One: [`0xE0e2Ba143EE5268DA87D529949a2521115987302`](https://arbiscan.io/address/0xe0e2ba143ee5268da87d529949a2521115987302#code)
 * Base: [`0x03362f847B4fAbC12e1Ce98b6b59F94401E4588e`](https://basescan.org/address/0x03362f847b4fabc12e1ce98b6b59f94401e4588e#code)
 * Avalanche: N/A
 * Polygon: N/A
 * BNB: N/A
 * Linea: N/A
 * Plasma: N/A
 * Sepolia Testnet: [`0x1E3D76AC2BB67a2D7e8395d3A624b30AA9056DF9`](https://sepolia.etherscan.io/address/0x1E3D76AC2BB67a2D7e8395d3A624b30AA9056DF9#code)
 
 These contracts can be verified through [this](https://github.com/balancer/cow-amm) repository.
 
 1. In order to create a new pool, one first needs to call the `newBPool` function of the factory contract. An example transaction that creates a new pool can be found [here](https://etherscan.io/tx/0x7543a97853827e267ecd3c1309509ac7704e4f85a53fbfacd6060f461d85bad8#eventlog). The relevant `LOG_NEW_POOL` log also reveals the address of the newly created pool; in our example transaction, it is `0x81530e9B069c69F6671A0A9d7Ee337cafEF419F6`.
 
 <Note>
   In case ABI of the factory contract is not fetched, the ABI from the Sepolia network can be used.
 </Note>
 
 1. The next step is to approve the tokens we want to add to the pool; this can be done by calling the `approve()` function on the contract of the relevant ERC-20 token that is being added to the pool, where the "spender" needs to be set to the newly created BPool address from (1).
 
 <Warning>
   One needs to take the token's decimals into account in order to set the correct approval.
@@ -37,7 +38,7 @@
 
 1. The next step is to bind the approved tokens to the pool, by using the `bind()` function of the newly created pool contract. We need to do one bind per token that will be added to the pool. Note that the `denorm` parameter should always be set to 1000000000000000000 (i.e., 10^18).
 
 2. We can then set the swap fee; this is the fee trades will pay if they trade permissionlessly (i.e., outside of the batch), and this is done by calling the `setSwapFee()` function of the pool contract. The fee parameter needs to be specified in wei, hence, a 10% fee would be 100000000000000000 (i.e., 10^17)
 
 <Note>
   In order to guarantee full LVR protection, the fee should be set to 100%.

cow-amm/tutorials/cow-amm-for-solvers.mdx

@@ -1,34 +1,35 @@
 ---
 title: "CoW AMM Liquidity for Solvers"
+description: "How solvers can use CoW AMM as a liquidity source on CoW Protocol, including custom buy and sell amounts and pool selection."
 ---
 
 ## I'm a solver. How do I use CoW AMM liquidity?
 
 CoW AMM orders already appear in the CoW Protocol orderbook, so you're already using its liquidity. However, CoW AMMs allow solvers to specify custom buy and sell amounts, as long as the order preserves or increases the constant product invariant of the token reserves.
 
 CoW AMMs can be treated as a liquidity source akin to Uniswap or Balancer weighted pools with uniform weights. Each CoW AMM is a pair that trades two tokens.
 
 Importantly, surplus for a CoW AMM order is measured differently when computing the solver reward payout.
 
 ### Indexing Balancer CoW AMMs
 
 CoW AMM pairs can be detected by listening to the `COWAMMPoolCreated` events emitted by the `BCowFactory` instance for the current chain (see the [official contract repository](https://github.com/balancer/cow-amm) for the current deployment addresses). All addresses of Balancer CoW AMMs are sent as part of the auction instance as `surplusCapturingJitOrderOwners`.
 
 The AMM reserves are the balance of the two tokens traded by the AMM.
 
 ### Creating CoW AMM orders with the helper contract
 
 Integrating CoW AMM orders requires adding a JitOrder with the CoW AMM. This order should be described from the CoW AMM pool's perspective. So if a user wants to sell token A to buy token B and you would like to settle (part of) this order with a CoW AMM, then you would need to add a JitOrder from the CoW AMM's perspective to match (part of) this order. In other words, you would be adding a JitOrder for the CoW AMM to sell token B to buy token A. You can do this by calling the `orderFromBuyAmount` because the user’s amount is exactly how much you would want the pool to receive, asking for the amount of tokens in exchange.
 
 [The source code for the helper contract can be found here.](https://github.com/balancer/cow-amm/blob/main/src/contracts/BCoWHelper.sol) The `orderFromBuyAmount` and 'orderFromSellAmount' methods return the order, preInteractions, postInteractions, and signature. This can be used to generate the order (JitOrder) and check prices.
 
 This order generated by the BCoWHelper contract will contain the limit prices for which the CoW AMM is willing to trade. Trading at exactly these limit prices will not generate surplus for the CoW AMM, any price improvement from these limit prices will be surplus captured by the CoW AMM.
 
 One thing to keep in mind when using the helper contract to generate these JitOrders is that both the `orderFromSellAmount` and `orderFromBuyAmount` methods return an order where the `partiallyFillable` field is marked as true. However, since the driver does not support partially fillable JitOrders, it replaces the partiallyFillable field with false. This means that the `partiallyFillable` field must be set to false before passing the solution to the driver and the signature of both the JitOrder and the commit hash in the pre-interaction should be updated accordingly.
 
 Doing this will generate additional surplus in the solver competition (assuming you trade at a better price than the provided limit price). For example, if a solver would like to settle a user using outside liquidity that trades a pair for which there is a CoW AMM, then that solver can compare those prices with that of the CoW AMM. This (or part of this) interaction can then be replaced with the CoW AMM to generate additional surplus. This way the solver can integrate CoW AMMs by solving as if these CoW AMM's do not exist, and then check whether some of the outside interactions can be replaced by CoW AMMs (note: UPC and EBBO apply to CoW AMMs as well).
 
 Another way that a solver can use CoW AMM's is by using outside liquidity from the competition/auction to trade with the CoW AMM, thereby re-balancing the AMM and receiving an additional surplus for doing so if the prices of the CoW AMM is off relative to the outside world.
 
 The helper contracts are deployed here:
 
@@ -39,7 +40,7 @@
 * Avalanche N/A
 * Polygon N/A
 * BNB N/A
 * Linea N/A
 * Plasma N/A
 
 ### Settling a custom order

cow-protocol/explanation/architecture/autopilot.mdx

@@ -1,5 +1,6 @@
 ---
 title: "Autopilot"
+description: "The autopilot is the backend engine that orchestrates CoW Protocol auctions, coordinating solvers, orderbook, and on-chain settlement."
 ---
 
 ## Overview
@@ -32,7 +33,7 @@
 
 The autopilot builds an auction that includes all tradable orders. To handle this, it needs to maintain a complete overview of the protocol.
 
 Much of the order data it needs is collected through the database, which is shared with the orderbook. The database stores the vast majority of available order information, including user signatures.
 
 Other information can only be retrieved on-chain and is updated every time a new block is mined. For example, it needs to know from the protocol:
 
@@ -43,13 +44,13 @@
 
 Retrieved information isn't limited to the CoW Protocol itself. The autopilot needs to provide a reference price for each token in an order (a numéraire); the reference price is used to normalize the value of the [surplus](/cow-protocol/reference/core/auctions/the-problem), since the surplus must be comparable for all orders and two orders could use the most disparate `ERC-20` tokens. The reference token is usually the chain's native token, since it's the token used to pay for the gas needed when executing a transaction. Orders whose price can't be fetched are discarded and won't be included in an auction.
 
 Native token price fetching is handled by an integrated price estimator in the autopilot. The price is fetched from multiple sources and may change based on the current configurations. Prices are both queried from a list of selected existing solvers as well as retrieved internally by the autopilot (for example, by querying some external parties like Paraswap and 1inch, but also by reading on-chain pool data as Uniswap).
 
 Orders that can't be settled are filtered out. This is the case if, for example:
 
 * an order is expired
 * for fill-or-kill orders the user's balance isn't enough to settle the order
 * the approval to the vault relayer is missing
 * the involved tokens aren't supported by the protocol
 
 The autopilot also checks that [`ERC-1271`](/cow-protocol/reference/core/signing-schemes#erc-1271) signatures are currently valid.

cow-protocol/explanation/architecture/driver.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Driver"
-description: "People interested in running a solver to participate in CoW Protocol mainly want to focus on implementing the most efficient solver engine. However, there are also many mundane tasks that may not seem like a competitive advantage but have to be done regardless."
+description: "The driver is the CoW Protocol component that handles non-competitive solver operations, freeing teams to focus on building an efficient solver engine."
 ---
 
 ## Overview
@@ -13,7 +13,7 @@
 
 The `driver` sits between the [autopilot](/cow-protocol/explanation/architecture/autopilot) and a [solver engine](/cow-protocol/explanation/architecture/solver-engine) and acts as a intermediary between the two. In case you decide to run the driver for a solver engine the lifecycle of an auction looks like this.
 
 Splitting the driver from the solver engine is just a design decision to keep the barrier of entry for new solvers low. However, there is nothing preventing you from patching, forking or reimplementing the driver. You can even merge the responsibilities of the driver and solver engine into one if you want to build the most optimal solver possible; the only hard requirement is that the component the autopilot interfaces with implements this [interface](/cow-protocol/reference/apis/driver).
 
 ## Methodology
 
@@ -27,9 +27,9 @@
 
 ### Fetching liquidity
 
 Unless you find a perfect CoW you'll need some sort of liquidity to settle an order with. To get your solver started with a good set of base liquidity the driver is able to index and encode a broad range of fundamental AMMs. These include `UniswapV2` and its derivatives, `UniswapV3` as well as several liquidity sources from the `BalancerV2` family. All of these can be individually configured or completely disabled if your solver engine manages liquidity on its own.
 
 ### Postprocessing solutions
 
 The driver expects the solver engine to return a recipe on how to solve a set of orders but the recipe itself could not be submitted on-chain. In the post-processing step the driver applies multiple sanity checks to the solution, encodes it into a transaction that can be executed on-chain and verifies that it actually simulates successfully before it considers the solution valid. All this is done because solvers can get slashed for misbehaving so the reference driver checks all it can to reduce the risk of running a solver as much as possible.
 
@@ -41,22 +41,22 @@
 
 ### Submitting settlements
 
 If a solver provided the best solution the autopilot will tell the driver to actually submit it on-chain. This is not as straight forward as it sounds when the blockchain is congested and liquidity sources are volatile. To protect the solver from losing ETH by submitting solutions that revert the driver continuously verifies that the solution still works while it submits it on-chain. As soon as it would revert the driver cancels the transaction to cut the losses to a minimum.
 
 The driver can be configured to use different submission strategies which it dynamically choses based on the potential of MEV for a settlement. If the settlement does not expose any MEV (e.g. it executes all trades without AMMs) it's safe and most efficient to directly submit to the public mempool. However, if a settlement exposes MEV the driver would submit to an MEV-protected RPC like [MEVBlocker](https://mevblocker.io).
 
 ### Flash Loans
 
 The user is able to create a flash loan order's hint by attaching to the `appData` the specified metadata. The autopilot reads the order and cuts it into a [fair combinatorial batch auction](/cow-protocol/explanation/introduction/fair-combinatorial-auction). Then the driver fetches the `appData` by calling the orderbook with `GET /v1/app_data/<app_data_hash>` for every order and caches them in memory. The driver should include the flash loan information into the batch auction's order before sending it to the solver(s).
 
 #### Flash Loans Encoding
 
 If a solver decides to encode the transaction without the help of the reference driver, the solver must call the `IFlashLoanRouter` contract's [flashLoanAndSettle](/cow-protocol/reference/contracts/periphery/flashloans#flashloanandsettle) function instead of the settlement contract's [settle](/cow-protocol/reference/contracts/core/settlement#settle) function. The solver must provide all necessary flash loan inputs for the settlement, as well as the settle calldata, which will be executed within the same context by the `IFlashLoanRouter` contract. The `IFlashLoanRouter` contract will then request the specified flash loans and, once received, execute the settlement as instructed.
 
 The entry point to the router contract ([IFlashLoanRouter](/cow-protocol/reference/contracts/periphery/flashloans#iflashloanrouter-contract)) is the function `flashLoanAndSettle`. It takes a list of loans with the following entries for each loan:
 
 * The loaned amount and ERC-20 token.
 * The flash-loan lender (e.g., Balancer, Aave, Maker, ...).
 * The *borrower*, which is an adapter contract that makes the specific lender implementation compatible with the router.
 
 Only CoW-Protocol solvers can call this function. It also takes the exact call data for a call to `settle`. The flash-loan router is a solver for CoW Protocol and calls `settle` directly once the flash loans have been obtained.
@@ -81,9 +81,9 @@
 
 As you can see the driver has many responsibilities and discussing all of them in detail would be beyond the scope of this documentation but it's worth mentioning one guiding principle that applies to most of them: make the driver do as *little* work as possible in the hot path when processing an auction.
 
 Because having more time for the solver to compute a solution leads to a more competitive solver every process in the driver should introduce as little latency as possible. Also the blockchain is obviously the single source of truth for a lot of the state in the driver and fetching state from the network can be quite slow.
 
 To reconcile these aspects many internal components listen for new blocks getting appended to the blockchain. Whenever that happens the driver fetches all the relevant information and caches it. When the next auction comes in and the driver actually needs that data it's already up-to-date and ready to be used.
 
 ### Dependencies
 

cow-protocol/explanation/architecture/solver-engine.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Solver Engine"
-description: "The Solver Engine implements the  of the CoW Protocol batch auction. As part of the auction lifecycle, it receives a request from the  containing a potentially pre-processed auction instance and returns information about which order to execute together with instructions on how to achieve the desired execution using on-chain liquidity \"interactions\"."
+description: "The Solver Engine is the component that picks which CoW Protocol orders to execute in a batch and returns on-chain interactions to settle them."
 ---
 
 <Note>
@@ -28,7 +28,7 @@
 
 ### Baseline
 
 For each order in the problem set, this solver implements a greedy single-path output maximization algorithm in a weighted graph where vertices correspond to tokens and edges correspond to AMMs providing liquidity between tokens with their output equal to the exchange rate as defined by AMM function given the input amount. Outputs are adjusted to consider the execution cost of updating the AMM when used, using fixed gas amount estimates but taking into account the gas price provided in the auction input. The graph originates over a set of "base tokens" plus the buy and sell token of the order. It aims to find the single path from buy to sell token that maximizes the output for sell orders and minimizes the input for buy orders. It handles partially fillable attempting to first fill the entire order. If the resulting output doesn't satisfy the limit price, it re-attempts filling the order to 50% and keeps halving its amount until a match is found. It does not produce Coincidences of Wants.
 
 ## Flash Loans
 

cow-protocol/explanation/benefits/trade-any-intent.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Trade any intent"
-description: "CoW Protocol allows users to express any type of trade intent on Ethereum and EVM-compatible chains, leveraging  to execute the transactions through the most optimal route."
+description: "CoW Protocol lets users express any trade intent on Ethereum and EVM-compatible chains, with solvers routing each intent through the most optimal path."
 ---
 
 The protocol supports any order logic which includes standard market and limit orders, but also advanced order types such as [TWAP](/cow-protocol/explanation/order-types/twap-orders). Thanks to `ERC-1271`, smart contracts can also submit intents, paving the way for the [Programmatic Order Framework](/cow-protocol/explanation/order-types/programmatic-orders) and contracts like [Milkman](/cow-protocol/explanation/order-types/milkman-orders).

cow-protocol/explanation/flash-loans/integrators.mdx

@@ -1,6 +1,7 @@
 ---
 title: "How to specify an order with flash loan"
-description: "The flash loan is encoded into the 's metadata as an optional object. This information serves as a hint for the solver, but the solver ultimately can decide for a different approach in order to make the operation more optimal."
+sidebarTitle: "Flash loan orders"
+description: "How to encode a flash loan as optional metadata on a CoW Protocol order so solvers can use it as a hint when proposing settlements."
 ---
 
 It is important to ensure that the flash loan gas overhead is added to the slippage tolerance when creating the order.

cow-protocol/explanation/how-it-works/flow-of-an-order.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Flow of an order"
-description: "Rather than creating executable on-chain transactions, CoW Protocol users submit their orders as signed  messages. This allows  to find the optimal execution path for the batch of orders before committing them on-chain."
+description: "How a CoW Protocol order flows from a signed off-chain message, through solver competition, to optimal batch execution and on-chain settlement."
 ---
 
 Let's bring all of our main concepts together by taking a look at the flow of an order through CoW Protocol.
@@ -24,7 +24,7 @@
 
 Once the winning solver executes the batch's orders on-chain, users receive their tokens.
 
 The competition between solvers in a batch auction ensures that users (including traders, DAOs, smart contracts, and bots) always receive the best prices for their trades.
 
 Letting solvers do the heavy lifting means users don't have to worry about finding the best liquidity pool, setting the right gas price, or picking the optimal slippage tolerance for their trades. Solvers are also experts at avoiding MEV so users can rest assured their orders are protected from MEV bots that exploit their price through frontrunning and sandwich attacks.
 

cow-protocol/explanation/introduction/fair-combinatorial-auction.mdx

@@ -1,6 +1,7 @@
 ---
 title: "Fair Combinatorial Batch Auction"
-description: "CoW Protocol collects and aggregates intents off-chain and auctions them off to solvers. The auction is a Fair Combinatorial Batch Auction (FCBA) because each solver can submit multiple bids. A solver can submit multiple bids on individual orders, in which case each \"bid\" represents the best price this solver can provide to an individual order. However, a solver can also submit \"batched\" bids, that is, bids on groups of orders."
+sidebarTitle: "FCBA"
+description: "How CoW Protocol's Fair Combinatorial Batch Auction (FCBA) aggregates off-chain intents and lets solvers submit individual or batched bids."
 ---
 
 The protocol filters out \`\`unfair'' batched bids, which are those delivering less to an order than some available "non-batched" bids. It then selects the combination of winning bids that maximizes the surplus received by the orders that are part of the auction (subject to some computational constraints due to the combinatorial nature of the problem).

cow-protocol/explanation/introduction/intents.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Intents"
-description: "Rather than placing orders by  that executes directly on-chain (i.e. as happens on Uniswap or SushiSwap), CoW Protocol users place orders by  that specifies parameters like the assets and amounts they would like to trade. The intent is a signed message which allows the solvers to execute a trade on behalf of the user using their specified assets and amounts."
+description: "How CoW Protocol uses intents — signed messages that describe a desired trade — instead of on-chain transactions, letting solvers execute trades on the user's behalf."
 ---
 
 There are a number of [financial](#financial-benefits-of-intents) and [technical](#technical-benefits-of-intents) advantages to intent-based trading.
@@ -12,7 +12,7 @@
 Thanks to its intent-based architecture, CoW Protocol delegates the job of finding the optimal execution path to professional third parties known as [solvers](/cow-protocol/explanation/introduction/solvers). Solvers not only scan all available on-chain liquidity (similar to a DEX aggregator) they also provide extra price improvements in several ways:
 
 * [**Coincidence of Wants**](/cow-protocol/explanation/how-it-works/coincidence-of-wants): Direct P2P (peer-to-peer) matching for two or more users who have expressed opposite buy and sell intents for the same token pair. This optimization, enabled by batch auctions, allows users to bypass liquidity provider (LP) fees and it reduces the gas fees for trading as orders don't need to interact with other non-CoW Protocol smart contracts.
 * **Private Market Maker Inventory**: Many solvers have access to off-chain liquidity through CEX inventory, integration with private market makers, or private liquidity of their own. This allows them to fill certain trades at better prices than what may be available through on-chain AMMs at any given time.
 * [**MEV Protection**](/cow-protocol/explanation/benefits/mev-protection): On CoW Protocol, users are never exposed to MEV bots. Instead, solvers settle trades on behalf of the user, taking on all MEV risk. In addition, solvers submit all orders in a batch at a uniform clearing price, meaning there is no advantage to re-ordering trades (the basis of all MEV exploitation).
 
 ## Technical Benefits of Intents
@@ -20,7 +20,7 @@
 The intent-based architecture of CoW Protocol also provides a number of technical benefits:
 
 * Enabling [solvers](/cow-protocol/explanation/introduction/solvers) to execute all sorts of transactions (not just trades) based on specific instructions and on-chain conditions. This powers products like [CoW Hooks](/cow-protocol/explanation/order-types/cow-hooks) and [Programmatic Orders](/cow-protocol/explanation/order-types/programmatic-orders)
 * Establishing additional rules for the way orders settle on-chain, such as guaranteeing that the trade is settled at [EBBO](/cow-protocol/reference/core/definitions#ebbo) (Ethereum best bid and offer, guaranteeing that the baseline price for the trade is what on-chain AMMs offer) and uniform clearing prices (where trades with the same token pair in the same batch are cleared at the same price)
 * Allowing users to pay gas fees in their *sell token* without needing to hold the chain-native token (like ETH) in their wallet
 * Eliminating fees for failed transactions
 * Allowing users to place multiple orders at once

cow-protocol/explanation/order-types/cow-hooks.mdx

@@ -1,15 +1,15 @@
 ---
 title: "CoW Hooks"
-description: "CoW Hooks allow users to pair any Ethereum action (or set of actions) with an order on CoW Protocol, leveraging the  to execute the actions together in the sequence."
+description: "CoW Hooks let users attach any Ethereum action to a CoW Protocol order so pre- and post-trade steps execute together as part of the same flow."
 ---
 
 Hooks execute the entire sequence as a single transaction. True to the CoW Protocol model, users pay gas fees in their sell token if, and only if, the sequence of transactions succeeds. Under the hood, CoW Hooks are arbitrary Ethereum "calls" that attach to an order and execute before and/or after the order. Developers and advanced traders can use code to express an intent that performs some action before a swap (pre-hooks) and after a swap (post-hooks).
 
 ## Pre-Hooks
 
 These are actions that execute before the swap, allowing pre-hooks to be used to "set up" an order. Some examples including:
 
 * Unstaking tokens just-in-time for trading
 * Claiming an airdrop right before dumping
 * Signing token approvals so that the approval and the trade itself are batched together as a single action
 
@@ -32,7 +32,7 @@
     Browse and use pre-built hooks, or publish your own
   </Card>
   <Card title="Build a Hook dApp" icon="code" href="/cow-swap/hooks/hook-dapp">
     Develop a custom hook dApp for the CoW Swap interface
   </Card>
   <Card title="Post-Hook Examples" icon="arrow-right" href="/cow-swap/hooks/post-hook-examples">
     Swap → stake, swap → bridge, and swap → vault patterns

cow-protocol/explanation/order-types/pay-debt-flash-loans.mdx

@@ -1,6 +1,7 @@
 ---
 title: "Repay debt with collateral using flash loans"
-description: "A key use case of flash loans is the ability to repay debt with collateral, since flash loans allow users to close or reduce their debt positions without needing upfront liquidity."
+sidebarTitle: "Repay debt with collateral"
+description: "Use CoW Protocol flash loans to repay debt with collateral, letting users close or reduce debt positions without needing upfront liquidity."
 ---
 
 Instead of requiring users to have assets readily available to repay their loans, flash loans enable them to temporarily borrow the needed funds, use those funds to repay their debt, and immediately reclaim their locked collateral. Once the collateral is received, it can be swapped or liquidated to cover the borrowed amount, ensuring the loan is repaid within the same transaction.
@@ -22,7 +23,7 @@
 
 #### Lender allows a third-party to initiate the transfer of collateral tokens
 
 In this case, the user can sign a pre-hook that deploys a [COWShed](https://github.com/cowdao-grants/cow-shed) to repay the debt using flash-loaned tokens. `COWShed` is a user owned ERC-1967 proxy deployed at a deterministic address. This deterministic deployment allows users to set the proxy address as the receiver for cowswap orders with pre/post-hooks. The user signs a EIP-712 message for the pre/post-hooks which gets validated. Only user signed hooks are executed on the user's proxy. This allows users to confidently perform permissioned actions in the hooks such as:
 
 * transferring assets from the proxy to someone else.
 * use the proxy to add collateral or repay debt on a maker CDP or an AAVE debt position, etc.
@@ -35,5 +36,5 @@
 
 If the lender does not allow third-party to initiate the transfer of collateral tokens from the lending pool to the trader's address, the process becomes more involved. In this case, the repayment must come directly from the owner's account, meaning the owner cannot simply be an EOA (Externally Owned Account). Instead, it must be a smart contract (e.g. a SAFE wallet). That enables you to authorize function calls coming from the safe by signing them with the safe. That way you can create a hook initiating the withdrawal of the collateral tokens that a third-party can initiate. This is not possible when the collateral owner is an EOA.
 
 Additionally, repayment might not always involve selling the collateral token directly. In some cases, the protocol allows selling an interest-bearing version of the token instead. For example, if the collateral is aUSDC (which represents USDC deposited in Aave and earning interest), selling aUSDC instead of withdrawing and selling USDC directly ensures a more seamless repayment process. Understanding these trade-offs helps determine the correct approach based on the specific requirements of the lending protocol.
 

cow-protocol/explanation/order-types/programmatic-orders.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Programmatic orders"
-description: "In addition to normal wallets, CoW Protocol also supports smart contract wallets that implement . This allows users to place orders through smart contracts with programmable parameters that execute based on certain conditions."
+description: "How programmatic orders on CoW Protocol let smart contract wallets place orders with programmable parameters that execute based on on-chain conditions."
 ---
 
 We call these types of orders "programmatic orders" and we've developed a framework for creating programmatic orders, aptly named the "Programmatic Order Framework."
@@ -16,7 +16,7 @@
 **Example Use-Cases of Programmatic Orders:**
 
 * **Advanced order types:** The conditional nature of programmatic orders allows for complex order types such as stop-loss, good-after-time, take-profit, and more. In fact, CoW Protocol's [TWAP orders](/cow-protocol/explanation/order-types/twap-orders) are built on top of the Programmatic Order Framework.
 * **Automated wallet operations:** Wallets of all sizes can automate recurring actions using the Programmatic Order Framework. DAOs can automate payroll, treasury diversification, fee collections and more, while individuals can automate portfolio rebalancing, yield farming, hedge market positions and more.
 * **Protocol integrations:** Through the Programmatic Order Framework, protocols can add custom functionality to any transaction type. DAO tooling companies, for example, can build plug-n-play products while DeFi protocols can leverage the power of the Framework to assist with recurring protocol-level transactions like loan liquidations.
 
 ## Getting started

cow-protocol/howto/cow-explorer.mdx

@@ -1,10 +1,10 @@
 ---
 title: "Viewing orders"
-description: "As CoW Protocol utilizes an off-chain orderbook, and settles on-chain, getting a holistic view of the current state of CoW Protocol requires a combination of on-chain and off-chain data. Individually, this information is available from the following:"
+description: "How to view CoW Protocol orders across on-chain and off-chain sources using the CoW Explorer and complementary tools."
 ---
 
 * [Order book API](/cow-protocol/reference/apis/orderbook) (off-chain)
 * CoW Protocol Subgraph (on-chain)
 
 Switching between these tools, and reading raw JSON data is better suited for computers, not humans. To make it easier to view the current state of CoW Protocol, we've built a tool that combines the two, providing a convenient and holistic view of the current state of CoW Protocol.
 

cow-protocol/howto/solvers/fee-computation.mdx

@@ -1,5 +1,6 @@
 ---
 title: "Fee computation for limit orders"
+sidebarTitle: "Fee computation"
 description: "Guidelines for how solvers should compute fees when executing limit orders, where users sign orders with zero fees and solvers propose fees at execution time."
 ---
 
@@ -32,7 +33,7 @@
 When computing fees for a limit order, solvers should estimate:
 
 - **Gas cost**: The gas required to execute the order's swap interactions on-chain, priced at the current gas rate
 - **Liquidity cost**: Any adverse price impact from routing through AMMs
 - **Revert risk**: A small buffer to account for the probability that the settlement fails
 
 ### What counts as "execution cost"
@@ -50,7 +51,7 @@
 - Systematically overcharging to accumulate positive slippage
 
 <Warning>
 Violations of fair fee practices are considered potentially slashable offenses under CIP-11's malicious behavior provisions. The protocol monitors fee behavior and systematic overcharging can lead to penalties. See the [competition rules](/cow-protocol/reference/core/auctions/competition-rules#governance) for details.
 </Warning>
 
 ## How fees interact with rewards

cow-protocol/howto/solvers/flashloans_support.mdx

@@ -1,17 +1,18 @@
 ---
 title: "How to execute flashloans orders"
-description: "This short tutorial explains how orders with flashloans hints can be executed by solvers."
+sidebarTitle: "Execute flashloans orders"
+description: "How CoW Protocol solvers can detect, route, and execute orders that include flashloan hints in their metadata."
 ---
 
 ## Where to get information about an order’s flashloan?
 
 Information about an order's flashloan is added by the user inside the order’s [appdata](/cow-protocol/reference/core/intents/app-data). As a reminder, the autopilot only shares the appdata hash as part of the auction instance it shares with the [drivers](/cow-protocol/explanation/architecture/driver), and so it is the driver's responsibility to recover the full appdata.
 
 <Note>
   [Solvers](/cow-protocol/explanation/architecture/solver-engine) connected to the reference driver already receive the full appdata from the driver.
 </Note>
 
 For example, this [staging order](https://explorer.cow.fi/gc/orders/0x413a7246f58441ad92ea19c09cef90d1b23a1e211e0963f3d39b7db48140533d669685c660c260d80b614f8d1a5ffd24c4e3b82668cd8760) has the appdata hash `0xa8476d34ec1e22b818cf3d6289e30271a04a4e38a8a3a71f947b5881de06a852` which can be looked up [here](https://barn.api.cow.fi/xdai/api/v1/app_data/0xa8476d34ec1e22b818cf3d6289e30271a04a4e38a8a3a71f947b5881de06a852). Specifically, in the `metadata` field, the `flashloan` entry looks as follows:
 
 ```
       "flashloan": {        "amount": "20000000000000000000",        "liquidityProvider": "0xb50201558B00496A145fE76f7424749556E326D8",        "protocolAdapter": "0x19167A179bcDDBecc2d655d059f20501E5323560",        "receiver": "0x19167A179bcDDBecc2d655d059f20501E5323560",        "token": "0xe91D153E0b41518A2Ce8Dd3D7944Fa863463a97d"      }
@@ -19,56 +20,56 @@
 
 We now briefly explain what each entry means:
 
 * `amount`: units (in wei) that should be flashloaned;
 * `token`: which token should be flashloaned;
 * `receiver`: address that is supposed to receive the tokens;
 * `liquidityProvider`: the lending protocol’s contract (i.e. AavePool);
 * `protocolAdapter`: which address needs to be used to adapt the `liquidityProvider` to CoW Protocol’s flashloan machinery.
 
 ## Adjustments needed in the solver/driver
 
 ### Encoding the Call to the Flashloan Router
 
 As the flashloan needs to be available over the entire duration of the settlement, all flashloan settlements will have to go through the [flashloan router](/cow-protocol/reference/contracts/periphery/flashloans#iflashloanrouter-contract) (deterministically deployed at `0x9da8b48441583a2b93e2ef8213aad0ec0b392c69`; see the [flash-loan-router repository](https://github.com/cowprotocol/flash-loan-router) and the mainnet deployment [here](https://etherscan.io/address/0x9da8b48441583a2b93e2ef8213aad0ec0b392c69#code)). So, instead of calling `settle()` on the settlement contract, the driver has to call `flashloanAndSettle()` on the flashloan router contract. This `flashloanAndSettle()` call takes 2 arguments:
 
 1. `Loan.Data[]`, which can be trivially initialized with the data from the order’s `flashloan` field;
 2. the settlement, which is the calldata for the regular `settle()` call the router will eventually initiate after taking out all the flashloans.
 
 <Note>
   Specifically for the Aave integration, the driver is not required to inject any additional permissioned interactions. If the call to the flashloan router is constructed correctly and the pre- and post-hooks of the order are included, the call should succeed.
 
   We stress again that this is fully handled by the reference driver.
 </Note>
 
 ### Estimating the Gas Costs
 
 Solvers are responsible for capturing enough network fees to cover the total gas cost of a settlement. The flashloan flow, as described in the previous section, requires a call to a wrapper contract, which first takes the loans and then calls the settlement contract. This wrapper adds an overhead compared to just calling the settlement contract, and for this reason solvers should pay extra attention when estimating the total gas needed.
 
 <Warning>
   Proper gas estimation will be needed for all solvers - even the ones connected to the reference driver, as the reference driver does not do any post-processing and adjustments of the network fees computed by solvers. If this overhead is not taken into account, every time a solver settles a flashloan order would result in losses due to the underestimated gas costs.
 </Warning>
 
 <Note>
   If the solver does a simulation of the `eth_call` as part of its gas estimation logic, one will need to adjust it to call the flashloan router instead of the settlement contract. Alternatively, one can consider heuristically adding an overhead to estimate the additional gas needed. Some information on the gas can be found [here](https://github.com/cowprotocol/flash-loan-router/pull/19).
 </Note>
 
 ### Adjusting the Order Filtering Logic
 
 Many solvers implement some order filtering logic that, for example, discards orders with missing balances early so the matching engine does not have to process them. Orders may be placed if taking out a flashloan and executing the pre-hooks will lead to sufficient balance and allowance for the order. In Aave’s case, for example, the order will only pass the signature verification check if the pre-hook executed successfully. And that can only be executed if the `receiver` in the flashloan hint got enough tokens before hand.
 
 There are multiple ways for a solver to handle this:
 
 * assume an order is good if it uses flashloan;
 * adjust the solver's verification logic to simulate the whole flashloan (as discussed in the section about calling the router);
 * adjust the solver's verification logic to "fake" the flashloan by using state overrides to make it appear as if the flashloan `receiver` got the tokens it needed.
 
 ### Handling Bigger Auction Instances
 
 Together with the support for flashloans, we want to minimize the order filtering the autopilot does before even building the auction. This filtering was initially implemented as a performance optimization since most of the orders do not have sufficient balance, and the plan is to remove it. The order filtering is already implemented in the reference driver as well so nothing should change for solvers connected to that. For other solver/ drivers the auction in the `/solve` endpoint will contain \~3K orders or more from now on.
 
 ## Details on Aave’s Integration
 
 Aave will cover 3 new use cases:
 
 1. **Collateral swap**: User has a debt position and wants to change the collateral they use ([example](https://explorer.cow.fi/gc/orders/0x413a7246f58441ad92ea19c09cef90d1b23a1e211e0963f3d39b7db48140533d669685c660c260d80b614f8d1a5ffd24c4e3b82668cd8760)).
 
@@ -77,8 +78,8 @@
 3. **Debt swap**: User has a debt in a token and wants to swap for something else. Think about leverage, changing the debt to reduce interest for example ([example](https://explorer.cow.fi/gc/orders/0x6c100f2f6bb46ebf1c9f52660fdbe31079d4f982f56b524605358bd419af3a6237c390b08d5a3104b3efc1401e8d11e52624c75868d305a0)).
 
 <Note>
   These orders do not involve Aave’s `aToken` (i.e. `aUSDC` instead of `USDC`) but supporting them is recommended to participate in the non-flashloan version of each of the three usecases.
 </Note>
 
 Assuming the flashloan router call is encoded correctly, Aave’s orders will move the flashloaned funds to the correct spot using the pre-hook and will repay the flashloan in the post-hook. No additional calls have to be encoded in a solution. However, for this to work the flashloan has to be taken out with the given flashloan information. Getting the tokens, for example, by private liquidity is not supported in this use case.
 

cow-protocol/howto/solvers/onboard.mdx

@@ -1,5 +1,7 @@
 ---
 title: "Joining The CoW Protocol Solver Competition"
+description: "Step-by-step guide to onboarding as a solver on CoW Protocol, including bonding pools, shadow competition, and going live in production."
+sidebarTitle: "Solver onboarding"
 ---
 
 > ***NOTE:*** In order to get connected to the shadow competition, feel free to reach out to an admin of the ["CoW Swap Solvers"](https://t.me/+2Z_-DW57meA1MDlh) group on Telegram.
@@ -18,7 +20,7 @@
 6. Moving to production
 7. Weekly rewards and accounting
 8. Moving to other networks
 9. Joining the mainnet competition
 10. Joining the quoting competition
 11. F.A.Q.
 
@@ -28,7 +30,7 @@
 
 The general KYC requirements are to send us documentation proving that you are the beneficial owners of the company behind the solver and 1-2 passports of some of the main developers of the solver. Do not send this before the meeting, we will explain the process during the meeting so that you can send the documents afterwards.
 
 Given the risk that will be carried by the CoW DAO bonding pool we also ask that solvers who join the solver competition through the CoW DAO bonding pool start solving on Arbitrum first. After being in production on Arbitrum solvers can move to other L2's relatively easily. But joining the mainnet competition will require further evaluation after some time of solving on L2's.
 
 ### Service fees
 
@@ -48,10 +50,10 @@
 
 ### Exposed Endpoint
 
 The exposed endpoint provided must be of the following format: \{base\_url}/$\{envName}/$\{network} - for example: [https://api.mysolver.io/staging/mainnet](https://api.mysolver.io/staging/mainnet) envName values: shadow, staging, prod supported networks: arbitrum-one, avalanche, base, bnb, linea, mainnet, polygon, xdai (gnosis) and more are coming out!
 
 <Note>
   The request body received by your `/solve` endpoint is quite large. If you are using Nginx, the default request size limit will be too small and prevent you from receiving any auctions. Add the following directive to your Nginx `http`, `server`, or `location` block:
 
   ```nginx
   client_max_body_size 10M;
@@ -113,22 +115,22 @@
 
 After the onboarding call, the CoW team will begin preparing the required infrastructure for your solver to join the solver competition. If you are joining the solver competition under the CoW DAO bonding pool, then this will involve setting up and managing the driver on your behalf and setting up and managing the submission keys on your behalf.
 
 To do this, the team will generate keys for your solver to use for settling auctions on-chain and whitelisting those for the solver competition. In order to do this you will need to send a `rewards address` that you would like to use to receive weekly rewards on the chain that you are solving on. Specifically, the rewards address needs to be controlled by the relevant solver team on both the chain it is currently solving and on mainnet, as we send native token transfers to the chain the solver is active while we send COW rewards to the mainnet address always.
 
 After this process is done, the team will send you the submission addresses that your solver will use to settle auctions on-chain. While this is managed by the CoW team, it will be your responsibility to monitor this and make sure that is holds enough funds to cover gas fees. The driver has a minimum threshold for gas that it applies to make sure that the address holds (more than) enough funds to pay the required gas fees. Therefore we recommend these balances:
 
 | Network  | Environment | Recommended initial balance |
 | -------- | ----------- | --------------------------- |
 | Mainnet  | Staging     | 0.2 ETH                     |
 | Mainnet  | Production  | 1 ETH                       |
 | Arbitrum | Staging     | 0.05 ETH                    |
 | Arbitrum | Production  | 0.2 ETH                     |
 | Base     | Staging     | 0.05 ETH                    |
 | Base     | Production  | 0.2 ETH                     |
 | Gnosis   | Staging     | 15 xDAI                     |
 | Gnosis   | Production  | 100 xDAI                    |
 
 > ***NOTE:*** Please send the funds in the native currency of the chain that these addresses will be solving on. So for a submission address generated for your solver on Arbitrum, send the funds in ETH on the Arbitrum network.
 
 After your solver is live and begins settling transactions, it will be your responsibility to monitor these addresses and to make sure that they hold enough funds to settle transactions for winning auctions.
 
@@ -140,7 +142,7 @@
 
 ## 7. Weekly rewards and accounting
 
 Every week on Tuesday your solver will receive payments and rewards for settling auctions. Rewards in COW will be sent to the rewards address on mainnet, and reimbursements for network fees and slippage will be distributed on the same network as where the solving took place.
 
 We advise using a single rewards address that is available on all networks.
 
@@ -148,14 +150,14 @@
 
 ## 8. Moving to other networks
 
 After joining the solver competition on Arbitrum we can enable your solver on other chains relatively soon. For this we will go through the same process of generating addresses, vouching for them, and whitelisting them. For each new chain that we deploy your solver on we will need:
 
 * A rewards address for receiving the weekly COW rewards associated with that network;
 * An endpoint that you would like to use for staging amd production.
 
 ## 9. Joining the mainnet competition
 
 We usually wait a bit before migrating solvers to mainnet. After your solver has been active on other networks for some time the team can enable your solver on mainnet.
 
 ## 10. Joining the quoting competition
 
@@ -163,11 +165,11 @@
 
 ## 11. F.A.Q.
 
 ### Can we get access to the orderbook API?
 
 Yes, we can whitelist solvers so that they can have access to the orderbook API. Although we generally wait with this until your solver is live and settling orders on-chain.
 
 ### How do we integrate CoW AMMs?
 
 [We have a section in the documentation about integrating CoW AMMs.](https://docs.cow.fi/cow-amm/tutorials/cow-amm-for-solvers)
 
@@ -177,7 +179,7 @@
 
 ### What are the environments?
 
 There are three environments: shadow, staging, and production. In the shadow competition (only arbitrum and mainnet now) the solver is tested using production order flow but without settling any orders. This is for testing the integration of the solver. It is possible to simulate the solver's solutions and see how it does.
 
 In the staging (barn) competition settling happens on-chain but the volume is much lower. That way the solver is tested by actually settling orders on chain.
 

cow-protocol/howto/solvers/routes_integration.mdx

@@ -1,5 +1,7 @@
 ---
 title: "Getting new routes integrated Into CoW Protocol"
+description: "Guide for DeFi teams to integrate their liquidity sources with CoW Protocol so solvers can route trades through them."
+sidebarTitle: "Routes integration"
 ---
 
 ## Overview

cow-protocol/reference/contracts/core/allowlist.mdx

@@ -1,6 +1,7 @@
 ---
 title: "GPv2AllowlistAuthentication"
-description: "import HistoricalFact from './_gpv2.md'"
+description: "Reference for the GPv2AllowlistAuthentication contract, which manages the allowlist of solvers authorized to settle batches on CoW Protocol."
+sidebarTitle: "Allowlist authentication"
 ---
 
 ## Architecture

cow-protocol/reference/contracts/core/settlement.mdx

@@ -1,6 +1,7 @@
 ---
 title: "GPv2Settlement"
-description: "import HistoricalFact from './_gpv2.md'"
+description: "Reference for the GPv2Settlement contract, which executes batch settlements on CoW Protocol by matching orders and interacting with on-chain liquidity."
+sidebarTitle: "Settlement"
 ---
 
 ## Architecture
@@ -11,7 +12,7 @@
 * A list of trades to execute
 * A list of interactions
 
 A solver monitors on-chain liquidity and on receiving batch-auction instances from the Protocol, it determines which orders can be matched, the clearing prices of the settlement, and what extra liquidity is necessary from the blockchain.
 
 Normally, all orders in a settlement are settled with *uniform clearing prices*, which means that every user receives the same price for the same token.
 
@@ -28,13 +29,13 @@
 
 ### Trades
 
 Trades contain a description of the users' orders, a signature for verifying its validity, and the executed amount (for partially fillable orders).
 
 The contract decodes the order parameters from the trade.
 
 ### Interactions
 
 Interactions allow solvers to execute arbitrary calls to any on-chain contract. Normally, they are used to interact with other on-chain liquidity providers, for example, to make a swap call to Uniswap.
 
 <Accordion title="Protocol fee collection">
   Interactions are also used for accounting / bookkeeping purposes as well. As trades are executed, the Protocol collects a fee from each trade and stores this in the settlement contract (known as *[internal buffers](/cow-protocol/reference/core/definitions#internal-buffers)*). At regular intervals, the Protocol withdraws the fees from the settlement contract to the Protocol's treasury Safe.
@@ -68,13 +69,13 @@
 | `sellToken`         | `ERC-20` token sell                                                                                                                                                                             |
 | `buyToken`          | `ERC-20` token to buy                                                                                                                                                                           |
 | `receiver`          | The address that will receive the proceedings of the trade. If this field is `address(0)` (i.e. the zero address `0x00...0`), then the user who signed the trade is going to receive the funds. |
 | `sellAmount`        | Amount of `sellToken` that is sold in wei.                                                                                                                                                      |
 | `buyAmount`         | Amount of `buyToken` that is bought in wei                                                                                                                                                      |
 | `validTo`           | UNIX timestamp (in seconds) until which the order is valid                                                                                                                                      |
 | `appData`           | Extra information about the order. Not enforced by the smart contract outside of signature verification (may be used for referrals etc).                                                        |
 | `feeAmount`         | Amount of fees paid in `sellToken` wei                                                                                                                                                          |
 | `kind`              | `buy` or `sell`                                                                                                                                                                                 |
 | `partiallyFillable` | partially fillable (`true`) or fill-or-kill (`false`)                                                                                                                                           |
 | `sellTokenBalance`  | From where the `sellToken` balance is withdrawn                                                                                                                                                 |
 | `buyTokenBalance`   | Where the `buyToken` is deposited                                                                                                                                                               |
 
@@ -143,7 +144,7 @@
 
 #### `settle`
 
 This function is permissioned and can only be called by solvers passing the allow-list authentication. It executes a settlement:
 
 ```
 function settle(    IERC20[] calldata tokens,    uint256[] calldata clearingPrices,    GPv2Trade.Data[] calldata trades,    GPv2Interaction.Data[][3] calldata interactions) external nonReentrant onlySolver;

cow-protocol/reference/contracts/core/vault-relayer.mdx

@@ -1,11 +1,12 @@
 ---
 title: "GPv2VaultRelayer"
-description: "import HistoricalFact from './_gpv2.md'"
+description: "Reference for the GPv2VaultRelayer contract, which holds token allowances and shields user funds from malicious solver interactions on CoW Protocol."
+sidebarTitle: "Vault relayer"
 ---
 
 ## Architecture
 
 The `GPv2VaultRelayer` contract is an important component used to protect user funds from malicious solvers. As previously mentioned, the `GPv2Settlement` contract allows using arbitrary on-chain liquidity through interactions (such as performing a swap on [Balancer V2](https://balancer.fi), or performing a Paraswap trade). If `Vault` and `ERC-20` allowances were made directly to a `GPv2Settlement` contract, a malicious solver could drain user funds through the interaction mechanism. However, since these allowances are made to the `GPv2VaultRelayer` contract and interactions to the contract are strictly forbidden, malicious solvers have no direct access to user funds. The `GPv2Settlement` contract uses the `GPv2VaultRelayer` to withdraw user tokens only as part of the trade, which contains strong guarantees that the user's signed order parameters are respected.
 
 The `GPv2VaultRelayer` has access to user balances through 3 mechanisms:
 
@@ -25,18 +26,18 @@
 
 ### Balancer External Balances
 
 The second mechanism that the `GPv2VaultRelayer` contract can use to withdraw user `ERC-20` tokens is through `Vault` external balances. This works by having an `ERC-20` allowance for the Balancer Vault, and a relayer approval for the `GPv2VaultRelayer` contract.
 
 This allowance and approval combination allows the `GPv2VaultRelayer` contract to transfer `ERC-20` tokens through the `Vault`. Roughly speaking, the process works in the following way:
 
 1. `GPv2VaultRelayer` request to the Balancer Vault an `ERC-20` transfer from the user account to the `GPv2Settlement` contract
 2. The Balancer Vault verifies that the `GPv2VaultRelayer` contract is: a. Authorized by Balancer governance to act as a relayer b. The user has set an approval for that specific relayer
 3. The Balancer Vault issues an `ERC-20` transfer from the user account to the `GPv2Settlement` contract using the Vault's existing `ERC-20` allowance
 
 This system for withdrawing user funds has several advantages such as:
 
 * It can reuse existing `Vault` `ERC-20` allowances and doesn't require new ones specific to the CoW Protocol.
 * Upgrades to the CoW Protocol contract would only require a single relayer approval for all tokens instead of individual `ERC-20` approvals for each token being traded.
 * The `GPv2VaultRelayer` approval can be revoked by a single transaction to the `Vault` instead of multiple transactions to each `ERC-20` token for which the user wants to remove the approval.
 
 Orders with the `sellTokenBalance` flag set to `external` will withdraw using this process.

cow-protocol/reference/contracts/periphery/composable-cow.mdx

@@ -1,6 +1,6 @@
 ---
 title: "ComposableCoW"
-description: "ComposableCoW is the contract that implements programmatic orders on CoW Protocol. Programmatic orders are a subset of smart contract orders. It allows one to create programmatic orders that:"
+description: "Reference for the ComposableCoW contract, which implements programmatic orders on CoW Protocol as a subset of smart contract orders."
 ---
 
 1. Can be used to generate multiple discrete order (self-expressing)
@@ -16,23 +16,23 @@
 The following principles have been employed in the architectural design:
 
 1. `O(1)` gas-efficiency for `n` programmatic order creation / replacement / deletion
 2. Programmatic orders **SHOULD** behave the same as a discrete order for EOAs (self-custody of assets, i.e. "wrapper" contracts not required)
 3. Programmatic orders **SHOULD** be optimized towards *statelessness* - pass required data via `calldata`
 4. **MAY** enhance the [Safe](https://safe.global) user experience when paired with [`ExtensibleFallbackHandler`](https://hackmd.io/-nLuF3JIRyuS5w864_mbrg) 🐮🔒
 
 By using Merkle Trees, the gas efficiency of `O(1)` is achieved for `n` programmatic orders. This is achieved by storing the Merkle Tree root on-chain, and passing the Merkle Tree proof to the `ComposableCoW` contract. This allows for `O(1)` gas efficiency for adding / removing programmatic orders.
 
 For simplicity, single orders are also supported, however, this is **NOT** recommended for large `n` as the gas efficiency is `O(n)`.
 
 ### Execution context
 
 As there are many nested contracts, it's important for a callee to know some context from the caller. To achieve this, ComposableCoW passes a `bytes32` variable `ctx` to the callee, such that:
 
 ```
 ctx = merkle root of orders: bytes32(0)      single order:          H(ConditionalOrderParams)
 ```
 
 Having this context also allows for programmatic orders / merkle roots to use this as a key in a mapping, to store programmatic order-specific data.
 
 #### Programmatic order verification flow
 
@@ -139,7 +139,7 @@
 ### Guarantees and Invariants
 
 * CoW Protocol's settlement contract enforces single-use orders, i.e. **NO** `GPv2Order` can be filled more than once
 * For merkle trees, `H(ConditionalOrderParams)` **MUST** be a member of the merkle tree `roots[owner]`
 * For single orders, `singleOrders[owner][H(ConditionalOrderParams)] == true`
 
 <Warning>
@@ -167,7 +167,7 @@
 </Note>
 
 <Check>
   When used with Merkle Trees and a cryptographically-secure random `salt`, the programmatic order is effectively private (until a discrete order cut from this programmatic order is broadcast to the CoW Protocol API).
 </Check>
 
 <Warning>
@@ -186,11 +186,11 @@
 
 | **Field**       | **Description**                                          |
 | --------------- | -------------------------------------------------------- |
 | `proof`         | Merkle Tree proof (if applicable, zero length otherwise) |
 | `params`        | [`ConditionalOrderParams`](#conditionalorderparams)      |
 | `offchainInput` | Off-chain input (if applicable, zero length otherwise)   |
 
 By setting `proof` to zero-length, this indicates to `ComposableCoW` that the order is a single order, and not part of a Merkle Tree.
 
 ### `Proof`
 
@@ -224,7 +224,7 @@
 | `IPFS`    | `5`            | `abi.encode(bytes32 ipfsCid)`                                                                          |
 
 <Warning>
   Locations above are for the point of defining a standard. The provided watch-tower currently does *not* support Merkle Tree proofs for orders.
 </Warning>
 
 <Accordion title="JSON schema for proofs">
@@ -237,7 +237,7 @@
 
 ### `roots`
 
 Using an `owner` as a key, the `roots` mapping stores the Merkle Tree root for the programmatic orders of that `owner`.
 
 ```
 mapping(address => bytes32) public roots;
@@ -273,7 +273,7 @@
 
 #### `setRoot` / `setRootWithContext`
 
 A `safe` or `owner` calls the respective setter method to set the Merkle Tree root for their programmatic orders:
 
 ```
 function setRoot(bytes32 root, Proof calldata proof) public;function setRootWithContext(    bytes32 root,    Proof calldata proof,    IValueFactory factory,    bytes calldata data) external;
@@ -281,12 +281,12 @@
 
 | **Parameter** | **Description**                                                                         |
 | ------------- | --------------------------------------------------------------------------------------- |
 | `root`        | Merkle Tree root of programmatic orders                                                  |
 | `proof`       | [`Proof`](#proof)                                                                       |
 | `factory`     | An `IValueFactory` that will be used to populate the `ctx` storage slot (if applicable) |
 | `data`        | Data to be passed to the `factory` to populate the `ctx` storage slot (if applicable)   |
 
 When a new merkle root is set, emits `MerkleRootSet(address indexed owner, bytes32 root, Proof proof)`.
 
 <Note>
   `ComposableCoW` will **NOT** verify the proof data passed in via the `proof` parameter for `setRoot`. It is the responsibility of the client and watch-tower to verify / validate this.
@@ -335,7 +335,7 @@
 
 #### `getTradeableOrderWithSignature`
 
 A watch-tower calls the `getTradeableOrderWithSignature` method to get a discrete order that is tradeable on CoW Protocol:
 
 ```
 function getTradeableOrderWithSignature(    address owner,    IConditionalOrder.ConditionalOrderParams calldata params,    bytes calldata offchainInput,    bytes32[] calldata proof) external view returns (GPv2Order.Data memory order, bytes memory signature);
@@ -360,7 +360,7 @@
 
 ### Custom error codes
 
 * `ProofNotAuthed()` - the proof is not authorized (merkle root incorrect)
 * `SingleOrderNotAuthed()` - the single order is not authorized
 * `SwapGuardRestricted()` - the swap guard did not pass verification
 * `InvalidHandler()` - the handler is not a valid programmatic order

cow-protocol/reference/contracts/programmatic/twap.mdx

@@ -1,6 +1,6 @@
 ---
 title: "TWAP"
-description: "A simple  (TWAP) trade may be thought of as  smaller trades happening every  time interval, commencing at time . Additionally, it is possible to limit a part's validity of the order to a certain  of time interval ."
+description: "Reference for CoW Protocol TWAP orders — a programmatic order type that splits a trade into equal parts executed at regular intervals."
 ---
 
 ## Data Structure
@@ -25,7 +25,7 @@
 * `t` = 86400 (duration of each part, in seconds)
 * `span` = 0 (duration of `span`, in seconds, or `0` for entire interval)
 
 If Alice also wanted to restrict the duration in which each part traded in each day, she may set `span` to a non-zero duration. For example, if Alice wanted to execute the TWAP, each day for 30 days, however only wanted to trade for the first 12 hours of each day, she would set `span` to `43200` (ie. `60 * 60 * 12`).
 
 Using `span` allows for use cases such as weekend or week-day only trading.
 
@@ -39,7 +39,7 @@
    * `salt`: set to a unique value.
    * `staticInput`: the ABI-encoded `TWAP.Data` struct.
 
 2. Use the `struct` from (1) as either a Merkle leaf, or with `ComposableCoW.create` to create a single programmatic order.
 
 3. Approve `GPv2VaultRelayer` to trade `n x partSellAmount` of the safe's `sellToken` tokens (in the example above, `GPv2VaultRelayer` would receive approval for spending 12,000,000 DAI tokens).
 

cow-protocol/reference/core/auctions.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Auction mechanism"
-description: "CoW Protocol uses an implementation of the  for executing trades. Within a given auction, the goal is to compute prices and traded amounts to maximize a well-defined function, subject to a fairness constraint."
+description: "How CoW Protocol auctions compute prices and traded amounts to maximize a well-defined objective, subject to a fairness constraint."
 ---
 
 This can be formulated as a concrete optimization problem that needs to be solved, and this is where solvers come into play. Informally, a solver is an algorithm that takes as its input an auction instance and outputs a set of solutions (or bids), each corresponding to how it can best execute different combinations of orders in the batch. The solutions proposed by all solvers are then processed by the protocol, which selects (potentially multiple) winners according to a well-defined objective function.

cow-protocol/reference/core/auctions/accounting.mdx

@@ -1,6 +1,7 @@
 ---
 title: "Solver competition accounting process"
-description: "There is an accounting process in place for the solver competition. It is performed separately on each chain. Currently, the execution of the accounting process takes place once a week for all chains the protocol operates on, and each accounting week starts on Tuesday at midnight UTC and concludes a week later at midnight UTC. This accounting process consists of the following:"
+sidebarTitle: "Accounting"
+description: "Reference for the weekly accounting process used to settle the CoW Protocol solver competition on each chain, including timing and outputs."
 ---
 
 * calculation of total rewards/penalties, as specified by the [mechanism](/cow-protocol/reference/core/auctions/rewards);
@@ -15,7 +16,7 @@
 
 In each accounting week, we first identify all auctions that took place within that week. Specifically:
 
 * we identify all blocks with a timestamp that is at least as large as the starting Tuesday, 00:00 UTC timestamp and strictly smaller than the ending Teusday, 00:00 UTC timestamp ([this Dune query](https://dune.com/queries/3333356) does exactly this computation). Let \[X,Y] denote this interval;
 * we then look at all auctions whose block deadline (i.e., the latest block for which the on-chain submission is considered valid/on-time) is larger or equal than X and smaller or equal than Y, and these are the auctions for which we compute rewards for that particular accounting week.
 
 At the end of each accounting week, for each solver, the rewards and penalties are aggregated, and we have a performance reward per solver; note this can be negative in the case where penalties exceed rewards. The reward, naturally expressed in the native token, for each auction can be found in this Dune table: [https://dune.com/queries/4351957](https://dune.com/queries/4351957) (see `capped_payment` column).
@@ -24,7 +25,7 @@
 
 We stress that performance rewards and quote rewards are kept separate in the accounting.
 
 We also highlight that performance and quote rewards are both paid in COW. To convert rewards from the native currency to COW, we use the average COW price, in USD, as provided in the `prices.usd` Dune table, where the blockchain is set to Ethereum, so as to ensure that this price is always available. The average is taken over the last 24h of the accounting period, in order to reduce the possibility of manipulating that price (see [here](https://github.com/cowprotocol/dune-queries/blob/6ee39f14eb74fee770fe9b79ceef7b18fc5e5dba/cowprotocol/accounting/rewards/main_rewards_dashboard_query_2510345.sql#L57) for the Dune sql code that does this specific calculation). The native token's average price in USD is also computed similarly (see [here](https://github.com/cowprotocol/dune-queries/blob/6ee39f14eb74fee770fe9b79ceef7b18fc5e5dba/cowprotocol/accounting/rewards/main_rewards_dashboard_query_2510345.sql#L64)). Once these two prices are available, the conversion from native token to COW and vice versa is straightforward.
 
 ## Protocol and partner fees
 
@@ -56,7 +57,7 @@
 
 In this section, we share a few details about how protocol/partner/network fees are computed by observing an on-chain execution. When it comes to protocol and partner fees, one needs to be aware of the fee policies associated with an order. These fee policies are shared with solvers as part of the auction instance sent to them, and are also revealed for each trade in the [Order Book API Reference](/cow-protocol/reference/apis/orderbook). This allows us to fully determine the protocol and partner fees associated with the order.
 
 To use an example, suppose that we have a sell order that sells 1 WETH and the user receives 3000 USDC. When checking the api, we might see the following:
 
 ```
     "executedProtocolFees": [      {        "policy": {          "surplus": {            "factor": 0.5,            "maxVolumeFactor": 0.01          }        },        "amount": "5000000",        "token": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"      }    ]
@@ -66,11 +67,11 @@
 
 Once we know how much is the protocol fee, we can add it to the amount received by the user, in case of a sell order, or subtract it from the sell amount of the trade, in case of a buy order, in order to compute what we call the "raw buy amount" (or "raw sell amount" respectively). Using this amount and the uniform clearing price vector the solver proposed in its execution, we can now identify the network fee the solver charged the user.
 
 To elaborate a bit on the above, we clarify that for each transaction, a solver is required to report a uniform clearing price vector as part of the calldata, meaning a vector that has one price per token traded, as well as custom prices on a per trade basis. These custom prices allow a solver to capture fees, whenever needed. The uniform clearing price vector is meant to describe the exchange rates in the absence of fees. So once we have the raw sell/buy amount, we can apply the uniform clearing price vector and see how much the user "would" have sold if there was no network fee charged. The difference between what the user actually sold and what they would have sold in case of zero network fees exactly identifies how much was the network fee charged to the trade.
 
 Going back to our example, suppose the solver charged 0.001 WETH for the above trade. This means that the solver received 1 WETH, kept 0.001 WETH aside, and then swapped 0.999 WETH for 3005 USDC. The solver then realized that the protocol fee is 5 USDC, and thus kept 5 USDC aside, while returning 3000 USDC to the user. The uniform clearing prices, since they capture the exchange rate in the absence of fees, would then be set as follows: ucp(WETH) = 3005 and ucp(USDC) = 0.999. While the custom trade prices would be set to p(WETH) = 3000 and p(USDC) = 1.
 
 From the actual on-chain execution, as we mentioned, one can reverse-engineer the solver's execution and determine using the fee policies that the protocol fee is 5 USDC. Which means that the raw buy amount is equal to 3005 USDC. By observing the calldata, we recover the UCP vector, and apply the exchange rate implied by that vector, which gives that the user "should" have sold 3005 \* 0.999 / 3005 = 0.999 WETH. Since the user actually sold 1 WETH, we then conclude that the difference, i.e., 1 - 0.999 = 0.001 WETH, was the network fee the solver charged for the trade.
 
 ### Slippage
 
@@ -112,7 +113,7 @@
 function payOverdraft(address solver) external payable;
 ```
 
 To check an overdraft, call `solverOverdraftBalance` with the solver address. To pay it off, call `payOverdraft` with the solver address and attach the desired payment as `msg.value` in wei.
 
 <Note>
   Solvers should monitor their overdraft status regularly. Accumulated overdrafts reduce future payouts and, if left unaddressed, can significantly delay reward distributions. The [solver rewards Dune dashboard](https://dune.com/cowprotocol/cow-solver-rewards) can be used to track current balances and outstanding overdraft amounts.

cow-protocol/reference/core/auctions/ebbo-rules.mdx

@@ -1,11 +1,11 @@
 ---
 title: "EBBO violations: details"
-description: "In this section, we will elaborate on the details about what consistutes an EBBO violation, and what actions are taken by the DAO in case such a violation occurs. The content of this section is based on ."
+description: "What constitutes an EBBO violation on CoW Protocol and the actions CoW DAO takes when a solver triggers one."
 ---
 
 ## Certificate of EBBO violation
 
 A certificate for an EBBO violation consists of a reference routing on a block (and log index) between the start of the auction and when the settlement happened onchain. A reference routing for a trade at a given block (and index) is an execution of that trade which only uses liquidity from base protocols and routes through base tokens (see the "Base protocols and tokens" section [here](/cow-protocol/reference/core/auctions/competition-rules) for the definition of base protocols and base tokens). The surplus received by users in this routing is used as reference surplus. The difference between the reference surplus and the surplus actually received by the user is the size of the EBBO violation. This amount needs to be reimbursed to a user.
 
 A certificate for an EBBO violation can be challenged by the solver who is accused of the EBBO violation by providing a different block (and index), within 72 hours of the notification of the violation. In this case, a reference routing on this block (and index) might be proposed by the core team and used as certificate instead. The new certificate, if any, cannot be challenged again.
 

cow-protocol/reference/core/auctions/rewards.mdx

@@ -1,13 +1,13 @@
 ---
 title: "Solver rewards"
-description: "The protocol is currently subsidizing the solver competition on all chains it operates on, by rewarding solvers on a weekly basis (currently, every Tuesday) with rewards paid in COW. Solvers are rewarded based on their performance as solvers (i.e., when participating in the standard solver competition) as specified by , , ,  ,  and . Solver rewards for participating in the price estimation competition and providing quotes that are needed for the gas estimates and limit price computations of market orders are specified in , , , and ."
+description: "Reference for how CoW Protocol rewards solvers weekly in COW tokens, covering both the standard solver competition and the price estimation competition."
 ---
 
 <Note>
   For the interested reader, the main source of truth for the weekly payments to solvers is this [Dune dashboard](https://dune.com/cowprotocol/cow-solver-rewards). The dashboard is populated with data aggregated by scripts within the [solver-rewards](https://github.com/cowprotocol/solver-rewards) repository.
 </Note>
 
 ## Solver competition rewards (CIPs 20, 36, 38, 48, 57, 67, 74)
 
 Solver rewards are computed using a mechanism akin to a Vickrey–Clarke–Groves mechanism (a generalization of a second-price auction to combinatorial auctions). First, each solver proposes multiple solutions. Each solution contains a price vector and a list of trades to execute, which can be used to compute the solution's score. The protocol then selects the winning solutions (and winning solvers) using a fair combinatorial auction, which first filters out the solutions deemed unfair and then selects the combination of fair solutions that maximizes the total score of the auction (see [here](/cow-protocol/reference/core/auctions/competition-rules#off-chain-protocol) for more details).
 
@@ -18,7 +18,7 @@
 The payment to the winning solver $i$ is
 
 $$
 \text{payment}_i = \text{cap}(\text{totalScore} - \text{referenceScore}_i - \text{missingScore}_i)
 $$
 
 Here $\text{totalScore}$ is the sum of the scores of all winning solutions in the auction and $\text{missingScore}_i$ is the sum of the scores of solver $i$'s winning solutions that reverted. Finally, $\text{referenceScore}_i$ is the total score of a counterfactual auction in which all bids from solver $i$ are removed from the set of bids that survive the fairness filtering.
@@ -29,18 +29,18 @@
 
 The payment is capped from above and below using the function $\text{cap}(x) = \max(-c_l, \min(c_u, x))$, where $c_u$ is the protocol fee (excluding partner fees) that the protocol earned from the trades in all solutions supplied by the solver in that auction and $c_l$ is chain-specific, determined by the following values:
 
 * Ethereum mainnet, Arbitrum, and Base chain: 0.010ETH
 * Gnosis Chain: 10xDAI
 * Avalanche: 0.3AVAX
 * Polygon: 30POL
 * BNB: 0.04BNB
 * Linea and Ink: 0.0015ETH
 * Plasma: 30XPL
 
 If only one solver submits solutions, $\text{referenceScore}_i$ is, by definition, zero.
 
 <Note>
   There is no guarantee that the per-auction rewards are greater than the costs of executing a transaction (due to, for example, gas costs). 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 costs such as gas.
 </Note>
 
 ### Buffer accounting
@@ -57,7 +57,7 @@
 
 With respect to optimal bidding, note that the protocol rewards allow a solver to participate in an auction without misreporting the score they can generate (net of expected costs). This is easy to see if the cap is not binding, and misreporting does not affect $\text{referenceScore}_i$. Then, by reducing the reported score of a solution, solver $i$ does not affect its payoff if this solution is among the winners (which only shifts from protocol rewards to positive slippage), while reducing the probability that this solution is a winner. It is therefore a dominant strategy to bid truthfully.
 
 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. The filtering step of the fair combinatorial auction also makes this problem more complex, because there are some edge cases in which by reducing the score of a solution, solver $i$ can benefit by making the filtering steps less stringent for its opponents (see [here](https://forum.cow.fi/t/combinatorial-auctions-from-theory-to-practice-via-some-more-theory-about-rewards/2877) for a discussion). 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, truthfully revealing the (cost-adjusted) score that a solver can generate for each submitted solution is optimal if the cap is not binding, and misreporting does not affect $\text{referenceScore}_i$. It is not necessarily optimal in uncompetitive auctions when the difference between the best and second-best solution may be large, and in some edge cases in which a solver may benefit from making the filtering step less stringent. 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 - at the time of writing (November 2025) the cap on rewards is binding only in about 9% of auctions - and that a solver benefits by making the filtering steps less stringent for its opponents only in sporadic cases.
 
@@ -71,7 +71,7 @@
 
 This means:
 
 - **Small order economics**: For a \$1,000 trade at 2 bps protocol fee, the maximum reward is approximately \$0.20 — often insufficient to cover gas costs on Ethereum mainnet. Solvers must account for execution costs in their score adjustments.
 - **Bidding implications**: When the cap is binding, the mechanism shifts from second-price to first-price dynamics. A solver cannot benefit from truthful bidding beyond the cap, so the incentive to maximize user surplus is reduced for capped auctions.
 - **Practical strategy**: Solvers should factor the reward cap into their cost-adjusted scores. If the expected reward (after caps) does not cover expected execution costs, a rational solver will not include that order in their solution.
 
@@ -80,7 +80,7 @@
 When a winning solution reverts on-chain, the solver incurs a penalty based on the reference score (the best alternative solution that was available). Key considerations:
 
 - **Asymmetric evaluation**: The winning solver's score is measured after actual settlement, but the reference score is treated optimistically — it assumes the second-best solver would have succeeded. In practice, when market conditions cause one solver to revert, there is a high probability (~80% based on historical data) that other solvers would also revert on the same auction.
 - **Penalty caps**: The lower cap $c_l$ limits the maximum penalty per auction (e.g., 0.01 ETH on mainnet). This bounds worst-case losses but still creates meaningful risk for solvers operating on thin margins.
 - **Optimal bidding under revert risk**: A solver with success probability $p$ and potential surplus $S$ should discount their bid to account for revert risk. The optimal bid considering penalties is approximately $\max(p \times S, \; S - \frac{1-p}{p} \times c_l)$, where $c_l$ is the penalty cap. For example, a solver generating \$100 surplus with 90% success probability and a \$20 penalty cap should bid approximately \$97.77.
 - **Protocol-induced vs. solver-induced failures**: Not all reverts are the solver's fault — market conditions can change between bid submission and settlement. The protocol is working toward faster auction cycles (targeting one auction per block) to minimize this window.
 
@@ -97,27 +97,27 @@
 For ongoing discussion of these mechanics and their evolution, see the [CoW Forum Technical category](https://forum.cow.fi/c/tech-spells/2). Key threads include discussions on [CIP-74's impact on small orders](https://forum.cow.fi/t/second-price-auction-is-broken-for-small-orders-since-cip-74/3317), [penalty mechanics](https://forum.cow.fi/t/how-penalties-affect-bidding-of-solvers/3341), and [revert scenarios](https://forum.cow.fi/t/thoughts-about-second-price-auction-in-case-of-reverts/3309).
 </Note>
 
 ## Price estimation competition rewards (CIPs 27, 36, 57, 72)
 
 The price estimation competition is a separate competition where solvers provide the best response to a quote request. Quote requests look almost identical to single-order batch auctions, where there is only one order with a trivial limit price, and solvers propose executions of this order with the goal to maximize "out amount minus gas costs" in the case of a sell request, or minimize "in amount + gas costs" in the case of a buy request.
 
 As specified in [CIP-27](https://snapshot.org/#/cow.eth/proposal/0x64e061568e86e8d2eec344d4a892e4126172b992cabe59a0b24c51c4c7e6cc33), [CIP-36](https://snapshot.org/#/cow.eth/proposal/0x4e58f9c1208121c0e06282b5541b458bc8c8b76090263e25448848f3194df986) [CIP-57](https://snapshot.box/#/s:cow.eth/proposal/0x46d4fea1492207cf400fcb7a01141a7d4c730791d658cc77236941fc9eb7dccb), and [CIP-72](https://snapshot.box/#/s:cow.eth/proposal/0xc1b1252f0c99126b4e09730022faa31a7bb58073a3dc064c19b74d44164c39a7), a solver that provides the best quote to an order that is then submitted is rewarded if and only if all of the following conditions are satisfied:
 
 1. The order is a fill-or-kill market order;
 2. The quote is verified (i.e., its calldata successfully simulated in the autopilot);
 3. The order was executed (not necessarily by the quoting solver);
 4. The solver that provided the winning quote during order creation proposed an execution of the order (in at least one auction) that is at least as good as the quote, and that execution was not filtered out by the fairness filtering of the fair combinatorial auction mechanism.
 
 The current rewards for eligible quotes are as follows:
 
 * Ethereum mainnet: $\min\{0.0007 \text{ ETH}, 6 \text{ COW}\}$
 * Gnosis Chain: $\min\{0.15 \text{ xDAI}, 6 \text{ COW}\}$
 * Arbitrum: $\min\{0.00024 \text{ ETH}, 6 \text{ COW}\}$
 * Base Chain: $\min\{0.00024 \text{ ETH}, 6 \text{ COW}\}$
 * Avalanche-C Chain: $\min\{0.006 \text{ AVAX}, 6 \text{ COW}\}$
 * Polygon Chain: $\min\{0.6 \text{ POL}, 6 \text{ COW}\}$
 * BNB Chain: $\min\{0.001 \text{ BNB}, 6 \text{ COW}\}$
 * Linea: $\min\{0.00003 \text{ ETH}, 6 \text{ COW}\}$
 * Plasma: $\min\{0.6 \text{ XPL}, 6 \text{ COW}\}$
 * Ink: $\min\{0.00003 \text{ ETH}, 6 \text{ COW}\}$
 

cow-protocol/reference/core/auctions/the-problem.mdx

@@ -1,6 +1,7 @@
 ---
 title: "What is solving? A mathematical, high-level description"
-description: "At a high level, a solver is an algorithm that takes as inputs the orders that are valid for an auction, the state of the liquidity sources that the solver can access, the rules set by the protocol (including those specifying the protocol fees), and returns one or multiple solutions, where a solution selects a subset of the orders valid in an auction and specifies feasible in and out amounts for each of those orders. The solutions proposed by each solver during a given auction are the outcome of a two-step optimization problem: optimal routing and then optimal bidding."
+sidebarTitle: "What is solving?"
+description: "A mathematical, high-level description of solving on CoW Protocol: how solvers take orders and liquidity as input and output optimal routing and bidding solutions."
 ---
 
 In this section, we describe mathematically the different components of the "solving" problem. We discuss optimal routing and optimal bidding [in the solvers' strategy section](/cow-protocol/reference/core/auctions/rewards#solvers-strategy).
@@ -21,7 +22,7 @@
 
 A *sell order* specifies a maximum sell amount of a given token $Y > 0$, a buy token $b$, and a limit price $\pi$, that corresponds to the worst-case exchange rate that the user is willing to settle for. The limit price can be specified explicitly (as in the case of limit orders) or derived from an underlying quote and a slippage tolerance parameter (as in the case of market orders).
 
 Sell orders can be fill-or-kill which means that the executed sell amount must be $Y$ (or nothing). They can be partially fillable which means that the executed sell amount can be smaller or equal to $Y$. Formally, if $x$ denotes the (proposed) buy amount and $y$ denotes the (proposed) sell amount of the order, a fill-or-kill limit sell order has the form
 
 $$
 S = \left\{ \begin{bmatrix} x \\ -y \end{bmatrix} \text{ s.t. } \frac{y}{\pi} \leq x \text{ and } y \in \{0, Y\} \right\}
@@ -98,11 +99,11 @@
 Solvers propose solutions to the protocol, where a solution is a set of trades to execute. Formally, suppose there are $I$ users and CoW AMM orders and $J$ external liquidity sources. A solution is a list of trades $\{o_1, o_2, \ldots, o_I, l_1, l_2, \ldots, l_J\}$ for each user, CoW AMM pool and external liquidity source such that:
 
 * **Incentive compatibility and feasibility**: the solution respects the orders' acceptance set.
 * **Uniform directional clearing prices**: all users trading the same token pair in the same direction must face the same prices. Importantly, this constraint is defined at the moment when the swap occurs. So, for example, suppose user $i$ receives $x$ units of token 1 in exchange for $y$ units of token 2 and that the protocol takes a fee in the sell token $f_2$. Define $p_{1,2} = \frac{x}{y - f_2}$ as the price at which the swap occurs. Uniform directional clearing prices means that $p_{1,2}$ is the same for all users buying token 1 and selling token 2. Deviations from uniform directional prices are allowed to account for the extra gas cost of orders triggering hooks.
 * [**All other competition rules**](/cow-protocol/reference/core/auctions/competition-rules): These are a set of principles that solvers should follow, which were voted by CIPs.
 
 <Warning>
   At CoW DAO's discretion, systematic violation of these rules may lead to penalizing or slashing of the offending solver.
 </Warning>
 
 From the protocol viewpoint, each solution that satisfies the above constraints has a *score* that is given by the total surplus generated and the fees paid to the protocol, all aggregated and denominated in some numéraire. More specifically, the score of a solution is equal to the sum of scores of the orders the solution proposes to execute, where the score of an order $o$ is defined as:

cow-protocol/reference/core/definitions.mdx

@@ -1,5 +1,6 @@
 ---
 title: "Definitions"
+description: "Glossary of core CoW Protocol terms — intents, orders, solvers, auctions, batches, and settlement vocabulary used across the documentation."
 ---
 
 #### Intent
@@ -26,13 +27,13 @@
 
 The difference between the quote the user received and the price at which their discrete order was settled.
 
 #### Gasless
 
 An expression that does not require a user to make a transaction on the blockchain, and therefore does not require the user to pay gas in the native token.
 
 #### EBBO
 
 Ethereum Best Bid and Offer. The highest bid price and lowest ask (offered) price for a token, sourced from among well known DEXs (Uniswap, Sushiswap, Balancer) as defined by the rules of the solver competition.
 
 #### Internal buffers
 

cow-protocol/reference/core/intents/hooks.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Hooks"
-description: "The  allows users to request the solvers to execute user-defined Ethereum calls (also known as an \"inner/internal transaction\") before and after the execution of an order in a settlement."
+description: "How CoW Protocol hooks let users request solvers to execute user-defined Ethereum calls before and after an order is settled."
 ---
 
 ## Specification
@@ -11,11 +11,11 @@
 
 Each hook is described by three parameters:
 
 * `target`: the target address of the Ethereum call.
 
   Using implementing EIP-2612 approvals as an example, this would be the token contract.
 
 * `callData`: the data of the Ethereum call.
 
   In the example above, the ABI-encoded function call to `permit`.
 
@@ -23,7 +23,7 @@
 
   An order quote uses this value to estimate the total fee needed to execute an order. The more gas needed, the higher fee will be needed for the order to be settled.
 
   If the call requires more gas than specified here, the Ethereum call in the hook will be internally reverting *but the order will be executed regardless*.
 
 <Note>
   When placing *partially fillable* orders with hooks, **pre-hooks will only be executed on the first fill**. Therefore, your hook should ensure that the liquidity is sufficient for the entire order to be filled. On the other hand, **post-hooks are executed on every fill**.
@@ -33,7 +33,7 @@
 
 Orders are linked to hooks through the [app data](/cow-protocol/reference/core/intents/app-data).
 
 As long as the full appdata with hook information is included when posting the order to the [orderbook API](/cow-protocol/reference/apis/orderbook), the order will be stored with hook information included and settlements using this order will include its pre and post hooks.
 
 ## Call context
 
@@ -74,7 +74,7 @@
     Create your first hook step-by-step using CoW Swap
   </Card>
   <Card title="Hook Store" icon="store" href="/cow-swap/hooks/hook-store">
     Browse pre-built hooks or publish your own hook dApp
   </Card>
   <Card title="Post-Hook Examples" icon="arrow-right" href="/cow-swap/hooks/post-hook-examples">
     End-to-end swap → stake, bridge, and deposit examples

cow-protocol/reference/core/signing-schemes.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Signing schemes"
-description: "As CoW Protocol handles user's orders that were provided off-chain, the authenticity of a user's order needs to be asserted. Authenticity is asserted by the user  their order. A user may be an EOA or a smart contract."
+description: "Reference for the signing schemes CoW Protocol uses to authenticate off-chain orders from EOAs and smart contract wallets."
 ---
 
 ## Order digest
@@ -34,7 +34,7 @@
 To encode the order into the order digest, the [`EIP-712`](https://eips.ethereum.org/EIPS/eip-712#specification) specification is used:
 
 ```
 orderDigest = keccak256("\x19\x01" ‖ domainSeparator ‖ hashStruct(orderStruct))
 ```
 
 The components are:
@@ -70,18 +70,18 @@
 import {  Order,  OrderBalance,  OrderKind,  domain,  hashOrder} from "@cowprotocol/contracts"// Define an orderconst order: Order = {  sellToken: "0x6b175474e89094c44da98b954eedeac495271d0f", // dai  buyToken: "0xdef1ca1fb7fbcdc777520aa7f396b4e015f497ab", // cow  sellAmount: "10000000000000000000000000", // 10m dai  buyAmount: "10000", // 10k cow  validTo: 1704067200,  appData: "0xc85ef7d79691fe79573b1a7064c19c1a9819ebdbd1faaab1a8ec92344438aaf4", // keccak256("cow")  feeAmount: "0",  kind: OrderKind.SELL,  partiallyFillable: false,  sellTokenBalance: OrderBalance.ERC20,  buyTokenBalance: OrderBalance.ERC20,};// hash the order to generate the order digestconst digest = hashOrder(domain(1, "0x9008D19f58AAbD9eD0D60971565AA8510560ab41"), order);// output the digestconsole.log(`Order digest: ${digest}`)
 ```
 
 ### Etherscan Example
 
 For convenience, we also deployed a small helper contract that makes it easy to compute order uids as well as their full encoding for each chain using the Etherscan UI:
 
 * [Ethereum](https://etherscan.io/address/0xe84dcd8587287b997f51299430a396ad03aaec06/#readContract#F1)
 * [Gnosis](https://gnosisscan.io/address/0xCA51403B524dF7dA6f9D6BFc64895AD833b5d711/#readContract#F1)
 * Base N/A
 * Arbitrum N/A
 * Avalanche N/A
 * Polygon N/A
 * BNB N/A
 * Linea N/A
 * Plasma N/A
 * Ink N/A
 * [Sepolia](https://sepolia.etherscan.io/address/0x59Ffd6c1823F212D49887230f155A35451FdDbfa/#readContract#F1)
@@ -90,7 +90,7 @@
 
 CoW Protocol supports four different signing schemes. These signing schemes are summarized in the following table:
 
 | **Signing Scheme**                                                            | **Gasless** | **EOA** | **Smart Contract** |
 | ----------------------------------------------------------------------------- | ----------- | ------- | ------------------ |
 | [`eth_sign`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_sign) | ✅           | ✅       | ❌                  |
 | [`EIP-712`](https://eips.ethereum.org/EIPS/eip-712)                           | ✅           | ✅       | ❌                  |
@@ -105,7 +105,7 @@
 
 ### `eth_sign`
 
 This signature type is the most commonly supported signing mechanism for EOAs.
 
 The signature is computed as:
 
@@ -118,11 +118,11 @@
 * `ethSign`, using the user's private key to ECDSA-sign a message prefixed with `"\x19Ethereum signed message:\n"` and its length
 * `orderDigest`, the order digest
 
 Most Ethereum libraries support `ethSign` signatures ([ethers-js](https://docs.ethers.io/v5/api/signer/#Signer-signMessage), [web3py](https://web3py.readthedocs.io/en/stable/web3.eth.html?highlight=sign#web3.eth.Eth.sign)).
 
 ### `EIP-712`
 
 This signing method, also known as typed structured data signing, is the recommended signing method for EOAs, since the user will be able to see the full order data that is being signed in most wallet implementations.
 
 The signature is computed as:
 
@@ -135,7 +135,7 @@
 * `ecdsaSign`, using the user's private key to ECDSA-sign the message
 * `orderDigest`, the order digest
 
 Many Ethereum libraries have some degree of support for signing typed data without building the order digest by hand (for example [ethers-js](https://docs.ethers.io/v5/api/signer/#Signer-signTypedData), and [web3py](https://web3py.readthedocs.io/en/stable/web3.eth.html?highlight=sign_typed_data#web3.eth.Eth.sign_typed_data)).
 
 In any case, you may want to read about the [domain separator](https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator) and [encoding the order struct](#encoding).
 
@@ -150,7 +150,7 @@
 ```
 
 <Check>
   When submitting an `ERC-1271` order to the API, the `from` field **MUST** be set to the address of the smart contract that will be signing the order. This is because the `ERC-1271` signature is not an Ethereum signature, and thus the `from` field cannot be inferred from the signature.
 </Check>
 
 The components are:
@@ -185,7 +185,7 @@
 ```
 
 <Check>
   When submitting a `PreSign` order to the API, the `from` field **MUST** be set to the address of the order owner. This is because the `PreSign` signature is not an Ethereum signature, and thus the `from` field cannot be inferred from the signature.
 </Check>
 
 <Note>

cow-protocol/reference/core/tokens.mdx

@@ -1,16 +1,16 @@
 ---
 title: "Supported tokens"
-description: "CoW Protocol supports  tokens. However, not all  token contracts are created equal, despite the idea of a standard interface. Some contracts introduce issues, such as fee on transfer or lockup periods, which make them unsuitable."
+description: "Which ERC-20 tokens CoW Protocol supports — and which token behaviors (fee-on-transfer, lockups, rebasing) cause incompatibility."
 ---
 
 ## Requirements
 
 For a token to be considered tradeable on CoW Protocol, it **MUST**:
 
 * Be [`ERC-20`](https://eips.ethereum.org/EIPS/eip-20) compliant
 * Have a valid price provided by a *price estimator* for an order worth **0.1 ETH** of the token (For Ethereum mainnet and Arbitrum One)
 * Have a valid price provided by a *price estimator* for an order worth **1 xDAI** of the token (For Gnosis)
 * The most reliable way to meet the above requirements is to bootstrap a direct liquidity pool with the appropriate native token for the chain(e.g., a WETH\<>TOKEN pool on Univ2 for Ethereum mainnet) with at least the minimum liquidity required to support price estimation as described above
 * Not be on the bad token list
 
 <Note>
@@ -21,7 +21,7 @@
 
 ### Price estimators
 
 Price estimators are a subset of solvers that are used to determine the value of a token and are able to quote trades. These services themselves may have dependencies / limitations. The best way to ensure a token is tradeable is to bootstrap a Uni v2 (or some other well-known AMM) pool with the token, as these should get indexed by most price estimators. Some of the AMMs that are automatically indexed are UniswapV2, Honeyswap, SushiSwap, BalancerV2 (different weighted and stable pool versions), Baoswap, Swapr, UniswapV3.
 
 ### Bad token list
 
@@ -29,7 +29,7 @@
 
 ## New `ERC-20` tokens
 
 Have you created a new `ERC-20` and want to make it seemlessly tradeable on CoW Protocol?
 
 * Bootstrap a Uni v2 (or some other well-known AMM) pool with the token (and it's minimum viable liquidity)
 * Reach out to solvers to let them know about the best liquidity source and how they can integrate it

cow-protocol/reference/sdks/cow-sdk.mdx

@@ -1,5 +1,6 @@
 ---
 title: "CoW SDK"
+description: "Reference for the CoW SDK — the official TypeScript library for integrating with CoW Protocol's orderbook, signing, and trading flows."
 hidden: true
 ---
 
@@ -15,17 +16,17 @@
 
 The SDK supports all CoW Protocol enabled networks:
 
 * **Ethereum** (1) - `SupportedChainId.MAINNET`
 * **Gnosis Chain** (100) - `SupportedChainId.GNOSIS_CHAIN`
 * **Arbitrum One** (42161) - `SupportedChainId.ARBITRUM_ONE`
 * **Base** (8453) - `SupportedChainId.BASE`
 * **Polygon** (137) - `SupportedChainId.POLYGON`
 * **Avalanche** (43114) - `SupportedChainId.AVALANCHE`
 * **BNB** (56) - `SupportedChainId.BNB`
 * **Linea** (59144) - `SupportedChainId.LINEA`
 * **Plasma** (9745) - `SupportedChainId.PLASMA`
 * **Ink** (57073) - `SupportedChainId.INK`
 * **Sepolia** (11155111) - `SupportedChainId.SEPOLIA` (Testnet)
 
 ## 🔗 **Related Resources**
 
@@ -141,7 +142,7 @@
 **Customize or disable** via `advancedSettings.appData.metadata.utm`:
 
 ```
 // Custom UTMawait sdk.getQuote(parameters, {  appData: {    metadata: {      utm: { utmContent: 'my-integration-v2' }    }  }})// Disable UTMawait sdk.getQuote(parameters, {  appData: {    metadata: {      utm: {}    }  }})
 ```
 
 > **Note:** Providing any `utm` field gives you full control - the SDK will not add defaults.
@@ -173,7 +174,7 @@
 ### Installation
 
 ```
 # For ethers v6pnpm add @cowprotocol/sdk-ethers-v6-adapter ethers# For ethers v5pnpm add @cowprotocol/sdk-ethers-v5-adapter ethers@^5.7.0# For viempnpm add @cowprotocol/sdk-viem-adapter viem
 ```
 
 ### Adapter Setup Examples
@@ -193,7 +194,7 @@
 #### ViemAdapter
 
 ```
 import { ViemAdapter } from '@cowprotocol/sdk-viem-adapter'import { http, createPublicClient, privateKeyToAccount } from 'viem'import { sepolia } from 'viem/chains'const account = privateKeyToAccount('YOUR_PRIVATE_KEY' as `0x${string}`)const transport = http('YOUR_RPC_URL')const provider = createPublicClient({ chain: sepolia, transport })// You can also set `walletClient` instead of `signer` using `useWalletClient` from wagmiconst adapter = new ViemAdapter({ provider, signer: account })
 ```
 
 ## Low-Level SDK Usage Example

cow-protocol/tutorials/cow-amm-deployer.mdx

@@ -1,6 +1,6 @@
 ---
 title: "CoW AMM Deployer"
-description: "The  is a user-friendly Safe App that simplifies the process of deploying and managing  (Automated Market Makers) from Safe wallets. It enables users without programming skills to take advantage of the benefits of CoW AMM."
+description: "Use the CoW AMM Deployer Safe App to deploy and manage CoW AMM pools from a Safe wallet — no programming required."
 ---
 
 The app was developed by [bleu](https://github.com/bleu-fi) with sponsorship from the [CoW Grants DAO](https://grants.cow.fi/).
@@ -17,12 +17,12 @@
 
 ## Prerequisites
 
 Before using the CoW AMM Deployer, ensure that you have the following:
 
 1. A Safe wallet: If you don't have one, follow these steps to create a new Safe wallet:
 
    * Go to the [Safe website](https://app.safe.global/welcome) and click on "Create new Safe".
    * Choose the network (e.g., Ethereum) and the number of required confirmations.
    * Add the owners of the Safe wallet and set the threshold for confirmations.
    * Review and create the Safe wallet.
 
@@ -32,16 +32,16 @@
 
 ## Creating an AMM
 
 To create a new CoW AMM using the deployer, follow these steps:
 
 1. Access the CoW AMM Deployer app from your Safe wallet.
 
 2. On the homepage, click on the "Create AMM" button.
 
 3. Fill in the required information in the AMM creation form:
 
    * **Token Pair**: Select the token pair you want to provide liquidity for. Both tokens should already be in your Safe wallet.
    * **Price Oracle**: Choose the price oracle (e.g., Balancer, Uniswap V2) to provide price hints to the watch-tower about your CoW AMM. Enter the pool identifier used by the selected protocol. You can also load this information from the protocol subgraph using the provided button. If the button fails, it means there isn't a pool with at least $1000 USD of TVL for that token pair.
    * **Minimum Trade Amount**: Specify the minimum amount of the first token required for each trade. For most tokens, this value is automatically filled. If not, a strategy may be to calculate the equivalent of $10 USD in the first token.
    * **Fallback Handler**: If your wallet is unsupported, upgrade to a Safe with the special fallback handler. [Learn all about the new Safe Extensible Fallback Handler](https://blog.cow.fi/all-you-need-to-know-about-cow-swaps-new-safe-fallback-handler-8ef0439925d1) and its relevance to Safe in this [overview](https://help.safe.global/en/articles/40838-what-is-a-fallback-handler-and-how-does-it-relate-to-safe). Naturally, the upgrade process has undergone [extensive auditing](https://github.com/cowprotocol/composable-cow/tree/ab3addad9bc05acdbf5fb040eb5c336209b58e31/audits) for increased peace of mind.
 
@@ -82,13 +82,13 @@
 
 ### Frequently Asked Questions
 
 1. **Can I create multiple CoW AMMs with the same Safe wallet?**
 
    * No.
 
 2. **What happens to my tokens when I stop an AMM LP position?**
 
    * When you stop an AMM LP position, your tokens in your Safe will no longer be used to provide liqudity. As the CoW AMM **IS** the Safe when there is an active CoW AMM, the liquidity never leaves your Safe wallet! You can then withdraw or use them for other purposes.
 
 3. **Can I change the token pair of an existing AMM?**
 
@@ -100,15 +100,15 @@
 
 **You may also deploy a CoW AMM through the Balancer UI using [this guide.](https://cow.fi/learn/how-to-create-a-lvr-protected-liquidity-pool-on-cowamm)**
 
 The proposed transactions and interactions can be executed through any smart contract or EOA transaction builder, Etherscan "Write Contract," from other UI mechanisms, or directly from the console.
 
 ### Factory Contract Addresses
 
 * Ethereum Mainnet: [`0xf76c421bAb7df8548604E60deCCcE50477C10462`](https://etherscan.io/address/0xf76c421bAb7df8548604E60deCCcE50477C10462#code)
 * Gnosis Chain: [`0x703Bd8115E6F21a37BB5Df97f78614ca72Ad7624`](https://gnosisscan.io/address/0x703Bd8115E6F21a37BB5Df97f78614ca72Ad7624#code)
 * Arbitrum One: [`0xE0e2Ba143EE5268DA87D529949a2521115987302`](https://arbiscan.io/address/0xe0e2ba143ee5268da87d529949a2521115987302#code)
 * Base: [`0x03362f847B4fAbC12e1Ce98b6b59F94401E4588e`](https://basescan.org/address/0x03362f847b4fabc12e1ce98b6b59f94401e4588e#code)
 * Sepolia Testnet: [`0x1E3D76AC2BB67a2D7e8395d3A624b30AA9056DF9`](https://sepolia.etherscan.io/address/0x1E3D76AC2BB67a2D7e8395d3A624b30AA9056DF9#code)
 
 These contracts can be verified through [this](https://github.com/balancer/cow-amm) repository.
 
@@ -117,10 +117,10 @@
 1. Call the `newBPool` function of the factory contract. An example transaction can be found [here](https://etherscan.io/tx/0x7543a97853827e267ecd3c1309509ac7704e4f85a53fbfacd6060f461d85bad8#eventlog). The `LOG_NEW_POOL` log reveals the address of the newly created pool.
 
 <Note>
   In case ABI of the factory contract is not fetched, the ABI from the Sepolia network can be used.
 </Note>
 
 2. Approve the tokens by calling `approve()` on the relevant ERC-20 token contract, with the "spender" set to the newly created BPool address.
 
 <Warning>
   Take the token's decimals into account when setting the correct approval amount.
@@ -128,7 +128,7 @@
 
 3. Bind the approved tokens to the pool using the `bind()` function of the pool contract. One bind per token. The `denorm` parameter should always be set to `1000000000000000000` (10^18).
 
 4. Set the swap fee by calling `setSwapFee()` on the pool contract. The fee is specified in wei (10^17 = 10%).
 
 <Note>
   To guarantee full LVR protection, set the fee to 100% (technically up to 99.99%).