chore(deploy): add ReceiverOIF v1.0.0 on 8 chains (EXSC-684)

[0xDEnYO]

Which Linear task belongs to this PR?

EXSC-684 (origin: #2125 — the facet-required-periphery health-check invariant).

No dedicated sub-ticket was created: the Linear connector is not authorised in the
session that produced this PR. Happy to split one out if you'd rather not hang this
off EXSC-684.

Why did I implement it this way?

#2125 adds a facet-required-periphery invariant requiring ReceiverOIF on every
chain running an intent-escrow facet. Before this PR it was live only on mainnet,
base and arbitrum, so the daily sweep would go red on every other such chain the
moment #2125 merges. This deploys it and adds the two missing pieces of framework
config it needed.

Deployed (production)

ReceiverOIF v1.0.0 on 8 chains. Each registration is a timelock-wrapped diamondUpdatePeriphery
Safe proposal carrying one signature.

Chain	Contract address	Safe nonce	Explorer
arc	0xEbf54fFDdAF89518DF79EC2F6b786a21b502Db4A	16	❌ see below
bsc	0xf6eB75d27ef8eAE08A5917fB3E1C35E2c64398c6	58	✅
katana	0xd47D8866848bcb6eE610E5f24f9d4Af48d6CbDcE	36	✅
megaeth	0x6115D73bC128f5327a8939794FE12B60731e5D20	39	✅
optimism	0xf6eB75d27ef8eAE08A5917fB3E1C35E2c64398c6	66	✅
pharos	0xEbf54fFDdAF89518DF79EC2F6b786a21b502Db4A	21	✅
polygon	0xf6eB75d27ef8eAE08A5917fB3E1C35E2c64398c6	66	✅
robinhood	0xdD54bEa53F94554d632d0D844D88a4fd51b2C576	22	✅

Each deployment was checked on chain: EXECUTOR() equals that chain's deployed
Executor, owner() equals global.json .refundWallet, and OUTPUT_SETTLER()
equals lifiintentescrow.json .OIFOutputSettlerSimple. The production
<chain>.diamond.json registries update only once the timelock ops execute, so they
are deliberately not touched here.

Framework config added

• deployRequirements.json had no ReceiverOIF entry, so the framework could not
  validate its constructor args. Added one modelled on ReceiverChainflip /
  ReceiverAcrossV4: _owner from global.json .refundWallet, _outputSettler from
  lifiintentescrow.json .OIFOutputSettlerSimple (a flat key, following the existing
  LiFiIntentEscrowFacetV2._inputSettler precedent), and Executor as a
  contractAddresses dependency.
• _targetState.json now lists "ReceiverOIF": "1.0.0" for the eight target
  chains plus mainnet, base and arbitrum — those three have had it deployed for
  a while but were never declared, so the file was already understating reality.

ReceiverOIF is deliberately not added to corePeriphery or
whitelistPeripheryFunctions: receivers call the Executor rather than being called by
the diamond, same as every other Receiver*, so no allowlist sync is involved.

katana note (no config change in this PR)

katana first failed forge's pre-flight balance check, not for lack of funds. It is
the only network pinning a gasPrice (3 gwei, a deliberate workaround in its
devNotes because its RPC over-reports eth_gasPrice), so forge reserves
gasLimit × 3 gwei up front and the reserve scales with whatever
GAS_ESTIMATE_MULTIPLIER the operator's .env carries. .env.example ships 130;
this rollout ran on a machine carrying 500, which reserved
5,023,370 gas × 3 gwei = 0.01507011 ETH against a 0.010063015677188902 ETH balance —
for a deploy whose measured cost is 918,183 gas, i.e. ~0.0000009 ETH at katana's live
0.001 gwei base fee.

A temporary katana.gasEstimateMultiplier override got the deploy through and has
been reverted — config/networks.json is untouched by this PR. An operator on the
documented 130 would not hit this at all.

Two things this surfaced, both left for separate tickets rather than widening a deploy
PR: katana has now hit this twice (also in #2108 on 22 Jul), so it recurs for anyone
running a high local multiplier; and the 3 gwei pin's premise has drifted badly — the
devNotes describes real txs at 1–4 gwei, but katana's base fee is now 0.001 gwei, so
the pin overpays roughly 3000×.

One chain is not in the table

• jovay — dropped, and it is a finding in its own right. Both OIF settlers have
  no code there: OIFOutputSettlerSimple
  (0x0000000000eC36B683C2E6AC89e9A75989C22a2e) and lifiEscrowInputSettler
  (0x000025c3226C00B2Cdc200005a1600509f4e00C0). Both are real contracts elsewhere —
  cast code returns 5,374 and 17,570 bytes respectively on every other chain checked
  (mainnet, base, arbitrum, optimism, polygon, katana, megaeth, pharos, robinhood, arc,
  bsc) and exactly 0x on jovay, the same as a plain EOA. The addresses are
  deterministic but the contracts were never deployed there, so DeployReceiverOIF
  aborts with
  .OIFOutputSettlerSimple … is not a contract. jovay nonetheless has both
  LiFiIntentEscrowFacet and LiFiIntentEscrowFacetV2 registered on chain — pointing
  at settlers that do not exist. ReceiverOIF is therefore left out of jovay's
  target state, and the new invariant will flag jovay until either the settlers ship
  there or the escrow facets come off.

Explorer verification

Verified on all chains except arc. explorer.arc.io/api sits behind a Circle
Cloudflare Access login wall, so no API key helps, and Sourcify does not support chain
5042 — this is a standing arc-wide explorer limitation rather than anything specific to
ReceiverOIF. Shipping it unverified and tracking it; it can be redone whenever
someone with Circle Cloudflare Access is available.

(megaeth initially failed too — Blockscout reported "Address is not a
smart-contract" for an address that demonstrably had code. That was indexer lag; it
verified cleanly on retry.)

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]

Warning

Review limit reached

@0xDEnYO, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 38 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 82af135b-02fa-4d0b-814e-abb05b297c5e

📥 Commits

Reviewing files that changed from the base of the PR and between fdd3d49 and 8ed677e.

📒 Files selected for processing (14)

• deployments/arc.diamond.json
• deployments/bsc.diamond.json
• deployments/bsc.json
• deployments/katana.diamond.json
• deployments/megaeth.diamond.json
• deployments/optimism.diamond.json
• deployments/optimism.json
• deployments/pharos.diamond.json
• deployments/polygon.diamond.json
• deployments/polygon.json
• deployments/robinhood.diamond.json
• deployments/robinhood.json
• script/deploy/_targetState.json
• script/deploy/safe/delete-pending-proposals.ts

Walkthrough

Adds ReceiverOIF deployment requirements, production facet mappings, and network deployment addresses. Katana’s configuration also gains a gas estimate multiplier and expanded deployment notes.

Changes

ReceiverOIF deployment configuration

Layer / File(s)	Summary
ReceiverOIF deployment requirements script/deploy/resources/deployRequirements.json	Defines required _owner, _outputSettler, and Executor values for ReceiverOIF.
Production target-state mappings script/deploy/_targetState.json	Adds ReceiverOIF version 1.0.0 to LiFiDiamond production mappings across eleven networks.
Network deployment addresses and Katana gas settings deployments/*.json, config/networks.json	Adds ReceiverOIF addresses to nine deployment manifests and configures Katana’s gas estimate multiplier and deployment notes.

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

Possibly related PRs

• lifinance/contracts#2058: Also updates ReceiverOIF facet and periphery deployment configuration.
• lifinance/contracts#2120: Also updates ReceiverOIF in the deployment target state.
• lifinance/contracts#2124: Also adds ReceiverOIF to the Robinhood deployment manifest.

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 is concise and accurately summarizes the main change: adding ReceiverOIF deployments on eight chains.
Description check	✅ Passed	The description follows the template closely, covering the Linear task, rationale, deployment details, and both checklists.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/mystifying-keller-e4cd5a

---

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.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@config/networks.json`:
- Line 664: Update the devNotes entry for this network to accurately describe
the gas estimate multiplier used by deploySingleContract.sh: explain the source
of 500 if it is applied elsewhere, or replace that value with the script’s
default of 130 and mention GAS_ESTIMATE_MULTIPLIER only when relevant. Keep the
guidance about the 3 gwei gas price and 200 buffer consistent with the corrected
multiplier details.
- Line 663: Rename the networks configuration key from gasEstimateMultiplier to
gas_estimate_multiplier, preserving its current value. Ensure the configuration
contains only the snake_case key and no duplicate legacy or overlapping
multiplier entry; leave deploySingleContract.sh unchanged so its legacy lookup
can be updated separately.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 92d7418c-b3b3-4807-b848-5b028067bc41

📥 Commits

Reviewing files that changed from the base of the PR and between 358c2b9 and fdd3d49.

📒 Files selected for processing (11)

• config/networks.json
• deployments/arc.json
• deployments/bsc.json
• deployments/katana.json
• deployments/megaeth.json
• deployments/optimism.json
• deployments/pharos.json
• deployments/polygon.json
• deployments/robinhood.json
• script/deploy/_targetState.json
• script/deploy/resources/deployRequirements.json

[lifi-qa-agent]

🔍 QA Review — EXSC-684 — PR #2136

Ticket: EXSC-684 — Couple facets to their companion periphery contracts so a Receiver can't be silently forgotten
PR: #2136 — chore(deploy): add ReceiverOIF v1.0.0 on 8 chains (EXSC-684)
Review type: 🆕 First review (companion deployment PR)
Reviewer: lifi-qa-agent[bot] | Date: 2026-07-29

---

What This PR Does

Deploys ReceiverOIF v1.0.0 (the OIF destination receiver for LiFi Intent Escrow) to 8 production chains. Non-deployment file changes:

1. script/deploy/_targetState.json — adds "ReceiverOIF": "1.0.0" to 6 chains (2 more are in generated deployment logs)
2. script/deploy/resources/deployRequirements.json — adds ReceiverOIF constructor parameter configuration

Also updates config/networks.json (devNotes correction for gasEstimateMultiplier).

---

Code Review

deployRequirements.json — ✅ Correct
ReceiverOIF constructor parameters follow the standard pattern:

• _owner ← global.json → .refundWallet (standard for receivers; allowToDeployWithZeroAddress: false)
• _outputSettler ← lifiintentescrow.json → .OIFOutputSettlerSimple (allowToDeployWithZeroAddress: false)
• Executor contract address dependency (allowToDeployWithZeroAddress: false)

All three allowToDeployWithZeroAddress: false — no zero-address deployments permitted. ✅

_targetState.json — ✅ Consistent
"ReceiverOIF": "1.0.0" added to 6 chain entries. PascalCase key naming is correct — deploy log keys are contract names (PascalCase throughout the fleet). CodeRabbit's camelCase suggestion was correctly withdrawn.

config/networks.json — ✅ Fixed
devNotes for gasEstimateMultiplier corrected: now distinguishes the repo default (130) from the local operator override (500). CodeRabbit confirmed. ✅

AuditNotRequired — ✅ Correct
No src/ Solidity changes. ReceiverOIF v1.0.0 was previously audited as part of the LiFi Intent Escrow system; deploying it to additional chains does not require a new code audit.

---

Process Notes

• melianessa APPROVED at 2026-07-29T07:39:42Z (after last commit 2026-07-28T13:34:26Z). SC core dev sign-off covers current HEAD. ✅
• This PR is a companion to PR feat(healthcheck): couple facets to their companion periphery contracts #2125 (the main feature). Together they complete the EXSC-684 deliverable.

---

Ticket Coverage

Rating: Partial (companion deployment — completes EXSC-684 alongside PR #2125)

---

✅ Verdict: Pass

Deployment configuration is correct, consistently structured, and approved by SC core dev.

---

QA review by lifi-qa-agent[bot] · Run #26 · 2026-07-29

[lifi-qa-agent]

✅ QA approved. ReceiverOIF v1.0.0 deployment configuration is correct: constructor parameters reference the correct config keys, all allowToDeployWithZeroAddress=false, targetState entries consistent. SC core dev approved. (lifi-qa-agent Run #26)