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 endpoint behind DALP chain operations. DALP uses this endpoint to submit signed transactions and read chain state.
The same layer provides the block and log data that the indexer turns into application events.
In production, DALP services normally reach those endpoints through the Chain Gateway. The gateway owns routing policy, retries, hedging, cache use, and failover across configured upstreams. The RPC node or provider still owns the blockchain client, endpoint credentials, network reachability, and method support.
The Transaction Signer submits signed transactions through this endpoint. The Chain Indexer consumes chain events after they are available.
Network connectivity
Network fit
DALP is EVM-focused. A target network must expose the JSON-RPC methods that DALP services, transaction submission, and indexing rely on, and the deployment must provide a usable chain ID, RPC endpoint, contract metadata, and finality or confirmation policy.
The same architecture can be used with different EVM operating models, but each network 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
- Transaction submission: Sends already signed transactions to the configured network upstream.
- State queries: Reads current or historical blockchain state, such as balances, contract storage, and call simulation results, when the upstream supports the requested method.
- Event availability for indexing: Provides block and log data that DALP indexing components use after the chain exposes those events.
- Client-dependent methods: Debug, trace, archive, and WebSocket capabilities depend on the selected node client or provider plan and should be validated before relying on them.
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, 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 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 responsibilities rather than to the EVM RPC Node itself.
Use this split 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 responsibilities
- 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 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.