要点速览
加密货币确认策略决定一笔链上付款何时可以入账。Paymos 读两个输入： 付款人选的网络，和账单的美元金额。每条网络在每个金额档上有自己的 确认深度，所以同一条链上，小额账单比大额更早结清。这些深度是配置， 可以连同所属金额档一起引用。深度换算出来的分钟数属于链，商户代码 该读的是账单状态，不是一个常量。
抄进商户代码的确认深度，会在配置或网络变化的那一天开始对不上。 履约应跟随已确认的账单状态。
加密货币确认策略决定一笔付款何时可以入账。Paymos 读两个输入：付款人选定的网络，和这张账单的美元金额。每条网络在每个金额档上有自己的确认深度，所以同一条链上，小额账单比大额更早结清。这些深度是配置，不是估算，所以本文可以把它们直接写出来。它们不是时钟：一个确认数背后的分钟数由链的出块节奏决定，集成方要按已确认的账单状态放单，而不是按计时器。
确认策略决定什么？
确认策略把一个原始链上事件变成付款结果。在多数网络上，这意味着数付款所在区块之上又堆了多少块；在会给出显式终局性信号的网络上，策略改读那个信号。两种情况下商户看到的都是同一样东西——账单状态——用不着自己跑这套判断。
这套策略存在的原因是：刚观察到的链上事件不等于已经结清的付款。重组（reorg，链重组）可以替换最近的区块，所以钱包上显示的那一个确认，证明的是「进块了」，不是「不会变了」。深度买的是概率；协议给出的终局性信号，按该协议自己的规则买到的是更强的保证。集成的边界就落在已确认的账单状态上，而不是客服正好打开的那个区块浏览器页面。
为什么安全等待时长取决于金额？
金额就是最近一个区块被替换时暴露出去的那份价值。安全性是网络的属性，损失大小是账单的属性。忽略后者的策略只能给两者挑一个等待，而两个答案都不对：深到够扛一笔五位数转账，20 美元的订单就要干等；快到配得上 20 美元的订单，五位数那笔的风险就被算便宜了。
按账单的美元金额分档解决了这件事。门槛是 100、1000 和 10000 美元，每一档适用到本档门槛为止（含）。各网络在这些档里的确认数不同，有些网络用的档比别人少——因为一个区块在每条链上不是同一件事。
分档确认策略实际长什么样？
以下就是分档真正在起作用的那几条网络的完整规则。Ethereum 账单在 100 美元及以下等 2 个确认，到 1000 美元是 6 个，到 10000 美元是 12 个，再往上 32 个。Tron 从 2 个起步，然后是 6 个，1000 美元以上封顶在 19 个——27 位超级代表里已有 19 位固化该区块的那个点。Base 和 Optimism 在同一组门槛上走 5 / 15 / 30 / 100。Arbitrum 走 40 / 120 / 240 / 800，乍看夸张，把亚秒级出块算进去就对上了：它的四个时间跨度和 Base 落在同一处。
有几条链完全不需要分档。BSC 和 Polygon 按自己的终局性信号结清。Solana 在 finalized 承诺上扫描，发现即确认。TON 只要一个区块，因为它的每个主链区块到达时就是最终的。
单独引用其中一个数字，正是这条规则被说错的方式。「Tron 在 19 个确认后达到终局」在 1000 美元以上准确，在这条线以下就是错的。要么把金额档跟着数字一起带上，要么把整行都给出来。确认机制说明讲了为什么同样的原始区块数在每条网络上不代表同等安全。
一档折合成实际时长是多久？
一个确认数要变成时长，得经过网络当前的出块速率。Ethereum 最浅的一档在正常节奏下约 24 秒，最深的一档六分钟出头；Tron 最浅的一档在 6 秒上下。这些数字每一个都请当约数读。
网络拥堵时出块变慢，这套算术也跟着漂。这就是这项策略两半之间的分界线：确认数是设置，时长是预报。把预报写成承诺的收银台文案、客服话术或合同条款，会在第一个忙碌的下午就被打脸。
协议终局性怎么影响确认策略？
权益证明网络可以直接给出终局性，而不是让人从深度里推。Ethereum 用 Casper FFG 检查点组织这件事，按 epoch 而不是逐块把历史定下来。Paymos 在 Ethereum 上仍然数区块——按档从 2 个到 32 个——所以金额仍是决策的一部分。
链的终局性来得又快又无条件时，分档就整个消失了：上面列的那四条网络之所以只有单档，就是这个原因。共识在那里直接回答了深度只能给出概率的问题。模型不同，商户面前的结果只有一个：账单状态。
为什么策略必须跟随网络的当前行为？
网络会改变自己出块的速度和确定程度。BSC 的 Fermi 升级缩短了出块时间，Polygon 的 Heimdall v2 缩短了到达终局的路径。 这两件事都在不动确认数的前提下，改变了一个确认数在实际时长上的含义。
这正是反对把数字冻进商户代码的理由。链一变，深度配置这边我们自己调；而商户仓库里的常量，要等有人想起来开一个 PR 才会变。上面那些档位是 Paymos 维护的设置的一张快照，不是协议里的条款。
什么时候硬编码确认数才是对的？
很少，而且永远不能拿它顶替账单状态。读这张表去理解等待多久，是它的正当用法；围着「12 个确认」写一个 if，不是——那个常量漏掉了付款人选的网络、账单落进的金额档，以及这两者的下一次变化。
集成要做的事更窄，也比上面这一切都活得久：持久化 Paymos 账单编号、验证状态更新上的签名、让履约幂等。订单不该因为计时器到期、钱包显示了一个区块、或者上一笔付款在另一条链上很快就通过而发出去。这些观察对客服排查有用，替代不了眼前这张账单的已确认结果。
Paymos 怎么套用这套策略？
Paymos 把网络和金额放在一起评估，然后返回结果。小额付款在更少的确认上结清，大额付款等更强的门槛，实际耗时跟着链那一刻的状态走。这些确认数只在 Paymos 动它们的时候才动——这恰恰是它们和网络费的区别：网络费的价由链来定，本站任何一页都不会把它写成一个固定金额。
| 维度 | 固定确认数 | 分档策略 | |
|---|---|---|---|
| 小额付款体验 | 一个抄来的常量决定等多久 | 走该网络最浅的那一档 | |
| 大额转账安全 | 各金额一视同仁 | 账单金额越高，档位越深 | |
| 风险模型 | 所有金额等同样长 | 等待随风险敞口缩放 | |
| 在有终局性信号的链上 | 商户自己解读网络 | 不分档，由链的信号决定 | |
| 调参位置 | 商户维护的常量 | Paymos 的配置，无需重新部署 |
常见问题
什么是加密货币确认策略？
确认策略是支付网关用来决定一笔链上付款何时可以入账的规则。Paymos 读付款人选定的网络和账单的美元金额，然后套用这一对组合上配置好的深度。商户集成应对最终返回的账单状态作出反应。
为什么确认数要随付款金额变化？
金额就是最近一个区块被替换时暴露出去的价值。同一条链上，40 美元的账单和 40000 美元的账单敞口不同，等的深度自然也不同。用一个等待覆盖两者，要么让小额白等，要么把大额的风险算便宜了。
商户可以引用 Paymos 的确认数吗？
可以，只要金额档跟着这个数一起走。「Tron 在 19 个确认后达到终局」在 1000 美元以上成立，在这条线以下就是错的。另有两条限制：这些深度是 Paymos 可以调整的配置，由它换算出来的分钟数是近似值，不是结算保证。
一笔大额稳定币付款需要多少个确认？
看网络。10000 美元以上，Ethereum 账单等 32 个确认，Base 账单等 100 个——数字差得远，落地时长却接近，因为 Base 的出块间隔短得多。Tron 最深的一档是 19，适用于 1000 美元以上。原生终局性快的链根本不分档。
商户该自己实现一个固定确认数吗？
不该。深度属于 Paymos 的配置，配置一动它就跟着动；而商户代码里的常量会一直保持旧值，直到有人重新部署。读账单状态得到的是同一个答案，并且在配置变化之后依然正确。
按区块数确认和按终局性确认有什么区别？
区块深度数的是付款所在区块之上又堆了多少块；终局性是共识协议按自己的规则给出的更强信号。链上拿不出更强信号时，Paymos 数深度；链上拿得出，就用链自己的终局性。两条路，商户读到的都是同一个账单状态。
什么时候不该用硬编码的确认数
- 如果合同需要有保证的结算时长，确认深度给不了。数字是定的，走完 它要多少分钟归链管，拥堵一来就拉长。
- 如果商户代码必须照抄这张深度表，应重新考虑设计：配置可能在商户 不重新部署的情况下变化，而账单状态本来就带着结果。
- 如果履约流程无法响应账单状态变化，先补上可靠的状态处理，再谈自动 交付。
- 如果某个流程在确认结果之前就需要确定性，应使用独立的业务控制， 而不是照着区块浏览器上看到的画面放单。
参考来源
- 1. Bitcoin whitepaper: A Peer-to-Peer Electronic Cash System (Satoshi Nakamoto, 2008) — confirmation-depth probability model (accessed 2026-06-01)
- 2. Casper the Friendly Finality Gadget (Buterin, Griffith, 2017) — epoch finality under proof-of-stake (accessed 2026-06-01)
- 3. Ethereum consensus mechanisms: proof-of-stake finality and epochs (Ethereum Foundation) (accessed 2026-06-01)
- 4. TRON super-representatives and block solidification (TRON DAO documentation) (accessed 2026-06-01)
- 5. BNB Chain Fermi upgrade — fast finality announcement (accessed 2026-06-01)
最近复核：2026年8月21日
