Hybrid swap should default to a price-optimal pool/book split

leonardocolucci commented

2026-07-27 14:35:41 +00:00

(Migrated from gitlab.com)

Summary

The hybrid pool/book split is chosen by the caller, not solved for. TradeMarketOrderPanel exposes a useHybridBook toggle plus a manually typed bookInputHuman, and the pair contract's hybrid_simulation takes pool_input / book_input as given. Nothing computes the split that actually maximises the taker's return_amount.

The practical effect on columbus-5 mainnet is that the limit book receives almost no flow: 12 of the 13 venue trades since 2026-07-19 were pool-only (book_input = 0). Takers get a worse price than they could, and makers get close to zero fills, which in turn discourages anyone from posting book liquidity at all.

Evidence

The one book leg in that window (tx C9785A0CE66FEF698B671FF078A3D286F51827ECB4353453D47DCD7DFFA83E85, 2026-07-22) used a split that was worse than pool-only: 94.779 vs 95.168 CORAL for 100 EMBER. So even when a user does opt in, the manual control can make their fill worse.

Measured today on EMBER/CORAL (terra1klwuxas6x7p6fjde60kq70t0hu86wvt3fvyr2vgs0nn32fnv0q4qwznwp4) via hybrid_simulation, selling 100 EMBER, sweeping book_input with max_maker_fills: 10:

book_input   return_amount (CORAL)
  0 EMBER    95.167670      <- what takers actually submit
  5 EMBER    95.196424
 10 EMBER    95.224711
 15 EMBER    95.228720
 20 EMBER    95.232037      <- optimum, +0.068% vs pool-only
 25 EMBER    95.211540
 30 EMBER    95.189889
 35 EMBER    94.908681
 40 EMBER    94.796331

The curve is single-peaked: routing too little to the book leaves maker liquidity unused, routing too much walks past it into worse resting orders. The optimum is interior, so neither of the two values a user is likely to pick by hand (0, or the full amount) is close to right.

At smaller sizes the gap is larger — for a 10 EMBER sell, book-first returns 9.565380 vs 9.525202 pool-only, +0.422% for the taker.

Suggested change

Default the panel to solving for the split rather than asking for it: bisect (or ternary-search) book_input over [0, offer_amount] against hybrid_simulation and submit the maximiser. The response is monotone enough that a handful of probes converges, and the simulation is already being called for the quote.

Keeping the manual bookInputHuman control behind an advanced/expert toggle would preserve the current behaviour for anyone who wants it.

Why it matters beyond price improvement

Maker participation is gated on fill probability. As long as book routing is opt-in and hand-sized, resting liquidity is close to unfillable regardless of how competitively it is priced, so the book stays thin, so opting in stays unattractive. Making the split automatic is what breaks that loop — and it matters most at the moment a real token lists, when there is genuine volume to route.

Found while running a market-making bot against the soft-launch pools. Happy to share the sweep script or re-run it on other pairs if useful.

## Summary The hybrid pool/book split is chosen by the caller, not solved for. `TradeMarketOrderPanel` exposes a `useHybridBook` toggle plus a manually typed `bookInputHuman`, and the pair contract's `hybrid_simulation` takes `pool_input` / `book_input` as given. Nothing computes the split that actually maximises the taker's `return_amount`. The practical effect on columbus-5 mainnet is that the limit book receives almost no flow: **12 of the 13 venue trades since 2026-07-19 were pool-only** (`book_input = 0`). Takers get a worse price than they could, and makers get close to zero fills, which in turn discourages anyone from posting book liquidity at all. ## Evidence The one book leg in that window (tx `C9785A0CE66FEF698B671FF078A3D286F51827ECB4353453D47DCD7DFFA83E85`, 2026-07-22) used a split that was *worse* than pool-only: 94.779 vs 95.168 CORAL for 100 EMBER. So even when a user does opt in, the manual control can make their fill worse. Measured today on EMBER/CORAL (`terra1klwuxas6x7p6fjde60kq70t0hu86wvt3fvyr2vgs0nn32fnv0q4qwznwp4`) via `hybrid_simulation`, selling 100 EMBER, sweeping `book_input` with `max_maker_fills: 10`: ``` book_input return_amount (CORAL) 0 EMBER 95.167670 <- what takers actually submit 5 EMBER 95.196424 10 EMBER 95.224711 15 EMBER 95.228720 20 EMBER 95.232037 <- optimum, +0.068% vs pool-only 25 EMBER 95.211540 30 EMBER 95.189889 35 EMBER 94.908681 40 EMBER 94.796331 ``` The curve is single-peaked: routing too little to the book leaves maker liquidity unused, routing too much walks past it into worse resting orders. The optimum is interior, so neither of the two values a user is likely to pick by hand (0, or the full amount) is close to right. At smaller sizes the gap is larger — for a 10 EMBER sell, book-first returns 9.565380 vs 9.525202 pool-only, **+0.422%** for the taker. ## Suggested change Default the panel to solving for the split rather than asking for it: bisect (or ternary-search) `book_input` over `[0, offer_amount]` against `hybrid_simulation` and submit the maximiser. The response is monotone enough that a handful of probes converges, and the simulation is already being called for the quote. Keeping the manual `bookInputHuman` control behind an advanced/expert toggle would preserve the current behaviour for anyone who wants it. ## Why it matters beyond price improvement Maker participation is gated on fill probability. As long as book routing is opt-in and hand-sized, resting liquidity is close to unfillable regardless of how competitively it is priced, so the book stays thin, so opting in stays unattractive. Making the split automatic is what breaks that loop — and it matters most at the moment a real token lists, when there is genuine volume to route. --- Found while running a market-making bot against the soft-launch pools. Happy to share the sweep script or re-run it on other pairs if useful.

leonardocolucci commented

2026-07-31 17:34:19 +00:00

(Migrated from gitlab.com)

Two weeks of maker-side data from mainnet that bear directly on this, including the first book legs the venue has taken.

On 2026-07-28 I moved a resting ladder on EMBER/CORAL (terra1klwuxas6x7p6fjde60kq70t0hu86wvt3fvyr2vgs0nn32fnv0q4qwznwp4) inside the pool's 180bps band, so every rung was strictly better than the AMM touch on both sides. Two things followed.

The book-crossing route works, and takers who use it gain. Two swaps have crossed the book since:

tx	time (UTC)	offer	return	book leg	pool leg
`71C06267E93AE3BBFB5234FF2D8FF2FB77AC2A2EEA42F700DF5AADA741F07C66`	2026-07-29 05:55:45	100 EMBER	95.043998 CORAL	17.858056	77.185942
`B0F2EDDB5ACFE2ADE5B6D835F490A033B78DE8730CEBFD76734756161E9CB4BF`	2026-07-30 11:13:41	100 EMBER	94.792604 CORAL	17.805559	76.987045

Both from terra1smg8tks5g68u7umhvlcf8d232uru7wecqgkh8z. That same address made five earlier swaps on the pair, all with book_return_amount = 0 -- correctly, because until 07-28 my rungs sat outside the fee band and the pool really was the better price. First trade after the ladder moved inside the band, it crossed. So the router does consult the book and does prefer it when it is genuinely better.

But the behaviour is per-caller, and the callers that skip the book pay for it. On the same pair, 2026-07-29 11:22:15Z, tx A8F9E3F92C18F5EB9ED3D0538E36E07F680B0258BA666DCDF5A6AD039719B1D2 from terra1rf4u54vh3m6qvd3crwrzwjw3s0ysat7a308c0p offered 50 EMBER and returned 47.437778 CORAL with book_return_amount = 0 -- an effective 0.94876. Reconstructing from my own order records, at that point I had bids resting at 0.961439 / 0.956608 / 0.951777 with roughly 28.98 CORAL of aggregate depth, all unfilled and later cancelled on TTL. That is up to ~1.34% better for the first ~30 EMBER of their order, left on the table. A third sender, terra1vadedjw2d9vrpy57hgpg69g78w94dghgrsys84 (tx 8AE8F7A13B6A0E2416E98C62DF7F99D1B1AB97B5C4281FFBFC7A66DF21ACC46E, 25 EMBER), also took pool-only.

So the split is not just theoretically suboptimal -- on this pair it is currently the difference between two callers getting ~1% better fills and three callers not. Which one you get appears to depend on the path, not on the prices.

Two things this adds to the original report:

The interior optimum in the sweep above is not hypothetical any more. There is now real resting depth inside the band for a solver to find, and when it gets found the taker measurably wins.
Worth confirming which path the dex.cl8y.com UI takes by default. If the pool-only callers above are the UI, then every retail swap on the venue is skipping available book liquidity and the fix here is worth roughly a percent per trade to users. If they are a bespoke bot, this is narrower -- but then the UI default is the thing to check, not the thing to assume.

Happy to run the hybrid_simulation sweep again against current depth if that would help size the change.

Two weeks of maker-side data from mainnet that bear directly on this, including the first book legs the venue has taken. On 2026-07-28 I moved a resting ladder on EMBER/CORAL (`terra1klwuxas6x7p6fjde60kq70t0hu86wvt3fvyr2vgs0nn32fnv0q4qwznwp4`) inside the pool's 180bps band, so every rung was strictly better than the AMM touch on both sides. Two things followed. **The book-crossing route works, and takers who use it gain.** Two swaps have crossed the book since: | tx | time (UTC) | offer | return | book leg | pool leg | |---|---|---|---|---|---| | `71C06267E93AE3BBFB5234FF2D8FF2FB77AC2A2EEA42F700DF5AADA741F07C66` | 2026-07-29 05:55:45 | 100 EMBER | 95.043998 CORAL | 17.858056 | 77.185942 | | `B0F2EDDB5ACFE2ADE5B6D835F490A033B78DE8730CEBFD76734756161E9CB4BF` | 2026-07-30 11:13:41 | 100 EMBER | 94.792604 CORAL | 17.805559 | 76.987045 | Both from `terra1smg8tks5g68u7umhvlcf8d232uru7wecqgkh8z`. That same address made five earlier swaps on the pair, all with `book_return_amount = 0` -- correctly, because until 07-28 my rungs sat outside the fee band and the pool really was the better price. First trade after the ladder moved inside the band, it crossed. So the router does consult the book and does prefer it when it is genuinely better. **But the behaviour is per-caller, and the callers that skip the book pay for it.** On the same pair, 2026-07-29 11:22:15Z, tx `A8F9E3F92C18F5EB9ED3D0538E36E07F680B0258BA666DCDF5A6AD039719B1D2` from `terra1rf4u54vh3m6qvd3crwrzwjw3s0ysat7a308c0p` offered 50 EMBER and returned 47.437778 CORAL with `book_return_amount = 0` -- an effective 0.94876. Reconstructing from my own order records, at that point I had bids resting at 0.961439 / 0.956608 / 0.951777 with roughly 28.98 CORAL of aggregate depth, all unfilled and later cancelled on TTL. That is up to ~1.34% better for the first ~30 EMBER of their order, left on the table. A third sender, `terra1vadedjw2d9vrpy57hgpg69g78w94dghgrsys84` (tx `8AE8F7A13B6A0E2416E98C62DF7F99D1B1AB97B5C4281FFBFC7A66DF21ACC46E`, 25 EMBER), also took pool-only. So the split is not just theoretically suboptimal -- on this pair it is currently the difference between two callers getting ~1% better fills and three callers not. Which one you get appears to depend on the path, not on the prices. Two things this adds to the original report: 1. The interior optimum in the sweep above is not hypothetical any more. There is now real resting depth inside the band for a solver to find, and when it gets found the taker measurably wins. 2. Worth confirming which path the `dex.cl8y.com` UI takes by default. If the pool-only callers above are the UI, then every retail swap on the venue is skipping available book liquidity and the fix here is worth roughly a percent per trade to users. If they are a bespoke bot, this is narrower -- but then the UI default is the thing to check, not the thing to assume. Happy to run the `hybrid_simulation` sweep again against current depth if that would help size the change.

PlasticDigits commented

2026-08-05 01:32:37 +00:00

(Migrated from gitlab.com)

Thanks for the detailed mainnet sweeps and follow-up — very useful.

Follow-up: since you mentioned running your own market-making / taker bots, are those bots calling GET /api/v1/route/solve (indexer best-execution split), or are they declaring pool_input / book_input themselves (direct pair hybrid_simulation / swap, or POST /route/solve with hybrid_by_hop)? Knowing which path your bots use would clarify how much of the pool-only fill gap is UI vs integrator defaults.

Evaluation summary

Agreed on the goal: default market tickets should submit a price-optimal pool/book split, not a hand-sized one. Preferred approach:

Use the existing indexer GET solver as the default for trade/market quoting (ADR 0002: 17-point book_input grid + coordinate descent). Pattern C stays caller-declared on-chain; the solver fills in the params off-chain.
Do not put split search on-chain — walking/searching splits inside execute would be too gas-expensive and unpredictable vs today’s bounded book walk + declared split.
Avoid a second client-side ternary/bisect over LCD hybrid_simulation in the panel — that would duplicate the indexer solver, add LCD load/latency, and risk quote≠submit drift. Finer continuous search (if needed later) belongs in the indexer only.
Manual bookInputHuman can stay behind Advanced / POST override for integrators who want a fixed split.

The maker flywheel point stands: as long as common taker paths skip competitive resting depth, books stay thin. Slippage (min_return / max_spread) remains the execute-time guard; auto-split is advisory like today’s GET path.

Frontend routes that do not default to the indexer GET solver

These are the dapp paths that skip GET /api/v1/route/solve best-execution (or only hit POST with a caller-fixed split):

/trade — market ticket (TradeMarketOrderPanel)
Always uses a caller-chosen split via quoteDirectHybridSwap → POST /route/solve with fixed hybrid_by_hop (LCD hybrid_simulation fallback). Empty book field defaults to 100% book (pool_input = 0), not an optimized interior split. Never calls getRouteSolve.
/ — Swap Advanced manual book leg (SwapPage + Settings hybrid)
When hybrid is on, the pair is direct CW20, and the user types a non-empty Book leg amount, quoting/submit use that fixed split (quoteDirectHybridSwap / POST) and override the GET solver for that quote.
/trade — hybrid toggle off
Pool-only pair simulateSwap / pool-only hybrid (book_input = 0); no GET solve.
/ — Swap GET failure / non-solver fallbacks
If getRouteSolve fails (or assets are outside the CW20 indexer path), Swap falls back to direct pair simulateSwap / multihop LCD — pool-oriented, not a fresh hybrid split search.

Contrast: default / Swap (hybrid on, empty manual book, CW20↔CW20) already uses getRouteSolve and therefore already searches for a return-maximizing split. Empty book on Swap means book_input = 0 before that GET path (solver may still allocate book); empty book on Trade means full book and never asks the solver — documented asymmetry in docs/limit-orders.md.

Likely fix direction (no code yet)

Unify /trade market with Swap’s default: quote via GET /route/solve, submit the solver’s hybrid params, keep manual split as Advanced. That matches your “default to solving” ask without on-chain search or a panel-local optimizer.

Thanks for the detailed mainnet sweeps and follow-up — very useful. **Follow-up:** since you mentioned running your own market-making / taker bots, are those bots calling `GET /api/v1/route/solve` (indexer best-execution split), or are they declaring `pool_input` / `book_input` themselves (direct pair `hybrid_simulation` / `swap`, or `POST /route/solve` with `hybrid_by_hop`)? Knowing which path your bots use would clarify how much of the pool-only fill gap is UI vs integrator defaults. ### Evaluation summary Agreed on the goal: **default market tickets should submit a price-optimal pool/book split**, not a hand-sized one. Preferred approach: - **Use the existing indexer GET solver as the default** for trade/market quoting (ADR 0002: 17-point `book_input` grid + coordinate descent). Pattern C stays caller-declared on-chain; the solver fills in the params off-chain. - **Do not put split search on-chain** — walking/searching splits inside execute would be too gas-expensive and unpredictable vs today’s bounded book walk + declared split. - **Avoid a second client-side ternary/bisect over LCD `hybrid_simulation`** in the panel — that would duplicate the indexer solver, add LCD load/latency, and risk quote≠submit drift. Finer continuous search (if needed later) belongs in the indexer only. - Manual `bookInputHuman` can stay behind Advanced / POST override for integrators who want a fixed split. The maker flywheel point stands: as long as common taker paths skip competitive resting depth, books stay thin. Slippage (`min_return` / `max_spread`) remains the execute-time guard; auto-split is advisory like today’s GET path. ### Frontend routes that do **not** default to the indexer GET solver These are the dapp paths that skip `GET /api/v1/route/solve` best-execution (or only hit POST with a caller-fixed split): 1. **`/trade` — market ticket** (`TradeMarketOrderPanel`) Always uses a caller-chosen split via `quoteDirectHybridSwap` → `POST /route/solve` with fixed `hybrid_by_hop` (LCD `hybrid_simulation` fallback). Empty book field defaults to **100% book** (`pool_input = 0`), not an optimized interior split. Never calls `getRouteSolve`. 2. **`/` — Swap Advanced manual book leg** (`SwapPage` + Settings hybrid) When hybrid is on, the pair is direct CW20, and the user types a non-empty **Book leg amount**, quoting/submit use that fixed split (`quoteDirectHybridSwap` / POST) and **override** the GET solver for that quote. 3. **`/trade` — hybrid toggle off** Pool-only pair `simulateSwap` / pool-only hybrid (`book_input = 0`); no GET solve. 4. **`/` — Swap GET failure / non-solver fallbacks** If `getRouteSolve` fails (or assets are outside the CW20 indexer path), Swap falls back to direct pair `simulateSwap` / multihop LCD — pool-oriented, not a fresh hybrid split search. **Contrast:** default **`/` Swap** (hybrid on, empty manual book, CW20↔CW20) already uses `getRouteSolve` and therefore already searches for a return-maximizing split. Empty book on Swap means `book_input = 0` *before* that GET path (solver may still allocate book); empty book on Trade means full book and never asks the solver — documented asymmetry in `docs/limit-orders.md`. ### Likely fix direction (no code yet) Unify **`/trade` market** with Swap’s default: quote via `GET /route/solve`, submit the solver’s hybrid params, keep manual split as Advanced. That matches your “default to solving” ask without on-chain search or a panel-local optimizer.

PlasticDigits commented

2026-08-05 01:35:59 +00:00

(Migrated from gitlab.com)

"Unify /trade market with Swap’s default: quote via GET /route/solve, submit the solver’s hybrid params, keep manual split as Advanced." is approved

"Unify **`/trade` market** with Swap’s default: quote via `GET /route/solve`, submit the solver’s hybrid params, keep manual split as Advanced." is approved

PlasticDigits commented

2026-08-05 01:47:25 +00:00

(Migrated from gitlab.com)

mentioned in commit ba891c373f

mentioned in commit ba891c373f5ee5de213b26b699e3fff7e45c7516

PlasticDigits commented

2026-08-05 01:48:28 +00:00

(Migrated from gitlab.com)

mentioned in merge request !1041

PlasticDigits commented

2026-08-05 01:48:37 +00:00

(Migrated from gitlab.com)

Implemented the approved scope only (leave issue open pending bot-runner path clarification):

MR: !1041 — unify /trade Market with Swap’s default: quote via GET /route/solve, submit solver hybrid params, keep manual split as Advanced.

Shared helper: frontend-dapp/src/utils/cw20RouteSolveQuote.ts
Trade Advanced: empty book = no override (not 100% book); typed book → POST
Docs/skills updated: docs/limit-orders.md, AGENTS_HYBRID_QUOTING.md, ADR 0002 amendment

Not in this MR: on-chain split search, client-side ternary over LCD hybrid_simulation, Trade useRouteSolveProgress wiring, or closing this issue.

Implemented the approved scope only (leave issue open pending bot-runner path clarification): **MR:** !1041 — unify `/trade` Market with Swap’s default: quote via `GET /route/solve`, submit solver hybrid params, keep manual split as Advanced. - Shared helper: `frontend-dapp/src/utils/cw20RouteSolveQuote.ts` - Trade Advanced: empty book = no override (not 100% book); typed book → POST - Docs/skills updated: `docs/limit-orders.md`, `AGENTS_HYBRID_QUOTING.md`, ADR 0002 amendment Not in this MR: on-chain split search, client-side ternary over LCD `hybrid_simulation`, Trade `useRouteSolveProgress` wiring, or closing this issue.

PlasticDigits commented

2026-08-05 01:53:10 +00:00

(Migrated from gitlab.com)

mentioned in commit 1ab04d6f58

mentioned in commit 1ab04d6f58af4dba001ff07d9723c41931607ec2

PlasticDigits commented

2026-08-08 11:12:22 +00:00

(Migrated from gitlab.com)

mentioned in commit 66b93245fa

mentioned in commit 66b93245fa6f7c444275fbb2b09f484e21541b6a

PlasticDigits commented

2026-08-08 11:12:22 +00:00

(Migrated from gitlab.com)

mentioned in commit 8da9f15e32

mentioned in commit 8da9f15e32a4f2cf653f714cc4ee87fab0ed265e

PlasticDigits (Migrated from gitlab.com) closed this issue

2026-08-08 11:12:30 +00:00

PlasticDigits commented

2026-08-08 11:12:37 +00:00

(Migrated from gitlab.com)

Verification complete (#501) — closed

Verified the approved scope (MR !1041 + follow-up on main @ 8da9f15): /trade Market defaults to indexer GET /api/v1/route/solve (same best-execution path as Swap), with Advanced manual split via POST and hybrid-off = pool-only.

What we did

Confirmed shared helper quoteCw20ViaRouteSolve is used by Swap + Trade market default.
Fixed Trade submit parity: apply hybridParamsWithSubmitCap to GET solver hybrid (matches Swap / #249 gas envelope).
Fixed stale E2E selector in fee-discount-quote-245.spec.ts (Advanced → trade-market-hybrid-toggle).
Added make verify-issue-501, Playwright e2e/trade-market-route-solve-501-tx.spec.ts, and docs/skills crosslinks.
Hardened deploy/postgres: host-psql probe + compose exec fallback; Phase 6.2 always writes full indexer/.env (keeps FACTORY_ADDRESS).

Verification checklist

Default Market (Advanced collapsed, empty book) quotes via GET /api/v1/route/solve (not POST)
Empty book is not 100% book / not a caller-declared override
Advanced typed book leg → POST /route/solve with fixed split
Advanced hybrid off → pool-only simulateSwap (no route/solve)
Submit uses solver hybrid from indexerOperations + hybridParamsWithSubmitCap
Unit: make verify-issue-501 (10/10)
Playwright: trade-market-route-solve-501-tx.spec.ts — 2 passed
Docs/skills/ADR crosslinks present

Note on bot-runner path (comment thread)

Reporter follow-up about maker/taker bots vs GET /route/solve remains an integrator question outside the approved retail UI scope. The venue UI path is now aligned with Swap’s GET default.

How to re-verify

make verify-issue-501
bash scripts/with-node.sh --cwd frontend-dapp -- \
  ./node_modules/.bin/playwright test e2e/trade-market-route-solve-501-tx.spec.ts --project=e2e-tx

## Verification complete (#501) — closed Verified the approved scope (MR !1041 + follow-up on `main` @ `8da9f15`): **`/trade` Market defaults to indexer `GET /api/v1/route/solve`** (same best-execution path as Swap), with Advanced manual split via `POST` and hybrid-off = pool-only. ### What we did - Confirmed shared helper `quoteCw20ViaRouteSolve` is used by Swap + Trade market default. - Fixed Trade submit parity: apply `hybridParamsWithSubmitCap` to GET solver hybrid (matches Swap / #249 gas envelope). - Fixed stale E2E selector in `fee-discount-quote-245.spec.ts` (Advanced → `trade-market-hybrid-toggle`). - Added `make verify-issue-501`, Playwright `e2e/trade-market-route-solve-501-tx.spec.ts`, and docs/skills crosslinks. - Hardened deploy/postgres: host-psql probe + compose exec fallback; Phase 6.2 always writes full `indexer/.env` (keeps `FACTORY_ADDRESS`). ### Verification checklist - [x] Default Market (Advanced collapsed, empty book) quotes via **GET /api/v1/route/solve** (not POST) - [x] Empty book is **not** 100% book / not a caller-declared override - [x] Advanced typed book leg → **POST /route/solve** with fixed split - [x] Advanced hybrid off → pool-only `simulateSwap` (no route/solve) - [x] Submit uses solver hybrid from `indexerOperations` + `hybridParamsWithSubmitCap` - [x] Unit: `make verify-issue-501` (10/10) - [x] Playwright: `trade-market-route-solve-501-tx.spec.ts` — 2 passed - [x] Docs/skills/ADR crosslinks present ### Note on bot-runner path (comment thread) Reporter follow-up about maker/taker bots vs GET /route/solve remains an integrator question outside the approved retail UI scope. The venue UI path is now aligned with Swap’s GET default. ### How to re-verify ```bash make verify-issue-501 bash scripts/with-node.sh --cwd frontend-dapp -- \ ./node_modules/.bin/playwright test e2e/trade-market-route-solve-501-tx.spec.ts --project=e2e-tx ```

PlasticDigits commented

2026-08-16 09:55:50 +00:00

(Migrated from gitlab.com)

mentioned in issue #533

leonardocolucci commented

2026-08-17 21:14:17 +00:00

(Migrated from gitlab.com)

Thanks for the thorough evaluation and for unifying /trade Market with the GET /route/solve path (!1041). Good outcome for makers and takers alike, and the verification write-up was very helpful.