How dedicated blockchain infrastructure works

Most production workloads run fine on shared blockchain RPC infrastructure. A small set of them can't. A trading desk whose round-trip latency to the sequencer, the rollup's transaction-ordering service, decides whether its order lands in the next block. A security firm whose simulation engine runs a custom EVM tracer no shared provider will host. A regulated fintech whose compliance team won't sign off on hardware shared with another customer's workload.

For those workloads, the answer is dedicated blockchain infrastructure.

Dedicated is the same infrastructure, scoped to one tenant. Same RPC stack, same data services, same APIs, but the capacity, the host, and the runtime are yours. Teams like Blockaid use Alchemy Dedicated Clusters to secure $312B+ in assets with the performance and consistency their customers require.

That distinction is what makes dedicated worth the price for a narrow set of workloads, and what makes shared the right default for everyone else. The useful question is not whether dedicated is better. It is whether your workload has outgrown what shared infrastructure is designed to do.

What is dedicated blockchain infrastructure?

Dedicated blockchain infrastructure is a single-tenant RPC and indexing cluster: a fleet of blockchain nodes, routing infrastructure, and data services on hardware reserved for one workload. The API surface is the same as shared infrastructure by default, so existing integrations port without code changes. Customization extends that surface rather than replacing it: custom tracers and binaries, picked regions, and capacity-based pricing instead of per-request billing.

A typical cluster includes:

• A pool of full nodes for the chain, sized to the customer's peak request rate plus one extra node so failover doesn't drop traffic during a node restart, also known as the N+1 pattern.
• Optional archive nodes for historical state access, which provide full state from genesis rather than only recent blocks.
• An edge proxy and load balancer in front of the node pool, acting as the routing layer that receives every request and picks which node serves it.
• An observability stack, usually a Grafana dashboard exposing node health, request latency, and error rates.
• A failover path to shared infrastructure for traffic spikes the cluster was not sized for.

The infrastructure is the same shape as what shared providers run internally. The difference is the lease. Dedicated means the capacity is committed to one customer, the runtime is theirs to configure, and the data path is not shared with anyone else's workload.

When does a workload need dedicated infrastructure?

Four workload patterns push past what shared infrastructure can do.

Custom tracers and binaries

EVM tracers are the functions that instrument transaction execution. They extract internal call traces, storage reads, struct logs, and revert reasons. The standard tracers, such as callTracer and prestateTracer, cover most analytics. Security tools, simulation engines, and forensics platforms need more: custom JavaScript tracers that match their internal schemas, or modified geth and erigon binaries that expose execution state shared providers never expose.

Running those on a shared host is not safe for the host or the tenant. It is why simulation and security vendors run dedicated clusters.

Region-bound latency

For most application traffic, a few extra network hops are invisible. For workloads that issue tens of requests per second and care about each one, physical distance between the client, the node, and the sequencer can decide whether a transaction lands in time.

High-frequency trading, oracle feeds, and MEV searchers, which are bots that extract value from how transactions get ordered into blocks, compete on those margins. Dedicated clusters let the customer place node pools in the same region as the sequencer or the consumer.

Regulatory isolation

Some compliance frameworks require single-tenant compute. SOC 2 Type II controls around segregation of customer data, certain banking and brokerage regimes, and internal risk reviews at large financial institutions often converge on the same requirement: no other customer's workload should run on the same host.

Shared infrastructure runs many customers on the same hosts by design. Dedicated infrastructure does not.

Unbounded query ranges

Shared RPC providers cap eth_getLogs ranges to protect the cluster from query bombs. That is fine for wallets reading a user's recent transactions, and it is why most analytics workloads route to an indexed Data API instead of raw eth_getLogs.

For explorers, indexers, and chain analytics teams that need to scan large historical ranges of raw logs, the cap becomes the bottleneck. Dedicated clusters can lift it because the cap exists to protect other tenants, and on a single-tenant cluster there are no other tenants to protect.

A quick reference for the decision:

If a workload does not fit one of the four dedicated patterns, shared infrastructure is almost always cheaper, simpler, and faster to ship.

How do dedicated clusters work?

The architecture of a dedicated cluster comes down to six choices: who else runs on the box, where the boxes live, how many of them, how they agree on state, what software they run, and how they bill.

Single-tenant isolation

Single-tenant means the customer's nodes run on compute reserved for that customer's workload. In practice, compliance reviews often require documentation of workload isolation, access controls, auditability, and key handling.

The practical implication is what isolation rules out. A noisy neighbor on a shared host cannot degrade the customer's tail latency, because there is no neighbor. A side-channel leak from another tenant cannot reach the customer's process. A compliance reviewer can point at a documented control instead of "we trust the provider to keep workloads separate."

Regional deployment

Latency from a client to an RPC node is bounded by network distance. For most application traffic, that is invisible. For workloads that issue frequent latency-sensitive requests, placing nodes closer to the stack, users, sequencer, or validators can be the difference between a competitive product and a slow one.

Dedicated clusters let the customer pick the region. A common pattern is one cluster per major user geography, or one cluster co-located with the sequencer for a specific rollup. The trade is operational: more regions means more clusters to monitor, patch, and pay for. Most workloads need one or two.

N+1 redundancy and failover

A dedicated cluster runs the customer's target capacity plus one spare node. If any node degrades or restarts, traffic shifts to the spare without the customer noticing. That is the N+1 pattern, the standard shape for any service that needs to survive a single-node failure without losing availability.

The harder question is what happens when load exceeds the cluster. Two real cases trigger this: chain congestion, where the cluster's request volume spikes because the chain is busy, and customer traffic spikes from a campaign, an event, or an integration going live. A cluster sized for steady-state load can get rate-limited under a large spike.

Two architectural answers exist. One is to size the cluster for peak, which means paying for idle capacity most of the time. The other is automatic failover to shared infrastructure: when the cluster saturates, traffic spills to the provider's shared fleet rather than returning 429s. The customer keeps the same API, the same auth, and the same response shape. Failover is the more efficient pattern, but it requires the dedicated provider to also operate first-class shared infrastructure.

Block-perfect consistency

Different nodes in a load-balanced pool can disagree on the latest block for a few hundred milliseconds. The fastest node sees block N, the slowest is still on N-1. For a wallet checking a balance, that is invisible. For a trading bot that reads the same block twice through different nodes and gets inconsistent state, it is a real bug.

Block-perfect consistency means the cluster returns a consistent view of chain state across the node pool, so stateful clients do not see stale or conflicting reads. The trade-off is that the cluster optimizes for correctness as well as speed, which matters most when the workload makes decisions from fresh chain state.

Custom tracers and binaries

With a dedicated runtime, the customer can run a custom JavaScript tracer, ship a patched geth build, swap the client, or modify client configuration that shared providers pin globally. Shared providers cannot expose this surface because changing the client version or config affects every tenant on the host.

This is the capability simulation, forensics, and analytics products are built on. Their value comes from extracting execution state that the standard tracer interface does not expose. Without a dedicated runtime, the product does not exist.

Capacity-based pricing

Shared infrastructure charges per request, typically as a compute unit per call, with multipliers for heavier methods. Dedicated infrastructure charges per cluster: a fixed monthly fee for the committed capacity regardless of how many requests the customer sends against it.

The model fits workloads that have predictable peak load and would otherwise burn shared compute units at scale. On a dedicated cluster, the marginal cost of an additional request is zero until the workload hits the cluster's ceiling. Above a workload-specific threshold, capacity-based pricing can be cheaper than per-request billing even before accounting for the other capabilities dedicated unlocks.

When is shared the right default?

Three things matter when deciding between shared and dedicated infrastructure. For a deeper walkthrough of the tradeoffs, see our overview on choosing between Node RPC and Dedicated Clusters.

Dedicated does not make the RPC stack inherently faster

The RPC stack underneath is the same, so a single-request benchmark on a quiet system will not tell the whole story. Dedicated improves latency when the cluster is placed closer to the workload, and it improves predictability when isolation protects the P99, the slowest 1% of requests, under sustained load.

Multi-region shared can out-survive single-region dedicated

A regional cloud outage that takes down a single-region cluster barely registers on a globally distributed shared fleet. The pragmatic deployment pairs dedicated in key regions with shared as the global default.

The four-pattern test is strict

If the workload does not hit one of custom runtime, region requirement, regulatory isolation, or query-range cap, shared is cheaper, simpler, and usually more reliable. The move to dedicated is usually a forcing function, not a preference.

How does Alchemy support dedicated blockchain infrastructure?

Most workloads start and stay on shared. Our RPC API and Data API run on the same Cortex platform that powers dedicated, with a free tier, no contract, and no minimum commitment. Pull an API key from the dashboard and start sending requests in a few minutes.

When a workload hits one of the four patterns, custom tracer, region requirement, regulatory isolation, or query-range cap, Alchemy Dedicated Clusters gives single-tenant capacity on the same infrastructure. We support custom tracers and binaries, regional deployments, N+1 redundancy with automatic failover to shared, block-perfect consistency, Grafana dashboards from day one, and SOC 2 Type II compliant infrastructure for regulated environments. Pricing is based on provisioned capacity, not per-request usage, so teams with predictable load can plan around fixed monthly infrastructure.

Dedicated clusters are the same infrastructure, scoped to your workload. If shared infrastructure works, stay on shared. If your workload is one of the few that cannot, talk to our team.

FAQs

What is the difference between dedicated blockchain infrastructure and shared RPC?

Shared RPC runs many customers across a managed fleet. Dedicated blockchain infrastructure reserves the runtime, capacity, and data path for one workload. The API surface can stay the same, but dedicated adds single-tenant isolation, custom runtime options, regional placement, and capacity-based pricing.

Is dedicated infrastructure the same as a private RPC endpoint?

Not always. A private RPC endpoint can mean a customer-specific URL or access policy on shared infrastructure. Dedicated infrastructure goes further: the node pool and supporting runtime are reserved for one customer's workload.

When should a team avoid dedicated infrastructure?

Avoid dedicated infrastructure when the workload does not require custom binaries, regulatory isolation, region-specific placement, or unusually large raw query ranges. In those cases, shared RPC is usually simpler, cheaper, more elastic, and faster to ship.

Can dedicated and shared infrastructure run together?

Yes. Most teams that use Dedicated Clusters run a hybrid setup: dedicated for the chains or workloads with hard requirements, and shared RPC for everything else. The APIs match, so moving a workload between the two is mostly an endpoint and routing decision.

How does pricing work for dedicated clusters?

Dedicated clusters are priced on provisioned capacity rather than per-request usage. Pricing depends on the chain, node type, throughput, region, and capabilities included. For high sustained workloads, fixed capacity pricing can be easier to forecast than per-request billing.

How quickly can a dedicated cluster be provisioned?

Provisioning depends on the chain, client, region, and configuration. Some clusters can be deployed quickly when the requirements are standard. More complex setups, such as custom binaries, special hardware, or new regions, require more planning.