v4.0: Final 4 refinements for complete coverage
- Merchant POS integration: scan/input/online redemption, offline capability, multi-store management (3.10.4) - Issuer-configurable rules: transferability, resale limits, audience targeting, per-person limits, store restrictions (3.1.3) - On-chain refund logic: atomic reverse swap, refund windows, non-refundable states, abuse prevention (3.4.2) - KPI system expanded to 4 categories / 25 metrics: business, UX, security/compliance, infrastructure (8.1-8.4) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
parent
7a247c3a62
commit
967d7d62c9
|
|
@ -242,6 +242,26 @@ Genex = **券交易领域的区块链基础设施平台先行者**
|
|||
- [ ] 发行审批流程
|
||||
- [ ] 发行上架管理
|
||||
|
||||
**发行方可配置规则（链上合约级别执行）：**
|
||||
|
||||
> 发行方在创建券时可自定义以下规则，规则写入链上合约，发行后不可更改。
|
||||
|
||||
| 规则 | 默认值 | 可选范围 | 说明 |
|
||||
|------|--------|---------|------|
|
||||
| **可转让性** | 允许P2P转移 | 允许 / 禁止 / 限定条件 | 政府福利券可设为"不可转让" |
|
||||
| **转售次数** | Utility Track默认2-3次 | 0-10次（0=不可转售） | 0次=仅限一级市场购买，不可二级市场交易 |
|
||||
| **使用人群限定** | 无限定 | 全部用户 / 指定KYC属性 | 如学生券（KYC验证学生身份）、企业员工券 |
|
||||
| **单人限购** | 无限制 | 1-N张 | 防止囤货炒作，如每人限购5张 |
|
||||
| **使用门店限定** | 全部门店 | 全部 / 指定门店列表 | 连锁企业可限定券在特定门店使用 |
|
||||
| **叠加使用** | 不可叠加 | 可叠加 / 不可叠加 | 是否允许同一笔消费使用多张券 |
|
||||
| **最低消费** | 无 | 0-N金额 | 满X元可用（满减券场景） |
|
||||
|
||||
- [ ] 发行方在创建券模板时通过勾选/填写设定规则（Web2界面，无需了解合约参数）
|
||||
- [ ] 规则在CouponFactory铸造时写入链上元数据，合约级别强制执行
|
||||
- [ ] "不可转让"券：Coupon合约的transfer函数对该券返回revert
|
||||
- [ ] "限定门店"券：Redemption合约验证核销门店ID是否在允许列表中
|
||||
- [ ] 平台审核时检查规则合理性（如：不允许设置歧视性人群限定）
|
||||
|
||||
#### 3.1.4 券的类型支持（白皮书分类）
|
||||
| 类型 | 描述 | 金融属性 |
|
||||
|------|------|----------|
|
||||
|
|
@ -378,9 +398,26 @@ P = F × (1 - dt) × (1 - rc)
|
|||
#### 3.4.2 清算规则
|
||||
- [ ] 交易手续费计算（平台收益）
|
||||
- [ ] 买卖双方资金划转
|
||||
- [ ] 退款机制
|
||||
- [ ] Breakage收益计算与分配
|
||||
|
||||
**退款机制（链上资产退款逻辑）：**
|
||||
|
||||
> 券是链上资产，售出后所有权已转移。退款 = 链上反向操作，比传统退款更复杂。
|
||||
|
||||
| 场景 | 退款流程 | 技术实现 | 时效 |
|
||||
|------|---------|---------|------|
|
||||
| **一级市场退款**（消费者→发行方） | 消费者发起退款申请 → 平台审核 → 券从买方退回发行方（链上转移）→ 资金从发行方退回买方 | Settlement合约反向原子交换（券↔资金同时退回） | 审核通过后即时链上执行 |
|
||||
| **二级市场退款**（买方→卖方） | 买方发起申诉 → 平台仲裁 → 券从买方退回卖方 → 资金从卖方退回买方 | Settlement合约反向原子交换 | 仲裁裁决后执行 |
|
||||
| **已核销券** | **不可退款** | Redemption合约已销毁券，不可逆 | — |
|
||||
| **已过期券** | **不可退款**（Breakage已计入发行方收益） | 券状态为Expired，不可操作 | — |
|
||||
| **已转赠/已转售券** | 仅退当前持有人的购入价，不追溯前手 | 退款对象 = 当前持有人 | — |
|
||||
|
||||
- [ ] **一级市场退款窗口**：发行方可设定退款期限（如购买后7天内可退），过期不可退
|
||||
- [ ] **退款原子性**：退款通过Settlement合约执行反向原子交换，券和资金同时退回，不存在"退了钱但券没退回"的风险
|
||||
- [ ] **手续费退还规则**：一级市场退款全额退还（含手续费）；二级市场退款仅退交易金额（手续费不退）
|
||||
- [ ] **退款上链记录**：每笔退款在链上记录（退款交易哈希），作为审计和争议处理的不可篡改证据
|
||||
- [ ] **防滥用**：单用户退款率超阈值触发风控审查（防止恶意"买了用了再退"的欺诈）
|
||||
|
||||
#### 3.4.3 兑付清算（合约直接结算，平台不介入）
|
||||
> 消费者使用券时，通过智能合约直接与发行方完成结算/清算/销毁，**平台不接触消费数据，不介入消费环节**
|
||||
- [ ] 合约清算：消费者调用合约兑付，券自动销毁
|
||||
|
|
@ -677,6 +714,37 @@ P = F × (1 - dt) × (1 - rc)
|
|||
- [ ] **批量操作**：批量发行、批量核销、批量导出数据
|
||||
- [ ] **消费者数据隔离**：发行方后台仅可见自己发行的券的汇总数据（兑付率、销量），不可见消费者个人信息（合约清算保护）
|
||||
|
||||
#### 3.10.4 商户端核销集成
|
||||
|
||||
> **发行方（企业总部）发行券，但核销发生在线下门店。门店收银员需要简单、可靠的核销工具，且必须支持网络不稳定场景。**
|
||||
|
||||
**核销方式（三种并行）：**
|
||||
|
||||
| 方式 | 场景 | 说明 |
|
||||
|------|------|------|
|
||||
| **扫码核销**（推荐） | 门店收银员用手机/平板扫消费者出示的券码 | 最常用，调用Redemption合约 |
|
||||
| **输码核销** | 消费者报出券码，收银员手动输入 | 扫码设备故障时的备选 |
|
||||
| **在线核销** | 线上商城/小程序内消费 | 用户点击"使用"，前端调用合约 |
|
||||
|
||||
**商户端工具：**
|
||||
- [ ] **商户核销App**（iOS/Android）：门店收银员专用，扫码即核销，操作≤3秒
|
||||
- [ ] **Web端核销后台**：门店管理员通过浏览器核销+查看核销记录
|
||||
- [ ] **POS SDK集成**：为已有POS系统的连锁企业提供SDK，嵌入现有收银流程
|
||||
- [ ] **核销API**：第三方系统（如企业自有App）调用API完成核销
|
||||
|
||||
**离线核销能力（关键）：**
|
||||
> 门店网络不稳定时（地下商场、偏远地区），核销不能中断。
|
||||
- [ ] **离线缓存核销**：App本地缓存已发行券的验证数据（券ID+状态+有效期），断网时可本地验证并暂存核销记录
|
||||
- [ ] **联网后同步**：网络恢复后自动将离线核销记录上链（调用Redemption合约）
|
||||
- [ ] **离线风控**：离线核销设单笔/单日限额（防止离线期间被重复核销），超限需联网验证
|
||||
- [ ] **冲突处理**：如离线期间同一张券被两个门店核销，以先上链者为准，后者自动退回并通知
|
||||
|
||||
**多门店管理：**
|
||||
- [ ] 连锁企业可设置门店层级：总部→区域→门店
|
||||
- [ ] 各门店独立核销权限（某些券限定指定门店使用）
|
||||
- [ ] 门店级核销数据汇总至总部仪表盘
|
||||
- [ ] 门店员工账号管理（收银员仅有核销权限，店长有数据查看权限）
|
||||
|
||||
---
|
||||
|
||||
## 4. 技术需求
|
||||
|
|
@ -1224,14 +1292,47 @@ P = F × (1 - dt) × (1 - rc)
|
|||
|
||||
## 8. 关键指标（KPI）
|
||||
|
||||
### 8.1 核心业务指标
|
||||
|
||||
| 指标 | 描述 | 目标值 |
|
||||
|------|------|--------|
|
||||
| 交易成功率 | 成功完成/发起交易 | > 95% |
|
||||
| 发行方兑付率 | 已兑付/已售出券 | > 85% |
|
||||
| 链上确认时间 | 从交易发起到链上确认 | < 30秒 |
|
||||
| 链上确认时间 | 从交易发起到链上确认 | < 1秒（CometBFT即时终结） |
|
||||
| 用户投诉率 | 投诉订单/总订单 | < 1% |
|
||||
| 平台折价率 | 平均成交价/面值 | 80-90% |
|
||||
| 发行方留存率 | 持续发行方比例 | > 70% |
|
||||
| 退款率 | 退款订单/总订单 | < 3% |
|
||||
| 核销成功率 | 核销成功/核销发起（含离线） | > 99.5% |
|
||||
|
||||
### 8.2 UX与用户体验指标
|
||||
|
||||
| 指标 | 描述 | 目标值 |
|
||||
|------|------|--------|
|
||||
| 标准模式占比 | 标准模式用户/总用户 | > 95% |
|
||||
| 注册→首次购买转化率 | 注册后完成首笔交易的用户比例 | > 30% |
|
||||
| 翻译层API延迟 | UX翻译层额外耗时 | < 50ms |
|
||||
| 用户零区块链感知率 | 调研中"不知道平台用了区块链"的用户比例 | > 90% |
|
||||
|
||||
### 8.3 安全与合规指标
|
||||
|
||||
| 指标 | 描述 | 目标值 |
|
||||
|------|------|--------|
|
||||
| 映射表完整性 | 链上锚定哈希校验通过率 | 100% |
|
||||
| OFAC筛查覆盖率 | 通过OFAC筛查的交易/全部交易 | 100% |
|
||||
| P0事件响应时间 | 检测到→启动应急 | < 15分钟 |
|
||||
| 合约升级成功率 | 升级成功/升级发起 | 100% |
|
||||
| SAR提交及时率 | 可疑交易报告按时提交比例 | 100% |
|
||||
|
||||
### 8.4 技术基础设施指标
|
||||
|
||||
| 指标 | 描述 | 目标值 |
|
||||
|------|------|--------|
|
||||
| 系统可用性 | 平台整体正常运行时间 | > 99.9%（SLA） |
|
||||
| Genex Chain TPS | 链上每秒处理交易数 | ≥ 5000 |
|
||||
| Genex Chain出块时间 | 区块生成间隔 | ≤ 1秒 |
|
||||
| DR切换时间 | 灾难发生→备用系统接管 | < 15分钟（RTO） |
|
||||
| 数据恢复点 | 数据丢失窗口 | < 1分钟（RPO） |
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -1266,7 +1367,7 @@ P = F × (1 - dt) × (1 - rc)
|
|||
|
||||
---
|
||||
|
||||
*文档版本: v3.9*
|
||||
*文档版本: v4.0*
|
||||
*生成日期: 2026-02-09*
|
||||
*来源: 券的金融本质与短期资金募集机制白皮书 (draft v0.1)*
|
||||
*更新: GNX代币合规分析（1.7），智能合约升级策略（4.3.6），安全事件响应（4.4.2），隐私删除权方案（3.7.3），第三方依赖备选（4.7），发行方B端UX（3.10.3）*
|
||||
*更新: 商户端核销集成与离线能力（3.10.4），发行方可配置规则（3.1.3），链上退款逻辑（3.4.2），KPI体系扩展为4类25项指标（8.1-8.4）*
|
||||
|
|
|
|||
Binary file not shown.
Loading…
Reference in New Issue