fix(dex): stop trusted-leg preference from underpricing dust-amount LOP fills

[mrAndreyIsachenko]

oneinch_lo_executions_macro.sql picks a trusted token's leg value first when computing amount_usd, to avoid trusting a manipulated or illiquid price on the other leg. That's correct most of the time, but a maker can set a degenerate making_amount (as low as 1 wei on-chain - checked the raw decoded calldata and the contract's own output_0 return value, this is not a decode error) while genuinely trading real value on the taker side. Since the trusted leg always won regardless of its own amount, amount_usd landed near zero for these fills even though the trade had real value.

Measured against production data: 169 LOP fills in the 30 days before 2026-08-16, across ethereum, bnb, base, arbitrum, optimism, polygon and gnosis, show this pattern - always a wrapped-native maker leg with a dust amount. About $656/month understated.

Fix: the trusted leg only loses if its own transferred amount, normalized by decimals, is below 1e-9 of a token - nine orders of magnitude above the observed 1-wei bug pattern and far below any plausible real trade. A trusted leg with a normal amount but a smaller dollar value than an untrusted leg (for example an illiquid token with an inflated price) is untouched, exactly as before.

First version of this fix compared dollar values between legs instead of the trusted leg's own amount, and that turned out to be wrong: a regression sweep of real trades found a DATA/USDC pair where DATA (illiquid, ~$243k) overstates value and USDC's smaller ~$173 is the correct one - exactly the case trusted-preference exists to protect. A dollar-ratio check can't tell "trusted leg has a dust amount" apart from "untrusted leg has an inflated price," so it would have broken that case. Checking the trusted leg's own amount instead of a ratio fixes that.

Validation, all against real production data:

• Reproduced the exact fix logic against the known bad transaction (17 fills in one batch, each independently decoded with its own order_hash and call_trace_address - not a trace-collision issue): 6 of 17 corrected to real values, 11 unchanged only because those particular tokens have no price data at all (a separate, unrelated gap).
• Confirmed the DATA/USDC case above is untouched.
• Broad regression sweep: pulled every "normal-looking" trade (amount_usd > $1) in the 30-day window with a skewed leg ratio, expanded to 123 individual fills across 8 chains, diffed old vs new for each. 37 changed, all matching the dust-amount signature (old value 1e-15 to 1e-19, corrected to $0.005-$179). 86 unchanged, including every legitimate divergence case like DATA/USDC. No false positives found.

[cursor]

PR Summary

Medium Risk
Changes valuation logic for all chain LO execution models via a shared macro; scope is narrow and regression-tested, but downstream DEX metrics depend on amount_usd.

Overview
OneInch limit-order execution amount_usd no longer sticks to a trusted leg when that leg’s on-chain transfer is degenerate dust (normalized amount < 1e-9), so fills with sentinel maker amounts (e.g. 1 wei) can use the other leg’s USD value instead of near-zero.

The executions aggregation now keeps user_trusted_data / sources_trusted_data (amount + decimals from the winning trusted transfer) alongside the existing USD maxes, and amount_usd is chosen with a CASE: if trusted data exists but the normalized trusted amount is below the threshold, it falls back to the non-trusted-priority coalesce chain; otherwise it keeps the original trusted-first coalesce. Trusted legs with a smaller dollar value than an untrusted inflated-price leg are unchanged.

^{Reviewed by Cursor Bugbot for commit a4cebd3. Configure here.}

[dennisp42]

replayed the new case expression against oneinch.lo x oneinch_evms.transfers for all of august 2026, all chains: 600,944 fills, 879 change, every one of them up from ~0 (old values 1e-15 to 1e-19) to $988.90 in total, largest single fill $179.45. nothing decreases, nothing goes null, every changed fill has an 18-decimal trusted leg. total lo amount_usd moves from $1,323,946,350 to $1,323,947,339.
https://dune.com/queries/8589370

logic reads right. the check is on the trusted leg's own transferred amount, so the DATA/USDC style case (trusted leg smaller in dollars, normal amount) stays on the trusted leg. edge cases hold: both legs trusted and one of them dust picks the non-dust leg via max_by, null decimals falls through to the old coalesce chain.

nit: the 1e-9 token threshold can only fire for tokens with more than 9 decimals. a 1-unit dust leg in a 6-decimal token is 1e-6 and passes as real. fine for the observed pattern (always wrapped native), worth one line in the comment so nobody expects it to catch usdc dust.

nit: the two comment blocks are long for what the case does. keep the one-line why, drop the DATA/USDC narrative, it lives in the pr.

ci green on dex, 14 lo_executions models built full and merged incremental in run 32466727216, no test failures. approve.