Thanks for the thoughtful questions — they touch exactly the design boundary we’ve been very deliberate about with ERC-8086.
Our intent with ERC-8086 is to define a minimal, native privacy primitive at the token level, rather than standardizing a full privacy protocol or prescribing a concrete ZK system. This is very much a “minimal interface, maximal freedom” design.
Circuits & verifiers
The absence of circuits and generated verifier contracts in the reference repo is intentional.
ERC-8086 is not meant to canonize a specific circuit family. Doing so would effectively turn the ERC into a full product specification, which would dramatically raise the implementation bar and exclude many existing or future designs. Instead, the ERC defines what a token must expose, not how privacy is achieved internally.
Projects are free to:
- generate verifiers off-repo,
- use different proving systems,
- upgrade circuits over time,
as long as they conform to the interface.
This also means that systems like Railgun could adopt ERC-8086 naturally, without refactoring their circuit architecture.
the circuits used in our reference implementation are planned to be open-sourced in the near future.
They are intended as a reference and starting point, not a mandatory target: anyone will be free to reuse them directly or adapt them to build their own ERC-8086–compatible implementations.
Recipient keys & wallet interoperability
look this ERC-8091: Privacy Address Format