上次给交易所充币，地址复制完我又检查了两遍memo，就怕币到了却认不出是我的。后来看 @Dusk_Foundation 的交易所集成文档，才发现Dusk对充值后台的要求比“填对备注”更细：先选Moonlight公开账户模型，再决定每人一个账户，还是共用账户加memo
如果采用共用账户，memo只负责告诉系统“这笔钱应该归给谁”，却不适合当作防重复入账的唯一凭证。两名用户可能填错相同memo，同一笔数据也可能因为后台重启被重新扫描。官方文档因此建议用Dusk交易ID做idempotency key，用大白话说，就是给每笔充值上一把“只能记一次”的锁。#dusk
还有一个容易被忽略的边界：交易所不该看到Moonlight余额增加就立刻给用户加账。它需要从已最终化的归档历史中扫描直接转账，并把memo缺失、格式错误、未知或重复的充值先放进隔离区，而不是想当然地自动入账。
更细的是，后台写入充值记录和推进区块检查点，要在同一个数据库事务里完成。先推进检查点再入账，服务崩溃后可能跳过用户的钱；先入账却没保存进度，重扫时又可能处理两次。Phoenix转换、合约付款和质押提现也要分别设置事件规则，不能混成普通充值。
这套逻辑很像快递仓库：memo是收件人标签，交易ID是不重复的快递单号，finalized则是包裹真正入库。只看其中一个，都可能造成丢件或重复派件。
所以我看 $DUSK 的交易所适配，不只看“能不能充提”，更看后台能否做到最终化后入账、交易ID去重、检查点和账本同步提交。真正金融级的体验，不是前台转圈圈很快，而是后台重启、重扫也不会多给或少给用户一分钱。#dusk
如果采用共用账户，memo只负责告诉系统“这笔钱应该归给谁”，却不适合当作防重复入账的唯一凭证。两名用户可能填错相同memo，同一笔数据也可能因为后台重启被重新扫描。官方文档因此建议用Dusk交易ID做idempotency key，用大白话说，就是给每笔充值上一把“只能记一次”的锁。#dusk
还有一个容易被忽略的边界：交易所不该看到Moonlight余额增加就立刻给用户加账。它需要从已最终化的归档历史中扫描直接转账，并把memo缺失、格式错误、未知或重复的充值先放进隔离区，而不是想当然地自动入账。
更细的是，后台写入充值记录和推进区块检查点，要在同一个数据库事务里完成。先推进检查点再入账，服务崩溃后可能跳过用户的钱；先入账却没保存进度，重扫时又可能处理两次。Phoenix转换、合约付款和质押提现也要分别设置事件规则，不能混成普通充值。
这套逻辑很像快递仓库：memo是收件人标签，交易ID是不重复的快递单号，finalized则是包裹真正入库。只看其中一个，都可能造成丢件或重复派件。
所以我看 $DUSK 的交易所适配，不只看“能不能充提”，更看后台能否做到最终化后入账、交易ID去重、检查点和账本同步提交。真正金融级的体验，不是前台转圈圈很快，而是后台重启、重扫也不会多给或少给用户一分钱。#dusk