Feat: Layerzero oracle

[haythemsellami]

Description

This PR implements a LayerZero V2-based oracle for cross-chain message attestation.

Oracle Implementation:

• Extends BaseInputOracle for standardized attestation storage
• Inherits ChainMap for protocol endpoint ID to canonical chain ID mapping
• Uses MinimalOApp for ownerless LayerZero V2 integration

Public Interface:

• quote() - Returns estimated messaging fees (native + LZ token)
• submit() - Sends attested payloads cross-chain via LayerZero endpoint
• lzReceive() - Receives and stores cross-chain attestations
• setChainMap() - Maps LayerZero endpoint IDs to canonical chain IDs (owner-only)

Design Decisions:

• Options parameter: Allows callers to specify gas limits and execution parameters.
• Refund handling: Excess fees automatically refunded to msg.sender by the LayerZero endpoint.

Related Issues

Fix #42.

Third-Party Integration Checklist

• No external library imports - Confirmed no new dependencies added to foundry.toml
• Interfaces copied locally - All required interfaces copied to src/oracles/[oracle-type]/external/[protocol-name]/
• Proper documentation - Each copied interface includes source header with:
• Self-contained - Integration works with only repository code
• Minimal interfaces - Only copied the specific methods/events needed

Additional Notes

MinimalOApp contract is a minimal/succinct version of Layerzero-v2 OApp contracts, it remove the ownership of the contract as well as keeping track of peers.

[haythemsellami]

Find Typos check failing because of other files unrelated to this PR. Will keep this PR focused on Layerzero related changes.

[haythemsellami]

forge fmt --check failing in the CI but passing locally, I guess because the CI is pinned to nightly version.
IMO it's better to use stable version in CI too as nightly may break things sometimes...

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[pepebndc]

Fixed CI, code not yet reviewed @haythemsellami

[reednaa]

Code looks fine. One thing to consider regarding LayerZero (and similar oracles in the future) is what to do about the required nature of configured oracle security?

Should we allow the owner to choose validators or how do we best let the intent configure them?

LayerZero is particularly hard since (I may be wrong) we can't embed configuration at flight time.

[reednaa]

@haythemsellami After discussing this with OZ, we have decided that it is required that oracle configuration needs to be possible at deploy time. That means the constructor needs to be able to call setConfig (I believe, it is some time since I last interacted with LayerZero so specific function names may be off).

One thing that is notable regarding this is that "equal" configs does not result in equal oracle addresses and LayerZero DVNs have different addresses on different chains.
This means there should also be a way to expose the config used on construction. I believe a transparent function to LZ's getConfig is fine (if possible).

• Config should be setable for both DVNs and executors though I believe it may be possible to do with a single call. (If I recall correctly, Executor config is not possible through options at flight time since correct executor is checked on receive)
• A sane default (LZ's default) should be possible to set if not config is provided.
• No way to modify the config post deployment should be possible.

LZ docs: https://docs.layerzero.network/v2/developers/evm/configuration/dvn-executor-config

[haythemsellami]

@haythemsellami After discussing this with OZ, we have decided that it is required that oracle configuration needs to be possible at deploy time. That means the constructor needs to be able to call setConfig (I believe, it is some time since I last interacted with LayerZero so specific function names may be off).

One thing that is notable regarding this is that "equal" configs does not result in equal oracle addresses and LayerZero DVNs have different addresses on different chains. This means there should also be a way to expose the config used on construction. I believe a transparent function to LZ's getConfig is fine (if possible).

• Config should be setable for both DVNs and executors though I believe it may be possible to do with a single call. (If I recall correctly, Executor config is not possible through options at flight time since correct executor is checked on receive)
• A sane default (LZ's default) should be possible to set if not config is provided.
• No way to modify the config post deployment should be possible.

LZ docs: https://docs.layerzero.network/v2/developers/evm/configuration/dvn-executor-config

Implemented the above. Re a default config, I think if no custom config is set, by default a fallback one is used https://docs.layerzero.network/v2/concepts/modular-security/security-stack-dvns#default-configuration.
But maybe we should require having the set-up of a default immutable config at deployment ?