How to get an Aptos RPC endpoint for RWA (2026 tutorial)

TL;DR

The first time an Aptos RWA app runs an allowlist check across every holder of a tokenized fund, the public fullnode answers a few view calls and then starts returning rate-limit errors mid-batch — and because Aptos has no eth_getLogs and no JSON-RPC, there’s no event-log shortcut to fall back on. Compliance state, NAV, and yield all live inside Move resources you read one view call at a time, so endpoint throughput is the bottleneck for real-world-asset workloads on Aptos. This guide explains why, and how to get a private Aptos RPC endpoint that survives a real compliance sweep.

What is an Aptos RPC endpoint

An Aptos RPC endpoint is the REST API surface your application uses to talk to an Aptos fullnode. Unlike Ethereum and the chains that copied its JSON-RPC interface, Aptos exposes a RESTful HTTP API: you GET account resources, submit transactions to a /transactions route, and call read-only Move functions through the /view endpoint. For richer queries — token holders, historical transfers, aggregated balances — there is a separate Indexer GraphQL API. There is no eth_call, no eth_getLogs, and no eth_* namespace at all. For real-world-asset (RWA) applications, this matters more than it sounds: the data you care about — a fund’s net asset value, a holder’s KYC status, whether a wallet is frozen — is stored as a typed Move resource on an account, and you read it by calling the module’s view function at a specific ledger version.

What depends on the endpoint, specifically on Aptos:

• Reading account resources (token balances, ownership of Fungible Asset and Digital Asset objects)
• Calling Move view functions for read-only state — NAV, yield parameters, allowlist and freeze status on RWA tokens
• Submitting and simulating transactions (mint, transfer, redeem, compliance-gated operations)
• Querying transactions by version or by account for audit and reconciliation
• Reading events emitted by Move modules via the events-by-handle route
• Indexer GraphQL queries for holder lists, historical balances, and token activity

You can review the full set of operations in the Aptos fullnode REST API reference.

On Aptos, endpoint quality shows up as missing or stale resource reads rather than dropped transactions: a view call that quietly returns a rate-limit error mid-batch can leave an RWA compliance check half-finished, and a fund dashboard showing yesterday’s NAV is worse than one showing none.

How Aptos RPC differs from EVM chains

If you are coming from Ethereum, the hardest part of Aptos is unlearning the JSON-RPC mental model. Aptos is not EVM-compatible, and the differences are structural, not cosmetic.

The API transport is REST, not JSON-RPC. You do not send {"method": "eth_call", "params": [...]} to a single endpoint. You make HTTP requests to resource-shaped routes — /accounts/{address}/resource/{resource_type}, /view, /transactions/by_version/{version}. Tooling built around web3.js, ethers.js, or raw JSON-RPC batching does not apply.

State is organized as resources, not contract storage slots. On Ethereum, an RWA token’s compliance data lives in mapping slots you reach with eth_getStorageAt or a view function over a deployed contract. On Aptos, that same data is a Move resource — a typed struct — stored under an account address. A tokenized fund’s balance is a FungibleStore resource; its compliance flags are fields inside a module-defined struct. You read them by their fully-qualified type, and the type system guarantees the asset can’t be silently duplicated or dropped.

There is no event-log query primitive. The single biggest adjustment for RWA developers: Aptos has no eth_getLogs. You cannot scan a block range for Transfer or ComplianceCheck events across many contracts in one call. Aptos events are tied to event handles on specific resources, and broad historical event analysis goes through the Indexer GraphQL API instead — a completely different query model that you provision and scale separately.

Transactions are versioned globally. Aptos assigns a monotonically increasing version to every transaction across the whole chain, not just a block number. For RWA audit trails, this is an advantage — you can read an account’s exact resource state “as of version N” — but it means your historical queries are keyed on version, and reconstructing state at an arbitrary past version requires an archive node.

The practical takeaway: every assumption about how you fetch and watch on-chain data has to be rebuilt for the Move resource model, and the provider you choose has to expose the REST API, the /view endpoint, and the Indexer — not a generic “Ethereum-compatible” RPC.

Aptos RPC endpoint options

Public vs private Aptos RPC endpoints

For RWA workloads the public-vs-private decision comes down to one question: can the endpoint absorb a fan-out read? A single compliance sweep over a tokenized fund means one view call per holder, and the public Aptos fullnode is anonymously rate-limited on a compute-unit basis — it is sized for exploration, not for an app that reads allowlist status across thousands of addresses on every settlement cycle.

Official public endpoints:

• Mainnet: https://fullnode.mainnet.aptoslabs.com/v1
• Testnet: https://fullnode.testnet.aptoslabs.com/v1

⚠️ The public Aptos Labs fullnodes apply anonymous, compute-unit-based rate limits per IP. There is no SLA, and a batch of view calls or Indexer queries can exhaust your quota mid-operation — leaving an RWA compliance check or NAV refresh partially completed with no clean error boundary. The Aptos APIs documentation steers production traffic to API-key access and dedicated infrastructure rather than the anonymous public endpoint.

Factor	Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
Rate limit	Anonymous per-IP compute-unit cap	No aggressive throttling
/view fan-out (compliance sweeps)	Throttled mid-batch	Sustained throughput
Indexer GraphQL access	Shared, best-effort	Provisioned and scalable

When a compliance check has to touch every holder before a fund can settle, a shared endpoint that throttles partway through the batch is not a reliability inconvenience — it is a blocked settlement. That is the case for a managed endpoint on Aptos RWA workloads.

📖 For a detailed comparison of Aptos RPC providers, see Best Aptos RPC providers in 2026.

Full node vs archive Aptos node

For RWA on Aptos, historical access is a compliance requirement, not a nice-to-have: auditors and regulators ask what a fund’s NAV was, and which wallets held it, at a specific point in the past — which on Aptos means reading resource state at a specific ledger version.

Full node access	Archive node access
Current NAV and yield view reads	Historical NAV reconstruction at a past version
Live allowlist and freeze-status checks	Audit trail of compliance state changes over time
Submitting mint, transfer, and redeem transactions	Reconstructing holder balances as of any prior version

Because Aptos versions every transaction globally, a Chainstack archive node lets you query an account’s exact resource state as of any historical version — the foundation for RWA reporting, NAV attestation, and regulatory audit trails that a full node (which prunes older state) cannot serve. Chainstack supports archive nodes for Aptos.

HTTPS vs WebSockets

Aptos does not offer the JSON-RPC-style WebSocket subscriptions EVM developers expect (eth_subscribe has no Aptos equivalent), so it is worth being clear about what real-time access actually looks like before reaching for a transport table. Standard fullnode interaction is HTTPS request/response against the REST API; live data is handled either by polling the REST endpoint or by the Indexer GraphQL API, not by a persistent fullnode socket.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	view calls, resource reads, tx submission, NAV/compliance polling	Streaming token-activity feeds via Indexer subscriptions where available
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

In practice, most Aptos RWA applications run entirely over HTTPS: poll view functions for NAV and compliance state, submit transactions over REST, and use the Indexer GraphQL API for holder and activity queries. Persistent fullnode WebSocket subscriptions are not part of the standard Aptos REST model.

How to get a private Aptos RPC endpoint with Chainstack

You can deploy a private Aptos RPC node on Chainstack in a few steps:

1. Log in to the Chainstack console (or create an account).
2. Create a new project
3. Select Aptos as your blockchain protocol
4. Choose network: Aptos Mainnet or Aptos Testnet
5. Deploy the node
6. Open Access and credentials and copy your HTTPS endpoint
7. Run a quick connectivity check before wiring it into production code

Once you have the endpoint, connect with the official Aptos TypeScript SDK and make a read-only view call — the same primitive an RWA app uses to check a fund’s NAV or a wallet’s compliance status:

import { Aptos, AptosConfig, Network } from "@aptos-labs/ts-sdk";

// Point the SDK at your Chainstack endpoint instead of the public fullnode
const config = new AptosConfig({
  network: Network.MAINNET,
  fullnode: "YOUR_CHAINSTACK_ENDPOINT/v1", // REST API base, note the /v1 suffix
});
const aptos = new Aptos(config);

// Read-only Move view call — no gas, no transaction
const balance = await aptos.view({
  payload: {
    function: "0x1::coin::balance",
    typeArguments: ["0x1::aptos_coin::AptosCoin"],
    functionArguments: ["0x1"],
  },
});

console.log(balance);

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

You can also access Chainstack Aptos 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 Aptos — there is no Chainlist entry to add an Aptos endpoint to a wallet.

Chainstack pricing for Aptos RPC

Chainstack bills on request units rather than opaque compute credits, which makes an Aptos RWA workload easier to model: a compliance sweep is a predictable number of view calls, so you can forecast cost directly from how often you re-check holders. 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	from $990	400M+ RU	Unlimited	$5

Advanced options relevant to Aptos RWA workloads:

• Archive node access (from the Growth plan) — archive requests consume 2 RU each versus 1 RU for full-node requests; essential for historical NAV and audit-trail queries. See Chainstack archive data.
• Unlimited Node — flat monthly fee with RPS-tiered throughput, useful when a fund’s compliance sweeps drive high, steady view volume.
• Dedicated Nodes — isolated infrastructure from $0.50/hour per node plus storage, for institutional RWA platforms that need throughput guarantees.

How to estimate monthly cost

1. Estimate baseline reads per minute (NAV polling, dashboard refreshes, balance lookups)
2. Add transaction submissions (mints, transfers, redemptions) per minute
3. Multiply by your re-check frequency to get requests per month
4. Map the total against the plan tiers above, leaving headroom for overage
5. The Aptos-specific multiplier: RWA compliance is a fan-out, not a single call — one allowlist sweep over N holders is N view requests, so a fund with thousands of holders re-checked on every settlement cycle can dwarf its baseline read volume. Size for the sweep, not the average.

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
• Archive endpoint confirmed for historical NAV and audit-trail reads before any compliance reporting goes live
• /view fan-out rate-limited on your side so a full holder sweep cannot self-throttle mid-batch
• Indexer GraphQL access provisioned and load-tested separately from the REST fullnode — they are different services with different limits

Troubleshooting common Aptos RPC issues

Issue	Cause	How to fix
429 Too Many Requests	Public endpoint anonymous compute-unit cap hit	Move to a managed endpoint with dedicated throughput
Compliance sweep stops partway	/view fan-out exhausted the per-IP rate limit mid-batch	Use a private endpoint and add a client-side rate limiter sized to the full holder count
view call returns a type or resource error	Wrong fully-qualified resource type, or resource not present on the account	Verify the module address and struct type; confirm the account actually holds the resource
Historical NAV query returns missing state	Full node has pruned the target ledger version	Query an archive node, which retains resource state at any past version
Holder list or activity query is slow or incomplete	Treating the REST fullnode as an indexer	Route holder and historical-activity queries through the Indexer GraphQL API, not the fullnode REST API
Looking for eth_getLogs / eth_subscribe equivalents	Applying an EVM mental model to a Move/REST chain	Use event-handle reads for module events and the Indexer for broad historical event analysis

Conclusion

The failure that catches Aptos RWA teams is not a dramatic outage — it is a compliance sweep that returns 429 halfway through. One view call per holder, multiplied across a tokenized fund, against an anonymous public endpoint, and the batch dies in the middle with some wallets checked and some not. There is no eth_getLogs to fold the check into a single range scan, and no JSON-RPC batch to lean on; the Move resource model means each piece of compliance state is its own read, so the endpoint’s sustained throughput is the whole ballgame. That half-finished sweep is hard to diagnose precisely because it looks like a partial success.

The pattern that works: build on a private endpoint from day one, put a client-side rate limiter in front of every fan-out so a full holder sweep can never self-throttle, and provision an archive node before you write a line of NAV reporting — historical resource reads at a specific ledger version are non-negotiable for RWA audit trails on Aptos. Treat the Indexer GraphQL API as a separate dependency with its own capacity, not an afterthought bolted onto the REST fullnode.

Start free, then move compliance-critical traffic to dedicated infrastructure as your fund grows.

FAQ

Why can’t I use eth_getLogs to track RWA transfers on Aptos? Aptos is not EVM-compatible and has no eth_getLogs or JSON-RPC namespace at all. Events are tied to event handles on specific Move resources, so there is no single call that scans a block range for transfer or compliance events across contracts. For broad historical event analysis — holder lists, transfer history, activity feeds — you use the Aptos Indexer GraphQL API, which is a separate service from the fullnode REST API.

How do I read a tokenized fund’s NAV or a wallet’s compliance status on Aptos? Both are read-only Move view function calls against the resource where that state is stored. You call the RWA module’s view function through the /view endpoint, passing the relevant account address; it returns the typed value with no gas cost and no transaction. Because each holder is a separate read, a full compliance sweep is a fan-out of many view calls — which is why endpoint throughput matters so much for RWA workloads.

Do I need an archive node for Aptos RWA applications? For compliance reporting, yes. Auditors and regulators ask what a fund’s NAV and holder set were at a specific point in the past, and Aptos versions every transaction globally — so reconstructing resource state “as of version N” requires an archive node, because a full node prunes older state. Chainstack supports archive nodes for Aptos; archive requests consume 2 RU each.

Which SDKs work with an Aptos RPC endpoint? The official @aptos-labs/ts-sdk (TypeScript/JavaScript) and the Python aptos-sdk are the primary clients, alongside the Aptos CLI for module publishing and Move tooling. Point any of them at your private endpoint’s REST base (with the /v1 suffix) instead of the public fullnode. Ethereum SDKs like ethers.js and web3.js do not work with Aptos.

Is the public Aptos endpoint enough for production? No. The public Aptos Labs fullnodes apply anonymous, per-IP compute-unit rate limits with no SLA, and an RWA workload’s view fan-out exhausts that quota quickly — leaving compliance sweeps and NAV refreshes partially completed. Production RWA traffic needs a private endpoint with dedicated throughput and provisioned Indexer access.

Does Aptos support WebSocket subscriptions like Ethereum? Not in the JSON-RPC sense. There is no eth_subscribe equivalent on the fullnode. Real-time data on Aptos comes from polling REST view calls or from the Indexer GraphQL API, where streaming-style queries are available. Most Aptos RWA applications run entirely over HTTPS.

Additional resources

• Aptos: Publish a module to save and retrieve a message on-chain — hands-on Move module tutorial on Chainstack docs
• Chainstack Aptos tooling documentation
• Aptos fullnode REST API reference — official Aptos developer documentation
• RPC infrastructure for RWA protocols — node requirements for real-world-asset workloads
• Top 7 RWA token data tools for developers in 2026 — including the open-source Chainstack rwa-sdk
• More Aptos tutorials and articles on the Chainstack Blog