ERC-8290: Shielded Note Teleportation

ERCs
, ,
1

Hi everyone,

I am proposing a new ERC standard that I would greatly appreciate feedback on.

While experimenting with improvements and other ways to apply the concept of zkwormholes from EIP-7503, I discovered a way for it to enable interoperability between privacy protocols, even existing ones such as Tornado Cash, 0xbow’s Privacy Pools and Railgun. Users can move assets from one privacy protocol to another without publicly withdrawing and re-depositing. This is achieved by the user creating a note in the source pool bound to an unspendable address which then can be imported into a destination protocol by verifying that the burn commitment is included in source pool.

This ERC is meant to standardize this for any privacy protocol on the application level to implement it and be interoperable with others.

Interesting benefits as a result:

  • Positive-sum privacy sets - teleporting shielded notes across privacy protocols increases the privacy set of the destination pool without reducing the privacy set of source pool. New privacy protocols that implement it can, in essence, inherit the anonymity of larger existing privacy protocols.
  • Backwards-compatibility - it is possible to teleport notes from existing privacy protocols without them needing to upgrade. Though, it does introduce other considerations since its burning a note and effectively locking the asset value of that note inside the pool. The risk of that can be mitigated if the pool upgrades to support imports or there is some other solution implemented in the asset contract.
  • Cross-chain possibility - the unspendable “burn” address is a hash bounded to destination pool address and chain ID to prevent replay attacks, but as a byproduct, can support cross-chain note teleportation as well depending on the canonical tree the destination pool relies on. This means users can move assets cross-chain from one privacy protocol (or privacy chain) to another without utilizing a bridge.

Another thing to mention is that the burn address can be 32-bytes instead of only 20-bytes since most privacy pools do not place that same restriction as Ethereum on addresses. This allows it to be more secure and collision-resistant, but that is not guaranteed and depends on the implementation of destination pool. This technically can even support regular EIP-7503-style zkwormholes from public transfers if destination pool allows it, which is why I say it depends.

Last thing I would like to mention is compliance. If desired or obligated, privacy protocols can implement compliance measures when importing teleported notes from other privacy protocols. For example, the destination pool may use an Association Set Provider (ASP) like 0xbow to screen teleported notes of illicit funds originally deposited into Tornado Cash. This standard does not delve into that but I did want to mention it is not mutually exclusive to compliance. However, an unintended consequence is that it may also enable bypassing some forms of existing compliance enforcement if teleporting the note to a destination pool that does not place the same enforcement as the source pool. It is up to the destination pool to choose to honor the source pool’s compliance requirement or require their own, if any.

Although there are some risks to consider, some that are not too entirely different from bridges, I think this can greatly benefit all privacy protocols and increase privacy for all.

Link: ERC-8290: Shielded Note Teleportation

2

Fun idea, but shielded pools custody the actual ERC-20s. So the tokens have to move with the note. Otherwise the destination pool owes real assets against value it doesn’t hold. Which means the source needs an export path that releases the assets on proof of burn. So the claim “without them upgrading” doesn’t really work.

We hit the same wall when working on murk.finance for cross-chain private transfers. The note leg is the easy part (proving a commitment exists somewhere else). But the token part is where it fails. Only solution is to give the destination pool a mint authority on a token it doesn’t control, which is not possible…

So… no good answer yet on our side either :blush: The only correct solution for now is withdraw-and-redeposit. So there’s a leak, but at least the pool is solvent.

4

I believe there are actually a few solutions to handle the actual asset. Fundamentally similar issue managing the liquidity of an asset on different chains, which is why said its not entirely different from bridges. We can apply similar concepts from bridge solutions to this ERC.

2 possible options with or without existing privacy protocols upgrading:

  1. Yes, can give destination pool minting authority of a wrapped version. Wrap the token before depositing into source pool, teleport and it mints on transfer if destination pool holds less than amount being withdrawn. Then user can always unwrap and claim the original asset. The wrapped token implementation would just need to restrict which pools it mints for. (Or if the token is upgradeable, the owner can upgrade it to do this directly without user needing to wrap it)

  2. On withdrawal from destination pool, mint a new token bERC20 of same amount to represent 1:1 value to burnt asset from source pool like worm.cx does. User can then swap bERC20 for ERC20 if they want. Also kind of like Hop protocol for a similar concept bidirectionally.

Another option can be a pool/network of liquidity providers that fulfills the needed asset amount to withdraw from destination pool. I can only see this option working if both source and destination privacy pools accept importing each others’ teleported notes.

These need to be explored more, but I am optimistic we can do more than just settle for withdraw and redeposit tokens.