feat(uniswapx-sdk): add Ink (57073) for DutchV3 rollout - #682
Conversation
|
● Reviewed · against Note Approved. Adds the four AssessmentThe load-bearing entries are correct: explicit quoter and filler-validation entries avoid the Iteration history · 2 reviews2026-08-05 21:42 UTC · ✅ approved · 0 findings ·
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Note
✅ Approved — see full review in the sticky comment ↑
Graphite Automations"Request reviewers once CI passes on sdks monorepo" took an action on this PR • (08/05/26)2 reviewers were added and 1 assignee was added to this PR based on Siyu Jiang (See-You John)'s automation. |
The Ink reactor and OrderQuoter are deployed and source-verified (Uniswap/UniswapX#375); these are the mapping entries that let the SDK resolve them. - REACTOR_ADDRESS_MAPPING[57073][Dutch_V3] -> 0x000000007A1C8e570011EeDF86A2A35593013cBA - UNISWAPX_ORDER_QUOTER_MAPPING[57073] -> canonical OrderQuoter - PERMIT2_MAPPING[57073] -> canonical Permit2 (verified on-chain) - EXCLUSIVE_FILLER_VALIDATION_MAPPING[57073] -> zero address The two mapping entries that would otherwise misresolve are the quoter (falls through to the legacy 0x54539967... default, not deployed on Ink) and the exclusive-filler validator (falls through to 0x8A66..., which does not exist on Ink). Both are covered by tests. The reactor address is shared with Robinhood, as chains 130/196/1868 already share 0x000000005aF6... REVERSE_REACTOR_MAPPING collapses shared addresses to one key, which is correct since both are Dutch_V3. No Priority / Dutch_V2 / Hybrid / UNISWAPX_V4_* entries: no such reactors are deployed on Ink, and the absence is what makes x-service's OffChainUniswapXOrderValidator.validateReactorAddress reject those order types for the chain. Tests extend the existing DutchV3-rollout tables with Ink, using a 30-block decay window (~30s wallclock at Ink's 1s blocks), and the REACTOR_ADDRESS_MAPPING inline snapshot is updated. Full uniswapx-sdk unit suite passes (333 tests). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Phase 2 of the Ink (chainId 57073) DutchV3 rollout. The reactor and OrderQuoter are deployed and source-verified on Ink (Uniswap/UniswapX#375); this PR adds the mapping entries that let the SDK resolve them.
Changes
REACTOR_ADDRESS_MAPPING[57073][Dutch_V3]0x000000007A1C8e570011EeDF86A2A35593013cBAUNISWAPX_ORDER_QUOTER_MAPPING[57073]0x00000000a3db63Df9078cBF3dF88B4CAdD5a7F58PERMIT2_MAPPING[57073]EXCLUSIVE_FILLER_VALIDATION_MAPPING[57073]Ink is not in
NETWORKS_WITH_SAME_ADDRESS, so all four need explicit entries. Two of them are load-bearing rather than cosmetic — without them the lookups don't fail, they silently resolve to the wrong contract:constructSameAddressMapto the legacy0x54539967…default, which is not deployed on Ink.0x8A66…, which does not exist on Ink. Zero address matches every other V3-only chain; exclusivity is reactor-enforced viaExclusivityLib.Both cases are covered by the tests below.
The reactor address is shared with Robinhood
Not a typo — Ink's reactor is deployed at the same address as Robinhood's. This is already the status quo elsewhere: chains 130, 196, and 1868 share
0x000000005aF6…today.REVERSE_REACTOR_MAPPINGis keyed by reactor address, so it collapses the two chains to a single key. That is correct here since both map toDutch_V3. I verified at runtime that the shared key resolves toDutch_V3, that both chains return the same reactor fromgetReactor, and that no address anywhere in the mapping is claimed by two different order types — the property that would actually matter if it broke.What is deliberately absent
No
Priority,Dutch_V2,Hybrid, orUNISWAPX_V4_*entries. No such reactors are deployed on Ink, and the absence is the upstream guard: x-service'sOffChainUniswapXOrderValidator.validateReactorAddressinfers "unsupported order type" from the missing entry. Adding zero-address placeholders would defeat that.No chain-specific order-construction handling needed
Ink is a standard OP-stack L2 — 1s contiguous blocks, real dynamic EIP-1559 basefee, native ETH with the canonical WETH predeploy — so
adjustmentPerGweiBaseFeekeeps its normal non-zero treatment and the native sentinel is usable.@uniswap/sdk-corealready has full Ink coverage (ChainId.INK,INK_ADDRESSES,WETH9[57073], 1s block time), added in #614, so no sdk-core change is needed.Tests
Extends the two existing DutchV3-rollout tables (added for Robinhood/Arc in #615) with Ink rather than adding parallel cases:
constants.test.ts—getReactorresolution, canonical quoter, canonical Permit2, zero-address filler validation. InlineREACTOR_ADDRESS_MAPPINGsnapshot updated.V3DutchOrderBuilder.test.ts— builds a V3 order for 57073 with a 30-block decay window (~30s wallclock at Ink's 1s blocks; compare 120 for Robinhood, 60 for Arc) and asserts the reactor resolves without an explicit address.Full
uniswapx-sdkunit suite passes: 333 tests, 0 failures.Note the three touched files are already Prettier-dirty on
main, so I did not runprettier --write— it would have buried this change in unrelated reformatting. The added lines follow the surrounding style.Release
Ships as a
patchvia changeset (.changeset/ink-dutchv3-mappings.md) rather than a hand-editedpackage.json+CHANGELOG.md, so the release bot handles it and this doesn't conflict with the pending changeset onmain.🤖 Generated with Claude Code