API in Blockchain Architectures: When to Use Gateways vs Direct Node Access

A lot of decision-makers come to us with the same burning question: "Should we use a hosted RPC gateway like Infura, Alchemy, QuickNode, Chainstack, or Cloudflare, or should we just set up and manage our own nodes?" Well, you’re in luck! This guide is here to provide you with a straightforward, up-to-date framework to help you make the best choice for your needs.
We're going to dive into the trade-offs between cost, latency, reliability, security, and data consistency. Plus, I've got some handy patterns lined up that you can start using this quarter. Can't wait to share them with you!

Who this is for

Hey there, startup CTOs! If you’re getting ready to launch your mainnet MVP and are looking to scale up, this is for you! Enterprise platform leaders are diving into the world of digital wallets, exchanges, analytics, and tokenized assets, all with the goal of making them compatible across different blockchain networks. Product managers are working hard to find the sweet spots for balancing latency, cost, and reliability. They're diving into the details to figure out where to set those limits just right.

Gateways vs direct nodes: what each actually gives you

Gateways are basically managed RPC platforms.
- Pros: They provide flexible capacity, smart global routing, efficient caching, automatic retries, and rate-limiting. All of this adds up to a much smoother experience for you.
You’ll have access to a ton of cool extra APIs, including ones for NFTs, tokens, account abstraction, subgraphs, webhooks, gRPC, and plenty more. Oh, and they also include SLAs and security attestations like SOC and ISO, which is awesome for the procurement process! (quicknode.com).
- Cons: Hey, just a heads up! When you’re diving into this, keep in mind that there are a few method caps and pricing units for each method you’ll need to think about. Some namespaces or heavier calls might have limitations--like how eth_getLogs has range limits and there are some restrictions on txpool and trace depending on your provider or the plan you’re on. It’s worth checking those details! (alchemy.com). Sometimes, the infrastructure can seem a bit murky. It really depends on the mix of providers and clients, and those edge cases can differ quite a bit.
Direct Node Access: This means you can get right into your own cluster or use dedicated nodes from a provider.
- Pros: You have total control over the client, the version, and the flags. On top of that, it delivers solid performance for those heavy-duty tasks such as tracing, debugging, txpool, and GraphQL. (geth.ethereum.org). The data semantics are pretty straightforward, which makes it easier to set up strict block-pinning (EIP‑1898) and handle reorganizations in a consistent way. (eips.ethereum.org).
- Cons: Yeah, there's definitely a lot to manage here. You have to think about syncing everything, keeping up with upgrades, monitoring the system, dealing with storage growth, and being ready to handle any incidents that come up. It's quite a bit of work! You'll want to invest in some high-performance hardware--like NVMe drives and a focus on IOPS. Plus, it's really important to do some solid capacity planning to handle those unexpected spikes that can pop up. (docs.nethermind.io).

The 8-signal decision framework

When most of these signals are showing "true," it's a good idea to use gateways. On the flip side, if they’re mostly "false," then you might want to go for direct node access instead. ”.

1. Traffic volatility: You know those sudden spikes and changes in traffic that can catch you off guard? Having gateway autoscaling and global routing really helps you handle those situations like a pro. Many providers love to boast about their 99. You’ve got 99% uptime SLAs and multi-region routing, which is pretty solid. But hey, it never hurts to take a quick peek at the current SLA terms just to be sure! (blog.quicknode.com).

2. Chain diversity: If you’re diving into multi-chain projects--think EVM, Solana, and the latest Layer 2 solutions--look for platforms that back 60 to 70+ chains. They can seriously boost your workflow, and a lot of them come with some handy extra data services too. (alchemy.com).

3. Method mix: If you're depending a lot on eth_getLogs to pull in large ranges, and you're also using trace/debug or txpool, it’s probably a good idea to go with direct nodes or dedicated plans for better reliability. A lot of gateway tiers usually have limits on ranges or place restrictions on using heavier methods. (alchemy.com).

4. Deterministic reads: Looking to capture the precise historical state during reorgs or forks? You might want to check out EIP-1898! By using single-client, single-region direct nodes, you can really hone in on those crucial paths. It’s a solid way to make sure you get the reliability you need. (eips.ethereum.org).

5. Write-path needs: When figuring out your mempool strategy--whether you're going public or keeping it private--plus considering MEV protection and how you’re routing your builders, you’ll often find yourself gravitating toward specialized endpoints like Flashbots Protect or MEV-Blocker. These tools can really help, even if they don’t follow the usual RPC gateway setup. (docs.flashbots.net).

6. Compliance & Procurement: When it comes to businesses, having SOC 2 or ISO certifications and getting that VIP support is really important. It’s almost non-negotiable for many enterprises! Fortunately, a lot of gateways--and even some providers with dedicated managed nodes--have got that all sorted out from the start. (quicknode.com).

7. Cost profile: If your reads tend to spike or if you're working with more complicated methods, switching to dedicated nodes with a flat rate could actually end up being cheaper than using the CU/credit models. On the other hand, if your site sees low to medium traffic consistently, then PAYG CUs might be the way to go for keeping costs down. (alchemy.com).

8. Talent & Ops: If your SREs aren’t quite ready to tackle a mix of client issues, snapshot repairs, and observability tools, it might be smarter to go with gateways or dedicated managed nodes for now.

Current realities (end of 2025): facts worth knowing

Latency and routing claims can definitely differ quite a bit from one provider to another. For example, QuickNode shares some live benchmarks via QuickLee that give us the scoop on p95s from different providers. Just a heads-up, though--these numbers are self-reported! A bunch of providers like to brag about getting global read times under 100 ms, but it really depends on where you are and the method you pick. Hey, just a heads-up--before you jump in, it's a good idea to double-check the details for your specific area and the methods you're planning to use. (blog.quicknode.com).

Alchemy's got a PAYG plan lined up for 2025, and the pricing is based on Compute Units. Pretty straightforward, right? They actually have these cool tables that break down the cost of different methods in CUs. For example, if you use eth_call, it’ll use about 26 CUs, while eth_blockNumber will only set you back 10 CUs. Plus, they measure how fast things are moving in CUPs! If you stick to lighter methods, this can really help save you some cash. But just a heads-up--things can get a little tricky when it comes to handling heavier logs and traces. (alchemy.com).

Hey, if you're wondering how reliable Infura really is, you can check out their public status page. It shows real-time uptime stats, and you'll notice that it might drop below 100% for specific transports, like mainnet HTTPS, over the last three months. Think of “four nines” as a great target to shoot for, but it's a good idea to build your system with failover in mind just in case. (status.infura.io).

Ankr’s PAYG model lets you pay for what you use, charging you a little bit for each request--roughly around $0. You'll need 00002 for every EVM HTTPS request you make. This could be a great go-to for your cost modeling! (ankr.com).

Cloudflare’s Ethereum Gateway is actually really cool! It stores read data right at the edge, which speeds things up, while it handles writes by sending them to its nodes. Pretty smart, right? Think of it like a surge protector for your hybrid setups--it’s really handy! (developers.cloudflare.com).

Data correctness and method-level nuance (don’t skip this)

Keep your reads pinned: Don't forget to utilize EIP-1898’s “blockHash” when you're working with methods like eth_call and getProof. It’s a helpful little trick! With this approach, you can always rely on the state you’re checking, even when there are reorganizations happening, regardless of how your provider is handling the routing. Take a look at this: eips.ethereum.org. You might find it interesting!
Keep an eye on eth_getLogs limits: Just a heads up, some providers have their own rules when it comes to block ranges or how much data you can request at once. For instance, Alchemy has some pretty cool options. They offer unlimited ranges for certain chains, and you can choose either a pay-as-you-go plan or an enterprise plan. Just a heads up, though--there's a 150 MB limit on responses. You know, it’s pretty smart to create windowed queries and then organize them by address or topic. Plus, don’t forget to paginate your results--it makes everything way easier to navigate! More info here: (alchemy.com).
Watch out for those heavy namespaces: You might find that the trace/debug and txpool namespaces are sometimes locked behind paywalls, turned off, or even slowed down on shared endpoints. Just something to keep in mind! If you find yourself in a situation where you really need to use those namespaces, think about managing the node on your own, either by hosting it yourself or picking a plan that clearly backs them up. Check this out: (besu.hyperledger.org).
Why standardization is key: The EIP-1474 and the Execution APIs repo really help you get a good grasp on how JSON-RPC is supposed to work. Just remember, though, that there are still a few quirks between different clients that you might run into. Be sure to run some tests with the real clients you’re planning to use in production, like Geth, Nethermind, Erigon, and Besu. It’s super important to check how they perform in practice! More details here: (eips.ethereum.org).

Performance and hardware: what “direct node access” really entails

Here's a general idea of what to expect for 2025 when it comes to Ethereum mainnet execution clients. Just a heads up, actual metrics might shift from month to month, so keep that in mind!

Erigon 3 (full): So, if you're planning to use the full version, you’re looking at around 920 GB of storage. And if you want the archive option, that's going to take about 1 TB. 77 TB. If you're looking to set things up right, go for NVMe storage--it really makes a difference. As for RAM, you'll want between 16 and 64 GB, depending on how you're planning to use it. For all the info you need, just click here. It's all laid out for you!
Nethermind (the whole package): So, if you're considering setting it up alongside a consensus client, you should probably budget around 2 TB of space in total. When it comes to the archive, you're looking at around 14 TB of data. Just keep in mind, that number can change a bit depending on which client you decide to go with. If you want top-notch performance, it's definitely worth considering high IOPS NVMe drives that push over 10k. Trust me, you'll notice the difference! If you want to dig deeper, you can find more info over here.
Geth is still holding it down for you with GraphQL (EIP‑1767), which really makes it easy to run efficient multi-field queries. Don’t forget to turn it on specifically. For more info, just check this out here.

Operational Must-Haves:

Hey, just a quick reminder to get your Prometheus and Grafana metrics up and running for your clients. Both Geth and Nethermind really excel at providing great support, so you'll definitely want to take advantage of that! Feel free to take a look at it here! Make sure you’ve got a good snapshot and checkpoint sync strategy set up. It’s also smart to have a few warm spares ready to go in a different availability zone or region, just in case you need to failover quickly.

Get your log ingestion up and running, and set up alerts for stuff like peer counts, head lag, pruning, database growth, and RPC latency. You'll want to keep an eye on these things!

Security, compliance, and private connectivity

When it comes to enterprise procurement, having SOC 2 and ISO attestations is really crucial. For example, QuickNode has scored some impressive certifications like SOC 1/2 Type 2 and ISO/IEC 27001. On the other hand, Blockdaemon is pretty proud of their SOC 2 Type II and ISO 27001 certifications too. Pretty cool, right? Don't forget to take a peek at their trust portals and ask for the most recent reports while you’re at it! (quicknode.com). Hey, if you're working with AWS, you might want to check out PrivateLink from certain providers, like Chainstack. It's definitely worth considering! It can definitely help cut down on latency and avoid going through public egress. (docs.chainstack.com). Hey, make sure you pay attention to all the buzz about regional routing and data residency. It's definitely worth keeping in mind! You really need to make it a point to chat with your InfoSec team right from the start! It’s turning into a pretty essential discussion.

MEV-aware write paths

Hey there, Ethereum users! If you want to keep your transactions safe from those pesky frontrunning or sandwich attacks, here’s a little tip: use a private order flow like Flashbots Protect RPC for your write transactions. For your read transactions, you can stick with your usual RPC. It’s a simple way to add an extra layer of protection! Hey, just wanted to give you a quick heads up! Flashbots has dropped some news about changes to their API and batching, so it’s a good idea to stay on top of those timelines. You don’t want any surprises catching you off guard! Hey, if you want to dive deeper into the details, just hop over to this link: docs.flashbots.net. It's got all the info you need! Hey, have you thought about checking out some other Order Flow Agents (OFAs)? MEV-Blocker is a solid option you might want to consider! They can really speed up the inclusion process and might even throw in some rebates. Take a moment to think about the ups and downs of user experience, especially when it comes to landing times, and how it stacks up against any chances of being exposed to the public mempool. For more details, just check out this link: docs.cow.fi. You'll find all the info you need there!

Cost modeling: two quick examples

Just to clarify, these examples aren't meant to be recommendations. They’re here to help you figure out how to estimate your expenses.

If you're gearing up to tackle some serious read-heavy EVM analytics--think about 50 million calls every month--here’s what you need to know:

Ankr PAYG: When you crunch the numbers, that adds up to 50 million calls at a cost of $0. Pretty impressive, right? So, that's about $0.00002 each, which ends up being around $1,000 a month just for HTTPS alone. And that’s not even factoring in any egress or networking costs! For more info, just swing by ankr.com. You’ll find all the details you need there! Alright, so when you're using Alchemy PAYG, you'll need to turn your requests into CUs depending on the methods you choose. Just to give you a rough idea, asking for eth_blockNumber usually costs about 10 CUs, while an eth_call will set you back around 26 CUs. And when it comes to getLogs, the CU cost can really vary. Just keep that in mind as you’re planning your moves! Their pricing starts at absolutely zero dollars. It's at 45 per million CUs, but then it drops down to zero. Once you reach 300 million CUs, it’s going to be 40 per million from there on out. Your bill is really going to depend on the mix of CUs you have. So, it’s a good idea to take a closer look at their CU tables to get a clearer estimate. If you're looking for more details, check out alchemy.com. They’ve got a bunch of info that might help you out!

2) Trace/txpool-intensive debugging:

When you're diving into debugging, having direct nodes--whether they're dedicated or self-hosted--can really give you an edge. That's mainly because shared endpoints usually limit the amount of access you get to trace/txpool, or they can be pretty pricey. Having a set monthly fee for a dedicated node brings a whole lot of predictability to the table. If you're going with managed gateways, definitely take a moment to check out the per-method multipliers and SLAs. They can make a big difference! If you're looking for more details, check out docs.chainstack.com. They’ve got a lot of helpful info there!

Three production-ready architecture patterns

Pattern A -- “Gateway-first with deterministic reads”

Great for: wallets, NFT marketplaces, and big consumer apps.

Reads: Go ahead and use the main RPC gateway, and don’t forget to set up retries and block-tag pinning while you’re at it! When it comes to log ingestion, I'd definitely recommend using windowed eth_getLogs. Also, if you have the chance, use webhooks or subscriptions--they can make things a lot smoother! (alchemy.com).
Writes: Generally, it's best to stick with the regular public mempool for most situations. If you're handling sensitive transactions, like DEX swaps, you'd definitely want to switch to Flashbots Protect RPC. It adds an extra layer of security that's worth it! (docs.flashbots.net).
Fallback: It's a good idea to keep a backup provider endpoint on hand, just in case. Plus, having a lightweight Cloudflare Ethereum Gateway can really help when there's a surge in traffic by allowing for quick reads and caching. (developers.cloudflare.com).

Code sketch (Node.js/ethers v6):

Sure! Here's a quick code example to show you how to get started with Node.js and ethers v6. It's pretty straightforward!

Setting Up

Alright, before we dive in, just double-check that you've got Node.js installed on your machine. It’s a must-have for what we’re about to do! You can grab it over at the Node.js official website. Happy downloading! Once you’ve got everything ready, just go ahead and install the ethers package:

npm install ethers

Basic Example

Let me give you a quick example to help you get the ball rolling.

const { ethers } = require('ethers');

// Connect to the Ethereum network
const provider = new ethers.providers.InfuraProvider('homestead', 'YOUR_INFURA_PROJECT_ID');

// Fetch the current block number
async function getBlockNumber() {
    const blockNumber = await provider.getBlockNumber();
    console.log(`Current Block Number: ${blockNumber}`);
}

getBlockNumber();

Interacting with a Smart Contract

Alright, so let’s imagine you’re looking to engage with a smart contract. Here’s how you can go about it:

const contractAddress = 'YOUR_CONTRACT_ADDRESS';
const abi = [
    // Replace with your contract's ABI
];

const contract = new ethers.Contract(contractAddress, abi, provider);

// Call a read-only function
async function getData() {
    const data = await contract.readFunctionName(); // Change to your actual function name
    console.log(`Data from smart contract: ${data}`);
}

getData();

Sending Transactions

Before you can send a transaction, you’ll need to get your wallet set up first.

const wallet = new ethers.Wallet('YOUR_PRIVATE_KEY', provider);

async function sendTransaction() {
    const tx = {
        to: 'RECIPIENT_ADDRESS',
        value: ethers.utils.parseEther('0.1'), // Amount in ETH
    };

    const transactionResponse = await wallet.sendTransaction(tx);
    console.log(`Transaction hash: ${transactionResponse.hash}`);
}

sendTransaction();

Conclusion

And that's a wrap! You've got a simple overview of how to use Node.js with ethers v6 to chat with the Ethereum blockchain. Pretty cool, right? Don't forget to swap out those placeholders with your real info! Happy coding!.

import { FallbackProvider, JsonRpcProvider } from "ethers";

const providers = [
  new JsonRpcProvider(process.env.RPC_PRIMARY),
  new JsonRpcProvider(process.env.RPC_SECONDARY),
  // optional surge-protector read path
  new JsonRpcProvider("https://cloudflare-eth.com")
];

export const rpc = new FallbackProvider(providers, 1); // quorum 1

// Deterministic read pinned to blockHash (EIP-1898)
export async function safeCall(callData, blockHash) {
  return rpc.send("eth_call", [callData, { blockHash }]); // reorg-stable
}

Pattern B -- “Direct-node core with gateway burst buffer”

Perfect for: exchanges, risk engines, and indexers that need a steady and reliable trace or txpool.

Set up two execution clients, like Erigon and Nethermind, in separate Availability Zones (AZs). Just a heads up, you’ll want to keep them restricted to your VPC only. When you're thinking about how much NVMe you need, make sure to take a good look at what you need right now as well as what you might need down the road. (docs.erigon.tech). Hey, don’t forget to activate the Prometheus metrics! It’s super important to set up alerts for head lag, RPC latency, and database size too. You'll want to keep an eye on these things! This will help you keep track of how things are going. (geth.ethereum.org).
Consider setting up a managed gateway specifically for handling overflow reads and making sure your data is distributed globally. When you're working on write-paths, be sure to send them through Protect RPC, especially if keeping users safe is a top concern. It's really important to prioritize their safety! (docs.flashbots.net).

Example Erigon Flags (Storage-Optimized):

Check out these helpful Erigon flags that can really boost your storage setup!

--storage.cache=2G: This sets aside 2GB just for caching purposes. Feel free to adjust the value according to what you have on hand.
--prune=full: This option will get rid of all the old data and just hold onto the really important stuff.
--max-ancestors=20: This setting keeps the number of ancestor blocks to a maximum of 20. Feel free to tweak this however you like!
--db.goroutine=8: This option lets you set how many goroutines you want to use for your database operations, and in this case, it's set to 8. Adding more goroutines can definitely give you a speed boost, but just keep an eye on how much resources you’re using! If you're looking to free up some disk space, you can turn off snapshots by using --snapshot=false. Just a heads up--it could affect how things perform.

Go ahead and play around with these flags until you find the setup that works best for your storage needs! Have fun experimenting!

erigon \
  --chain mainnet \
  --http --ws --private.api.addr=127.0.0.1:9090 \
  --db.pagesize=16k \
  --prune=hrtc \
  --authrpc.addr=0.0.0.0 --authrpc.jwtsecret=/secrets/jwt.hex

Take a look at the client’s current hardware guidelines. They’ll help you pick the best prune mode and disk to go with! For all the info you need, just check it out here!

Pattern C -- “Multi-chain hybrid (EVM + Solana)”

Great for: hopping between different blockchains, keeping track of your wallets, and staying updated with real-time insights.

Solana: If you're looking for seamless, low-latency data, definitely take a look at gRPC streams (Yellowstone/Geyser). They offer a great experience without any limits! You know, it could really help to set up some dedicated clusters to maintain a smooth throughput. Just a thought! (quicknode.com).
EVM: For regular data reads, go ahead and use a gateway. But if you need to dive deeper into trace logs or logs in general, it might be a good idea to set up a dedicated node or plan for that. If you’re using AWS, it’s worth considering private networking to help reduce latency. Trust me, it can make a noticeable difference! (docs.chainstack.com).
Just a thought: It could be beneficial to consider separating write-paths with private order flow where it feels right.

Emerging best practices (late 2025)

Block-pinning as a default: Seriously consider adding blockHash (EIP‑1898) to your state reads. It becomes super important when you're handling heavy loads or trying to reconcile balances. Trust me, it can really make a difference! This little adjustment really helps you avoid those pesky "moving target" bugs that can sneak in after a reorg. Take a look at this: (eips.ethereum.org).
Windowed logs and backfills: It's a good idea to set some limits on your ranges based on what the provider recommends. Plus, using jobs to manage backlogs helps avoid those huge single calls that can pile up with millions of logs. Let’s keep it quick and to the point! If you need more info, check this out: (alchemy.com). It’s got all the details you’re looking for!
Mempool strategy as a feature: How about throwing in a “Protected Send” option in your user interface? I think it could really enhance the experience! A lot of users are really happy that they don’t have to worry about those pesky failed transaction fees anymore. Plus, they love having some extra protection against frontrunning! Make sure to stay on top of any updates for the provider's API and keep an eye on those essential headers! Learn more here: (collective.flashbots.net).
Think Observability SLOs, not just SLAs: If you're dealing with gateways, it’s super important to keep an eye on those p95 and p99 latencies--make sure you’re breaking them down by method and region. It's definitely a smart move to check in on your benchmarks every now and then. You know how vendor claims can get a little too rosy--it's best to put them to the test and see for yourself! Check this out: (blog.quicknode.com).
Private networking: If you're working with AWS, you should definitely check out PrivateLink. It’s worth asking about! It really streamlines firewalling and helps reduce those pesky tail latency issues. If you're looking for more details, just check this out: (docs.chainstack.com). You'll find everything you need there!

Practical details you can use tomorrow

Alchemy CU Math: Take a look at Alchemy’s live table, which is basically like running eth_call for 26 CUs. Oh, and don’t forget to check out their rate card--it’s just $0! A 45-year-old male customer, dropping to zero. Hey there! Just a quick note: when you're looking at the bills in your CI for each PR, keep in mind that you'll want to scale it up to 40/M. This will help you get a clearer picture of the costs involved. Hope that helps! This way, you can prevent any merges that could send your projected monthly recurring revenue (MRR) over those limits you’ve set. (alchemy.com).
eth_getLogs Guardrails: Just a heads up--when you're working with your data layer, it's super important to set specific block ranges for each chain. For instance, with Ethereum, aim for around 2k-5k blocks per call, while for Polygon, you’ll want to keep it even lower. So, for the “new” logs, go ahead and set up subscriptions and webhooks. As for catching up on older logs, you can handle those in batches offline. (alchemy.com).
Using Cloudflare Gateway as a Read Cache: If you've got some popular data that gets accessed a lot, tapping into edge caching can seriously speed things up and save you some cash with your providers. It's a smart move to keep those hot blocks running smoothly! Just be sure to set up some solid cache keys that incorporate the block numbers. That’ll really help things run smoothly! (developers.cloudflare.com).
Txpool and Trace Access: If you're looking to get into those, your best bet is to opt for dedicated nodes or enterprise plans that specifically mention support for them. Just a heads up--it's a good idea not to make any assumptions on this! So, when you're looking at Besu, Geth, and Reth, keep in mind that each of them has its own version of the txpool. Just make sure to look into the enablement flags and authentication settings. It's definitely worth taking a minute to double-check! (besu.hyperledger.org).

Solana-specific notes (because it’s different)

If you need real-time streams for things like accounts or programs, definitely consider using gRPC. It's a solid choice! Hey, if you're aiming for top-notch performance and want to avoid any limits on data intake, it’s worth checking out dedicated Yellowstone clusters. They could really have your back! If you're thinking about shared plans, you can generally expect them to kick off at about $499 a month. Take a look at this: (quicknode.com). It's worth checking out! If you're diving into write-path latency, especially for things like trading or bots, you might want to check out some specialized endpoints. Services like “Fastlane” can really help speed things up. They make sure to include tips and priority fees while also giving you those P99 slot-latency metrics. Hey, just double-check the region placement to make sure it lines up with your setup. If you’re looking for more info, check this out: marketplace.quicknode.com. It’s got everything you need!

When a gateway is the wrong choice

If you want to keep the debug/trace/txpool accessible 24/7 without any hiccups, you'll need to be prepared to tweak the client flags yourself to get everything running smoothly.
It's really important to have a dependable method for replaying transactions in a consistent way, using the same client and data set every time. This is super important for stuff like audits and any kind of regulated reporting. So, it looks like your cost setup isn't really into those per-method multipliers--like all those big logs and traces. Instead, you’re more into keeping things simple with a flat rate for a dedicated node. (docs.chainstack.com).

When direct nodes are the wrong choice

Looks like you might be a bit stretched when it comes to your team’s capacity for upgrades, snapshots, and dealing with incidents like reorg storms and disk failures. You’ve got to stay on top of more than 60 chains and do it fast, or be prepared to switch networks whenever needed! So, you’re in a bit of a bind, huh? You need enterprise compliance and SLAs ASAP, but it looks like you don’t have a platform of your own to handle that. (quicknode.com).

Implementation checklist (copy/paste into your RFC)

Decide per-path routing:
Reads: Go with the main gateway for your read operations. If you're dealing with sensitive stuff, it's best to use deterministic reads that are tied to the blockHash. Check it out here.
Writes: Stick with the default public mempool, and when you're doing swaps or mints, make sure to use "Protected Send" through Flashbots Protect. It’s the way to go! If you want to dive deeper into the details, just check out this link here. It’s got all the info you need!
Have backup plans: Make sure you've got a backup provider lined up, and don’t forget to utilize the Cloudflare Ethereum Gateway for those times when traffic gets a bit crazy. It’s always smart to be prepared! If you want to dive deeper into this, just check it out here. You'll find some interesting info!
Heavy methods: If you're looking to do things like eth_getLogs backfills, or if you need to debug or trace transactions, it's a good idea to snag a dedicated node or go for an enterprise plan. Trust me, it makes a world of difference! If you want to dive into the details, just click here. Happy exploring!
Observability: Go ahead and fire up Prometheus. It's a great tool for tracking things like RPC latency, head lag, how many peers you've got, and even the growth of your database. It'll make monitoring a lot easier! If you want to dive deeper into it, just click here to check it out!
Cost controls: Make sure you create CU/credit budgets in your Continuous Integration (CI) setup. This way, if any builds try to go over the monthly cap, they won’t get through. It’s a great way to keep things in check! If you want to learn more about that, you can check it out here.
Compliance and Security: Don’t forget to ask for the latest SOC and ISO reports! If you’re operating in a regulated space, I’d recommend using PrivateLink for added security. If you want to dive deeper into the details, you can check it out here.

What “good” looks like in 2025

Check out this cool multi-provider FallbackProvider! It comes with block-pinned reads and windowed logs, making it super handy for your needs. We’ve got a private order flow RPC specifically set up for those sensitive writes, plus a public mempool to handle your regular transactions. (docs.flashbots.net). Here’s a neat little direct-node cluster that’s really well-tuned. It’s compact but does a fantastic job for deep analysis while keeping everything consistent. Plus, it serves as a gateway for those times you need to scale elastically. We've got Prometheus and Grafana dashboards set up that are tied to our SLOs. Plus, we’re doing routine checks on latency and accuracy across various providers to keep everything in check.
(geth.ethereum.org).

How 7Block Labs helps

We build and manage hybrid RPC setups that combine the flexibility of gateways with the dependable play of node-level determinism. Here’s a quick rundown of what we typically focus on:

Alright, let’s kick things off by looking at how costs and latency stack up for each method, comparing CUs/credits to dedicated options. If you're curious, you can find all the details on their website at alchemy.com. It's definitely worth a look! Alright, so next on the agenda, we’re diving into direct-node blueprints. This includes some cool options like Erigon and Nethermind, plus we’ll touch on consensus mechanisms too. Hey, make sure you don’t overlook the NVMe sizing, pruning, and those CI-based disaster drills! They’re super important! If you need more details, just check out docs.erigon.tech. You’ll find all the info you need there! Hey, have you checked out MEV-aware write paths and endpoint governance yet? There's some pretty cool info just waiting for you over at docs.flashbots.net. It'll give you a solid overview!

And let's not forget about AWS's private networking option, PrivateLink. Plus, those enterprise compliance packages are pretty important too! Check out the details at docs.chainstack.com for all the latest info!

Got a 2-4 week project in mind and want it tailored specifically to your needs? We’ve got your back! We’ll dig into your method mix, traffic, and any security worries you might have. Together, we’ll lay out the architecture, map out the cost model, and outline all the steps to get everything up and running smoothly. Let's make this happen!

References and further reading

Hey, take a look at the Ethereum JSON-RPC spec (that's EIP-1474), plus check out block-pinning (EIP-1898) and the Execution APIs repository while you're at it. You'll find some really useful info there! Check it out right here: (eips.ethereum.org). It's got everything you need!

So, here's the lowdown on providers: Hey there! Check out Alchemy’s pricing and CU tables for the 2025 PAYG plan. Want the latest info? Check it out here: (alchemy.com).
Check out the limits and guidelines for using eth_getLogs. For more info, check out Alchemy at alchemy.com. They've got all the details you need! Check out QuickNode's benchmark transparency through QuickLee! It's a great way to get the insights you need. Take a look at their insights here: blog.quicknode.com. You might find some really interesting info!
Curious about the current status of Infura and want to get the scoop on their trace API? You're in the right place! Just check out this link: (status.infura.io).
Let’s dive into the details of the Cloudflare Ethereum Gateway architecture and check out what caching features it has to offer! You can find all the info you need right here: developers.cloudflare.com. It's got everything laid out for you! Hey there! If you're into security stuff, you should definitely take a look at the attestations from QuickNode and Blockdaemon. You can find all the details over at quicknode.com. It’s worth a peek! Alright, let’s dive into client operations and hardware! If you're working with Erigon or Nethermind, check out this great resource for some handy hardware and disk advice: (docs.erigon.tech). It’s got everything you need to get started! If you’re getting into Geth, make sure you check out the GraphQL and metrics overview. It’s super helpful! You can find it here: geth.ethereum.org. Happy exploring!

If you combine deterministic direct-node reads for the few methods that really need them with a reliable gateway that’s backed by a solid SLA for the rest, you’re really hitting that sweet spot. It’s like having the best of both worlds right at your fingertips! Most teams end up seeing less tail latency, fewer surprise expenses, and a boost in accuracy. That's exactly the way we roll at 7Block Labs--it's our philosophy and we really make it happen!