I rewrote the draft and now many of my earlier comments in this thread are no longer accurate! Here are the changes:
1. Recursive auth is now the v0 architecture.
I previously argued for a monolithic v0 and a later hard fork into recursion. I no longer think that is the right trade. I now think it is important not to require repeated hard forks for new auth methods, and not to split the anonymity pool by auth method.
2. The old synthetic-intent / Privacy RPC framing is gone from the spec.
I still think delegated proving and a Privacy-RPC-style UX are useful, but they do not belong in the base protocol. The draft still supports third-party proving; it just no longer bakes a specific delegated-proving UX into the protocol.
The only concrete auth flow in the spec is a simpler ECDSA / EIP-712 example, and that is just an example companion auth circuit, not the protocol’s required signing scheme.
3. Labels are narrower now.
Labels are no longer presented as a full proof-of-innocence / compliance system. They are a limited lineage primitive in the base layer. This feature can be extended in the future.
4. Issuer-specific visibility is out of the base draft.
I still think compliance-related extensions may matter, and I’m open to adding something back if we get clearer requirements. But issuer visibility felt too underspecified to enshrine now, especially without better evidence about what issuers actually want from the feature.
The rationale and security sections were also rewritten heavily, so a lot of the earlier discussion about synthetic transaction UX, circuitId, hard-forking in new auth methods, labels, and issuer visibility is now stale.
So if you read the thread from the top, please treat many of my earlier replies as superseded by the current draft.
Thanks again for your feedback! You showed me the error of my ways and the EIP is stronger because of it!
Updated PR: Add EIP: Protocol-Enshrined Privacy Pool by RogerPodacter · Pull Request #11373 · ethereum/EIPs · GitHub