常见问题

几乎总是链搞错了。Arc 主网和 Arc Testnet 是两个网络，由两个主机名提供服务，各有彼此独立的索引——任何一个都不持有另一个的哪怕一个区块。把主网哈希粘进测试网站点是解析不出来的，反过来同样如此。

每个页面都在页脚写明它属于哪条链以及那条链的 ID，因此在断定某个哈希不存在之前请先核对。地址与哈希不同，它在两条链上都是有效的，两个页面都会加载：它们是恰好共用二十个字节的两段互不相关的历史。

Arcscan 对 Arc Testnet 的索引从区块 53,500,000 开始。它下面的区块在这里从未被索引，因此没有任何 Arcscan 界面能够回答关于它们的问题——正如 /v1/chain 所说，该区间的空结果是 Arcscan 缺失的历史，而不是链缺失的。

这样的区块仍然能打开，因为它的头部是从节点而不是从索引读取的，页面也会直截了当地说明缺的是哪一半：

主网不受影响：它的索引一直抵达区块 0，并自那里起连续。逐条数据流的详情见数据覆盖范围。

因为目前任何主网合约都还无法在任何地方被验证。Arcscan 从 Sourcify 读取已验证源码，而 /v1/chain 对链 5042 报告 verified_source: false，并附上这条说明：

所以主网合约页面只展示链本身提供的内容，到此为止。验证表单在主网上仍会加载，但它一打开就说明同一件事——Sourcify 并未把链 5042 列为受支持，因此提交会被拒绝——而不是接受一份注定不可能成功的上传。这里没有什么在等 Arcscan。

测试网不一样：Sourcify 确实收录了链 5042002，/v1/chain 在那里报告 verified_source: true。不过 Arcscan 持有的是一份缓存，而不是一份镜像：

实际后果是：第一个打开某个合约页面的人，正是促使它的源码被获取的人。一个已在上游验证、但在这里还从未被请求过的合约，其页面上没有源码——而那是一次缓存未命中，不是关于该合约的任何陈述。

在单笔交易自己的页面上，那里它所发出的调用是实时从节点读取的。主网上没有全链范围的列表：那需要 Arcscan 的 traces 索引，而今天这个索引没有任何区块。被索取时，API 会用文字拒绝，而不是返回一个空页面：

空列表读起来会是「没有发生过内部调用」，那是另一个说法，而且是假的。本站每一处缺口都是这个形状：在数据未被持有的地方给出一句话，而绝不是一个零。

不权威——请把它们当作参考。这里的代币价格由链上池子推导而来，Arcscan 会把它来自哪个池子、在哪个区块上观察到一并发布出来，好让这个数字可以被核对，而不是被相信。当没有任何池子跨过深度下限时就没有价格，页面会用文字说明，而不是显示一个可能被读成零的破折号。

本站的每一个美元价值都继承这一点：它恰好就是价格与余额的算术；当两者之一未知时，该价值会被报告为未知，而不是照算不误。市值是总供应量乘以价格——Arcscan 没有这条链的流通量数据，也不会去估算。

Arcscan 跟随链头。Arc 大约每半秒产生一个区块——实测于 2026年8月10日，/v1/chain 报告主网 506 ms、测试网 536 ms——而最终性是即时的，因此已经存在的区块永远不会被重组掉。索引在链头之后落后少量区块运行，并持续追赶。

本页不打印任何实时数字，因为写在这里的任何数字在几秒内就是错的。当前链头、平均出块时间和每条数据流的落后量都在网络状态上，它读取的正是本回答所引用的同一份文档。

不需要，阅读时也从来不会要求这两样。Arcscan 根本没有账户——页头里的「登录」控件是被刻意渲染成禁用状态的，因为没有什么可以登录，而一个看上去可用却其实不可用的控件是在撒谎。这里没有密钥、没有等级，也没有什么需要注册。

唯一涉及钱包的地方是可选的合约交互面板，在你按下「连接 Web3」之前它什么也不做：它与你本来就装好的扩展通信，Arcscan 既不持有私钥，也看不到私钥。阅读本站的任何页面，都不需要你签署任何东西。

有——https://rpc.arc-scan.io，仅限 Arc 主网。它通过 HTTPS POST 路由到若干独立提供方并具备故障转移，回答常规的读取方法。一次调用就能确认你连到了哪条链：

$ curl -s -X POST https://rpc.arc-scan.io \
    -H 'content-type: application/json' \
    --data '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x13b2"
}

有几类请求是被刻意拒绝的，每一次拒绝都会说明是什么以及为什么，而不是含糊地失败：所有签名类方法（「This endpoint holds no keys and will not forward a signing request」）、整个 trace_ 和 debug_ 命名空间，以及 eth_subscribe——这里没有 WebSocket 传输，因此没有东西可以承载订阅。完整的方法列表和故障转移行为见公共 RPC。

不要钱，也不需要。这个端点在设计上就是公开的：没有认证、没有 API 密钥、没有按调用方的配额，也没有等级模型。你不必告诉我们你是谁就能使用它。

唯一的限制是在边缘按调用方施加的洪泛限制，因此猛敲端点的客户端会被降速，而不是被计费或封禁。它不会做的事是编造答案：当所有能提供某个方法的提供方都不可用时，调用会返回一个如实说明这一点的错误。见公共 RPC。