🕸️JSON-RPC API Reference

This page details the HTTP endpoints serviced by the block engine.

JSON-RPC HTTP Methods

The block engine accepts HTTP requests using the JSON-RPC 2.0 specification.

Request Formatting

To make a JSON-RPC request, send an HTTP POST request with a Content-Type: application/json header. The JSON request data should contain 4 fields:

• jsonrpc: string - set to "2.0"

• id: number - a unique client-generated identifying integer

• method: string - a string containing the method to be invoked

• params: array - a JSON array of ordered parameter values

We follow the same request formatting as Solana JSON-RPC requests. You can find the documentation here.

Without Authorization (Default)

Currently, no authentication is required to send requests. Any changes to the authentication mechanism will be updated in the documentation and communicated to all stakeholders.

With Authorization (using UUID)

Custom Rate Limits: Custom rate limits can be accessed using a custom header and query parameter with UUID V4 API-Keys. These can be used in two different ways:

1. Header Field: Include the API key in the x-jito-auth header.

   • Example: x-jito-auth: <uuid>

2. Query Parameter: Include the API key as a query parameter.

   • Example: api/v1/bundles?uuid=<uuid>

Definitions

• Bundle: A list of transactions that execute sequentially and atomically, meaning "all or nothing." A bundle only succeeds if all individual transactions within it succeed.

• Hash: A SHA-256 hash of a chunk of data.

• Pubkey: The public key of an Ed25519 key-pair.

• Tip Account: Accounts to which a tip can be paid for processing bundles. Clients submitting bundles must pay a tip for this service.

• Transaction: A list of Solana instructions signed by a client keypair to authorize those actions.

• Signature: An Ed25519 signature of a transaction's payload data, including instructions, used to identify transactions.

State Commitment

The commitment level indicates how finalized a block is at a given point in time. Listed from most to least finalized, the commitment levels are:

• "finalized" : The node will query the most recent block confirmed by a supermajority of the cluster as having reached maximum lockout. This means the cluster has recognized this block as finalized.

• "confirmed" : The node will query the most recent block that has been directly voted on by a supermajority of the cluster, incorporating votes from gossip and replay. It does not count votes on descendants of a block, only direct votes on that block. This level also upholds "optimistic confirmation" guarantees from release 1.3 onwards.

• "processed" - The node will query its most recent block. Note that this block may still be skipped by the cluster.

Please refer to configuring-state-commitment for more details.

RpcResponse Structure

Methods that take a commitment parameter return an RpcResponseContext JSON object consisting of two parts:

• context : An RpcResponseContext JSON structure that includes the slot field where the operation was evaluated. For example:

      "context": {
      "slot": 1
    },

• value : The value returned by the operation itself. For example:

        "value": [
            {
                "bundle": {
                    "signatures": [
                        "3Eq21vXNB5s86c62bVuUfTeaMif1N2kUqRPBmGRJhyTA",
                        "2nBhEBYYvfaAe16UMNqRHre4YNSskvuYgx3M6E4JP1oDYvZEJHvoPzyUidNgNX5r9sTyN1J9UxtbCXy2rqYcuyuv"
                    ]
                },
                "slot": 1234,
                "confirmationStatus": "finalized",
                "err": "null"
            }
        ]