> ## Documentation Index > Fetch the complete documentation index at: https://docs.lasso.sh/llms.txt > Use this file to discover all available pages before exploring further. # Versions, availability, and evidence > Choose between released RPC Core and managed Cloud, with versioned proof and workload limits. 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: | Surface | Version or observation | What it establishes | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | RPC Core source | [v0.4.4](https://github.com/jaxernst/lasso-rpc/releases/tag/v0.4.4), source `291c57162f382e5680cc218c7627972a9c5204f2` | The released source described by the Core API guides. [Exact-source CI](https://github.com/jaxernst/lasso-rpc/actions/runs/35537374714) passed; repository main can be newer. | | RPC Core container | v0.4.4, image index `sha256:4e000226f83680ec472cca937fcbcf839add7b4aecc4f31e15cbaf5e35f8a1c7` | The [release manifest](https://github.com/jaxernst/lasso-rpc/releases/download/v0.4.4/container-release.json) binds source and image digests. Native AMD64 and ARM64 installation checks passed before [publication completed](https://github.com/jaxernst/lasso-rpc/actions/runs/35537711234). | | Managed Cloud | Public health reported source `89ade5b9be5745f09ee09f0c394223549e5f0085` at `2026-09-20T18:46:30Z` | A dated deployment observation. Recheck [health](https://lasso.sh/api/health) and [service discovery](https://lasso.sh/agent.json) for your evaluation. Process health does not qualify your workload. | | Cloud APIs and payment availability | Live [OpenAPI](https://lasso.sh/openapi.json), [manifest](https://lasso.sh/agent.json), and [deployment guide](https://lasso.sh/SKILL.md) | Available routes, credential classes, and enabled payment rails on that deployment. An implemented API can still be disabled. | ## 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. | Capability | RPC Core v0.4.4 | Managed Cloud | Qualification boundary | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | HTTP reads and batches | Supported; you configure and operate upstreams. | Managed or account-owned provider pools. | History, method support, quotas, and parameters depend on eligible upstreams. Batches route items independently and do not pin a snapshot. | | Signed transactions | One upstream dispatch for `eth_sendRawTransaction`. | Conservative single dispatch. | An acknowledgment is not inclusion or finality. Reconcile an indeterminate result by transaction hash. | | WebSocket unary requests, `newHeads`, and `logs` | Supported; enable intended providers and protect your endpoint. | Account-key WebSocket access is advertised. Anonymous-key WebSocket access is not. | Recovery is bounded. Reconnect and reconcile application checkpoints after termination. Pending-transaction subscriptions are outside the released subset. | | Historical state and log ranges | Forwarded subject to provider capabilities. | Provider capability and availability constrain routing. | No universal archive depth or log-range guarantee. Qualify your exact historical witnesses. | | Stateful filters | Can forward when capability policy permits, without cross-request upstream affinity. | Rejects the documented [HTTP filter lifecycle](/cloud/rpc-behavior#stateful-http-filters) locally with `-32601`. | Use `eth_getLogs` or supported subscriptions; filter IDs are provider-local. | | Block regression protection | Opt-in `local` policy with best-effort peer recovery; optional coordinated policy requires its own operating setup. | Custom-profile On/Off control for local protection. | Local protection covers sequential choices within one running application generation. A server switch or restart can return a lower block. | | Hash-selected state reads | Explicit selectors are retained through routing and retries. | Same documented application pattern. | Choose and carry one hash through every read; upstream state and selector support are required. This is not finality or execution proof. | | Identity, billing, incoming customer quotas | Outside Core. Protect exposed endpoints through your network or reverse proxy. | Account, key, entitlement, and usage services. | Profiles do not multiply an upstream account's quota. [Account and anonymous CU differ](/cloud/observability#usage-units). | | MPP funding and paid sessions | Outside Core. | Implemented paths, disabled in production at the observation above. | Check the live manifest before attempting payment. Legacy Tempo protocol support does not imply current CLI compatibility. | | Sustained workload capacity | Depends on your deployment and providers. | Depends on workload, profile, providers, and service policy. | The linked evidence does not establish a general 24-hour, seven-day, or 30-day operating envelope across these workloads. | Use the detailed [Core method contract](/api/supported-methods), [Cloud workload behavior](/cloud/rpc-behavior), and [Cloud compatibility contract](/cloud/json-rpc-compatibility) for execution and failure semantics. Before adoption, evaluate one real application flow using [the two-provider guide](/cloud/bring-your-own-rpc), including its recovery path. ## Public release evidence The [v0.4.4 source release](https://github.com/jaxernst/lasso-rpc/releases/tag/v0.4.4) 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](/concepts/routing-strategies#load-balanced). The [v0.4.3 source release](https://github.com/jaxernst/lasso-rpc/releases/tag/v0.4.3) 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](/api/supported-methods#reads-and-execution-safety) and [subscription recovery limits](/advanced/websocket-subscriptions#application-checkpoints-and-reorgs). The v0.4.4 [container verification summary](https://github.com/jaxernst/lasso-rpc/releases/download/v0.4.4/container-verification.md) records 19 installation and recovery checks on each native [AMD64](https://github.com/jaxernst/lasso-rpc/releases/download/v0.4.4/verification-amd64.json) and [ARM64](https://github.com/jaxernst/lasso-rpc/releases/download/v0.4.4/verification-arm64.json) image. It covers installation, custom profiles, HTTP/WebSocket routing, container replacement, retained history, and optional journal recovery. The preceding [v0.4.3](https://github.com/jaxernst/lasso-rpc/releases/download/v0.4.3/container-verification.md) and [v0.4.2 container reports](https://github.com/jaxernst/lasso-rpc/releases/download/v0.4.2/container-verification.md) remain historical evidence for those earlier images. The v0.4.2 [feature validation report](https://github.com/jaxernst/lasso-rpc/releases/download/v0.4.2/feature-validation.md) 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](https://lasso.sh/benchmarks/routing-overhead.html) 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](https://lasso.sh/benchmarks/lasso-routing-overhead-ledger-2026-08-24.tar.gz) 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.