TokenRail.

需要解决的问题

券与款分别转移时，第一笔成功、第二笔失败会留下需要补偿的中间状态。TokenRail 用合成数据搭建可编程结算实验平台，研究同链原子交割，并继续处理链交易提交、链下持仓同步和对账中的失败。它是项目实验，不承载真实资金。

方案与架构

合约层包含 IdentityRegistry、DepositToken、BondToken、DvPSettlement 和 PaymentEscrow。卖方创建固定条款，买方确认后指令进入 READY；双方分别授权代币额度，结算提交员执行同一笔 EVM 交易中的两条资产转移。

演示工作台 → Java API / 交易编排
                    ↓
              四节点 Besu QBFT
                    ↓
          身份 / 存款 / 债券 / DvP / Escrow
                    ↓
           Transfer 事件 → 持仓投影
                    ↓
              固定区块水位对账

Java 服务在广播前持久化请求、nonce 和签名交易哈希，结合幂等键与 receipt 查询恢复不确定的提交结果。Transfer 事件是代币持仓的增减来源；投影按完整区块提交，对账在同一区块高度比较链上状态与链下快照。

演示与验证

本地 M7 验收从已提交代码的干净归档重建环境。记录包括 51 个合约测试、四节点 QBFT 故障恢复、8 个链与数据库回归、8 个独立可靠性测试、2 个全栈场景，以及条件支付、原子 DvP、冻结拒绝与解冻重试三类演示。这些是固定环境中的正确性证据。

原子性实验专门让第二条转移失败，核对失败 receipt、四个代币余额、授权额度和指令状态，避免仅以执行前的余额检查代替回滚验证。四个验证节点都运行在本机，验证协议行为，不代表独立故障域下的生产部署。

取舍与技术栈

首版限定单链、一个模拟存款发行方和一种模拟债券。READY 记录交易意图，不锁定资产，因此执行时重新检查余额、授权、资格和期限。Java 应用采用模块化单体；工作台用原生 HTML、CSS、JavaScript，由 Spring Boot 托管。

技术栈包括 Solidity、OpenZeppelin、Foundry、Anvil、Java 21、Spring Boot、Web3j、Hyperledger Besu 和 PostgreSQL。学习重点是区分链上业务状态、每次提交尝试和投影同步状态：RPC 超时不能直接解释为交割失败，数据库事务也不能撤销已确认的链交易。

查看项目

合约、Java 服务、部署模板与验收文档已同步到公开 GitHub 仓库。M7 验收说明记录固定环境中的检查范围；原子交割的设计也整理在本站的工程笔记中。

下面是实验平台的验收演示录像，使用模拟资产与合成数据。