Alert Source Discuss
⚠️ Draft Standards Track: Core

EIP-7503: Zero-Knowledge Wormholes

Enable minting of secretly burnt Ethers as a native privacy solution for Ethereum

Authors Keyvan Kambakhsh (@keyvank), Hamid Bateni (@irnb), Amir Kahoori <>, Nobitex Labs <>
Created 2023-08-14
Discussion Link


While researching on privacy solutions and applications of ZKP, we discovered a technique, by which people can burn their digital asset (E.g ETH) by sending it to an unspendable address, and later build a ZK proof showing that some amount of tokens has been burnt in a transaction in an older block, without revealing the transaction. The EIP proposes to add a minting functionality to Ethereum, so that people can re-mint Ethers that they have purposefully burnt. This will make an anonymity pool of the size of the entire Ethereum blockchain without much hassle.


In Elliptic-Curve based digital signatures, normally there is a secret scalar $s$, from which a public-key is deriven (By multiplying the generator point with the scalar: $s \times G$)

A public-key is spendable if and only if its corresponding private-key $s$ exists. We can generate unspendable public-keys by generating random points on the curve. But how can other people be sure that a point is indeed random and not the result of calculating $s \times G$?

A great source of randomness is a hash function. If the public-key is the hash of a secret preimage $s$, we can conclude that the public-key is unspendable, since there isn’t a polynomially bounded algorithm to find $r$ where $g^r=h(s)$.

Using the help of Zero-Knowledge proofs, we can hide the value of $s$! We just need to prove that we know a secret value $s$ where the public-key is $H(s)$. We can go even further. We can prove that some EOA-to-EOA transaction has happened in the history of blockchain, which has burnt some amount of ETH. By revealing this to the Ethereum blockchain and providing something like a nullifier (E.g. $h(s | 123)$ so that double minting of same burnt tokens are not possible), we can add a new minting functionality for ETH so that people can migrate their secretly burnt tokens to a completely new address, without any trace on the blockchain. This will make an anonymity pool of the size of the entire Ethereum blockchain without much hassle.


Cryptocurrency mixers like TornadoCash can successfully obfuscate Ethereum transactions, but it’s easy for the governments to ban usage of them. Anybody who has interactions with a mixer contract, whether the sender or receiver, can get marked. However this EIP tries to minimize the privacy leakage of the senders, by requiring zero smart-contract interactions in order to send money, so we only use plain EOA-to-EOA transfers. In order to have a “teleportation” mechanism we divide the set of all Secp256k1 points $E(K)$ into two subsets/address-spaces:

  • The spendable address-space: $\{p \in E(K) \exists s : g^s=p\}$
  • The unspendable address-space: $\{p \in E(K) \nexists s : g^s=p\}$

The spendable/unspendable addresses are not distinguishable, so we can exploit this fact and define a spendability rule for the money sent to addresses that can’t be spent using regular elliptic-curve signatures. Using the help of Zero-Knowledge proofs, we can hide the transaction trace and design a new privacy protocol, which is what this EIP is proposing.

Backwards Compatibility

The Ethers generated using the mint function should not have any difference with original Ethers. People should be able to use those minted Ethers for paying the gas fees.

Reference Implementation

A reference implementation is not ready yet, but we have an estimation of circuit size given the current implementations of Keccak256 and Secp256k1 point additions in Circom language.

The R1CS Zero-Knowledge-proof circuit of such system includes:

  • A 5-block (5*136 bytes) Keccak256 (~750k constraints) for block-hash calculation.
  • 3x 4-block (4*136 bytes) Keccak256 (~600k constraints) for Merkle-Patricia-Trie proofs.
  • Another Keccak256 instance for hashing the EOA-to-EOA transfer
  • Checking if EOA-to-EOA transaction is really sending to a unspendable address (Secp256k1 point addition)

Our approximation is that all these will need at most 3m constraints.

NOTE: The circuit size can get much smaller in case we maintain a zk-friendly merkle tree (Using MiMC/Poseidon/etc), storing all of the EOA-to-EOA transfers inside the core implementation of the Ethereum protocol.

Security Considerations

In case of faulty implementation of this EIP, people may mint infinite amount of ETH, collapsing the price of Ethereum.

Copyright and related rights waived via CC0.


Please cite this document as:

Keyvan Kambakhsh (@keyvank), Hamid Bateni (@irnb), Amir Kahoori <>, Nobitex Labs <>, "EIP-7503: Zero-Knowledge Wormholes [DRAFT]," Ethereum Improvement Proposals, no. 7503, August 2023. [Online serial]. Available: