How to get an Ethereum RPC endpoint for DeFi in 2026

TL;DR

The moment your DeFi protocol broadcasts a transaction through a public Ethereum endpoint, it lands in the public mempool — where MEV searchers see your swap or liquidation before it confirms and reorder the block around it. Compounding that, a bot that reads contract state at the latest block tag is acting on data that can still reorg away, turning a “confirmed” liquidation into a loss. This guide explains how Ethereum’s public mempool and finality model shape RPC endpoint selection for DeFi, and how to deploy a private endpoint built for it.

What is an Ethereum RPC endpoint for DeFi

An Ethereum RPC endpoint is the JSON-RPC 2.0 interface your DeFi application uses to read chain state, submit transactions, and stream events from an Ethereum execution client over HTTPS or WebSocket. Every interaction a DeFi protocol has with the chain — pricing collateral, scanning for liquidatable positions, executing a swap, confirming settlement — is an RPC call against eth_call, eth_getLogs, eth_sendRawTransaction, and the subscription methods. The endpoint is the boundary between your strategy code and the validator set actually building blocks.

On Ethereum specifically, the user-facing DeFi actions that depend on the endpoint include:

• eth_call for price oracle reads, collateral-ratio and health-factor checks, and any view-function query against a lending or AMM contract
• eth_getLogs for scanning Swap, Transfer, Sync, and liquidation events across block ranges — the backbone of position tracking and price-feed indexing
• eth_subscribe over WebSocket for newHeads and logs streams, so a liquidation bot reacts to a new block instead of polling for it
• eth_sendRawTransaction to broadcast signed swaps, liquidations, and arbitrage bundles
• eth_getTransactionReceipt to confirm settlement, read at the correct block tag for the financial stakes involved
• debug_traceTransaction and the trace_* family for reconstructing historical trade paths and backtesting strategies

You can review the full list of supported JSON-RPC methods and block tags in the Ethereum developer documentation.

For DeFi, endpoint quality is not a latency nicety — it decides whether your protocol acts on correct or stale finality state. A shared endpoint that lags by even a few blocks during a volatility spike can hand your liquidation bot a position that already moved, or feed your AMM router a price the chain has since revised in a reorg.

Why DeFi on Ethereum demands more from your RPC endpoint

Ethereum’s base layer was not built to make DeFi infrastructure easy. Two properties define almost every hard RPC decision a DeFi team makes, and neither shows up until you are under real load.

The first is the public mempool. Unlike an L2 with a private sequencer queue, every transaction you broadcast to Ethereum mainnet is visible to the entire searcher ecosystem the instant it propagates. A profitable swap or liquidation you submit through a generic public endpoint is a public signal — searchers can sandwich it, front-run it, or back-run it before it is included. The endpoint you broadcast through, and whether it offers a private transaction or MEV-protected submission path, is therefore a direct economic decision, not a connectivity one.

The second is finality semantics. Ethereum’s Proof-of-Stake chain exposes three block tags that matter for DeFi:

• latest — the most recent proposed block. Fast, but it can be reorged out. Safe for read-only UI, dangerous for money movement.
• safe — the latest justified block (roughly one epoch, ~6.4 minutes). A reasonable threshold for most settlement logic.
• finalized — the latest finalized block (roughly two epochs, ~12.8 minutes). Irreversible under normal conditions; the correct tag for releasing collateral or crediting bridged funds.

A protocol that reads collateral state at latest to trigger a liquidation, then has that block reorged, has acted on data that no longer exists — and the bug surfaces as an accounting discrepancy, not an error log. Layer on Ethereum’s 12-second block time, which sets the natural polling cadence, and the heavy weight of eth_getLogs queries that back up first when every DeFi protocol on the network scans for the same liquidation events simultaneously, and you have a workload that punishes shared infrastructure precisely when the stakes peak. Chainstack’s reliable RPC infrastructure for DeFi is built around these exact pressure points — dedicated resources, faster transaction propagation, and managed subgraphs for protocols like Uniswap, Aave, and Compound.

Ethereum RPC endpoint options

Public vs private Ethereum RPC endpoints

The public-versus-private decision on Ethereum is really a decision about whether you can tolerate broadcasting DeFi transactions into a shared mempool over a throttled connection — during the exact market events that make your protocol money. Public endpoints are fine for reading a balance on a testnet. They are the wrong tool the moment a liquidation cascade has every bot on the network hammering the same nodes.

There is no official Ethereum Foundation public RPC for mainnet. The endpoints developers reach for are community-run, with no reliability guarantee and aggressive throttling:

• Mainnet (community): https://ethereum-rpc.publicnode.com , https://eth.llamarpc.com
• Sepolia testnet: https://ethereum-sepolia-rpc.publicnode.com
• Hoodi testnet (validator/staking): https://ethereum-hoodi-rpc.publicnode.com

⚠️ Public Ethereum endpoints typically cap you at roughly 100 requests per minute and offer no private transaction submission. A DeFi aggregator polling prices across pools, or an indexer running eth_getLogs across thousands of blocks, exhausts that budget in seconds and starts receiving 429 Too Many Requests — and every transaction it sends is fully exposed in the public mempool. Because there is no official mainnet public RPC, the Ethereum docs themselves point developers toward running a node or using a node service for production access.

Factor	Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
Rate limit	~100 req/min, throttled	No aggressive throttling
eth_getLogs at scale	Times out under wide ranges	Flat latency on dedicated nodes
Transaction privacy	Public mempool only	Private/MEV-protected submission available
Archive access	Not available	Available

📖 For a detailed comparison of Ethereum RPC providers, see Best Ethereum RPC providers in 2026.

When a single liquidation event can 10x your request volume and turn every broadcast into MEV bait, a shared public endpoint is not a smaller version of production infrastructure — it is a different category of thing that happens to share an API.

Full node vs archive Ethereum node

For DeFi, the line between a full node and an archive node is the line between knowing what a position is worth now and knowing what it was worth at every block in its history. A full node serves current and recent state — enough to price collateral, route a swap, and trigger a liquidation. An archive node retains the full historical state trie, which DeFi analytics depend on.

Full node access	Archive node access
Real-time price feeds and oracle reads	Historical eth_getLogs backfills beyond the pruning window
Current collateral and health-factor checks	TVL and liquidity reconstruction across a pool’s lifetime
Live swap and liquidation execution	LP fee-accumulation and impermanent-loss accounting
Recent event subscriptions	Strategy backtesting via debug_traceTransaction replay

Chainstack supports Ethereum archive nodes, billed at 2 request units per call versus 1 for a full node. If your DeFi product computes historical APYs, reconstructs a vault’s deposit flows, or has to answer “what was this position worth at block N,” archive access is not optional — a full node will have pruned the state you need.

HTTPS vs WebSockets

For a liquidation bot, the difference between HTTPS polling and a WebSocket subscription is the difference between asking “is there a new block yet?” twelve times a minute and being told the instant one arrives. On a 12-second block chain, polling wastes requests between blocks and adds latency at exactly the moment a new block reveals a liquidatable position.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	eth_call reads, tx broadcast, backfills	newHeads + logs streams for liquidation bots and price feeds
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

Chainstack Ethereum endpoints expose both HTTPS and WebSocket URLs. For event-driven DeFi — watching Swap logs, reacting to new heads, streaming oracle updates — a WebSocket eth_subscribe stream replaces a polling loop and removes the per-request overhead that compounds across thousands of daily reads.

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: Mainnet or Sepolia / Hoodi testnet
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. Once your endpoint is live, the connection setup with ethers.js — the most common Ethereum SDK — looks like this:

import { ethers } from 'ethers';

// HTTPS provider for reads and transaction broadcast
const provider = new ethers.JsonRpcProvider("YOUR_CHAINSTACK_ENDPOINT");

// Read at the 'finalized' tag for settlement-critical DeFi logic,
// not 'latest', which can still be reorged out
const block = await provider.getBlock("finalized");
console.log(block.number);

📖 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, which is convenient for adding the network to MetaMask and other wallets with one click. But Chainlist is a network directory, not an infrastructure provider — the RPC URLs it surfaces are public or community endpoints with the same throttling and mempool exposure described above. Any URL you pull from Chainlist should be swapped for a managed endpoint before your DeFi protocol sees production traffic.

Chainstack pricing for Ethereum RPC

Chainstack bills on a request-unit model, which makes DeFi cost forecasting far more predictable than the compute-unit schemes where a single heavy eth_getLogs call can cost an unknown multiple of a simple read. A full-node request is 1 RU; an archive request is 2 RU. See the full Chainstack pricing page for plan details and overage rates.

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

For high-throughput DeFi workloads, two add-ons matter. The Unlimited Node offers flat-fee, RPS-tiered access with no per-request metering — useful when an indexer’s request volume is hard to cap. Dedicated Nodes (from $0.50/hour plus storage, available from the Pro plan) give you isolated resources for latency-sensitive liquidation and arbitrage strategies.

How to estimate monthly cost

1. Count baseline reads per second across all your services (price polling, health-factor checks, balance reads)
2. Add event-subscription load — each logs stream and newHeads consumer
3. Factor archive calls at 2 RU each if you run analytics or backtesting
4. Convert to monthly request units and match against a plan tier
5. Buffer for volatility: a liquidation cascade can multiply DeFi RPC load several times over in minutes, and eth_getLogs scanning spikes alongside it — size for the worst day, not the average one

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
• Block-tag policy enforced in code: finalized for collateral release and settlement, safe for most financial logic, latest for UI only
• MEV-protected or private transaction submission path configured for value-bearing broadcasts
• eth_getLogs block ranges capped (5,000 blocks per request on Ethereum) and paginated to avoid timeouts

Troubleshooting common Ethereum RPC issues for DeFi

Issue	Likely cause	How to fix
429 Too Many Requests during volatility	Public endpoint rate limit under concurrent load	Move to a managed private endpoint with dedicated RPS
WebSocket disconnects mid-subscription	Provider-side timeout or missing heartbeat	Implement reconnect with exponential backoff and resubscribe
Transaction confirmed but financial state wrong	Read at latest and the block reorged	Read settlement-critical state at safe or finalized
Your swap or liquidation gets front-run	Broadcast into the public mempool	Route value-bearing transactions through a private/MEV-protected submission path
eth_getLogs returns empty or times out	Block range too wide for one query	Cap to 5,000 blocks per request and paginate
Archive query returns missing/stale state	Node is full, not archive — state was pruned	Deploy an archive node for historical reads

Conclusion

The transactions that lose money on Ethereum DeFi rarely fail loudly. A liquidation triggered on a latest-tag read that gets reorged doesn’t throw an error — it books a position that the chain no longer agrees exists, and you find out during reconciliation. A profitable swap broadcast through a public endpoint doesn’t bounce — it gets sandwiched, and the slippage looks like ordinary market movement until you trace it. Both failures are quiet, both are infrastructure decisions in disguise, and both compound exactly when volume spikes.

The pattern that works is not complicated, but it is non-negotiable. Read settlement-critical state at finalized, never latest. Broadcast value-bearing transactions through a private submission path, never the open mempool. Run those reads and broadcasts over a dedicated endpoint with headroom for the worst day, with a fallback provider behind it. Public infrastructure cannot give you any of the three, and discovering that during a liquidation cascade is the most expensive way to learn it.

Start on the free Developer tier to wire up your block-tag policy and event subscriptions, then move to dedicated infrastructure before your protocol holds real value.

FAQ

Which block tag should my DeFi protocol read for settlement? Use finalized for anything that moves or releases funds — collateral release, bridge credits, payout logic — because it is irreversible under normal conditions. Use safe for most other financial reads where a ~6.4-minute lag is acceptable. Reserve latest for read-only UI, never for money movement: a latest read can be reorged out from under you, and acting on it is the most common silent accounting bug in Ethereum DeFi.

Why does my swap or liquidation keep getting front-run on Ethereum? Because Ethereum has a public mempool. Every transaction you broadcast through a standard endpoint is visible to MEV searchers before it is included in a block, and a profitable DeFi action is an open invitation to be sandwiched or front-run. The fix is to route value-bearing transactions through a private or MEV-protected submission path rather than broadcasting into the open mempool — an endpoint-level decision, not a contract change.

Are public Ethereum endpoints good enough for a DeFi app? For development and testing, yes. For production, no — there is no official Ethereum Foundation mainnet public RPC, community endpoints cap around 100 requests per minute, and they offer no private transaction submission. A DeFi aggregator polling prices or an indexer scanning eth_getLogs exhausts that budget in seconds and starts seeing 429s during the volatility windows that matter most.

Do I need an archive node for DeFi on Ethereum? Only if you query historical state. Real-time pricing, health-factor checks, and live execution run fine on a full node. But reconstructing a pool’s TVL history, computing LP fee accumulation over a position’s lifetime, backfilling eth_getLogs beyond the pruning window, or backtesting a strategy all require an archive node, since a full node prunes older state.

How do I avoid eth_getLogs timeouts when indexing DeFi events? Cap each query to about 5,000 blocks on Ethereum and paginate across the range rather than requesting a huge span in one call. eth_getLogs is among the heaviest method types and is the first to back up on shared endpoints during liquidation cascades, so a dedicated endpoint plus disciplined block-range chunking keeps query latency flat regardless of network conditions.

Which SDKs and tools work with a Chainstack Ethereum endpoint? Any standard Ethereum library: ethers.js (most common), web3.js, and viem for TypeScript-first projects. For DeFi data pipelines, you can also index protocols like Uniswap with subgraphs against your Chainstack endpoint. All of them connect to the HTTPS and WebSocket URLs from your node’s credentials with no Ethereum-specific configuration beyond the endpoint string.

Additional resources

• Ethereum logs tutorial series: logs and filters — eth_getLogs and event filtering in depth
• Chainstack Ethereum tooling documentation
• Understanding eth_getLogs limitations — block-range caps and pagination for DeFi indexing
• How Stobix survived crypto’s biggest liquidation cascade — DeFi infrastructure under real market stress
• More Ethereum tutorials and articles on the Chainstack Blog