Skip to main content

gRPC Overview (Beta)

⚙️Early-Stage Feature

This content describes an alpha/beta feature or service. These early stage features and services are in active development, so details are likely to change.

This feature or service is currently available in

  • Devnet
  • Testnet
  • Mainnet

The Sui Full Node gRPC API provides a fast, type-safe, and efficient interface for interacting with the Sui blockchain. Designed for power users, indexers, explorers, and decentralized apps, this API enables access to Sui data with high performance and low latency.

info

Refer to Access Sui Data for an overview of options to access Sui network data.

What is gRPC?​

gRPC offers a high-performance, efficient communication protocol that uses Protocol Buffers for fast, compact data serialization. Its strongly typed interfaces reduce runtime errors and simplify client/server development across multiple languages. With built-in support for code generation, you can scaffold clients in Typescript, Go, Rust, and more. This makes it ideal for scalable backend systems like indexers, blockchain explorers, and data-intensive decentralized apps.

In addition to request-response calls, gRPC supports server-side streaming, enabling real-time data delivery without constant polling. This is especially useful in environments where you need to track events and transactions live. gRPC's binary format is significantly faster and lighter than JSON, saving bandwidth and improving latency.

Refer to when to use gRPC vs GraphQL to access Sui data.

gRPC on Sui​

Protocol buffers define the gRPC interface. You can find the relevant beta .proto files at sui-apis on Github, which apart from the gRPC messages (request and response payloads) include the following services:

ServiceProtoPurpose
TransactionExecutionServicesui/rpc/v2beta2/transaction_execution_service.protoSubmit and execute signed transactions on the Sui network. Wallets and apps use the service to send user actions to the network.
LedgerServicesui/rpc/v2beta2/ledger_service.protoLookup specific checkpoints, transactions, objects and more from the current state and recent history of the Sui network. “History” here refers to the recent past - limited to what a Full node retains.
LiveDataServicesui/rpc/v2beta2/live_data_service.protoQuery up-to-date on-chain data like balances, coin metadata, dynamic fields, or owned objects. Also supports dry-run simulations for transactions.
SubscriptionServicesui/rpc/v2beta2/subscription_service.protoStream live updates for checkpoints. Ideal for building reactive systems such as indexers, bots, and dashboards. Refer to Subscriptions for streaming data.
MovePackageServicesui/rpc/v2beta2/move_package_service.protoAccess metadata and content of Move packages deployed on the Sui network. Useful for tooling, analysis, and smart contract introspection.
SignatureVerificationServicesui/rpc/v2beta2/signature_verification_service.protoValidate signatures outside transaction execution. Helps pre-verify payloads that may include zklogin or other signatures, simulate authentication, or build custom signing workflows.

Use these definitions to generate client libraries in various programming languages.

info

If you were using the v2beta proto files previously, note that the latest definitions are now under the v2beta2 version.

Field masks​

A FieldMask in Protocol Buffers is a mechanism used to specify a subset of fields within a message that should be read, updated, or returned. Instead of retrieving the entire object, a client can request only the specific fields they need by providing a list of field paths. This improves performance and reduces unnecessary data transfer.

In the Sui gRPC API, FieldMasks are used in requests like GetTransaction, GetObject, and so on to control which parts are included in the response (such as, effects and events of a transaction).

Key behaviors:

  • Field masks are defined using google.protobuf.FieldMask and typically appear in the request message as read_mask.
  • You can pass an explicit value of * to request all fields.
  • If you omit read_mask, it defaults to * (all fields), unless documented otherwise.
  • Each field path in the mask must match the field structure of the response proto message. Nested fields are supported using dot notation.
  • In batch APIs, only the top-level read_mask is respected — the API ignores any masks inside sub-requests.
  • In some cases, non-terminal repeated fields might be supported in the mask (even if this is atypical per standard FieldMask behavior).

Field presence​

When using gRPC with Sui, it's important to understand how field presence works, especially when dealing with proto3 syntax. In proto3, primitive fields (like numbers, booleans, and strings) are always initialized to a default value if not present in the message — this means you can’t tell whether a value is explicitly set or just left out. To give you that distinction, Sui marks all fields as optional, even if they’re required by the API.

As a user of the API, this lets you:

  • Detect whether a field value is actually provided or just defaulted.
  • Write clients that can perform partial updates or simulate intent (for example, distinguish between an explicitly empty input versus a missing one).
info

Remember that if a field is marked optional in the proto, it might still be required for the request to be valid — this is a protobuf quirk, not an indication of actual business logic.

Encoding​

In the Sui gRPC API, identifiers with standard human-readable formats are represented as strings in the proto schema:

  • Address and ObjectId: Represented as 64 hexadecimal characters with a leading 0x.
  • Digests: Represented as Base58.
  • TypeTag and StructTag: Represented in their canonical string format (for example, 0x0000000000000000000000000000000000000000000000000000000000000002::coin::Coin<0x0000000000000000000000000000000000000000000000000000000000000002::sui::SUI>)

Pagination​

When using gRPC APIs that return lists of data — such as account balances, owned objects, and so on — you typically need to handle pagination. These APIs return results in chunks and include tokens to help you request the next batch.

Here’s how it works:

  • In the request, provide a page_size to control how many items you want returned. If you leave this unset or set it to 0, the API uses a sensible default.
  • You can also include a page_token in the request, which tells the server where to continue from. You get this token from the previous response.
  • The response includes a list of results and a next_page_token value, which you can pass into your next request to get the next page.
  • When the server returns an empty next_page_token, you’ve reached the end of the list.

Make sure to keep all other parameters in your request the same between paginated calls — otherwise, the server might reject the request with an INVALID_ARGUMENT error.

Errors​

The Sui gRPC services follow the richer error model defined in AIP-193. When an RPC returns a non-OK status code, detailed error information is typically included in the grpc-status-details-bin header. This header contains a google.rpc.Status message encoded in Base64.

You can decode this message to access structured error details, which might include specific causes, context, or metadata. This makes it easier to understand and handle errors programmatically in your client applications.

HTTP headers​

In many gRPC responses, the Sui API includes additional metadata in the form of HTTP headers. These headers provide contextual information about the current network state and might be useful for debugging, telemetry, or understanding the data’s freshness.

Here are the headers you might encounter:

  • x-sui-chain-id: The chain ID of the current network.
  • x-sui-chain: A human-readable name for the current network (such as "mainnet" or "testnet").
  • x-sui-checkpoint-height: The height of the latest checkpoint at the time of the response.
  • x-sui-lowest-available-checkpoint: The earliest checkpoint for which transaction and checkpoint data can still be queried.
  • x-sui-lowest-available-checkpoint-objects: The earliest checkpoint from which object data (input/output) is available.
  • x-sui-epoch: The current epoch of the network.
  • x-sui-timestamp-ms: The network timestamp in milliseconds since the Unix epoch.
  • x-sui-timestamp: The network timestamp in milliseconds since the Unix epoch in human-readable RFC 3339 format.

Not all headers are guaranteed to be present in every API response — they are only included when applicable to the given RPC.

Subscriptions for streaming data​

The SubscriptionService provides real-time streaming updates for on-chain activity via gRPC server-side streaming APIs.

For example, the SubscribeCheckpoint RPC lets you subscribe to the global stream of executed checkpoints. When a subscription is initialized, the stream begins at the latest checkpoint known to the server. Checkpoints are guaranteed to arrive in order and without gaps. This allows clients to track exactly which checkpoint they last processed.

If the stream is interrupted — for example, due to client disconnect or network error — you can resume from the last known checkpoint using other APIs to backfill any missed data before resubscribing.

Streaming APIs are useful for building indexers, dashboards, or bots that need to react to real-time Sui activity with minimal latency. Refer to Access streaming data with buf for information on how to test.

Developer access and usage recipes​

The following recipes show how to accomplish some common tasks using gRPC.

Access using grpcurl​

Simplest way to experiment with gRPC is by using grpcurl.

note

Your results might differ from the examples that follow, depending on the breadth, maturity, and data retention of the gRPC APIs available on the Sui Full node you use.

List available gRPC services​

$ grpcurl <full node URL:port> list

where the port on Sui Foundation managed Full nodes is 443. It should return something like:

grpc.health.v1.Health
grpc.reflection.v1.ServerReflection
sui.rpc.v2beta2.LedgerService
sui.rpc.v2beta2.LiveDataService
sui.rpc.v2beta2.MovePackageService
sui.rpc.v2beta2.SignatureVerificationService
sui.rpc.v2beta2.SubscriptionService
sui.rpc.v2beta2.TransactionExecutionService

List available APIs in the LedgerService​

$ grpcurl <full node URL:port> list sui.rpc.v2beta2.LedgerService

which should return something like:

sui.rpc.v2beta2.LedgerService.BatchGetObjects
sui.rpc.v2beta2.LedgerService.BatchGetTransactions
sui.rpc.v2beta2.LedgerService.GetCheckpoint
sui.rpc.v2beta2.LedgerService.GetEpoch
sui.rpc.v2beta2.LedgerService.GetObject
sui.rpc.v2beta2.LedgerService.GetServiceInfo
sui.rpc.v2beta2.LedgerService.GetTransaction

Get the events and effects details of a particular transaction​

$ grpcurl -d '{ "digest": "J4NvV5iQZQFm1xKPYv9ffDCCPW6cZ4yFKsCqFUiDX5L4" }' <full node URL:port> sui.rpc.v2beta2.LedgerService/GetTransaction

Get the transactions in a particular checkpoint​

$ grpcurl -d '{ "sequence_number": "164329987", "read_mask": { "paths": ["transactions"]} }' <full node URL:port> sui.rpc.v2beta.LedgerService/GetCheckpoint

Get the latest information for a coin type​

$ grpcurl -d '{ "coin_type": "0x2::sui::SUI" }' <full node URL:port> sui.rpc.v2beta2.LiveDataService/GetCoinInfo

List the objects owned by a particular address​

$ grpcurl -d '{ "owner": "0x94096a6a54129234237759c66e6ef1037224fb3102a0ae29d33b490281c8e4d5" }' <full node URL:port> sui.rpc.v2beta2.LiveDataService/ListOwnedObjects

List the dynamic fields in a particular object​

$ grpcurl -d '{ "parent": "0xb57fba584a700a5bcb40991e1b2e6bf68b0f3896d767a0da92e69de73de226ac" }' <full node URL:port> sui.rpc.v2beta2.LiveDataService/ListDynamicFields

Access streaming data with buf​

grpcurl does not support server-side streaming RPCs. To test or experiment with SubscriptionService, use the buf CLI instead.

$ buf curl --protocol grpc https://<full node URL>/sui.rpc.v2beta2.SubscriptionService/SubscribeCheckpoints -d '{ "readMask": "sequenceNumber,digest,summary.timestamp" }'  --timeout 1m

which should return something like:

{
  "cursor": "164324277",
  "checkpoint": {
    "sequenceNumber": "164324277",
    "digest": "AJsK688sDPbzWro1VSN3gVPxR1hfM9v3Bk1M9EhPBc3A",
    "summary": {
      "timestamp": "2025-07-05T16:49:09.788Z"
    }
  }
}
{
  "cursor": "164324278",
  "checkpoint": {
    "sequenceNumber": "164324278",
    "digest": "J35nDAwZm9YRZ4kHJH9oSqCMQ2ZrkbpmshCTi6N5TCpV",
    "summary": {
      "timestamp": "2025-07-05T16:49:10.032Z"
    }
  }
}
{
  "cursor": "164324279",
  "checkpoint": {
    "sequenceNumber": "164324279",
    "digest": "DgoaWNGtWojozP88AnmHskkDbdvyMApP1jVz2wRzPsC5",
    "summary": {
      "timestamp": "2025-07-05T16:49:10.292Z"
    }
  }
}
...
...
...

Sample clients in different programming languages​

This is an example to build a Typescript client for Sui gRPC API. If you want to use a different set of tools or modules that you’re comfortable with, you can adjust the instructions accordingly.

Install dependencies

npm init -y
npm install @grpc/grpc-js @grpc/proto-loader
npm i -D tsx

Project structure

.
├── protos/
│   └── sui/
│       └── node/
│           └── v2beta/
│               ├── ledger_service.proto
│               └── *.proto
├── client.ts
├── package.json

Download all the sui/rpc/v2beta proto files from Github v2beta in the same folder.

Sample client.ts to get events and effects details of a particular transaction

import * as grpc from '@grpc/grpc-js';
import * as protoLoader from '@grpc/proto-loader';
import * as path from 'path';

const PROTO_PATH = path.join(__dirname, 'protos/sui/rpc/v2beta/ledger_service.proto');

// Load proto definitions
const packageDefinition = protoLoader.loadSync(PROTO_PATH, {
  keepCase: true,
  longs: String,
  enums: String,
  defaults: true,
  oneofs: true,
  includeDirs: [path.join(__dirname, 'protos')],
});

const suiProto = grpc.loadPackageDefinition(packageDefinition) as any;
const LedgerService = suiProto.sui.rpc.v2beta.LedgerService;

// Create gRPC client
const client = new LedgerService(
  '<full node URL>:443',
  grpc.credentials.createSsl()
);

// Sample transaction digest in Base58 format
const base58Digest = '3ByWphQ5sAVojiTrTrGXGM5FmCVzpzYmhsjbhYESJtxp';

// Construct the request
const request = {
  digest: base58Digest,
  read_mask: {
    paths: ['events', 'effects'],
  },
};

// Make gRPC call
client.GetTransaction(request, (err: any, response: any) => {
  if (err) {
    console.error('Error:', err);
  } else {
    console.log('Response:', JSON.stringify(response, null, 2));
  }
});

Run the sample client

npx tsx c
info
  • proto-loader handles any nested .proto files - just make sure paths and imports are correct.
  • The example assumes that gRPC is available on port 443 which requires SSL.
  • Digest in the request is directly provided in the Base58 format, but check if you need to decode from your source format.

Best practices​

  • Always use field masks when applicable to reduce response size and latency, especially for large resources.
  • Use TLS (port 443) for production traffic to ensure encrypted transport and prevent downgrade attacks.
  • Use streaming subscriptions for real-time use cases instead of polling repeatedly.
  • Generate client code from the official .proto definitions in sui-rpc-api to ensure compatibility and type safety.
  • Paginate carefully — always check next_page_token and do not assume all data is returned at once.
  • Retry transient failures with exponential backoff, especially for streaming APIs or busy public nodes.
  • Validate all input data, including encodings and message formats, to prevent hard-to-debug API rejections.

Frequently asked questions​

  • Q: Can I use field masks in batch requests?

    • A: Only the top-level read_mask field is respected in batch requests like BatchGetObjects. Any field masks within individual GetObjectRequest items are ignored.

  • Q: Why does the API return fewer results than the requested page_size?

    • A: Even if you request a specific page_size, the server might return fewer items. This could be due to Full node specific limits, filtered results, or reaching the end of available data.

  • Q: Why do some fields say optional if they're required?

    • A: In proto3, marking a field as optional gives the API the ability to detect field presence — that is, whether a field value is explicitly set or simply defaulted. This doesn't mean the field is optional in practice. You still need to follow the API contract to ensure the request is valid.

  • Q: Are all services and related data guaranteed to be available on all Full nodes?

    • A: Full nodes may vary in which services and retention they support. Some services might not be supported yet or some APIs may return NOT_FOUND depending on the node's configuration and data availability.

Full node operator configuration​

Refer to Considerations to enable gRPC.