提款证明失败，先别急着怀疑是钱包出了问题。Privacy Pools 的提款需要同时满足多层链上验证，任何一层没对上都会失败。下面这 4 项数据，按顺序检查，能帮你定位大部分失败原因。
第 1 项：状态树根——你的存款还在树上吗
提款证明必须证明你的存款承诺（commitment）当前存在于状态树（State Tree）里。这棵树是增量且只增不减的：存款时加入叶子，提款时消耗对应的 nullifier，但叶子本身仍保留在树上。
做什么：确认你提款时使用的状态树根（stateRoot）还没过期。
怎么做：去区块浏览器查一下你最近一笔存款的交易确认时间。Privacy Pools 合约会记录最近几个状态树根，提款证明里绑定的状态树根必须是合约认可的那几个之一。如果你拖太久才提款，状态树根已经滚动到了新的版本，你的证明会直接失效。
完成标准：找到合约里记录的"最近 N 个状态树根"列表，确认你证明里用的那个树根还在列表里。
第 2 项：关联集树根——ASP 的版本对上了吗
提款证明除了证明"钱是我的"，还得证明"这笔存款是干净的"——也就是属于关联集提供者（ASP）发布的那个合规集合。
做什么：确认你证明里用的关联集树根（aspRoot）是 ASP 当前发布的最新版本。
怎么做：ASP 会定期更新关联集（比如拉入新的合规地址、剔除新发现的非法地址），每次更新都会发布一个新的树根并上链。你的提款证明里绑定的 aspRoot，必须和合约里当前记录的 ASP 树根一致。
完成标准：去 Privacy Pools 的 dApp 界面或区块浏览器，查一下当前 ASP 树根，和你生成证明时用的那个对一对。
第 3 项：context 绑定的"处理人"——防止别人抢你的提款
Privacy Pools 的提款电路里有一个叫 context 的公开信号，它会把提款参数（收款地址、费用等）"绑"进证明里。合约验证时，会检查交易的发送方（msg.sender）是不是 context 里绑定的那个处理人（processor）。
做什么：确认你的提款方式（直接提款还是中继提款）对应了正确的 processor 地址。
怎么做：
- 如果你用的是直接提款（自己付 Gas），processor 应该是你自己的钱包地址。
- 如果你用的是中继提款（Relayer 代提交），processor 应该是 Entrypoint 合约的地址。
如果这个对不上，合约验证会直接回滚。
完成标准：打开你的提款交易记录，确认发送方地址和证明里绑定的 processor 是同一个。
第 4 项：nullifier——别重复花同一笔钱
每笔存款都有一个唯一对应的 nullifier（零知识证明里的"销毁凭证"）。提款时，这个 nullifier 的哈希值（nullifierHash）会公开上链，标记这笔钱已经被花掉了。
做什么：确认你这次提款用的 nullifier 还没有被消耗过。
怎么做：去合约的 nullifier 映射表里查一下，你的这笔存款对应的 nullifierHash 是不是已经被记录过了。如果已经被记录了，说明这笔钱之前已经提过，不可能再提第二次。
完成标准：在合约的 nullifier 列表里，找不到你这个 nullifierHash 的记录。
操作完成的校验方式
把这 4 项都过一遍之后，重新生成一次提款证明并提交。如果成功了，说明问题出在刚才排查的某个环节。如果还是失败，去区块浏览器查这笔失败交易的具体 revert 原因，通常能直接告诉你哪个条件没满足。
