How to get an Ethereum RPC endpoint for custodians (2026)

TL;DR

A custodian can lose a customer deposit without a single error in the logs: ETH that arrives through a contract’s internal call emits no Transfer event, so if your endpoint can’t run trace_block or debug_traceTransaction, that deposit never shows up in your reconciliation and you find the gap at audit time, not at credit time. Public Ethereum endpoints don’t expose trace methods at all and throttle eth_getLogs aggressively, and they fail the SOC 2 vendor review before an engineer even tests latency. This guide shows custodians and asset managers how to choose, deploy, and harden an Ethereum RPC endpoint that survives both reconciliation and due diligence.

What is an Ethereum RPC endpoint

An Ethereum RPC endpoint is the JSON-RPC interface your application uses to talk to the Ethereum network — a URL that accepts method calls like eth_getBalance, eth_call, and eth_getLogs over HTTPS or WebSocket and returns state from the execution layer. For a custodian or asset manager, it is the single source of truth between the chain and your internal ledger: every balance you report, every deposit you credit, and every withdrawal you broadcast passes through it.

The endpoint is what makes the following institutional actions possible:

• Reading account balances for ETH and ERC-20 holdings (eth_getBalance, eth_call to balanceOf)
• Detecting incoming deposits, including internal transfers, via eth_getLogs and trace methods (trace_block, debug_traceTransaction)
• Confirming settlement and finality (eth_getBlockByNumber with the finalized tag, eth_getTransactionReceipt)
• Reconstructing historical state for reconciliation, NAV calculation, and proof-of-reserves (archive eth_call and eth_getBalance at past block heights)
• Broadcasting signed withdrawals and rebalancing transactions (eth_sendRawTransaction)

You can review the full list of supported methods in the Ethereum JSON-RPC API documentation.

For custody and asset management workloads, endpoint quality is not a latency question — it is a completeness question. A standard endpoint that silently drops a eth_getLogs page or rejects a trace call doesn’t crash your application; it quietly desynchronizes your ledger from the chain, and a reconciliation break discovered weeks later is far more expensive than a timeout you catch in seconds.

How custodian-grade Ethereum RPC differs from a standard endpoint

Most RPC guides assume a read-light dApp. Custody and asset management is a different load profile: heavy historical reads, trace-dependent deposit detection, and a vendor that has to clear a security review. The table below maps where a standard endpoint and an institutional-grade endpoint diverge for this workload.

Requirement	Standard public endpoint	Custodian-grade endpoint
eth_getLogs range	Capped (≈100 blocks free, throttled)	Up to 10,000-block ranges on paid tiers
Trace methods (trace_block, debug_traceTransaction)	Not available	Available for internal-transfer detection
Archive state access	Recent blocks only	Full historical state for reconciliation
Finality semantics	Best-effort	finalized tag honored for safe crediting
Vendor security posture	None	SOC 2 Type II and ISO 27001, RBAC, SSO, audit trails
SLA and support	None	Custom SLAs and incident response

These differences matter for provider selection because three of them — trace access, archive depth, and a documented security posture — are not features you can bolt on later. They determine whether you can even detect every deposit and whether your compliance team will let the provider into production at all.

Ethereum RPC endpoint options

Public vs private Ethereum RPC endpoints

For custodians, the public-vs-private decision is settled by a single question: can the endpoint prove it saw every value movement into your addresses? Public endpoints can’t, because they don’t expose the trace methods that surface internal transactions, and they rate-limit the log queries you need for high-volume deposit scanning.

Ethereum has no single official public endpoint; the network relies on a mix of community and provider-hosted URLs (for example https://eth.llamarpc.com and https://rpc.ankr.com/eth for mainnet, and Sepolia/Holesky URLs for testing). These are convenient for development but throttled and trace-disabled.

⚠️ Public Ethereum endpoints typically cap eth_getLogs at around 100 blocks per request on free access, expose no debug/trace namespace, and offer no SLA — which is why the Ethereum docs themselves recommend using a node service provider for production workloads.

Factor	Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
eth_getLogs range	Throttled, ~100-block cap	Up to 10,000-block ranges
Trace/debug methods	Disabled	Available
Archive access	Not available	Available
Security posture	None	SOC 2 Type II and ISO 27001, RBAC, SSO

For a custodian, the deciding factor is not cost or even uptime — it is that a managed endpoint is the only way to guarantee trace-level visibility into every deposit and to clear the vendor security review that gates production access.

Full node vs archive Ethereum node

For custody and asset management, historical state access is what separates a live balance display from a defensible audit. Reconciling a fund’s NAV at a past valuation point, regenerating a proof-of-reserves snapshot, or answering an auditor’s “what was this address worth at block N” all require querying state that a full node has already pruned.

Full node access	Archive node access
Current ETH and token balances	Historical balances at any past block for NAV and audit
Live deposit and withdrawal monitoring	Backfilling missed deposits after an outage
Recent transaction receipts	Full-history eth_getLogs reconstruction for compliance
Pending and recent block reads	Point-in-time proof-of-reserves snapshots

Chainstack supports Ethereum archive nodes, billed at 2 request units per call. Because custodians and asset managers are routinely asked to reproduce balances and movement at specific historical moments, an archive node is not an optional add-on for this use case — it is the system of record behind every audit response.

HTTPS vs WebSockets

Deposit detection is fundamentally an event-driven problem, which is why the transport choice matters for custodians. Polling every block over HTTPS for new deposits wastes requests and adds latency to crediting; a persistent WebSocket subscription pushes new heads and logs to you the moment they land.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Balance reads, archive reconciliation, batch reporting	Real-time deposit and newHeads subscriptions
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

WebSocket subscriptions are available on managed Ethereum endpoints; they are rarely offered on public endpoints. For a custodian, the practical pattern is WebSocket subscriptions for live deposit detection plus an HTTPS path for archive reconciliation and trace backfills.

How to get a private Ethereum RPC endpoint with Chainstack

1. Log in to the Chainstack console (or create an account).
2. Create a new project
3. Select Ethereum as your blockchain protocol
4. Choose network: Ethereum Mainnet or a testnet (Sepolia or Holesky)
5. Deploy the node
6. Open Access/Credentials and copy your HTTPS and WebSocket endpoints
7. Run a quick connectivity check before wiring it into production code

You can deploy a private Ethereum RPC node on Chainstack in a few minutes, then connect with your preferred SDK. The example below uses ethers.js and matches the connection pattern from the Chainstack Ethereum tooling docs:

import { ethers } from 'ethers';

// HTTPS provider for balance reads and archive reconciliation
const httpProvider = new ethers.JsonRpcProvider("YOUR_CHAINSTACK_ENDPOINT");
httpProvider.getBlockNumber().then(console.log);

// WebSocket provider for real-time deposit subscriptions
const wsProvider = new ethers.WebSocketProvider("YOUR_CHAINSTACK_WS_ENDPOINT");
wsProvider.on("block", (blockNumber) => {
    console.log("New block:", blockNumber); // trigger deposit scan on each new head
});

📖 For the full integration guide, see the Chainstack Ethereum tooling documentation.

You can also access Chainstack Ethereum RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP.

Using Chainlist

Ethereum is listed on Chainlist (chain ID 1), which makes it easy to add the network to wallets like MetaMask by injecting a chain ID and an RPC URL. Chainlist is a network registry, not an infrastructure provider — the RPC URLs it surfaces are public endpoints with the throttling and trace limitations described above. For any custody or asset management workload, replace a Chainlist-sourced URL with a managed endpoint before it touches production.

Chainstack pricing for Ethereum RPC

Chainstack bills on request units rather than opaque compute credits, which makes monthly cost straightforward to model against your deposit-scan and reconciliation volume. See the full Chainstack pricing page for plan details and overage rates.

Plan	Cost	Requests/Month	RPS	Overage (per 1M extra)
Developer	$0	3M RU	25	$20
Growth	$49	20M RU	250	$15
Pro	$199	80M RU	400	$12.50
Business	$499	200M RU	600	$10
Enterprise	$990+	400M+ RU	Unlimited	$5

Archive calls are billed at 2 request units each, so reconciliation-heavy workloads should size their plan with archive read volume in mind. For predictable, high-throughput deposit scanning, the Unlimited Node add-on (from $149/mo) removes per-request metering, and Dedicated Nodes (from $0.50/hour plus storage) provide isolated infrastructure with custom SLAs for institutions that require single-tenant deployments.

How to estimate monthly cost

1. Count your active deposit addresses and the polling or subscription frequency per address
2. Add archive read volume for daily reconciliation and periodic proof-of-reserves snapshots (remember archive calls cost 2 RU each)
3. Factor in trace calls for internal-transfer detection on every block you scan
4. Add a buffer for audit periods and month-end reporting bursts
5. Custodians see the sharpest cost spikes during market volatility and quarter-end NAV runs — size for your peak reconciliation day, not your average, because that is the day an undersized plan throttles exactly when accuracy matters most

Production readiness checklist

• Primary + fallback RPC provider configured
• Request timeout policy set
• Retry logic with exponential backoff implemented
• Credentials stored in env/secret manager (never hardcoded)
• Monitoring for latency, error rate, and throttling
• Alerts for sustained degradation
• debug/trace methods (trace_block, debug_traceTransaction) confirmed enabled on your provider before launch
• Deposit detection covers internal transactions via traces, not just Transfer logs
• Finality policy defined: credit on the finalized tag with a documented confirmation depth and reorg handling
• Archive access confirmed for historical reconciliation and audit backfills

Troubleshooting common Ethereum RPC issues

Issue	Cause	How to fix
429 Too Many Requests	Public endpoint rate limit	Move to a managed endpoint with a defined RPS tier
Missed deposits despite no errors	Funds arrived via internal transaction (no Transfer log)	Scan with trace_block / debug_traceBlockByNumber, not only eth_getLogs
eth_getLogs returns “query returned more than 10000 results” or range error	Block range or result cap exceeded	Paginate into smaller ranges and query against an endpoint that supports 10,000-block ranges
the method debug_traceTransaction does not exist	Trace namespace disabled on public endpoint	Use a managed node with debug & trace enabled
Deposit credited then disappears	Chain reorg before finality	Credit only on the finalized tag; set a confirmation depth
WebSocket disconnects	Idle timeout or network drop	Add reconnect/heartbeat logic and backfill missed blocks on reconnect

Conclusion

The expensive failure for a custodian is not downtime — it is the deposit you never saw. An ETH transfer that lands through a contract’s internal call leaves no Transfer log behind, so an endpoint without trace access reports a clean sync while your ledger quietly drifts from the chain. You don’t get an error. You get a reconciliation break that surfaces during an audit, when reconstructing what happened is hardest and the reputational cost is highest.

The pattern that works is not complicated, but it is non-negotiable. Detect deposits with trace methods, not just logs. Credit on the finalized tag with a documented confirmation depth so a reorg never reverses a credited balance. Keep an archive node as your system of record for reconciliation and proof-of-reserves. And put it all behind a provider that has already passed SOC 2 Type II and ISO 27001 audit, because for a regulated custodian the security review is the first gate, not the last.

Start on the free tier to validate trace and archive access against your reconciliation logic, then move to Dedicated Nodes when you need single-tenant infrastructure and a custom SLA.

FAQ

How do I detect deposits that arrive as internal transactions on Ethereum? Internal transfers — ETH moved by a contract during execution — do not emit a Transfer log, so eth_getLogs alone will miss them. You need trace methods like trace_block or debug_traceBlockByNumber, which replay each block’s execution and expose every value movement. These methods are not available on public endpoints, which is the single most important reason a custodian cannot rely on a public Ethereum endpoint for deposit detection.

Do I need an archive node for custody reconciliation? Yes, for anything beyond recent history. A full node prunes old state, so reconstructing a balance at a past block for NAV calculation, audit response, or proof-of-reserves requires archive access. On Chainstack, archive calls are billed at 2 request units each, so size your plan with reconciliation volume in mind.

How does Ethereum finality affect when a custodian should credit a deposit? Ethereum reaches finality roughly two epochs (about 13 minutes) after a block, after which it cannot be reverted without an extraordinary economic penalty. Crediting a deposit on an unfinalized block risks a reorg reversing it, so custodians should credit on the finalized block tag with a documented confirmation policy rather than on first inclusion.

Does Chainstack meet institutional vendor security requirements? Chainstack holds SOC 2 Type II and ISO 27001 certification and supports role-based access control, SSO, and TLS encryption — the control categories asset managers and custodians audit during third-party vendor risk review. A provider without SOC 2 Type II and ISO 27001 typically does not clear the initial security screening regardless of technical capability.

Which SDKs work with an Ethereum RPC endpoint? Any standard Ethereum library — ethers.js, web3.js, viem, or web3.py — works against a managed endpoint over both HTTPS and WebSocket. For custody workloads, confirm your library exposes the debug/trace namespace and supports WebSocket subscriptions for real-time deposit monitoring.

Is a public Ethereum endpoint ever enough for an asset manager? Only for development and testing. Public endpoints throttle eth_getLogs, disable trace methods, provide no archive depth, and carry no SLA or security attestation — so they fail both the completeness requirement for reconciliation and the vendor due-diligence gate before they ever reach production.

Additional resources

• Tracking some Bored Apes: the Ethereum event logs tutorial — hands-on eth_getLogs and event filtering on Chainstack
• Chainstack Ethereum tooling documentation — SDK setup and connection patterns
• Understanding eth_getLogs limitations — block-range caps and pagination strategy
• Ethereum JSON-RPC API documentation — official method reference
• Debug and Trace API for Ethereum — trace method reference for internal-transfer detection
• More Ethereum tutorials and articles on the Chainstack Blog