Trait NodeAddOns 

pub trait NodeAddOns<N>: Send
where
    N: FullNodeComponents,
{
    type Handle: Send + Sync + Clone;

    // Required method
    fn launch_add_ons(
        self,
        ctx: AddOnsContext<'_, N>,
    ) -> impl Future<Output = Result<Self::Handle, Report>> + Send;
}

Customizable node add-on types.

This trait defines the interface for extending a node with additional functionality beyond the core FullNodeComponents. It provides a way to launch supplementary services such as RPC servers, monitoring, external integrations, or any custom functionality that builds on top of the core node components.

Purpose

The NodeAddOns trait serves as an extension point in the node builder architecture, allowing developers to:

• Define custom services that run alongside the main node
• Access all node components and configuration during initialization
• Return a handle for managing the launched services (e.g. handle to rpc server)

How it fits into NodeBuilder

In the node builder pattern, add-ons are the final layer that gets applied after all core components are configured and started. The builder flow typically follows:

1. Configure NodeTypes (chain spec, database types, etc.)
2. Build FullNodeComponents (consensus, networking, transaction pool, etc.)
3. Launch NodeAddOns with access to all components via AddOnsContext

Primary Use Case

The primary use of this trait is to launch RPC servers that provide external API access to the node. For Ethereum nodes, this typically includes two main servers: the regular RPC server (HTTP/WS/IPC) that handles user requests and the authenticated Engine API server that communicates with the consensus layer. The returned handle contains the necessary endpoints and control mechanisms for these servers, allowing the node to serve JSON-RPC requests and participate in consensus. While RPC is the main use case, the trait is intentionally flexible to support other kinds of add-ons such as monitoring, indexing, or custom protocol extensions.

Context Access

The AddOnsContext provides access to:

• All node components via the node field
• Node configuration
• Engine API handles for consensus layer communication
• JWT secrets for authenticated endpoints

This ensures add-ons can integrate deeply with the node while maintaining clean separation of concerns.

Required Associated Types

type Handle: Send + Sync + Clone

Handle to add-ons.

This type is returned by launch_add_ons and represents a handle to the launched services. It must be Clone to allow multiple components to hold references and should provide methods to interact with the running services.

For RPC add-ons, this typically includes:

• Server handles to access local addresses and shutdown methods
• RPC module registry for runtime inspection of available methods
• Configured middleware and transport-specific settings
• For Engine API implementations, this also includes handles for consensus layer communication

Required Methods

fn launch_add_ons( self, ctx: AddOnsContext<'_, N>, ) -> impl Future<Output = Result<Self::Handle, Report>> + Send

Configures and launches the add-ons.

This method is called once during node startup after all core components are initialized. It receives an AddOnsContext that provides access to:

• The fully configured node with all its components
• Node configuration for reading settings
• Engine API handles for consensus layer communication
• JWT secrets for setting up authenticated endpoints (if any).

The implementation should:

1. Use the context to configure the add-on services
2. Launch any background tasks using the node’s task executor
3. Return a handle that allows interaction with the launched services

Errors

This method may fail if the add-ons cannot be properly configured or launched, for example due to port binding issues or invalid configuration.

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementations on Foreign Types

impl<N> NodeAddOns<N> for ()

where N: FullNodeComponents,

type Handle = ()

async fn launch_add_ons( self, _components: AddOnsContext<'_, N>, ) -> Result<<() as NodeAddOns<N>>::Handle, Report>

impl<N, EthB, PVB, EB, EVB, RpcMiddleware> NodeAddOns<N> for EthereumAddOns<N, EthB, PVB, EB, EVB, RpcMiddleware>

where N: FullNodeComponents, <N as FullNodeTypes>::Types: NodeTypes<Primitives = EthPrimitives>, <<N as FullNodeTypes>::Types as NodeTypes>::ChainSpec: Hardforks + EthereumHardforks, <<N as FullNodeTypes>::Types as NodeTypes>::Payload: EngineTypes<ExecutionData = ExecutionData>, <N as FullNodeComponents>::Evm: ConfigureEvm<NextBlockEnvCtx = NextBlockEnvAttributes>, EthB: EthApiBuilder<N>, PVB: Send, EB: EngineApiBuilder<N>, EVB: EngineValidatorBuilder<N>, EthApiError: FromEvmError<<N as FullNodeComponents>::Evm>, <<<N as FullNodeComponents>::Evm as ConfigureEvm>::BlockExecutorFactory as BlockExecutorFactory>::EvmFactory: EvmFactory<Tx = TxEnv>, RpcMiddleware: RethRpcMiddleware,

type Handle = RpcHandle<N, <EthB as EthApiBuilder<N>>::EthApi>

async fn launch_add_ons( self, ctx: AddOnsContext<'_, N>, ) -> Result<<EthereumAddOns<N, EthB, PVB, EB, EVB, RpcMiddleware> as NodeAddOns<N>>::Handle, Report>

Implementors

impl<N, EthB, PVB, EB, EVB, RpcMiddleware> NodeAddOns<N> for RpcAddOns<N, EthB, PVB, EB, EVB, RpcMiddleware>

where N: FullNodeComponents, <N as FullNodeTypes>::Provider: ChainSpecProvider, <<N as FullNodeTypes>::Provider as ChainSpecProvider>::ChainSpec: EthereumHardforks, EthB: EthApiBuilder<N>, PVB: PayloadValidatorBuilder<N>, EB: EngineApiBuilder<N>, EVB: EngineValidatorBuilder<N>, RpcMiddleware: RethRpcMiddleware,

type Handle = RpcHandle<N, <EthB as EthApiBuilder<N>>::EthApi>