Query Astar TVL Data: RPC Calls vs. Indexing
A practical guide to fetching Astar Network TVL-related on-chain data, showing when a direct RPC call is enough and when you need an indexer, with a runnable Node.js example and failure handling.
If you want to work with "Astar Network TVL" data as a developer, the first decision is not which endpoint to hit but whether you need raw RPC access or an indexed query layer. This guide answers that up front, then walks through a runnable example that reads a token balance over JSON-RPC, explains what that number does and does not tell you about TVL, and shows where an indexer fits in. You can start from the Astar network page on OnFinality to see how RPC access to Astar is offered, but the concepts below apply to any Astar RPC provider.
Answer first: RPC or indexing?
Astar TVL is an aggregate: it is the summed value of assets locked in contracts across the chain, priced in a reference currency. No single JSON-RPC method returns "TVL." RPC gives you point reads and logs; an indexer gives you historical, aggregated, queryable state.
So the rule of thumb is: use RPC when you need a current balance, a contract call result, or a specific block's data. Use an indexer when you need TVL over time, per-protocol breakdowns, or cross-contract aggregation that would otherwise require scanning many blocks yourself.
This distinction matters because developers often reach for an RPC endpoint expecting an analytics answer. The example below deliberately shows the RPC side so you can see exactly what it returns and where it stops.
- RPC: single calls, current state, logs by block range you request.
- Indexing: pre-processed, queryable history and aggregates.
- TVL is derived data — you compute it from balances plus prices, or you query it from an indexer that already did.
Runnable example: read a balance over Astar JSON-RPC
The snippet below uses Node.js 18+ (global fetch) to call eth_getBalance on an Astar RPC endpoint you supply. It does not hardcode any provider URL — you pass your own endpoint via an environment variable, which is the correct pattern for any provider, including the OnFinality Astar network page.
The result is a balance in wei for one address. That is a building block for TVL, not TVL itself.
// astar-balance.mjs — Node.js 18+
const RPC_URL = process.env.ASTAR_RPC_URL;
const ADDRESS = process.env.ASTAR_ADDRESS;
if (!RPC_URL || !ADDRESS) {
console.error('Set ASTAR_RPC_URL and ASTAR_ADDRESS first.');
process.exit(1);
}
async function getBalance() {
const res = await fetch(RPC_URL, {
method: 'POST',
headers: { 'content-type': 'application/json' },
body: JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'eth_getBalance',
params: [ADDRESS, 'latest'],
}),
});
if (!res.ok) {
throw new Error(`HTTP ${res.status} from RPC endpoint`);
}
const json = await res.json();
if (json.error) {
throw new Error(`RPC error ${json.error.code}: ${json.error.message}`);
}
if (typeof json.result !== 'string') {
throw new Error('Unexpected response shape: no result string');
}
return BigInt(json.result);
}
try {
const wei = await getBalance();
console.log('Balance (wei):', wei.toString());
console.log('Balance (native units):', (Number(wei) / 1e18).toFixed(6));
} catch (err) {
console.error('Balance lookup failed:', err.message);
process.exit(1);
}Run it with your own endpoint and address: ASTAR_RPC_URL=https://your-astar-endpoint ASTAR_ADDRESS=0x... node astar-balance.mjs. Expected result: a line like Balance (wei): 1234500000000000000 followed by the native-unit figure.
Failure handling is explicit: missing env vars exit early, non-2xx HTTP throws, a JSON-RPC error object throws with its code and message, and an unexpected response shape throws rather than silently returning NaN. This is the minimum you want before trusting any number that feeds a TVL calculation.
From a balance to a TVL figure
To turn balances into TVL you need three things: the set of contracts and tokens that count as "locked," the balance of each at a given block, and a price for each asset at that block. RPC can give you the balances; prices usually come from an oracle or an external price feed.
Doing this for one block is feasible with RPC. Doing it across many blocks, many contracts, and many tokens is where direct RPC calls become impractical — you would be issuing thousands of calls and doing your own aggregation and caching. That is the point where an indexer earns its place.
If you are still mapping out the concepts, the OnFinality Learn library covers RPC and indexing fundamentals without assuming a specific provider.
- Define your TVL scope explicitly (which contracts, which tokens).
- Snapshot balances at a specific block for reproducibility.
- Attach prices from a source you trust and record the timestamp.
- Aggregate off-chain or via an indexer for historical series.
When to switch to an indexer
Switch to indexing when your question is historical or aggregate: "what was TVL last Tuesday," "which protocol grew fastest this month," or "sum locked value across 40 contracts." An indexer ingests blocks and logs, stores them in a queryable store, and lets you ask those questions with a query instead of a loop of RPC calls.
A practical way to decide: if answering your question requires more than a handful of RPC calls per request, or requires data from past blocks you did not store, index it. If it is a single current read, keep it on RPC.
For teams weighing the operational side of running RPC access versus indexing, the OnFinality RPC Assistant is a reasonable next read on how RPC access is typically set up and reasoned about.
- Historical series → index.
- Single current value → RPC.
- Cross-contract aggregation → index.
- One contract call result → RPC.
Measure, don't assume
Any claim about latency, throughput, or reliability of a specific endpoint should come from your own measurement, not from a guide. To evaluate an Astar RPC endpoint for a TVL pipeline, time a fixed batch of eth_getBalance calls against it from your own environment and record p50 and p95 latency, error rate, and rate-limit responses.
Do the same for your indexer queries: measure query latency and result freshness (how far behind chain head the indexed data is). Those two numbers — latency and freshness — tell you more about fitness for a TVL dashboard than any marketing page.
Start with the Astar network page on OnFinality to see the access options, then benchmark from your own machine before committing a pipeline to any endpoint.
- Measure p50/p95 latency and error rate yourself.
- Track indexer freshness relative to chain head.
- Record the block number alongside every TVL snapshot for reproducibility.