TOKEN_API_NO_OR_FILTER: swaps endpoint requires two parallel calls

[chillsauce]

/v1/evm/swaps has separate input_contract and output_contract filters but no OR / “either side” filter. Clients must issue two parallel calls and merge to get all swaps for a token. Doubles latency and rate-limit consumption on every detail-page render.

Proposed change. Add an involves_contract (or token_contract) filter that matches either side.

[0237h]

Triage: confirmed gap, needs further investigation.

The existing /v1/evm/swaps SQL is built around AND-intersection across N filters via minutes_union + HAVING count() >= n. An OR-side filter does not compose cleanly with that design — either it risks the optimizer not using both per-side projections, or it breaks the intersection guarantee when combined with other filters. A direct, narrowly-scoped fix on the API SQL would either be unsafe or carry the same perf regression that motivated the current design (#449).

Filed indexer-side at pinax-network/substreams-evm#257 to investigate the right substrate. No fix in the current PR series.

---

🤖 Generated with Claude Code