Grove is gone, and the endpoints it ran no longer resolve. Grove stepped away from running its gateway in November 2025 and handed the public traffic to the Pocket Network Foundation; the founders’ farewell letter on grove.city now says the company “is winding down” after nine years. The hosts your app may still have in its config, in the form https://<chain>.rpc.grove.city/v1/<app-id>, return no DNS answer today.
If your application still points at one of those URLs, it is already failing. If it was moved to the Foundation’s free endpoints, it works, but on shared infrastructure with no service level behind it. This guide is the practical version of moving a production app off either: what changes in your code, what to verify before you cut over and what to watch in the first week.
First, separate the protocol from the gateway
Two different things carry the Pocket name, and only one of them went away.
Pocket Network, the protocol, continues. The farewell letter is explicit that it is stewarded by the Pocket Network Foundation and remains permissionless. Since 25 November 2025 the Foundation runs the public gateway at api.pocket.network, with per-chain hosts such as eth.api.pocket.network. Its own docs describe it as free RPC access for development, testing and moderate production use.
Grove Portal, the hosted gateway, is gone. That is the piece most teams were calling: your per-chain endpoints and, if you used one, your app ID.
So this is not a decentralisation decision. It is a gateway replacement, and you can treat it as one.
Before you touch any code
Read three things off your current setup while they are still in your own config, because the Grove docs are no longer online to look them up in.
Your endpoint URLs. Copy every one your application uses, per chain and per environment. The chain identifier at the start of the host (eth, solana, base and so on) is the part you need to map.
Which chains you actually call. Not the ones you provisioned. The ones that appear in your logs. Endpoints that nobody calls are easy to drop now and cost nothing to leave out.
Which methods you actually call. Group them: plain reads, eth_getLogs ranges, writes, traces. This matters for the next section, and it is the input to any sensible cost estimate.
Map your chains first, not your code
The single thing that can block a migration is a chain your new provider does not serve. Check that before anything else.
BoltRPC serves 35+ chains across EVM and non-EVM, including Bitcoin, Solana, Sui (over gRPC), Aptos, Tron and Starknet. The full list with chain IDs and endpoint slugs is on the networks page and in the docs, both generated from the live catalog rather than typed by hand.
Two things to check per chain while you are there:
- Archive depth. The networks page shows per chain whether the pool holds full or partial archive state. That is measured from the node, not asserted in a table: a pool that loses genesis state loses the claim automatically.
- Trace and debug support. Also per chain, also measured. If you run
debug_traceTransactionin production, confirm the chain you need answers it before you cut over.
The URL change
On the JSON-RPC chains, every chain is reached on one host, with your key in the path and the chain slug after it:
https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/ethereum
wss://endpoints.boltrpc.io/ws/YOUR_API_KEY/ethereumSwap the slug for any chain in the docs table. One key works across every chain you are entitled to, so a multi-chain application stops carrying one credential per network. The exceptions are listed on their network pages: the Beacon and Aptos REST APIs take their REST path after the slug, Sui is gRPC with the key in a header, and Enjin has public endpoints.
The samples below read the key from BOLT_KEY. Set it first, or the URL is built with undefined in it and the endpoint answers 401.
JavaScript, ethers.js v6
import { JsonRpcProvider } from "ethers";
const provider = new JsonRpcProvider(
`https://endpoints.boltrpc.io/rpc/${process.env.BOLT_KEY}/ethereum`
);
console.log(await provider.getBlockNumber());JavaScript, viem
import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";
const client = createPublicClient({
chain: mainnet,
transport: http(
`https://endpoints.boltrpc.io/rpc/${process.env.BOLT_KEY}/ethereum`
),
});
console.log(await client.getBlockNumber());curl
curl https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/ethereum \
-X POST \
-H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'On the EVM chains, standard JSON-RPC is standard JSON-RPC. If your code speaks it today, the transport swap is a URL and an environment variable. No SDK shim, no method translation.
The non-EVM chains keep their own native interfaces: Solana’s getHealth and friends, Sui’s gRPC sui.rpc.v2 services (Sui has retired its sui_* and suix_* JSON-RPC methods), Aptos and Beacon over REST, Bitcoin over its own JSON-RPC. Official SDKs point at the endpoint unchanged.
What changes about limits and billing
This is where gateways differ most, so it is worth being precise.
Monthly plans carry no per-second rate limit. Your traffic is metered against a monthly request-unit allocation, not throttled at a per-second ceiling. A burst during a liquidation cascade or a mint routes at full speed. The free trial does carry a limit of 100 requests per second, so load-test on a paid plan, not on the trial.
Each method’s weight is published. A request unit is a measure of one call’s server cost, and the weight of each JSON-RPC method is published before you sign up rather than discovered on an invoice. Plain reads cost less than traces; gRPC streams are metered by the bytes they carry. You can multiply your own call mix by the published weights and get your bill in advance, which is the point of the calculator on the pricing page.
That is also the cleanest way to size your plan during a migration. Take the method breakdown you collected earlier, apply the weights and you have a number before you commit to anything.
A cutover that does not page you at 2am
Run both in parallel. Point a read replica or a single non-critical service at the new endpoint first and leave it for a day. You are looking for method coverage gaps and unexpected error shapes, not speed.
Keep a fallback in the provider chain. Both ethers.js and viem support multiple transports with failover. Configure the new endpoint as primary and keep whatever you have as secondary until you are confident, then drop the old one. Our guide on RPC failover covers the patterns.
Move writes last. Reads are idempotent and safe to shift early. eth_sendRawTransaction deserves its own change window and its own monitoring.
Watch your error codes, not just your error rate. A -32601 means the method is not served on that chain, which is a coverage problem and not a reliability one. Our guide on handling RPC errors has the full mapping.
Check your WebSocket assumptions. Some chains have no native WebSocket at the node, so the gateway synthesizes a newHeads stream for Aptos, Bitcoin, Tron and the Beacon chains. If you subscribe on one of those, read the per-chain notes on its network page before you assume parity with your old setup.
Migration checklist
- Endpoint URLs and chain identifiers copied out of your current config
- Chains you actually call confirmed against the networks page
- Archive depth and trace support confirmed per chain, where you need them
- Method mix exported from logs and priced with the published weights
- New key issued and stored as an environment variable, never in client code
- One non-critical read service cut over and observed for 24 hours
- Failover configured with the old endpoint as secondary
- Writes moved in their own window
- Old endpoint removed from the provider chain
FAQ
Is Pocket Network shutting down?
No. The protocol continues under the Pocket Network Foundation, which also runs the free public gateway at api.pocket.network. Grove, the company that ran the Grove Portal gateway, has wound down, and its rpc.grove.city hosts no longer resolve.
Can I just stay on the free Pocket endpoints?
For development and testing, yes. For production, weigh it like any free shared endpoint: the Foundation’s docs pitch it at moderate production use, and nothing in them promises capacity or uptime for your traffic.
Do I have to rewrite my application?
No. If you are calling standard JSON-RPC through ethers.js, viem, web3.js, web3.py or an official non-EVM SDK, the change is the endpoint URL and a key in an environment variable.
Can I test before I commit?
Yes. The free trial needs no credit card. It is rate limited, so use it for correctness and coverage checks rather than load tests; its length and allowance are on the pricing page.
What if you do not serve a chain I need?
Tell us. The networks page is the current catalog and it moves. If a chain you depend on is missing, contact us with the chain and your volume rather than assuming the answer is no.
Related
- How to choose a blockchain RPC provider
- How BoltRPC request units work
- RPC failover: building reliable infrastructure
- Multi-chain RPC: connect your dApp to every chain
Moving off Grove Portal
Start with the chains you actually call and the methods you actually send. Everything else in a migration is detail.
Start your free trial or talk to us about the chain list before you plan the cutover.