Skip to main content

​
Custom profiles and provider probes

A custom profile is an account-owned pool of upstream providers. It uses the same routing engine as a managed profile while keeping its membership, credentials, billing lifecycle, and route identity separate. Start with the two-provider evaluation, or use the agent management workflow when available on your deployment.

​
Operator journey

  1. Create a draft and choose its display name. Review the generated slug before activation because the slug becomes part of the RPC route.
  2. Add a chain and one or more provider URLs. Credentials remain server-side and must not appear in screenshots, issue comments, client errors, or logs.
  3. Optionally probe each provider. A probe spends upstream quota because it makes representative JSON-RPC and WebSocket calls.
  4. Review method categories, archive behavior, request limits, latency, and WebSocket results. Correct false assumptions before activation.
  5. Activate the profile, then send a harmless request such as eth_chainId through its profile route.
  6. Observe traffic and provider health. Add, remove, or update providers as the upstream stack changes; active edits propagate across the running cluster.
An unprobed provider can be activated and routed with conservative defaults. That is useful when probe cost or provider quotas matter, but it provides less evidence for capability-aware routing. For HTTP, use an account key authorized for the account-owned profile:
The corresponding WebSocket route is wss://lasso.sh/ws/rpc/profile/<slug>/<strategy>/<chain>?key=$LASSO_KEY. See the live OpenAPI contract for profile-scoped HTTP, WebSocket, and authentication details. A key from another account is not authorized merely because it knows the profile slug.

​
Supported provider connection settings

The current Lasso Cloud editor accepts provider URLs. Use the endpoint URL supplied by your provider and verify the required methods with a probe and a test request. The editor does not currently expose custom authentication headers or independent HTTP and WebSocket endpoint pairing. A provider that requires header-only authentication, or different HTTP and WebSocket hosts or paths, cannot be fully configured through this editor. Do not assume that changing https to wss creates a valid WebSocket endpoint, or move a header credential into a URL unless your provider explicitly supports that authentication method. The preview management API advertises connection fields in its live configuration schema, including independent HTTP and WebSocket URLs when supported. Check that deployment contract separately from the editor. Neither path promises support for arbitrary provider authentication. Lasso RPC Core supports more transport configuration options when self-hosted; those options are separate from the current Cloud editor.

​
Interpret probe results

A category result summarizes representative method calls; it is not a verdict on the provider as a whole.
  • Supported: the representative methods tested successfully.
  • Partial: some methods succeeded and others failed or were unavailable. Inspect the failed methods and compare them with the application’s workload.
  • Blocked: the endpoint or plan rejected the representative behavior. This can be a provider policy or plan boundary rather than a node failure.
  • Not served: Lasso intentionally does not forward the category, so no upstream test is meaningful.
For example, failure of legacy uncle methods can make the core category partial without affecting ordinary Ethereum reads. eth_createAccessList can make state queries partial even when eth_call, balances, code, and storage work. Event filters may be blocked while direct eth_getLogs or WebSocket subscriptions remain the right application path. Judge the individual methods you need.

​
Historical results

Archive support is not one boolean in the upstream ecosystem. A provider can serve old blocks, state, and logs differently, and plan-gated access can look like pruning. Lasso records the probe’s evidence but current routing uses a conservative archive capability model. Validate the exact historical queries and ranges your application depends on rather than assuming “reported archival” means unlimited history for every method.

​
Safe editing model

Profile configuration is database-backed. Successful edits invalidate and rebuild the relevant runtime configuration across regions; request routing does not query Postgres on every call. Operators are expected to test provider URLs and intended behavior before applying changes. The normal recovery path for a bad provider is to correct or remove it while the remaining eligible providers continue to serve traffic where possible.

​
Block regression protection

Turn Block regression protection On in a chain’s settings to keep sequential eth_blockNumber and latest eth_getBlockByNumber requests from returning a lower height on the same running Lasso server. Progress is shared automatically across the fleet, with best-effort recovery after a server switch or restart. Off is the default. See the protection guide for scope and error behavior. To read several balances or contract values at the same block, use the separate Read at one block pattern. It works with protection Off; the setting does not pin ordinary latest state calls automatically.

​
Live block monitoring

In a chain’s settings, Live block monitoring uses the providers selected for Monitor new heads. Turning it off preserves those selections and uses HTTP polling; client subscriptions remain available. Shared providers may still have feeds in use by another profile. Open Learn more for polling controls and current status. Custom intervals are available when Lasso recognizes credentials in the provider URL. Detection uses URL patterns; a private endpoint with an unrecognized short path token still receives the managed polling rate. Endpoints classified as public retain Lasso’s minimum polling interval. Monitoring tracks provider freshness, while Block regression protection controls the blocks returned to callers.