The addon defines 71 dex* settings. The settings console renders a field for 34 of them. The other 37 are read by the server on every quote, every sweep and every indexer tick, and there is no screen in the product that shows you their value — which is the single most useful thing to know before you go looking for a control that does not exist.

The three doors

The Swap console sends only the keys you changed, so a key with no field is never included in a save and never overwritten by one. It also means a key with no field cannot be set from that screen — the API is the only door.

curl -X PUT https://your-host/api/admin/dex/settings \
  -H 'Content-Type: application/json' \
  -H 'Cookie: <your admin session>' \
  -d '{"dexDirectPoolMaxTradeToLiquidityBps": 50}'

The response names exactly what happened — updated, unchanged and ignored. A key you spelled wrong lands in ignored rather than being written, so a typo is loud instead of creating a row nothing reads.

The master switches

Fees

The fee defaults to 0 so a fresh install quotes on every chain. A chain with a fee above zero and no recipient refuses to quote unless you tick Run at zero fee on that chain; see Fees and revenue.

There is no dexFeeRecipient

There was, and it was deleted. The address that receives your fee is the feeRecipient column on the chain row, set in Admin → Swap → Chains, and it has no global fallback — with dexFeeBps above zero, a chain without one refuses to quote.

Two things short-circuit that refusal before the recipient is ever read. Run at zero fee (zeroFeeAcknowledged on the chain row) is checked first, before the fee setting is even looked at — an operator who ticked it has already answered the question, so the chain quotes at zero fee. And a pair routed DIRECT_ONLY never demands a recipient at all, because a raw AMM router has no integrator-fee parameter to carry one; that pair quotes on a chain with nothing set. Anything that reaches an aggregator refuses.

Two reasons the global key is gone, and the first is disqualifying: every settings row bar one is world-readable through the unauthenticated /api/settings, and a settings row is globally singular. One string cannot be both a Gnosis Safe on mainnet and an EOA on Base, and no fallback between those two is ever what you meant. The address is per-deployment state, so it lives beside the RPC override on the chain it belongs to.

If you find a dexFeeRecipient row in your settings table from an older install, nothing reads it. Delete it or leave it; either way, set the recipient per chain.

Slippage and price protection

Quotes

Token safety

dexScreeningSimulateTimeoutMs bounds the honeypot round trip, not the vendor call — that one is the provider's own timeout. A simulation that times out contributes nothing rather than failing the token: it can only ever make a verdict worse, never better, so an abandoned probe leaves the vendor's answer standing. Raising it above the default is reasonable on a busy archive endpoint; lowering it below a couple of seconds effectively turns simulation off without turning the switch off, which is the confusing version of the same outcome.

Router safety

Compliance

Execution and market data

The direct-pool half

Everything below governs the venue where your own money is the liquidity. It exists as a separate set of keys rather than a retune of the ones above for one reason: the global values govern pools you did not choose and do not profit from, and these govern a pool you chose, sized and earn the LP fee on. They must be able to differ without weakening the aggregator path.

None of the keys in this half has a field on any screen except dexDirectPoolsEnabled and dexPoolRiskAckRequired, which live on the console's Liquidity tab. The rest are set through the API.

The routing decision — dexVenuePolicy

Four values are legal globally:

The default is the most conservative policy that still delivers the point of the feature — pairs no aggregator will quote become tradable — while changing nothing for the majors. Turning direct pools on does not re-route WETH/USDC.

DIRECT_ONLY is a per-pair value and has no global form

There is a fifth value, and the settings PUT refuses it by name. Per pair, DIRECT_ONLY is a legitimate statement: this is my token, my pool, do not bother asking 0x. Globally it routes every pair — including the majors — through whatever pool happens to be bound, at a fill no user can see the cause of. There is no honest use for the global form, so it does not exist there.

Set it per pair instead: Admin → Swap → Listings → Pairs, the Routing column. Each pair holds INHERIT (the default, meaning "use the global value"), any of the four above, or DIRECT_ONLY. A pair set to DIRECT_ONLY with no bound pool is rejected by the model itself, because every quote on it would refuse with NO_ROUTE.

An unrecognised policy on a pair falls back to your global value rather than to a hardcoded default — your platform-wide choice is a better guess at your intent than anything the code could invent.

The direct-pool risk envelope

dexDirectPoolsEnabled is layer five of the kill-switch ladder and the first thing every quote checks — before any model query, before any RPC spend, so turning it off costs one boolean read. It also gates the pool indexer at boot. Off, a direct pool is not priced, not indexed, and a pair set to DIRECT_ONLY becomes unquotable by anything. Swaps already broadcast are still watched and settled either way; switching the venue off never strands a transaction.

The four gates, in the order they refuse

A direct candidate must clear all four before it can enter the race, and each refusal names both the threshold and what was observed:

The trade-to-liquidity cap is the load-bearing one, and it is not a duplicate of the impact ceiling. On a constant-product pool, impact is roughly trade size over reserves for small trades, so a 1% cap is about 100 bps of impact by construction — a structural bound that still holds when no impact figure can be computed at all. A swap at 2% of reserves has around 200 bps of impact, which is under a 300 bps warning and over the 1% ratio: refused here and nowhere else.

Two nulls are refusals rather than passes, and both directions matter:

• A pool whose reserves cannot be priced in USD refuses with POOL_TOO_SHALLOW. That is exactly the pool whose depth cannot be vouched for, so letting a null through would make the floor a no-op on precisely the tokens it was written to catch.
• A null price impact refuses with DIRECT_POOL_IMPACT_UNCOMPUTABLE. On an aggregator route an unreported impact is only a warning — a vendor not reporting a number is not evidence of anything. Here the platform holds the reserves itself, so a null is not "unreported", it is "degenerate".

The win margin prices a conflict of interest

netOut(aggregator) is net of your own integrator fee. netOut(direct) is net of nothing, because a raw AMM router has no fee hook to net — see Why a direct pool earns no swap fee. At a zero margin a direct pool wins any time it is within roughly your fee of the aggregator, and the platform routes away from its own revenue on a rounding difference, invisibly, on every trade.

Comparing gross output would fix that by routing users to a worse fill, which is the opposite of best execution. So the comparison is on net output — what the user actually receives — and a material margin is required before displacing a venue with third-party competition, MEV protection and a vendor SLA behind it.

Two details you will see in the quote log:

• The margin doubles when either side's net output could not be computed and the comparison drops to gross, because a gross comparison systematically flatters the venue with no fee — always the direct one.
• Exactly at the margin, the aggregator wins. The comparison is strict: the burden of proof sits on the venue displacing the incumbent.

Zero is accepted as a deliberate choice (best net output wins outright) and is not recommended, for the reason above. It is documented, not forbidden.

Slippage on a direct route

The effective ceiling is the lower of dexMaxSlippageBps and dexDirectPoolMaxSlippageBps, so setting the direct ceiling above the global one is not an error — it simply never binds.

The direction of the ceiling is the point: on a thin pool a wide tolerance is a standing, publicly visible invitation to sandwich for exactly that amount, because the attacker reads amountOutMin straight out of the mempool calldata. That is why the direct ceiling is 100 bps against the global 500.

There is no separate starting value on a direct route. Every quote starts from the slippage the user asked for, or from dexDefaultSlippageBps (50) when they asked for nothing, and a direct fill is then re-clamped down to the effective ceiling above. dexDirectPoolDefaultSlippageBps is defined, defaulted to 100 and refused on save when it sits above that ceiling — but no quote path reads it, so raising it widens nothing.

dexDirectPoolPrivateRpcRequired is inert

It is defined, defaulted, validated on save and read by nothing. There is no warning today when a direct-pool transaction is built against a public endpoint. Setting it changes no behaviour; treat the private-RPC decision as an infrastructure choice you make in Environment, not as something this switch enforces.

Pool verification freshness

Quoting a pool requires two independent facts, and they are deliberately not merged into one status: the lifecycle (state is ACTIVE — how far through create → seed → retire the pool is) and the trust axis (verifiedAt is fresher than dexPoolVerifyMaxAgeHours).

A stale verification stops the pool being quotable. It is not a warning badge. The refusal is POOL_VERIFICATION_STALE, and the pool goes on looking perfectly healthy on its own row — ACTIVE, seeded, with reserves — while every quote against it refuses. The same freshness check drives the poolVerified line on the pool readiness panel, so that panel is where you see it first.

The reason is that a verification is a claim about a moment. A factory can be superseded, a token row edited, a deployment removed from the registry. Treating a two-month-old proof as current is how a pool stays quotable after the fact that made it quotable stopped being true.

The pool indexer

The indexer turns a pool's own Swap logs into 1-minute candles, so a market whose chart comes from your pool has one. It runs on a single process behind a lease, and it does not arm at all while dexDirectPoolsEnabled is off.

What each one actually changes:

• dexPoolRefreshMs is two things at once — the interval the indexer timer fires at, and the length of the window each tick re-derives (plus a fixed five-minute overlap, so a log arriving at the edge of the previous pass still lands in its bucket). Lowering it makes charts fresher and multiplies your RPC bill; the indexer floors it at 30 seconds whatever you set.
• dexPoolIndexChunkBlocks is the size of one getLogs call. This is the one to lower when your provider returns "block range too large" — most public endpoints cap at 1000, some at 500. A chunk that fails is skipped rather than retried in a loop, and the next pass covers the hole.
• dexPoolIndexMaxBlocks bounds one pool's sweep, so a pool with a long unindexed history backfills across several passes instead of one enormous request.
• dexPoolIndexBootstrapBlocks only applies when the pool's creation block is not known. It is the floor the backfill starts from, counted back from the confirmed head. Too small and early history is silently missing; too large and a first pass walks blocks that contain nothing.

The reorg rewind is destructive, and deliberately so

The indexer never reads past head − requiredConfirmations, so a reorg shallower than the confirmation depth cannot touch an emitted candle — those blocks were never read. A deeper reorg is detected by re-reading the block the cursor sits on and comparing its hash.

When the hash has changed, the indexer rewinds dexPoolIndexReorgRewindBlocks blocks, deletes the recorded pool events above the rewind point, and re-derives the affected candles from scratch. It does not patch a bar in place: a partially corrected bar is indistinguishable from a correct one afterwards, so there would be no way to notice the difference later. The rewind is logged as a warning naming the pool and the block.

An unreadable block is not treated as a reorg. Treating an RPC hiccup as one would rewind and re-derive on every transient failure, which is an RPC bill and a churned cache for nothing.

Seeding your own pool

dexSeedSlippageBps is not swap slippage. It bounds how far the pool may have moved between the moment the console rendered your calldata and the moment your transaction mines. On a subsequent add the router recomputes the optimal ratio from live reserves and refunds the excess, so the minimums are real protection.

On a first add they are structurally meaningless. Uniswap V2 takes the reserveA == 0 && reserveB == 0 branch: nothing can revert, because there is no reference price to compare against, and the ratio you supply is the price. The console reports seedSlippageBps as null on a first add for exactly that reason, and the real protection there is the implied price rendered in both directions plus a typed confirmation of it — see Direct pools.

dexSeedMaxDeviationBps is the other half of that protection, and it only applies when both tokens have an independent price. Above it the plan refuses; the refusal is overridable, but only with a deliberate flag that costs a second confirmation in the console.

The LP-fee sweep floor

dexSweepMinValueUsd is real: the settlement cron leaves a swap-fee group unswept below it, so dust does not cost more in gas than it is worth, and an unpriced accrual counts as above the threshold rather than below — withholding a fee merely because it could not be priced would strand it indefinitely, which is the opposite of what a minimum is for.

dexLpFeeSweepMinValueUsd is its intended twin and is read by nothing. There is no LP-fee sweep to floor. On a V2 pool there structurally cannot be one: a burn returns principal and fees in one indistinguishable pair of transfers, and the only expressible number is fees minus impermanent loss, which is neither. On V3 the arithmetic exists, and the withdraw path still writes zero profit rows today. Setting this key changes no behaviour — see LP positions.

The five Super-Admin-only settings

dexEnabled, dexAllowlistMode, dexKycRequired, dexDirectPoolsEnabled and dexPoolRiskAckRequired require the Super Admin role — not a permission. edit.dex.settings is not enough, and the server re-resolves the role on every request rather than trusting anything the screen asserts.

A Super Admin gets a live control on the Swap console for four of the five, with a line underneath saying the role is why. The tile also names the role rather than the permission, because "why can I change this and my colleague cannot" is the next question and the permission that opened the screen is not the answer.

dexEnabled stays read-only even for a Super Admin, and the reason is structural rather than a policy choice: every page under Swap — including the settings console itself — stops answering while the master switch is off, so this screen can never be the place it is turned on. Offering an off-switch whose only effect is to close the console you are standing in is a trap, not a control. It lives in platform settings so there is always a screen to turn it back on from.

dexFeeBps is deliberately not in that set: an operator changing their own revenue share harms nobody but themselves. It is audited instead, and the audit trail carries the old and new value for that key specifically.

What a save refuses

The PUT applies one patch atomically and reports one violation, not a list: a patch is all-or-nothing, so the second violation is unreachable information until the first is fixed.

That last one is worth its own sentence. A provider name outside A–Z a–z 0–9 _ . - is nulled on read, and a null name resolves to the noop screener — which marks every token safe without checking it, with no critical log, on an install whose operator believes screening is on. A slug with a space in it is therefore worse than a typo, and this is the only place a human is present to be told.