本文将详细解析该项目中涉及的交易状态 、争议状态 、仲裁提案状态以及DAO 提案状态，并提供相应的流转图及前端映射表。
一、DAO 提案状态流转
DAO 提案是社区治理的核心，其状态管理涵盖了从创建到执行或取消的全生命周期。
1. 状态定义与流转逻辑
| 状态码 | 状态名称 | 业务含义 | 流转条件 |
|---|---|---|---|
| 0 | 创建 (待开始) | 提案已创建，等待社区投票 | 初始状态 |
| 1 | 投票中 | 提案正在接受社区投票 | 首次有人投票时从 0 变为 1 |
| 2 | 投票通过 (等待加入公示期) | 投票时间到，赞成票不少于反对票，等待被手动加入公示期 | 后端定时任务检测到投票时间到且赞成 ≥ 反对 |
| 3 | 失败 | 投票时间到，赞成票少于反对票，提案终止 | 后端定时任务检测到投票时间到且赞成 < 反对 |
| 4 | 加入公示期 (公示期中) | 提案已通过投票，正在公示期，锁定等待执行 | 用户将状态 2 或投票时间已到但仍在状态 1 的提案加入公示期 |
| 5 | 执行 | 提案内容已在链上生效 | 公示期结束后，用户触发执行操作 |
| 6 | 取消 | 提案发起者主动撤销提案 | 发起者在 0 或 1 阶段取消提案 |
2. 流转图
3. 前端展示映射
| 状态码 | 前端显示文本 |
|---|---|
| 0 | 提案已创建，等待投票中 |
| 1 | 投票中 |
| 2 | 等待加入公示期 |
| 3 | 提案失败 |
| 4 | 公示期中 |
| 5 | 提案已执行 |
| 6 | 提案已取消 |
二、交易状态流转
交易状态涉及链下匹配、链上确认、交易执行、取消、争议处理及过期等多个环节。
1. 状态定义与流转逻辑
| 状态码 | 状态名称 | 业务含义 | 流转条件 |
|---|---|---|---|
| 链下初始化 | (链下过程) | 用户链下发起交易请求，匹配引擎匹配成功后，链下数据库创建交易记录（生成链下交易ID） | 初始链下状态 |
| 等待链上确认 | 等待链上确认 | 在链下初始化后，等待履约方调用链上创建交易对函数 | 链下状态，用于前端展示调用合约时的过渡 |
| 0 | 交易对创建 | 履约方调用链上创建交易对函数成功 | 履约方链上调用成功 |
| 1 | 率先转账方确认转账 | 率先转账方完成转账操作并确认 | 率先转账方确认 |
| 2 | 履约方确认转账 | 履约方完成转账操作并确认 | 履约方确认 |
| 3 | 交易完成 | 率先转账方最终确认收币（或系统自动确认） | 率先转账方最终确认 |
| 4 | 交易取消 | 交易双方任意一方取消交易 | 交易状态在 0, 1, 2 时，任一方取消 |
| 5 | 发起争议 | 交易双方任意一方发起争议 | 交易状态在 0, 1, 2 时，任一方发起争议 |
| 6 | 争议已解决 | 争议处理完毕，根据仲裁结果，交易最终状态为已解决 | 争议状态（D2, D3, D4）更新后，更新交易状态 |
| 7 | 交易过期 | 交易时间已超过，后端定时任务检测并处理 | 后端定时任务检测到交易过期 |
2. 流转图
3. 前端展示映射
| 状态码 | 前端显示文本 |
|---|---|
| (链下) | 交易已创建 (等待链上确认) |
| 0 | 交易已创建，等待率先转账方确认转账 |
| 1 | 等待履约方确认转账 |
| 2 | 等待率先转账方最终确认 |
| 3 | 交易已完成 |
| 4 | 交易已取消 |
| 5 | 交易存在争议 |
| 6 | 交易争议已解决 |
| 7 | 交易已过期 |
三、争议状态流转 (交易表中链下字段)
这个字段不存链上，是后端根据链上的仲裁提案情况同步的。
1. 状态定义与流转逻辑
| 状态码 | 状态名称 | 业务含义 | 流转条件 |
|---|---|---|---|
| 0 | 无争议 | 默认状态，交易正常进行中 | 初始状态 |
| 1 | 争议处理中 | 交易方已发起争议，等待仲裁委员会处理 | 交易状态从 0, 1, 2 变为 5 时，此状态变为 1 |
| 2 | 争议请求已执行 | 仲裁委员会投票通过争议请求 | 仲裁提案状态为 3 (执行) 时从 1 变为 2 |
| 3 | 争议请求已驳回 | 仲裁委员会投票驳回争议请求 | 仲裁提案状态为 2 (失败/驳回) 时从 1 变为 3 |
| 4 | 争议已过期 | 仲裁提案在有效期内未完成处理而过期 | 仲裁提案状态为 4 (过期) 时从 1 变为 4 |
2. 流转图
3. 前端展示映射
| 状态码 | 前端显示文本 |
|---|---|
| 0 | 无争议 |
| 1 | 争议处理中 |
| 2 | 争议请求已执行 |
| 3 | 争议请求已驳回 |
| 4 | 争议已过期 |
四、仲裁提案状态流转 (争议表中链上字段)
该字段记录在争议表中，代表了对某次争议的仲裁投票进程。
1. 状态定义与流转逻辑
| 状态码 | 状态名称 | 业务含义 | 流转条件 |
|---|---|---|---|
| 0 | 提案创建 | 仲裁委员会委员针对某个争议创建仲裁提案 | 委员创建仲裁提案。 |
| 1 | 投票中 | 仲裁委员对该提案进行投票 | 首次有人投票时从 0 变为 1。 |
| 2 | 失败 (驳回) | 投票结束时，赞成票未达到 2/3 | 投票结束后，赞成票 <= 2/3。 |
| 3 | 执行 (通过) | 投票结束时，赞成票大于 2/3 | 投票结束后，赞成票 > 2/3。 |
| 4 | 过期 | 提案在有效期内未完成投票而过期 | 投票时间到期且未完成投票 |
2. 流转图
3. 前端展示映射
| 状态码 | 前端显示文本 |
|---|---|
| 0 | 仲裁提案已创建，等待投票中 |
| 1 | 投票中 |
| 2 | 仲裁提案被驳回 |
| 3 | 仲裁提案已执行 |
| 4 | 仲裁提案已过期 |
五、总览与交互关系
所有这些状态机并非独立运行，而是通过事件和数据更新进行交换。
1. 交互关系图
2. 交互逻辑总结
- 交易发起争议 ：当交易状态变为 5 (发起争议) 时，立即将交易记录中的争议状态 字段更新为 1 (争议处理中)。
- 仲裁提案的创建与投票 ：在争议状态为 1 期间，仲裁委员会委员可以创建针对该争议的仲裁提案，其状态从 A0 (提案创建) -> A1 (投票中) 经历变化。
- 仲裁结果影响争议状态 ：当仲裁提案投票结束（无论是通过、驳回还是过期），其状态（A2, A3, A4）会更新交易记录表中的争议状态 字段，将其从 D1 (争议处理中) 更新为 D2 (已执行) 、D3 (已驳回) 或 D4 (已过期)。
- 争议解决影响交易状态 ：一旦交易记录中的争议状态 从 D1 更新为 D2, D3, 或 D4 中的任意一个，表示争议处理完毕，此时将主交易状态 从 T5 (发起争议) 更新为 T6 (争议已解决)。
总结
通过上述多维度的状态定义和流转机制，该项目能够清晰地追踪 DAO 提案和链下交易的每一个环节，尤其是在处理复杂的争议场景时，链上仲裁与链下业务状态的交互保证了系统的透明性和健壮性。前端通过这些明确的映射，可以为用户提供直观且实时的状态反馈。