Skip to main content

​
Ethereum JSON-RPC compatibility

Lasso is a standards-led compatibility and routing layer for EVM RPC. Applications use ordinary JSON-RPC while Lasso handles provider differences in transport behavior, error delivery, method coverage, history, limits, and chain-specific extensions. The goal is one predictable interface over providers that differ.

​
Compatibility target

Ethereum RPC is governed by a versioned set of specifications rather than one complete, immutable document. Lasso uses this precedence:
  1. JSON-RPC 2.0 for request, response, notification, error, and batch envelopes.
  2. Applicable Final Ethereum Interface EIPs for specific wire contracts.
  3. The ethereum/execution-apis schemas pinned to commit 739f9e00806003d2204adca7595f704849b9be30.
  4. The activated fork and official specification for the requested chain.
  5. Observed provider capabilities for what a particular endpoint can serve.
EIP-1474 remains useful for Ethereum value and error conventions, but its status is Stagnant. Lasso does not treat it as a complete Final baseline.

​
What Lasso unifies

​
JSON-RPC envelopes

Lasso validates client envelopes before routing. jsonrpc must be the exact string "2.0", method must be a string, and present params must be an array or object. IDs retain their JSON type and value. Valid notifications do not receive a response, and malformed requests that cannot supply a valid ID use id: null. HTTP batches preserve every valid item, including duplicate IDs, and omit notification responses. Use unique IDs because duplicate IDs remain ambiguous for clients even when Lasso preserves them.

​
Provider results and errors

Successful upstream results pass through. Lasso does not rebuild blocks, transactions, receipts, or logs because doing so could remove new fork fields or chain extensions. Some providers return a valid JSON-RPC error with an HTTP 4xx or 5xx status. Lasso preserves a request-correlated upstream code, message, and data object. HTML, gateway text, and other transport failures remain routing evidence and may trigger safe failover.

​
Ethereum parameter conventions

Lasso validates standards-defined shapes that affect routing or remove genuine ambiguity:
  • EIP-1898 block selectors require exactly one of blockNumber or blockHash. requireCanonical is valid only with blockHash.
  • EIP-234 eth_getLogs filters may use blockHash, but not together with fromBlock or toBlock.
  • Values authored by Lasso, including downstream subscription IDs, use canonical Ethereum quantity encoding.
Provider result shapes and value encodings are checked in Lasso’s tests, not on the routing path.

​
Methods, extensions, and affinity

Lasso does not treat every method as interchangeable:
  • Reads that are safe to repeat fail over within one deadline.
  • eth_sendRawTransaction receives one upstream dispatch because a lost response may still mean the transaction was applied.
  • Unknown and vendor methods pass through, with one dispatch each.
  • HTTP filter methods are rejected, because a filter ID belongs to one provider; use eth_getLogs or subscriptions.
  • WebSocket subscriptions support newHeads and logs, with failover and backfill.
Profiles can include chain extensions, bundler methods, or client-specific namespaces. Their transport, replay safety, affinity, capability, cost, and access policy must be explicit before Lasso advertises stronger behavior than single dispatch.

​
Compatibility terms

​
Next

Read Cloud RPC workload behavior for the managed method, execution-safety and continuity boundaries, including rejected filter lifecycle methods. Core supported methods is the separate self-hosted contract; Core forwards provider-local filters without affinity.