先区分两份合约里的支付方向
理解区块链原子交换，可以先把双方各自在不同链上提供的合约分开。Decred原始工具说明以Bitcoin和Decred为例，一方把资产付入第一份合约，另一方在另一条链建立第二份合约。双方希望领取的是对方提供的资产，不能把两笔存入动作合并成一笔已经完成的兑换。
这套工具还要求双方通过额外通信交换合约等资料。链上脚本并不会自动理解聊天里约定的金额和收款对象。阅读材料时，应保留每份合约所在网络、资金来源、预期领取人及退款一方，避免只看到共同哈希就认定双方承诺完全一致。
秘密原像与收款权限必须同时对应
BIP199描述的HTLC脚本有两条支出路径：指定一方通过披露哈希原像支出，另一方在超时条件满足后走退款路径。脚本还检查相应公钥哈希与签名，所以知道秘密原像，并不等于任何人都可以随意领取。这份BIP目前标记Closed，本文只引用历史脚本说明，不把它当作新近获准部署的标准。
Decred流程里，发起人先提供秘密的哈希，之后通过领取另一链资产的交易披露秘密，参与人再从该交易提取原像。若发起人在另一方尚未履行前提前披露，参与人可能已经具备领取第一份合约的条件。因此，资料中出现的秘密是此次交换使用的原像，不能误写成双方互交钱包私钥。
相同哈希不能替代合约核对
Decred的auditcontract说明要求核对领取地址、输出金额、锁定时间，并验证交易实际支付到了该合约；参与第二份合约时还要核对秘密哈希。设一份完全虚构的记录，双方约定甲领取乙提供的五个单位，哈希字段正确，但合约领取地址写成了丙。共同哈希仍然正确，收款条件却已不符合约定。
另一个区别是脚本内容与资金输出。拿到一段看起来满足条件的脚本，尚不能证明对应交易把约定数量付给了它。整理交换证据时，合约、支付它的交易和后续支出各有用途；只保留其中一张截图，会漏掉其他对象之间是否真正对应的问题。
两侧退款安排保留顺序与余量
在这份Decred工具示例中，发起人一侧等待更久，参与人一侧较早具备退款条件。这样安排，是为秘密在第二条链披露后，另一方仍有时间处理第一条链的领取。示例使用的具体小时数是该工具的设定，不是所有链、所有网络状态下都足够的通用参数。
BIP199也提醒，披露原像的支出可能尚未进入区块，却已让对方得知秘密。因此，超时附近不能只用消息发送顺序代替链上结果。本文核对的是原始流程中的条件关联，没有执行工具、发布合约或验证实际交换；是否完成应分别查看两链的有效支出记录，而不是从原子二字推断没有时序风险。