JSON-RPC endpoint

Overview

DALP exposes POST /api/v2/rpc/{networkName} as a managed JSON-RPC endpoint for the EVM networks your platform runs. Point any standard JSON-RPC client, indexer, or wallet tooling at it to read on-chain state without holding direct credentials for the underlying node providers.

Behind one URL, the platform keeps a pool of upstream RPC providers for each network. The platform scores those upstreams on block-height lag, routes each call to a healthy and current one, retries transient failures, and fails over to another upstream when one goes down. You call a single endpoint, and the platform manages provider health, credentials, and failover.

The endpoint is read-only by default and authenticated with a dedicated RPC API key. The endpoint is the public access point for the same upstream pool the platform itself uses, so your integrations read from the same vetted, monitored providers as the platform.

For account-abstraction calls, use the advanced accounts transaction relay instead. Its typed REST resources submit and track ERC-4337 UserOperations.

Access and scope

Every request needs an RPC API key. Send it in either header:

• Authorization: Bearer <your-rpc-api-key>
• x-api-key: <your-rpc-api-key>

A missing key returns 401 Missing RPC API key. A key that is unknown, revoked, or past its expiry returns 401 Invalid RPC API key. RPC API keys are separate from the platform REST API keys and carry their own rate limit and expiry.

The {networkName} path segment selects which configured network the call targets. The platform resolves that network's upstream pool and forwards the request there.

Authentication keys

A platform administrator issues, rotates, and revokes RPC API keys.

• Issue. A new key returns its full secret once, prefixed with dalp_rpc_. Store it securely at that moment; the platform keeps only a hashed form and cannot show the value again. Each key carries a name, an optional expiry, and a rate limit.
• Rotate. Rotation revokes the current key and issues a replacement that inherits the previous key's rate limit, returning a new secret. Move your clients to the new secret, then retire the old one.
• Revoke. A revoked key stops working immediately. Revoke a key the moment it is no longer needed or may be exposed.

Because a key can expire and can be rotated or revoked at any time, treat a 401 as a signal to refresh the key your client holds rather than to retry the same secret.

Requirements

Before you call the endpoint:

• Hold a valid, non-expired RPC API key for the platform.
• Know the networkName of the target network as configured on the platform.
• Send each request as a JSON-RPC 2.0 object with Content-Type: application/json.

Send a request

Send a single JSON-RPC 2.0 request object. The endpoint forwards it to the network's upstream pool and returns the JSON-RPC response.

curl --request POST \
  "$PLATFORM_URL/api/v2/rpc/mainnet" \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer $RPC_KEY" \
  --data '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_blockNumber",
    "params": []
  }'

A successful response echoes the request id and returns the upstream result:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x12a4b6c"
}

Batch requests

Send an array of request objects to run several calls in one round trip. The endpoint returns an array of responses, one per request.

A batch holds at most 100 requests. Each element in the batch spends one unit of the key's rate limit, so a single large batch cannot bypass the per-key limit. An empty array, or a batch over the 100-request maximum, returns a single JSON-RPC -32600 error rather than a partial result.

curl --request POST \
  "$PLATFORM_URL/api/v2/rpc/mainnet" \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer *** \
  --data '[
    { "jsonrpc": "2.0", "id": 1, "method": "eth_chainId", "params": [] },
    { "jsonrpc": "2.0", "id": 2, "method": "eth_blockNumber", "params": [] }
  ]'

Allowed methods

The endpoint serves read methods by default. The allowlist covers the standard EVM read surface, including:

A method outside the allowlist returns a JSON-RPC -32001 error with the message JSON-RPC method is not enabled. State-changing methods, such as broadcasting raw transactions, are not enabled on this endpoint. Submit transactions through the platform's transaction APIs instead.

Log query limits

eth_getLogs calls are checked against per-network bounds before they reach an upstream. A query that crosses a guard is rejected with a JSON-RPC -32602 error and a message naming the bound it hit. The defaults are:

A query also returns -32602 when:

• toBlock is below fromBlock.
• fromBlock or toBlock is neither a hex quantity nor a named tag (latest, earliest, pending, safe, finalized).
• A range ends at a live tag the platform cannot resolve to a concrete height. Specify concrete block numbers when this happens.

A blockHash filter targets a single block and carries no range, so it is not range checked. An operator can tighten these limits in network configuration.

These guards keep a single query from sweeping an unbounded range. Page large log scans into smaller block windows that stay within the network's range.

Rate limits

Each RPC API key has its own request budget over a rolling time window. The default is 120 requests per 60-second window, and an administrator can set a different value per key. A request that exceeds the limit returns 429 RPC API key rate limit exceeded. In a batch, every element counts as one request against the budget.

When you hit the limit, back off until the current window rolls over before retrying.

Error responses

The endpoint follows JSON-RPC error semantics. Application-level errors are returned in the JSON-RPC error envelope so clients handle them through standard JSON-RPC parsing:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32001,
    "message": "JSON-RPC method is not enabled"
  }
}

Authentication and rate-limit failures are returned as HTTP status codes rather than JSON-RPC envelopes:

Errors returned by the upstream provider are forwarded too. A deterministic application error, such as a contract revert or insufficient funds, passes through with the provider's original code, message, and data payload so your client can decode the revert. Infrastructure or topology failures are normalized to a safe code and a fixed message, with provider URLs and internal details stripped:

Integration notes

• Authenticate every request with an RPC API key in the Authorization: Bearer or x-api-key header. The platform REST API key does not authenticate this endpoint.
• Include an id on each request when you need to correlate responses, especially in batches where order is not guaranteed to match.
• Treat this endpoint as read-only. Route writes and transaction submission through the platform's transaction APIs.
• Bound every eth_getLogs call to a concrete block range and page large scans. Live tags such as latest are accepted only when the platform can resolve them to a height.
• Handle 429 with backoff keyed to the window length, and handle 401 by refreshing the key your client holds.
• For network-wide JSON-RPC error codes returned by the platform, see the Platform API error reference.

Related

• Configure RPC upstream pools for the admin task that sets the upstream providers and failover order behind this endpoint.
• Supported networks for the EVM connectivity a network needs before it can serve RPC traffic.
• Advanced accounts transaction relay for the ERC-4337 REST resources that submit and track UserOperations.