Chainfeeds 导读：
如果传统支付的 UX 与加密的自托管能够结合，那么加密支付才可能真正成功。
文章来源：
https://x.com/paramonoww/status/2031428418672251148
文章作者：
Pavel Paramonov
观点：
Pavel Paramonov ：在加密支付场景中，每笔交易本质上都是一次充值，用户给别人转账是给对方账户充值，支付给商家也是对商家账户的充值。但不同类型的充值信任假设和用户体验完全不同：CEX、加密钱包、加密卡或加密支付服务，各自的结算机制和体验差异巨大。加密卡之所以能实现近即时支付体验，是因为在消费环节实际上并没有用加密货币，而是用法币透支支付，POS 系统通过 Visa、Mastercard 或 Amex 网络结算，商家无需等待链上确认。然而，加密卡的结算问题存在于充值阶段：从用户发送资产到资产可支配，需要经历多次链上转账确认与应用显示，造成一定延迟。相比之下，真正的链上支付最终目标是实现买家和商家之间的原生加密交易，但受限于链上结算时间和最终性差异，交易无法即时完成，这也是加密支付体验仍不完善的根本原因。大多数 L1 区块链都存在两种最终性：乐观最终性和经济最终性。乐观最终性意味着交易在钱包显示已确认，但仍有被回滚的风险；经济最终性则表示交易不可逆，真正完成。两者之间的时间差可能导致链重组（reorg），即区块链丢弃部分区块并采用新的历史，从而使依赖前一笔交易的后续交易失效。举例来说，如果 Alice 给你转 1 ETH，你再立即给 Bob 转 0.5 ETH，而 Alice 的交易被 reorg 撤销，则 Bob 的交易无效，最终受害者是 Bob 和你，而 Alice（恶意用户）成为唯一赢家。这也是为什么交易所要求多次确认才能让用户交易可用，而零售支付场景无法等待多个区块确认，必须寻找新的结算解决方案，以避免用户和商家承担链上风险。目前加密支付模型主要有两类：加密卡和钱包支付。加密卡通过现有支付网络吸收所有风险，用户体验友好，但仍受传统金融限制，无法真正实现自托管支付。钱包支付允许用户直接从钱包付款，完全无许可且透明，但商家承担结算风险，同时 UX 复杂，需要扫描二维码、选择代币和网络等操作。像 WalletConnect 的 PoS 集成尝试仍存在操作复杂的问题。创新方案如 Flexa 则采用抵押资产（AMP 代币）担保模式：商家收到即时授权，链上交易在后台确认，若交易失败，抵押资产赔付商家。这种模式将商家结算与链上最终性分离，使支付体验接近即时，同时允许多链支付而不增加商家复杂度。结合传统支付 UX 与加密自托管的优势，未来加密支付可以实现更大规模落地。
内容来源
