Private Boba Network RPC Endpoints on a Dedicated Node

A dedicated Boba Network RPC node runs on single-tenant bare-metal hardware reserved for you: CPU, RAM, NVMe storage, and network port are yours alone. Shared RPC endpoints split capacity across many users, so when demand spikes they throttle requests or add latency. A dedicated setup avoids that and lets you control the full stack, from the Boba execution client to the L1 Ethereum RPC connection.

Boba Network is an Ethereum Layer 2 optimistic rollup built on the OP Stack that settles to Ethereum L1. It combines Ethereum security with the speed and lower cost of an L2, and is fully EVM compatible so existing Ethereum contracts deploy unchanged. Boba's HybridCompute lets smart contracts trigger off-chain computation and access real-world data within a single transaction.

Boba is an OP Stack L2 rollup. A node has two parts: an execution client (op-reth is recommended; op-geth is deprecating) and a rollup node (op-node). The execution client handles state, transactions, and RPC queries; the rollup node derives L2 blocks from Ethereum L1 data. You also need a reliable Ethereum L1 RPC and beacon endpoint. With full root access you install, configure, and update these on your own schedule.

It depends on full versus archive. A full node runs well on 8 to 12 high-clock cores, 32 to 64 GB RAM, and multi-terabyte NVMe. Archive nodes need 16+ cores, 64 to 128 GB RAM, and significantly more disk that grows with chain history. NVMe matters more than raw capacity: it keeps sync steady and reduces query lag under load. op-reth keeps the archive far smaller than op-geth.

Yes. Boba is an L2 rollup that derives its blocks from Ethereum L1 data, so the op-node component reads from an Ethereum L1 RPC and beacon endpoint to verify batch submissions and reconstruct the L2 chain. You can use your own Ethereum node or a reliable third-party L1 source. The quality of your L1 endpoint directly affects whether your Boba node stays in sync.

A full node keeps current state and recent history and serves most RPC queries: balances, contract reads, receipts, and recent logs. An archive node retains full historical state at every block height, which is needed for eth_call at older blocks, historical balance lookups, and deep event-log scans. Archive needs much more storage and RAM, so choose full for standard production and archive when you need historical state.

Yes. Boba publishes database snapshots for node operators, which skip the long replay from genesis and get a node serving in hours rather than days. We provision your single-tenant server from a current snapshot, and you can verify it against the published sha256sum. Prefer hands-off? We can fully manage the sync, updates, and monitoring while you keep a working private endpoint.

No. Unlike shared RPC providers that bill per "compute unit" and throttle you past a quota, a dedicated node is a flat monthly price with unlimited requests and zero overages. One node equals all the throughput your hardware can serve. That makes budgeting predictable and removes the surprise bills that come with usage-based RPC pricing.

Shared RPC pools serve thousands of customers from pooled infrastructure, so you inherit rate limits, noisy-neighbor latency, and compute-unit billing. A RedSwitches node runs on single-tenant bare metal that is yours alone: reserved CPU, RAM, and NVMe, a dedicated 10/25 Gbps port, and a private endpoint you control. Performance tracks your hardware, not another tenant's traffic.

No. We provision from current snapshots so your node is live in hours rather than syncing from genesis for days. You can run it yourself with full root access, or choose our fully managed option where our engineers handle the sync, updates, and monitoring. Either way you receive a working private endpoint, not an empty server.

Yes. With 20+ Tier III locations across the US, EU, Asia, and Australia you can place your node in the same region as your users or a chain's sequencer to cut round-trip latency. Tell us your target region and we will recommend the closest facility. You can also run multi-region nodes for redundancy and split read and write endpoints.