ERC-8085: Dual-Mode Fungible Tokens

ERCs
, , , ,
23

Noob question, whats different with Railgun?

24

Hi @zk-friendly
Railgun is a full, end-to-end product, while ERC-8086 and ERC-8085 are mainly about interface standards. They focus on what the primitives look like, not on prescribing a specific implementation.

If you’re asking how our reference implementation differs from Railgun, here’s where you can dig deeper:

If you’re not very code-oriented, the easiest way is to try what we’ve already deployed on testnet — anyone can experiment and verify things directly:

  1. Anyone can create native privacy assets with a Zcash-style privacy model, as easily as creating an ERC-20 token:
    https://testnative.zkprotocol.xyz/

  2. Anyone can wrap ETH or any existing ERC-20 into a privacy asset and gain privacy features:
    https://zerolayer.live/

  3. Anyone can easily create dual-mode tokens (privacy + ERC-20 public mode), just like creating an ERC-20. Users can freely switch between private and public modes depending on their use case:
    https://testdmt.zkprotocol.xyz/

ERC-8086, ERC-8085, and ERC-8091 are better understood as a modular privacy layer for Ethereum. They’re designed as building blocks — anyone can use them to build their own privacy products on top.

4 Likes
25

Your design is 100% same with railgun, shield and unshield, dual mode. but the utxo design is not good for UX

26

I intentionally tried out several different privacy solutions, and honestly the UX is way better than I expected.

The only downside right now is that you have to experience it on your own testnet. If wallets supported this protocol natively, it would be amazing to let users switch between privacy mode and public mode directly in the wallet with a simple toggle.

At that point, using privacy would feel just as easy as interacting with a regular ERC-20 token.

I’d strongly suggest providing an SDK so wallets can integrate this more seamlessly.

27

Thanks for the suggestion — we’ve been thinking along the same lines as well.

28

I’m about as much of an outsider to this topic as one can be, but after reading through your proposal, would it make sense to reserve+standardize an address that “owns” the private tokens? balanceOf(PRIVATE_ACCOUNT) would be equivalent to totalPrivacySupply().

I’d also recommend specifying whether a Transfer event is emitted for toPrivacy and toPublic.

Also also, toPrivacy is weird English, IMHO. toPrivate sounds more natural.

29

Thanks for the thoughtful feedback!

Re: PRIVATE_ACCOUNT for private balances

We considered this approach but decided to stay with the burn/mint pattern for mode conversions:

  1. Semantic clarity: When tokens enter privacy mode, they are cryptographically transformed into commitments - they don’t “exist” as ERC-20 balances anymore. Using burn/mint better reflects this transformation.

  2. Supply tracking: We explicitly track totalPrivacySupply() which is maintained through mode conversion operations. This provides clear visibility without needing a special account.

  3. Avoiding confusion: A PRIVATE_ACCOUNT that “holds” tokens but can never actually transfer them (except through ZK proofs) might be conceptually misleading.

Re: Transfer events for toPrivate/toPublic

Adopted. The spec now requires:

  • toPrivate(): MUST emit Transfer(account, address(0), amount)
  • toPublic(): MUST emit Transfer(address(0), recipient, amount)

Re: toPrivacy → toPrivate

Thanks again for the review!

30

I would argue that because:

  • totalSupply() MUST return the sum of all public balances plus totalPrivacySupply()

then the private tokens are not burned.

31

Sorry, I may not have explained this clearly, and perhaps I didn’t fully understand your question at first.

totalSupply() MUST return the sum of all public balances plus totalPrivacySupply().

Why is this necessary?

The core of token privacy lies in hiding holders, hiding balances, and hiding transfers. This kind of privacy is primarily about individual-level data and interactions — users need privacy at the personal level.

However, when it comes to totalSupply, we believe it should be intentionally designed to be public and accurate. totalSupply is a system-wide, collective metric, and it is highly valuable to all holders. Users should be able to clearly understand the overall state of the system: what the current total supply is, and how many tokens are in a privacy state.

This visibility helps prevent scenarios where tokens in the privacy state could be minted without bounds without users being aware.

The purpose of totalPrivacySupply() is to provide a public aggregate statistic for tokens that are currently in the privacy state, completing the system-level view described above. Tokens counted in this value are not burned; it represents an accurate and effective total amount of tokens currently held in privacy mode.

This value is not associated with any specific address. Instead, it represents tokens held collectively via commitments by many users. These holders are untraceable, forming a strong privacy environment where holders, balances, and transfers are all hidden.

32

You explained correctly, I think!

My argument is that if:

  • toPrivate/toPublic are analogous to burn/mint, and
  • minting/burning tokens modify the totalSupply

Then:

  • toPrivate / toPublic should decrease or increase the totalSupply respectively.

Otherwise, you’re not being consistent and treating toPrivate/toPublic as halfway between a transfer and a mint/burn.

I don’t think it’s any weirder than an external contract holding tokens. As far as observer is concerned, the tokens move in and out with Transfer events like any other account. permit-style interactions don’t screw anything up, and they’re essentially the same thing (except with ecrecover instead of a zk proof).

I actually find treating privacy operations as mint/burn to be more confusing. From an indexer’s perspective, how do you differentiate a mint/burn Transfer event from a privacy one?

33

On a completely separate note, how do dual-mode tokens fix this:

  • :cross_mark: Splits liquidity between public and wrapped versions

?

Not a criticism, I just don’t know how that works and am curious!