Incomplete AMPL blacklist: routes through unblacklisted AMPL pools on UniV3/V4

[Haikane]

Summary

The AMPL pool blacklist is incomplete. Only 2 specific AMPL pool addresses are blacklisted (UniV3 AMPL/WETH and UniV2 AMPL/WETH), but AMPL exists in many more pools across UniV3, UniV4, and potentially other protocols. Routes actively go through these unblacklisted AMPL pools.

Evidence

A USDC → EKUBO quote returned a 4-hop route through two AMPL pools not in the blacklist:

USDC → ??? (UniV3 0x898adc9a…784325)
  → AMPL (UniV3 0x02121488…17396b)
  → ETH (UniV4 0xcd494893…79b5d1)
  → EKUBO (Ekubo V3)

Neither 0x02121488f4fd9ae3e799b58f12bf8d962317396b nor 0xcd49489364242e854d9118eaa430f02d13156f2fc3cd78402d5efb150579b5d1 are in blacklist.toml.

Root cause

The blacklist operates on individual component IDs (pool addresses), not token addresses. AMPL is a rebasing token that breaks simulation in ANY pool, but the blacklist only had 2 specific pool addresses. New AMPL pools (on UniV4, different fee tiers on UniV3, etc.) slip through.

Suggested fix

Add token-level blacklisting to Fynd: a blacklisted_tokens field in blacklist.toml that excludes ALL pools containing a given token address. For AMPL (0xd46ba6d942050d489dbd938a2c909a5d5039a161), this would catch every pool automatically regardless of protocol or fee tier.

As a stopgap, I've added the 3 newly discovered AMPL pools to blacklist.toml locally.