Astar Network TVL is a moving number, and the first thing to understand is that no single RPC method returns it. TVL is an aggregate: someone has to read balances and contract state across many DeFi contracts, price those assets, and add them up. That aggregation happens either in a third-party analytics dashboard or in code you run yourself against an Astar RPC endpoint.
If you are here to check a headline figure, an analytics dashboard is the fastest path. If you are here because you are building a dashboard, a bot, or a risk monitor that needs Astar TVL on a schedule, the rest of this page is about how to get the underlying data reliably.
Decide first: dashboard lookup or self-hosted TVL pipeline
Before writing any code, decide which of these two jobs you actually have. They need very different infrastructure.
| Your goal | Best source | What you need |
|---|---|---|
| Check the current Astar TVL number | Public analytics dashboards that index Astar | Nothing to build; accept the dashboard's methodology |
| Track TVL for one protocol | That protocol's own dashboard or subgraph | Trust the protocol's own accounting |
| Build a custom TVL feed across many contracts | Your own indexer or scheduled job against Astar RPC | A reliable RPC endpoint, contract ABIs, and a price source |
| Alert when TVL moves sharply | Scheduled reads plus a threshold check | Low-latency reads and a stable endpoint you control |
| Historical TVL charts | An indexer with stored events | Archive-capable access or your own database |
If your answer is the first two rows, you can stop reading and use a dashboard. If it is the last three, you need an RPC endpoint you can call on a schedule, and the rest of this article is about doing that well.
Where Astar TVL data actually comes from
Astar is an EVM-compatible network, so most DeFi activity on it looks like DeFi on any EVM chain: lending pools, DEX pools, liquid staking, and vaults. TVL is the sum of the value of assets deposited into those contracts.
To compute it yourself you combine three ingredients:
- Contract state. For each protocol, read the balances it holds. For a DEX pool that means the reserves of each token; for a lending market it means total supplied minus total borrowed; for a vault it means the vault's underlying token balance.
- Token prices. Convert each token balance into a common unit, usually USD. Prices come from an oracle or an off-chain price API, not from Astar itself.
- A definition of what counts. Do you count only Astar-native contracts, or also bridged assets? Do you count staked ASTR? Different dashboards answer this differently, which is why two sources can report different Astar TVL numbers on the same day.
That last point matters more than people expect. When you compare Astar TVL across sources, check whether they include liquid staking, whether they double-count assets that are deposited into a second protocol, and whether they price bridged tokens at the bridged value or the native value.
Chain settings at a glance
Before you can read any contract, you need to point a client at Astar. The network is EVM-compatible, so standard Ethereum tooling works.
| Setting | Value |
|---|---|
| Network | Astar (EVM-compatible) |
| Native token | ASTR |
| Tooling | Standard EVM JSON-RPC clients (ethers, viem, web3.js) |
| RPC access | Shared endpoint or dedicated node via OnFinality |
| Explorer | Astar block explorer for manual contract inspection |
OnFinality provides an Astar RPC endpoint you can use for reads, and dedicated Astar nodes if your TVL pipeline needs consistent throughput. See the Astar RPC network page for the current endpoint details, and RPC pricing if you want to compare shared and dedicated options.
Reading Astar contract state over JSON-RPC
Every TVL calculation starts with a read. For a simple ERC-20 balance held by a protocol contract, you call eth_call with the balanceOf selector. Here is a minimal curl example against an Astar RPC endpoint:
curl -s https://astar.api.onfinality.io/public \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_call",
"params": [
{
"to": "0xTokenContractAddress",
"data": "0x70a08231000000000000000000000000ProtocolContractAddress"
},
"latest"
]
}'
The data field is the 4-byte balanceOf(address) selector followed by the 32-byte padded address. For a DEX pool you would instead call getReserves() on the pair contract, and for a lending market you would call the market's accounting methods.
Doing this by hand for dozens of contracts gets old quickly. In JavaScript with viem, a TVL read for one pool looks like this:
import { createPublicClient, http, formatUnits } from "viem";
const client = createPublicClient({
transport: http("https://astar.api.onfinality.io/public"),
});
const pairAbi = [
{
name: "getReserves",
type: "function",
stateMutability: "view",
inputs: [],
outputs: [
{ name: "reserve0", type: "uint112" },
{ name: "reserve1", type: "uint112" },
{ name: "blockTimestampLast", type: "uint32" },
],
},
];
const [reserve0, reserve1] = await client.readContract({
address: "0xPairContractAddress",
abi: pairAbi,
functionName: "getReserves",
});
console.log("reserve0", formatUnits(reserve0, 18));
console.log("reserve1", formatUnits(reserve1, 18));
From there, multiply each reserve by its USD price, sum across pools, and you have a TVL figure. The RPC layer is the easy part; the accounting rules are where the real work lives.
Production readiness checklist for a TVL pipeline
A TVL feed that runs once is a script. A TVL feed that runs every few minutes and feeds a dashboard or alert is infrastructure. Before you ship it, check these points.
- Endpoint stability. A scheduled job that fails because the endpoint rate-limits you will produce gaps in your chart. If you poll frequently or read many contracts per cycle, a dedicated node removes the shared-pool variability. See dedicated nodes.
-
Batch your reads. Use
eth_callbatching or multicall contracts to reduce round trips. Fewer requests means fewer chances to hit a limit and a faster cycle. - Pin your block. Read all contracts at the same block number so your TVL snapshot is internally consistent. A snapshot that reads pool A at block 100 and pool B at block 105 can be subtly wrong.
- Handle reverts. A paused or upgraded contract will revert. Your job should log the failure and continue rather than crash the whole cycle.
- Store history yourself. RPC endpoints serve current and recent state. If you want a TVL chart, write each snapshot to your own database.
- Separate price risk from chain risk. If your price API is down, your TVL number is wrong even if every RPC call succeeded. Track both failure modes.
Common failure modes and how to debug them
When your Astar TVL number looks wrong, the cause is usually one of a handful of things. Work through this table before assuming the RPC endpoint is at fault.
| Symptom | Likely cause | Fix |
|---|---|---|
| TVL drops to zero suddenly | A contract read reverted or an address changed | Check the contract on the explorer; verify the address and ABI |
| TVL is consistently ~2x another source | Double-counting assets deposited into a second protocol | Define whether you count nested deposits |
| Number drifts from a dashboard | Different price source or different block | Align block height and price feed |
| Reads intermittently fail | Rate limiting or a flaky shared endpoint | Batch reads, add retries, or move to a dedicated node |
| Historical reads fail | Node is not serving old state | Use an indexer or archive-capable access for history |
| Values look fine but chart has gaps | Scheduled job crashed silently | Add monitoring and alerting on the job itself |
A quick sanity check is to read a single well-known contract directly and compare it to the explorer. If the raw read matches the explorer but your aggregate does not, the bug is in your aggregation, not in the RPC layer.
Choosing between shared RPC and dedicated nodes for TVL tracking
For occasional reads, a shared Astar RPC endpoint is enough. For a pipeline that polls many contracts on a tight schedule, the tradeoffs shift.
| Workload | Shared RPC | Dedicated node |
|---|---|---|
| Manual checks and one-off reads | Good fit | Overkill |
| A few contracts every few minutes | Usually fine | Optional |
| Hundreds of reads per cycle | May hit limits | Better fit |
| Low-latency alerting | Variable | More predictable |
| Historical or archive reads | Limited | Depends on configuration |
OnFinality offers both: a managed Astar RPC endpoint for general use and dedicated Astar nodes when you need consistent throughput. If you are unsure which fits, the guide to choosing an RPC provider walks through the evaluation criteria, and supported RPC networks lists what is available today.
Key Takeaways
- Astar Network TVL is an aggregate, not a single RPC call. You either trust a dashboard's methodology or compute it yourself.
- To compute it, read contract state over Astar's EVM-compatible JSON-RPC, price the assets, and sum them.
- Different sources report different Astar TVL because they define what counts differently. Check the methodology before comparing.
- Pin all reads to one block for a consistent snapshot, batch your calls, and store history in your own database.
- Shared RPC endpoints suit occasional reads; dedicated nodes suit frequent, high-volume TVL pipelines.
- Most "wrong TVL" bugs are aggregation or pricing bugs, not RPC bugs. Verify a raw read against the explorer first.
Frequently Asked Questions
Does Astar have a single TVL API?
No. Astar exposes standard EVM JSON-RPC methods, not a TVL endpoint. TVL is computed by reading many contracts and pricing the assets, either in a dashboard or in your own code.
Why does Astar TVL differ between dashboards?
Because each dashboard decides what to include: native versus bridged assets, liquid staking, and whether nested deposits are double-counted. Always compare methodology, not just the number.
Can I read Astar TVL with ethers or viem?
Yes. Astar is EVM-compatible, so standard EVM libraries work. Point your client at an Astar RPC endpoint and call the relevant contract methods.
Do I need a dedicated node to track Astar TVL?
Only if your polling volume or latency needs outgrow a shared endpoint. For occasional reads, a shared endpoint is usually sufficient. For frequent, high-volume pipelines, a dedicated node gives you more predictable throughput.
How do I get historical Astar TVL?
RPC endpoints serve current and recent state. For history, run an indexer that stores events, or use archive-capable access. Most teams store their own snapshots over time.
Where can I find the Astar RPC endpoint?
The current endpoint details are on the Astar RPC network page. OnFinality also lists RPC pricing for shared and dedicated options.
Related resources
Originally published at OnFinality.
Top comments (0)