YAA: guardian 协签 UX — 提额(#3b) + 转账 Tier-3(#3a)

[jhfnetboy]

YAA：guardian 协签 UX —— 提额（#3b）+ 转账 Tier-3（#3a）

分层安全里有两处需要 guardian 协签，本 issue 统一跟踪。

#3b 提额（放宽 tier 限额）

用户把 tier1/tier2/日限额抬高时，需 guardian 协签（modifyTierLimitsWithGuardians）。

• SDK 已交付（aastar-sdk#188）：modifyTierLimitsGuardianDigestFromChain（读链上 nonce 算 digest）+ encodeModifyTierLimitsWithGuardians（带 guardian 签名提交），合约 v0.20.1 有链上 e2e。
• YAA 要做：在 /tier-setup 或 /guard 加"提额"流程 —— 算 digest → 收 guardian 签名 → 提交。
• 现在可做：用自托管 guardian（用户自己的第二个 passkey/钱包）做完整链上 e2e。

#3a 转账 Tier-3 协签

单笔超 tier2 → 需 guardian 对 userOpHash 协签才能上链（resolveTransfer 已能判出 requiredSigs.guardian > 0）。

• 自托管 guardian → 浏览器内签 → 现在可做 + 可 e2e。
• 独立 guardian（别人）→ 要带外触达 → 依赖 Build(deps-dev): Bump eslint-config-next from 15.5.5 to 15.5.6 #193（绑定 + 方案2 批准）。

分工 / 需要协助

• aastar-sdk：请确认 #3b 自托管 guardian 协签的消费方式（digest → 谁签 → encode 提交），以及转账 Tier-3 的 submitPreparedTransfer({guardianSigner}) 用法。
• DVT（Validator#124）+ aastar-sdk Build(deps-dev): Bump eslint-config-next from 15.5.5 to 15.5.6 #193：独立 guardian 的带外批准（方案2）—— #3a 的独立路径依赖它。

落地顺序

1. #3b 提额 + 自托管 guardian 完整链上 e2e（先做）。
2. #3a 转账 Tier-3 自托管路径 + e2e。
3. #3a 独立 guardian 带外路径 —— 等 Build(deps-dev): Bump eslint-config-next from 15.5.5 to 15.5.6 #193。

关联：aastar-sdk#188（提额）、aastar-sdk#193（带外绑定/批准）、AAStarCommunity/YetAnotherAA-Validator#124（方案2凭证）。

[jhfnetboy]

#3b 进展：on-chain e2e 全过 ✅(PR #383)

scripts/test/onchain/raise-tier-limits.mjs 实跑 Sepolia 全程通过：

• 建带 2 guardian 账户 → digest（验证 == 合约 _guardianOpHash）→ 2 guardian 签 → 提交 → tier1Limit 0→0.5 ETH、tierLimitNonce→1（真 tx）。

确认的机制细节：

1. guardian 用 eth-prefixed signMessage 签 digest（不是 raw）。
2. RECOVERY_THRESHOLD = 2（2 个不同 guardian）。
3. modifyTierLimitsWithGuardians 是 onlyOwner。

UI 前要解的一个问题（需 SDK/合约确认）

真实 YAA 账户的 owner 是谁？怎么满足 onlyOwner？

• e2e 里 owner = 测试 EOA，直接 writeContract 即可。
• 但 YAA 账户的 owner 是 passkey / KMS 派生地址，不是用户能直接发 tx 的 EOA。
• onlyOwner 检查 msg.sender == owner；走 UserOp 时 msg.sender 是 EntryPoint/account，不等于 owner-passkey → 直接走 UserOp 可能过不了 onlyOwner。

请 @aastar-sdk / 合约team 确认：YAA 账户提额时，modifyTierLimitsWithGuardians 的 owner-call 路径是什么？

• (a) owner = KMS 可签的地址 → 后端用 KMS 发 owner tx？
• (b) 有 UserOp 包装让 account 以 owner 身份调自身？
• (c) 其他？

机制已证；这是 UI 落地的最后一块拼图。

[jhfnetboy]

owner-call 路径确认(SDK + 合约实证)

读了 AAStarAirAccountBase.sol,给结论:

(b) UserOp 让 account 调自身 → ❌ 不行

modifyTierLimitsWithGuardians 是严格 onlyOwner(msg.sender == owner),不是 onlyOwnerOrEntryPoint。

• 走 4337 UserOp → msg.sender == EntryPoint ≠ owner → revert NotOwner。
• 走 account.execute(self, ...) → msg.sender == account ≠ owner → revert。
  → 带 guardian 的提额不能经 bundler/UserOp。

(a) owner 直发 tx → ✅ 正解

账户 owner 是 secp256k1 ECDSA signer(合约 _owner 注释 + owner = _owner)。YAA 账户的 owner key 在 KMS/TEE 里。
→ KMS/TEE 用 owner key 签一笔普通 eth tx({to: account, data})+ relayer 广播,msg.sender == owner 满足。

关键:这适用于所有 onlyOwner 调用,不只提额

setTierLimits / setWeightConfig / addGuardian 也都是严格 onlyOwner。所以 owner-tx 路径是初始 tier 配置就需要的前置,不是提额新增的。YAA 初始 setTierLimits 怎么发的,提额就怎么发(同路径 + 加 guardian 签的 calldata)。

SDK 已就位(无需新增)

• modifyTierLimitsGuardianDigestFromChain({client, account, ...}) → 读 nonce + 建 digest(0.26.17,链上 e2e 验过)。
• encodeModifyTierLimitsWithGuardians(account, t1, t2, deadline, guardianSigs) → 返回 {to: account, value:0, data} calldata。
• #3b UI 流程:① SDK 建 digest → ② 2 guardian 钱包 eth-prefixed signMessage(digest) → ③ SDK 建 calldata → ④ 交 KMS 以 owner 身份发这笔 tx。
• (已修 SDK 注释 aastar-sdk#202:之前误写"owner UserOp",会把你带去 revert 的路径。)

⚠️ 唯一开放点 → 给 KMS 团队

KMS 是否暴露"以账户 owner 身份签 + 广播任意 eth tx"的端点?(签 raw eth tx 用 TEE owner key)。

• 若 YAA 已能发 setTierLimits(onlyOwner),这条已存在 → 提额直接复用。
• 若没有(初始 tier 也没在链上发过),则 KMS 需补这个 owner-tx 端点 —— 这是 setTierLimits + 提额共同的前置。

@AAStarCommunity/AirAccount(KMS):请确认 owner-tx 提交路径是否已有。合约侧无需改动(机制已实证)。

[jhfnetboy]

合约侧确认（airaccount-contract v0.20.1）

楼上分析正确，合约侧补充实证。

onlyOwner 源码确认

// src/core/AAStarAirAccountBase.sol:282
modifier onlyOwner() {
    if (msg.sender != owner) revert NotOwner();
    _;
}

// src/core/AirAccountExtension.sol:111 (modifyTierLimitsWithGuardians 所在)
modifier onlyOwner() {
    if (msg.sender != owner) revert NotOwner();
    _;
}

owner = initialize() 传入的 EOA 地址（secp256k1 key 对应地址），存在 storage slot 中。不接受 address(this) 也不接受 EntryPoint。

UserOp 路径为什么必死

executeUserOp 的调用链：

EntryPoint.handleOps
  → account.executeUserOp(userOp)       // msg.sender = EntryPoint ✓ onlyEntryPoint 过
    → address(this).delegatecall(inner)  // 相当于 execute()，msg.sender 仍 = EntryPoint
      → _call(dest, value, func)         // dest=address(this) → 新的 external call
        → modifyTierLimitsWithGuardians  // msg.sender = address(this) ≠ owner → NotOwner ❌

这不是 bug，是设计：admin 操作（改 tier、加 guardian）要求明确的 owner key 授权，EntryPoint 代理路径刻意被排除。

所有 onlyOwner 函数（共 17 个）都走同一路径

包括：modifyTierLimitsWithGuardians、modifyTierLimitsWithMixedGuardians、addGuardian、addP256Guardian、removeGuardianWithMixedSigs、setWeightConfig、proposeWeightChange、registerAgent、revokeAgent……

结论：YAA 账户从 createAccountWithDefaults 部署后，首次 setTierLimits 就已经走过一次 owner-tx 路径。提额复用同一路径，没有新依赖。KMS 只需确认这条路径已有（见下）。

给 KMS 团队的唯一问题

YAA 账户部署后，第一次 setTierLimits（onlyOwner）是怎么发出去的？

如果已有答案，提额直接复用。如果 setTierLimits 也从未在链上发过（初始 tier 在 initialize 里设），那 KMS 需要新增"owner 签 raw eth tx + broadcast"端点——这是 所有 admin op 的共同前置，不只是提额。

合约侧无需任何改动，v0.20.1 已在 Sepolia 部署（Factory 0x4f7BBb00c1086f5c0EBdDBDb4BC39cF348EfB2C3，tierLimitNonce() selector 0xb6135596 可用）。

[jhfnetboy]

✅ owner-tx 路径已存在(KMS 无需新增)—— 给具体落地步骤

读了 KMS signer:/Sign 端点已能签 EIP-155 Transaction(RLP,owner key 在 TEE,WebAuthn-gated)—— 见 kms-signer.ts sign / signWithCeremony("Sign a message or EIP-155 transaction via /Sign")。所以 (a) 不只是正解,能力本来就有,不用等 KMS 加端点。

#3b 提额的完整落地链路(后端流程)

1. (浏览器) SDK modifyTierLimitsGuardianDigestFromChain({client, account, t1, t2, deadline}) → digest。
2. (浏览器) 2 个 guardian 钱包 signMessage({message:{raw: digest}})(eth-prefixed)→ [sig1, sig2]。
3. (浏览器→后端) SDK encodeModifyTierLimitsWithGuardians(account, t1, t2, deadline, [sig1,sig2]) → {to: account, data} calldata。
4. (后端) 构 EIP-155 tx {to: account, data, nonce, gas, chainId} → KMS /Sign(owner ceremony,Transaction 字段) 用 owner key 签 → signed raw tx。
   • SDK 的 KmsSigner.signWithCeremony(...) 已封装这步。
5. (后端) sendRawTransaction 广播(relayer / RPC)→ msg.sender == owner 满足 ✓。

⚠️ strict 板(#63)注意

/Sign 签 Transaction 在 strict 模式要传 options.payload = 该 tx 的签名 digest(SDK 算不出 RLP 逐字节,默认裸 nonce 会被拒)。SDK KmsSigner 支持 options.payload,后端算好 tx 的 signing hash 传进去即可。

关键:这和初始 setTierLimits 同路径

setTierLimits/addGuardian 也都是严格 onlyOwner → YAA 初始 tier 配置就走这条 owner-tx 链路,提额只是第 1-3 步多了 digest + guardian 签。所以不是提额新增的前置。

→ owner-call 路径定了:KMS /Sign 签 EIP-155 tx + 广播。SDK 三个件齐(digest / calldata / KmsSigner)。YAA #3b UI 可落地。 唯一要 YAA 后端做的:第 4-5 步(KMS /Sign + 广播),browser 侧只收集 guardian 签。

@AAStarCommunity/AirAccount(KMS)请确认 /Sign 的 Transaction 路径在 dev 板 v0.27.0 可用(应该是既有能力)。

[jhfnetboy]

KMS 团队确认 — owner-tx 签名路径（提额 setTierLimits）

查了 KMS 代码，逐条确认 + 两处要澄清的事实：

✅ 签名路径已存在、可直接复用（无新增 KMS 签名工作）

POST /Sign 接受 transaction 对象 → TEE 用账户 owner secp256k1 密钥签一笔以太坊交易（api_server.rs sign_transaction）。提额直接复用：

build owner tx { to: <account>, data: <setTierLimits calldata>, value:"0x0", nonce, gas, gasPrice, chainId }
  → POST /Sign (带 owner WebAuthn ceremony) → TEE 签 → 返回 signature

要 owner WebAuthn ceremony（passkey，与所有签名 op 一致）——正合适：owner 显式授权提额。

⚠️ 一处纠正：KMS 是「签」不是「直发」

楼上 (a)「KMS 直发 owner tx」要修正：KMS 只签、不广播（KMS 内无 RPC/provider/sendRawTransaction）。所以路径是 KMS 签 owner tx → 客户端(SDK/YAA)广播签好的 raw tx——和今天所有 tx 一样。签名零额外工作；广播本就在客户端侧。

⚠️ 「首次 setTierLimits 怎么发」的前提要更正

KMS 不部署账户、也不发 tier 配置（无 tier/deploy/factory 逻辑）。所以初始 tier 配置不是 KMS 发的，是 SDK/YAA 编 tx → KMS 签 → 客户端广播。提额是同一个 Sign-then-broadcast 模式，无 KMS 内部 tier 流程（也不需要）。

需 YAA/SDK 确认两点（决定是否真的零额外工作）

1. 交易类型：当前 /Sign 的 transaction 是 legacy（gasPrice），不支持 EIP-1559（无 maxFeePerGas/maxPriorityFeePerGas）。owner tx 走 legacy 行不行？若必须 type-2 → 这是 KMS 要补的小工作。
2. owner == KMS 派生 EOA：owner tx 的 msg.sender = 该 owner 密钥派生地址。需确认 YAA 账户的 owner 就是这个 KMS 托管地址（否则 onlyOwner 过不了）。

• 另：/Sign 返回 signature（hex），SDK 用它 + tx 字段组装 raw tx 广播（响应里 transaction_hash 目前是占位，不影响）；nonce/gas 由客户端给。

结论：签名路径在、可复用、要 owner ceremony；唯一可能的 KMS 小工作 = 若需 EIP-1559。确认 legacy 可用 + owner-EOA 对齐后，#3b UI 即可动手。跟踪在 AirAccount#129。

[jhfnetboy]

✅ KMS 实跑确认：/Sign 在 strict 模式签 EIP-155 owner tx —— 成功（dev 板 kms.aastar.io v0.27.2）

不只读代码了——在 dev 板实跑了一次完整 strict owner-tx 签名，过：

• CreateKey(test passkey) → BeginAuthentication → 构造 strict commitment → POST /Sign (Transaction + WebAuthn ceremony)
• 返回广播就绪的已签 EIP-155 raw tx：f86c80 8504a817c800 825208 94<to> 88<value> 80 25 a0<r> a0<s> —— v=0x25=37（EIP-155, chainId=1），验签恢复 sender 成功（密码学有效）。

SDK 在 strict 下要构造的 commitment（实测精确公式）

TA 对 tx 做 #68 payload-commitment 绑定（verify_passkey_for_wallet(.., Some(tx_signing_hash))）。所以：

nonce_bytes      = base64url_decode( BeginAuthentication.Options.challenge )
tx_signing_hash  = keccak256( RLP([nonce, gasPrice, gas, to, value, data, chainId, 0, 0]) )   # 标准 EIP-155 unsigned hash
clientDataJSON.challenge = base64url( SHA256( nonce_bytes ‖ tx_signing_hash ) )

• tx_signing_hash 用 eth_account serializable_unsigned_transaction_from_dict(tx).hash()（或 viem/ethers 的 unsigned tx hash）算的，与 TA 内部 Wallet::tx_signing_hash 逐字节一致（commitment 被接受=证明匹配）。
• 然后 POST /Sign { KeyId(或 address), DerivationPath, Transaction:{chainId,nonce,to,value,gasPrice,gas,data}, WebAuthn:{ChallengeId, Credential} } → { Signature: <已签 raw tx hex> }。
• owner ceremony 必需（owner passkey 签 commitment）——正是提额该有的：owner 显式授权。

结论 + 一个 caveat

• 零新增 KMS 开发：既有能力，现已 strict 实跑确认。YAA 后端按上面 recipe 发 owner tx（KMS 出已签 raw tx，YAA/SDK 广播）。
• caveat（仍需 YAA 确认）：当前 /Sign 是 legacy EIP-155（gasPrice），不支持 EIP-1559（type-2 maxFee）。提额 owner tx 走 legacy 行不行？若必须 1559 → 这才是 KMS 要补的小工作。
• owner == 该 wallet 的派生 EOA（msg.sender==owner 成立）。

球回到 YAA：确认 legacy 可用即可动 #3b UI。Refs AirAccount#129。

[jhfnetboy]

关键发现 + 决策:owner-call 走 gasless(方案 B），已提合约需求

发现：onlyOwner 配置调用 = #1 画像页实际未生效

setTierLimits / setWeightConfig / modifyTierLimitsWithGuardians 均 onlyOwner（严格 msg.sender==owner，owner=KMS-EOA，无 self）。

• simulate 实证：setTierLimits self-call（passkey UserOp 路径）→ NotOwner()；owner-call → ✅。
• 影响：Feature/validator #1 画像页经 sponsored UserOp（execute 包裹 self-call）提交 profileSetupCalls → 链上 revert → tier 从未真正设上。#3a 设 tier、#3b 提额同理被挡。

决策：B（gasless），不走 A（给 owner-EOA 充 ETH）

理由：AirAccount 是合约账户，配置变更应和所有操作一样 gasless（xPNTs + SuperPaymaster 代付）；A 会引入"每用户隐藏 EOA 充 ETH + 散碎运维"，违背"用户永不碰 ETH"招牌。用户对 A/B 完全无感知（都是 点一下+指纹）。

已提合约需求 → airaccount-contract#140

把 3 个配置函数从 onlyOwner 放宽为允许 msg.sender==address(this)（self-call）。YAA/SDK 的 execute(account,0,configCalldata) self-call 即可通，YAA/SDK 侧零改动。安全不削弱（execute 已被 validateUserOp/passkey 把关；setTierLimits 初始后锁；提额仍需 2 guardian 签名）。

YAA 侧状态（等 #140）

• Build(deps): Bump @types/react from 19.1.13 to 19.1.15 #140 落地后 Feature/validator #1 画像页自动生效（现有代码不改，self-call 路径就通）——届时我会跑验证。
• #3a B3 e2e（设 tier 步骤）解锁；spec 已写好，待 Build(deps): Bump @types/react from 19.1.13 to 19.1.15 #140 后跑。
• #3b 提额 UI 解锁。
• #3a 的 B1+B2（PR feat(transfer/#3a): Tier-3 guardian co-sign (B1 backend + B2 UI) [B3 e2e pending] #384，转账 guardian 协签）本身是 UserOp 非 onlyOwner，不被 Build(deps): Bump @types/react from 19.1.13 to 19.1.15 #140 阻塞，但其 B3 e2e 的账户配置步骤要等 Build(deps): Bump @types/react from 19.1.13 to 19.1.15 #140。

当前 YAA 侧 #3 暂停，等合约 #140。