Scroll RPC Nodes & Endpoints

Scroll RPC URLs you can use right now

Third-party endpoints, free and shared. Scroll's traffic is lighter than the larger rollups, so these hold up well for reads and fall over in the same place as everywhere else: wide log ranges and sustained polling.

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider("https://rpc.scroll.io");
const blockNumber = await provider.getBlockNumber();
console.log("Scroll block:", blockNumber);

Where shared Scroll endpoints stop being enough

Scroll attracts teams that chose it for bytecode-level equivalence: infrastructure projects, bridges, and DeFi protocols that reuse mainnet contracts and audits unchanged. Those teams tend to run mainnet-grade tooling, steady archive reads, deep eth_getLogs backfills, and monitoring that replays historical state, and they run it against public endpoints sized for wallet traffic. The mismatch shows up as throttled backfills and gaps in monitoring.

A dedicated Scroll RPC node gives that tooling the same footing it has on mainnet: archive access as a property of the node rather than a premium tier, log windows set by client configuration, and throughput that does not depend on other tenants. On BLAZED.sh your indexer or monitor runs in a container on the node host, reading over a local socket.

Bytecode equivalence, and why your existing tooling just works here

Scroll's design goal separates it from most zk rollups: equivalence at the bytecode level rather than at the language level. Contracts compile with standard solc and the resulting EVM bytecode executes as it would on mainnet, which means the artifacts, the verification flow, and the address derivation you already use carry over without a chain-specific build step. Where zkSync Era asks you to compile differently and rethink CREATE2, Scroll mostly asks you to change the RPC URL.

That equivalence extends to the debugging surface, which is the part teams notice. Standard trace methods behave the way mainnet tooling expects, so stack traces, gas profiling, and the debugging habits built up on Ethereum transfer directly instead of needing a chain-specific equivalent. The tradeoff is on the proving side rather than yours: matching the EVM exactly makes the circuit harder to build and the proofs more expensive to generate, which is the cost Scroll absorbed so that your toolchain would not have to change.

Scroll RPC latency is a distance problem

Scroll's proving pipeline runs off the critical path of your reads; what your users and monitors actually experience is the RPC. A remote endpoint spends tens to low hundreds of milliseconds per call crossing the public internet. Running the code on the node host removes that path entirely: on our live Ethereum product, co-located calls complete in under 10 milliseconds, and dedicated Scroll nodes will follow the same architecture.

What dedicated Scroll node hosting will cost

BLAZED.sh prices node access in per-request credits granted monthly by your subscription, with a deliberately narrow weight spread: most RPC methods cost a single credit, and only a handful of heavy operations cost more. Dedicated Scroll nodes will launch on the same credit model, with the waitlist deciding rollout priority.

Monitoring and indexing on Scroll are read-and-logs workloads, single-credit calls almost throughout, so the credit model prices a backfill by its block count rather than by method-weight arithmetic.

Perfect for

What is Scroll?

Scroll's design goal is to match the Ethereum EVM as closely as possible at the bytecode level, which minimises surprises when porting contracts and reusing audits. It generates zk validity proofs for its batches and verifies them on Ethereum, inheriting Ethereum security while keeping fees low. For developers this means the integration is essentially an Ethereum integration with a different RPC URL and chain ID. Scroll's ecosystem leans toward DeFi and infrastructure projects that value equivalence and verifiability. The recurring theme applies here too: proving happens off-path, but your users experience the RPC, so sustained query performance for logs and state reads is what a dedicated node improves.

Scroll RPC: frequently asked questions