Protocol Overview

Background
Cross-chain value transfers are one of the cornerstones in the world of truly decentralized finance. Blockchains are secure but isolated networks that don't have access to real-world data as well as to the state of other chains. Moreover, users have to rely on third-party services and centralized solutions, which are likely to request sensitive information or be susceptible to censorship. Every time a user performs a transfer through centralized bridges, the person has to bear the risk of their funds either being stuck due to an imbalance of liquidity on one of the sides of the bridge or being frozen due to centralization.
deBridge aims to solve these problems and become a decentralized standard for cross-chain liquidity transfers and overall interoperability of smart contracts in different chains.
Protocol Structure
The solution consists of 2 key layers:
Protocol layer — on-chain smart contracts
Infrastructure layer — off-chain validation nodes
The protocol layer is a set of on-chain smart contracts that are used for asset management, validation of validators/oracles signatures, and to reach consensus among validators as the transaction is treated as valid only if the minimum required threshold of confirmations by validators is achieved. The governance manages the parameters of the smart contracts, such as fees, the whitelist of elected validators, validators payout ratio, and more.
The infrastructure layer is based on Chainlink infrastructure and is represented by a set of validators who operate a Chainlink oracle node. deBridge will build a decentralized oracle network (DON) designated for cross-chain interoperability where each of the validators are elected by deBridge governance. Without limiting the generality in what follows, we will assume the oracle and the validator are one and the same.
deBridge is leveraging Chainlink technology for cross-chain intercommunication of deBridge components. Each oracle performs real-time monitoring of the blockchain events emitted by the deBridgeGate smart contract and is obliged to relay information about the transfer to the target blockchain by submitting the corresponding transaction into deBridgeAggregator smart contract in the target blockchain. The transfer is considered as "confirmed" as soon as the minimum required amount of confirmations is accumulated from validators for this specific transfer.
With the described protocol design, the only risk is if the majority of validators collude and validate fake transaction in order to withdraw Protocol collateral or mint an arbitrary amount of deAsset. There is a set of measures, including slashing and delegated staking mechanics, that are implemented into the protocol design to prevent collusion of validators and avoid economic incentives for validators to endanger the protocol. These measures are described in more detail in the Slashing and Delegated Staking section.
How it works
Naming
The protocol utilizes a locking and minting approach where the native token is locked/unlocked in a deBridgeGate smart contract in the native chain and wrapped asset (deAsset) is minted/burnt in secondary chains. 
For each asset, under the native chain of the asset, we assume the unique blockchain where the token was originally created. 
Secondary chains are blockchains supported by deBridge to which tokens can be transferred/bridged and where deAssets are minted. 
Collateralization
Each of the tokens locked in the native chain have the associated wrapped asset on the target chains. By design, the protocol ensures that the total supply of each deAsset that can be minted in secondary chains is always 1:1 backed by the asset collateral locked in deBridgeGate smart contract in the native chain. That provides a flawless user experience and guarantees that the user will never face a liquidity imbalance problem which is often encountered in other bridging solutions, where users face significant delays after they already locked liquidity in the bridge.
Protocol Fees
The protocol takes a small fee for each transfer performed through deBridge. A small fee is what users pay for confidence and decentralization since half of these fees go as payout to deBridge validators who are financially liable for the proper operation of the protocol.
 The fee consists of two components (Fix + %):
Fix - a fixed amount that is taken in the base asset of the blockchain which is aimed to cover the cost price validators pay for submission of the validation tx into the target chain. For example, if the transfer is performed from the Ethereum chain, then the fixed ETH amount will be deducted from the user's wallet towards the protocol treasury on Ethereum. The fixed fee is also required for Cross-chain interoperability when the smart contract in one blockchain can invoke an arbitrary method of the smart contract into another chain without transferring any liquidity cross-chain.
Percent (%) - a percentage of each amount of bridged liquidity. Similar to Uniswap and many other DeFi protocols, deBridge takes a small 10 BPS (0.1%) fee from each transfer. All collected fees are transferred into the protocol treasury smart contract.
Listing at deBridge
The deBridge protocol is universal and there are no listing requirements. Any arbitrary ERC-20 or ERC-721 (NFT) tokens can be bridged. If the token is bridged for the first time, together with the validation tx validators pass the following parameters of the token to the target chain:
Native token smart contract address
Native chain Id
Token name
Token symbol
Decimals
The wrapped (deAsset) is deployed in the target chain automatically together with the first claim of the wrapped asset. Thus no additional actions are required from user, listing is performed automatically by the Chainlink DON. In deBridge we care about user experience and strive to minimize unnecessary actions to be performed by protocol users.
Partial Liquidity Provision
One of the features of deBridge protocol is that it tends to effectively utilize liquidity locked as collateral for deAssets. Any token locked in collateral can be taken by users in a form of flash loans. Upon governance decision, part of the specific asset liquidity can be supplied into reliable DeFI strategies like AAVE, Compound which should be approved by deBridge governance. Normally that should be strategies without impermanent loss with the ability to retrieve liquidity at any given moment. Decentralized insurance for these strategies can be acquired from protocols like Nexus Mutual or Unslashed
Introduction
Next - The Core Protocol
Transfers Flow
Last modified 20d ago
Copy link
Contents
Partial Liquidity Provision