Skip to main content

Overview

Lasso RPC supports JSON-RPC batch requests, allowing you to send multiple RPC calls in a single HTTP request. This reduces network overhead and improves throughput for bulk operations.

Batch Request Format

Send an array of JSON-RPC request objects instead of a single object.

Single Request

Batch Request

Basic Example

Response:
Responses are returned in the same order as the requests, preserving the request array order.

Batch Size Limit

Maximum 50 requests per batch (configurable via max_batch_requests application config). Exceeding the limit returns an error:

Advanced Examples

Account Balance and Nonce

Response:

Multiple Contract Calls

Response:

Mixed Methods

Response:

Historical Log Queries

Batch Requests with Strategies

Batch requests work with all routing strategies.

Fastest Strategy

Provider Override

Profile-Scoped

Error Handling

Batch requests return partial results if some requests fail.

Mixed Success and Error

Response:

Invalid Request in Batch

Response:

Performance Optimization

Lasso optimizes batch requests with zero-copy passthrough when possible.

Passthrough Conditions

Batch responses use raw bytes directly from upstream providers when:
  1. All requests succeed
  2. All responses are Response.Success structs
  3. Observability metadata is not requested in body (include_meta not set to body)

Observability with Batches

Response headers include:
  • X-Lasso-Request-ID: Request tracking ID
  • X-Lasso-Meta: Metadata for first successful request
For batch requests, observability metadata in headers represents the first request with a valid context. Use include_meta=body for per-request metadata (degrades performance).

Request IDs

Each request in a batch must have a unique id field for proper response correlation.

Good Practice

Bad Practice

Duplicate IDs make it impossible to correlate responses with requests. Always use unique IDs.

Best Practices

Batch Size

  • Keep batches under 50 requests (hard limit)
  • Optimal batch size: 10-20 requests for balance between throughput and latency
  • Larger batches may trigger provider rate limits

Request Ordering

  • Group related requests together
  • Place high-priority requests first
  • Consider response time variance

Error Recovery

  • Check each response individually for errors
  • Implement retry logic for failed requests
  • Don’t assume all-or-nothing success

Use Cases

Good for batching:
  • Multiple account balances
  • Multiple contract read calls
  • Block metadata queries
  • Token holder data
Bad for batching:
  • Subscription requests (eth_subscribe not supported over HTTP)
  • Write operations (not supported)
  • Single high-priority request (no latency benefit)

Configuration

Configure batch size limit in your application config:
Default: 50