链上救灾

Relief MON 是一个基于 Monad 区块链原生代币 MON 的救灾资金与物资协同调度平台。用户直接捐赠 MON，平台用链上资金池采购应急物资、签订人力与救援服务合同，从捐赠到采购、交付、验收、付款全链路在链上可追溯。二、业务规则1. 全 MON 流程：用户直接捐 MON2. 平台采购：用户捐 MON，平台统一采购物资、签订人力与救援服务3. 用途限定：捐赠时选择类型 / 限定灾情项目，自动分配不得越界4. 钱包前置：注册并绑定钱包后才允许正式捐赠5. 算法推荐 + 人工审批：系统评分只做推荐，中选由人工审批决定6. 合同双签：平台与供方钱包签署同一版本合同（EIP-712 类型化数据签名）7. 三权分立：供方、验收方、财务方账号分离，验收后财务钱包才能付款8. 分批验收：按实际验收量支付，不提前支付合同全额9. 争议隔离：只冻结争议批次，独立复核人复核，无争议批次继续办理10. 结余退回：任务结余清理合同义务后回原捐赠，保留用途，可退款或重新授权11. Gas 资金池承担：业务 Gas 由资金池承担，用户先垫付、确认后自动报销12. FIFO 资金使用：多人共同出资按捐款入池先后顺序使用，逐批实际支付归属13. 版本化合同：价格 / 数量 / 收款人 / 交付标准变更需新版本与重签14. 链上隐私：仅上链业务 ID、哈希、机构和时间，身份证 / 银行卡 / 合同原文链下保存三、业务架构relief-token-miniprogram/├── web/ 前端页面│ ├── mobile/ 移动端：捐赠者、公众、供应方│ ├── admin/ 管理端：审核、财务、合规、审计│ ├── operations/ 岗位工作台：报价、采购、合同、履约│ └── shared/ 三端共用的 API、合约 ABI、图片和第三方库│├── backend/ Node.js 后端│ ├── server.js 服务启动入口、HTTP 路由、静态页面服务│ ├── *-service.js 业务服务│ ├── *-domain.js 领域规则、状态计算│ ├── *-store.js JSON/SQLite 数据存储│ ├── data/ 本地业务数据和钱包数据│ ├── test/ 后端及浏览器自动化测试│ └── scripts/ Solidity 合约编译脚本│├── contracts/ Solidity 智能合约│ ├── ReliefPool.sol│ └── ReliefDonationLedger.sol│├── docs/ 架构、接口、数据库、权限及验收文档├── .repair-backups/ 各阶段修复前的代码备份├── start.ps1 Windows 一键启动脚本├── sitemap.json└── README.md 项目总说明四、双层网络与追踪平台采用公开链 + 私有层双层设计：• 公开层（Monad L1）：所有 MON 资产动作必须上链 —— 捐赠存入、预算分配、合同托管、交付验收凭证哈希、兑换锁定、付款回执、MON 结算、最终水印完成• 私有层（后端账本）：供应商 KYB、联系方式、完整竞价方案、合同原文、运输单、发票、验收原件水印血缘链（每笔捐赠从入池到终结的完整追踪）：Plain TextDONATION-001（根水印）  → TASK-001（分配水印）  → CONTRACT-001（托管水印）  → DELIVERY-001（验收水印）  → REDEMPTION-001（付款水印）  → FINISHED（终态）每次拆分生成子 lot，MON 留在托管合约内时资金血缘可验证。捐赠者可按资金 ID 查询从捐赠到最终物资采购的完整链路。完整业务流程阶段一：捐赠入池Plain Text用户注册 → 绑定钱包（EIP-712 签名挑战验证）  → 选择捐赠类型/限定灾情项目  → 签署 DonationPermit（含金额、Gas预留、用途、nonce、截止时间）  → 调用合约 donate，MON 转入资金池  → 合约校验：注册签发方授权、nonce 未使用、金额匹配、用途合法  → 生成 DonationReceived 事件，建立 donation lot 根水印  → 自动按 FIFO + 优先级分配到活跃任务关键约束：未注册绑定钱包不能捐赠；每笔捐赠预留 Gas 费用；用途 / 项目限制在后续分配时全程生效；任务结余退回原捐赠可用余额。阶段二：灾情任务Plain Text上报员提交灾情（位置/等级/需求/证据）  → 官方核验员核验（驳回/临时批准/正式批准）  → 生命救援允许临时批准，但必须生成事后复核待办  → 任务进入活跃队列，合约 registerTask() 登记  → 资金池按 FIFO 自动分配匹配用途的捐赠资金任务状态：REPORTED → VERIFYING → APPROVED → DISPATCHING → EXECUTING → COMPLETED阶段三：供方准入与报价Plain Text供应商/救援队通过链上准入管理 → 直接入驻（跳过正式入驻环节）  → 管理员签发绑定邮箱和机构的单次岗位邀请  → 用户在移动账户页绑定钱包并领取岗位  → 供方在岗位工作台提交报价（物资单价、可供量、到达时长、有效期）  → 报价写入 SQLite，每 5 秒刷新公众商城展示  → 报价过期/零库存/供方撤权后自动下架阶段四：竞价与合同签署Plain Text调度员查看认证资源池 → 系统计算推荐分（价格/时效/距离/资质）  → 调度员提出候选方案（SHORTLISTED）  → 采购审批员确认中选（AWARDED），填写理由  → 创建合同草案（DRAFT），锁定报价预留库存  → 合同条款生成 EIP-712 类型化数据（含合同ID、版本、数量、单价、双方钱包、验收标准哈希、nonce、截止时间）  → 平台钱包签名 → 供方钱包签名（必须同一版本）  → 双方签名完成 → 合同状态 FUNDS_RESERVABLE  → 链上创建托管 Escrow，MON 冻结 → 记录 EscrowCreated 事件  → 合同状态 FUNDS_RESERVED，进入履约核心规则：各环节只能通过智能合约签署推进；合同版本化，变更需重签；未完成双方签名不能创建托管；管理员不能以管理令牌代替业务岗位签约。阶段五：分批交付与验收Plain Text供方创建交付批次（DELIVERED），上传 1-6 件原始附件（PNG/JPEG/PDF）  → 独立验收员验收（不能是供方、买方或财务人员）  → 验收结果：ACCEPTED / PARTIAL（部分）/ REJECTED / DISPUTED（争议）  → 争议批次：管理员分派独立复核人（排除所有历史参与人）  → 复核人提交独立原件与结论 → 按复核通过量形成应付  → 无争议批次继续办理，不被争议批次阻塞阶段六：付款与结算Plain Text按实际验收数量 × 合同单价 = 本批应付金额（derivePayable）  → 财务人员发起付款（不能是验收员或供方）  → 链上 Escrow 释放 MON 到供方钱包  → 记录 EscrowReleased + PayoutRecorded 事件  → 合同状态 PARTIALLY_SETTLED → SETTLED  → 任务结余清理后回原捐赠可用余额  → 已验收且已链上支付的批次生成版本化 PDF 凭证（含二维码、累计贡献、SHA-256）阶段七：链上追踪与审计Plain Text每一步操作生成链上交易哈希 + 凭证哈希  → Indexer 从 Monad 重建 donation lot 父子血缘  → 捐赠者按资金 ID 查询完整链路  → 监管机构实时审计：资金流向、竞价过程、合同执行、付款记录  → 每日对账：MON 存入总额 = 可用+托管+结算+退款余额之和 = 可追踪资金流