VDA token bridge

[tahpot]

Project for bridging the VDA token between Ethereum mainnet and the chosen VDA primary blockchain.

[ITStar10]

In general, bridging tokens between chains can be done using web APIs. Usually, it involves burning & minting tokens. So if we bridge tokens from chain 'A' to chain 'B', tokens are burnt on 'A' and minted on 'B'.
To do such a process, a contract (called bridge contract) should be deployed on both chains.
While bridging tokens from 'A' to 'B', the bridge contract deployed on 'A' burn tokens and emit event including token information. A web application monitoring events from bridge contract on 'A' parse this information and make a call for 'mint' to bridge contract on 'B'. This is the general process of bridging. Here, we add some techniques to secure & sync transactions.
In poly network, one of the cross-chain transactions, there is a node to synchronize merkle-tree of chains. Now, the poly network supports cross-chain transactions between various chains including BTC, Ethereum, BSC, NEO, ONT and etc.
In spite of such powerful structures, there was hacking to Poly network.
Bridging is a part of cross-chain transactions. And we can choose the best way for our VDA token bridge.

[ryank000]

Wouldn't we want to look at existing cross-chain bridge solution providers and speak to them about support for VDA to bridge from Ethereum to other chains? It's seems like that would be a more secure approach than trying to set up our own bridging contracts.
The dependency is the VDA token contract on the other side of the bridge. Im not clear whether projects who bridge tokens themselves take responsibility for this, or whether the bridge provider creates the token contract themselves.

[ITStar10]

I had explained only how the bridging process works.
We should use our VDA node, bridge contracts, and other stuffs created by us for VDA-bridge.
By the way, we can and we should apply all the best techniques to our bridge.

[tahpot]

@ITStar10

I'm confused.

As @ryank000 said, we would aim to use existing bridges for the various chains.

As such, we don't require any development work on our side. Or am I missing something?

[ITStar10]

We are aiming our Verida Protocol.
There are several protocols & methods for cross-chain transactions. In the above, I explained how cross-chain transactions work.
If we use already developed protocols for our Verida project, we can't control the entire project.
Here is an example. O3Swap (one of the cross-chain swaps) depends on the poly network. They just send their transactions to the poly network and get 0.3% fees on their side, and they don't know how the internal transactions go on.
Also the Poly network gets fees on each transaction.
Our own Verida protocol can be a slave of any other networks? Absolutely not.
We will construct our own Verida network and all our applications will make interactions through the Verida network, not others.
Here, we can refer to the currently existing structure that is common & general for cross-chain transfer.
Among all cross-chain protocols that I had seen before, the Poly network looks more secure than others. So I mentioned how that network works.

[tahpot]

Ok. Just to be clear, we are not building our own blockchain.

We need to bridge our ERC20 token to other blockchains (L1 and L2). We will not be building our own bridges, we will be using other, existing bridges.

This is not a current priority.

[tahpot]

After discussion with @ITStar10

Key notes:

• The Verida ERC20 token will be bridged to other L1 and L2 chains.
• A new token contract will be created and deployed for each L1 / L2 chain we decide to bridge to.
• The work to bridge the Verida ERC20 to other L1 / L2 chains will be separate projects that can be prioritized in the future. This work will include, creating a token that implements the correct interfaces for the bridging protocol used on the respective L1 / L2.
• The Verida ERC20 token may need to be upgraded in the future, to enable bridging the Verida ERC20 token to other L1 / L2 chains in the future.

Next steps:

• Do nothing until we decide on the L1 / L2 the Verida smart contracts will be deployed on
• Once decided, we will implement a bridge to our chosen L1 / L2
• Decide on any other L1 / L2 bridges we want to support
• Implement bridges
• Launch Verida ERC20 token and bridges, with liquidity

[nick-verida]

Hey @ITStar10 I’m using ZenHub in GitHub, click this link to join my workspace and see other features available in GitHub or download the ZenHub extension and sign up with your GitHub account.
Posted using ZenHub