Routing

For every request, Lasso finds the providers in the profile that can serve it, orders them by your strategy, and fails over to the next one when an error is safe to retry. You choose the strategy per call site in the URL.

curl -sS "$LASSO_RPC_URL/fastest/base?include_meta=body" \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \
  | jq '.lasso_meta | {strategy, candidate_providers, selected_provider, retries}'

How a provider is chosen

Find candidates. Providers in the profile that serve the chain and transport. Known method gaps, history limits and range limits move a provider that can’t serve the request to the back; Lasso never drops the last route.
Order by health. Providers with an open circuit are skipped. Healthy providers come before rate-limited or recovering ones, and providers behind the requested block wait behind those at the head.
Order by strategy. Within each health group, your strategy sets the order.
Send, and fail over. A read that fails in a way that’s safe to retry moves to the next provider, within one request deadline.

Choose a strategy

Strategy	What it does	Use it for
`load-balanced`	Spreads requests in random order across healthy providers, counting a provider once even when it serves both HTTP and WebSocket	Backends, indexers, quota spreading
`balanced-fast` (default on Premium)	Random order weighted toward providers with lower recent latency	User-facing reads
`fastest`	Tries the provider with the lowest recent latency for this kind of request first	Trading and latency-critical paths
`priority`	Tries providers in your Custom profile’s configured order; use it on Custom profiles	A preferred primary with backups

A URL without a strategy uses balanced-fast on Premium and load-balanced on other profiles. latency-weighted is an alias of balanced-fast. Latency is measured in the region serving you, per provider, transport and kind of request (a family of related methods). Premium and Custom serve all four strategies. public, payment fallback and free access serve load-balanced, and lasso_meta.strategy reports what was used. On premium, strategies price differently.

What failover covers

Work	On a provider failure
Reads: balances, calls, receipts, blocks, logs	Retried on the next provider in the order, within the request deadline
Historical reads	Retried on the next provider, steered toward those known to serve that history
`eth_sendRawTransaction`	The same signed bytes go to the next provider, up to three in total; sender faults stop there. See transactions
WebSocket `newHeads` and `logs`	Moved to another provider, with missed blocks backfilled
A provider answering 429	Moved behind healthy providers until its cooldown ends
A provider that keeps failing	Its circuit opens; after a cooldown, a trial request decides whether it returns
Every provider in the profile	The final JSON-RPC error returns inside an HTTP 200; check the body’s `error`, not only the status

A profile never borrows providers from another pool. Pin one provider with <base>/provider/<name>/<chain> to debug it; a pin has no failover.

Trial it against your current endpoint

Send the same mix of your app’s real methods through your current endpoint and through Lasso, from the regions you deploy in.
Compare success rate, p50, p95 and p99 latency, and head freshness. A lower mean alone doesn’t show the tail improved.
Add ?include_meta=body to see selected_provider, retries, upstream_latency_ms and lasso_overhead_ms for each request. See routing evidence.
Force the failure you need to survive, such as throttling or stopping one of your own nodes, and confirm your requests keep succeeding.

Lasso’s routing engine adds under 1.1 ms at p95 at 10,000 requests per second; see the routing overhead benchmark.

When Lasso’s own systems fail

Each node routes from its last-known keys, profiles and provider state, so a database, billing or metering outage doesn’t refuse requests. Changes made during the outage take effect once the node can read them.

Limits

load-balanced spreads load across healthy providers, not evenly: if only one is healthy, it takes nearly every first attempt.
fastest can concentrate traffic on one provider for one kind of request.
A provider without recent measurements isn’t assumed fast or slow; it’s tried after measured ones.
Failover helps only when providers overlap on the method, history and chain you need. Two URLs on the same provider account can fail together.

RPC method behavior: reads, history, transactions, filters and subscriptions.
Routing evidence: see which provider served a request and why.
Bring your own providers: route over the provider accounts and nodes you already have.

Get started

Concepts

Guides

Reference

Updates

Routing

Routing

How a provider is chosen

Choose a strategy

What failover covers

Trial it against your current endpoint

When Lasso’s own systems fail

Limits

Next

​Routing

​How a provider is chosen

​Choose a strategy

​What failover covers

​Trial it against your current endpoint

​When Lasso’s own systems fail

​Limits

​Next

Routing

How a provider is chosen

Choose a strategy

What failover covers

Trial it against your current endpoint

When Lasso’s own systems fail

Limits

Next