Overview
Lasso can optionally include routing metadata in RPC responses, allowing clients to inspect provider selection, retry behavior, and request timing. This is useful for debugging, monitoring, and understanding routing decisions. Metadata is opt-in only — responses do not include metadata by default.Opt-In Mechanisms
Clients control metadata visibility via:Query Parameter
Request Header
headers- Metadata in response headersbody- Metadata in response body- Omit parameter - No metadata (default)
Headers Mode
Request:Decoding X-Lasso-Meta
TheX-Lasso-Meta header contains base64url-encoded JSON:
Size Limit
If encoded metadata exceedsmax_meta_header_bytes (default 4KB), only X-Lasso-Request-ID is included.
Configuration:
Body Mode
Request:Metadata Fields
Complete Schema
Field Descriptions
| Field | Type | Description |
|---|---|---|
version | string | Metadata schema version (always “1.0”) |
request_id | string | UUID v4 for request tracking |
strategy | string | Routing strategy: fastest, load_balanced, latency_weighted |
chain | string | Chain name (e.g., “ethereum”, “base”) |
transport | string | Transport protocol: http or ws |
selected_provider | object | Provider that fulfilled the request |
selected_provider.id | string | Provider identifier |
selected_provider.protocol | string | Transport used: http or ws |
candidate_providers | array | Providers considered (format: "provider_id:protocol") |
upstream_latency_ms | number | Time waiting for provider response |
retries | number | Number of retry attempts (0 = first try succeeded) |
circuit_breaker_state | string | Circuit state: closed, open, half_open, unknown |
end_to_end_latency_ms | number | Total request duration (selection + upstream + overhead) |
Use Cases
1. Debugging Provider Selection
Scenario: Understand why a specific provider was chosen.eth_blockNumber.
2. Monitoring Retry Behavior
Scenario: Track failover attempts.3. Performance Analysis
Scenario: Identify slow requests and upstream latency.4. Circuit Breaker Monitoring
Scenario: Detect when providers are degraded.5. Client-Side Request Tracing
Scenario: Correlate client requests with server logs.Client Library Examples
JavaScript/TypeScript
Python (web3.py)
Go (go-ethereum)
Performance Impact
Overhead Breakdown
| Operation | Overhead | Notes |
|---|---|---|
| Header encoding | <2ms | JSON encode + base64url |
| Body enrichment | <1ms | Map.put operation |
| Total (headers) | ~2ms | Added to end-to-end latency |
| Total (body) | ~1ms | Added to end-to-end latency |
| Total (none) | 0ms | No metadata overhead |
include_meta is omitted.
Configuration
Observability Settings
Troubleshooting
Metadata Not in Response
Symptom: Response does not include metadata despiteinclude_meta parameter.
Verify parameter:
Large Metadata Missing from Headers
Symptom:X-Lasso-Request-ID present but X-Lasso-Meta absent.
Cause: Metadata exceeds max_meta_header_bytes.
Solution 1: Use body mode instead:
Invalid Base64 Decoding
Symptom: JavaScriptatob() fails with “Invalid character” error.
Cause: Header uses base64url encoding (not standard base64).
Fix: Replace - and _ before decoding:
Summary
Lasso’s request metadata provides:- Opt-in visibility into routing decisions and performance
- Two delivery modes: headers (compact) or body (no size limit)
- Comprehensive data: provider selection, retries, circuit state, timing
- Client library support for JavaScript, Python, Go
- Low overhead (<2ms for headers, <1ms for body)
- Request tracing via UUID request IDs
- Production-safe with configurable size limits