Sui RPC Endpoints

Dwellir provides Sui RPC endpoints at https://api-sui-mainnet-full.n.dwellir.com/<your-api-key> for mainnet. Sui uses a unique network identifier rather than traditional chain IDs. Replace <your-api-key> with the key from your Dwellir dashboard.

Dwellir's Sui endpoints currently provide HTTPS access via JSON-RPC. Sui's architecture differs from EVM chains; for real-time event monitoring, use the JSON-RPC subscription methods available over HTTP or contact our team about dedicated node options with streaming capabilities.

Dwellir's Sui endpoints run full nodes that provide access to current state and recent transaction history. Sui's object-centric model differs from account-based chains; full nodes can query owned objects, transaction effects, and recent checkpoints. For deep historical data requirements, contact our team about dedicated node configurations.

1. Sign up at dwellir.com and retrieve your API key from the dashboard. 2. Replace your current RPC URL (e.g., https://fullnode.mainnet.sui.io:443) with https://api-sui-mainnet-full.n.dwellir.com/<your-api-key>. The API implements Sui's full JSON-RPC specification including object queries, transaction execution, and checkpoint data.

Sui is a high-performance Layer 1 built with Move, offering sub-second finality, parallel transaction execution, and up to 120,000+ TPS. Unlike EVM chains, Sui uses an object-centric data model enabling independent transaction processing. The native token is SUI. Block explorers: suiscan.xyz and suivision.xyz.

Dwellir's Sui endpoints are fully compatible with Sui's official SDKs including @mysten/sui.js (TypeScript), Sui Rust SDK, and Sui Python SDK. The Move programming language is used for smart contracts. Configure your SDK with the Dwellir RPC URL and your API key.

Sui's object-centric model has three ownership types: 1) Owned objects belong to a single address and enable parallel execution (fast path)—ideal for user assets like NFTs or personal tokens, 2) Shared objects can be accessed by multiple transactions but require consensus ordering, causing higher latency and potential contention—use for DEX pools, registries, or multi-party state, 3) Immutable objects (frozen) can never change and are freely readable. Design tip: Minimize shared object usage when possible. If two transactions write to the same shared object simultaneously, one will fail due to contention even if logic is correct.

Sui gas optimization differs from EVM chains due to its object model: 1) Favor owned objects: Transactions touching only owned objects use the 'fast path' (no consensus), resulting in lower fees and latency, 2) Avoid hot shared objects: Frequently-modified shared objects create bottlenecks; consider sharding state across multiple objects, 3) Batch operations: Group related operations in a single Programmable Transaction Block (PTB) to amortize costs, 4) Object cleanup: Delete unneeded objects to receive storage rebates. For high-throughput apps like games, design around owned objects where each user's state is independent.