EVM RPC Node
The EVM RPC Node provides the direct interface to blockchain networks, handling JSON-RPC requests for transaction submission, state queries, event subscription, and hybrid node access across public and private EVM-compatible chains.
Overview
The EVM RPC Node is the blockchain network access point for DALP operations. It provides transaction submission, state queries, and event streaming through JSON-RPC.
Production deployments connect through the Chain Gateway for load balancing and failover across multiple endpoints.
The Transaction Signer submits signed transactions through this network layer.
The Chain Indexer consumes chain events after they are available.
Network connectivity
Supported networks
DALP operates across all EVM-compatible networks without application changes. Network-specific configuration handles consensus differences, gas models, and confirmation requirements.
Layer 1 mainnets
| Network | Description |
|---|---|
| Ethereum | Primary EVM network with largest ecosystem |
| Polygon PoS | High-throughput sidechain with low fees |
| BNB Smart Chain | EVM-compatible chain with fast finality |
| Avalanche C-Chain | Sub-second finality with Snowman consensus |
| XDC Network | Enterprise-grade hybrid blockchain |
| Gnosis Chain | Community-owned network (formerly xDai) |
Layer 2 rollups
| Network | Type | Description |
|---|---|---|
| Arbitrum One | Optimistic | Largest L2 by TVL with Nitro technology |
| Base | Optimistic | OP Stack chain incubated by Coinbase |
| OP Mainnet | Optimistic | Bedrock-based flagship OP Stack chain |
| Linea | ZK | ConsenSys zkEVM with type 2 equivalence |
| zkSync Era | ZK | Matter Labs ZK Stack rollup |
| Scroll | ZK | Community-driven zkEVM |
| Polygon zkEVM | ZK | Polygon type 2 zkEVM |
Specialized and appchains
| Network | Description |
|---|---|
| ADI Chain | UAE-based ZK Stack chain for institutional finance and regulated stablecoins |
| Immutable zkEVM | Gaming-focused Polygon zkEVM |
| Worldchain | World ID verified OP Stack chain |
Testnets
| Network | Mainnet equivalent |
|---|---|
| Sepolia | Ethereum testnet |
| Holesky | Ethereum validator testnet |
| Amoy | Polygon PoS testnet |
| Arbitrum Sepolia | Arbitrum One testnet |
| Base Sepolia | Base testnet |
Private networks
| Client | Use case |
|---|---|
| Hyperledger Besu | Enterprise features with permissioning |
| Go-Ethereum (Geth) | Reference implementation for private networks |
| Nethermind | .NET-based client with enterprise plugins |
| Erigon | Archive-optimized client for analytics |
Network resources
- Chainlist - Complete EVM network directory with public RPC endpoints
- L2Beat - Layer 2 network security and TVL analytics
RPC capabilities
- Transaction submission: Routes signed transactions to the network mempool with structure validation before broadcast
- State queries: Read current or historical blockchain state (balances, contract storage, call simulations)
- Event subscription: WebSocket connections for real-time event streaming and new block notifications
- Trace APIs: Debug and trace APIs for transaction execution details and gas breakdowns (client-dependent)
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 Chain Gateway, 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, scaling, 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, and provider contracts.
Cloud provider and regional boundary
For self-hosted deployments, DALP supports AWS, Azure, GCP, OpenShift, and approved Kubernetes environments when the required managed services, network paths, object storage, observability, and backup controls are available. Region selection belongs to the operator's landing zone and regulatory boundary rather than to the EVM RPC Node itself.
Use this boundary when reviewing hybrid architectures:
| 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 Chain Gateway 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 Chain Indexer 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 the planning ranges: cloud-native targets 2 to 15 minutes RTO with seconds to 1 minute RPO, hot-warm targets 30 to 180 minutes RTO with 5 to 60 minutes RPO, hot-cold targets 8 to 72 hours RTO with 4 to 24 hours RPO, and hot-hot targets 1 to 10 minutes RTO with seconds to minutes or 1 to 5 minutes RPO depending on the operating model. The measured result comes from the operator's restore or failover drill.
Security
- Authentication: API keys for managed providers; reverse proxy, service mesh, or node-level authentication for self-hosted nodes
- Network isolation: Private nodes should stay inside isolated network segments with firewall, ingress, or route restrictions
- Transport protection: Use HTTPS or WSS for external RPC endpoints. Keep HTTP or WS endpoints internal to trusted network paths, or protect them through private connectivity, ingress policy, or service-mesh controls.
Availability and recovery
Node access and indexing recover together during incidents. After an RPC endpoint fails over, operators should confirm that transaction submission still works, chain reads return the expected head, and the Chain Indexer is catching up from its stored checkpoint.
For production deployments, keep at least two reachable upstream endpoints where the network design supports it.
Monitor RPC endpoint 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
- Chain Gateway for load balancing and failover
- Chain Indexer for event processing and reindexing boundaries
- High availability for RTO, RPO, and recovery-pattern selection
- Transaction Signer for transaction submission
Chain Gateway
The Chain Gateway 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 provides reliable, system-guaranteed price and foreign exchange data for digital assets through a centralized directory with multiple feed types and subject scopes.