For every route that involves V3 (and for the bridge amount of every route), the only slippage protection the transaction carries is quote - 0.5%, where quote is the revert payload of an eth_call sent to the unauthenticated public RPC (RPC_URL, with automatic failover to a second provider on HTTP 429/5xx in createRpcClient.post). quoteV3ExactIn (js/v4-arb-encoder.js:616-620) and quoteExactIn (js/v4-arb-encoder.js:1465) accept any well-formed revert payload; there is no cross-check against the tick price the page already holds from Swap logs or slot0, no lower bound relative to amountIn, and the user's min-out field defaults to 0 (index.html:177) so readAmounts (index.html:378) cannot raise the floor.

The dry run and send go through the wallet's RPC, but a swap with amountOutMinimum = 1 simulates successfully at the real price, so the dry run does not catch it. In auto mode the same RPC also supplies the Swap logs that produce the GREEN verdict, so one lying endpoint can both trigger the trade and strip its protection on every 30 s poll (the wallet still prompts for a signature, which an auto-mode operator is expecting to grant).

Expected: a quote that is inconsistent with the observed pool price, or a round-trip minimum below a sane fraction of amountIn, is refused.

Actual: it is accepted and encoded as the transaction's amountOutMinimum.

Fix: bound the accepted quote against the log/slot0-implied price (e.g. refuse when the quote-implied price deviates by more than a few percent from 1.0001^tick scaled by decimals) and refuse a round-trip minUsdgOut below usdgIn * (1 - 2*SLIPPAGE_BPS/10000) unless the operator explicitly opts into a lower floor.

quoteSpread (index.html:839-846) computes selected.finalQuote and selected.minimumReturn = finalQuote - 0.5% only when one leg is V3. For a V4/V4 spread selected.minimumReturn stays undefined, so readAmounts falls back to the min-out field whose default is 0 (index.html:177). routeSnapshot only rejects a zero minimum for routes with a V3 leg (js/v4-arb-encoder.js:2368), and prepareSwap/buildCalldata accept minUsdgOut = 0.

The result is a two-command transaction whose first swap is protected by the bridge minimum but whose second swap accepts any output, including 0.

Auto mode (maybeAutoExecute -> quoteSpread -> dryRun -> send) therefore fires on a GREEN verdict computed from two stale last-swap ticks and sends a round trip that can return far less currency1 than it spent: the sell pool's price may have moved since its last swap, it may be thin at the bridge size, and a sandwicher can take the whole second leg. showGasEstimate already quotes the sell leg for V4/V4 routes (index.html:794) but uses it for display only.

Expected (asymmetry with the V3 path and with buildAtomicCalldata, which refuses minUsdgOut < usdgIn): the sell quote minus slippage is enforced as the minimum for every route.

Actual: V4/V4 routes enforce no minimum unless the operator types one.

Fix: set selected.minimumReturn = applySlippage(finalQuote) for V4/V4 routes too (the quote already exists), and have routeSnapshot/prepareSwap refuse minUsdgOut == 0 for every route, not only V3 ones.

The page grants approvals on three surfaces: (a) approveRouteV3 -> token.approve(V3_ROUTER, 100 * amount) for every V3 leg's input token, which per routeApprovals (js/v4-arb-encoder.js:2376-2380) is currency1 for a V3 buy and currency0 (100 x bridge amount) for a V3 sell in a V4->V3 mixed route; (b) approveRoutePermit2/approveBothPermit2 -> Permit2.approve(token, ROUTER, 100 * amount, now + 30 days) for currency1 and currency0; (c) it relies on, but never grants, the ERC20 allowance of each token to Permit2. revokeAll (js/v4-arb-encoder.js:2618-2644) only zeroes currency1.approve(V3_ROUTER, 0) and currency1.approve(PERMIT2, 0).

After REVOKE ALL the wallet still carries: currency0 -> SwapRouter02 at 100 x bridge (page-granted, surface a), Permit2 -> Universal Router for currency0 and currency1 up to 100 x amounts for 30 days (page-granted, surface b), and currency0 -> Permit2 (prerequisite).

The README's justification ('with the ERC20 allowance at 0 the router cannot pull anyway') holds only for currency1 via Permit2; it does not cover the currency0 ERC20 allowance to SwapRouter02, which is fully live. The button's name and status text ('allowances revoked ... Approvals are needed again before the next swap') claim completeness the code does not deliver.

Fix: iterate both pair tokens in revokeAll, and for each also call Permit2.approve(token, ROUTER, 0, 0) when readPermit2 shows a non-zero amount (the README already documents that call as the revocation).

sendRoute sets prepared = null on entry and, for a mixed route, sends transactions[0] (leg 1), waits for its receipt, then checks balance/deadline/allowance, simulates and sends transactions[1]. Every failure after firstReceipt (leg-2 eth_call revert because the price moved below minUsdgOut, deadline passed while the operator approved the wallet prompt, receipt timeout, wallet rejection) throws and leaves the wallet holding ponsAmount+ of currency0.

The page then offers no way to re-quote and submit only leg 2 against the held bridge balance: prepareRoute always calls routeTransactions, which for a mixed route always builds leg 1 first (js/v4-arb-encoder.js:2458-2466), and sendRoute always submits transactions[0]. A retry therefore buys a second bridge amount before attempting to sell the first; the TRANSFER buttons move whole balances to another wallet but do not sell.

The README documents 'leg 1 cannot be rolled back' but not that the page cannot finish the route.

Expected: after a confirmed leg 1 the page can re-quote the sell leg for the held bridge amount and submit leg 2 alone (same deadline/allowance checks).

Actual: the operator must unwind with an external tool or accept a second leg 1.

Fix: keep the confirmed leg-1 context (bridge amount actually received, sell pool, deadline) and expose a 'retry leg 2' path that rebuilds only transactions[1] with a fresh sell quote and minimum.

handle accepts any POST whose body parses as a JSON-RPC object or array (validPayload), forwards it unchanged to Blockmachine and on 429/5xx to dRPC, and answers with access-control-allow-origin: *. There is no origin allow-list, no method allow-list (eth_sendRawTransaction, debug_, trace_ are forwarded), no per-client rate limit and no shared secret.

Once deployed and pointed to by RPC_URL, the URL is public in the served page, so a third party can drive the operator's provider rate limits to exhaustion. Because the page itself falls back on 429, the attacker's traffic also forces the page onto the fallback provider, which is the trust-expansion the RPC-trust review flags above.

Expected: the Worker serves only the operator's page and the read-only method set the page needs.

Actual: it relays anything from anywhere.

Fix: restrict access-control-allow-origin to the page's origin, allow-list the JSON-RPC methods the page uses (eth_call, eth_getLogs, eth_getBlockByNumber, eth_gasPrice, eth_chainId), and apply a per-IP rate limit (Cloudflare rate limiting rule or Workers KV counter).

Quotes come from createRpcClient() (RPC_URL, silently retried against RPC_FALLBACK_URL on 429/5xx at js/v4-arb-encoder.js:1321; the page never shows which endpoint answered). quoteExactIn() trusts the revert data verbatim (decodeQuoteRevert, js/v4-arb-encoder.js:1443) and quoteV3ExactIn() trusts the V3QuoteResult revert (js/v4-arb-encoder.js:617-620). The quote alone sets bridgeAmount (swap 1's amountOutMinimum and swap 2's amountIn) and, for V3 routes, minimumReturn.

The simulation and send go through the wallet's provider, which only checks that the transaction does not revert, so an under-stated quote passes every guard: the transaction is valid, just unprotected. An over-stated quote fails closed (revert), so the exploitable direction is 'too small'.

For V4/V4 the min-out field defaults to 0 (documented as a small-amount test), so after a deflated buy quote the transaction carries no price floor at all: swap 1 sells the full input with a minimum ~1e13 times below the real output, swap 2 sells a dust amount, and the wallet ends up holding currency0 at whatever price the block gave.

There is no sanity check of the quote against the tick-derived price the page already has (pool.price from the Swap log / slot0), and no requirement that the user's minimum be non-zero for amounts above the test size.

Area 3 note: the V3 creation-call quote itself is bound to the hardcoded factory (src/V3Quote.sol:59,67) and authenticates the callback (msg.sender == pool), so a pasted fake pool cannot alter the quoted amount and validateV3Pools() blocks executing it; the RPC is the only party that can forge a V3 or V4 quote.

sendRoute() sets prepared = null before leg 1 (line 2505). If leg 1 confirms and any later step fails (balance-increase check 2535, deadline 2536, allowance 2541/2544, the leg-2 eth_call 2546 reverting because the sell pool moved, a wallet rejection, or an on-chain revert in waitReceipt), the catch at 2549-2558 reports 'Leg 1 confirmed ... check both hashes' and throws.

Nothing in the client or page can then (a) re-quote the sell leg, or (b) build and send a currency0 -> currency1 single-leg transaction: routeTransactions() always begins with the buy leg, prepareRoute()/sendRoute() only accept a full route, and the page's only other action on currency0 is TRANSFER ALL to another wallet.

The leg-2 floor also goes stale by construction: selected.finalQuote / minimumReturn are quoted at row-selection time (index.html:842-843), before leg 1 is signed, confirmed (up to 120 s) and re-checked, and are never refreshed, so a sell pool that moved 0.5% against the user between the quote and leg 2 makes leg 2 revert at 2546 and strands the bridge amount.

The README documents that leg 1 cannot be rolled back and that the operator must 'decide how to unwind or retry', but the page gives them no tool to do either; re-running the route buys more currency0 first.

wallet.revokeAll(token) sets token.approve(V3_ROUTER, 0) and token.approve(PERMIT2, 0) for one token (js/v4-arb-encoder.js:2618-2644). The page passes only pair.currency1.

But approveRouteV3() grants 100 x ponsAmount of currency0 to SwapRouter02 for V4-buy/V3-sell mixed routes (routeApprovals(): the sell leg's input is currency0, js/v4-arb-encoder.js:2378-2379, 2411), and approveBothPermit2()/approveRoutePermit2() grant Permit2 allowances to the Universal Router for currency0 and currency1 that are never touched.

In All-pairs mode pair() is the selected spread's pair or the first pair, so other pairs' input tokens (e.g. WETH when both WETH and USDG are Token Bs) are not revoked either. After the button finishes the page reports 'REVOKE ALL finished for USDG. Approvals are needed again before the next swap', which is false for the surviving allowances.

The residual Permit2 allowance (100 x amount, 30 days) becomes live again the moment the user re-approves the token to Permit2 for any other dapp, since Permit2 is a shared singleton; the README's reasoning ('with the ERC20 allowance at 0 the router cannot pull anyway') holds only until then.

Uniswap V3 liquidity() is the liquidity at the current tick only. A pool whose positions sit entirely above or below the current price has liquidity() == 0 yet a swap crosses into those positions and fills (partially or fully).

V3Quote returns (0, 0) without calling swap(), quoteV3ExactIn() returns 0, and the page shows 'Warning: no liquidity' with execution disabled (index.html:830-836); readPoolHealthBatch() marks the same pool EMPTY from liquidity() for the spread table (js/v4-arb-encoder.js:1540-1541).

The check is therefore a false negative, not a loss: trades are missed, never mis-priced, and a pool that only partially fills is still caught by the client's amountInUsed != amountIn rejection (js/v4-arb-encoder.js:619). The actual swap() call already handles the zero case (received == 0 -> V3QuoteResult(amount, 0)), so the pre-check adds nothing but the false negative.

Noted for completeness of the assigned V3-quote review: the fake-pool question is answered negatively (quote path bound to the hardcoded factory, callback authenticates msg.sender == pool, validateV3Pools() rejects a pasted address that the factory does not return), so only the RPC can forge a V3 quote (see the medium RPC-trust finding).

The page separates two trust domains: the public monitoring RPC (RPC_URL with RPC_FALLBACK_URL, or the operator's Worker) for polling and quoting, and the wallet provider for allowance checks, eth_call dry runs and eth_sendTransaction. The wallet-side checks are presented as the safety net ('Send will simulate these same bytes again').

But the token metadata that converts the operator's typed amounts into base units comes only from the monitoring RPC: createPoolMonitor/createAllPairsMonitor/createManualMonitor read symbol() and decimals() through rpc.request/rpc.batchRequest (js/v4-arb-encoder.js:1497-1499 decodePair, :369-378 tokenMeta), and index.html uses meta.decimals1 in quoteSpread() (line 820) and readAmounts() (lines 376-377) to build usdgIn and minUsdgOut, and meta.decimals0/decimals1 in every format() call, in the balance bar, and in the APPROVE limits text.

Nothing re-reads or cross-checks decimals through the wallet provider or against the fixed table of known tokens the file already carries (USDG 6, PONS 18, WETH 18).

Because the same wrong decimals drive both the base-unit conversion and every formatted display, the operator sees '0.01 USDG', 'Reusable limits: 1 USDG', and a balance bar that all agree, while the transaction, the 100x V3-router approval and the 100x Permit2 approval are built from a 100x larger base-unit amount.

The wallet's eth_call dry run passes as long as the inflated amount is covered by balance and allowance, which the page's own APPROVE buttons grant at 100x the inflated figure.

Combined with the quote path, which also comes from the monitoring RPC (the bridge amount and, for V3 routes, the enforced minimum return are decoded from revert data the RPC supplies), a compromised or hijacked RPC endpoint fully controls amountIn, amountOutMinimum and the approval limits of the transaction the operator is asked to sign. On-chain decimals verified via the public RPC for chain 4663: USDG decimals()=6, PONS decimals()=18.

The Worker (worker/rpc-proxy.js) forwards upstream bodies unchanged and adds no verification, so it does not change this.

Fix: read decimals()/symbol() of the pair through the wallet provider (wallet.request) before building amounts, or compare the monitoring RPC's values against a wallet-provider read and refuse to quote/build on mismatch; additionally pin the known tokens' decimals (USDG 6, PONS 18, WETH 18) in the encoder and reject RPC values that disagree. Keep the monitoring RPC for logs and quotes as designed.

quoteSpread() quotes the sell leg and derives selected.minimumReturn = sellQuote - 0.5% only when a leg is V3 (line 839-846); readAmounts() (line 378) raises the operator's 'Minimum currency1 return' field to that floor, and routeSnapshot() rejects a zero minimum for V3 routes (js/v4-arb-encoder.js:2368). For a V4/V4 route the same sell quote is fetched by showGasEstimate() (line 794, 'Expected return ...

Net after gas') but only displayed; minUsdgOut stays at the field value, whose default is '0' (line 177), and buildCalldata() accepts amountOutMinimum 0 for swap 2 (js/v4-arb-encoder.js:815-821).

The README documents this as 'V4-only routes retain the default minimum return of 0' for a small-amount test, but auto mode (maybeAutoExecute, lines 904-919) executes V4/V4 spreads without any click beyond the wallet signature and is driven entirely by data from the monitoring RPC: the GREEN verdict comes from the last Swap log tick of each pool (which can be stale, or fabricated by the RPC), the isDrained filter uses the same RPC tick, and the swap-1 quote comes from the same RPC.

The only on-chain protection in swap 1 is amountOutMinimum = bridge (quote x 0.995); swap 2 has none. So a stale tick (pool moved since its last swap), an empty or thin sell pool whose tick the RPC reports above -887000, or a lying RPC results in swap 2 dumping the whole bridge amount into the sell pool at any price while the page's own display already holds the number that would have protected the trade.

This is the asymmetry the Asymmetry guide describes between two branches of one function that should do equivalent work, with the economic consequence that the one branch that can run unattended is the unprotected one.

Fix (preserving the documented 'minimum 0 for a manual test' behaviour): in quoteSpread() set selected.minimumReturn = applySlippage(sellQuote) for every route, and in readAmounts() apply the floor whenever auto mode is on (or always, letting the operator lower it only by explicit field entry when auto is off); alternatively require minUsdgOut >= usdgIn in maybeAutoExecute() so an automated 'arbitrage' can never settle below break-even.

The page grants standing allowances on up to three surfaces for two tokens: (1) approveRouteV3 (js/v4-arb-encoder.js:2404-2428) approves 100x the V3 leg's input to SwapRouter02; for a mixed V4 (buy) -> V3 (sell) route, routeApprovals() makes that leg's token currency0 (the bridge token, e.g. PONS), so currency0's ERC20 allowance to the V3 router is set to 100 x ponsAmount.

(2) approveBothPermit2 / approveRoutePermit2 (:2267-2289, :2430-2448) set Permit2.allowance(owner, token, UniversalRouter) to 100x for 30 days, for currency1 and, in V4/V4 and V3->V4 routes, for currency0.

(3) The operator's own ERC20 approval of each token to Permit2 is a prerequisite the page checks but never grants or revokes. revokeAll(token) (:2618-2644) zeroes only token.approve(V3_ROUTER, 0) and token.approve(PERMIT2, 0), and index.html calls it for meta.currency1 alone (line 962, and the Section 2 copy at lines 113-114). After it finishes the status reads 'REVOKE ALL finished for .

Approvals are needed again before the next swap' (line 966), which is false for currency0: a V4->V3 route can be re-sent immediately with the surviving PONS -> SwapRouter02 allowance plus the surviving Permit2 allowances, and the surviving currency0 -> Permit2 ERC20 allowance means the README's argument for leaving the Permit2 table alone ('with the ERC20 allowance at 0 the router cannot pull anyway') does not hold for currency0 at all.

The uint160 Permit2 allowances for the Universal Router (100x the test amounts, 30 days) also survive for both tokens even though the encoder already exposes the exact call that clears them (approvePermit2(token, ROUTER, 0, 0), README 'To revoke a Permit2 allowance').

No third party can spend these allowances (SwapRouter02 and the Universal Router pull only from their msg.sender; verified on chain 4663 that 0xcaf681...5cb2 reports factory() = the configured V3 factory and WETH9() = the configured WETH), so this is a completeness and false-assurance defect rather than a direct drain, but it is exactly the completeness question the review was asked, and the operator relying on the button to end their exposure before e.g. a router upgrade or a shared-Permit2 phishing is left exposed on the bridge token.

Fix: in index.html call wallet.revokeAll for meta.currency0 as well as meta.currency1 (skipping zero allowances as now), and extend revokeAll to also call approveForSession(token, ROUTER, 0, 0) when Permit2.allowance(owner, token, ROUTER).amount != 0; update the Section 2 text and the final status accordingly.

sendRoute() (js/v4-arb-encoder.js:2502-2560) submits leg 1, waits for its receipt, then checks the bridge balance, deadline and leg-2 allowance, simulates leg 2 and submits it. Any failure after the first receipt (leg-2 eth_call revert because the sell pool moved so minUsdgOut is unreachable, a rejected signature, a leg-2 revert, receipt timeout, deadline passed after a slow leg 1, Permit2 expiry, wallet account change) sets prepared = null and throws the message above.

The page then has no entry point that builds or sends only the sell leg: prepareRoute() always starts from route.buy with route.usdgIn (routeTransactions(), :2450-2467 always returns [leg1, leg2]), auto mode never touches mixed routes, and the only other actions on the bridge token are TRANSFER TO NEW WALLET (whole balance to another address) and REVOKE ALL.

So the operator is left holding currency0 bought at the buy pool's price with no in-page path to the second half of the trade; the README documents that 'restarting the whole route is never automatic' and that the operator 'must inspect both hashes ... before deciding how to unwind or retry', but the only in-page 'retry' available (select the same spread, dry run, send) re-executes leg 1 and doubles the bridge exposure before attempting leg 2 again.

The two-transaction design is intentional and the sequencing, checks and messages around it are correct; the gap is the missing 'sell leg only' continuation, which the existing code can provide without new trust: build routeTransactions(route,...)[1] with the current bridge balance (or route.ponsAmount) as input, re-quote the sell leg for a fresh minimum, simulate and submit it through submitLeg.

Until then the wallet is 'stuck' in the sense the review asked about: the bridge token can only leave through another dapp or the whole-balance transfer.

Reviewed for the question 'can a fake pool return a wrong quote'.

The constructor resolves the pool from the hard-coded factory (not from any pasted or RPC-supplied address), the callback receiver is created inside the same reverting creation eth_call, quote() is restricted to the creator (msg.sender == caller) and uniswapV3SwapCallback to the resolved pool (msg.sender == pool), the price limits are MIN_SQRT_RATIO+1 / MAX_SQRT_RATIO-1, delta signs and int256.min are checked, a swap that returns instead of calling back is rejected (V3QuoteUnexpectedReturn), and the client (js/v4-arb-encoder.js:602-625) requires the exact V3QuoteResult selector with 68 bytes and rejects partial fills (amountInUsed != amountIn).

The embedded bytecode matches the pinned compiler artifact (node scripts/embed-v3-quote.js --check passed on this tree). A pasted Manual-mode contract cannot steer the quote (it only supplies token0/token1/fee, which select the factory's pool) and cannot be traded because validateV3Pools() requires factory.getPool(...) == pasted address at dry run. The only inaccuracy found is this shortcut: Uniswap V3's liquidity() is the liquidity at the current tick only.

A factory pool whose price sits outside every position (liquidity() == 0) but that has positions elsewhere would fill a real swap after crossing into range, yet V3Quote returns (0, 0) and quoteV3ExactIn returns 0, so the page shows 'Warning: no liquidity' and disables approve/dry run/send. This is a false negative (missed opportunity), never an over-quote or an under-protected trade.

If exactness is wanted, drop the shortcut and let the callback report the real (amountInUsed, amountOut); the client's partial-fill check already handles the genuinely illiquid case.

revokeAll(token) sets token.approve(V3_ROUTER, 0) and token.approve(PERMIT2, 0) for ONE token, and index.html:962 always passes meta.currency1 (the token sold in swap 1).

But the page itself grants allowances on currency0 as well: approveRouteV3 approves currency0 to SwapRouter02 at 100x the bridge amount for V4-buy/V3-sell mixed routes (routeApprovals pushes the currency0 entry whenever route.mixed, js/v4-arb-encoder.js:2378-2379, limit at :2411), and approveBothPermit2 / approveRoutePermit2 write Permit2 allowances to the Universal Router for currency0 and currency1 (100x, 30 days). None of these is touched by REVOKE ALL.

The README's justification ('with the ERC20 allowance at 0 the router cannot pull anyway') only holds for currency1: currency0's ERC20 allowance to Permit2 (operator-granted, typically unlimited) is never revoked, so the Permit2 -> router allowance for currency0 remains fully spendable, and currency0's direct ERC20 allowance to SwapRouter02 remains at 100x the bridge amount.

The button is labelled REVOKE ALL and the status line says 'Approvals are needed again before the next swap', which is false for the currency0 side. Concrete exposure after 'REVOKE ALL finished': SwapRouter02 can still pull 4.975 PONS (100x a 0.04975 bridge) and the Universal Router can still pull 4.975 PONS via Permit2 for 30 days.

All quotes (V3 creation-call eth_call, V4 router-revert eth_call) go to the public RPC client created at index.html:248, never to the wallet provider, and the client retries the same payload once against RPC_FALLBACK_URL on HTTP 429 or any 5xx (js/v4-arb-encoder.js:1312-1331), returning whichever answers; nothing in the UI or client records or displays that a quote came from the fallback, and nothing cross-checks a quote against a second source.

The quote then becomes the economic protection of the trade: selected.bridgeAmount = applySlippage(buyQuote) is swap 1's minimum output and swap 2's exact input, and selected.minimumReturn = applySlippage(finalQuote) is the floor readAmounts enforces on the user's field (index.html:378).

A compromised or wrong-chain endpoint therefore controls the floors directly: a deflated sell quote lowers the enforced minimum to near zero while still passing routeSnapshot's 'a quoted minimum return is required' check (js/v4-arb-encoder.js:2368), and a deflated buy quote lowers swap 1's minimum, so a sandwich on either leg captures the difference.

The primary endpoint needs only to answer 429 (a public rate limit, which the operator cannot prevent) for trust to move to the second provider for that single request. The README names the RPC as a trust assumption for availability, not for the correctness of the slippage floor, and the Worker (worker/rpc-proxy.js) applies the same silent switch server-side.

routeTransactions always builds the route from leg 1, and prepareRoute/sendRoute are the only execution entry points the wallet client exports (connect, timestamp, approvePermit2, prepareRoute, sendRoute, approveRouteV3, approveRoutePermit2, approveBothPermit2, checkTokenAllowances, checkAllowances, prepareSwap, sendSwap, readBalances, transferAllToken, transferAllEth, revokeAll, request, account, invalidate, destroy).

When a mixed route's leg 1 confirms and leg 2 stops for any of the documented reasons (rejected signature, revert, failed simulation, deadline passed after leg 1, allowance shortfall, wallet change), sendRoute throws 'Leg 1 confirmed (...). Leg 2 did not confirm; check both hashes and the wallet's bridge balance before taking further action' (js/v4-arb-encoder.js:2552) and the wallet is left holding the bridge token (currency0).

There is then no action in the page or client that sells that bridge balance: re-selecting the spread and clicking dry run/send prepares two transactions again whose first is a fresh leg 1 (a second buy), so the operator who 'retries' as the UI invites doubles the currency0 position before the first one is sold. The single-leg encoders exist (buildV3Calldata for one hop, encodeV4Swap single swap), so a 'sell bridge only' preparation is cheap to add.

The README documents that leg 1 cannot be rolled back and that restarting is never automatic, but it does not say that the tool has no path to complete the half-finished trade; the TRANSFER buttons can only move the bridge token elsewhere, not convert it back.

quoteSpread() quotes the sell leg and sets selected.minimumReturn = finalQuote - 0.5% only when one leg is V3 (index.html:839-846). readAmounts() (index.html:378) raises the operator's field to that floor, and routeSnapshot() rejects a zero minimum only for V3 routes (js/v4-arb-encoder.js:2368).

For a V4/V4 spread the same sell quote is fetched by showGasEstimate() (index.html:794) but used for display only; minUsdgOut stays at the field default '0' (index.html:177) and buildCalldata() accepts amountOutMinimum 0 for swap 2. The transaction therefore protects swap 1 (bridge minimum) but lets swap 2 accept any output, including 0, so a moved or thin sell pool or a sandwich takes the whole second leg.

The README documents 'minimum 0' as a small-amount manual test, but auto mode executes V4/V4 spreads with no click beyond the signature, so the only branch that can run unattended is the unprotected one. Merged from audit_permissions (02d9ed86) and audit_math (208e01a8).

Fix (keeping the manual-test behaviour available): set selected.minimumReturn = applySlippage(sellQuote) for every route in quoteSpread() and let the operator lower it only by explicit entry when auto mode is off; have routeSnapshot()/prepareSwap() refuse minUsdgOut == 0 for every route.

All quotes (V3 creation-call eth_call, V4 router-revert eth_call) go to the public RPC client created at index.html:248, never to the wallet provider. createRpcClient.post() (js/v4-arb-encoder.js:1312-1331) retries the same payload once against RPC_FALLBACK_URL on HTTP 429 or any 5xx and returns whichever answers; nothing records or shows which endpoint produced a quote. quoteV3ExactIn() (js/v4-arb-encoder.js:616-620) and decodeQuoteRevert() (js/v4-arb-encoder.js:1439-1444) accept any well-formed revert payload.

The quote alone sets selected.bridgeAmount (swap 1's minimum and swap 2's input) and selected.minimumReturn (the enforced floor at index.html:378). There is no cross-check against the tick-derived price the page already holds (pool.price/displayPrice from Swap logs or slot0), no lower bound relative to amountIn, and the min-out field defaults to 0, so a deflated quote passes routeSnapshot()'s only check (minimum != 0).

The dry run and send go through the wallet provider, but a swap with amountOutMinimum 1 simulates fine at the real price, so the 'wallet re-simulates the same bytes' safety net does not catch it. An over-stated quote fails closed (revert); the exploitable direction is 'too small'. A primary endpoint that merely answers 429 moves trust to the second provider for that one request.

The V3 creation-call quote itself is sound (factory-bound pool, callback authenticates msg.sender == pool, exact selector and length, partial fills rejected; validateV3Pools() rejects a pasted pool the factory does not return), so the RPC is the only party that can forge a quote. Merged from audit_flow (f6296ace), audit_economics (24957ca7) and audit_math (94cb8165).

Fix: bound the accepted quote against the log/slot0-implied price (refuse when the quote-implied price deviates more than a configurable few percent from 1.0001^tick scaled by decimals), refuse a round-trip minUsdgOut below usdgIn x (1 - 2 x SLIPPAGE_BPS/10000) unless the operator explicitly opts in, cross-check quotes through the wallet provider's eth_call, and surface fallback use in the status bar.

Token metadata that converts the operator's typed amounts into base units comes only from the monitoring RPC: createPoolMonitor/createAllPairsMonitor/createManualMonitor read symbol() and decimals() through rpc.request/rpc.batchRequest (js/v4-arb-encoder.js:369-378, 1497-1499), and index.html uses meta.decimals1 in quoteSpread() (line 820) and readAmounts() (lines 376-377) to build usdgIn and minUsdgOut, and in every format() call, the balance bar and the approval-limits text.

Nothing re-reads decimals through the wallet provider or checks them against the fixed table of known tokens (USDG 6, PONS 18, WETH 18) the file already carries.

Because the same wrong decimals drive both the base-unit conversion and every formatted display, the operator sees '0.01 USDG', 'V3 Router limit: 1.0 USDG' and a balance bar that all agree, while the transaction, the 100x SwapRouter02 approval and the 100x Permit2 approval are built from a 100x larger base-unit amount. The wallet-side eth_call passes because the inflated amount is covered by balance and by the allowance the page's own APPROVE button just granted.

Together with the quote finding, a compromised RPC controls amountIn, amountOutMinimum and the approval limits of what the operator signs. Distinct mechanism and fix from the quote finding, so kept separate. From audit_permissions (72134f2a).

Fix: read decimals()/symbol() through the wallet provider before building amounts (or compare and refuse on mismatch), and pin the known tokens' decimals in the encoder, rejecting RPC values that disagree.

wallet.revokeAll(token) (js/v4-arb-encoder.js:2618-2644) sets token.approve(V3_ROUTER, 0) and token.approve(PERMIT2, 0) for ONE token, and the click handler passes only meta.currency1.

But the page itself grants allowances on currency0 too: approveRouteV3() approves 100x the V3 leg's input to SwapRouter02, and routeApprovals() (js/v4-arb-encoder.js:2376-2380) makes that input currency0 (the bridge token) for a mixed V4-buy/V3-sell route; approveRoutePermit2()/approveBothPermit2() write Permit2 allowances to the Universal Router for currency1 and, in V4/V4 and V3->V4 routes, currency0 (100x, 30 days). None of these is touched.

The README's justification ('with the ERC20 allowance at 0 the router cannot pull anyway') holds only for currency1: currency0's ERC20 allowance to Permit2 (operator-granted, typically unlimited) is never revoked, so currency0's Permit2 -> router entry stays spendable, and currency0's direct allowance to SwapRouter02 stays at 100x the bridge. After the button finishes the page reports 'REVOKE ALL finished for USDG.

Approvals are needed again before the next swap', which is false: a V4->V3 route can be re-sent at once. No third party can spend these allowances (both routers pull only from msg.sender), so this is a completeness and false-assurance defect rather than a direct drain. Merged from audit_flow (88e0287e), audit_permissions (e5108a8f), audit_economics (7c0b4819) and audit_math (0693167e).

Fix: in the click handler iterate over [meta.currency0, meta.currency1]; extend revokeAll() to call Permit2.approve(token, ROUTER, 0, 0) (encodePermit2Approve already supports amount 0) when readPermit2 shows a non-zero amount; update the Section 2 text and final status, or rename the button to state its single-token scope.

sendRoute() (js/v4-arb-encoder.js:2502-2560) sets prepared = null, sends leg 1, waits for its receipt, then checks bridge balance, deadline and leg-2 allowance, simulates and sends leg 2. Any failure after firstReceipt (leg-2 eth_call revert because the sell pool moved below minUsdgOut, deadline passed during a slow leg 1, wallet rejection, revert, receipt timeout) throws 'Leg 1 confirmed (...). Leg 2 did not confirm' and leaves the wallet holding the bridge token.

The wallet is not stuck in the sense of locked funds (the bridge token is a normal balance and TRANSFER ALL can move it), but the page has no entry point that builds or sends only the sell leg: routeTransactions() always begins with the buy leg, prepareRoute()/sendRoute() only accept a full route, and the leg-2 floor (selected.minimumReturn) is quoted at selection time and never refreshed after leg 1 confirms.

So the operator who follows the UI's only path (re-select the spread, dry run, send) buys a second bridge amount before any of the first is sold. The README documents that leg 1 cannot be rolled back and that restarting is never automatic, but not that the tool cannot finish the trade. Merged from audit_flow (e1bcd169), audit_permissions (5abe9b16), audit_economics (722a3a17) and audit_math (db4c0a83).

Fix: after a confirmed leg 1 keep a 'leg 2 pending' context (bridge amount actually received, sell pool, deadline), re-quote the sell leg for a fresh minimum, re-run the allowance/deadline checks and expose a single-leg 'retry leg 2 / sell bridge' action built from routeTransactions(route, ...)[1]; at minimum make prepareRoute() refuse a new mixed route while the wallet holds the unsold bridge amount without an explicit acknowledgement.

handle() accepts any POST whose body parses as a JSON-RPC object or array (validPayload, lines 58-65), forwards it unchanged to the primary and on 429/5xx to the fallback, and answers with access-control-allow-origin: . There is no origin allow-list, no method allow-list (eth_sendRawTransaction, debug_, trace_* are forwarded), no shared secret and, by design comment, no rate limit.

Once deployed and set as RPC_URL the URL is public in the served page, so a third party can exhaust the operator's Worker quota and the upstream providers' per-origin limits; because the page itself falls back on 429, that traffic also pushes the legitimate page onto the fallback provider, which is the trust expansion described in the quote finding. The upstream endpoints are public and keyless, so the gain to an attacker is the operator's quota rather than a secret.

From audit_math (ebe79e58).

Fix: restrict access-control-allow-origin to the page's origin, allow-list the methods the page uses (eth_call, eth_getLogs, eth_getBlockByNumber, eth_blockNumber, eth_gasPrice, eth_chainId), and add a per-IP rate limit (Cloudflare rate-limiting rule or a Workers KV counter).

Uniswap V3 liquidity() is the liquidity at the current tick only. A pool whose positions lie entirely above or below the current price has liquidity() == 0, yet an exact-input swap crosses into those positions and fills. V3Quote returns (0, 0) before calling swap(), quoteV3ExactIn() returns 0, the page shows 'Warning: no liquidity' and disables execution (index.html:830-836), and readPoolHealthBatch() marks the same pool EMPTY from liquidity() (js/v4-arb-encoder.js:1540-1541).

This is a false negative (missed trades), never an over-quote or an under-protected trade: a pool that only partially fills is still rejected by the client's amountInUsed != amountIn check (js/v4-arb-encoder.js:619), and swap() already handles received == 0.

On the fake-pool question the review was asked: the quote path is bound to the hardcoded factory (lines 59, 66-68), the callback authenticates msg.sender == pool (line 47) and quote() the creator (line 34), the client requires the exact V3QuoteResult selector with 68 bytes, the embedded bytecode matches the pinned artifact (node scripts/embed-v3-quote.js --check), and validateV3Pools() requires factory.getPool(...) == the pasted address before execution, so a pasted or RPC-supplied fake pool cannot alter the quoted amount; only the RPC can (see the quote finding).

Merged from audit_flow (d115b1da) and audit_permissions (0c0bfb1d). Fix, if exactness is wanted: drop the pre-check and let the callback report the real (amountInUsed, amountOut); if kept for gas, treat it as 'possibly empty' rather than 'no liquidity'.