DVT program: AirAccount co-signer 集成 — 架构 + 跨仓库分工 + 落地路线

[jhfnetboy]

DVT program hub —— 把 AirAccount #70（DVT co-signer）落地

本 issue 把 AirAccount 侧 DVT 设计（docs/design/dvt-solution.md，已 merged PR #71，4 轮 review APPROVE）汇到这里，作为 DVT program 的协调中心。yet-dvt 是 program hub + BLS 共签节点实现；其它仓库各提供自己那一块（协作关系，非被统领）。

---

📍 进度入口（最新状态看这三条评论 · 2026-06-14）

本 issue 当决策看板；规范正文进各仓库 docs/design/*.md 走 PR。最新协商状态与待办全在下面三条评论：

1. 决策看板 + 跨仓库回复一致性核对（先看这条） → #issuecomment-4702108909
   含 A 决策状态表 + B 一致性核对（谁还没对齐）+ 7 条「谁该回谁」待回复清单。
2. 协商项 code format #1 — BLS 签名 preimage / messagePoint 绑定格式 → #issuecomment-4702069726
   现状：airaccount-contract（lead）已定稿决策 B hash_to_curve(userOpHash, DST)，节点零返工；待 aastar-sdk 对齐 + chore(deps): bump actions/checkout from 6 to 7 #110 定 proof tuple/signerMask 位序。
3. 协商项 admin for signer #2 — DVT 策略治理（来源 / 生命周期 / 接口） → #issuecomment-4702074390
   提案：YetAnotherAA-Validator/docs/design/dvt-policy-governance.md。
4. 看板更新 — SP 两条权威答案 + 每账户 scoped 限额模型 → #issuecomment-4702143353
   SP #283 已定：proof tuple=(signerMask,sigG2)、signerMask=slot 位序、Decision 2 staked-validation（C1/C2 accepted）；新增「每账户 合约+资产+数额 自定义限额」模型（复用 AirAccount grant-session 原语）。
5. IPolicyRegistry 6 问 → chore(deps): bump actions/checkout from 6 to 7 #110 ack(Blocker-1 解除,2026-06-15) → #issuecomment-4703894384
   airaccount-contract chore(deps): bump actions/checkout from 6 to 7 #110 owner 确认 SP 的 6 个 IPolicyRegistry 对齐默认:Q1 ALLOW/REQUIRE_DVT/REJECT(预留 REQUIRE_EXTRA)· Q2 per-policy windowSeconds rolling · Q3 additive · Q6 wire-format-agnostic —— 4 项 ✅;2 处有意分歧(附代码依据):Q4 ETH 哨兵=0xEeee…EEeE(非 address(0))、Q5 governance=OZ TimelockController+2-of-3 RecoveryService(非自实现 timelock,因 registry 是独立单例、不受账户 EIP-170 约束)。→ 球回 SP:据此定稿 IPolicyRegistry + 实现 registry body。

✅ 协商已收敛 —— 四家全部 feedback： aastar-sdk（接受 B、撤回 A、tuple/slot 位序锁定）· airaccount-contract #110（4 项全确认；scoped 原语 TokenConfig+SessionKeyValidator 已上线 v0.18.0-beta.2，缺 sender-keyed staked registry 外壳）· SuperPaymaster #283（Decision 1+2 权威定稿）· AirAccount #70（#1/#2/§10 最终 +1）。

🟢 已定稿：preimage=B（节点零返工）· proof tuple=(signerMask,sigG2) · signerMask=注册 slot 位序 · Decision 2=staked-validation（sender-keyed todaySpent）· 产品默认值（2 天时间锁 / 2-of-3 RecoveryService / 自定义合约+资产+数额，不走 oracle / DVT 现可选未来必选）· scoped 限额复用 grant-session 字段形状。

🏁 协商全面 CLOSED（SP 已 confirm），进入实现阶段。 SP 补充一条 DST 修正：SP 自己的 BLS.sol 误用 _NUL_，须改为终态 _POP_（这是 SP 自身返工，非 YAA 节点——YAA 节点 + 黄金向量本就用 _POP_，仍零返工，且充当正确 DST 的参照基准）。

🟢 冻结终态：DST=BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_ · proof=(signerMask,sigG2)/slot 位序 · PolicyRegistry=新建 per-sender/staked/governance-gated（资产原生额度，无 oracle；2 天时间锁 + 2-of-3 RecoveryService；节点策略源==slash 源）。

🔧 实现阶段（各仓库 against 冻结决策）：SP v5.4 顺序 =（1）改 BLS DST _NUL_→_POP_ →（2）freeze 黄金向量 (message→msgG2)+(slot keys→pkAgg) →（3）出 IPolicyRegistry。**【2026-06-15 更新】(3) 的 IPolicyRegistry 6 个对齐问题已由 #110 ack 解除(见进度入口第 5 条):SP 按 Q4=0xEee…、Q5=OZ TimelockController 定稿接口 + 实现 registry body。**下游：#110 建 registry（复用 TokenConfig+Session 形状）· AirAccount 接 KMS 闸门 · aastar-sdk 收口组装 · YAA 节点 PolicyService 接链上第 1 层读取（待 IPolicyRegistry）。

---

一句话

DVT = 一组独立链下验证节点，对大额/高风险操作按各自策略 BLS12-381 门限共签，使「单把 owner key 被盗 = 全损」退化为「必须同时攻破 owner key + 门限内独立策略节点才损」。

⚠️ 命门（dvt-solution.md 反复强调）

安全增益全部来自「独立性」，不来自「再签一次」。 盲签（拿到请求就签 / 不跑独立策略 / 私钥与 owner key 同环境）→ DVT 形同橡皮图章。价值全部来自 CA 改不了的独立信号：① 独立 BLS 私钥 ② 独立策略（链上/节点本地，CA 无权改）③ 独立确认通道（不经 CA，直连用户另一设备）。

co-signer 角色不卡 R-1（比验证者角色强的地方）：它不验「签名来自真 NXP 芯片」，只断言「≥门限个独立节点按策略批准」——即使 KMS 是假 TEE（威胁模型向量 V5），大额操作仍要独立节点共签。所以 co-signer 是 V5 在 R-1 收口前的现实缓解手段。

跨仓库分工（各自拥有自己那块）

组件	仓库	职责
DVT 节点软件（BLS 门限共签 + 各自跑策略）	本仓库 yet-dvt	program hub + 节点实现
ROLE_DVT 合约（角色注册/质押/退出/slash + BLS 公钥注册/聚合验证）	SuperPaymaster	链上角色与经济约束
KMS 共签集成（大额 op 需 ≥门限 DVT 聚合共签才放行）	AirAccount	主签名方 + 集成点
链上验门限聚合签名	account contract	智能账户验证组合签名
客户端运行时聚合（收集 KMS 主签 + DVT BLS 聚合 → 提交）	aastar-sdk	运行时「汇聚者」
激励绑「正确执行策略」（贡献 SBT，非签名次数）	PGL / MushroomDAO	防盲签的经济约束

运行时的真正「汇聚者」是 SDK（客户端收集各方签名）+ 链上 account/SuperPaymaster（验门限）。yet-dvt 提供节点 + 程序协调，不是运行时调度中心。

防 DVT 自身被攻破

• 门限（≥N of M）：单节点失陷不致命。
• 多样性：不同运营者/法域/软件栈（同质化会被同一漏洞或同一法律强制一锅端）。
• 激励绑正确执行：绑「签名次数」= 节点为攒积分盲签 → 毁掉安全价值。

落地路线（建议）

1. yet-dvt：定节点协议（BLS12-381 聚合、策略接口、独立确认通道）+ 参考实现。
2. 给各协作仓库提 issue：SuperPaymaster(ROLE_DVT)、AirAccount(KMS 共签集成)、account-contract(链上验)、aastar-sdk(客户端聚合)、PGL(激励)。
3. co-signer 角色（B）先行（不卡 R-1）；验证者角色（A）依赖 chore: fix README license badge — MIT → Apache 2.0 #37/R-1，靠后。

参考

• AirAccount docs/design/dvt-solution.md（两角色 + 独立性命门 + co-signer 缓解 V5 不卡 R-1 + 与 KMS 互补 + 实现路线）
• AirAccount docs/design/threat-model-ca-adversary.md（V5 假 TEE）、docs/dKMS.md（去中心化 KMS：BLS 聚合 + 链上策略 + slash + VRF）
• BLS 聚合签名节点参考：本仓库 YetAnotherAA-Validator
• 上游：SuperPaymaster v5 ROLE_DVT + PGL 贡献记录

cc AirAccount #70。本 issue 由 AirAccount 侧汇总发起；yet-dvt 作为 program hub 协调推进。

[jhfnetboy]

DVT program 协调追踪表（领取 / 交付 / 核对）

每个仓库按自己的约定/文档实现自己那块，在各自 issue 里交付；本 hub 追踪 + 跨仓库核对。

#	仓库	任务	issue	状态	依赖
1	YetAnotherAA-Validator	DVT 节点软件（BLS 门限共签 + 独立策略 + 独立通道）	本 #42	⬜ 待领取	—
2	SuperPaymaster	ROLE_DVT 合约（注册/质押/退出/slash + BLS 注册/聚合验证）	#283	⬜ 待领取	—
3	airaccount-contract	智能账户链上验组合签名（KMS 主签 + ≥门限 DVT BLS 聚合）	#110	⬜ 待领取	SuperPaymaster #283
4	AirAccount	KMS 主签 + 大额 op 需 ≥门限 DVT 共签的集成点	AirAccount#70	⬜ 待领取	节点协议(#42)
5	aastar-sdk	客户端聚合（收 KMS 主签 + DVT BLS 部分签 → 聚合 → 提交，独立通道）	#63	⬜ 待领取	#283/#42
6	Brood (PGL)	激励：贡献 SBT 绑「正确执行策略」非签名次数	Brood#3	⬜ 待领取	#283

落地顺序（建议）

1. 协议先定（本仓库 DVT program: AirAccount co-signer 集成 — 架构 + 跨仓库分工 + 落地路线 #42）：BLS12-381 聚合格式 + 策略接口 + 独立确认通道。
2. 链上基础：SuperPaymaster #283（ROLE_DVT/BLS 验证）→ airaccount-contract chore(deps): bump actions/checkout from 6 to 7 #110（验组合签名）。
3. 集成 + 运行时：AirAccount feat(v1.4.0): Price Keeper Phase 1 — Chainlink oracle staleness guard (#58) #70（大额门限闸门）+ aastar-sdk [direction] aNode = 语言无关协议:SDK 边界切割(防循环)+ Node/Go/Rust 三实现并行的前置设计与阻塞 #63（聚合提交）。
4. 激励闭环：Brood Bump @types/node from 24.7.0 to 24.7.2 #3（PGL SBT）。
5. co-signer 角色（B）先行（不卡 R-1）；验证者角色（A）依赖 chore: fix README license badge — MIT → Apache 2.0 #37/R-1，靠后。

协调机制

• 本 DVT program: AirAccount co-signer 集成 — 架构 + 跨仓库分工 + 落地路线 #42 是单一事实源 + 进度表；各仓库 issue 链回本 hub。
• 各仓库自治：按自己约定/CI/文档实现 + 自测 + 交付；本 hub 做跨仓库核对（接口对齐、聚合签名端到端能验通）。
• 命门复核（每个交付都要过）：独立性（独立 BLS key + CA 改不了的策略 + 不经 CA 的通道）+ 激励不绑签名次数——否则 DVT 退化为橡皮图章。

注：本协调表由 AirAccount 侧汇总搭建（含设计 dvt-solution.md）。持续协调由 yet-dvt 仓库 owner / jason 驱动；AI 助手按需在单次会话内协助核对，不是常驻协调者——协调的持久载体是本表 + 各仓库 issue。

[jhfnetboy]

📋 协调文档已合入 AirAccount main：https://github.com/AAStarCommunity/AirAccount/blob/main/docs/design/dvt-program-coordination.md （与本 hub #42 的进度表配套；本 hub 是单一事实源）。各仓库 issue 已逐一关联本文档：SuperPaymaster#283 · airaccount-contract#110 · aastar-sdk#63 · Brood#3 · AirAccount#70。

[jhfnetboy]

DVT 依赖链 + 建议开发顺序（修订进度表 · 双向依赖说清）

上一条进度表的补充：把「谁依赖谁」补全成双向，并据此给出开发顺序。按依赖链推进——上游没定，下游接口就是猜的。

依赖关系（双向）

#	仓库 / 任务	它依赖谁（上游）	谁依赖它（下游）
#42	yet-dvt 节点协议 + 软件（BLS12-381 聚合格式 / 策略接口 / 独立通道）	— （基础，无上游）	#283, #70, #110, #63
#283	SuperPaymaster ROLE_DVT（注册/质押/slash + BLS 链上验证）	#42（BLS 方案要一致）	#110, #70, #63, #3
#70	AirAccount KMS 主签 + 大额门限闸门	#42, #283	#63, #110
#110	airaccount-contract 链上验组合签名	#42, #283, #70（组合签名格式）	—（终端：链上验证）
#63	aastar-sdk 客户端聚合（收 KMS 主签 + DVT 部分签 → 聚合 → 提交）	#42, #283, #70	—（终端：运行时）
#3	Brood PGL 激励（贡献 SBT 绑正确执行）	#283（质押/slash 钩子）	—（终端：经济闭环）

链条（一图看全）

        #42 节点协议(BLS方案/策略/独立通道)   ← 一切的根
          │
          ▼
        #283 ROLE_DVT 合约(BLS链上验/注册/slash)
          │            │
   ┌──────┴──────┐     └────────────► #3 PGL 激励(并行,#283 后可起)
   ▼             ▼
 #70 KMS闸门   #110 链上验组合签名
   │  (产出 KMS主签+组合格式)
   ▼
 #63 SDK 聚合(收 #70 主签 + 节点部分签 → 聚合 → 提交)

建议开发顺序（严格按依赖链）

1. DVT program: AirAccount co-signer 集成 — 架构 + 跨仓库分工 + 落地路线 #42：先定节点协议 —— BLS12-381 聚合格式、策略接口、独立确认通道。这是根，必须最先。
2. #283：ROLE_DVT 合约（BLS 方案要和 DVT program: AirAccount co-signer 集成 — 架构 + 跨仓库分工 + 落地路线 #42 一致）。
3. feat(v1.4.0): Price Keeper Phase 1 — Chainlink oracle staleness guard (#58) #70 + chore(deps): bump actions/checkout from 6 to 7 #110 并行：两者都只依赖 DVT program: AirAccount co-signer 集成 — 架构 + 跨仓库分工 + 落地路线 #42+#283；chore(deps): bump actions/checkout from 6 to 7 #110 还要等 feat(v1.4.0): Price Keeper Phase 1 — Chainlink oracle staleness guard (#58) #70 定下组合签名格式，所以 feat(v1.4.0): Price Keeper Phase 1 — Chainlink oracle staleness guard (#58) #70 略先于 chore(deps): bump actions/checkout from 6 to 7 #110。
4. [direction] aNode = 语言无关协议:SDK 边界切割(防循环)+ Node/Go/Rust 三实现并行的前置设计与阻塞 #63：SDK 聚合 —— 需要 feat(v1.4.0): Price Keeper Phase 1 — Chainlink oracle staleness guard (#58) #70 的 KMS 主签接口 + DVT program: AirAccount co-signer 集成 — 架构 + 跨仓库分工 + 落地路线 #42 的部分签格式，最后接。
5. Bump @types/node from 24.7.0 to 24.7.2 #3：PGL 激励 —— #283 之后即可起，可与 3/4 并行。

横切原则（顺序之外，每步都要守）

• co-signer 角色（B）先行：不卡 attestation R-1，即使假 TEE 也缓解 V5。验证者角色（A）依赖 chore: fix README license badge — MIT → Apache 2.0 #37/R-1，靠后。
• 命门：独立性（独立 BLS key + CA 改不了的策略 + 不经 CA 的通道）+ 激励不绑签名次数。每个交付在本 hub 核对时复查这两条。

协调文档：AirAccount docs/design/dvt-program-coordination.md（已 merged）。本 hub #42 = 单一事实源；各仓库按自己约定领取、交付，回本表核对。

[jhfnetboy]

补充:分工表漏掉的下游消费方 — YetAnotherAA(主仓 dapp/后端)

YAA 不是 DVT 的生产方(不建节点/合约/SDK),但已经在消费这条线的输出,建议纳入依赖图。代码实证(当前 master):

• aastar/src/bls/bls.service.ts:经 @aastar/airaccount 调 client.bls.generateBLSSignature(userId, userOpHash) + packSignature(blsData) —— 消费聚合 BLS 签名。
• aastar/src/transfer/transfer.service.ts:useAirAccountTiering: true,按金额分级:Tier1 = P256;Tier2 = P256+BLS;Tier3 = P256+BLS+guardian。

含义:

1. [direction] aNode = 语言无关协议:SDK 边界切割(防循环)+ Node/Go/Rust 三实现并行的前置设计与阻塞 #63(SDK 客户端聚合)是 YAA 的直接依赖。[direction] aNode = 语言无关协议:SDK 边界切割(防循环)+ Node/Go/Rust 三实现并行的前置设计与阻塞 #63 改 SDK 聚合/签名接口时,须保持 client.bls.generateBLSSignature/packSignature、executeTransfer({useAirAccountTiering}) 兼容,否则 YAA 转账流程会断。建议依赖图补一条:[direction] aNode = 语言无关协议:SDK 边界切割(防循环)+ Node/Go/Rust 三实现并行的前置设计与阻塞 #63 → YetAnotherAA(消费方 / 端到端验证)。
2. feat(v1.4.0): Price Keeper Phase 1 — Chainlink oracle staleness guard (#58) #70(KMS 大额门限闸门)需与 YAA 现有 Tier2/3 对齐:YAA 已有"大额→BLS+guardian"的金额分级,别与 feat(v1.4.0): Price Keeper Phase 1 — Chainlink oracle staleness guard (#58) #70 的门限闸门搞成两套重复/冲突的金额阈值;建议明确二者是同一机制。
3. 命门复核的现实印证:YAA 今天的 Tier2/3 BLS 若来自单点签名器,正是文档警告的橡皮图章。DVT 对 YAA 的价值,就是把这条已有的分级 BLS 变成真·独立分布式 —— 因此 YAA 适合当本 program 的"价值验证消费者":节点出部分签 → SDK 聚合 → YAA 转账端到端验通,实证独立性生效。

YAA 侧不新建 DVT 组件;#63/#70 定型后回来核对 YAA 的 bls.service/transfer.service 接口与分级对齐即可。

[jhfnetboy]

YAA(消费方)的依赖图自加 + 待澄清的疑惑(请 program 一起对一下)

接上一条补充。我把 YAA 作为消费方加进依赖图,并列出几个需要协议/各仓库一起拍板的疑惑——都源自 YAA 现有代码,贴出来在这交流。

依赖图自加

#63 aastar-sdk 客户端聚合 ──────────────→ YetAnotherAA(主仓 dapp · 消费方 / 端到端验证)
#70 KMS 大额门限闸门 ──(金额分级语义对齐)──→ YetAnotherAA transfer Tier2/3

我的疑惑 / 待澄清

Q1 — #70 门限闸门 与 YAA 现有 Tier2/3 是不是同一套?
YAA 现在按金额分级(transfer.service.ts,useAirAccountTiering):Tier1 = P256;Tier2 = P256+BLS;Tier3 = P256+BLS+guardian(ECDSA)。

• 是 (a) 把 Tier2/3 里那一签 BLS 换成门限 DVT 共签(同一机制,只是签名器从现状换成独立 DVT 节点集),还是 (b) 在 Tier3 之上再叠一层独立门限?
• 若 (a):金额阈值 tier1Limit/tier2Limit 与 feat(v1.4.0): Price Keeper Phase 1 — Chainlink oracle staleness guard (#58) #70 的"大额"阈值是同一组参数吗?在哪定(SDK 配置 / 合约)?
• 若 (b):P256 + guardian + DVT 门限的总签名,链上怎么验?airaccount-contract chore(deps): bump actions/checkout from 6 to 7 #110 的组合签名格式要不要为 YAA 这条(P256+guardian+DVT)留位?

Q2 — 当前 BLS 签名器是不是单点?(命门复核现实印证)
YAA 默认 BLS_SEED_NODES=https://v1.aastar.io(单一 seed),经 client.bls.getActiveSignerNodes() 取节点列表再聚合。

• 这个 seed 背后现在是 1 个签名器还是多个独立节点?若单点,YAA 今天的 Tier2/3"BLS 共签"实质是单签 = 命门复核里的橡皮图章。
• DVT 后 YAA 怎么发现/选独立节点?还是继续 getActiveSignerNodes() 吗?"不经 CA 的独立通道"在客户端侧具体长什么样?

Q3 — #63 聚合接口契约(YAA 直接依赖,别改断)
YAA 依赖:generateBLSSignature(userId, userOpHash) / packSignature(blsData) / getActiveSignerNodes() / executeTransfer({ useAirAccountTiering })。#63 客户端聚合重做时,这些保留(YAA 透明受益)还是会变(YAA 适配)?倾向保留或给迁移路径。

Q4 — packSignature 格式 与 链上验证联动
YAA 把 BLS 聚合 pack 进 UserOp signature(705B:nodeIds+blsSig+messagePoint+aaSig)。DVT 门限聚合后,这个 pack 格式 + 链上 validator 验证(#110)要不要变?YAA 的 packSignature 还兼容吗?

提案

YAA 愿意当本 program 的价值验证消费者:#63/#70 定型后,用 YAA 真实转账流程做端到端验证(节点部分签 → SDK 聚合 → YAA 提交 → 链上验通),实证"独立性生效、非橡皮图章"。

YAA 侧不新建 DVT 组件;以上是消费侧的接口/语义对齐点,answer 落定后我回来核对 bls.service.ts/transfer.service.ts。

[jhfnetboy]

Brood #3 (PGL 激励) — Check Review + 承接确认

来自 Brood orchestrator 视角的反馈。读完本 issue + Brood #3 + 上游 SP #283 + AirAccount docs/design/dvt-program-coordination.md，并核对了 SP v5 ROLE_DVT 现有实现 + Brood/PGL 文档兼容性。

关键现状发现

1. SP v5 ROLE_DVT 不是从零起：Registry.sol:85 已 _initRole(30 ether stake, 3 ether ticket, max 10 keys, min 2, ..., 30 days exit)；BLSAggregator.registerBLSPublicKey 已实现（含 H-02 自服务路径，stake 跌破 minStake 自动失效）。→ #283 是补全/校准 slash 触发器 + 把 BLS 验证扩到 DVT 场景，不是新建。
2. PGL 三个文档（Charter / Manifest / Revenue）完全没提 DVT：现有 PGL 是「数字 Agent 商店」3 角色商品模型（Supplier / Wrapper / Seller）；DVT 节点是基础设施公物提供者，不同维度。
   → 设计要做成 PGL 附录文档（protocol/PGL/DVT_INCENTIVE.md），不动 Charter 主体，但复用 PGL 法律红线（SBT 不可转让 + 无证券化）。

Check Review

维度	判断
方向正确性（绑正确执行策略 ≠ 绑签名次数）	✅
与 PGL 法律红线兼容（SBT 不可转让 + 不发币）	✅
与 SP v5 ROLE_DVT 经济闭环对接（复用 stake / slash / exit）	✅
依赖时序（#283 后即可起，与 #110 / #63 并行）	✅
「正确执行」可验证性	⚠️ 核心挑战（见下）
整体可执行	✅ 可执行，需先解 3 个设计问题

三个必须在设计阶段澄清的技术挑战

1. 「正确执行独立策略」如何链上可验证 — 推荐 Canary / Honeypot 机制（hub orchestrator 定期注入「按所有策略都应拒绝」的诱饵请求，签了即盲签即 slash） + 多样性 trait 间接保证独立性。负向验证比正向证明可落地。
2. SBT 颁发去中心化 — 全部链上自动颁发，触发条件机器可判（无盲签 trait / 在岗 trait / 多样性 trait），异常事件 → trait 扣减或 burn。零人工裁决。
3. 激励形态（不发币的前提下吸引人当节点） — 运营服务费（每次成功共签收固定服务费 = 普通商业对价，非「按次数线性发币」） + SBT trait 解锁 AgentStore 体系内的 curator 权限 / 高曝光位 / 优先支持等非货币权益 + 链上声誉外溢。

承接方案（Y: 协议规范 + 参考合约 interface）

交付物：protocol/PGL/DVT_INCENTIVE.md（PGL 附录，不污染 Charter 主体）

• 角色定义：ROLE_DVT_NODE = PGL 体系内的「基础设施公物提供者」
• SBT trait 体系（5-7 个 trait，每个有链上自动颁发 / 扣减条件）
• Canary / Honeypot 机制规范（含 hub orchestrator 协议接口）
• 服务费 + 非货币权益清单
• 与 SP v5 ROLE_DVT 的 stake / slash / exit 对接表
• Solidity IDVTIncentive.sol interface 草稿
• 反例库（绑签名次数 / 中心化裁判 / SBT 可转让 — 为什么都不行）

不修改：CHARTER.md 主体五条 / MANIFEST_SPEC.md（DVT 不是 AgentStore 上的作品，不签 pgl.yml）；REVENUE_MODEL.md 末尾加一条指针即可。

验收对齐本 hub

Hub 要求	交付对应
接口对齐	与 SP v5 ROLE_DVT 的 stake / slash / exit 全套对接表
命门复核 ① 独立性	DVT_INCENTIVE.md 「多样性 trait」+ 策略哈希注册
命门复核 ② 不绑签名次数	反例库 + SBT trait 全部基于「无盲签 / 在岗 / 多样性」非次数指标
法律红线	不发币 / SBT 不可转让 / 服务费 = 普通商业对价

时序

• 不阻塞：等 DVT program: AirAccount co-signer 集成 — 架构 + 跨仓库分工 + 落地路线 #42 节点协议定型 + #283 ROLE_DVT slash 触发器规范化
• 与 chore(deps): bump actions/checkout from 6 to 7 #110 / [direction] aNode = 语言无关协议:SDK 边界切割(防循环)+ Node/Go/Rust 三实现并行的前置设计与阻塞 #63 并行
• 预估：#283 ROLE_DVT 接口定型后 1 周内交付 DVT_INCENTIVE.md 初稿，回本 issue 贴进度表对齐 + 命门复核

— Brood orchestrator (cross-checked from Brood/#3 + SP source BLSAggregator.sol + Registry.sol)

[jhfnetboy]

补充：PGL 是 Charter 不是 License + 跟了 PGL 的 DVT 节点拿什么

为避免歧义，把 Brood 内部对 PGL 定位的澄清同步到本 hub。

PGL ≠ License，是 Charter / Layer 倡议

精确说法：

• PGL = Public Goods Layer（不是 License）—— 一个叠加在 Apache 2.0 / MIT / GPL 之上的自愿社会经济层
• Charter 是大家签的承诺书（不是法律文件）
• 不签 = 完全 OK，继续按原 license 用；签 = 拿到分发渠道 + 链上分账 + 声誉等权益

约束力来自渠道激励 + 链上记录可见性 + 社区声誉，不来自法律强制。

一句话：跟了 PGL 的 DVT 参与者拿什么

你拿到的是「链上不可转让的守护者声誉徽章」—— 不发币、不分红，但在 Mycelium 生态中能被引用、被信任、解锁 curator 等权限 + 运营服务费（普通商业合同）。

拆开看就两条腿：

• 现金腿：每次正常共签收运营服务费（不是按签名数线性发币，是普通商业对价 —— 合规）
• 声誉腿：SBT trait（无盲签 / 在岗 / 多样性）随时间累积成链上身份，能在 AgentStore 解锁权限、在生态被引用、在自身商业活动中作可信证明

不能卖、不能转，但复利成长期信任。

这两条腿合起来构成 PGL-DVT 的「正反馈闭环」：好好做事 → SBT 累积 → 生态权限 + 商业可信度 → 更多协作机会 → 持续做事的现金回报。

— Brood orchestrator

[jhfnetboy]

Hub 角色定位（权威说明 + 一个重要修正）

经过一轮核对，把 hub（本仓库 YetAnotherAA-Validator）的角色钉死，供所有子 issue 对齐。

1. "主持者"的准确含义：账本载体，不是常驻 agent

• 协调权的持久载体 = 本 issue DVT program: AirAccount co-signer 集成 — 架构 + 跨仓库分工 + 落地路线 #42 进度表 + 各仓库自己的 issue，不依赖任何人/AI 在线。
• AI 会话是单次、不持久的，只能在会话内协助接口对齐与命门复核，不驻守协调。
• 跨仓库推进的真正驱动者 = hub owner。仓库是「舞台 + 账本」，owner 是「指挥」。

Hub 的协调职责只有三件：维护依赖链/开发顺序、追踪 6 个子 issue 状态、把关命门复核。各子仓库按自己仓库的约定领任务/交付，完成后回 #42 核对——这个回流就是协调闭环。

2. ⚠️ 重要修正：hub 仓库本身有核心开发任务，不是纯看板

之前的表述容易让人误读为「hub 只协调、不写码」。这是错的。

YetAnotherAA-Validator 一身二职：

• 协调 hub → DVT program: AirAccount co-signer 集成 — 架构 + 跨仓库分工 + 落地路线 #42 进度表（维护职责）
• DVT co-signer 节点本体 → 整个 src/ signer service（真正的、也是最核心的开发任务）

证据：

• Fix2 Stage 1（已完成）：/signature/sign 的 owner-authorization gate（fail-closed 403），分支 feat/fix2-stage1-owner-auth。
• Fix2 Stage 2（OPEN，本仓库自己要写）：[Fix2 Stage 2] DVT node independent policy / out-of-band confirmation (owner-compromise protection) #40 DVT node independent policy / out-of-band confirmation (owner-compromise protection) —— 正是命门红线①「独立性」的落地主战场。

→ "改进 DVT" 的代码任务里，hub 仓库自己扛着最重的一块（命门①独立性），并非只做调度。

3. 依赖链与落地顺序（hub 口径，定稿）

#42 节点协议(根)
   └→ #283 ROLE_DVT 合约
        ├→ #70 KMS 大额门限闸门 ──(定组合签名格式)──┐
        │                                            ├→ #110 链上验组合签名
        │                                            └→ #63  SDK 客户端聚合(最后接)
        └→ #3  PGL 激励(并行)

顺序：#42 → #283 → #70(略先) + #110 → #63 → #3 并行
co-signer 角色（本仓库）不卡 R-1，可先行（Stage 1 已落地，Stage 2=#40 进行中）。

4. 命门复核（每个交付必过，否则 DVT 退化为橡皮图章）

• ① 独立性：独立 BLS key + CA 改不了的策略 + 不经 CA 的通道 —— 本仓库 [Fix2 Stage 2] DVT node independent policy / out-of-band confirmation (owner-compromise protection) #40 是主战场
• ② 激励不绑签名次数

---

一句话：hub = 本仓库（co-signer 节点实现 + #40）+ #42 账本。协调由账本承载、由 owner 驱动、由各仓库回流核对；同时 hub 自己扛命门①的核心实现，不是只调度。

[jhfnetboy]

📥 Brood #3 进度更新：DVT_INCENTIVE.md v0.1 草稿（70%）已出

消息来源：AAStarCommunity/Brood（PGL 体系所在仓库）
对应 hub 任务：Brood #3（PGL 激励 — DVT 节点贡献 SBT 绑「正确执行策略」而非签名次数）
PR：AAStarCommunity/Brood#4
预览文件：protocol/PGL/DVT_INCENTIVE.md

已完成（§1-§7 + §10，独立于 #283）

章节	内容
§1 定位	PGL 附录，不修改 Charter 主体；DVT 节点是 PGL 体系内的第 4 类参与者（基础设施公物提供者）
§2 角色定义	ROLE_DVT_NODE：完全开放、无许可；复用 SP v5 Registry.sol:85 已实装的 stake / exit / cooldown 机制
§3 两条命门	① 独立性（独立 BLS key + CA 改不了的策略 + 不经 CA 通道）② 激励不绑签名次数
§4 SBT trait 体系	5 个核心 trait（NoBlindSign / OnDuty / Diversity / PolicyPublisher / LongStanding），全部链上自动颁发，零人工裁决
§5 激励形态	现金腿：成功共签的运营服务费（普通商业对价，不是按次发币）·声誉腿：SBT trait 解锁 AgentStore curator / Mycelium DAO 治理引用 / CityRep 引用
§6 Canary / Honeypot 机制	「正确执行」的链上可验证负向证据：hub orchestrator 定期注入「按所有策略都应拒绝」的诱饵，签了即盲签即 slash + trait 清零
§7 反例库	6 个 PGL-DVT 不允许的设计：绑签名次数 / 中心化裁判 / SBT 可转让 / 服务费按 stake 线性 / 服务费按成功率线性 / Canary 设计公开
§10 边界澄清	不动 CHARTER / MANIFEST / REVENUE 主体；只在 REVENUE 末尾 + CITY_REP + README 加 1 段指针

待补（§8 + §9）—— 等 SP #283 ROLE_DVT slash 触发器定型

章节	内容
§8 SP v5 ROLE_DVT 对接表	registerRole / registerBLSPublicKey 调用规范 + slash 触发条件链上映射 + 服务费结算合约调用 + trait 颁发与 SP v5 SBT 系统对接
§9 IDVTIncentive.sol interface 草稿	完整 Solidity interface（基于 §8 实际对接表生成）

命门复核自检（hub #42 标准）

• ✅ 独立性：§4 Diversity trait + §3 策略哈希注册要求 + §6 Canary 机制保证
• ✅ 激励不绑签名次数：§3 命门二明文；§5 服务费按「成功共签的绝对次数」均分，不看比率；§7 反例库列出 3 种「绕回签名次数」的隐性陷阱
• ✅ 法律红线：SBT 不可转让、不发币、服务费 = 普通商业对价、零人工裁决
• ✅ 接口对齐：复用 SP v5 已实装的 Registry.sol:85 + BLSAggregator.registerBLSPublicKey（H-02 自服务路径）

一句话价值主张

跟了 PGL 的 DVT 节点拿到的是「链上不可转让的守护者声誉徽章」—— 不发币不分红，但在 Mycelium 生态中能被引用、被信任、解锁 curator 等权限 + 运营服务费（普通商业合同）。
现金腿 + 声誉腿，复利成长期信任。

后续

1. PR Bump ts-jest from 29.4.4 to 29.4.5 #4 review + 合入 Brood main
2. 等 SP #283 ROLE_DVT slash 触发器接口定型
3. 补 §8 + §9 → v0.2
4. 回本 hub 进度表 + 命门复核 → v1.0

— Brood orchestrator（消息来源：AAStarCommunity/Brood 仓库，对应 hub 分工的「PGL / MushroomDAO 那一块」）