Broadcast

What the Broadcast does

The Broadcast is DALP's in-platform RPC control plane for outbound EVM JSON-RPC traffic. Instead of pointing each service at one blockchain node, the platform keeps a pool of upstream RPC endpoints for every network and routes calls across that pool itself.

An operator configures a network once, with one or more upstream endpoints. The platform then handles the rest: it scores each upstream on how far it lags the chain tip, routes traffic to a healthy and current upstream, retries transient failures, and fails over to another upstream when one goes down. Application services keep reading from a single network configuration while the control plane manages provider health, credentials, and failover behind it.

An architect planning a bank-grade deployment needs to know how chain reads survive a slow or failed node, where to configure upstreams, and which controls stay with the deployment environment. This page answers those questions: routing and health scoring, upstream configuration, and the platform-versus-environment security boundary.

The control plane does not decide node ownership, provider trust, RPC caller authentication, or mutual TLS policy. Those controls belong to the target environment, its ingress or service-mesh layer, and the selected node or provider operating model.

Architecture

The control plane runs inside the platform rather than as a separate gateway pod. A single health-scoring poller measures each upstream and writes scores to a shared store, and every service reads those scores to select the same healthy upstream. The shared store also backs an optional historical-response cache.

How upstream selection works

The control plane keeps one upstream active per network and switches deliberately, not on every request. Three layers decide where a call goes.

When the active upstream fails a request, the control plane retries with backoff and jitter, then fails over to the next healthy upstream within the same request. If the shared health scores are stale or unavailable, each service falls back to a local liveness check rather than trusting an outdated ranking.

A weight on an upstream orders which healthy upstream is preferred when scores are close. Higher weight wins.

What operators configure

You define RPC connectivity per network in DALP configuration. Each network names one or more upstream endpoints, and the control plane supplies sensible defaults for everything else.

Each upstream entry can carry its own authentication, either an API-key header or HTTP basic auth, so the platform can reach providers that require credentials without exposing them in application code.

networks:
  mainnet:
    chain: mainnet
    rpc:
      urls:
        - https://primary-node.example.com
        - url: https://provider.example.com
          auth:
            type: apiKey
            headerName: Authorization
            value: ${MAINNET_PROVIDER_KEY}
          weight: 2
      wsUrl: wss://primary-node.example.com
      health:
        maxBlockHeadLag: 50

Keep endpoint URLs and credentials in your deployment configuration or secret-management process, not in application code.

Node connection model and security boundary

DALP does not require one fixed RPC node hosting model. The control plane routes to self-hosted full nodes, cloud-hosted nodes, managed RPC providers, or any combination. Your bank can operate a dedicated full node, register it as an upstream, and keep its credentials and network policy under your own operating model. That node needs to expose an EVM JSON-RPC interface the platform can reach; the control plane handles routing, scoring, and failover.

DALP owns routing, health scoring, and failover. Node ownership, upstream authentication, and independent validation sit with the deployment environment, outside the platform boundary.

Monitor pool health from the Console

A platform administrator manages and monitors RPC connectivity from the RPC control plane view in the Console. The view has two parts.

• Upstream pool editor. Configure the per-network upstream pool, including each endpoint and its provider-specific credential fields. Saved pools take effect without a restart.
• Health monitoring. A per-network table shows each upstream's liveness state, its tip lag behind the chain head, the upstream currently serving traffic, and the most recent failover or throttle event.

Each upstream reports one of four liveness states.

When the shared health store is unavailable, the view shows a clear "scores stale" banner so an operator does not read a single pod's local fallback as the authoritative pool state.

Request handling

The control plane applies per-request retry and timeout policy before a call fails over to another upstream. Configure these per network.

State-changing submissions such as eth_sendRawTransaction do not retry by default, so the platform never resubmits a transaction it cannot prove failed. The Transaction Signer owns submission and confirmation tracking for writes.

Log query limits

The Ledger Index and other read paths bound eth_getLogs calls against per-network limits before they reach an upstream: a maximum address count, a maximum block range, and a concurrency cap. These keep a single log scan from sweeping an unbounded range and let the platform adapt concurrency down when an upstream signals rate limiting. The same bounds are enforced on the public JSON-RPC endpoint.

Where resilience is applied

RPC resilience controls operate at distinct layers. Keep the responsibility split clear when you design an environment.

For production deployments, configure more than one upstream per network so the control plane has a healthy target to fail over to.

Operational notes

• Configure at least one upstream RPC endpoint for each EVM network your deployment serves, and more than one where you need failover or load distribution.
• Use encrypted https and wss upstream URLs, and set allowPrivateUpstreams only when you intentionally target in-cluster or loopback nodes.
• Watch the Console health view for upstreams that drift into the Excluded or Unhealthy state, and for the stale-scores banner that signals a degraded shared store.
• Track request volume, latency, upstream tip lag, failover events, and rate-limit responses in your observability tooling alongside chain node metrics.

See also

• EVM RPC Node for the node endpoint behind the control plane
• JSON-RPC endpoint for the authenticated read-only endpoint that exposes the same upstream pool externally
• Ledger Index for event processing
• Transaction Signer for transaction submission
• Self-hosting architecture for the wider deployment model
• Observability for monitoring