Skip to main content
Lasso RPC Core v0.5.0 selects upstream channels from the requested file profile and chain. A configured provider and an executing channel are different: one provider can offer HTTP and WebSocket transports, and multiple configuration entries can refer to the same physical upstream.

​
Eligibility

Selection considers the requested transport, channel availability, circuit and rate-limit state, head observations, declared archival support, method capabilities and explicit exclusions. A configured WebSocket URL alone does not establish a connected transport. Method support and parameter limits can differ between providers and transports. Historical age is inferred where the request and available head evidence allow it. A numeric selector older than archival_threshold requires a declared archival provider; one whose age cannot be established does not. A state read selected by block hash (EIP-1898) always requires a declared archival provider, because its age is unknown before dispatch. Without one, Core returns a non-retriable archive_required error without contacting an upstream. An archival: true flag is configuration, not measured proof of state, receipts, logs or every selector shape. Lag selection uses Core’s head observations and configured lag allowance. Unknown or stale evidence must not be interpreted as verified head agreement. See block regression protection for the separate request-level policy and its evidence boundaries.

​
Configuration

This complete profile body demonstrates supported selection and provider capability fields. Add profile frontmatter when saving it. The local upstream must serve Ethereum; its declared capabilities must reflect what you have qualified.
selection belongs under the chain. The profile body accepts only the chains mapping. A routing.method_overrides block is not supported. See the released file schema and configuration reference.

​
Strategy ranking

Routing strategies define channel order: randomized load balancing with a bounded distinct-instance first pass for replay-safe calls, recent reliability-qualified latency, relative latency weights, or configured priority. Fastest and latency-weighted use recent local routing evidence, not lifetime dashboard averages or an implicit exploration floor.

​
Health tiering

The released order is: Open circuits are excluded. Each strategy defines its within-tier order, including load-balanced instance diversity. A channel in tier 2 precedes one in tier 3 even if the latter has a better latency or configured priority. Half-open admission is controlled; appearing in the candidate order does not reserve permission to send.

​
Execution and failover

Core checks live admission before dispatch, so a selected channel may be rejected if its state has changed. Replay-safe requests can continue through eligible channels within the three-dispatch limit and absolute deadline. Unsafe and unknown methods do not inherit that replay behavior. See the method contract. A successful candidate list does not guarantee a successful request. More eligible channels may exist than the dispatch budget can reach. Routing exhaustion is a JSON-RPC error over HTTP 200; candidate or internal provider errors are not a promised public error-detail schema.

​
Inspect an actual request

Request metadata with include_meta=body. candidate_providers describes selection candidates, attempted_channels records completed attempts, and executed_channel identifies successful upstream execution when present. Do not count candidates or the retries counter as a precise list of upstream dispatches. For managed service profiles, use Cloud RPC behavior. This Core reference does not define Cloud entitlements, account quotas or profile fallback behavior.