Smart Contracts Achitecture

The current implementation on Github quite differs from the description below. The experimental approach created during the Chainlink hackathon is simpler. Read the notes to see the difference.

deBridge smart contract system consists of 4 modules. White contracts are responsible for simple cross-chain transfers. Dark contracts provide fundamental mechanics for private asset exchanges. Periphery contracts interact with one or more core contracts but are not themselves part of the core and can be replaced/updated frequently. Governance contracts are used to manage core contracts, enable new transfers, support new protocols.

Smart Contracts Arhitecture

Transparent transfers

To make the solution cheap the module has two implementations: for chains with high and low transaction fees that differs on how the data between chains are transferred and validated.

The LightWhiteDebridge that manages transfers is deployed on expensive chains and must have the appropriate LightWhiteAggregator on the cheap chain that is used to aggregate the signatures from oracles. The collected signatures are submitted in one transaction on the network with high prices directly to the LightWhiteDebridge. When the user completes the transaction on the LightWhiteDebridge he provides the batch of the transactions from the oracles and their signatures are verified.

The WhiteAggregator and WhiteDebridge are designed for cheap networks. The confirmations from the oracles are sent by each of the oracles separately to the WhiteAggregator and the WhiteDebridge can communicate with it whenever the transferred amount is claimed. The fees are charged only on the chains with the fu

Both LightWhiteDebridge and WhiteDebridge can deploy and manage the supply of many WrappedAssets that represents the value that exists on other chain and is issued 1:1.

At the end of the Chainlink hackathon, only the full version of transparent transfers is implemented and deployed to both Ethereum and BSC.

Dark transfers

As in the case of the transparent transfers the "dark" contracts have 2 versions too.

The LighDarkDebridge that manages transfers is deployed on expensive chains and must have the appropriate LightDarkAggregator on the cheap chain that is used to aggregate the signatures from oracles. The collected signatures are submitted in one transaction on the network with high prices directly to the LightDarkDebridge. When the user completes the transaction on the LightDarkDebridge he provides the batch of the transactions from the oracles and their signatures are verified.

The DarkAggregator and DarkDebridge are designed for cheap networks. The confirmations from the oracles are sent by each of the oracles separately to the DarkAggregator and the DarkDebridge can communicate with it whenever the transferred amount is claimed. The fees are charged only on the chains with the fu

Both LightDarkDebridge and DarkDebridge can deploy and manage the supply of many WrappedAssets that represents the value that exists on other chain and is issued 1:1.

There are on-chain ZKP-Verifiers deployed to the cheap networks

The data submitted to the aggregator differs by the meaning of the data. In the case of the transparent transfer, the hash of the transfer parameters is sent by the oracle and in the case of the private transactions, it is the commitment note.

Governance

The GovernanceToken represents the voting power that can be used to manage the protocol and agree on future solution improvements. All the proposals are listed and executed through the Governance contract. At least 4% of the tokens are required to confirm the proposal.

Periphery

The contracts of this module are rather a sugar on top of the protocol. The fee from the WhiteDebridge/DarkDebridge can be proxied through FeeProxy. The reserves of the original asset locked in an exchange of the wrapped asset can be used by the DefiController which can have a few separate DefiStrategies that are switched by the condition.