Console EVM Updates

OAPP_EXTENDED_INTERFACE_ID is intended to flatten the complete OApp interface tree. However, it includes type(IOAppReceiver).interfaceId without separately including its parent, ILayerZeroReceiver. Solidity calculates an interface ID using only functions declared directly by that interface. Consequently, type(IOAppReceiver).interfaceId includes isComposeMsgSender but excludes the inherited allowInitializePath, nextNonce, and lzReceive functions.

/// @dev Flatten all leaf interface IDs.
bytes4 constant OAPP_EXTENDED_INTERFACE_ID = type(IOAppReceiver).interfaceId ^
    type(IOAppMessagingChannel).interfaceId ^
    type(IOAppCore).interfaceId ^
    type(IOAppOptionsType3).interfaceId ^
    type(IOAppMsgInspection).interfaceId;

The incomplete OApp ID propagates into OFT_EXTENDED_INTERFACE_ID. The contract currently returns 0x97b6b900, whereas the complete flattened interface ID is 0x06fbb406. The difference is exactly the omitted ILayerZeroReceiver interface ID. Integrations that independently calculate the identifier from the complete ABI may reject or misidentify compatible OFT deployments.

Include type(ILayerZeroReceiver).interfaceId when calculating OAPP_EXTENDED_INTERFACE_ID.

Nexus processes inbound transfers for multiple registered tokens using a single global CreditRedirectStorage configuration. However, each registered NexusERC20 stores an independent guard pointer that its administrator can replace through setGuard. When an inbound message is executed, Nexus first determines the effective recipient using the global allowlist.

        if (!_isAllowlisted(_to)) {
            /// @dev `escrow` is guaranteed to be non-zero here.
            address escrow = _getCreditRedirectStorage().escrow;
            emit CreditRedirected(_to, escrow, _amountLD);
            return escrow;
        }
        return _to;

If the global allowlist considers the intended recipient eligible, _redirectCredit returns the original recipient instead of the escrow address. Next, Nexus invokes the registered NexusERC20’s mint function. Before minting, NexusERC20 performs another validation using that token’s current guard. If the global allowlist and the token’s current guard contain different policies, the global allowlist may accept a recipient that the token guard rejects. In that case, Nexus does not redirect the credit to escrow because _redirectCredit returns the original recipient, but the subsequent guard check reverts the mint. Consequently, the sender’s tokens have already been burned on the source chain and remain temporarily unavailable while the destination message is pending.

Although the intended deployment uses one shared guard for all Nexus tokens, this relationship is not enforced during token registration, credit redirect configuration, or subsequent guard replacement.

Consider enforcing that Nexus’s credit-redirect allowlist remains compatible with every registered NexusERC20 guard.

TransparentUpgradeableProxy2Step forwards the caller-provided initialization data to the inherited ERC1967Proxy constructor. The pinned OpenZeppelin version permits this data to be empty, in which case the implementation is installed without initializing the proxy’s storage. If the implementation exposes an external initializer, it remains callable through the proxy. Because non-admin calls are delegated to the implementation, anyone can invoke the initializer before the legitimate administrator and assign themselves application ownership, roles, or other privileged configuration.

Require the proxy to be initialized atomically during deployment using the expected encoded initializer call. Consider upgrading to OpenZeppelin Contracts v5.6 or later, which rejects empty initialization data by default.

The interface describes burn as removing a verified inbound nonce, implying that any verified packet can be burned with the correct payload hash. However, the Endpoint additionally requires the nonce to be at or below lazyInboundNonce.

        if (curPayloadHash == EMPTY_PAYLOAD_HASH || _nonce > lazyInboundNonce[_oapp][_srcEid][_sender])
            revert Errors.LZ_InvalidNonce(_nonce);

Because verification does not advance lazyInboundNonce, burning a freshly verified packet will revert while its nonce remains above the lazy checkpoint. The incomplete documentation may cause operators to submit reverting recovery transactions or misunderstand when burn is applicable.

Document that burn requires an exact, nonempty stored payload hash and _nonce <= lazyInboundNonce.