Cross-chain bridge

This section describes how the DotOracle network allows users to transfer digital assets from one chain to another chain in a decentralized way.
DotOracle uses a Proof-of-Stake - based mechanism that requires public nodes to lock an amount of DTO token (we are thinking of 500k DTO/node) to become validators.
The locked DTO acts as bonding for validators. If a validator violates the protocol by generating false proofs, it will be penalized by a slashing mechanism that burns the locked bonded DTO bonding. In the case of DotOracle cross-chain liquidity network, a proof is called false if the proof is signed by one of the validators and the proof proves an invalid request bridge transaction.
A request bridge transaction is issued by a user on the application. A request bridge transaction locks an amount of an origin token on a chain or burns an amount of wrapped token. For example, when a user wants to transfer USDT from Ethereum to MoonBeam chain, the user issues a request bridge transaction on the Ethereum blockchain by using the DotOracle bridge application. The transaction then locks the to-be-bridged amount in the DotOracle bridge smart contract on Ethereum.
On each chain connected in the DotOracle liquidity network, there is a DotOracle bridge smart contract that:
  • Issues new wrapped token or unlocks token when users claim digital assets they are transferring cross-chain
  • Burns wrapped token or locks token when users want to make a request bridge transaction.
Any one/node that observes a false proof signed by a validator can submit the false proof along with confirmations of false proof from at least ⅔ validators. The submission will be then executed by the bridge contract (to be deployed on MoonBeam), which will burn part of the bonded DTO of the bad validator and reward the remaining validators and the observer with the remaining of the bonded DTO of the bad validator.
Any one can launch a relayer node that basically listens to all bridge contracts on all blockchains for request bridge events. Relayer nodes can be run by any one because these nodes are public and will be used for showing and collecting user transaction histories.
After enough confirmations for the request bridge transaction, the user can request claim confirmation signatures from all validators. The number of confirmations depends on which network the user is transferring digital assets from. For example, if transferring from Ethereum to MoonBeam, the user would need to wait at least 12 confirmations before being able to claim the wrapped token on the target chain (MoonBeam). The user needs at least ⅔ validators to approve claim confirmation by collecting at least ⅔ signatures of the validators that confirm that the users can claim toke on the target chain.
The user then makes a claim transaction with signatures collected from the validator network and submits the transaction to the bridge contract on the target chain to claim.
When claiming token on the target chain, there will be two cases:
  • If the target chain is the chain where the token is created initially, an amount of token will be released from the bridge contract on the target chain
  • If the source chain is the chain where the token is created initially, the bridge contract on the target chain will issue an amount of wrapped token.
For example, if a user is transferring USDT (original token on Ethereum chain) from Ethereum to MoonBeam, a wrapped token dtoUSDT will be issued on MoonBeam with decimals and amount the same as the amount the user is transferring.
On the other hand, if a user is transferring dtoUSDT (wrapped token) from MoonBeam back to Ethereum, the transferred dtoUSDT amount will be burned on MoonBeam and the corresponding amount of USDT will be released on Ethereum by the bridge contract on the respective blockchains.
All these operations will be operated through a decentralized network. Therefore, the security of the network is equal to the security of the validators, which follows the Byzantine Fault Tolerance, meaning that the network would only be attacked if more than ⅓ network validators bribe with each other to attack the network.