Stop RPC outages and rate limits from reaching your app
A single provider URL fails whenever that provider does. This guide puts one Lasso endpoint in front of several providers, so reads move to the next provider when one is down or rate limited. Your app keeps standard JSON-RPC and only the URL changes. Use it when provider errors are reaching your users.1. Create an endpoint
One request returns a working key, with no signup:{chain} in its
rpc_url_template with a chain such as ethereum, base or arbitrum, and
give that URL to viem, ethers, Foundry, Hardhat or your indexer in place of your
provider URL. See install Lasso in your app.
2. Choose your providers
3. Pick a strategy per call site
The strategy goes in the URL, so one app can use several. See
routing.
What happens when a provider fails
Lasso also moves live WebSocket
newHeads and logs subscriptions to another
provider and backfills missed blocks.
Check that it worked
SetLASSO_RPC_URL to rpc_url_template without /{chain}, then ask for
routing evidence on any call:
lasso_meta names the provider that served the request, the candidates and any
retries. See routing evidence.
Limits
- Failover covers reads that are safe to repeat.
eth_sendRawTransactionsends the same signed bytes to up to three providers in turn, and a sender fault such as nonce too low stops at the first. See transactions. - Lasso tries a bounded number of providers. If every one fails, you get one
JSON-RPC error inside an HTTP 200, so check the body’s
error, not only the status. See error handling. - A profile never borrows providers from another pool. Failover is only as independent as the providers in that profile, so pick ones that don’t share a failure domain.
- A pinned provider URL has no failover.
Next
- RPC method behavior: what each kind of request does.
- Set up production RPC with an agent: hand this setup to an agent.
- Balance and payment fallback: what happens when a balance runs out.