This frames soundness risk as borne by the registering user. That only holds if a note is cryptographically bound to a single auth verifier.
In EIP-8182, soundness risk caused by a buggy or malicious auth verifier is only borne by the registering user, but not because notes are bound to a specific verifier.
The reason is that every spend must pass two independent gates.
The first gate is the fork-managed “pool proof.” This is the pool soundness layer. It proves the transaction is a valid shielded-pool state transition:
- The inputs are real notes in the tree
- The corresponding nullifiers aren’t already consumed
- Value is conserved between inputs and outputs.
A user-selected auth verifier cannot relax any of those constraints.
The second gate is the “auth proof.” This proof answers whether the selected auth method authorizes this particular transaction intent. It is a per-user authorization gate layered on top of the pool soundness gate enforced by the pool proof.
So even if an auth verifier is maximally broken and returns true for everything, it cannot print money, spend non-existent notes, bypass nullifiers, or violate value conservation. What it can do is make authorization too permissive for only those users who opted into that verifier.
Concerning the real aim, merging the pools, there are many signals that leaks which leaf belongs to which circuit
I agree, my point is just that these signals aren’t materially exacerbated by EIP-8182’s approach to authorization relative to the risks present in all shielded pools of this sort.
That said, it would certainly be better else-equal to not leak the auth method used for a given shielded transaction. But I can’t see a way to do that aside from either (a) forcing every tx to use the same auth method or (b) recursively verifying the auth proof in the pool proof.
Both of these I found less palatable than the current approach (though an earlier version of EIP-8182 did use the recursive approach, but the complexity was not worth it).