chore(sdks): Version Packages

sdks/liquidity-launcher-sdk/CHANGELOG.md

@@ -1,5 +1,19 @@
 # @uniswap/liquidity-launcher-sdk
 
+## 1.10.0
+
+### Minor Changes
+
+- 4cfb073: Instant Launch: state the post-redeploy pool shape. The 2026-08-05 chain-4663 full redeploy did not re-pin the 3e05da8 InstantLaunchStrategy unchanged — it recompiled it with a new pool shape, which the SDK still described as "unchanged across deploys". All values below were read back from the deployed strategies' getters (`TICK_SPACING()` / `initialTick()` / `MIN_LAUNCH_TICK()`) on both current strategies and all eight pre-redeploy strategies.
+
+  - `INSTANT_LAUNCH_POOL_TICK_SPACING` → `25` (was 60). The current generation's compile-time `TICK_SPACING`; every pre-redeploy generation is 60. Confirmed against live `TokenLaunched` events: post-redeploy launches carry pool keys `(2500, 25, hookless)`.
+  - `INSTANT_LAUNCH_ALLOWED_POOL_TICK_SPACINGS` (new) → `[25, 60]`. The append-only grandfather set (same shape as `QUICK_LAUNCH_ALLOWED_POOL_TICK_SPACINGS`): pools are permanent, so routing/discovery consumers deriving a token's candidate launch pools must race a `(INSTANT_LAUNCH_POOL_LP_FEE, spacing)` key for every entry — the token address alone cannot say which generation minted its pool.
+  - `INSTANT_LAUNCH_INITIAL_TICK` → `198_050` (was 198,060) and `INSTANT_LAUNCH_MIN_LAUNCH_TICK` → `-160_100` (was -208,980): the current generation's launch-position bounds.
+  - `InstantLaunchDeployment.tickSpacing` / `.minLaunchTick` (new registry fields, beside the existing `initialTick`): the authoritative per-generation pool shape — 25 / 198,050 / -160,100 on the 2026-08-05 pair, 60 / 198,060 / -208,980 on every earlier generation. Consumers that know a launch's minting strategy resolve the exact pool key from here.
+  - `getInstantLaunchPoolKey` / `getInstantLaunchPoolId` now take an optional `tickSpacing` (default: the current generation) — pass the minting generation's spacing for pre-redeploy tokens. `getInstantLaunchPoolKeys` (new) returns one candidate key per grandfathered spacing, newest first, for consumers that must probe. `QuoteInstantLaunchBuyParams.tickSpacing` (new, optional) threads the same override through quoting.
+
+  `INSTANT_LAUNCH_POOL_LP_FEE` is genuinely unchanged (2500 on all ten deployed strategies). The quick-launch graduation-pool counterpart of this change (50 → 25) shipped in 1.9.0.
+
 ## 1.9.0
 
 ### Minor Changes

sdks/liquidity-launcher-sdk/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uniswap/liquidity-launcher-sdk",
-  "version": "1.9.0",
+  "version": "1.10.0",
   "description": "⚒️ An SDK for launching tokens and auctions with the Uniswap Liquidity Launcher (CCA + LBP) stack",
   "repository": "https://github.com/Uniswap/sdks.git",
   "keywords": [

sdks/uniswapx-sdk/CHANGELOG.md

@@ -1,5 +1,38 @@
 # @uniswap/uniswapx-sdk
 
+## 3.1.0
+
+### Minor Changes
+
+- dd518c4: Rename `multicallSameContractManyFunctions` to `multicallSameContractManyCalls`. The old name is still exported as a deprecated alias, so no existing import breaks.
+
+  The helper resolves `functionName` to a single fragment once, then encodes one call per entry in `functionParams` — it varies the arguments of one function, not the function itself. `functionName` living in the shared `MulticallParams` base type already makes "many functions" impossible: its sibling `multicallSameFunctionManyContracts` extends the same base and varies the address instead, and that one is named accurately.
+
+  No capability was missing. `multicall` is exported and takes arbitrary `{target, callData}` pairs, so heterogeneous functions and contracts were always reachable through it; these two helpers are narrow conveniences over it, one of them mislabeled.
+
+### Patch Changes
+
+- 241fb9a: 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: `constructSameAddressMap` only seeds the five `NETWORKS_WITH_SAME_ADDRESS` chains, so without an explicit entry the lookup is `undefined` and `UniswapXOrderQuoter`'s constructor throws `MissingConfiguration("quoter", "57073")`.
+  - `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, and the quieter of the two: without an entry the lookup is `undefined`, and `encodeExclusiveFillerData` assigns it into `ValidationInfo.additionalValidationContract` unguarded, so `undefined` propagates into order construction instead of throwing. Exclusivity itself is reactor-enforced via `ExclusivityLib`; the zero address makes the hook correctly inert.
+
+  No entry is added for `Priority`, `Dutch_V2`, `Hybrid`, or the `UNISWAPX_V4_*` mappings — 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.
+
+  Ink needs no chain-specific order-construction handling: it is a standard OP-stack L2 with 1s blocks, a real dynamic EIP-1559 basefee, and native ETH, so `adjustmentPerGweiBaseFee` keeps its normal non-zero treatment and the native sentinel is usable. `@uniswap/sdk-core` already has full Ink coverage (`ChainId.INK`, `INK_ADDRESSES`, `WETH9[57073]`, 1s block time).
+
+- 1797f3b: UniswapX quoters: return batch results in the caller's order. `quoteBatch` / `validateBatch` (and the Relay and V4 equivalents) misattributed results for batches that mixed orders with and without block overrides — the caller got another order's quote and validation.
+
+  `getMulticallResults` dispatches each order carrying `blockOverrides` on its own `eth_call`, because a block override applies to a whole call and those orders cannot share one. It then concatenated the responses override-orders-first and returned them, discarding the caller's ordering. Since results carry no order identity, `results[i]` is the only binding to `orders[i]`, so the mismatch was silent.
+
+  Results are now scattered back into their input positions. This also corrects two places that cross-referenced the permuted results against the un-permuted input array — the exclusive-filler branch of `getValidations` and `checkTerminalStates` — which could blend one order's revert data with another order's deadline, nonce, or block override into a single verdict.
+
+  The reordering triggered whenever an order without block overrides preceded one with them: `[dutch, priority]` came back swapped, `[dutch, dutch, priority]` rotated all three. Homogeneous batches, single-order calls, and batches listing every override order first were already correct, so `quote()` and `validate()` were never affected. In practice this needed a batch mixing Dutch with Priority or Hybrid orders.
+
+  Also skips a wasted `eth_call` that `UniswapXOrderQuoter` and `RelayOrderQuoter` fired when every order in a batch carried an override, and consolidates three copies of the batching logic into one `multicallOrdersPreservingOrder` helper.
+
 ## 3.0.11
 
 ### Patch Changes

sdks/uniswapx-sdk/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uniswap/uniswapx-sdk",
-  "version": "3.0.11",
+  "version": "3.1.0",
   "author": "Uniswap",
   "repository": "https://github.com/Uniswap/sdks.git",
   "keywords": [