Skip to main content

​
RPC method behavior

Lasso handles each method by whether it’s safe to retry, depends on history, or holds state on one provider. Use this table to plan each workload’s rollout; the sections below give the details. Transaction dispatch differs between the hosted service and self-hosted engine:

​
Current reads

Methods such as eth_blockNumber, balances, receipts and most contract calls fail over to another eligible provider when an error is safe to retry. Your app still handles ordinary reorgs, and providers can differ by a block or two at the head. For a latest block that never goes backwards on a Custom profile, set block protection. For several reads at the same block, use read at one block.

​
Historical state and logs

Historical state, receipts and logs have separate coverage at each provider. A provider that serves old logs may lack old state, and the reverse. Lasso infers a request’s age from its block selector and steers it toward providers known to serve that depth. State reads by block hash go only to archival providers, because a hash’s age is unknown before dispatch. eth_getLogs also has provider-specific range and result-size limits. A provider’s own limit differs by provider, so Lasso tries the same query on the remaining candidates first; it returns -32005 with data.reason: "log_range_too_large" and data.action: "reduce_block_range" only once none of them can serve it. Split a returned range error into smaller fromBlock–toBlock spans in your app. Lasso’s own response-size cap applies to every provider alike and returns that -32005 at once. A provider that refuses eth_getLogs for plan reasons is treated the same way. Qualify your exact queries with indexer backfills.

​
Trace and debug methods

Trace namespaces are often plan-gated or client-specific. Test your exact methods, parameters and timeouts through the profile you’ll use. On a Custom profile, Lasso learns which providers refuse a method and shows it in the profile’s knowledge.

​
Transactions

eth_sendRawTransaction sends the same signed bytes sequentially within one deadline, with an allowance of three sends. A rate limit or quota exhaustion moves it to the next provider without consuming that allowance, and the same provider is never tried twice; a timeout, full pool, underpriced replacement or unfamiliar rejection moves it to the next provider and does count against the allowance. All sends share a limit of 16 candidate admissions. A sender fault stops at the first: nonce too low or too high, insufficient funds, an invalid signature, a malformed transaction or invalid gas or fee limits. So does a response saying the node already knows the transaction. A provider pin sends to that provider only. Before returning an error, Lasso looks the transaction up by hash once, and returns the hash if the transaction is pending or mined. If the lookup can’t run in time, the error stands and the outcome is uncertain: resend the same signed bytes, which is always safe, and reconcile by hash. Final transaction errors carry error.data.error_type: transaction_rejection, retryable, next_action and request_id; honor any Retry-After. When retryable is true, next_action says it’s safe to resend the same signed transaction; when false, it says to check the transaction’s hash for a receipt before signing a new one, then address the cause in the error message. A successful response means a provider accepted the transaction, not that it was included. Your app owns signing, nonces, replacement, receipts and finality. Self-hosted RPC Core sends a transaction to one provider only.

​
HTTP filters

Lasso rejects eth_newFilter, eth_newBlockFilter, eth_newPendingTransactionFilter, eth_getFilterChanges, eth_getFilterLogs and eth_uninstallFilter with -32601. Filter IDs live on one provider and can’t follow a request to another. Use eth_getLogs for scans and WebSocket subscriptions for real-time delivery. Self-hosted RPC Core forwards these methods without failover; see supported methods.

​
WebSocket subscriptions

Lasso shares upstream subscriptions across your clients and moves them to another provider in the same profile when one fails, backfilling missed newHeads and logs over HTTP and suppressing duplicates. When no alternate provider is configured, Lasso instead retries reconnecting to that same provider within the recovery deadline, rather than ending the subscription. Pending-transaction subscriptions aren’t served. The engine’s behavior is documented in WebSocket subscriptions.

​
Standards and provider differences

Lasso follows JSON-RPC 2.0 for envelopes and batches, Final Ethereum interface EIPs for specific wire contracts, and the ethereum/execution-apis schemas at commit 739f9e0, then each chain’s activated fork.
  • Envelopes. jsonrpc must be "2.0", method a string, and params an array or object when present. IDs keep their JSON type. Notifications get no response; a request with no usable ID gets id: null.
  • Batches. Every valid item is answered and notification responses are omitted. Use unique IDs; duplicates are preserved but ambiguous.
  • Results pass through. Lasso doesn’t rebuild blocks, transactions, receipts or logs, so new fork fields and chain extensions reach your app unchanged.
  • Upstream errors keep their code, message and data, even when the provider sent them with an HTTP 4xx or 5xx. HTML, gateway text and other transport failures are treated as provider failures and can fail over. When Lasso’s own retry budget runs out across several providers without a usable response, it returns its own sanitized error instead; see response signals and errors.
  • Parameters. EIP-1898 block selectors need exactly one of blockNumber or blockHash, and requireCanonical only with blockHash. An EIP-234 eth_getLogs filter can’t mix blockHash with fromBlock or toBlock.
  • Unknown, vendor and chain-specific methods pass through with one dispatch each and no failover.

​
Limits

  • Subscription recovery is bounded by a replay window and a deadline. When it can’t complete, the socket closes with code 1011 rather than skip events; the client reconnects and resubscribes.
  • Subscriptions don’t move between profiles.
  • Clients handle network disconnects, duplicates around a reconnect, and their own checkpoints for indexer-grade processing.

​
Next