-
Notifications
You must be signed in to change notification settings - Fork 254
Description
Is your feature request related to a problem? Please describe.
When integrating OAppCore into a project, I discovered that setPeer accepts EID 0 as a valid endpoint ID. EID 0 is not a valid LayerZero endpoint (valid ranges are 30xxx for mainnet, 40xxx for testnet), which can lead to silent misconfigurations. Additionally, there's no validation to prevent setting the local endpoint as its own peer, no batch function for multi-chain deployments requiring multiple setPeer calls, and no event emitted when setDelegate is called.
Describe the solution you'd like
- Validate EID 0: Add
require(_eid != 0)insetPeerto reject invalid endpoint IDs - Prevent self-peer: Add
require(_eid != endpoint.eid())to prevent setting the local chain as a peer - Batch peer setting: Add
setPeers(uint32[] calldata _eids, bytes32[] calldata _peers)for gas-efficient multi-chain deployments - Add
hasPeerhelper: A non-reverting view function to check if a peer is configured - Emit
DelegateSetevent: Add observability for delegate changes insetDelegate - Validate endpoint in constructor: Add
require(_endpoint != address(0))to catch deployment errors early
Describe alternatives you've considered
Currently implementing these as overrides in our inheriting contract:
function setPeer(uint32 _eid, bytes32 _peer) public override onlyOwner {
require(_eid != 0, "Invalid endpoint ID");
super.setPeer(_eid, _peer);
}
This works but requires every OApp integrator to implement the same validation logic. Upstream fixes would benefit all users and ensure consistent behavior across the ecosystem.
Additional context
- EID numbering convention: 30xxx (mainnet), 40xxx (testnet)
- EID 0 represents an uninitialized/invalid state
- Multi-chain protocols often deploy to 5+ chains, making batch setPeers particularly valuable
- The existing
_getPeerOrRevertinternal function already treatsbytes32(0)as invalid, suggesting EID 0 should also be rejected at the setter level