From cb7701009bf4b14acc7bb5232c025a0444ad2ac1 Mon Sep 17 00:00:00 2001 From: Aryan Godara Date: Mon, 14 Sep 2026 15:45:45 +0530 Subject: [PATCH 1/5] docs: add fast-path orders documentation Signed-off-by: Aryan Godara --- .../concepts/how-it-works/flow-of-an-order.md | 2 + .../concepts/order-types/fast-path-orders.md | 76 +++++++++++++++++++ .../reference/core/intents/app_data.mdx | 2 +- 3 files changed, 79 insertions(+), 1 deletion(-) create mode 100644 docs/cow-protocol/concepts/order-types/fast-path-orders.md diff --git a/docs/cow-protocol/concepts/how-it-works/flow-of-an-order.md b/docs/cow-protocol/concepts/how-it-works/flow-of-an-order.md index d7ddc423f..1fbf0a932 100644 --- a/docs/cow-protocol/concepts/how-it-works/flow-of-an-order.md +++ b/docs/cow-protocol/concepts/how-it-works/flow-of-an-order.md @@ -24,3 +24,5 @@ The competition between solvers in a batch auction ensures that users (including 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. + +Most orders follow this batch-auction flow. One exception is a [fast-path order](../order-types/fast-path-orders), which settles out of competition right after placement instead of waiting for the next batch, trading some of the batch's benefits for a faster settlement. diff --git a/docs/cow-protocol/concepts/order-types/fast-path-orders.md b/docs/cow-protocol/concepts/order-types/fast-path-orders.md new file mode 100644 index 000000000..d62928754 --- /dev/null +++ b/docs/cow-protocol/concepts/order-types/fast-path-orders.md @@ -0,0 +1,76 @@ +--- +sidebar_position: 9 +description: Fast-path orders settle out of competition for faster execution. What they are, when to use them, and how to opt in. +--- + +# Fast-path orders + +On CoW Protocol, orders aren't settled one at a time. They're collected and +solved together in a batch auction: each cycle, the protocol gathers the orders +that are ready, solvers compete to settle the whole batch, and the winning +solution is submitted on-chain. Solving orders as a batch is what earns users +the best prices, since solvers can match trades directly against one another (a +[coincidence of wants](../how-it-works/coincidence-of-wants)) and compete on the +surplus they find. The tradeoff is time: putting a batch together +every cycle means an order waits for the next auction before it settles. + +But sometimes speed matters more than surplus. A user might want their order +filled as quickly as possible, still at a fair price with their limit respected, +without waiting for the whole auction cycle and the next batch to settle. That is +what a fast-path order is for. The limit price is still respected for settling the +order; they simply trade the extra surplus a batch can find for a faster settlement. + +A fast-path order reuses the quote the user already holds. Quotes go through +their own solver competition, and the winning quote is the one presented to the +user to sign. Once signed, that solver gets the exclusive right to settle the +order on-chain, using the solution it already produced, within a short window. + + +## The flow + +Fast path is decided at the quote stage, and the order settles in a few steps: + +1. The user requests a quote with fast path enabled. +2. Solvers compete for it, and the winning quote is returned to the user. +3. The user signs that quote and places the order. +4. The winning solver settles it directly, outside the batch, within a short + exclusivity window (the order's `validFrom`). +5. If the window passes without a settlement, the order joins the next batch + auction like any other order. + +`validFrom` (in the order's `appData`) is the timestamp from which an order may +enter a regular batch auction. For a fast-path order it doubles as the +exclusivity window: until `validFrom` passes, the order can only be settled +through the fast-path route. It is an independent field, while a value you set +is always respected. But even if you leave it blank, we'll still apply a default. + +## Enabling fast path + +Fast path is opt-in and changes nothing else about your order. Two things have to +line up: + +1. **You opt in.** Set `enableFastPath` in the order's + [`appData`](/cow-protocol/reference/core/intents/app-data). It is signed with + the order, so without it an order is never fast-pathed. +2. **A supporting solver wins the quote.** Set `fastPath` on your `/quote` + request. The order is fast-pathed only if the winning quote comes from a + solver that supports it, which the protocol works out during the quote. + +If both hold, the order is fast-pathed. Otherwise it settles through the normal +batch auction. The `fastPath` request field is in the +[Order Book API reference](/cow-protocol/reference/apis/orderbook). + +## Which orders can use fast path + +Fast path only fits orders that are ready to settle the moment they are placed. + +- **Market (fill-or-kill) orders.** Partially fillable orders are not fast-pathed. +- **No pre-signed or smart-contract (ERC-1271) orders.** Pre-signed and ERC-1271 + orders aren't ready to settle right after placement, so the fast path can't + complete before the window closes. +- **Place it against the fast-path quote you received, unchanged.** An order that + doesn't match a fast-path quote, for example one with a different limit price, + won't be fast-pathed and settles through the normal batch auction instead. + +If an order can't use fast path for any of these reasons, nothing breaks: it just +settles the normal way, through the batch auction. diff --git a/docs/cow-protocol/reference/core/intents/app_data.mdx b/docs/cow-protocol/reference/core/intents/app_data.mdx index d7959ec2f..a2607070a 100644 --- a/docs/cow-protocol/reference/core/intents/app_data.mdx +++ b/docs/cow-protocol/reference/core/intents/app_data.mdx @@ -51,4 +51,4 @@ If not using the CoW Explorer appData utility or the app-data SDK, make sure to The schema for the AppData document is defined in [JSON schema](https://json-schema.org/). The schema is available in the [app-data](https://github.com/cowprotocol/cow-sdk/blob/main/packages/app-data/README.md) SDK. The schema is shown below: - + From d67226fb1487a2655644661c2212f5798266c82a Mon Sep 17 00:00:00 2001 From: Aryan Godara Date: Tue, 15 Sep 2026 23:02:21 +0530 Subject: [PATCH 2/5] docs: note validFrom and fast path are mutually exclusive Signed-off-by: Aryan Godara --- .../concepts/order-types/fast-path-orders.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/cow-protocol/concepts/order-types/fast-path-orders.md b/docs/cow-protocol/concepts/order-types/fast-path-orders.md index d62928754..03a39abc5 100644 --- a/docs/cow-protocol/concepts/order-types/fast-path-orders.md +++ b/docs/cow-protocol/concepts/order-types/fast-path-orders.md @@ -34,15 +34,15 @@ Fast path is decided at the quote stage, and the order settles in a few steps: 2. Solvers compete for it, and the winning quote is returned to the user. 3. The user signs that quote and places the order. 4. The winning solver settles it directly, outside the batch, within a short - exclusivity window (the order's `validFrom`). + exclusivity window set by the protocol. 5. If the window passes without a settlement, the order joins the next batch auction like any other order. -`validFrom` (in the order's `appData`) is the timestamp from which an order may -enter a regular batch auction. For a fast-path order it doubles as the -exclusivity window: until `validFrom` passes, the order can only be settled -through the fast-path route. It is an independent field, while a value you set -is always respected. But even if you leave it blank, we'll still apply a default. +The exclusivity window on a fast-path order is set by the protocol, not by you. +`validFrom` and fast path are mutually exclusive: set `validFrom` (in the order's +`appData`) for a "wait for CoW" order that only becomes solvable at a time you pick, +or opt into fast path for out-of-competition settlement, but not both. A fast-path +order ignores `validFrom`. ## Enabling fast path From 6e1e9e320c5c7f69e07eb93a18634bb5e0ae6eb1 Mon Sep 17 00:00:00 2001 From: Aryan Godara Date: Tue, 6 Oct 2026 10:27:59 +0530 Subject: [PATCH 3/5] drop fastPath quote request field from fast-path orders Signed-off-by: Aryan Godara --- .../concepts/order-types/fast-path-orders.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/cow-protocol/concepts/order-types/fast-path-orders.md b/docs/cow-protocol/concepts/order-types/fast-path-orders.md index 03a39abc5..04e6825f8 100644 --- a/docs/cow-protocol/concepts/order-types/fast-path-orders.md +++ b/docs/cow-protocol/concepts/order-types/fast-path-orders.md @@ -52,13 +52,12 @@ line up: 1. **You opt in.** Set `enableFastPath` in the order's [`appData`](/cow-protocol/reference/core/intents/app-data). It is signed with the order, so without it an order is never fast-pathed. -2. **A supporting solver wins the quote.** Set `fastPath` on your `/quote` - request. The order is fast-pathed only if the winning quote comes from a - solver that supports it, which the protocol works out during the quote. +2. **A supporting solver wins the quote.** The order is fast-pathed only if the + winning quote comes from a solver that supports it, which the protocol works + out during the quote. If both hold, the order is fast-pathed. Otherwise it settles through the normal -batch auction. The `fastPath` request field is in the -[Order Book API reference](/cow-protocol/reference/apis/orderbook). +batch auction. ## Which orders can use fast path From 237347e9094062a84fb2f3f1e7d8223ba24853b4 Mon Sep 17 00:00:00 2001 From: Aryan Godara Date: Fri, 9 Oct 2026 12:25:06 +0530 Subject: [PATCH 4/5] address comments Signed-off-by: Aryan Godara --- .../concepts/how-it-works/flow-of-an-order.md | 2 +- .../concepts/order-types/fast-path-orders.md | 32 ++++++++++--------- 2 files changed, 18 insertions(+), 16 deletions(-) diff --git a/docs/cow-protocol/concepts/how-it-works/flow-of-an-order.md b/docs/cow-protocol/concepts/how-it-works/flow-of-an-order.md index 1fbf0a932..14f1d4973 100644 --- a/docs/cow-protocol/concepts/how-it-works/flow-of-an-order.md +++ b/docs/cow-protocol/concepts/how-it-works/flow-of-an-order.md @@ -25,4 +25,4 @@ The competition between solvers in a batch auction ensures that users (including 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. -Most orders follow this batch-auction flow. One exception is a [fast-path order](../order-types/fast-path-orders), which settles out of competition right after placement instead of waiting for the next batch, trading some of the batch's benefits for a faster settlement. +Most orders follow this fair combinatorial auction flow. One exception is a [fast-path order](../order-types/fast-path-orders), which settles out of competition right after placement instead of waiting for the next auction, trading some of the fair combinatorial auction's benefits for a faster settlement. diff --git a/docs/cow-protocol/concepts/order-types/fast-path-orders.md b/docs/cow-protocol/concepts/order-types/fast-path-orders.md index 04e6825f8..0ad3cc5ce 100644 --- a/docs/cow-protocol/concepts/order-types/fast-path-orders.md +++ b/docs/cow-protocol/concepts/order-types/fast-path-orders.md @@ -5,26 +5,28 @@ description: Fast-path orders settle out of competition for faster execution. Wh # Fast-path orders -On CoW Protocol, orders aren't settled one at a time. They're collected and -solved together in a batch auction: each cycle, the protocol gathers the orders -that are ready, solvers compete to settle the whole batch, and the winning -solution is submitted on-chain. Solving orders as a batch is what earns users -the best prices, since solvers can match trades directly against one another (a +On CoW Protocol, orders aren't settled one at a time. They are collected and +solved together in a fair combinatorial auction: in each auction, the protocol +gathers the orders that are ready, solvers compete for the best execution on each +directed token pair, and the winning solutions are submitted on-chain. Solving +orders within an auction is what earns users the best prices, since solvers can +match trades directly against one another (a [coincidence of wants](../how-it-works/coincidence-of-wants)) and compete on the -surplus they find. The tradeoff is time: putting a batch together -every cycle means an order waits for the next auction before it settles. +surplus they find. The tradeoff is time: putting a (batched) solution together +in every auction means an order waits for the next auction before it settles. -But sometimes speed matters more than surplus. A user might want their order -filled as quickly as possible, still at a fair price with their limit respected, -without waiting for the whole auction cycle and the next batch to settle. That is -what a fast-path order is for. The limit price is still respected for settling the -order; they simply trade the extra surplus a batch can find for a faster settlement. +But sometimes speed matters more than the potential benefits of batching. A user +might want their order filled as quickly as possible, still at a fair price with +their limit respected, without waiting for the whole auction cycle and the next +batch to settle. That is what a fast-path order is for. The limit price is still +respected for settling the order; they simply trade the extra surplus a fully +fledged auction can potentially provide for a faster settlement. A fast-path order reuses the quote the user already holds. Quotes go through their own solver competition, and the winning quote is the one presented to the -user to sign. Once signed, that solver gets the exclusive right to settle the -order on-chain, using the solution it already produced, within a short window. - +user to sign. Once signed, the solver that provided the winning quote gets the +exclusive right to settle the order on-chain, using the solution it already +produced, within a short window. ## The flow From 660126eb5938820e9947df544f5c9bafc2a63833 Mon Sep 17 00:00:00 2001 From: Aryan Godara Date: Sun, 11 Oct 2026 00:32:37 +0530 Subject: [PATCH 5/5] address review (auction terminology, validFrom wording, fast-path commitment) --- .../concepts/order-types/fast-path-orders.md | 30 ++++++++++--------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/docs/cow-protocol/concepts/order-types/fast-path-orders.md b/docs/cow-protocol/concepts/order-types/fast-path-orders.md index 0ad3cc5ce..f45501afd 100644 --- a/docs/cow-protocol/concepts/order-types/fast-path-orders.md +++ b/docs/cow-protocol/concepts/order-types/fast-path-orders.md @@ -18,7 +18,7 @@ in every auction means an order waits for the next auction before it settles. But sometimes speed matters more than the potential benefits of batching. A user might want their order filled as quickly as possible, still at a fair price with their limit respected, without waiting for the whole auction cycle and the next -batch to settle. That is what a fast-path order is for. The limit price is still +auction to settle. That is what a fast-path order is for. The limit price is still respected for settling the order; they simply trade the extra surplus a fully fledged auction can potentially provide for a faster settlement. @@ -35,16 +35,15 @@ Fast path is decided at the quote stage, and the order settles in a few steps: 1. The user requests a quote with fast path enabled. 2. Solvers compete for it, and the winning quote is returned to the user. 3. The user signs that quote and places the order. -4. The winning solver settles it directly, outside the batch, within a short +4. The winning solver settles it directly, outside of a standard auction, within a short exclusivity window set by the protocol. -5. If the window passes without a settlement, the order joins the next batch +5. If the window passes without a settlement, the order joins the next auction like any other order. -The exclusivity window on a fast-path order is set by the protocol, not by you. -`validFrom` and fast path are mutually exclusive: set `validFrom` (in the order's -`appData`) for a "wait for CoW" order that only becomes solvable at a time you pick, -or opt into fast path for out-of-competition settlement, but not both. A fast-path -order ignores `validFrom`. +The exclusivity window on a fast-path order is set by the protocol. +`validFrom` and fast path are mutually exclusive. `validFrom` sets when a regular +order becomes eligible to enter the auction cycle, whereas fast path settles +right after placement, so a fast-path order ignores `validFrom`. ## Enabling fast path @@ -54,12 +53,15 @@ line up: 1. **You opt in.** Set `enableFastPath` in the order's [`appData`](/cow-protocol/reference/core/intents/app-data). It is signed with the order, so without it an order is never fast-pathed. -2. **A supporting solver wins the quote.** The order is fast-pathed only if the - winning quote comes from a solver that supports it, which the protocol works - out during the quote. +2. **A fast-path-capable solver wins the quote.** Solvers choose whether to + support fast path, and a solver that can't settle quickly enough simply + doesn't offer fast-path quotes. A solver that does offer one is committing to + it: if that quote wins and you sign it, the solver must settle on-chain within + the window, and the protocol holds it accountable for doing so. If it doesn't, + the order falls back to the normal auction and nothing is lost. If both hold, the order is fast-pathed. Otherwise it settles through the normal -batch auction. +auction. ## Which orders can use fast path @@ -71,7 +73,7 @@ Fast path only fits orders that are ready to settle the moment they are placed. complete before the window closes. - **Place it against the fast-path quote you received, unchanged.** An order that doesn't match a fast-path quote, for example one with a different limit price, - won't be fast-pathed and settles through the normal batch auction instead. + won't be fast-pathed and settles through the normal auction instead. If an order can't use fast path for any of these reasons, nothing breaks: it just -settles the normal way, through the batch auction. +settles the normal way, through the auction.