Incognito mode for Ethereum

Incognito mode for Ethereum

Incognito is a high-throughput proof-of-stake sidechain, made possible by the implementation of state sharding. Incognito takes a practical approach in designing and implementing its consensus mechanism, based on previous research and existing engineering by OmniLedger, Bitcoin, Ethereum 2.0, and Zilliqa.

The Incognito sidechain can be attached to any blockchain to conduct confidential asset transfer — in this case, Ethereum. The Incognito sidechain runs parallel to main blockchains, allowing for secure two-way transfers of crypto assets whenever privacy is needed.

This post will detail the means by which Incognito enables 100% confidential transfers of ETH and ERC20 tokens.

Incognito mode for Ethereum

In this post, we present the Incognito-Ethereum bridge — designed for fully decentralized cross-chain interoperability. Implementations will enable cross-chain communication between the two blockchains, and enable the choice of “incognito mode” for transfers of crypto assets (ETH and ERC20 tokens). Using this bridge, anyone can turn on privacy for their tokens and shield their balances and activity.

In the following sections, we will define and explain the functionality of the bridge as well as the mechanism by which such requirements are implemented.

Cross-chain asset transfer

A bridge can facilitate the transfer of crypto assets (e.g. tokens) between two blockchains by implementing locking, minting and burning mechanisms on each blockchain. When tokens are sent to a locking contract on Ethereum, Incognito needs to verify that the “locking” transaction was indeed confirmed on Ethereum, and upon the submission of the token lock transaction on Ethereum, proceed to mint a corresponding amount of privacy tokens (e.g., private Ether or private ERC20 tokens). When the private tokens are burned, the locking contract on Ethereum will verify the validity and unlock it upon submission of proof. This effectively maintains a 1:1 ratio between the private token on Incognito and the original token on Ethereum.

Ethereum ➔ Incognito

To convert ETH/ERC20 tokens on Ethereum to private ETH/ERC20 (pETH/pERC20) tokens on Incognito, users simply need to deposit their tokens to the Incognito Wallet. Under the hood, users are in effect sending their ETH or ERC20 tokens to a decentralized smart contract on Ethereum then sending the proof of that transaction to Incognito.

The Incognito chain verifies that proof and extracts information from it in order to mint private tokens to the predefined address.

The whole process is illustrated in the following figure:

Deposit Ether/ERC20 to smart contract

Our decentralized smart contract on Ethereum performs two pretty simple functions in the aforementioned deposit process — one for Ether and one for ERC20.

When those functions are called, two important pieces of information ( incognito address and deposit amount ) will be logged in anticipation of the related transactions being confirmed on the Ethereum network. In the following section, we explain how we use this information in minting private tokens.

Verify deposit proof

After the deposit transaction has been confirmed on the Ethereum chain, the proof can be obtained and a special transaction containing that proof can be submitted to the Incognito chain for verification, in order to mint the corresponding private tokens. The metadata of this special transaction contains the following fields:

  • Incognito private token id
  • Ethereum block hash
  • Ethereum transaction index
  • Merkle path (or proof) for a receipt relating to the deposit transaction in the Ethereum block

In order to verify the validity of an Ethereum proof on Incognito, we need to:

  • (1) Make sure that each Incognito node maintains a valid Ethereum header chain.
  • (2) Verify the validity of the proof (receipt’s Merkle path) with Ethereum header’s receipts root field (Merkle root). This is made possible via a receipt Trie (a special Ethereum data structure) from all receipts of transactions in a block.

Since Ethereum’s consensus is Proof of Work, here are some ways to achieve (1):

  • (a) Someone continuously relays Ethereum headers into Incognito and Incognito itself calculates the proof-of-work difficulty of the header and maintains a tree of all submitted headers. A block header is valid if it resides on the longest branch of the tree (a.k.a longest chain)
  • (b) Each Incognito validator node keeps a popular Ethereum light node (e.g. Parity or Geth). That light node also continuously syncs, verifies the proof-of-work difficulty and resolves the fork situation of block headers in a similar way to (1a)

In either (1a) or (1b), Incognito must obtain a valid Ethereum header in order to support the verification in (3). The team opted for (1b), a solution sufficient for moving forward based on the following assumption: as long as at least ⅓ of the number of validators in the Incognito committee run honest Ethereum light nodes, all is well. A transaction may only be comprised when a malicious Ethereum light node is run by at least (⅔ + 1) of the number of validators. (Note: Incognito’s consensus is Proof of Stake)

The verification process is illustrated in the following figure:

Mint private tokens

Along with the verification of Merkle path, the aforementioned process also extracts the content of the receipt belonging to a deposit transaction. From that receipt, the required information ( incognito address and deposit amount ) can be parsed for minting private tokens.

In other words, both deposit amount and incognito address of the receiver are stored in the proof so that no one can obtain the proof, do a front-running attack or steal any private tokens.

Incognito ➔ Ethereum

Withdrawing is the process of converting pETH (or pERC20) on Incognito to ETH (or ERC20) on Ethereum. On Ethereum, assets (ETH and ERC20) are held in a smart contract called the Incognito Vault . When someone wants to withdraw their tokens back to the main Ethereum blockchain, they need to supply the Incognito Vault with proof that sufficient tokens have been burned (i.e. destroyed) on Incognito. The private asset must be burned to maintain the 1:1 peg between the private asset on Incognito and the base asset.

The following diagram shows the whole process:

Burn private tokens

At any time, users can create a special transaction on Incognito called BurningRequest to initiate the withdrawal process. This tx sends an arbitrary amount of private tokens to the BurningAddress . Assets locked in this address cannot be moved, effectively destroying them. Along with the number of tokens to be withdrawn, users also provide a valid receiving address for the corresponding asset on Ethereum.

Here, TokenID is the private token id on Incognito chain, which will be used to derive the corresponding Ethereum asset (ETH or ERC20 contract address). RemoteAddress is the aforementioned address that will receive the Ethereum asset.

The tx is then mined and instructions generated and stored in the same block. This instruction will be included in a Burn proof , a cryptographic proof (signed by Incognito’s validators) that someone destroyed some amount of private tokens. Since the proof is stored onchain, it is viewable for anyone wishing to assess validity. The amount and token receiver (on Ethereum) is stored in the proof so that again, no one can get your proof, do a front-running attack and steal your tokens.

The proof is only considered valid when more than ⅔ of the current number of validators have signed it. On the Ethereum side, the list of validators is stored and continually updated to mirror Incognito’s.

The full code of BurningRequest tx can be found here:

Withdraw tokens with burn proof

After a burn proof has been generated, it can be obtained from the Incognito chain and submitted to the Vault contract. The proof contains the following metadata (burn instruction in the diagram below):

  • Type of token to withdraw (ETH or ERC20 address)
  • Amount of token
  • Token receiving address

Additionally, the contract also needs to verify that this proof is valid and signed by Incognito’s validators. We can split this into 3 steps:

  1. Verify that the burn instruction is in a merkle tree with some root X
  2. Merkle tree with root X is in a block with block hash Y
  3. Validators signed block Y

These steps are illustrated in the diagram below:

The code below shows the first step: verifying that the instruction (with hash instHash ) is in merkle tree (with root instRoot ), given the merkle path ( instPath ).

For the 2nd step, we need to recompute the hash of the block. On Incognito, block hash is computed by hashing the root of the merkle tree (storing all instructions) with the hash of the block body (containing all transactions). With this data, the contract can easily verify that merkle root X is in a block with hash Y.

Finally, the aggregated signature helps to prove that block hash Y has been approved by a group of validators Z. Note that since the contract already stores validator public keys, there is no need to provide them when validating a burn proof. The code below shows how we check if a sufficient number of validators (at least ⅔ + 1) signed the block.

The Incognito Vault contract is open-source here:

Swapping committee

We have left an important question unanswered so far: Incognito’s validators change all the time, how can the Incognito Vault smart contract keep track of them?

This is fairly simple to do by utilizing the tools discussed above. Every time a new validator joins the list or an existing one is removed (swapped), they collectively create and sign a SwapConfirm instruction. This instruction stores the pubkey of all validators and is validated in the exact same way as a burn instruction. Each committee effectively “hands over” to the next, and the chain of instructions ensure the list of validators is correct.

The following diagram illustrates this process:



The bridge was officially released along with the Incognito mainnet (end October 2019), and at the time of writing, has now enabled more than 30,000 privacy transactions. The wallet app is available for iOS and Android.


It would be better if you can give another post about the comparison with some other projects such as AZTEC or Tornado Cash.


@duc, any ideas on this? @andrey thought you may be able to weigh in. What would happen (besides sadness) if Incognito were to go under? In that event, do Incognito smart contracts automatically burn pTokens and mint new loser tokens or do our pTokens just go down with the ship?

1 Like

hey @jtmerchant, if you look into our roadmap then you could see that we’re working on stuff related to scalability as well as stability that will help the network more stable/decentralized/mature. One of them is slashing mechanism against validators/nodes not operating for a period (aka. one or a few epochs)

So in the worst-case scenario when Incognito is to go under in your words, or current validators shutdown their nodes in other words, anybody in the community can get Incognito code open-sourced on Github and run their own nodes in order to make the network operational again. By slashing’s help, the “shutdown-ed” committee will be transitioned to the new committee running by the community and that new committee will sign on a committee transition instruction so that Ethereum smart contract’s committee would also be updated.

Once the committee on Ethereum smart contract gets consistent with the new Incognito’s committee, the Ether/ERC20 tokens should be able to unlock as usual.

In fact, the main goal of the core team is to try to make things as decentralized as possible, not only the network but also people. As you can see, there are more and more people contributing to the project on both product development (via builders reward program) and growth (eg., design logo, introduction video, etc) so I personally think that anybody can a right to keep the network survive if they still see it helpful.


@duc amazing post, I have the following 2 questions:

Cool design I’m worried about possible bugs or backdoors

1 Like

What is the difference between this and what Secret Network just released:


I am not technical, but my knowledge is enough to see that those guys just released a blog post :rofl:

@Brendan_Kittredge you are a secret network agent :slight_smile: Maybe you could share what kind of innovation it brings?

It sounds like a Sushiswap guy comes to the Uniswap community and asks them to explain how Uniswap protocol is better than Sushiswap’s :triumph:


You are on the right track :grinning:


1 Like

I’m also with Secret Network (SN), trying to better understand incognito.

The innovation with SN is a public blockchain with privacy preserving smart contracts (general purpose computing). Having contracts with privacy (encrypted inputs/state/outputs) allows us to mint tokens with secret contracts (like ERC20s) and end up with privacy tokens. This is achieved by having a validator community running Trusted Execution Environments.

I would like to better understand what’s going on under the hood of Incognito. Can you pls point me to how Incognito achieves privacy once assets are minted on the side chain? How do the privacy tokens work?



Hey @cankisagun,

I replied your post on your forum just now :slight_smile: I came here and I saw your message.

You are a cofounder of SN, aren’t you? And I think you are Turk like me. If you want to contact me, you may use here or . I’m not from the team but I’m here since the testnet (October 2019). I have some information about the ecosystem. I also develop some products for Incognito community. To some extent, I may answer your technical questions. For more specialized topics, please wait for the core team. They are less active at the weekends.

While waiting them, you may read the whitepaper which is composed of a series of articles. Here is the entry point:

The whitepaper shows the smart-contracts as future work but it already was deployed as I stated in your forum. So the whitepaper may require a little update. Anyway, in addition to the links I gave in your forum, there is also a post showing Incognito’s smart contract solution via an example.

I hope both sides find a way for cooperation. To me, the core team is one of the most awesome teams in the crypto world, from both technical and ethical perspectives.



Hi again,

I think the first cooperation can be a trusted bridge between Incognito and SN. If you want to examine, here is how you can implement it:


Hey @cankisagun welcome in the community :slight_smile:

And Incognito is a privacy blockchain that utilizes public smart-contracts. I think we should explore a possible synergy. The first thing that came to mind is utilizing your privacy-preserving contracts in the Incognito’s privacy-preserving network.

@abduraman thank you for jumping in and sharing tech links, I think it a good start to dive in :slight_smile:

@cankisagun looking forward to your feedback and possible discussion once you catch up with what we build here)


Yes I am a validator on Secret Network :slight_smile: I was not trying to be adversarial or hide that fact. I should have posted with more background/information. I was having a discussion with @cankisagun about the technical implementations of the two projects and trying to understand the similarities and differences in approaches. Thank you for sharing the technical papers I will dig in!

Talking to Marina about The Privacy Quest was how I/we first found out about Incognito. I love what incognito is doing, and how they approach development in a no-nonsense, no hype way! I am very excited to see Privacy education in the space.


Every great love starts with a great story… :crazy_face:

1 Like

Hey @Brendan_Kittredge @cankisagun what about scheduling a tech call with me and @duc later this or earlier next week?


I’m more on the validator side of things, but I am learning about the implementation you guys are using. It sounds awesome. Saw the news today about pUniswap!


Let’s do it - what time zone are you guys in? I’m in PST


DM’d : )

1 Like

Did anyone ever address these points raised about possible bugs or backdoors? Just wondering…