Executor Interface and Execution Logic Standard

The IExecutor interface is the canonical contract specification for the off-chain service responsible for calling lzReceive on a destination OApp after a message has been verified by the configured Decentralized Verifier Networks (DVNs). This standard defines the commit and revert function signatures that govern the lifecycle of a message execution attempt, creating a clear separation between the verification of a packet's proof and the on-chain transaction that delivers its payload. For OApp builders, the Executor is not an abstract concept but a specific address authorized to spend a pre-paid gas limit on behalf of their application, making the interface's gas accounting logic a critical operational dependency.

The standard's core technical challenge is handling execution failure without breaking LayerZero's exactly-once delivery guarantee. When an Executor's lzReceive call reverts—due to an OApp's custom logic, an out-of-gas error, or a misconfigured destination contract—the interface mandates a revert path that stores the failed message for a future retry rather than dropping it. This introduces a state machine where messages can be STAGED, EXECUTING, or EXECUTABLE, and it forces OApp developers to design their lzReceive implementations to be idempotent and to handle the possibility of receiving a message that previously failed. The Executor's retry logic, including who pays for the gas on subsequent attempts, is a critical parameter that directly impacts the liveness of cross-chain applications during periods of network congestion or contract misconfiguration.

For teams operating Executors or integrating with them, the interface's gas accounting model is a primary source of operational risk. The Executor must accurately estimate the gas required for the destination lzReceive call, and the OApp or its users must pre-fund this execution via the _lzSend options. A mismatch between the estimated and actual gas cost can lead to a permanent failure loop if the Executor lacks a top-up mechanism, effectively bricking the message path. Chainscore Labs can review an OApp's execution options configuration and lzReceive failure modes to identify gas griefing vectors and ensure that retry logic aligns with the application's liveness requirements.

The IExecutor interface standard defines the exact logic for delivering a verified LayerZero message to its destination OApp. The core function, lzReceive, is called by an Executor on the destination chain, passing the _origin, _guid, _message, _executor, and _extraData parameters. The OApp's implementation of lzReceive must enforce that only the authorized Endpoint can invoke it, and it must handle the message payload atomically. This is the single point of execution that bridges the protocol's verification phase with application-layer state changes.

Gas accounting is a critical operational concern embedded in this standard. The Executor is responsible for providing sufficient gas to the lzReceive call, based on the options set by the sender (e.g., msg.value for the destination's native gas token). If the call reverts due to an out-of-gas error or an application-level failure, the message enters a failure state. The Executor is then expected to retry the delivery, but the standard does not mandate a specific retry strategy, creating a design space where Executors can implement exponential backoff, gas bumping, or manual intervention. This places a burden on OApp developers to design lzReceive logic that is gas-efficient and resilient to re-execution.

The failure-and-retry model introduces a liveness risk that OApp teams must explicitly address. A message that consistently fails (e.g., due to a breaking state change on the destination chain) can be permanently stuck unless the Executor or a permissioned role can force-fail it or the OApp implements a fallback. Chainscore can review OApp lzReceive implementations for gas griefing vectors, non-idempotent execution paths, and missing failure recovery mechanisms, ensuring that application logic aligns with the Executor's operational behavior.