0滑点补贴核算后台

IMPORTANT

战略定位：此功能的核心不在于"展示"，而在于**"风控与核算"**。0滑点补贴是平台真金白银的支出，后台必须能清晰回答"钱去哪了"以及"是否存在薅羊毛行为"。

1. 背景与目标

"0滑点跟单"是 BitMart 的差异化核心功能，由平台补贴跟单滑点价差。 运营管理端需要对这笔支出进行精细化管理，核心目标包括：

1. 成本监控：实时监控每日补贴水位。
2. 异常侦测：快速识别利用 0 滑点机制进行刷单或对敲的异常账户。
3. 客诉处理：当用户质疑补贴金额时，能调出详细的订单级计算过程作为证据。

---

原型设计

设计稿文件：[admin-zero-slippage.pen](file:///Users/wangshufu/Library/Mobile%20Documents/com~apple~CloudDocs/GBM/AIHub/docs/02-CopyTrading/admin-zero-slippage.pen)

原型包含两个画面：

1. 主页面：补贴历史列表 + 统计看板 + 筛选区
2. 详情弹窗：订单级别的补贴明细表

使用 Pencil 编辑器打开 .pen 文件查看交互原型。

2. 核心逻辑回顾

基于《0滑点跟单用户指南》，核心核算逻辑如下：

• 补贴金额 = abs(跟单成交价 - 带单成交价) * 数量（当跟单价劣于带单价时）
• 每日上限：跟单净投资额的 3%
• 单笔上限：BTC/ETH 30万美元，其他币种 5万美元（或权益倍数限制）
• 权益倍数限制：根据带单员权益动态调整

IMPORTANT

T+1 结算机制：补贴按 T+1 发放，即每日结算前一日产生的滑点补贴。因此，后台只能查看已发放的历史记录，无法预览"今日待补"金额。时间筛选器中的"昨日"指的是发放日期为昨日的记录（即前日产生的滑点）。

3. 功能需求

3.1 概览看板

在列表上方展示选定时间段的关键指标（基于发放日期）：

• 累计补贴金额：平台总支出
• 昨日已发放：昨日完成发放的补贴总额（对应前日产生的滑点）
• 昨日受补用户：昨日享受补贴的去重用户数
• 平均单笔补贴：监控异常波动

3.2 筛选区

必须支持多维度的精准检索：

• 时间范围：默认为"昨日"
• 输入搜索：
  • 跟单 ID
  • UUID（带单员唯一标识）
  • 带单员昵称
• 下拉筛选：
  • 补贴状态（全部/已发放/触顶/异常）

3.3 补贴历史列表

对应原型的"补贴历史"表格。

字段	说明
跟单 ID	跟单关系 ID
UUID	带单员身份唯一标识。带单员关闭带单后重新开启，UUID 会更新
带单员昵称	带单员的显示名称
补贴交易对数量	本次结算涉及多少个币对
补贴订单数量	涉及多少笔订单
总补贴金额	核心字段，平台实际支出
补贴时账号权益	结算时刻的跟单账户权益（用于计算上限基数）
净投资额	用户投入的本金
当日补贴上限	此用户当日可获得的最高补贴额（净投资额 × 3%）
支付时间	补贴发放时间
操作	[详情] 按钮

3.4 补贴详情

对应原型的"详情"弹窗。需展示订单维度的精算过程。

展示形式：模态弹窗

字段	说明
交易对	如 BTC/USDT
订单 ID	具体的跟单成交订单号
方向	买入 / 卖出
带单成交价	带单员的成交价格
跟单成交价	跟单者的成交价格
价格偏离	跟单价 - 带单价（数值）
价格偏离比	滑点比例
跟单数量	成交数量
跟单价值	数量 × 价格
带单员权益	开仓时的带单员权益快照
跟单员权益	开仓时的跟单员权益快照
跟单/带单权益倍数	倍数限制的判断依据
赔付比例	0% - 100%（若触犯倍数限制则为 0%）
赔付金额	最终该笔订单的补贴额

4. 交互体验要求

• 布局优化：
  • 列表字段较多，需使用宽排版，避免挤压
  • 数字列（金额、权益）需右对齐，便于比对
• 层级清晰：
  • 详情表是核算的核心，使用模态弹窗展示完整明细

5. 验收标准

1. 字段完整性：必须包含上述所有财务核对字段
2. 布局整洁：表格列宽分配合理，无文字重叠，数字对齐
3. 逻辑自洽：详情中各笔"赔付金额"之和，应等于列表中的"总补贴金额"