OFT deployment - #1450
Conversation
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
80917af to
b3ae00f
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 59ae6f76fd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Always use HyperEVM as destination for local testing | ||
| uint256 dstChainId = 999; | ||
| // Default to HyperEVM (chain 999) when no dstEid is passed; otherwise reverse-map the eid. | ||
| uint256 dstChainId = dstEid == 0 ? 999 : _chainIdForEid(dstEid); |
There was a problem hiding this comment.
When the requested dstEid is the current source chain's endpoint (or when running this script on HyperEVM with the default dstEid == 0), this resolves the destination to the same chain, after which _execute skips LayerZero and SponsoredOFTSrcPeriphery.deposit calls DstOFTHandler.executeDirect. That entrypoint requires DIRECT_CALLER_ROLE, but the new DeployDstHandler broadcast artifacts only grant the donation-box withdrawer role, the multicall whitelist role, and setAuthorizedPeriphery entries; they do not grant the source periphery DIRECT_CALLER_ROLE, so these same-chain deposits revert. Either reject same-chain destinations here or include the role grant for every configured same-chain src/dst pair.
Useful? React with 👍 / 👎.
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
…ntracts into faisal/oft-deployment
2 participants
Closes ACP-114