Skip to main content
Use Lasso RPC Core when you want to operate the routing engine and its network boundary. Use Lasso Cloud when you want managed routing, accounts, keys, billing, and provider operations. A shared engine does not mean that a Core release and the hosted service have identical behavior.

Version reference

Checked September 20, 2026:

Workload and ownership matrix

“Supported” here identifies an interface and its documented boundary. It does not certify every provider pool, chain, request parameter, or sustained load. Use the detailed Core method contract, Cloud workload behavior, and Cloud compatibility contract for execution and failure semantics. Before adoption, evaluate one real application flow using the two-provider guide, including its recovery path.

Public release evidence

The v0.4.4 source release gives distinct physical provider instances a first pass within each health tier for load-balanced, replay-safe unary fallback. Alternate transports remain available; health tiers and explicit recovered-head preference retain precedence. The dispatch budget, original deadline and candidate admission limits are unchanged. No configuration or journal migration is required. Trying another instance first can delay a working alternate transport. This does not certify archive coverage, operator independence or provider capacity; see the full routing boundary. The v0.4.3 source release rejects an HTTP endpoint after a malformed or mismatched chain-ID probe, orders buffered orphan-log events before replacement-block additions, and removes URL user information, paths, queries, and fragments from provider diagnostics. It requires no configuration or journal migration. These fixes do not qualify archive depth or arbitrary reorg recovery. See the HTTP identity boundary and subscription recovery limits. The v0.4.4 container verification summary records 19 installation and recovery checks on each native AMD64 and ARM64 image. It covers installation, custom profiles, HTTP/WebSocket routing, container replacement, retained history, and optional journal recovery. The preceding v0.4.3 and v0.4.2 container reports remain historical evidence for those earlier images. The v0.4.2 feature validation report records controlled and managed-service block-choice and hash-read checks. It preserves failed quota and latency populations, cold-channel limitations, and cross-server backsteps alongside the final warmed-channel pass. Those bounded checks do not establish a customer-capacity estimate, a fleet-wide monotonicity guarantee, or an SLA. They do not separately qualify arbitrary log reorg recovery or your transaction lifecycle.

Routing benchmark

The published routing-overhead report measures added p95 latency of 0.70–1.08 ms across five short synthetic-provider trials at 10,000 requests per second. A separate 60-second instrumented run measured 2.29 ms. The raw evidence ledger preserves accepted, rejected, and sustained runs. This is a routing-engine measurement. It excludes hosted authentication, database metering, Internet/provider latency, multiple regions, and WebSockets. Use client-observed latency, correctness, recovery, and upstream volume from your own workload when deciding whether to adopt Lasso.