Repository navigation
chore(whitelist): allow DEX aggregator routers on 0G, Pharos, Injective and Tempo (EXBE-679) - #2559
Conversation
…ve and Tempo (EXBE-679) Nordstern on 0g and pharos, OKX and DODO on pharos, OpenOcean on injective, 0x and Enso on tempo. Selectors are the backend DEX_SIGNATURE_ALLOWLIST entries found in each contract's bytecode; approval-only contracts (OKX TokenApprove, DODOApprove) get an empty functions map, as on other chains. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
WalkthroughThe contract whitelist adds entries for Pharos, Tempo, Injective, and 0g. The entries include contract addresses and function selectors or signatures. ChangesChain contract whitelist additions
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Feature Merge Risk: ⚪ Minimal · up to
|
Which Linear task belongs to this PR?
EXBE-679: [BE] Enable additional DEX aggregators on 0G, Injective, Pharos and Tempo (EXSC-1211 was cancelled in its favour)
Why did I implement it this way?
This PR only changes
config/whitelist.json. It adds six already-integrated aggregators on four chains whereflyis the only DEX today. All four diamonds already haveGenericSwapFacetV3andWhitelistManagerFacet, so no deployment is needed — only the whitelist and the on-chain sync after merge.nordstern0g0x9e6d21e759a7a288b80eef94e4737d313d31c13fIceCreamSwap()nordsternpharos0x2ca37ff95caf25366ef16fc2e655b78a165d125fIceCreamSwap()okxpharos0x974d1cf6ffa4fce5a4d62955afc02f45aac29f35dagSwapTo)okxpharos0x78466a1488f1883d71cfddd1c621351572de0a1cdodopharos0xa5ca5fbe34e444f366b373170541ec6902b0f75cmixSwap0xff84aafa,externalSwap0x2fa11647dodopharos0xbf105f4ffbd3825f5433d074008b9a76237d849copenoceaninjective0x6352a56caadc4f1e25cd6c75970fa768a3304e64swap0x90411a320xtempo0x0000000000001ff3684f28c67538d4d072c22734exec0x2213bc0bensotempo0xcfbaa9cfce952ca4f4069874ff1df8c05e37a3c7routeSingle,routeMulti,safeRouteSingle,safeRouteMultiHow the entries were built:
/chains+ livetx.to, OKX dex-smart-contract docs, DODO'sdodoex_v2_subgraphPharos config, OpenOcean live/v4/1776/swaptx.to, 0x-settlerchain_config.json, and the Enso deployments page. Enso on Tempo uses0xcfba…a3c7, not the shared0xf755…22cf, which has no code on Tempo.generateDexWhitelistsAndSignatureslogic: each selector inDEX_SIGNATURE_ALLOWLISTis kept if it is in the contract's bytecode (after resolvingimplementation()/ EIP-1967 proxies). Every resulting selector set equals an existing entry for the same tool on another chain, and every name was copied from those existing entries — no new or unnamed selectors.functionsmap, as on the other chains. On Pharos,DODOFeeRouteProxy._DODO_APPROVE_PROXY_()→0x2afc…eeaa, whose_DODO_APPROVE_()is0xbf10…849c. OKXTokenApprove.tokenApproveProxy()→0x7da6…91aa, whosetokenApprove()is0x7846…0a1c.contractsblock.git diff --stat:config/whitelist.json | 74 +++, insertions only.No test was added. No existing test covers individual DEX whitelist entries.
bunx prettier --check config/whitelist.jsonpasses.Out of scope: syncing the whitelist on-chain after the merge, and the backend change (allowlists, mocks and the matching
whitelisting_config.jsonentries), which lands in a separatelifi-backendPR under the same ticket. The backend checksisContractAllowedbefore quoting, so either PR can merge first.Checklist before requesting a review
Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)
🤖 Generated with Claude Code