摘要
Astar Network TVL 衡量的是 Astar 和 Soneium 对齐生态中 DeFi 合约的总锁定价值,通常从索引器或分析仪表板读取,而不是从单个链上数字读取。需要实时 TVL、合约余额或事件历史的开发者通过 RPC 端点查询 Astar,然后自行聚合结果。
本页解释了 Astar TVL 数据的来源,如何使用 JSON-RPC 和 JavaScript 提取底层链上价值,以及在 TVL 跟踪按计划运行时,如何在共享 RPC 端点和专用节点基础设施之间做出选择。
Astar Network TVL 是一个不断变化的数字,首先要明白的是,没有任何单一的 RPC 方法可以返回它。TVL 是一个聚合值:需要有人读取许多 DeFi 合约的余额和合约状态,对这些资产进行定价,然后将它们相加。这种聚合要么发生在第三方分析仪表板中,要么发生在你自己针对 Astar RPC 端点运行的代码中。
如果你来这里是为了查看一个头条数字,分析仪表板是最快的途径。如果你来这里是因为你正在构建一个需要定期获取 Astar TVL 的仪表板、机器人或风险监控器,那么本页的其余部分将介绍如何可靠地获取底层数据。
首先决定:仪表板查询还是自托管 TVL 管道
在编写任何代码之前,先确定你实际拥有以下哪项工作。它们需要非常不同的基础设施。
| 你的目标 | 最佳来源 | 你需要什么 |
|---|---|---|
| 查看当前的 Astar TVL 数字 | 索引 Astar 的公共分析仪表板 | 无需构建;接受仪表板的方法论 |
| 跟踪一个协议的 TVL | 该协议自己的仪表板或子图 | 信任协议自己的会计 |
| 跨多个合约构建自定义 TVL 数据源 | 你自己的索引器或针对 Astar RPC 的定时任务 | 可靠的 RPC 端点、合约 ABI 和价格源 |
| 当 TVL 剧烈波动时发出警报 | 定时读取加上阈值检查 | 低延迟读取和你控制的稳定端点 |
| 历史 TVL 图表 | 存储事件的索引器 | 支持归档的访问或你自己的数据库 |
如果你的答案是前两行,你可以停止阅读并使用仪表板。如果是后三行,你需要一个可以按计划调用的 RPC 端点,本文的其余部分将介绍如何做好这一点。
Astar TVL 数据实际来自哪里
Astar 是一个 EVM 兼容网络,因此其上的大多数 DeFi 活动看起来就像任何 EVM 链上的 DeFi:借贷池、DEX 池、流动性质押和保险库。TVL 是存入这些合约的资产价值总和。
要自己计算它,你需要结合三个要素:
- 合约状态。 对于每个协议,读取它持有的余额。对于 DEX 池,这意味着每种代币的储备;对于借贷市场,这意味着总供应量减去总借款量;对于保险库,这意味着保险库的底层代币余额。
- 代币价格。 将每个代币余额转换为通用单位,通常是美元。价格来自预言机或链下价格 API,而不是来自 Astar 本身。
- 什么算数的定义。 你只计算 Astar 原生合约,还是也包括桥接资产?你计算质押的 ASTR 吗?不同的仪表板对此有不同的回答,这就是为什么两个来源在同一天可能报告不同的 Astar TVL 数字。
最后一点比人们预期的更重要。当你比较不同来源的 Astar TVL 时,检查它们是否包括流动性质押,是否重复计算存入第二个协议的资产,以及它们是以桥接价值还是原生价值对桥接代币进行定价。
链设置一览
在读取任何合约之前,你需要将客户端指向 Astar。该网络兼容 EVM,因此标准的以太坊工具可以工作。
| 设置 | 值 |
|---|---|
| 网络 | Astar(EVM 兼容) |
| 原生代币 | ASTR |
| 工具 | 标准 EVM JSON-RPC 客户端(ethers、viem、web3.js) |
| RPC 访问 | 通过 OnFinality 的共享端点或专用节点 |
| 浏览器 | Astar 区块浏览器用于手动合约检查 |
OnFinality 提供了一个可用于读取的 Astar RPC 端点,以及如果你的 TVL 管道需要一致吞吐量的专用 Astar 节点。请参阅 Astar RPC 网络页面 获取当前端点详情,以及 RPC 定价 如果你想比较共享和专用选项。
通过 JSON-RPC 读取 Astar 合约状态
每个 TVL 计算都从读取开始。对于协议合约持有的简单 ERC-20 余额,你使用 balanceOf 选择器调用 eth_call。以下是一个针对 Astar RPC 端点的最小 curl 示例:
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"
]
}'
data 字段是 4 字节的 balanceOf(address) 选择器,后跟 32 字节填充的地址。对于 DEX 池,你会改为在配对合约上调用 getReserves(),对于借贷市场,你会调用市场的会计方法。
手动为几十个合约执行此操作很快就会过时。在 JavaScript 中使用 viem,一个池的 TVL 读取如下所示:
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));
从那里开始,将每个储备乘以其美元价格,跨池求和,你就得到了一个 TVL 数字。RPC 层是简单的部分;会计规则才是真正的工作所在。
TVL 管道的生产就绪检查清单
运行一次的 TVL 数据源是一个脚本。每隔几分钟运行一次并为仪表板或警报提供数据的 TVL 数据源是基础设施。在发布之前,请检查以下几点。
- 端点稳定性。 因端点速率限制而失败的定时任务会在图表中产生缺口。如果你频繁轮询或每个周期读取许多合约,专用节点可以消除共享池的变异性。请参阅 专用节点。
- 批量读取。 使用
eth_call批处理或多调用合约来减少往返次数。更少的请求意味着更少触及限制的机会和更快的周期。 - 固定你的区块。 在同一区块号读取所有合约,以便你的 TVL 快照内部一致。在区块 100 读取池 A 而在区块 105 读取池 B 的快照可能会微妙地出错。
- 处理回滚。 暂停或升级的合约将回滚。你的任务应记录失败并继续,而不是使整个周期崩溃。
- 自己存储历史。 RPC 端点提供当前和最近的状态。如果你想要 TVL 图表,请将每个快照写入你自己的数据库。
- 将价格风险与链风险分开。 如果你的价格 API 宕机,即使每个 RPC 调用都成功,你的 TVL 数字也是错误的。跟踪这两种故障模式。
常见故障模式及如何调试它们
当你的 Astar TVL 数字看起来错误时,原因通常是少数几种情况之一。在假设 RPC 端点有问题之前,请先查看此表。
| 症状 | 可能原因 | 修复 |
|---|---|---|
| TVL 突然降至零 | 合约读取回滚或地址更改 | 在浏览器上检查合约;验证地址和 ABI |
| TVL 始终是另一个来源的约 2 倍 | 重复计算存入第二个协议的资产 | 定义你是否计算嵌套存款 |
| 数字与仪表板漂移 | 不同的价格源或不同的区块 | 对齐区块高度和价格源 |
| 读取间歇性失败 | 速率限制或不稳定的共享端点 | 批量读取、添加重试或迁移到专用节点 |
| 历史读取失败 | 节点不提供旧状态 | 使用索引器或支持归档的访问来获取历史 |
| 值看起来正常但图表有缺口 | 定时任务静默崩溃 | 对任务本身添加监控和警报 |
一个快速的健全性检查是直接读取一个众所周知的合约并将其与浏览器进行比较。如果原始读取与浏览器匹配但你的聚合不匹配,那么错误在于你的聚合,而不是 RPC 层。
在共享 RPC 和专用节点之间选择用于 TVL 跟踪
对于偶尔的读取,共享 Astar RPC 端点就足够了。对于按紧凑时间表轮询许多合约的管道,权衡会发生变化。
| 工作负载 | 共享 RPC | 专用节点 |
|---|---|---|
| 手动检查和一次性读取 | 适合 | 过度 |
| 每隔几分钟几个合约 | 通常可以 | 可选 |
| 每个周期数百次读取 | 可能触及限制 | 更适合 |
| 低延迟警报 | 可变 | 更可预测 |
| 历史或归档读取 | 有限 | 取决于配置 |
OnFinality 提供两者:用于一般用途的托管 Astar RPC 端点和当你需要一致吞吐量时的专用 Astar 节点。如果你不确定哪个适合,选择 RPC 提供商指南 介绍了评估标准,支持的 RPC 网络 列出了当前可用的内容。
关键要点
- Astar Network TVL 是一个聚合值,而不是单个 RPC 调用。你要么信任仪表板的方法论,要么自己计算。
- 要计算它,请通过 Astar 的 EVM 兼容 JSON-RPC 读取合约状态,对资产进行定价,然后求和。
- 不同的来源报告不同的 Astar TVL,因为它们对什么算数的定义不同。在比较之前检查方法论。
- 将所有读取固定到一个区块以获得一致的快照,批量调用,并将历史存储在你自己的数据库中。
- 共享 RPC 端点适合偶尔读取;专用节点适合频繁、高容量的 TVL 管道。
- 大多数“错误的 TVL”错误是聚合或定价错误,而不是 RPC 错误。首先对照浏览器验证原始读取。
常见问题解答
Astar 有单一的 TVL API 吗?
没有。Astar 暴露标准的 EVM JSON-RPC 方法,而不是 TVL 端点。TVL 是通过读取许多合约并对资产进行定价来计算的,无论是在仪表板中还是在你自己的代码中。
为什么 Astar TVL 在不同仪表板之间不同?
因为每个仪表板决定包含什么:原生资产与桥接资产、流动性质押,以及嵌套存款是否被重复计算。始终比较方法论,而不仅仅是数字。
我可以使用 ethers 或 viem 读取 Astar TVL 吗?
可以。Astar 兼容 EVM,因此标准的 EVM 库可以工作。将你的客户端指向 Astar RPC 端点并调用相关的合约方法。
我需要专用节点来跟踪 Astar TVL 吗?
只有当你的轮询量或延迟需求超出共享端点时。对于偶尔的读取,共享端点通常就足够了。对于频繁、高容量的管道,专用节点提供更可预测的吞吐量。
如何获取历史 Astar TVL?
RPC 端点提供当前和最近的状态。对于历史,运行一个存储事件的索引器,或使用支持归档的访问。大多数团队会随时间存储自己的快照。
我在哪里可以找到 Astar RPC 端点?
当前端点详情在 Astar RPC 网络页面 上。OnFinality 还列出了共享和专用选项的 RPC 定价。