EVM RPC Node
The EVM RPC Node is the configured EVM JSON-RPC endpoint that DALP uses for transaction submission, chain reads, event indexing, and private or managed node access.
Overview
The EVM RPC Node is the configured EVM JSON-RPC address behind DALP chain operations. DALP uses it for transaction submission and to read network state.
The same layer provides the block and log data that the indexer turns into application events.
In production, DALP services normally reach the chain through the Broadcast. The Broadcast owns routing policy, retries, hedging, cache use, and failover across configured upstreams. The RPC node or provider still owns the blockchain client, connection credentials, network reachability, and which methods it supports.
The Transaction Signer submits signed transactions through this layer. The Ledger Index consumes chain events after they are available.
Use this page to understand how your deployment connects to EVM networks, which operating model fits your environment, and what each layer is responsible for.
Network connectivity
Network fit
DALP is EVM-focused. Each target chain must expose the JSON-RPC methods that DALP services, transaction submission, and indexing rely on. Your configuration must also provide a usable chain ID, RPC endpoint, contract metadata, and a finality or confirmation policy.
You can use the same architecture across different EVM configurations, but each chain is still an explicit deployment decision rather than an automatic DALP guarantee.
| Network model | What to validate | Why it matters |
|---|---|---|
| Public L1 or sidechain | Chain ID, supported JSON-RPC methods, gas model, confirmation depth, provider rate limits, and endpoint authentication | Confirms DALP can submit transactions and read consistent state through the configured gateway upstreams |
| EVM L2 rollup | Sequencer or RPC availability, finality assumptions, withdrawal/finality timing, gas estimation behavior, and fallback endpoint coverage | Keeps transaction monitoring and indexer expectations consistent with the rollup's operating model |
| Permissioned or private EVM network | Client type, consensus health, chain ID, RPC method support, account permissions, private connectivity, and operational ownership | Separates DALP application behavior from the institution's private-chain governance and infrastructure controls |
| Test network | Chain ID, faucet or funding process, contract deployment addresses, reset cadence, and whether indexed data can be discarded | Keeps test evidence separate from production operating assumptions |
Public network resources
- Chainlist for EVM chain identifiers and public RPC endpoint discovery
- L2Beat for layer 2 network and security context
RPC capabilities
The node layer handles four functions for DALP services. Review each before go-live.
The Platform API and Transaction Signer route outbound calls through this layer to submit signed transactions and read chain state. The Ledger Index also consumes block and log data from this same endpoint.
Advanced capabilities such as debug and trace methods, archive-mode queries, and WebSocket support depend on the selected node client or provider plan. Validate these before relying on them in production.
Deployment patterns for node access
DALP does not require one fixed blockchain node hosting model. The production pattern is to route DALP services through the Broadcast, then configure one or more EVM RPC upstreams behind that gateway.
| Pattern | What DALP connects to | When it fits | Availability check |
|---|---|---|---|
| Bank-operated node | An internal HTTP, HTTPS, WS, or WSS endpoint exposed by the operator's full node or validator-adjacent infrastructure | The operator needs direct control over node software, network policy, or independent verification | Monitor node lag, endpoint health, supported methods, and whether gateway traffic can move to a secondary upstream |
| Managed RPC provider | A provider endpoint configured as a gateway upstream | The operator prefers provider-managed node operations, capacity, and support | Monitor provider status, rate limits, authentication failures, and fallback provider readiness |
| Hybrid node access | A mix of bank-operated and provider-managed upstreams | The operator wants an internal primary path with provider fallback, or a provider primary path with a bank-operated verification node | Test failover across both upstream types and reconcile chain reads through the indexer after failover |
| Private EVM network | One or more RPC endpoints from the permissioned network | The target chain is operated by the institution, consortium, or private network operator | Track consensus health, finality depth, RPC method support, and indexer catch-up after network incidents |
This keeps node ownership separate from DALP application behavior. DALP centralizes routing, retries, hedging, cache use, and integrity checks in the gateway.
The deployment still owns node patching, endpoint credentials, private links, TLS or mutual TLS policy, provider contracts, and the decision to trust or independently verify a provider's chain view.
Cloud provider and regional responsibilities
For self-hosted deployments, DALP supports approved Kubernetes environments on AWS, Azure, GCP, and OpenShift. Each deployment requires managed infrastructure for networking and storage, along with observability and backup tooling. Region selection belongs to the operator's landing zone and regulatory responsibilities, not to the EVM RPC Node itself.
Apply this split when reviewing hybrid architectures. The table maps each requirement to the public DALP answer and the evidence to validate before go-live.
| Requirement | Public DALP answer | Evidence to validate before go-live |
|---|---|---|
| Core platform on-premises, node access in cloud | Supported when the on-premises DALP services can reach the cloud RPC upstreams through the Broadcast and the selected private connectivity, TLS, authentication, and routing policy. | Gateway upstream configuration, private connectivity test, credential rotation process, and RPC health alerts |
| Cloud-hosted Ledger Index or recovery-region indexer | Depends on the selected high availability pattern. The indexer region needs PostgreSQL, RPC endpoints, contract metadata, secrets, and observability. | Indexer checkpoint state, database access, RPC access, block-lag alerting, and catch-up drill result |
| AWS, Azure, or GCP region choice | Supported where the operator can provision the required Kubernetes, PostgreSQL, cache, object storage, backup, and observability services. | Region approval, managed-service availability, network design, data-residency approval, and provider SLA mapping |
| Regional cloud outage affecting one node or indexer path | DALP continues on the remaining region only when a healthy RPC upstream, indexer path, database path, and routing runbook are already configured and tested. Otherwise affected workflows fail until the required chain access or indexed state recovers. | Failover drill, measured recovery time, accepted RTO/RPO target, indexer catch-up evidence, and post-failover chain-read check |
Treat RTO and RPO as deployment targets, not automatic product promises. The high availability pages define planning ranges for each pattern.
Cloud-native achieves 2 to 15 minutes RTO and seconds to 1 minute RPO. Hot-warm reaches 30 to 180 minutes RTO and 5 to 60 minutes RPO. Hot-cold reaches 8 to 72 hours RTO and 4 to 24 hours RPO. A hot-hot deployment achieves 1 to 10 minutes RTO and seconds to 5 minutes RPO, depending on the operating model. The measured result comes from the operator's restore or failover drill.
Security
Use API keys for managed providers. For self-hosted nodes, add a reverse proxy, service mesh, or node-level authentication layer in front of the endpoint.
Keep private nodes inside isolated network segments with firewall, ingress, or route restrictions. Use HTTPS or WSS for external RPC addresses. Keep HTTP or WS connections internal to trusted network paths, or protect them through private connectivity, ingress policy, or a service-mesh control. You own the TLS and access-control decisions for your node layer. DALP leaves the platform-wide profile to your environment.
Availability and recovery
Node access and indexing recover together during incidents. After an RPC source fails over, confirm that transaction submission still works, block reads return the expected head, and the Ledger Index is catching up from its stored checkpoint.
For production deployments, keep at least two reachable upstream addresses where the network design supports it.
Monitor RPC availability, chain head age, finality lag, indexer block lag, and gateway errors.
Include those checks in the selected high availability pattern so node failure does not look like a healthy DALP deployment with stale chain data.
See also
- Broadcast for load balancing and failover
- Ledger Index for event processing and reindexing responsibilities
- High availability for recovery-pattern selection, RTO targets, and RPO targets
- Transaction Signer for transaction submission
Broadcast
The Broadcast is DALP's eRPC-based gateway for outbound EVM JSON-RPC traffic. It routes application requests through configured upstream RPC endpoints with method-aware timeouts, retries, hedging, and caching.
Feeds system
The Feeds system maps subjects and topics to active price or foreign exchange feeds, so DALP workflows, token contracts, APIs, and external consumers can resolve current market data without hard-coding feed addresses.