debridge-contracts-obsolete

KO | EN

gitlite — search

#hacktoberfest #react #ai #go #golang #android #machine-learning #rust #linux #java #awesome #awesome-list #security #mcp

debridge-contracts-obsolete

(★ 30)

No description available.

debridge-contracts-obsolete 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

## How White Transfers Works

The transfer of the asset from chain A to chain B goes through the followed steps:

1. If the transfered asset isn't the native blockchain token (i.e ETH, BNB) the `approve` is done otherwise the transfered amount is attached to the next method.
2. The `send` method of `WhiteDebridge` contract is called. The `amount` of asset is locked on the contract, the fee is charged from the `amount` and the `Sent` event is emited.
3. The ChainLink nodes listen to the event on the `WhiteDebridge` contract and after 3 blocks confirmations submit the sent request identifier(`submissionId`) which is hash of concatination of `debridgeId`, `amount`, `receiver`, `nonce`. `DebridgeId` is hash of network id of the chain where the original token exists and token address on the original chain. The oracles are rewarded with LINKs immediatly after the submission.
4. After enough confirmations from Chainlink oracles (lets say 3 out of 5) the send request status becomes `confirmed`.
5. The user or any other party can call `mint` method of `WhiteDebridge` contract with the correct `debridgeId`, `amount`, `receiver`, `nonce` parameters that results into `submissionId`. If the submission is confirmed the wrapped asset is minted to the `receiver` address.

The transfer of the wrapped asset on chain B back to the original chain A to chain B goes through the followed steps:

1. The `approve` to spent the wrapped asset by `WhiteDebridge` is done.
2. The `burn` method of `WhiteDebridge` contract is called. The `amount` of the asset is burnt and the `Burnt` event is emited.
3. The ChainLink nodes listen to the event on the `WhiteDebridge` contract and after 3 blocks confirmations submit the burnt request identifier(`submissionId`) which is hash of concatination of `debridgeId`, `amount`, `receiver`, `nonce`. `DebridgeId` is hash of network id of the chain where the original token exists and token address on the original chain. The oracles are rewarded with LINKs immediatly after the submission.
4. After enough confirmations from Chainlink oracles (lets say 3 out of 5) the burnt request status becomes `confirmed`.
5. The user or any other party can call `claim` method of `WhiteDebridge` contract with the correct `debridgeId`, `amount`, `receiver`, `nonce` parameters that results into `submissionId`. If the submission is confirmed the fee is transfer fee is charged and original asset is sent to the `receiver` address.

**Note**: the chainlink node can only submit up to 32 bytes per one transaction to the chain that is why `debridgeId`, `amount`, `receiver`, `nonce` can't be submitted by the node in one transaction. To solve it the hash of the parameters is used.

## Aggregator

## Test

```
yarn start-ganache &
yarn test
```

# Ideas Backlog

- [ ] use assets in other protocols

- [ ] support NFT to make transfer fee lower

debridge-contracts-obsolete

debridge-contracts-obsolete 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

debridge-contracts-obsolete

debridge-contracts-obsolete 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README