Noir Beta 反馈 · 产品评审

3 个分页 · 25 项 · PR82 真扩展复核版本 211fb2c(未合并)

25 项已逐项复核当前代码调用链,并区分旧版问题、当前实现和实际验证范围。需求由产品决定;技术事实与复现由技术核实。未复现不等于已修复,受控数据检查不等于真实链上验收。截图与每项核实范围一一对应。

F1-1a

Private Swap 的 Gas 不足发现过晚

状态已确认 Bug,待修复已确认缺陷211fb2c 真实隔离扩展中,零原生 Gas 余额仍允许点击 Swap,点击后才提示不足;未广播交易。
原文
no way to pay gas on the Private account. it starts with 0 ETH, so my first swap there failed with "Insufficient native balance", and i only found out after clicking Swap.
合理性
零原生币余额且该交易需要原生 Gas 时,当前提示时机过晚。准确费用仍须在准备交易时判断。
核实情况
隔离 MV3:Private Ethereum USDC 10、ETH 0,Swap 可点击;点击后出现 Insufficient native balance,未进入确认页。余额和报价来自受控接口,无广播。
根因
输入金额不足与已准备交易的费用会拦截,但按钮前未检查已知的原生 Gas 零余额;Gas 不足在准备交易时才返回。
建议
在原生 Gas 余额已知为 0 且操作需要该币种时提前反馈;保留准备交易后的精确费用校验。

复现截图

本轮复现 · 原生 ETH 为0,USDC 为10,Swap 仍可点击。
本轮复现 · 原生 ETH 为0,USDC 为10,Swap 仍可点击。
本轮复现 · 点击后才显示原生余额不足,尚未进入确认页。
本轮复现 · 点击后才显示原生余额不足,尚未进入确认页。

原始截图

原反馈未附此项截图。

本轮验证:PR82 211fb2c · 隔离 Chromium MV3 · 公开测试钱包/受控接口 · 未真实广播。

代码依据与 PR82 归属(211fb2c)

211fb2c 仍可复现提示过晚;USDC 付 Gas 属独立需求。

F1-1b

用 USDC 支付 Gas

状态待产品确认新增能力需求当前可核对的 Swap 路径按原生币支付网络费;USDC 付 Gas 尚未作为产品能力确认。
原文
would be great to have gas paid in USDC
合理性
允许 USDC 支付 Gas 是支付路径和费用模型的新能力,不能作为 F1-1a 提前提示缺陷的既定修法。
核实情况
只读核对 211fb2c 源码;未执行 USDC Gas 交易,不能据此断言底层链或服务绝无代付能力。
根因
已核对交易准备后的费用比较使用网络原生币余额;本轮未见 Swap 的 USDC Gas 选择与执行路径。
建议
请产品确认是否支持 USDC 付 Gas、目标链与优先级;确认后再评估代付提供方、费用报价和失败回退。不能把它当作提前提示 Bug 的既定修法。

当前界面截图

暂无对应功能界面;本项为待评估诉求。

原始截图

原反馈未附此项截图。
代码依据与 PR82 归属(211fb2c)

PR82 未提供已核实的 USDC Gas 产品流程;此项仍是需求。

F1-1c

一键经 Shield 补充 Private Gas

状态待产品确认新增能力需求已有通用 Move 入口;尚未发现面向 Private Gas 的一键充值流程。
原文
i ended up moving ETH Public -> Shield -> Private by hand to keep them separate. would be great to have gas paid in USDC, or a one-click "top up gas via Shield", and at least show the warning before i hit Swap
合理性
用户希望从 Shield 快速补充 Private Gas,属于新增快捷工作流;是否自动选链、币种和金额需设计。
核实情况
只读核对入口和 Move 交易构造;没有执行入金或转账。
根因
当前 Shield 入口进入通用 Move,并由用户选择转移领域和资产;未见 Gas 专用动作。
建议
请产品确认是否需要 Private Gas 专用快捷入口;再明确目标链、Gas 币种、金额与费用来源。现有通用 Move 可以作为候选路径,但“经 Shield”不自动构成不被关联的隐私保证。

当前界面截图

暂无对应功能界面;本项为待评估诉求。

原始截图

原反馈未附此项截图。
代码依据与 PR82 归属(211fb2c)

PR82 提供通用 Move,但本轮未验证真实资金补 Gas 完整流程。

F1-2

选币后目标从 Private 静默变为 Public

状态疑似 Bug,待复现待核实缺陷线索现有真实扩展用例未复现选币后目标变 Public;初始化存在与选币事件不同的方向回退逻辑。
原文
when moving Shield -> Private, picking the token silently changed the destination from Private to Public. i caught it before confirming, but someone could easily send their Shield funds back to Public without noticing
合理性
选币事件本身不修改 From/To。若发生静默改向,应先确定是入口初始化、旧草稿恢复还是其他时序。
核实情况
隔离 MV3 中从 Shield→Private 将 Ethereum USDC 改为 Ethereum ETH,目标仍为 Private;未覆盖用户原资产、旧草稿与精确入口。
根因
Shield 入口初始化在无可用 Shield 资产且未编辑草稿时可回退方向;选币回调只更新资产、金额及相关目标资产,不直接改变领域。
建议
用原入口 URL、原资产和同账户草稿重现,记录选币前后 From/To 与初始化 effect 时序;确认后再定位修复。

当前界面截图

本轮当前界面 · Move 已选择 Shield → Private,切币前。
本轮当前界面 · Move 已选择 Shield → Private,切币前。
本轮当前界面 · 改选 ETH 后仍为 Private,未静默变更目标。
本轮当前界面 · 改选 ETH 后仍为 Private,未静默变更目标。

原始截图

原反馈未附此项截图。

本轮验证:PR82 211fb2c · 隔离 Chromium MV3 · 公开测试钱包/受控接口 · 未真实广播。

代码依据与 PR82 归属(211fb2c)

211fb2c 的已测选币路径未复现;不能把初始化回退直接认定为用户所述选币触发。

F1-3

异步选币列表重排导致点错链

状态疑似 Bug,待复现待核实缺陷线索异步加载时有条件稳定排序,但搜索、余额层级变化和新增网络仍可能移动目标行;误点尚未复现。
原文
in the token picker, the list keeps reshuffling while it says "Searching more networks...". i clicked ETH on Base and it selected ETH on Arbitrum because the rows moved under my cursor
合理性
已选代币状态稳定不等于鼠标下方的行稳定。当前保护只适用于空搜索且过滤条件不变,并限同余额层级。
核实情况
本轮一次性执行生产排序函数:Arbitrum 从零余额变为正余额时,即使已有 Base→Arbitrum 的顺序记录,仍会前移成 Arbitrum→Base。既有 MV3 只验证选中 token ID 不变,尚未复现鼠标落点由 Base ETH 变成 Arbitrum ETH。
根因
多链目录渐进发布;稳定顺序只在特定条件下沿用旧行次序,搜索提示与网络选项可能改变布局。
建议
按原搜索词和鼠标位置重现,记录加载前后两行坐标及实际点击的 assetId,再决定是否固定列表布局。

当前界面截图

本轮当前界面 · 目录请求仍在加载时的选币列表。
本轮当前界面 · 目录请求仍在加载时的选币列表。
本轮当前界面 · 目录返回后仍为所选 USDC Ethereum;不是原 ETH 误点场景。
本轮当前界面 · 目录返回后仍为所选 USDC Ethereum;不是原 ETH 误点场景。

原始截图

原反馈未附此项截图。

本轮验证:PR82 211fb2c · 隔离 Chromium MV3 · 公开测试钱包/受控接口 · 未真实广播。

代码依据与 PR82 归属(211fb2c)

211fb2c 有部分顺序保护,但不能据此认定异步误点已修复。

F1-4

Move 默认选中同名币的零余额链

状态疑似 Bug,待复现待核实缺陷线索普通 Move 默认优先有余额资产;已测 Base USDC 余额 10 时选中 Base USDC,零 Max 的原路径尚未复现。
原文
the Move screen sometimes preselects the right token on the wrong chain. e.g. it picked USDC on a chain where i have 0, so it showed "0 Max", even though my USDC was on Base. both look identical so for a sec i thought my funds were gone
合理性
默认选择使用链限定 assetId 和来源领域余额,不按同名币合并。不同入口或同作用域草稿可影响初始选币。
核实情况
隔离 MV3 普通 Move 入口在仅 Base USDC 有余额时默认 Base USDC 10;当时仍显示 Loading balances,未覆盖资产详情或旧草稿。
根因
普通默认优先有余额来源;资产详情传入完整 assetId,同作用域路由草稿可优先于路由 assetId,Shield 入口偏好又有独立候选逻辑。零 Max 随当前所选来源资产余额计算。
建议
获取原入口、查询参数、location.state 草稿及余额加载完成后的完整资产 ID,复现为何选到零余额链。

当前界面截图

本轮当前界面 · 普通 Move 默认 Base USDC,余额10;页面仍在加载。
本轮当前界面 · 普通 Move 默认 Base USDC,余额10;页面仍在加载。
本轮当前界面 · 资产选择器显示有余额的 Base USDC。
本轮当前界面 · 资产选择器显示有余额的 Base USDC。

原始截图

原反馈未附此项截图。

本轮验证:PR82 211fb2c · 隔离 Chromium MV3 · 公开测试钱包/受控接口 · 未真实广播。

代码依据与 PR82 归属(211fb2c)

211fb2c 普通默认路径未复现,不能把同名币歧义写成已证实根因。

F1-5

Public 列表显示三个账户合计

状态疑似 Bug,待复现待核实缺陷线索211fb2c 的 Public 列表代码已按 Public 余额投影;用户看到的 4.49 尚无对应版本与原始余额模型可核对。
原文
the asset list under the Public tab shows the total across Public + Shield + Private, not just Public. my USDC showed 4.49 when Public only had 3 (the rest was 1 in Shield and 0.49 in Private). i thought the balance was stuck until i checked on-chain
合理性
当前设计并非在 Public 列表显示三个隐私领域合计;若当前版仍显示跨领域合计,应作为缺陷调查。这里的领域也不等同于三个钱包账户。
核实情况
已核对 Home→按领域投影→分组→资产卡片。一次性执行生产投影函数:total=449、Public=300 时,列表和链分组都得到300,原始总额仍449。尚未在真实扩展还原原反馈的4.49显示。
根因
Public 列表在进入资产分组前提取 EVM mainRaw 或 Zcash transparentRaw,分组只对投影后的资产求和。原反馈数值无法由本轮源码直接还原。
建议
确认截图构建版本及同一资产的 total/main/private/shield 原始余额;在 211fb2c 对照 Public 列表显示值。

当前界面截图

暂无当前界面截图。

原始截图

原反馈未附此项截图。
代码依据与 PR82 归属(211fb2c)

当前 211fb2c 列表已按 Public/Shield/Private 投影后聚合。此次未建立原 4.49 场景的修复归属,不能声称是 PR82 新修,也不能把跨域合计当成预期设计。

F1-6

Private 入口 Swap 默认成 Zcash Shield

状态疑似 Bug,待复现待核实缺陷线索211fb2c 私有入口携带 Private 上下文并过滤 ZEC 来源;真实扩展最终显示 ETH Ethereum→USDC Ethereum。
原文
when i opened Swap from the Private tab, the "From" was set to Zcash Shield with ZEC (0 balance) instead of my Private account. had to change both the token and the account manually
合理性
当前代码的私有来源候选明确排除 ZEC;保存偏好不能越过过滤后的候选列表选回 ZEC。原反馈可能涉及旧构建或未覆盖的启动时序。
核实情况
现有隔离 MV3 在 Swap 内切换到 Private 后,稳态为 ETH Ethereum→USDC Ethereum;本轮另追踪 Home Private 入口参数、ZEC 过滤和保存偏好解析,确认偏好不能越过过滤列表选回 ZEC。未录制原反馈安装包或冷启动瞬态。
根因
当前版 Home 入口传递 Private mode 和链限定来源资产,Swap 选择器按私有 EVM 候选解析;无法从当前稳态路径确认原 Zcash Shield 默认出现的原因。
建议
先核对原截图构建版本与入口参数;仅当仍可在 211fb2c 复现时,补采冷启动首屏与选择器状态。

当前界面截图

本轮当前界面 · Private Swap 默认 ETH → USDC,未出现 Zcash。
本轮当前界面 · Private Swap 默认 ETH → USDC,未出现 Zcash。

原始截图

原反馈未附此项截图。
PR82 历史修复后验证图(1 张)
旧 B12:Private 普通入口默认 Ethereum ETH→USDC。仅为修复后证据;无本次反馈的 Zcash 默认原图。
旧 B12:Private 普通入口默认 Ethereum ETH→USDC。仅为修复后证据;无本次反馈的 Zcash 默认原图。

本轮验证:PR82 211fb2c · 隔离 Chromium MV3 · 公开测试钱包/受控接口 · 未真实广播。

代码依据与 PR82 归属(211fb2c)

当前入口和候选过滤已存在且稳态未复现;不要泛称保存偏好仍会默认选 ZEC。

F1-7

助记词确认页再次展示整组明文候选

状态已修复,待验收历史隐私体验缺陷全组真实词暴露已在更早的 #71 修正;PR82 包含该修复,不是 PR82 新增。
原文
the seed confirmation step (pick the 3rd and 10th word) shows all 24 words in plain text, just shuffled. the screen right before it blurs them, so this one kinda undoes that
合理性
原反馈可能准确:更早 227616a 实现确曾打乱展示整组真实词。PR82 提交版只展示被抽查的两个真实词,其余为排除整组助记词后的干扰词。
核实情况
已核对旧版全词打乱实现、#71 的 3ed4660 修复、PR82 基线和当前代码;本轮既有助记词用例通过,只保留被抽查的两个真实词。未新增实包截图。
根因
旧版 shuffleVerificationWordOptions 直接对 words.map 结果打乱;3ed4660 将候选改成两真实词加非助记词干扰项。
建议
按当前版本验收两词抽查与干扰项;不重复修复旧版全组暴露问题。若需进一步限制两词可见性,再作为独立隐私交互诉求评估。

当前界面截图

暂无当前界面截图。

原始截图

原反馈未附此项截图。
代码依据与 PR82 归属(211fb2c)

整组词暴露修复来自 3ed4660 (#71),已在 PR82 基线 cb4ca51 中;PR82 自身没有修改这两个文件。

修复来自 #71 的 3ed4660,早于 PR82。

F1-8

Move 被标为 Receive / Send

状态已修复,待验收交互文案缺陷PR82 已修复自有账户 Shield Move 的活动标题,真实产生交易后的进度与列表尚未验收。
原文
the same kind of action gets different labels. my Public -> Shield move showed as "Receive -2 USDC" in the progress popup and activity list, while Shield -> Private showed as "Send". calling both "Move" would be clearer
合理性
Public→Shield 与 Shield→Private 的自有账户迁移在活动行和详情的主标题已统一为 Move;步骤仍有描述具体阶段的名称。
核实情况
追踪 graph direction、活动行、详情页和 Move 提交后的弹层调用;现有 MV3 无实际 Confidential Move 提交证据。 旧报告的合成交易历史截图可证明展示结果,不能代替真实广播后的完整验收。
根因
旧标题直接按 deposit/withdraw 归类为 Receive/Send,未优先处理 direction=self 的迁移语义。
建议
用 PR82 实际交易记录验收进度弹层与历史行;保留源资产扣减的负号作为金额方向。

当前界面截图

暂无对应场景实拍;原反馈是否仍存在见核实情况。

原始截图

PR81 原反馈 A12 / 图5:Public→Shield 被标为 Receive -2 USDC;与本条同类。原图构建号未提供。
PR81 原反馈 A12 / 图5:Public→Shield 被标为 Receive -2 USDC;与本条同类。原图构建号未提供。
PR81 原反馈 A17 / 图7:历史列表显示 Receive USDC→USDC。
PR81 原反馈 A17 / 图7:历史列表显示 Receive USDC→USDC。
PR82 历史修复后验证图(1 张)
旧报告真实隔离 MV3、受控接口与合成历史:标题 Move。非同一笔交易的前后对比,不证明真实结算。
旧报告真实隔离 MV3、受控接口与合成历史:标题 Move。非同一笔交易的前后对比,不证明真实结算。
代码依据与 PR82 归属(211fb2c)

PR82 d4050e6 改动 multichain-activity-presentation 的 self Shield 标题,并接入 ConfidentialActivitySheet。不要泛化到所有转账类型。

F1-9

主按钮从 Review Cluster 变为 Move

状态待产品确认交互文案缺陷技术已核实路线与按钮变化条件;待产品确认是否统一用户可见命名。
原文
on the Move screen the main button said "Review Cluster" at first, then changed to "Move". not sure what cluster means there
合理性
Review Cluster 仅在 Public↔Private 且方法为 Cluster 时出现,改走 Shield 或 Directly 后主按钮显示 Move;确认页仍有 Cluster transfer/Confirm Cluster。
核实情况
静态核对路线判断、草稿默认方法、切换方法、按钮和确认页。未复现原反馈那一次交互顺序。
根因
主操作文案混入路线方法名,且不同阶段用 Review Cluster、Cluster transfer、Confirm Cluster、Move。
建议
建议统一主操作的 Move/Review 语义,Cluster 仅保留在方法选择中用于区分路线;产品确认命名后再调整。不把明确的路线变化写成无故跳词。

当前界面截图

既有 PR82 Cluster 隔离验证产物:主按钮仍显示 Review Cluster;非本次截图,未作为资金成交证明。源码 c25e375 仍保留此文字。
既有 PR82 Cluster 隔离验证产物:主按钮仍显示 Review Cluster;非本次截图,未作为资金成交证明。源码 c25e375 仍保留此文字。

原始截图

原反馈未附此项截图。
代码依据与 PR82 归属(211fb2c)

PR82 提交版仍保留这些文案,未修复此项。

F1-10

Swap 两个哈希都叫 Base Tx

状态待产品确认交易信息展示缺陷源/目标交易共用链名标签已核实;待产品确认展示角色的方案。
原文
the swap progress screen lists two transactions both labeled "Base Tx". would help to say which is the outgoing one and which is the incoming one
合理性
结果页有 origin 与 destination 两组哈希,但同样只显示链名加 Tx;同链时两行确实可同叫 Base Tx。
核实情况
静态追踪状态解析、SwapStatusDisplay 的两组映射和 TransactionResultPage 调用;没有含两个同链哈希的 MV3 截图。
根因
TxHashLink 接收资产/链/哈希,却没有接收哈希在路线中的角色。
建议
建议使用源交易/目标交易角色加链名;产品确认展示规范后调整。没有逐笔证据时不把源交易一概称为授权,或把目标交易一概称为到账。

当前界面截图

暂无当前界面截图。

原始截图

PR81 原图 C1:源/目标仅标链名 Tx。图中是 Arbitrum/BNB,不是反馈者的 Base/Base;用于核对缺少方向标签的组件。
PR81 原图 C1:源/目标仅标链名 Tx。图中是 Arbitrum/BNB,不是反馈者的 Base/Base;用于核对缺少方向标签的组件。
代码依据与 PR82 归属(211fb2c)

PR82 活动详情的哈希去重不作用于 SwapStatusDisplay 结果页,此项仍未修。

F1-11

输入密码时强度条挤动确认框

状态已确认 Bug,待修复表单布局缺陷提交代码和真实 popup 尺寸的 MV3 测量都确认确认密码字段跳动。
原文
on create password, the strength meter pops in and pushes the confirm field down while you type, so i clicked the wrong spot
合理性
首次输入弱密码使确认框下移 66px,强密码下移 46px,清空后回到原位。
核实情况
375×600 popup MV3 测量前、弱、强、清空四个状态;邀请码服务响应为受控有效值。
根因
密码为空时 PasswordStrength 返回 null,输入后在两个密码字段之间新增有高度的节点。
建议
预留稳定强度区域高度,并复核首次输入及清空时确认框位置。

复现截图

本轮复现 · 输入前,确认框 y=314。
本轮复现 · 输入前,确认框 y=314。
本轮复现 · 输入强密码后,确认框下移46px。
本轮复现 · 输入强密码后,确认框下移46px。

原始截图

原反馈未附此项截图。

本轮验证:PR82 211fb2c · 隔离 Chromium MV3 · 公开测试钱包/受控接口 · 未真实广播。

代码依据与 PR82 归属(211fb2c)

PR82 未改变该表单布局,Bug 仍在。

F1-12

邀请码为空仍可 Continue

状态疑似 Bug,待复现邀请码流程反馈用户反馈的是某安装包现象,但 PR82 门禁开启的实包对空值和空格有双重拦截,当前未复现。
原文
the Continue button on the invite code screen works even with the field empty
合理性
当前按钮对 trim 后空值禁用,submit 同样拦截;MV3 实测空值、全空格与 Enter 均不能继续。
核实情况
BETA_INVITE_REQUIRED=1 的隔离 MV3 页面测试,以及按钮和提交处理源码核对。
根因
在 PR82 代码和已测构建中未找到可跳过空邀请码的路径;历史安装包或其他入口尚无证据。
建议
暂不加重复校验;追溯反馈安装版本和确切入口后再判断是否为旧版本问题。

当前界面截图

本轮核对 · 空邀请码,按钮禁用;回车未跳转。
本轮核对 · 空邀请码,按钮禁用;回车未跳转。
本轮核对 · 仅空格同样无法继续。
本轮核对 · 仅空格同样无法继续。

原始截图

原反馈未附此项截图。

本轮验证:PR82 211fb2c · 隔离 Chromium MV3 · 公开测试钱包/受控接口 · 未真实广播。

代码依据与 PR82 归属(211fb2c)

双重拦截为提交版既有能力,不能写成 PR82 新修复,也不能写成当前可复现。

F1-13

首次入金约一分钟无余额和加载提示

状态疑似 Bug,待复现首次入金等待体验原始首次入金约一分钟未复现,现有进度与受控余额刷新只能缩小问题范围。
原文
after my first deposit it took about a minute for the balance to show up, with no loading hint
合理性
同步中显示 Zcash 进度,无缓存首次加载显示骨架;缓存余额为零且未处于同步状态时,界面可能没有入金待识别提示。受控余额变化在打开的 popup 自动显示。
核实情况
核对后台刷新、同步消息、popup 监听和 Home 展示;MV3 控制 WASM summary 从 0 变 0.25 ZEC,不是真实入金。
根因
原报告缺少链和交易时间点,无法确定延迟在确认、扫描、余额持久化还是业务视图;无证据支持普遍 UI 更新失败。
建议
取得原交易/链并按确认、识别/扫描、缓存落盘、视图更新分段计时,定位后只补当前等待阶段所需反馈。

当前界面截图

本轮受控核对 · 后台更新前,ZEC 为0。
本轮受控核对 · 后台更新前,ZEC 为0。
本轮受控核对 · 无重开/无操作,后台更新后显示0.25 ZEC;非链上入金。
本轮受控核对 · 无重开/无操作,后台更新后显示0.25 ZEC;非链上入金。

原始截图

原反馈未附此项截图。

本轮验证:PR82 211fb2c · 隔离 Chromium MV3 · 公开测试钱包/受控接口 · 未真实广播。

代码依据与 PR82 归属(211fb2c)

211fb2c 的账户选择恢复与入金检测/加载反馈没有直接修复对应关系;不可归因成功。

F2-1

Ledger 添加钱包报 Unauthorized setup sender

状态已确认 Bug,待修复Ledger 连接缺陷首次硬件连接的正式 SPA 路径可触发合法 Ledger 页被 sender 路由校验拒绝。
原文
This ui show up when you want to add a wallet Jemartel.near: I fid kinda oddd
合理性
首次连接从 /hardware/connect 内部跳转到 Ledger 时 sender.url 保留初始无 hash 地址,校验却用它判定当前路由;直接打开 Ledger hash 的已有钱包入口通过这一步。
核实情况
沿 Welcome→全页硬件选择→Ledger 页面→运行时请求追踪,MV3 实测 SPA 路由 Unauthorized、直接路由进入锁定前提错误;无设备。
根因
getOwnExtensionSenderUrl 在所有 URL 均属本扩展后仍优先返回 sender.url,忽略同 tab 更新后的 tab.url hash。
建议
在保留扩展来源及目标路由校验前提下正确使用当前 tab 路由;随后用 Ledger 设备验收连接与创建。

当前界面截图

本轮实际 SPA Ledger 页面。请求返回 Unauthorized 见核实记录;页面截图未显示设备创建报错。
本轮实际 SPA Ledger 页面。请求返回 Unauthorized 见核实记录;页面截图未显示设备创建报错。
对照:直接打开同一路由,通过来源校验后返回钱包未解锁。
对照:直接打开同一路由,通过来源校验后返回钱包未解锁。

原始截图

Feedback 2 图1:Ledger Flex 添加钱包时报 Unauthorized Ledger setup sender;原图未提供版本。
Feedback 2 图1:Ledger Flex 添加钱包时报 Unauthorized Ledger setup sender;原图未提供版本。

本轮验证:PR82 211fb2c · 隔离 Chromium MV3 · 公开测试钱包/受控接口 · 未真实广播。

代码依据与 PR82 归属(211fb2c)

PR82 未修复来源选择;既有直接入口成功不能否定首次连接入口的缺陷。

F2-2

添加账户仍显示旧 Zcash 历史界面

状态已修复,待验收添加账户界面体验Add Account 历史选择已复用统一字段组件且实包看到了新界面;原反馈是主观的 odd,最终体验接受尚未确认。
原文
This ui show up when you want to add a wallet Jemartel.near: I fid kinda oddd
合理性
未知历史时出现 New/Restore,已使用账户要求恢复起点;PR82 统一到 ZcashHistoryFields。隔离 MV3 已观察到选择与日期/区块高度控件。
核实情况
AccountList 条件入口、共用组件、字段验证源码及未知历史的 MV3 弹窗;未创建账户,也未实测已使用历史分支。
根因
旧 Add Account 使用独立界面,与导入恢复流程样式和选择方式不同。
建议
按真实入口验收视觉一致性,并保持历史恢复起点选择;必要时验证已使用账户强制恢复分支。

当前界面截图

本轮当前界面 · 新 Zcash 历史选择面板;受控未知历史。
本轮当前界面 · 新 Zcash 历史选择面板;受控未知历史。

原始截图

Feedback 2 图2:旧 Zcash account history 界面;与旧 D1 同类,原图未提供版本。
Feedback 2 图2:旧 Zcash account history 界面;与旧 D1 同类,原图未提供版本。
PR82 历史修复后验证图(1 张)
旧 D1 真实隔离 MV3:新历史选择底部面板。来自旧报告验证,非本次重新运行。
旧 D1 真实隔离 MV3:新历史选择底部面板。来自旧报告验证,非本次重新运行。

本轮验证:PR82 211fb2c · 隔离 Chromium MV3 · 公开测试钱包/受控接口 · 未真实广播。

代码依据与 PR82 归属(211fb2c)

PR82 d4050e6 将 AddAccountZcashHistoryContent 改为共用 ZcashHistoryFields,属于本 PR 实际修复。

F3-1

App 与 SDK 导出 UFVK

状态待产品确认功能诉求是否做、采用什么方案及优先级,由产品确认。
原文
LiveZEC needs a user's unified full viewing key (UFVK) to scan the chain through Zkool_GraphQL. That's how it picks up incoming transactions with memos and shows them on the overlay. Most users don't know what a UFVK is, and few wallets make it easy to export. Some don't expose it at all. Ask: let users export the UFVK directly through the Noir SDK, so integrations and onboarding are smoother.
合理性
接入入金与 memo 数据的场景可由产品评估;通用 UFVK 导出会授予接收方较广且持续的查看能力,隐私代价明显。技术建议不按该导出方案采纳,而非把它直接列为待实现能力。
核实情况
已逐层核对 SDK 方法/返回类型、dApp 分发、账户详情和硬件 provision 权限边界;未验证 LiveZEC/Zkool 实际接入。
根因
公开 SDK、dApp 方法分发及账户详情均未提供 UFVK 导出。内部硬件流程只接收设备提供的 UFVK,并限制为扩展页面调用;它不是供 dApp 使用的导出接口。复制出的查看密钥无法通过断开 dApp 连接收回。
建议
请产品确认 LiveZEC 最少需要哪些入金与 memo 数据、给谁查看、保留多久。技术建议不提供通用 UFVK 导出;先评估明确授权、按需分享交易数据的方案。

当前界面截图

暂无对应功能界面;本项为待评估诉求。

原始截图

原反馈未附此项截图。

权限依据:Zcash ZIP 316:Viewing Key / Full Viewing Key。断开连接无法回收已复制的密钥,是据此权限模型作出的判断。

代码依据与 PR82 归属(211fb2c)

211fb2c 无公开 UFVK 导出流程;内部硬件 UFVK 注册不能视作 SDK 已支持。

F3-2

用 seed 登录繁琐

状态使用问题,待说明使用疑问已支持本机密码解锁;需澄清反馈指日常解锁、导入恢复,还是 LiveZEC 登录。
原文
Logging in with recovery seeds is clunky. A more direct login method would improve UX.
合理性
日常 Noir 解锁已经不需要 seed;若是第三方服务要求助记词,不能通过更方便提交助记词来优化。
核实情况
已追踪 ImportWalletPage、UnlockForm 和 SDK connect 三条实际路径;当前日常解锁不需要助记词,未观察到原反馈的反复 seed 登录。
根因
导入恢复页校验助记词,日常 UnlockForm 调用本机密码解锁;SDK connect 授权已有账户,并不替代 LiveZEC 自身登录。原文没有指出哪个页面在要求 seed。
建议
先在反馈所指页面区分首次导入、日常解锁与 LiveZEC 登录;若日常解锁反复要求 seed,再作为流程缺陷定位。不得将助记词传给 dApp。

当前界面截图

暂无当前界面截图。

原始截图

原反馈未附此项截图。
代码依据与 PR82 归属(211fb2c)

本机密码解锁原已支持,并非 PR82 新增。是否反馈 LiveZEC 登录仍需明确,不能按钱包解锁直接关闭。

F3-3

用 viewing key 添加 Zcash 账户并接入登录

状态待产品确认功能诉求是否做、采用什么方案及优先级,由产品确认。
原文
Michae2xl suggested Noir could handle both login and adding a Zcash account via viewing key.
合理性
观察账户导入、钱包解锁和 dApp 登录是三种不同能力;viewing key 可被分享,不能当然作为账户控制权证明。
核实情况
已核对 SDK、Keystone 扫码、消息权限和硬件账户创建调用链;没有执行 LiveZEC 登录或通用观察账户导入。
根因
SDK connect/getAccounts 只授权或读取已有账户。Keystone 的设备扫码流程会经扩展专用消息注册硬件观察账户;没有证据表明这等同于任意 viewing key 导入或 dApp 创建账户能力。查看密钥本身也不证明账户控制权。
建议
请产品明确是 dApp 登录、只读账户导入还是设备账户注册,再评估权限与流程;不要用查看密钥直接充当登录身份凭据。

当前界面截图

暂无对应功能界面;本项为待评估诉求。

原始截图

原反馈未附此项截图。
代码依据与 PR82 归属(211fb2c)

PR82 已提交变更未覆盖该诉求;不代表已复现此问题。

F3-4

确认等待与余额可用时间

状态使用问题,待说明确认口径与等待体验通常3确认且扫描完成后可用;10确认用于收款记录/结果完成。当前未证实等待10确认才能转账。
原文
Confirmation times are long (3x for sending, 10x for receiving). Can they be shortened?
合理性
应区分余额何时可用和收款记录何时显示完成。代码已按3确认查询可用余额与选币;缩短等待诉求需结合真实链上和扫描耗时判断,不能把结果仍在 Confirming 等同于资金不能花费。
核实情况
375×600真实隔离扩展页面已实拍:受控RPC分别返回3与10确认,目标步骤从 Confirming 变为 Completed,底部从 View Activity 变为 Done。页面未显示具体确认数,也未显示“再等7块才可花费”。测试使用合成结果记录,诊断副本仅暴露现有状态及路由入口,未修改结果渲染或确认逻辑、未广播交易。截图不证明真实入金耗时或3确认花费已实测。
根因
余额查询与交易选币使用3/3确认策略,外部收款记录和ZEC目标结果页使用10确认完成口径。普通 Swap 结果页只显示分步状态,showStatus=false 会隐藏状态标题与说明;因此文案函数生成的“再等7块才可花费”在这个页面并未展示。
建议
说明3确认可用与10确认记录完成的区别。若实际可用余额仍迟迟不更新,由技术分段核对打包、确认、扫描和界面更新耗时;当前不按已确认文案Bug安排修复,也不直接降低确认数。

当前界面截图

受控RPC返回3确认:Destination transfer 显示 Confirming,底部为 View Activity。页面未显示确认数,也未显示“再等7块才可花费”。
受控RPC返回3确认:Destination transfer 显示 Confirming,底部为 View Activity。页面未显示确认数,也未显示“再等7块才可花费”。
受控RPC返回10确认:Destination transfer 显示 Completed,底部变为 Done。同一版本的状态对照,不是修复前后图。
受控RPC返回10确认:Destination transfer 显示 Completed,底部变为 Done。同一版本的状态对照,不是修复前后图。

原始截图

原反馈未附此项截图。
代码依据与 PR82 归属(211fb2c)

211fb2c 已使用3/3 WASM策略,保留10确认收款/结果完成口径。本轮普通结果页实拍未展示此前指出的文案,未确认可见文案故障;NU7官方目标出块间隔为25秒。

WASM 清单源版本 cb8da9d:查询与选币策略。已核对对应源码与包装接口,未在本轮重新构建 WASM。

NU7 官方发布说明:25秒目标间隔 · ZIP 218

截图验证记录

公开测试钱包与合成结果数据,未广播交易;诊断副本仅增加现有状态和路由访问入口。

渲染条件:SwapStatus 的 showStatus;TransactionResult 的条件渲染。

F3-5

关闭再打开 popup 才更新余额

状态疑似 Bug,待复现缺陷线索本轮未复现必须重开窗口;原扫描/多账户时序仍需对应场景。
原文
The balance sometimes doesn't sync until the pop-up is closed and reopened.
合理性
保持 popup 打开却无法及时显示已更新余额,不符合已有同步预期;若属实是缺陷。
核实情况
代码已追到扫描→summary→账户映射→缓存→消息→UI。既有诊断包把单次 summary 替换成0.25 ZEC,打开的 popup 自动更新;它跳过真实入金扫描和多账户选择,不能证明原故障已修复。
根因
扫描后后台读取 WASM summary,映射账户、更新缓存并发送 SYNC_PROGRESS;已打开的 popup 按网络/钱包/账户接收。211fb2c 修复注册多账户后未恢复 WASM 选中账户的问题,是可能相关的上游修复,但尚未证明与这条反馈同因。
建议
技术继续按同一账户的扫描高度、WASM 当前账户、缓存与消息时间戳定位真实扫描/后台重启时序;保留本轮传播检查作为局部证据,不再以它代替原故障复现。

当前界面截图

本轮受控核对 · 后台更新前,ZEC 为0。
本轮受控核对 · 后台更新前,ZEC 为0。
本轮受控核对 · 无重开/无操作,后台更新后显示0.25 ZEC;非链上入金。
本轮受控核对 · 无重开/无操作,后台更新后显示0.25 ZEC;非链上入金。

原始截图

原反馈未附此项截图。

本轮验证:PR82 211fb2c · 隔离 Chromium MV3 · 公开测试钱包/受控接口 · 未真实广播。

代码依据与 PR82 归属(211fb2c)

211fb2c 已提交多账户注册后的 WASM 账户选择修复;与原 popup 余额不刷新是否同因,尚未证实。

F3-6

Keystone 是否支持

状态使用问题,待说明使用疑问已支持部分 Keystone 链与操作;需向产品说明支持范围,不等于全部操作均支持。
原文
Asked about Keystone support, a viewing key option, and security features other wallets offer that Noir doesn't.
合理性
已有 Keystone 支持;泛泛询问不构成新增开发需求。
核实情况
已交叉核对固件链映射、启用链过滤、凭据校验、签名适配与运行时拦截;本轮没有设备实测。
根因
Keystone 已有入口,但可选链由固件类型、发布开关、凭据能力和链适配器共同决定。Zcash 走硬件 PCZT;Keystone 的透明资金来源受限,消息签名与 lending 身份方法也不能按软件钱包能力承诺。
建议
先明确要使用的链与操作,再给出该组合支持结论及设备验收结果;viewing key 诉求分别见 F3-1/F3-3,不与硬件覆盖混在一起。

当前界面截图

暂无当前界面截图。

原始截图

原反馈未附此项截图。
代码依据与 PR82 归属(211fb2c)

部分 Keystone 支持为既有功能;仅在链注册表或固件列表出现,不能证明该操作已可交付。

F3-7

其他钱包拥有的安全功能

状态待产品确认模糊诉求是否做、采用什么方案及优先级,由产品确认。
原文
Asked about Keystone support, a viewing key option, and security features other wallets offer that Noir doesn't.
合理性
没有功能名称、威胁场景和对比对象,无法判断合理性或必要性。
核实情况
已核对上述现有安全入口;因为原文未指明对象,无法对所谓“缺少的功能”作实测。
根因
原文没有具体安全功能、对比钱包版本或威胁场景。当前代码有密码解锁、自动锁定及安全设置,但这些事实不能证明与其他钱包功能相同,也不能据此认定缺陷。
建议
产品与市场补充具体功能、对比对象和使用风险后再决定;不凭笼统“更安全”承诺新增功能。

当前界面截图

暂无对应功能界面;本项为待评估诉求。

原始截图

原反馈未附此项截图。
代码依据与 PR82 归属(211fb2c)

PR82 已提交变更未覆盖该诉求;不代表已复现此问题。

F3-8

像 MetaMask 一样固定扩展

状态使用问题,待说明使用疑问已有侧边栏模式;工具栏固定属于浏览器操作,需先确认反馈指哪一种。
原文
Proposed making the extension pinnable, like MetaMask. Michae2xl liked the idea.
合理性
工具栏固定通常是浏览器能力,常驻则可能是已有侧边栏模式;不能直接记成 Noir 缺功能。
核实情况
已追踪 manifest、Settings 的 Sidebar 开关以及后台展示模式切换;未操作反馈者浏览器的固定状态。
根因
需区分三个不同操作:浏览器工具栏固定扩展图标、Settings→Sidebar 常驻侧栏、钱包内账户 Pin to top。扩展 manifest 已声明 toolbar action 和 side_panel;侧栏开关实际改变扩展展示方式。
建议
若指工具栏图标,说明浏览器扩展菜单中的固定操作;若指常驻钱包,使用 Settings→Sidebar。账户 Pin to top 只影响账户顺序。

当前界面截图

暂无当前界面截图。

原始截图

原反馈未附此项截图。
代码依据与 PR82 归属(211fb2c)

工具栏入口和 Sidebar 为当前已有功能,并非 PR82 新增;没有证据表明 Noir 本身不能被固定。

完整原文与补充材料

Feedback 1

1. no way to pay gas on the Private account. it starts with 0 ETH, so my first swap there failed with "Insufficient native balance", and i only found out after clicking Swap. the obvious fix is sending ETH from Public, but that links Public and Private on-chain which kinda defeats the point. i ended up moving ETH Public -> Shield -> Private by hand to keep them separate. would be great to have gas paid in USDC, or a one-click "top up gas via Shield", and at least show the warning before i hit Swap
2. when moving Shield -> Private, picking the token silently changed the destination from Private to Public. i caught it before confirming, but someone could easily send their Shield funds back to Public without noticing
3. in the token picker, the list keeps reshuffling while it says "Searching more networks...". i clicked ETH on Base and it selected ETH on Arbitrum because the rows moved under my cursor
4. the Move screen sometimes preselects the right token on the wrong chain. e.g. it picked USDC on a chain where i have 0, so it showed "0 Max", even though my USDC was on Base. both look identical so for a sec i thought my funds were gone
5. the asset list under the Public tab shows the total across Public + Shield + Private, not just Public. my USDC showed 4.49 when Public only had 3 (the rest was 1 in Shield and 0.49 in Private). i thought the balance was stuck until i checked on-chain
6. when i opened Swap from the Private tab, the "From" was set to Zcash Shield with ZEC (0 balance) instead of my Private account. had to change both the token and the account manually
7. the seed confirmation step (pick the 3rd and 10th word) shows all 24 words in plain text, just shuffled. the screen right before it blurs them, so this one kinda undoes that
smaller stuff:
- the same kind of action gets different labels. my Public -> Shield move showed as "Receive -2 USDC" in the progress popup and activity list, while Shield -> Private showed as "Send". calling both "Move" would be clearer
- on the Move screen the main button said "Review Cluster" at first, then changed to "Move". not sure what cluster means there
- the swap progress screen lists two transactions both labeled "Base Tx". would help to say which is the outgoing one and which is the incoming one
- on create password, the strength meter pops in and pushes the confirm field down while you type, so i clicked the wrong spot
- the Continue button on the invite code screen works even with the field empty
- after my first deposit it took about a minute for the balance to show up, with no loading hint
moving between Public, Shield and Private plus a swap on Private all went through fast and landed as estimated, and the confirm screens are really clear. works very well in Brave
haven't tried some of the other features yet, but will do when i find more time
thanks again for the invite, hope this is helpful!

Feedback 2

[截图1][截图2]
Jemartel.near:
This ui show up when you want to add a wallet
Jemartel.near:
I fid kinda oddd

Feedback 3

Main pain point: UFVK setup
LiveZEC needs a user's unified full viewing key (UFVK) to scan the chain through Zkool_GraphQL. That's how it picks up incoming transactions with memos and shows them on the overlay.
Most users don't know what a UFVK is, and few wallets make it easy to export. Some don't expose it at all.
Ask: let users export the UFVK directly through the Noir SDK, so integrations and onboarding are smoother.
LiveZEC recommends users create a fresh wallet just for LiveZEC.
Login
Logging in with recovery seeds is clunky. A more direct login method would improve UX.
Michae2xl suggested Noir could handle both login and adding a Zcash account via viewing key.
Feedback on Noir's current wallet
Confirmation times are long (3x for sending, 10x for receiving). Can they be shortened?
The balance sometimes doesn't sync until the pop-up is closed and reopened.
Noir's follow-ups
Asked about Keystone support, a viewing key option, and security features other wallets offer that Noir doesn't.
Proposed making the extension pinnable, like MetaMask. Michae2xl liked the idea.
Action items for Noir: UFVK export (in the app and SDK), simpler login, faster confirmations, a fix for the balance sync bug, and a pinnable extension.
[截图1]

原文附图:密钥原理图,不是钱包故障截图。

原文附带的密钥原理图