Routing and usage evidence

Lasso keeps the default response compatible with JSON-RPC. Evidence comes from baseline response headers, opt-in metadata, the dashboard, and server-side telemetry; those surfaces have different retention and audience boundaries.

Baseline headers

Header	Current boundary
`x-lasso-profile`	Authorized profile identity on authenticated profile routes.
`x-lasso-downgraded`	Present when account policy moved a request to public service.
`x-lasso-effective-strategy`	Present when the requested strategy was normalized to a different allowed strategy.
`x-lasso-cu`, `x-lasso-usd`, `x-lasso-strategy`	Per-request method-price evidence for anonymous-key responses and paid sessions. Account-key usage is recorded but these headers are not currently added to account-key responses.
`x-lasso-balance-warning`	Present when the applicable key or downgrade policy is near/exhausting its balance.

Operational fallback between system profiles preserves the authorized service profile’s x-lasso-profile identity. Internal routing metadata can separately describe the attempt that served the request.

Opt-in metadata

Use ?include_meta=headers or X-Lasso-Include-Meta: headers to preserve the JSON-RPC body and receive:

x-lasso-request-id;
x-lasso-meta, a base64url-encoded JSON routing record when it fits within the header limit.

curl -sS -D /tmp/lasso-headers.txt \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \
  "https://lasso.sh/rpc/k/$LASSO_KEY/fastest/ethereum?include_meta=headers"

python - <<'PY'
import base64, json, pathlib

headers = pathlib.Path("/tmp/lasso-headers.txt").read_text().splitlines()
encoded = next(
    line.split(":", 1)[1].strip()
    for line in headers
    if line.lower().startswith("x-lasso-meta:")
)
encoded += "=" * (-len(encoded) % 4)
print(json.dumps(json.loads(base64.urlsafe_b64decode(encoded)), indent=2))
PY

Use include_meta=body only when the client accepts a changed response shape. That mode adds a top-level lasso_meta object; it does not add x-lasso-meta. The metadata record exposes the request ID, strategy, chain, transport, candidate and selected providers, selection/upstream/end-to-end latency, Lasso overhead, retry count, and circuit state when those fields are available. service_profile_id identifies the original service profile; profile_id identifies the effective route, including configured fallback. executed_channel is present only when an upstream served the request. With Block regression protection On, provider-backed block choices include head_policy.policy=local, the application generation, captured floor and recovery evidence. Existing strict configurations can return retained block choices with head_policy.policy=global and no executing provider. Client metadata does not include per-attempt error details. Treat the live OpenAPI response and actual record as authoritative because optional fields depend on the request path and outcome. WebSocket callers can add "lasso_meta":"notify" to a JSON-RPC request to ask for a follow-up lasso_meta notification.

Block protection metadata

These optional fields help diagnose Block regression protection. They are not required to enable protection or read several values at one block. When head_policy.policy is local, a protected latest-block response can include:

Field in `head_policy`	Meaning
`block_number`, `block_hash`, `block_age_ms`	The accepted block and its age.
`instance`, `generation`	The serving Lasso instance and application lifetime. A replacement application starts a new generation.
`minimum_height`	The local floor captured when the request started.
`recovery_height`	A best-effort recovery height hint, or `null` if none was available.
`recovery_gap_blocks`	The gap below the recovered height. A nonzero gap is allowed; hints are not mandatory minimums.

Compare nonoverlapping requests within the same service profile, chain, instance and generation to assess local protection. These fields do not prove that a particular number of peers received an update or predict recovery time. Existing strict policies report policy=global and can include attributed chain-change observations. Their retained number/header responses have no executing upstream provider. Explicit-number/hash requests can legitimately have no head_policy object. State-read results do not independently attest which block the provider used to execute them. For correlation, use x-lasso-request-id, or x-request-id when no routing context was created. Both profile identity fields are opaque. HTTP batch headers expose only one item’s routing context. Oversized metadata can be omitted. If complete per-request diagnostics are required, use individual HTTP requests and record missing metadata explicitly; this is a diagnostics choice, not a requirement for consistent reads.

Operational workflow

Capture the request ID at the client boundary.
Compare the requested route with x-lasso-profile and, when present, x-lasso-effective-strategy.
Decode opt-in metadata to identify the serving provider, transport, latency, and retry count.
Check the dashboard’s regional provider state and recent activity.
Correlate the request ID with application and service telemetry for a durable incident record.

The dashboard’s recent activity is a bounded live presentation stream, not a durable request ledger. A connected LiveView receives relevant PubSub updates; the RPC request hot path does not render dashboard state or query Postgres for each viewer.

Common status signals

Signal	Meaning
`401`	API key is missing or invalid.
`402`	Anonymous balance or a session payment is exhausted.
`403`	The key is not authorized for the requested profile.
`429`	A Lasso or upstream limit was reached.
`503`	No eligible provider attempt served the request.

Start here

Operate Lasso

Application guides

Automation and reference

Routing and usage evidence

Routing and usage evidence

Baseline headers

Opt-in metadata

Block protection metadata

Operational workflow

Common status signals

​Routing and usage evidence

​Baseline headers

​Opt-in metadata

​Block protection metadata

​Operational workflow

​Common status signals

Routing and usage evidence

Baseline headers

Opt-in metadata

Block protection metadata

Operational workflow

Common status signals