[Shipped] Incognito's trustless bridge V3 with Ethereum bond contract

Objective: Deploy Incognito’s trustless bridge V3 and related parties on mainnet environments

Length: 3 months

Key results:

  • Have a trustless bridge protocol with Ethereum bond contract on mainnet by November 30



Shielding BTC and minting pBTC. Other public coins follow the same shielding process. Note that we simplify step 5 to make it simple for readers to follow the main logic: the proof of deposit is not generated by the custodian, but by the miners of underlying cryptonetwork.*


Unshielding pBTC and releasing BTC. Other public coins follow the same unshielding process*


COOL! :+1:
Who are the custodian?


hey @Roman, custodian could be anyone who deposits collaterals to the bond contract. For more details, please take a look at Trustless Custodians: A Decentralized Approach to Cryptocurrency Custodianship. Thanks.


Thanks @duc :raised_hands:
Very cool! I have carefully studied all the information! But to my deep regret I did not find information on how to get a high name custodian :woozy_face:


Just wanted to update a bit for the proposal’s status. As you could know we postponed this one since July to work on something with higher priority (i mean cross pair trading feature for pdex, code review as well as writing more tests).
So the tentative start time of the proposal will be around 4th week of August. Thanks.


Hi everyone,

We came back to Trustless bridge v3 after finishing other features (pDEX cross-pair trading, review and write more unit tests). We just want to update some new things about the proposal’s status that we have implemented for 3 weeks.

What results?

  • Refactor code more abstract: As you know, currently bridge v3 only supports shielding/unshielding BTC and BNB. But we want to define the interface for PortalToken (privacy token is shielded from public token through Bridge v3) in order for us or other community developers to expand the Bridge with other public tokens easily and quickly by supplying the proof verification functions on those public chains.
  • Implement new feature: Custodian deposit collaterals with Ethereum’s smart contract bond. Not only PRV collateral, the custodians are able to supply portal collaterals by their ETH/ERC20.
  • Update shielding flow: Allow the users to create shielding public token requests that match to custodians who deposited their collaterals to smart contract’s bond.

What next?

  • We do integration tests on custodians deposit collateral to the smart contract’s bond.
  • Test full shielding flow.
  • Implement and test custodians withdraw free collateral from the smart contract’s bond.
  • Implement and test unshielding flow.

Thanks for your following!


Thanks for the update on this! So the custodian will interact with an ethereum smart contract? I had thought that the bonded custodian model doesn’t require ethereum?

is there a github link for bridge V3 eth contract? i want to take a look

Hi @rareglottis,
Thanks for your interest in our proposal. You can visit these following github links:
https://github.com/incognitochain/incognito-chain/tree/portalv3 (Incognito-chain)
https://github.com/incognitochain/portal3-eth (Portal smart contract)
To view the code of Bridge v3. It will continue to be updated daily.


Hi everyone, some new updates about the proposal.

What results?

  • Implement and do integration tests on custodian withdraw free collaterals from the smart contract’s bond. Allow custodians to withdraw free collaterals (that weren’t locked by shielding requests) whenever they want.
  • Implement and test unshielding flow.
  • Update liquidation mechanism. There are 2 cases of liquidation on Bridge v3.
    • Case 1: The custodians don’t send back public tokens to users after timeout.
    • Case 2: The ratio between the public tokens’ value that the custodians are holding and the collaterals’ value are locked is dropped significantly below the specific minimum one.
      We finished implementing the first case. In this case, the users can get back the collaterals of the custodians from the smart contract’s bond instead of their own public tokens.

What nexts?

  • Implement the second case of liquidation.
  • Re-test all features on Bridge v3, make sure it’s ready for testing by QC team.

Let’s look forward to the launch date of Bridge v3! Thanks all.


Why is the custodians bond decreased when someone sends them more collateral? Maybe I’m misunderstanding but I would imagine that the trustless custodian could only be chosen if they have sufficiently staked and overcollateralized what they wish to custody. If being asked to custody more funds, the minimum requirement should INCREASE. (Maybe it’s a typo in the graphic.)

Hi @marko, thanks for your question.
The custodians who want to hold the cryptocurrencies on other cryptonetworks (public coins) have to deposit their collaterals with arbitrary amounts to the smart contract’s bond. After deposited, the custodian can receive public coins from shieldings with the limited amounts such that the ratio between the total collaterals provided and the total public coins’ holded is about 200%. After matching to the shielding, the limited amounts will be decreased. The custodians can deposit more collaterals to be able to receive more shieldings.


Hi everyone,
We have just completed the development phase of Bridge v3. We want to send you some notes about the proposal’s status.

What results?

  • Finish implementing and doing integration tests on auto-liquidation.
  • Re-test all features of Bridge v3 with Incognito vault (PRV collaterals) and Smart contract vault (ETH/ERC20 collaterals).

What next?

  • Write more unit tests and integration tests for Bridge v3.
  • Update exchange rate relayer better and more stable.

Let’s look forward to the launch date of Bridge v3! Thanks all.


Hi everyone,

Here are some main points about the development process of the trustless bridge v3 from Incognito’s team.

What results?

  • Write unit tests for Bridge v3 functions completely.
  • Update exchange rate relayer:
    • Get PRV price from three pool pairs on pDex instead of one pair.
    • Get the smallest BTC relaying header’s height from beacon nodes and full-nodes to make sure the relayer always feeds BTC headers fully.

What next?

  • Implement a new feature: When the total value of locked collaterals greater than 300% of the total value of holding public tokens, custodians are able to unlock their redundant collaterals such that the rest collaterals are at least equal to 200% of holding public tokens.
  • Refactor codes.

Thanks for your following! :hugs:


Thanks for the updates :slight_smile:

Hi everyone,
I just want to send you some updates about the proposal’s status after the past two weeks.

What results?

  • We have postponed the implementation new feature and refactor code as mentioned in the last update. We have focused on testing and fixing some issues before it will be deployed on Testnet.

What next?

  • Deploy Bridge v3 on Testnet.
  • Continue implementing the new feature: allow custodians to unlock their excess collaterals.
  • Refactor code.

Thanks for your following.


@duc, @0xkraken

Since you seem to be in charge of the Trustless Bridge/Bond Setup, I thought I would pass along some of my thoughts on the direction we should head towards with all this bridge business.

I propose creating a framework for,
Decentralized Collateralized Bridges

What are Bridges?
A bridge handles the shielding and unshielding of cryptocurrencies. Each individual integrated cryptocurrency has it’s own bridge.

BTC <-Bridge-> pBTC
XMR <-Bridge-> pXMR
ETH <-Bridge-> pETH

How can we Automate and Decentralize these Bridges?

To run a bridge, you need to be able to monitor transactions and interact with an external wallet of a particular crypto. You also need to have access to a Incognito Wallet with pVersions of that specified crypto. When users shield, they deposit into the external wallet, a Minting Proof is made, then the pVersion of the coin is sent out. When unshielding, the process happens in reverse.

What if we created a ‘bridge device’ similar to a pNode. This bridge device runs 24/7 and automates this process. Built in, the Device has a private incognito wallet key, and a private external wallet key.
This bridge would be 100% collateralized by the coin that it is bridging for. Meaning if it is bridging for BTC, then it must have BTC as collateral. The value of the external wallet combined with the incognito wallet must always equal the amount that is put up for collateral.

When someone adds collateral to the bridge, their incognito wallet in the bridge gets credited the same amount of coins but in pVersions. These can be minted when collateral is supplied.

When someone uses the Incognito App to request a shield address, one of these bridge devices gets selected to give it’s public external wallet address. A user deposits the crypto, and the device process’s the transaction and sends them a pVersion of the coin from the incognito wallet. This is an automated process and requires no effort. If for some reason the transaction is not made after the deposit was made, they forfeit an equal amount from their collateral, and a new device is selected to process the new transaction.

A bridge device can only be selected if it has enough collateral for the transaction. If for example a bridge device already recieved BTC in it’s external wallet, and sent out pBTC to keep balance. It can only be selected if the amount being shielded is less then or equal to (amount in collateral - amount in external wallet). However, for large transactions, i’m sure you could daisy chain multiple bridge devices if necessary. Same process in reverse.

Why Would people want to run Bridge Devices?
They can earn on transaction fee’s from unshielding.

The Idea:
These bridge devices can run many different wallets at once. With just a simple firmware update, a new wallet/bridge could be added. However it will only run bridges that it has collateral for.

Crypto communities of a particular coin can buy one of these devices and raise a large amount of capital to put as collateral. The collateral would be in the native coin, so if things get messy, you would be able to give people back their coins.

Instead of making a new device, you could theoretically update regular nodes to handle this functionality. The bridge device is pretty similar to a node. It requires capital, and it processes transactions upon being selected. Only difference is that it would probably be used more often and it is now storing potentially large amounts of different crypto depending on the collateral that is supplied. Users don’t have to use this feature if they don’t want to. Realistically if a node operator has a sufficient amount of collateral, they can be the main bridge for a particular coin which is great for coin communities looking to join in.

Since bridging is decentralized, it would be almost impossible for a particular bridge address to get blacklisted. Incognito Bridge wallets would consist of thousands of different wallets from many different devices.

Technically Incognito could host their own bridge and have users submit collateral through a system like provide (crowd-sourcing). They would earn an APY based on the earnings from unshielding. Almost every coin would be available to earn from.

Problem Solving:
There are some problems to workout with this system.
For example, how are the bridges chosen? How do we daisy chain large transactions effectively? Where do we store the private keys for the collateral?

There might have to be a middleman server made to handle these problems.

  • The bridge selection can work just like node selection, so that’s not to much of a problem, though a lot of tweaks would need to be made to verify states (A bridge could be maxed out and only allowed to be used for unshielding instead of shielding).
  • For receiving large transactions, we would have to make it a 2 step process. A shielding address is generated by this middleman server, and then once the transaction is received it sends a multi address transaction to all the chosen bridges. Each bridge only accepting an amount they are allowed to process. The middleman server can connect to the bridges individually and send the incognito wallet address that needs pCoins to be sent to.
  • The private keys would have to be stored by this middleman server. If the selected bridge doesn’t make the transaction, the middleman server would have to send the transaction again to a different bridge from the coins stored in the collateral wallet. This would also mean the middleman server would need read only keys from the Incognito wallets of each of these bridges to check if the transaction went through. Or at least be able to communicate with the bridges and ask for a response.

Obviously this is a lot of infrastructure and a big task, but I think it’s something worth pursuing as it would make the platform much better, safer, and private. As well as scaleable.


I really like this idea @Revolve

to all: Do custodians then earn PRV for their bond? What’s the incentive for someone to be a custodian?


Hi everyone,
There are some new updates for the trustless bridge v3 from Incognito team.

What results?

  • We deployed Bridge v3 protocol on Incognito’s Testnet, and finished testing full flow (shielding and unshielding flow) on both Incognito vault and Ethererum smart contract vault.
  • As mentioned in the recent update, we implemented the feature to allow custodians to unlock their excess collaterals that have been locked when shielding.
  • We refactored code.

What next?

  • Ready to deploy Bridge v3 on Mainnet.

Finally, hope the trustless bridge v3 will help you shield and unshield bridge tokens safely and decentralized completely. Thanks all.


Great work!!! This is exciting :grinning: