chore(deploy): add OutputValidator v1.0.0 on robinhood

[0xDEnYO]

Which Linear task belongs to this PR?

Fixes EXSC-685

Why did I implement it this way?

OutputValidator is core periphery (config/global.json → corePeriphery) and the production target-state Google Sheet lists it at 1.0.0 for all 75 networks — but it was never deployed to robinhood, so the diamond had no validator to call. This PR closes that gap: the contract is now deployed, verified, and proposed for registration + allowlisting on robinhood.

Robinhood fell through two separate cracks. It was brought up on 2026-06-25 in #1849 (then still named outlaw), which was after the OutputValidator fleet rollout of ~2026-06-09, so it wasn't part of that batch. And the new-network bring-up reads script/deploy/_targetState.json, which is stale relative to the sheet — OutputValidator is missing from it for all 75 networks (along with 161 other sheet entries, e.g. LiFiIntentEscrowFacetV2 on 63 networks and PolymerCCTPFacet on 16), so nothing in the automated path ever deployed it either. Regenerating that file from the sheet is deliberately left out of this PR to keep the diff to one concern; it's worth doing separately, since the drift currently hides this whole class of gap on every network.

State verified on-chain before deploying, so this isn't a log-only discrepancy: getPeripheryContract("OutputValidator") on the diamond returned 0x0, and there was no code at the address. Deployment used the standard CREATE3 path; the resulting address differs from other chains, which is normal for this contract (the 74 chains that have it span roughly 20 distinct addresses, since the salt varies with the build).

Production

Chain	Contract address	Safe nonce
robinhood	0x321E5015072eB568B24F46e5A92FFcc4316056AB	20 (registration), 21 (allowlist)

Both proposals are timelock-wrapped scheduleBatch calls on LiFiTimelockController 0x6E9Beb6997dAE04122f1f8f8980f3dc8225443F3 (3h minimum delay), each currently carrying a single signature and awaiting the usual signing round.

The config/whitelist.json diff adds OutputValidator for robinhood with selectors 0x27444dab (validateERC20Output(address,uint256,address)) and 0x5d865df2 (validateNativeOutput(uint256,address)). It ships here because proposal 21 is derived from it — registration alone does not let the diamond call the contract.

The contract is verified on Blockscout, and its constructor owner is 0x156CeBba59DEB2cB23742F70dCb0a11cC775591F, matching global.json → refundWallet as deployRequirements.json specifies. Production deployments/robinhood.diamond.json will only pick up the new periphery entry once the cuts actually execute, so it is intentionally not touched here.

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: 47 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: 54947a7d-c2b1-4907-abb6-27e9d83b88f6

📥 Commits

Reviewing files that changed from the base of the PR and between 41bc5aa and 1fe19d4.

📒 Files selected for processing (1)

• deployments/robinhood.diamond.json

Walkthrough

Robinhood deployment metadata now records deployed OutputValidator and ReceiverOIF addresses, and the whitelist defines OutputValidator with its address and validation method selectors.

Changes

Robinhood contract metadata

Layer / File(s)	Summary
Update Robinhood contract metadata config/whitelist.json, deployments/robinhood.json, deployments/robinhood.diamond.json	The whitelist adds OutputValidator validation signatures, the deployment mapping adds its address, and the diamond configuration sets OutputValidator and ReceiverOIF addresses.

Estimated code review effort: 1 (Trivial) | ~3 minutes

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 and concisely summarizes the main change: adding OutputValidator to Robinhood.
Description check	✅ Passed	The description matches the template with task, rationale, and review checklists, and is mostly complete.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/outputvalidator-robinhood

---

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: 1

🤖 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 `@deployments/robinhood.diamond.json`:
- Line 99: Update the Robinhood whitelist’s PERIPHERY entry in
config/whitelist.json to include the deployed ReceiverOIF address from the
ReceiverOIF field in deployments/robinhood.diamond.json, along with its selector
layout; if it is not intended for registration, clear the snapshot’s ReceiverOIF
field instead so consistency validation passes.

🪄 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: 92640c24-f66a-4560-bf29-380ec00c5745

📥 Commits

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

📒 Files selected for processing (3)

• config/whitelist.json
• deployments/robinhood.diamond.json
• deployments/robinhood.json