ERC-8085: Dual-Mode Fungible Tokens

[zero]

@HenryRoo

Hey hey, gorgeous privacy proposal, lol an amazing comment about VPN @aliceto, there is lack of something like this, secure privacy layer / mode like this one in proposal.

I’m also trying to better understand how this standard interacts with real-world compliance and “source of funds” checks.

In the ERC-20 world, on-chain analytics providers can reconstruct transaction graphs and help regulated entities assess the cleanliness of incoming funds. With ZRC-20, once assets are shielded, this transaction graph becomes opaque to everyone except the holder and parties who are explicitly given a viewing/auditing key.

A few related questions:

1. Am I correct that, for third parties without a viewing/auditing key, it is effectively impossible to perform a traditional on-chain source-of-funds analysis once assets are inside the ZRC-20 privacy layer, beyond tagging deposits/withdrawals that touch the pool?
2. Do you expect regulated exchanges or frontends that integrate ZRC-20 wrappers to require users to share viewing/auditing keys as a condition for deposits and withdrawals? If so, have you explored how this would work in practice (UX, key management, revocation, etc.)?
3. Are you considering any standardized zk-compliance primitives on top of ZRC-20 (for example, proofs of the form “these funds do not originate from addresses on a sanctions list” without revealing the full transaction path), or is this intentionally left entirely to higher-layer protocols?
4. From a regulatory-risk perspective, how do you see native privacy assets being treated differently from classic mixer designs, given that for third parties without keys the observable pattern still looks like “funds enter a shielded pool and later exit with unlinkability”?

I really like the idea of standardizing privacy primitives, but I’m curious how you envision the balance between strong privacy for users and the ability of compliant actors to perform meaningful source-of-funds checks in practice.

third parties without a viewing/auditing key, Once funds enter the privacy layer, tracing their provenance becomes inherently difficult. Private assets are not tied to any Ethereum account address, and any address that interacts with the privacy contract cannot be treated as a reliable indicator of ownership. Such an address might be a relayer, or simply another unrelated address that has no correlation with the actual user.

The proposal itself is intentionally scoped as an interface-level standard, rather than prescribing any concrete implementation or enforcement logic.
It defines how privacy addresses are expressed and interoperated, without constraining how individual projects choose to realize them.

This separation allows different implementations and client layers to adopt compliance-aware behaviors in ways that align with their local regulatory environments, while keeping the underlying protocol fully permissionless and minimal.
Enabling this kind of flexibility at the client and integration layer is one of the core design motivations behind ERC-8091.