chore(deploy): production deploy of intent contracts for new settlers

[gvladika]

Which Linear task belongs to this PR?

Ref EXSC-736

Why did I implement it this way?

LI.FI Intents switched to new settler contracts on 2026-08-06. Our two bindings to them — LiFiIntentEscrowFacetV2.LIFI_INTENT_ESCROW_SETTLER_V2 and ReceiverOIF.OUTPUT_SETTLER — are immutable, so repointing them is a redeploy, not a config write. This is the production half; the staging half is #2173, which this branch is stacked on (its commit shows in the diff until #2173 merges).

Both contracts were deployed via CREATE3 and their diamondCut / diamondUpdatePeriphery proposed to each chain's LiFiTimelockController through the Safe. No Solidity changed, so there are no version bumps and no new audit is required — the upstream open(StandardOrder) ABI is unchanged apart from becoming payable, which does not alter the selector and is irrelevant while the facet is noNativeAsset.

Chain	LiFiIntentEscrowFacetV2	ReceiverOIF	Safe nonces (facet / receiver / whitelist)
mainnet	0x1B5c543CFe993ec1c89ad399E5433562A8CF4e05	0xe6ee2a573047598B2452a879F2188B31d0442dbF	118 / 119 / 120
base	0x1B5c543CFe993ec1c89ad399E5433562A8CF4e05	0xe6ee2a573047598B2452a879F2188B31d0442dbF	82 / 83 / 84
arbitrum	0x1B5c543CFe993ec1c89ad399E5433562A8CF4e05	0xe6ee2a573047598B2452a879F2188B31d0442dbF	83 / 84 / 85
bsc	0x1B5c543CFe993ec1c89ad399E5433562A8CF4e05	0xe6ee2a573047598B2452a879F2188B31d0442dbF	62 / 63 / —
optimism	0x1B5c543CFe993ec1c89ad399E5433562A8CF4e05	0xe6ee2a573047598B2452a879F2188B31d0442dbF	72 / 73 / —
polygon	0x1B5c543CFe993ec1c89ad399E5433562A8CF4e05	0xe6ee2a573047598B2452a879F2188B31d0442dbF	72 / 73 / —
pharos	0xe45163d84952c381c5899C426cCEBAC5B1636108	0x3Ae6D86812cFe41686DbFEceDa22782855134e01	23 / 24 / —
katana	0x8A0Ca1F897F4a48ee54B5842f6861A21FA162AD1	0xF57475939184DD15C73Bb97cbaa649517695d983	38 / 39 / —
robinhood	0xF824feC6aCdD168C9Db95B1Eaed18bf3E8Aae0FF	0xc1DcE9F7F5a7477CaE473D262e47b05bF2E712a3	25 / 26 / —

21 proposals total. Addresses differ per chain group because the CREATE3 factory address differs per network; the deployer and salt are identical throughout. Every deployment was read back on-chain: all 9 facets return the new input settler 0x00fC00edbe7C003b006f870068c548940000223e and all 9 receivers return the new output settler 0x75220B7600c300005038432a0000f308e0000068.

Whitelist (config/whitelist.json) — the LI.FI Intents DEXS entry allowlists open() (0x7515fd56) on the input settler for mainnet, base and arbitrum, and that pair was live on all three diamonds. The sync produced one proposal per chain combining the removal of the old pair and the addition of the new one in a single timelock scheduleBatch, so the swap is atomic — there is no window in which both settlers are callable as swap targets, nor one in which neither is. This matters because the settler is reachable as an allowlisted swap target through SwapperV2 and GenericSwapFacetV3, independently of the facet's own _startBridge path, which does not consult LibAllowList.

config/networks.json — katana's gasPrice pin drops from 3 gwei to 0.5 gwei. The pin exists because katana's RPC used to over-report ~20 gwei, but it now reports ~0.002 gwei, so the stale 3 gwei value combined with GAS_ESTIMATE_MULTIPLIER=250 made forge's balance pre-check demand ~0.0176 ETH for a deployment that actually cost ~0.0000118 ETH — blocking the deploy with a misleading insufficient funds error. 0.5 gwei keeps a 250× margin over the live price. The katana deploy then succeeded and spent 0.0000348 ETH for both contracts.

Chains deliberately excluded. arc, jovay and megaeth are not in this rollout: neither new settler is deployed on them (verified on-chain). arc and megaeth run intents on the old settler today and would have broken; jovay has never had a settler at either address. Facet contracts were deployed on those three before this was caught, and the resulting three diamondCut proposals were deleted from the Safe queue rather than signed. Their deployment logs are intentionally left untouched here so the recorded state matches what is actually registered — the orphaned addresses are recorded in EXSC-742 instead.

This PR is a draft on purpose. deploymentAddressConsistency.yml skips draft PRs to support exactly this two-step flow: the flat deployment logs are ahead of the *.diamond.json logs until the timelock cuts execute. Once they have, the diamond logs get updated and the PR can be marked ready.

Follow-ups filed from what this rollout exposed: EXSC-740 (the facet deploy script does not verify its settler is a contract — the root cause of the arc/jovay/megaeth mis-deploy), EXSC-741 (deployContractToNetworks.sh reports OK after every deploy attempt fails), EXSC-742 (settlers missing on arc/jovay/megaeth — deploy or descope), EXSC-743 (verification broken on the arc/jovay/robinhood explorers), EXSC-744 (_targetState.json pins 1.1.2 against actual 1.0.0), EXSC-745 (config/whitelist.json carries 139 stale PERIPHERY entries and drifts in format from the sync output).

Checklist before requesting a review

• I have performed a self-review of my code
• This pull request is as small as possible and only tackles one problem
• I have added tests that cover the functionality / test the bug
• For new facets: I have checked all points from this list: https://www.notion.so/lifi/New-Facet-Contract-Checklist-157f0ff14ac78095a2b8f999d655622e
• I have updated any required documentation

Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)

• I have checked that any arbitrary calls to external contracts are validated and or restricted
• I have checked that any privileged calls (i.e. storage modifications) are validated and or restricted
• I have ensured that any new contracts have had AT A MINIMUM 1 preliminary audit conducted on by <company/auditor>

[coderabbitai]

Walkthrough

Updated Katana gas configuration, LI.FI Intents whitelist addresses, and LiFiIntentEscrowFacetV2 and ReceiverOIF deployment addresses across network and Diamond manifests.

Changes

Deployment Registry Configuration

Layer / File(s)	Summary
Contract and network configuration config/networks.json, config/whitelist.json	Katana’s configured gas price changed from 3 gwei to 0.5 gwei. LI.FI Intents addresses changed on mainnet, Base, and Arbitrum.
Network deployment manifests deployments/*.json	Updated LiFiIntentEscrowFacetV2 and ReceiverOIF entries across the network deployment manifests.
Diamond deployment manifests deployments/*.diamond.json	Updated LiFiIntentEscrowFacetV2 facet and ReceiverOIF periphery entries. The BSC periphery mapping was reordered without changing the listed entries.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• lifinance/contracts#2136: Updates the ReceiverOIF deployment entries also changed here.
• lifinance/contracts#2167: Updates overlapping multi-network Diamond deployment registries.
• lifinance/contracts#2173: Updates related LiFiIntentEscrowFacetV2 and ReceiverOIF deployment configuration.

Suggested labels: AuditNotRequired

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the production deployment of intent contracts for the new settlers.
Description check	✅ Passed	The description includes the task, rationale, deployment scope, exclusions, implementation details, and required checklist sections.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/exsc-736-lifi-intents-switchover-production

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}