Summary
Sui gRPC providers give applications a typed, streaming path to Sui data, but access models differ significantly. Public Foundation gRPC endpoints can suit prototypes and low-volume tooling; evaluate their current limits, support, and production terms before depending on them. Managed gRPC providers operate shared endpoints with documented capacity, monitoring, and support, making them a practical default for dApps, indexers, and backend workers. Dedicated Sui gRPC nodes isolate your workload on private infrastructure and are justified when burst behavior, latency, or compliance requirements outgrow shared capacity. The evaluation should be gRPC-first: confirm LedgerService and StateService read support, TransactionExecutionService for ExecuteTransaction and SimulateTransaction, and SubscriptionService for SubscribeCheckpoints, SubscribeTransactions, and SubscribeEvents. Also verify rate limits, burst allowances, regions, failover, and incident communication before moving production traffic. OnFinality provides managed Sui gRPC and RPC infrastructure for mainnet and testnet, with a path to dedicated nodes when workloads need isolation. Start from /networks/sui to review current Sui network support.
Key Takeaways
- Match the gRPC access model to workload risk: public for prototypes, managed shared for most production apps, dedicated for isolation.
- Verify LedgerService, StateService, TransactionExecutionService, and SubscriptionService before integration.
- Test rate limits, burst behavior, streaming stability, regions, and failover before moving traffic.
- Dedicated Sui gRPC nodes are justified by predictable capacity and isolation, not just higher traffic.
Sui gRPC access models: public, managed, dedicated
Sui gRPC access generally falls into three categories. Public Foundation gRPC endpoints may be useful for prototypes, but verify current access terms, rate limits, and support before using them for production. Managed gRPC providers operate shared endpoints with documented capacity, monitoring, and support, which is a practical default for production applications. Dedicated Sui gRPC nodes give your team an isolated endpoint with dedicated resources and configuration, but require a stronger operational or commercial commitment.
This guide is gRPC-first: Full Node JSON-RPC is treated as a legacy or migration surface. The choice is not about ranking vendors; it is about matching the access model to workload requirements. A wallet might start on managed shared capacity, while a high-frequency trading bot or indexer may need dedicated infrastructure from day one.
| Criterion | What to check | Why it matters |
|---|---|---|
| Public Foundation gRPC | Free public endpoints, default ports, rate limits | Fine for prototypes and low-volume tools; production use requires explicit verification of limits and support |
| Managed shared gRPC | Provider-managed endpoint, usage limits, support | Balances capacity and operational overhead for most production applications |
| Dedicated Sui gRPC node | Private endpoint, resource isolation, custom configuration | Predictable performance and isolation for critical workloads |
Core Sui gRPC services to verify
A provider may offer gRPC access, but not every provider exposes the same services. Before integrating, confirm that the endpoint supports the services your workload depends on. For reads, LedgerService and StateService are essential for checkpoint, transaction, object, and balance queries. For transaction workflows, TransactionExecutionService should expose ExecuteTransaction and SimulateTransaction. For real-time data, SubscriptionService should expose SubscribeCheckpoints, SubscribeTransactions, and SubscribeEvents. For broader Sui RPC guidance, see /rpc-assistant/sui-rpc-guide.
- Confirm LedgerService for checkpoint- and transaction-related reads.
- Confirm StateService for object state and balance queries.
- Confirm TransactionExecutionService for ExecuteTransaction and SimulateTransaction.
- Confirm SubscriptionService for streaming workflows.
- If generated clients use wrapper methods, map them back to these service and method names to avoid integration surprises.
Streaming subscriptions: checkpoints, transactions, events
Sui gRPC streaming is most valuable when you need low-latency notifications of chain activity. SubscribeCheckpoints emits new checkpoints as they are finalized, which is useful for syncing indexers or monitoring chain progress. SubscribeTransactions emits transaction digests or transaction data as blocks are processed. SubscribeEvents emits event data for Move modules and packages, which is often used by DeFi dashboards, games, and alerting systems.
Because gRPC uses HTTP/2 and protobuf, these streams are more efficient than polling JSON-RPC endpoints. However, check that the provider keeps subscriptions stable during reconnects and that your client handles backpressure and resubscription logic.
For a quick smoke test, use a placeholder such as: grpcurl -H "authorization: Bearer $AUTH_TOKEN" $GRPC_ENDPOINT SubscriptionService/SubscribeCheckpoints. Replace both placeholders with your provider's values and use the generated client stub for the exact method path.
Capacity planning, rate limits, burst behavior, regions, and support
Capacity planning for Sui gRPC should start with request profiles, not just a single RPS number. Measure normal and peak calls per method, including streaming sessions and backend jobs. Ask the provider how they handle burst traffic, whether method weights or response units apply, and whether streaming connections count separately from unary calls.
Regions matter for latency to validators and users. Verify where gRPC endpoints are deployed and whether you can choose or pin a region. Support details to check include access to request logs, usage dashboards, status updates, and a clear escalation path during incidents.
| Criterion | What to check | Why it matters |
|---|---|---|
| Rate limits | Per-method, per-IP, per-key, and streaming connection limits | Prevents unexpected throttling during traffic spikes |
| Burst behavior | Short-term burst allowance and queuing policy | Launch, mint, or market events can exceed steady-state limits |
| Regions | Endpoint locations, routing, and latency from your users and workers | Global applications need consistent latency |
| Support | Status page, logs, usage analytics, and incident escalation | Debugging production issues requires visibility |
Production reliability, monitoring, failover, and incident communication
A production Sui gRPC dependency needs more than a responsive endpoint. Check the provider's status page, historical incident communication, and whether they offer request-level logging or usage dashboards. Your own client should implement retries with exponential backoff, connection draining on errors, and resubscription logic for streams.
Plan for failover at the application layer. Using a second gRPC provider or a dedicated fallback endpoint can reduce downtime during provider incidents. Test failover regularly, not only during an outage. Also check how the provider communicates maintenance windows and whether they expose a scheduled maintenance feed.
- Review provider status history and incident updates.
- Enable request-level logs or usage analytics if available.
- Implement client retry, backoff, and stream resubscription.
- Test a secondary endpoint or provider before you need it.
- Confirm how maintenance windows are announced.
When a dedicated Sui gRPC node is justified
Dedicated Sui gRPC nodes are not just a bigger shared endpoint. They provide isolated resources, private endpoints, custom configuration, and predictable capacity that is not affected by other tenants. This is justified when your application has strict latency requirements, high sustained throughput, business-critical transactions, or compliance needs that require dedicated infrastructure.
Signs that dedicated infrastructure may be needed include: shared endpoint throttling during peak hours, inconsistent streaming delivery, inability to meet internal SLAs, or a need for custom node settings. The decision is not about ranking providers; it is about isolating a workload that has outgrown shared capacity. For operational guidance, see /rpc-assistant/sui-rpc-node.
- High sustained request volume or streaming fan-out
- Latency-sensitive trading, gaming, or bridge operations
- Compliance or data isolation requirements
- Frequent shared-capacity throttling or burst limits
- Need for custom node configuration or monitoring
Testnet gRPC access and mainnet separation
Testnet Sui gRPC endpoints are valuable for staging, contract testing, and QA automation, but they are not production infrastructure. Keep testnet and mainnet configurations explicit, and do not treat testnet data as permanent or guaranteed. The official Sui faucet is https://faucet.sui.io; verify current faucet policy and limits before relying on it for automated test runs.
Use /rpc-assistant/sui-testnet-rpc for testnet-specific RPC details and keep testnet calls separated from mainnet credentials. OnFinality's Sui testnet support should be used for development and staging, not production traffic.
Next steps: Sui Network Hub.
Frequently Asked Questions
Does Sui support gRPC for production data access?
Yes. Sui full nodes expose gRPC services including LedgerService, StateService, TransactionExecutionService, and SubscriptionService. Managed providers may offer gRPC endpoints, but not all do; confirm the specific methods you need before integration.
What is the difference between public and managed Sui gRPC providers?
Public Foundation endpoints may be rate-limited and have different support terms. Managed providers operate shared endpoints with documented capacity, monitoring, support, and often clearer upgrade paths. Dedicated nodes provide private, isolated infrastructure.
Which gRPC methods should I test for streaming Sui data?
SubscribeCheckpoints, SubscribeTransactions, and SubscribeEvents from SubscriptionService are the core streaming workflows. Test that your client can reconnect and resume streams after interruptions.
How do I test a Sui gRPC endpoint before committing?
Run a grpcurl smoke test with your provider's endpoint and auth token, verify a simple read from LedgerService or StateService, then test each streaming method you need. Measure latency from your deployment regions and review the provider's status page and support process.
When should I move from shared to dedicated Sui gRPC?
Move when shared capacity throttles your traffic, streaming becomes unstable during bursts, latency misses internal SLAs, or you need custom node configuration or data isolation. Dedicated nodes are about predictable capacity, not just higher limits.
Can I use Sui testnet gRPC for production?
No. Testnet gRPC is for staging, contract testing, and QA. Treat testnet data as temporary and keep it separate from mainnet credentials. Use the official faucet at https://faucet.sui.io and verify current policies.