交易

交易页面回答三个问题——它有没有做成什么、它转移了什么、它花了多少——而在 Arc 上，这三个问题的答案都与大多数浏览器读者所熟悉的链不同。

交易页面包含什么#

从交易列表、从某个区块，或把哈希粘进搜索框，都可以打开一笔交易。概览是一连串带标签的行——交易哈希、状态、区块、时间戳、发送方和交互对象（接收方），然后是价值与代币的转移，再是金额、交易手续费和 Gas 价格。比这更重的内容都放在各自的标签页里，因此打开一笔交易绝不会卡在某个 tracer 上。

标签页	它显示什么
概览	上面那些带标签的行，加上一个「更多详情」可展开区域，里面是 Gas 上限与使用量、手续费拆解、其他属性，以及解码后的输入数据。
内部交易	调用树，前提是 tracer 仍能为那个区块生成一棵。见下文——这里的空表格会是一句假话，因此页面不会渲染出一张空表。
日志	该交易发出的每一个事件，在事件签名已知时会被解码。标签上的数字是日志条数。
状态	该交易导致的余额、nonce 和存储差异，来自 diff 模式的 tracer。
获取原始交易 JSON	节点自身给出的该交易及其收据的 JSON，原样呈现且可复制。它不是一个标签页——它在标签页旁边的 ⋮ 菜单里。

状态#

状态有三个取值，不是两个。它读自收据，而收据要么说明执行已完成，要么说明它已回滚，要么已经无法再被读取。

标记	它的含义
成功	收据表明执行已完成。
失败	该交易已回滚。它试图做的一切都没有生效，但它在链上，而且手续费照样被收取了。
未知	Arcscan 无法告诉你发生的是二者中的哪一种。交易本身是最终的，也没有改变。

已回滚的交易绝不会显示为成功

这是一条有来历的规则：早先的一个版本在收据缺失时默认按成功处理，于是给已回滚的交易打上了绿色对勾并发布出去。凡是回滚原因可以还原的地方，它都会被解码并显示在标记旁边——合约自身的 require 消息、编译器的 panic 代码，或者带参数的具名自定义错误——而原始回滚数据始终只有一次点击之遥，因为那一行上的其余内容都是对它的解读。

当结果未知时#

一笔交易的结果只存在于它的收据里。节点按滑动窗口裁剪收据，而保留区块体的时间要长得多，因此越过那道边界之后，交易仍然能渲染，但它的结果已无法从节点恢复。Arcscan 自己的索引覆盖了这段空档的大部分，所以只有在两个来源都不持有收据时，「未知」才会到达你面前。它是一个真实的答案，不是错误，也不是加载状态，页面会用文字说明，而不是在一个灰色药丸旁边打印一个零手续费。覆盖范围从哪里开始、到哪里结束，详见数据覆盖范围。

没有待处理状态，没有确认数#

Arc 把自己的最终性报告为 instant：区块一经提交即为最终，无法被重组掉。因此交易页面上任何地方都没有确认数计数器——没有什么在朝着「安全」往上数——Arcscan 会在区块旁边显示一个已结算的「最终确定」状态。同样也没有待处理或内存池视图可供跳转，因为根本没有待处理状态可显示。

那么，一个解析不到任何东西的哈希意味着什么？

有两种可能，页面会把两种都说出来，而不是猜测。要么这笔交易比 Arcscan 已读取的数据更新，要么节点已经裁剪了某个足够旧的区块的「哈希到区块」查找——这种情况下区块仍然列出该交易，只是按哈希查找的能力没有了。页面会打印链头高度，好让你判断自己处在哪一种情况。

Gas 和手续费都以 USDC 计#

Arc 的原生资产——也就是用来支付 Gas 的东西——是 USDC，18 位小数。仅这一点就免去了其他链上手续费所需的换算：手续费和它的美元价值是同一个数字，因此页面上没有任何一处是某个数字乘以某个汇率的结果。

行	它是什么
金额	该交易本身转移的 USDC，18 位小数。
交易手续费	为处理它而支付的总额，以 USDC 计。
Gas 价格	每单位 Gas 的实际价格，以 Gwei 表示且保留完整精度，旁边再以原生金额重述同一价格。它不做四舍五入，因为价格 × 已用 Gas 必须与手续费对得上。
Gas 上限与使用量	设定的上限、实际使用的 Gas，以及百分比。
销毁与验证者小费	这是对上面「交易手续费」的拆解，而不是额外收费：基础费部分被销毁，优先费部分支付给出块者，两者之和即为手续费。

两种小数精度，同一个美元#

同一个美元在链上有两副面孔，把它们弄混会带来十二个数量级的误差，这也是这条链上最常见的混淆。原生 USDC——金额、Gas、手续费——是 18 位小数。USDC 的 ERC-20 合约位于 0x3600000000000000000000000000000000000000，是 6 位小数。金额始终按该资产在载荷中声明的小数位数渲染，绝不会假定为 18，而 ⋮ 菜单里的单位换算器正是为此而存在。代币的转移见代币。

日志#

「日志」标签页把收据读了两遍。第一遍读成句子——哪些日志转移了价值、从谁到谁——因为这是大多数读者带着来的问题。第二遍读成事件本身：发出事件的合约、解码后的事件名与签名、被拆解为具名参数的索引主题，以及被拆成具名字段的数据段，而原始主题和数据字始终只差一个按钮。

解码是尽力而为，且绝不猜测。签名未知的事件会渲染成带编号的主题和带编号的数据字，而不是一个杜撰出来的名字。两种视图都出自同一份收据，因此它们必须一致；一旦不一致，页面会打印一条警告，而不是把一份简短摘要摆在更长的列表上方，任由你自行假定。

内部交易#

内部交易是一笔交易在自身内部发出的调用，而这里有两种很容易被混为一谈的不同产物。单笔交易的调用树是在你打开标签页时由 tracer 按需生成的，这在今天的主网上是可用的。而一个全链范围、可检索的内部交易索引是另一回事，它建立在 traces 数据流之上——而该数据流目前在两条链上都没有任何区块。

traces 索引今天在两条链上都是空的

实测于 2026年8月10日：无论主网还是测试网，traces 数据流报告的已索引区块数为零，也没有任何区间。因此全链范围的内部交易列表目前无法由索引作答，地址页面同样无法据此列出内部转移。这是 Arcscan 已索引内容中的一处缺口，而不是在宣称这些调用没有发生过。

在无法生成调用树的地方，页面会如实说明，而不是渲染一张空表格——因为空表格读起来就是「这笔交易没有做过任何内部调用」，而那是一句关于链的假话。算术让这个区分变得可靠：每一笔执行过的交易至少有一个调用帧，也就是顶层调用本身，所以零个调用帧只可能意味着追踪没有生成出来。只有一个调用帧才是真正的「空」。当 tracer 无法作答时，Arcscan 会退回到收据仍能证明的内容：Arc 上的原生资金净变动同样以日志形式发布，因此即使调用帧无法获得，交易内部转移的价值仍然可以还原。

自己获取一份收据#

rpc.arc-scan.io在新标签页中打开是面向 Arc 主网、链 5042（0x13b2）的公共只读 JSON-RPC 端点。它位于若干独立提供方之前并具备故障转移，回答常规的读取方法，因此你可以拿交易页面上的任何数字直接与链核对。

curl -s https://rpc.arc-scan.io \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,
       "method":"eth_getTransactionReceipt",
       "params":["0xYOUR_TX_HASH"]}'

收据的 status，对完成的交易是 0x1，对已回滚的交易是 0x0——与「状态」标记所呈现的是同一个事实。该主机名上没有测试网端点。方法列表和限制见公共 RPC，Arcscan 自有端点返回的数据形态见 REST API。区块讲解了交易所在的那个容器。