Security Audit Report: Optimum Gateway

ProbeLab is an independent research and engineering team specialising in the measurement and optimisation of peer-to-peer networking protocols. Our work spans protocol design, performance benchmarking, and security reviews across the Ethereum ecosystem. We maintain active tooling across the Ethereum P2P stack, including Hermes, our instrumented Ethereum node for CL network analysis, and contribute to P2P research on libp2p, including GossipSub.

This audit was conducted as part of our ongoing program of applied security work on infrastructure running in, or alongside the Ethereum consensus layer. This report reflects our findings after the review of the Optimum Gateway and does not constitute a guarantee of the absence of vulnerabilities in code written after that point, nor does it cover the deployment environment or operator-specific configuration.

Executive Summary

This report covers an audit for the Optimum Gateway, split into two phases. All amendments and fixes were addressed by the Optimum team at the v1.0.2 tag (partner release getoptimum/ gateway:v1.0.2).

Phase 1 (March–April 2026, initial engagement): ProbeLab identified 22 numbered findings, plus 3 aggregator code-review items. The single high-severity finding (Phase 1 F-03, missing mump2p → CL publish step) was patched during the engagement; remaining items were tracked to resolution in v1.0.2.

Phase 2 (July 2026, follow-up): ProbeLab re-reviewed the codebase after an initial review of the first raised concerns. Seventeen new findings (F-01–F-17) emerged from Phase 2, none of which critical; all were addressed in v1.0.2 (F-07 partially resolved; telemetry deferral documented). The follow-up Phase 2 emphasised CL libp2p peering, Ethereum req/resp handshake handling, SSZ message processing, attestation subnet alignment, PeerDAS metadata, and observability on the CL ↔ mump2p forwarding path.

The audit confirmed that the gateway runs in parallel to the CL client's native libp2p stack, does not modify validator signing logic or attestation duties, and can be stopped at any time without affecting validator operation.

1. What the Optimum Gateway Software Does

The Optimum Gateway is responsible for receiving, validating, aggregating, and forwarding Ethereum messages (blocks, attestations) between two sides: the Optimum P2P network (mump2p) and the Ethereum CL host. It operates as a sidecar process alongside standard validator infrastructure.

• Deployment model: Sidecar daemon alongside validator infrastructure, typically paired with one CL client; does not modify validator signing logic, beacon state, or attestation duties.
• Interaction surface: Local CL client via libp2p/GossipSub; Optimum bootstrap API for validator-set sync, peer discovery, and trace submission; beacon API for fork-digest verification.
• Compatible CL clients: Lighthouse, Prysm, Nimbus, Teku, Lodestar, Grandine; validated by the Optimum team on Hoodi with the gateway at tag v1.0.2.
• Peering: The CL client must be configured with the gateway libp2p multiaddr (boot-node / trusted peer / equivalent). That is the required step for the CL to reach the gateway. Gateway-side direct_cl_peer s is not required for the initial connection: when the CL dials in, the gateway registers the peer dynamically in the GossipSub direct-peer set at runtime. direct_cl_peers remains recommended: it enables gateway-initiated re-dial after a gateway restart (Lighthouse and Nimbus do not reliably re-dial on their own), and when non-empty it enforces a connect-time peer-ID allowlist (see F-05).
• Operator profile: Professional node operators running Ethereum validators.

2. Audit Scope

2.1 In scope

• Networks tested: Hoodi testnet
• Topics tested: beacon_block, beacon_attestation_* (all 64 subnets)

2.2 Out of scope

• Off-chain infrastructure and hosting environment
• The mump2p core network protocol
• CL client internals
• Operator-specific firewall, Docker networking, and direct_cl_peers configuration

The review combined manual code review across all in-scope areas, static analysis, and end-to-end integration testing on Hoodi testnet using Hermes as a passive CL receiver.

2.3 Methodology

The following setup was used to test the interaction between the Optimum Gateway and Hermes (representing the CL side):

• Hermes was deployed locally on Hoodi with peer discovery disabled, using the Gateway's multiaddress as a direct connection, ensuring the Gateway was the only connected peer.
• The Gateway was deployed locally on the same machine, with Hermes's multiaddress configured as a direct connection.
• The experiment began once both hosts successfully established a mutual connection.
• With no other peers connected, all messages received by Hermes originated exclusively from the Gateway.

Hermes <--direct.connection--> Optimum Gateway <--connections--> mump2p Network

3. Optimum Gateway Architecture Overview

3.1 System diagram

Documentation: Optimum Gateway (v1.0.2)

CL_Client ──► [Optimum Gateway] ◄──► [mump2p network]
                     │
              [Bootstrap API]
         (validator sync, fork-digest,
          peer discovery, traces)

The gateway is configured for a single network (e.g. mainnet or Hoodi) and is designed to operate with one CL client in the typical deployment.

3.2 Interaction with existing infrastructure

The gateway runs in parallel to the CL client's native libp2p stack. It does not replace GossipSub, does not modify the CL client, and does not interact with validator signing, attestation construction, or block proposal logic.

• Parallel operation: The CL client's existing libp2p/GossipSub mesh keeps operating independently; the Gateway is simply notified of new messages on that mesh.
• Fallback behavior: If the gateway stops, or loses connectivity to mump2p, the CL client continues on its existing libp2p mesh. Validator duties are unaffected (see 3.3).
• No validator access: No modification of, or access to, validator key management, beacon state, attestation construction, or block proposal logic. It only operates at the plain p2p networking level.

3.3 Failure mode and reversibility

Stopping the gateway is process termination. The CL client keeps its existing libp2p mesh. Validator duties, attestations, and proposals are unaffected. On stop, the gateway closes CL gossipsub subscriptions, shuts down the CL libp2p host and the mump2p node, and writes nothing to CL storage, validator keystores, or the beacon DB.

You can find the full set of findings in the final Audit Report, which includes all links to related repositories and GH commits. For further clarifications, questions or recommendations, please do not hesitate to reach out to the ProbeLab team.