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 · 3 reviews2026-08-07 16:31 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. |
| Add Ink (chainId 57073) DutchV3 support. The reactor and OrderQuoter are deployed and source-verified on Ink; these are the mapping entries that let the SDK resolve them. | ||
|
|
||
| - `REACTOR_ADDRESS_MAPPING[57073][Dutch_V3]` → `0x000000007A1C8e570011EeDF86A2A35593013cBA`. This is the same address as Robinhood (4663), 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`. | ||
| - `UNISWAPX_ORDER_QUOTER_MAPPING[57073]` → canonical `0x00000000a3db63Df9078cBF3dF88B4CAdD5a7F58`. Required: without it the lookup falls through `constructSameAddressMap` to the legacy `0x54539967…` default, which is not deployed on Ink. |
There was a problem hiding this comment.
constructSameAddressMap only populates the five NETWORKS_WITH_SAME_ADDRESS chains, so without this entry UNISWAPX_ORDER_QUOTER_MAPPING[57073] is undefined and the UniswapXOrderQuoter constructor throws MissingConfiguration — it fails loudly rather than silently resolving to 0x5453
There was a problem hiding this comment.
You're right, and I checked before changing it — constructSameAddressMap only seeds the five NETWORKS_WITH_SAME_ADDRESS chains, so there's no fallthrough default at all. Confirmed empirically against an absent chain: UNISWAPX_ORDER_QUOTER_MAPPING[59144] is undefined, and only chain 5 is still on the legacy 0x5453… (the other four seeded chains are overridden by explicit entries below).
So the failure is the else branch in UniswapXOrderQuoter's constructor throwing MissingConfiguration("quoter", "57073") — loud, not silent. Corrected in the changeset, the PR body, and the test-file comment.
That comment predates this PR (it came in with the Robinhood/Arc rollout) and I propagated it when extending the table, so the fix covers the original wording too.
| - `REACTOR_ADDRESS_MAPPING[57073][Dutch_V3]` → `0x000000007A1C8e570011EeDF86A2A35593013cBA`. This is the same address as Robinhood (4663), 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`. | ||
| - `UNISWAPX_ORDER_QUOTER_MAPPING[57073]` → canonical `0x00000000a3db63Df9078cBF3dF88B4CAdD5a7F58`. Required: without it the lookup falls through `constructSameAddressMap` to the legacy `0x54539967…` default, which is not deployed on Ink. | ||
| - `PERMIT2_MAPPING[57073]` → canonical Permit2, verified on-chain (9,152 bytes, non-zero `DOMAIN_SEPARATOR()`). | ||
| - `EXCLUSIVE_FILLER_VALIDATION_MAPPING[57073]` → zero address, matching every other V3-only chain. Required: the default is `0x8A66…`, a contract that does not exist on Ink. Exclusivity is reactor-enforced via `ExclusivityLib`. |
There was a problem hiding this comment.
the lookup yields undefined, not 0x8A66… (the silent bug there is encodeExclusiveFillerData passing undefined through into ValidationInfo).
There was a problem hiding this comment.
Correct on both points — the lookup is undefined, not 0x8A66…, and the real hazard is downstream: encodeExclusiveFillerData does
} else if (chainId) {
additionalValidationContract = EXCLUSIVE_FILLER_VALIDATION_MAPPING[chainId];
}with no guard, so undefined lands in the returned ValidationInfo rather than throwing. That makes this the quiet one of the two and the entry more load-bearing than I'd written, not less. Rewritten accordingly.
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 constructSameAddressMap only seeds the five NETWORKS_WITH_SAME_ADDRESS chains, so a chain with no explicit entry reads back undefined rather than a wrong-but-plausible default. Both consequences are covered by tests: the quoter lookup makes UniswapXOrderQuoter's constructor throw MissingConfiguration, and the exclusive-filler lookup silently puts undefined into the ValidationInfo that encodeExclusiveFillerData returns. The test-file comment describing this is corrected in the same pass -- it previously said both fall through to deployed-but-wrong defaults. 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>
2 participants
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.constructSameAddressMaponly seeds those five chains — there is no fallthrough default for an arbitrary chain, so a missing entry reads backundefined. The two consequences differ in loudness:UniswapXOrderQuoter's constructor hits theelsebranch and throwsMissingConfiguration("quoter", "57073"). Loud, but quoting is impossible without the entry.encodeExclusiveFillerDataassigns the lookup intoValidationInfo.additionalValidationContractwith no guard, soundefinedpropagates into order construction rather than throwing. Zero address matches every other V3-only chain; exclusivity itself is reactor-enforced viaExclusivityLib, so zero makes the hook correctly inert.Both cases are covered by the tests below. The test-file comment describing this is corrected in the same pass — it previously described both as falling through to deployed-but-wrong defaults, which is not what the map does.
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