REST API

The Colibri Stateless server provides a comprehensive REST API for generating and verifying cryptographic proofs for blockchain data. This API enables lightweight, stateless verification of Ethereum and Layer-2 blockchain operations.

Overview

The API consists of the following main categories:

  • Proof Generation - Create cryptographic proofs for blockchain data

  • Proof Verification - Verify proofs and execute JSON-RPC requests

  • Beacon Chain API - Light client sync endpoints for Ethereum consensus layer

  • Health & Monitoring - Server health checks and Prometheus metrics

  • Configuration - Server configuration management (requires WEB_UI_ENABLED)

OpenAPI Specification

The complete API is documented using OpenAPI 3.1.0 specification. You can access the specification in the following ways:

Live Server Endpoint

If you have a running Colibri server instance, the OpenAPI specification is available at:

http://localhost:8090/openapi.yaml

Replace localhost:8090 with your server's host and port.

Static Specification

The specification is also available in the source repository at:

Interactive API Documentation

The OpenAPI specification below provides interactive documentation for all available endpoints.

Note: First, add the OpenAPI specification to GitBook via the OpenAPI panel or CLI, then replace colibri-api below with your spec name.

Endpoints

Verify and Execute JSON-RPC Request

post

Primary Use Case: Local RPC Provider Replacement

This endpoint is designed to serve as a complete, trustless replacement for traditional RPC providers. When running the Colibri server locally (using the installer packagesarrow-up-right), you can configure this endpoint as your RPC provider in wallets like MetaMask, enabling fully verified, trustless access to the blockchain without relying on third-party infrastructure.

How It Works:

The endpoint processes JSON-RPC requests through the following flow:

  1. Proof Generation: Creates or fetches cryptographic proofs for the request (locally or from configured prover nodes)

  2. Verification: Verifies the proof against the current sync committee state

  3. Response: Returns the verified JSON-RPC response in standard format

Supported Methods:

This endpoint supports all Ethereum JSON-RPC methods, including:

  • Methods with proofs (see Supported RPC Methodsarrow-up-right)

  • Local methods without proofs (eth_chainId, web3_clientVersion, etc.)

  • Filter methods (eth_newFilter, eth_getFilterChanges, etc.)

  • Subscription methods (eth_subscribe, eth_unsubscribe)

Local Setup Example:

# Install and run locally (macOS/Linux/Windows)
# See: https://corpus-core.gitbook.io/specification-colibri-stateless/developer-guide/installer

# Configure in MetaMask:
# Network Name: Colibri Verified Ethereum
# RPC URL: http://localhost:8090/rpc
# Chain ID: 1 (or your configured chain)

The /config and /config.html endpoints complement this use case by providing an easy-to-use configuration interface for non-developers, allowing them to adjust settings like RPC nodes, beacon nodes, and caching without editing configuration files.

Body
jsonrpcstring · enumRequired

JSON-RPC version

Possible values:
methodstringRequired

RPC method name

Example: eth_call
idone ofRequired

Request identifier

stringOptional
or
numberOptional
or
nullOptional
Responses
chevron-right
200

Request verified and executed successfully

application/json
Responseone of
or
post
/rpc

Generate Proof

post

Generates a cryptographic proof for a JSON-RPC request.

This endpoint accepts standard JSON-RPC requests with additional optional properties:

  • c4: Hex-encoded state of the requested client for proof decisions

  • include_code: Include bytecode in eth_call proofs

The response is an SSZ-encoded C4Request container defined in the Ethereum Main Proof Request specificationarrow-up-right.

Supported Methods with Proofs:

This endpoint only accepts RPC methods that have an associated ProofType. The ProofType determines the structure used in the C4Request.proof union.

For the complete list of supported methods and their proof types, see the Supported RPC Methodsarrow-up-right documentation.

Common Methods:

  • eth_call → EthCallProof

  • eth_getBalance → EthAccountProof

  • eth_getStorageAt → EthAccountProof

  • eth_getCode → EthAccountProof

  • eth_getProof → EthAccountProof

  • eth_getTransactionByHash → EthTransactionProof

  • eth_getTransactionReceipt → EthReceiptProof

  • eth_getLogs → List[EthLogsBlock]

  • eth_getBlockByNumber → EthBlockProof

  • eth_getBlockByHash → EthBlockProof

  • eth_blockNumber → EthBlockNumberProof

  • colibri_simulateTransaction → EthCallProof

Note: Methods without a ProofType (like eth_chainId, web3_clientVersion) are not supported by this endpoint. Use the /rpc endpoint instead, which handles all methods.

Body
Responses
chevron-right
200

Proof generated successfully

application/octet-stream
Responsestring · binary

SSZ-encoded C4Request container. See the C4Request specification for detailed structure.

The container includes:

  • version: 4-byte version (domain, major, minor, patch)
  • data: Union of different proof data types
  • proof: Union of different proof types
  • sync_data: Optional light client updates
post
/proof

Get Configuration Web UI

get

Serves the web-based configuration interface for managing server settings.

Use Case: Local RPC Provider Setup

This endpoint is specifically designed for users running Colibri locally as a trustless RPC provider (see /rpc endpoint). The Web UI provides an accessible way for non-developers to configure the server without editing configuration files directly.

Configuration Options:

  • RPC node endpoints (upstream Ethereum nodes)

  • Beacon node endpoints (for light client sync)

  • Memcached settings (for proof caching)

  • Network settings (host, port, chain ID)

  • Prover settings (local vs. remote proof generation)

Security Note: This endpoint is disabled by default for security reasons. Enable it with WEB_UI_ENABLED=1 environment variable or the -u command-line flag. Only enable on trusted networks (typically localhost for local RPC provider setup).

Responses
chevron-right
200

Configuration UI HTML page

text/html
Responsestring

HTML page with interactive configuration editor

get
/config.html

Get Server Configuration

get

Returns the current server configuration as JSON.

This endpoint is used by the configuration Web UI (/config.html) to display and manage settings. It's part of the local RPC provider setup workflow, allowing programmatic access to server configuration for management tools.

Security Note: This endpoint is disabled by default. Enable it with WEB_UI_ENABLED=1 environment variable or the -u command-line flag. Only enable on trusted networks.

Responses
chevron-right
200

Current server configuration

application/json
get
/config

Update Server Configuration

post

Updates the server configuration and triggers an automatic restart.

How It Works:

  1. Validation: The server validates all parameter values against their definitions (type, range, etc.)

  2. Save: Valid parameters are written to the configuration file

  3. Restart: The server executes exit(0), relying on the service manager (systemd, launchd, docker-compose) to restart it with the new configuration

Requirements:

  • Server must be started with a config file: -f <CONFIG> or --config <CONFIG>

  • WEB_UI_ENABLED=1 must be set (enabled by default with installer packagesarrow-up-right)

  • Service manager (systemd/launchd/docker-compose) must be configured to restart on exit

Restrictions:

  • Sensitive parameters (type: key) cannot be updated via this endpoint for security reasons

  • Integer parameters must be within their defined min/max range

  • Changes take effect after server restart (typically 1-2 seconds)

Use Case:

This endpoint is specifically designed for the local RPC provider setup, allowing non-technical users to adjust settings like RPC endpoints, beacon nodes, or caching options through the Web UI without manually editing configuration files.

Security Note: This endpoint is disabled by default. Only enable on trusted networks (typically localhost for local installations).

Body
Responses
chevron-right
200

Configuration updated successfully

application/json
post
/config

Health Check

get

Returns the server health status and operational statistics.

Use this endpoint for monitoring and health checks in production deployments.

Responses
chevron-right
200

Server is healthy

application/json
get
/health

Prometheus Metrics

get

Returns Prometheus-compatible metrics for monitoring server performance and operations.

Configure your Prometheus instance to scrape this endpoint for comprehensive monitoring of proof generation, verification, and RPC operations.

Responses
chevron-right
200

Prometheus metrics

text/plain
Responsestring

Prometheus text-based exposition format

get
/metrics

Get Beacon Block Header

get

Retrieves the beacon block header for a given block identifier.

This endpoint is part of the Ethereum Beacon Chain API and is used for light client sync operations. Requests are proxied to configured beacon nodes.

Path parameters
block_idstringRequired

Block identifier. Can be one of:

  • head - Canonical head in node's view
  • genesis - Genesis block
  • finalized - Latest finalized block
  • <slot> - Specific slot number
  • <hex_root> - Hex-encoded block root with 0x prefix
Example: head
Responses
chevron-right
200

Block header retrieved successfully

application/json
get
/eth/v1/beacon/headers/{block_id}

Get Light Client Bootstrap

get

Requests the LightClientBootstrap structure for a given post-Altair beacon block root.

This is used to initialize light clients with the current sync committee. See the Ethereum Consensus Specsarrow-up-right for details.

Path parameters
block_rootstring · hexRequired

Hex-encoded block root with 0x prefix

Example: 0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2Pattern: ^0x[a-fA-F0-9]{64}$
Responses
chevron-right
200

Light client bootstrap data

application/json
get
/eth/v1/beacon/light_client/bootstrap/{block_root}

Get Light Client Updates

get

Requests LightClientUpdate instances in the sync committee period range [start_period, start_period + count), leading up to the current head.

Used for light client sync to track sync committee changes across periods. See the Ethereum Consensus Specsarrow-up-right for details.

Query parameters
start_periodstringRequired

Starting sync committee period

Example: 1
countstringRequired

Number of periods to request

Example: 1
Responses
chevron-right
200

Array of light client updates

application/json
get
/eth/v1/beacon/light_client/updates

Get OpenAPI Specification

get

Returns this OpenAPI specification document in YAML format

Responses
chevron-right
200

OpenAPI specification

text/yaml
Responsestring
get
/openapi.yaml
200

OpenAPI specification

Schemas

Quick Start Examples

Generate a Proof

Generate a cryptographic proof for an eth_getBalance request:

The response is an SSZ-encoded C4Request container. For details on the proof format, see the Ethereum Main Proof Requestarrow-up-right specification.

Verify and Execute a Request

Execute a JSON-RPC request with automatic proof verification:

Response:

Execute a Smart Contract Call with Proof

Generate a proof for an eth_call request with bytecode included:

The include_code property ensures that the contract bytecode is included in the proof, enabling fully stateless verification.

Update Configuration

Update server configuration programmatically (requires WEB_UI_ENABLED=1 and a config file):

Response:

Note: After a successful configuration update, the server automatically restarts (via exit(0)), relying on the service manager (systemd/launchd/docker-compose) to restart it with the new settings. This is automatically configured by the installer packagesarrow-up-right.

Health Check

Check the server's operational status:

Response:

Prometheus Metrics

Retrieve metrics for monitoring:

Advanced Features

Client State Parameter

For historic block proofs, you can provide the client's state to optimize proof generation:

The c4 parameter is a hex-encoded representation of the client's current sync committee state, allowing the prover to determine which header proofs are necessary.

Supported JSON-RPC Methods

The following Ethereum JSON-RPC methods are supported with proof generation:

Account & Storage:

  • eth_getBalance

  • eth_getCode

  • eth_getStorageAt

  • eth_getProof

Transactions:

  • eth_getTransactionByHash

  • eth_getTransactionReceipt

  • eth_getTransactionCount

Blocks:

  • eth_getBlockByNumber

  • eth_getBlockByHash

  • eth_blockNumber

Contract Calls:

  • eth_call

Events & Logs:

  • eth_getLogs

Colibri-Specific:

  • colibri_simulateTransaction - Simulate transaction execution with proof

For a complete list of supported methods, see the Supported RPC Methodsarrow-up-right documentation.

Beacon Chain API

The server also provides light client endpoints from the Ethereum Beacon Chain API for sync committee updates:

  • GET /eth/v1/beacon/headers/{block_id} - Retrieve beacon block headers

  • GET /eth/v1/beacon/light_client/bootstrap/{block_root} - Initialize light client

  • GET /eth/v1/beacon/light_client/updates - Sync committee period updates

These endpoints are used internally by the verifier to maintain the current sync committee state and are also available for external light client implementations.

Error Handling

HTTP Status Codes

  • 200 OK - Request successful

  • 400 Bad Request - Invalid request format or parameters

  • 403 Forbidden - Web UI disabled (for /config and /config.html)

  • 404 Not Found - Endpoint or resource not found

  • 500 Internal Server Error - Server error during processing

Error Response Format

Error responses use the following JSON format:

For JSON-RPC errors, the standard JSON-RPC error format is used:

Rate Limiting & Performance

The server is designed for high-performance proof generation and verification. Key performance characteristics:

  • Concurrent Requests: Multiple requests can be processed in parallel

  • Proof Generation: Typically 100-500ms depending on proof complexity

  • Proof Verification: Typically 50-200ms depending on proof size

  • Light Client Sync: Sync committee updates every ~27 hours

For production deployments, consider:

  • Using memcached for caching frequently requested proofs (configure via MEMCACHED_HOST and MEMCACHED_PORT)

  • Monitoring via Prometheus metrics at /metrics

  • Load balancing across multiple RPC nodes (configure via RPC_NODES)

Security Considerations

Web UI Access

The configuration endpoints (/config and /config.html) are disabled by default for security reasons. Only enable them on trusted networks using:

Network Binding

By default, the server binds to 127.0.0.1 (localhost only). To expose the server to other machines:

Warning: Only expose the server to untrusted networks if you have proper security measures in place (firewall, authentication proxy, etc.).

Additional Resources

Last updated