How to get a Sui RPC endpoint for DeFi (2026 guide)

TL;DR

On Sui, a single DeFi swap is never one RPC call — pulling a pool’s reserves, the user’s coin objects, dynamic fields, and a dry-run quote can fan out into a dozen object reads before the trade is even signed, so the public 100-requests-per-30-seconds throttle collapses the instant two traders hit your AMM at once. Add Sui’s public JSON-RPC shutdown — mainnet endpoints go offline the week of July 27, 2026 and are fully decommissioned by mid-October 2026 — and RPC selection becomes a roadmap decision, not just an uptime one. The nuance that matters: only Sui’s public endpoints are affected, so a managed provider keeps serving JSON-RPC while you move to gRPC call by call. This guide shows how Sui RPC endpoints actually work for DeFi, where the public ones break, and how to deploy a private endpoint on Chainstack.

Tomorrow, Sui Foundation's public mainnet JSON-RPC endpoints shut down.

Full decommission lands mid-October.

Still calling JSON-RPC? Move to gRPC or GraphQL RPC through a data provider already running the new stack.

— Sui Developers (@suidevelopers) July 27, 2026

What is a Sui RPC endpoint

A Sui RPC endpoint is the network entry point your DeFi app calls to read object state and submit transactions, and it does not speak Ethereum JSON-RPC. Sui exposes its own JSON-RPC surface — methods like sui_getObject, suix_getOwnedObjects, suix_getBalance, and sui_dryRunTransactionBlock — built around objects and checkpoints rather than accounts and blocks. Everything on Sui is an object with a unique ID and a version, so a query targets object IDs, not a single account address with a mapping behind it. This is the structural fact that makes Sui RPC behave differently from anything in the EVM world.

For a DeFi application, the endpoint is what powers nearly every user-facing action:

• Reading an AMM pool’s reserves and fee tier (sui_getObject on the shared pool object)
• Enumerating a wallet’s coin objects before building a swap or deposit (suix_getOwnedObjects, suix_getCoins)
• Fetching balances across coin types for the portfolio view (suix_getBalance, suix_getAllBalances)
• Reading dynamic fields that hold position data, ticks, or sub-account state (suix_getDynamicFields)
• Simulating a swap or liquidation to quote output and gas before signing (sui_dryRunTransactionBlock, sui_devInspectTransactionBlock)
• Broadcasting the signed programmable transaction block (sui_executeTransactionBlock)
• Streaming or querying fills, swaps, and liquidation events (suix_queryEvents over JSON-RPC, or the gRPC checkpoint stream filtered client-side)

You can review the full list of supported methods in the Sui JSON-RPC API reference.

Endpoint quality on Sui is felt most acutely in read amplification: because a single DeFi position can span an owned coin object, a shared pool object, and several dynamic fields, one user interaction translates into a burst of object reads — and a shared endpoint that throttles mid-burst returns a half-loaded position, not a clean error.

How Sui RPC differs from EVM chains

If you are coming from Ethereum, the hardest part of Sui is not new method names — it is unlearning the account-and-log mental model. There is no eth_getLogs, no global key-value account state, and no nonce. State lives in discrete objects, each owned by an address or shared across the network, each carrying its own version number. A DeFi pool is not a contract holding balances in a mapping; it is a shared object that every trader’s transaction must touch.

That single fact drives the differences that matter for RPC selection:

• Reads are object lookups, not account queries. You fetch state by object ID and walk dynamic fields, rather than calling a view function against a contract address. A portfolio screen that is one eth_call on Ethereum becomes a fan-out of getObject and getDynamicFields calls on Sui.
• There is no mempool and no nonce. Owned-object transactions execute in parallel without ordering through a mempool; conflicting attempts to spend the same owned object are rejected as equivocation rather than queued. Transactions that touch shared objects (every AMM swap) are sequenced through consensus.
• Shared-object contention replaces gas-auction congestion. Under load, the bottleneck on a hot DeFi pool is consensus ordering on that shared object, not a fee market — so retry and backoff logic has to be built around object versioning, not nonce bumping.
• Finality is checkpoint-based. Sui commits transactions into checkpoints with sub-second finality; there is no probabilistic block-confirmation count to wait out.
• The public API is being switched off — but JSON-RPC is not disappearing. Sui Foundation is retiring its public JSON-RPC (mainnet the week of July 27, 2026) and steering new work onto a typed gRPC API. JSON-RPC stays in the node software, so a managed provider keeps serving it while you migrate call by call. EVM assumptions about a permanent, provider-agnostic JSON-RPC surface still do not transfer.

The practical consequence: provider selection for Sui DeFi is about read throughput and API roadmap, not about which eth_ methods are unlocked. A provider that throttles object reads or never ships gRPC will quietly cap your protocol’s growth once the public JSON-RPC endpoints are gone.

Sui RPC endpoint options

Public vs private Sui RPC endpoints

For Sui DeFi the public-versus-private question is decided by one number: how many object reads your busiest screen fans out into, multiplied by your concurrent users. Mysten Labs runs free public full nodes, and they are genuinely useful for development — but they are rate-limited in a way that a real trading interface outgrows almost immediately.

Official public endpoints:

• Mainnet: https://fullnode.mainnet.sui.io:443
• Testnet: https://fullnode.testnet.sui.io:443

⚠️ The public Mysten Labs full nodes are throttled to roughly 100 requests per 30 seconds (about 3.3 req/s) and are explicitly not meant for production traffic — the Sui docs themselves recommend using dedicated nodes or a professional RPC provider for any high-volume application. On a chain where one swap fans out into a dozen reads, that ceiling is reached by a handful of simultaneous users.

Public Sui RPC	Private Sui RPC
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
Rate limit	~100 req / 30s	No aggressive throttling
Object-read amplification	Throttle hit by a few concurrent users	Headroom for fan-out reads
JSON-RPC + gRPC	Public JSON-RPC gone by Oct 2026	Both interfaces on the same node

The dominant failure mode here is not downtime — it is a half-loaded position screen when a read burst clips the 3.3 req/s ceiling mid-fetch. For a DeFi product, managed infrastructure is what keeps a single user’s portfolio query from competing with every other user’s swap for the same shared throughput.

Full node vs archive Sui node

On Sui, historical access is about replaying checkpoint and object-version history — reconstructing what a pool’s reserves were at a past checkpoint, not just reading their current value. A full node answers “what is this object now”; an archive node answers “what was every version of this object.”

Full node access	Archive node access
Current pool reserves and live coin balances	Historical reserve and TVL reconstruction across checkpoints
Quoting and simulating a swap right now	Backfilling swap and liquidation events for analytics
Building and broadcasting transactions	Auditing a past object version after an exploit or dispute
Real-time position monitoring	Computing historical APY and fee accrual for a vault

If your DeFi product ships charts, P&L, historical APY, or any compliance export, you need an archive node — current-state full nodes prune the older object versions those features depend on. Chainstack supports archive access for Sui, billed at 2 request units per call versus 1 for full-node reads.

HTTPS vs WebSockets

Sui’s event subscription methods (suix_subscribeEvent, suix_subscribeTransaction) run over the JSON-RPC WebSocket, and on a managed node they keep working — gRPC streaming currently exposes only checkpoint subscriptions, not per-event ones. So for DeFi the realistic split is HTTPS for reads and writes, with live fills and liquidation feeds either staying on the JSON-RPC WebSocket or driven off the gRPC checkpoint stream and filtered client-side.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Object reads, swap simulation, tx submission	Live event/fill subscriptions (suix_subscribeEvent)
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

For high-throughput event pipelines — fill feeds, liquidation watchers — consider subscribing to the checkpoint stream over gRPC and filtering events client-side, which scales better than many per-event WebSocket subscriptions. Simpler feeds can stay on suix_subscribeEvent over the JSON-RPC WebSocket, which your managed node keeps serving.

Migrating from JSON-RPC to gRPC on Sui

Because only Sui’s public JSON-RPC is going away, the migration is not a rewrite — on a provider that serves JSON-RPC and gRPC from the same node, you port call by call while everything keeps running. Chainstack’s Sui JSON-RPC to gRPC migration guide has the full call-by-call mapping and a gRPC quickstart; most DeFi read and write methods map directly onto a gRPC service:

JSON-RPC method	gRPC service / method
sui_getObject	LedgerService/GetObject
sui_multiGetObjects	LedgerService/BatchGetObjects
suix_getOwnedObjects	StateService/ListOwnedObjects
suix_getDynamicFields	StateService/ListDynamicFields
suix_getBalance	StateService/GetBalance
sui_dryRunTransactionBlock	TransactionExecutionService/SimulateTransaction
sui_executeTransactionBlock	TransactionExecutionService/ExecuteTransaction

A handful of query methods — suix_queryEvents, suix_queryTransactionBlocks, suix_getStakes — have no gRPC equivalent and keep working over your managed JSON-RPC endpoint, so there is no method you are forced to abandon on the shutdown date. In TypeScript, the same @mysten/sui SDK (2.16+) exposes a gRPC client whose default gRPC-Web transport works over HTTPS from both Node.js and the browser:

// Same node, gRPC transport — @mysten/sui 2.16+
import { SuiGrpcClient } from '@mysten/sui/grpc';
const grpc = new SuiGrpcClient({ network: 'mainnet', baseUrl: 'YOUR_CHAINSTACK_ENDPOINT' });
const price = await grpc.core.getReferenceGasPrice();

How to get a private Sui RPC endpoint with Chainstack

1. Log in to the Chainstack console (or create an account)
2. Create a new project
3. Select Sui as your blockchain protocol
4. Choose network: Sui Mainnet or Sui Testnet
5. Deploy the node
6. Open Access/Credentials and copy your JSON-RPC (HTTPS) endpoint; the gRPC endpoint is sui-mainnet.core.chainstack.com:443 (testnet: sui-testnet.core.chainstack.com:443)
7. Run a quick connectivity check before wiring it into production code

You can deploy a private Sui RPC node on Chainstack in a few minutes, then drop the endpoint straight into the official @mysten/sui TypeScript SDK:

import { SuiClient } from '@mysten/sui/client';
// Point the client at your private Chainstack HTTPS endpoint
const client = new SuiClient({
  url: 'YOUR_CHAINSTACK_ENDPOINT',
});
// One meaningful read: fetch a DeFi pool object by its object ID
const pool = await client.getObject({
  id: '0xPOOL_OBJECT_ID',          // shared object ID of the AMM pool
  options: { showContent: true },  // include the Move struct fields (reserves, fees)
});
console.log(pool.data?.content);

📖 For the full integration guide, see the Chainstack Sui tooling documentation.

You can also access Chainstack Sui RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP.

Chainlist is EVM-only, so it does not apply to Sui — there is no chain ID to add to MetaMask and no Chainlist entry to copy an endpoint from.

Chainstack pricing for Sui RPC

Chainstack bills on request units rather than opaque compute credits, which makes a DeFi workload’s cost easy to model from your actual read and write counts — see the full Chainstack pricing page for plan details and overage rates.

Plan	Cost	Requests/Month	RPS	Overage (per 1M extra)
Developer	$0	3M RU	25	$20
Growth	$49	20M RU	250	$15
Pro	$199	80M RU	400	$12.50
Business	$499	200M RU	600	$10
Enterprise	$990+	400M+ RU	Unlimited	$5

Archive reads on Sui consume 2 request units per call instead of 1, and archive plus debug/trace access starts on the Growth tier. For DeFi teams that need predictable throughput rather than per-request metering, the Unlimited Node add-on offers flat-fee RPS tiers, and Dedicated Nodes start from $0.50/hour plus storage for isolated, latency-stable infrastructure.

How to estimate monthly cost

1. Count the object reads behind each user screen — a portfolio view or pool page is rarely one call on Sui.
2. Multiply by expected daily active users and sessions to get a baseline read volume.
3. Add write volume: swaps, deposits, and liquidations each submit a transaction plus a dry-run simulation.
4. Convert to monthly request units and match against a plan tier, leaving headroom above your peak RPS.
5. Size for fan-out, not for users: because one Sui DeFi action expands into many object reads, a few hundred concurrent traders can generate the request volume a naive estimate would assign to thousands — budget for the multiplier.

Production readiness checklist

• Primary + fallback RPC provider configured
• Request timeout policy set
• Retry logic with exponential backoff implemented
• Credentials stored in env/secret manager (never hardcoded)
• Monitoring for latency, error rate, and throttling
• Alerts for sustained degradation
• Object-read fan-out batched or coalesced so one user screen does not burst past your RPS limit
• Shared-object contention handled: retry on pool-object version conflicts under load, not just on network errors
• Migration path validated: confirm your provider’s gRPC and GraphQL roadmap before JSON-RPC is fully retired

Troubleshooting common Sui RPC issues

Issue	Cause	How to fix
429 Too Many Requests	Object-read fan-out exceeded the public ~3.3 req/s ceiling	Move to a managed endpoint; batch related object reads into fewer calls
Half-loaded position / partial state	Read burst throttled mid-fetch on a shared endpoint	Coalesce getObject + getDynamicFields calls; use a dedicated endpoint with read headroom
Swap transaction rejected as equivocation	Two transactions tried to spend the same owned coin object	Serialize transactions per owned object; refresh object versions before retrying
Pool transaction fails under load	Shared-object contention on a hot AMM pool during consensus sequencing	Retry with backoff on version conflicts; surface contention separately from network errors
dryRunTransactionBlock quote drifts from execution	Pool reserves changed between simulation and submission	Re-simulate close to submission; tighten slippage tolerance
Event subscription silently stops	Dropped JSON-RPC WebSocket connection	Add reconnect/heartbeat logic; keep suix_subscribeEvent on the managed JSON-RPC WebSocket, or stream checkpoints over gRPC and filter client-side

Conclusion

The expensive failure on Sui is not an endpoint going down — it is a position screen that loads three of its four objects because a read burst clipped the 3.3-requests-per-second public ceiling, and the user sees a wrong balance with no error to explain it. That bug does not show up in development, where one tester never generates concurrent fan-out. It shows up the first time real traders hit a shared pool at the same time, and it is brutal to diagnose because the RPC layer returned a partial success, not a failure.

The pattern that survives is straightforward: build on a private endpoint with real read headroom from day one, batch the object reads behind each screen so one interaction does not fan out into a throttle event, and get off the public endpoints before the July 2026 shutdown by moving to a provider that serves JSON-RPC and gRPC on the same node — so JSON-RPC keeps working and you migrate to gRPC call by call instead of rewriting your data layer under a deadline. Public nodes are for prototyping; production DeFi is not the place to discover their ceiling.

Deploy a Sui node on the free tier to prototype, then move to Dedicated Nodes or the Unlimited Node add-on once real trading volume arrives.

FAQ

Which SDK should I use to connect to a Sui RPC endpoint? For TypeScript and JavaScript, use the official Mysten Labs @mysten/sui SDK, which wraps the JSON-RPC surface and is migrating toward the newer gRPC and GraphQL transports. For Python, pysui is the maintained option, and there are official Rust and Go SDKs as well. Point any of them at your private Chainstack HTTPS endpoint instead of the public full node and your throughput ceiling disappears.

Why isn’t the public Sui endpoint enough for a DeFi app? Because Sui’s object-centric model amplifies reads: one swap or portfolio view fans out into many getObject and getDynamicFields calls, so the public ~100-requests-per-30-seconds limit is reached by a handful of concurrent users — long before you have a real user base. The throttle does not return a clean error either; it returns half-loaded state.

What does the JSON-RPC deprecation mean for my Sui DeFi protocol? Only Sui Foundation’s public JSON-RPC endpoints are being switched off — mainnet the week of July 27, 2026, fully decommissioned by mid-October 2026. JSON-RPC stays in the node software, so a managed provider keeps serving it. For DeFi teams the move is therefore call-by-call, not a rewrite: pick a provider that runs JSON-RPC and gRPC on the same node, port performance-sensitive reads and checkpoint streaming to gRPC, and keep methods with no gRPC equivalent (like suix_queryEvents) on JSON-RPC.

How do I handle shared-object contention on a busy AMM pool? Every swap touches the pool as a shared object, which is sequenced through consensus, so under heavy load you will see transactions fail on version conflicts rather than on gas. Build retry logic around object versioning — refresh the pool object and re-simulate before resubmitting — and treat contention as a distinct error class from network failures and throttling.

Do I need an archive node for a Sui DeFi product? If you display historical TVL, price charts, APY, or export data for compliance, yes — current-state full nodes prune older object versions, so reconstructing a pool’s past reserves requires archive access. Real-time quoting and trade execution run fine on a full node; the archive node is for the analytics and audit surface.

What metrics should I monitor on a Sui RPC endpoint? Track read latency and error rate per object-read call, throttling (429) frequency, and the fan-out factor of your busiest screens — how many RPC calls one user action generates. On Sui that last metric is the one that predicts when you will outgrow a plan tier, since request volume scales with object reads, not just user count.

Additional resources

• Migrate Sui from JSON-RPC to gRPC — Chainstack’s call-by-call method mapping and gRPC quickstart
• Sui: On-chain validator analytics with pysui — a hands-on Chainstack tutorial for querying Sui network data with Python
• Chainstack Sui tooling documentation — SDK setup across TypeScript, Python, Rust, and Go
• Chainstack introduces support for Sui — background on Chainstack’s Sui integration
• More Sui tutorials and articles on the Chainstack Blog