The Problem with Single-RPC Setups
Most payment integrations point at a single RPC endpoint — QuickNode, Alchemy, or a public node. If that node goes down, gets rate-limited, or returns stale data, your deposits stop being detected. Silently. No alerts. Just missed payments.
Paychainly's RPC Pool
Instead of a single URL, Paychainly maintains a pool of RPC endpoints stored in the rcps database table. Endpoints are ordered by priority (ascending by ID). The pool is loaded dynamically — you can add new nodes without restarting the service.
Failover Logic
When an RPC call fails or returns a 429 rate-limit response, the current endpoint is put in a 30-second cooldown. The next request automatically uses the next healthy endpoint in the pool. The cycle continues until a healthy node is found.
// Simplified failover logic
for (const rpc of this.pool) {
if (rpc.cooldownUntil > Date.now()) continue;
try {
return await rpc.provider.send(method, params);
} catch (err) {
if (err.status === 429) rpc.cooldownUntil = Date.now() + 30_000;
}
}Managing Your RPC Pool
In the admin panel, go to RPC Nodes. You can:
- Add new endpoints (Ankr, Chainstack, your own node)
- Set priority order
- Toggle endpoints active/inactive without removing them
- Monitor which node is currently serving requests
Recommended Setup
We recommend at least 3 RPC endpoints from different providers. Mix a premium dedicated node (lowest priority number = highest priority) with two public fallbacks. This gives you high throughput normally, with public nodes as emergency fallbacks.