Private Lens RPC Endpoints on a Dedicated Node

A Dedicated Lens RPC Node is a private Lens Chain node that runs on single-tenant infrastructure reserved for your workloads. We use it to serve your app's reads, writes, WebSocket subscriptions, background jobs, and internal services without placing you in a shared public pool. Lens Chain mainnet uses chain ID 232, supports HTTP JSON-RPC and WebSocket access, and uses GHO as the gas token. Lens is built on the Matter Labs ZK Stack, so a Lens node is closer to serious application infrastructure than a simple endpoint URL.

Not in the staking sense. Lens Chain is a ZK Stack Layer 2 with a centralized sequencer, so there is no permissionless, stake-to-earn validator like Ethereum or Solana. Block production and proof submission are handled by the sequencer and prover that settle to Ethereum. What we provision is a fast, dedicated full or archive RPC node (a ZKsync External Node), which is what apps, indexers, and dashboards actually need.

Yes. Lens Chain settles to Ethereum, so your External Node must connect to an Ethereum L1 RPC endpoint to follow the parent chain and verify state. If that L1 endpoint is slow or rate-limited, your Lens node can fall behind, which shows up as stale reads and delayed indexing. You can bring your own Ethereum endpoint or run Ethereum on dedicated servers with us, ideally in the same region for tighter latency and faster catch-up.

Yes. Lens supports both HTTP JSON-RPC and WebSocket RPC. In the official node setup, the HTTP API is exposed on port 3060 and the WebSocket API on port 3061. We treat that as a practical split: HTTP handles standard reads and writes, while WebSocket is what you want for live subscriptions, event listeners, and real-time product behavior.

A full node is the right fit for most production apps that need current chain state, transaction submission, and normal read traffic. An archive node is for teams that need the entire rollup history, broader historical access, or advanced workloads such as proof-related queries. Lens says archive mode requires more resources, uses a Postgres dump, and should have pruning disabled. In plain terms, full nodes run apps, while archive nodes support deeper data and research workloads.

Lens sets the minimum for a standard mainnet node at a modern CPU, 32 GB RAM, 700+ GB of storage, and a 100 Mbps connection, with 1 Gbps+ recommended. For archive, Lens moves to about 16 cores, 64 GB RAM, and 2 TB of storage, with the state continuing to grow. We usually size above the minimum for production because real workloads include app traffic, indexing, retries, and operating headroom. That is where a Lens RPC provider on dedicated hardware makes more sense than a tight shared plan.

You need archive access when your product depends on deeper historical data, full rollup history, or proof-related workflows that a standard node is not built to serve well. Lens also documents that if you require zks_getProof, the first archive bootstrap can need about 1 TB of RAM temporarily because the initial tree rebuild is very large. We only recommend that path when your workload actually needs it, because it changes both hardware planning and operating cost.

Yes. We support private endpoint patterns for dedicated RPC deployments, including firewall rules and IP allowlisting. That gives you a cleaner security boundary for internal services, partner access, staging traffic, or controlled production exposure. Our view is simple: your Lens RPC should only be visible to the systems and teams that actually need it.

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.