deBridge
  • Introduction
  • The deBridge Messaging Protocol
    • Protocol Overview
    • Fees and Supported Chains
    • 🟢Deployed Contracts
    • Development Guides
      • Building an EVM-based dApp
        • EVM smart contract interfaces
          • Interfaces
            • ICallProxy
            • IDeBridgeGate
            • IDeBridgeToken
            • IDeBridgeTokenDeployer
            • IOraclesManager
            • ISignatureVerifier
            • IWethGate
          • Libraries
            • Flags
          • Periphery
            • CallProxy
            • DeBridgeToken
            • DeBridgeTokenProxy
            • SimpleFeeProxy
          • Transfers
            • DeBridgeGate
            • DeBridgeTokenDeployer
            • OraclesManager
            • SignatureVerifier
            • WethGate
      • Sending cross-chain messages from Solana
        • On-Chain external call preparation for Solana
        • Off-chain external call preparation for Solana
      • Lifecycle of a cross-chain call
      • Gathering data for the claim
    • Development Tools
    • Security
    • Slashing and Delegated Staking
  • 🔁DLN: The deBridge Liquidity Network Protocol
    • Introduction
    • Protocol Overview
    • deBridge Hooks
    • Fees and Supported Chains
    • 🟢Deployed Contracts
    • Market and Limit Orders
    • Integration Guidelines
      • Interacting with the API
        • Authentication
        • Creating an Order
          • Quick Start
          • API Parameters
            • Estimation-Only
            • prependOperatingExpenses
          • API Response
            • JSON Example
          • Refreshing Estimates
        • Tracking Order Status
          • Order States
        • Integrating deBridge hooks
          • Creating Hook data for Solana
        • Submitting an Order Creation Transaction
        • Cancelling the Order
      • deBridge Widget
      • Interacting with smart contracts
        • Placing orders
        • Filling orders
      • Under the Hood
        • Reserve Assets
        • Bridging Reserve Assets
        • Bridging Non-Reserve Assets
        • Order Fulfillment
          • Detecting the Order
          • Fulfilling the Order
            • Pre-Fill-Swap
          • Claiming the Order
      • Affiliate fees
        • Withdrawing Affiliate Fees
      • Fees and operating expenses
    • Interacting with the deBridge App
      • Custom Linking
    • Protocol specs
      • Deterministic order ID
      • Hook data
        • Anatomy of a Hook for the EVM-based chains
        • Anatomy of a Hook for Solana
  • 💸dePort
    • Getting started
    • Transfers Flow
  • ⚡deBridge Points
    • Referrers Overview
    • Integrators Overview
  • 🌐deBridge IaaS
    • Getting started
  • 🌐Legal
    • SDK & API License Agreement
  • External Links
    • deBridge Use Cases
      • 💡Examples
    • Talks, Videos, and Articles
    • Website
    • Github
    • Twitter
    • Social channels
      • Discord
      • Facebook
      • LinkedIn
      • Medium
      • Telegram
      • YouTube
Powered by GitBook
On this page
  • Transfers From Native (Source) Chain
  • Cross-Chain Transfers Execution Time

Was this helpful?

  1. dePort

Transfers Flow

PreviousGetting startedNextReferrers Overview

Last updated 11 months ago

Was this helpful?

Transfers From Native (Source) Chain

Let's consider the situation where the user or smart contracts performs a transfer of the asset and data from chain A to chain B. Then the following steps are performed:

  • If the transferred asset isn't the base blockchain asset (i.e ETH or BNB) the approved method is called or the permit is signed. Then the send method of the DebridgeGate contract is invoked. The transferred amount of the asset is locked in the smart contract or burnt (for deAssets in secondary chains). The % component of the protocol's fee is deducted from the amount and transferred to the treasury, fix component of the fee is paid by the user in the base chain asset and also transferred to the treasury.

  • DebridgeGate smart contract calculates the unique hash of cross-chain transaction based on the set of unique parameters:

 _debridgeID =  keccak256(abi.encodePacked(_chainId, _tokenAddress));
 
 bytes memory packedSubmission = abi.encodePacked(
            SUBMISSION_PREFIX,
            _debridgeId,
            getChainId(),
            _chainIdTo,
            _amount,
            _receiver,
            nonce
        );
        
submissionId = keccak256(
                abi.encodePacked(
                    packedSubmission,
                    autoParams.executionFee,
                    autoParams.flags,
                    keccak256(autoParams.fallbackAddress),
                    isHashedData ? autoParams.data : abi.encodePacked(keccak256(autoParams.data)),
                    keccak256(abi.encodePacked(msg.sender))

debridgeID is a hash of concatenation of the token native chain Id and native token address.

  • deBridge validation nodes track events emitted by deBridgeGate smart contract and after a minimum number of blocks confirmations validators submit the transfer identifier (submissionId) to the deBridgeAggregator contract on the target chain. submissionId is calculated as a hash of concatenation:

  • The user or any arbitrary wallet (e.g. Keeper service) can call claim method of deBridgeGate by passing all transaction parameters and all validators' signatures. Smart contract will restore submissionId based on the set of passed parameters and if the minimum required number of validators' signatures is valid, the transaction is treated by the protocol as valid and the asset is minted/unlocked to the receiver address and data is executed through the callProxy.

deBridge protocol supports multi-chain routing when users can transfer deAssets between secondary chains directly, without the need to route them through the native chain. These transfers work in the same way, but deAsset is burnt in the chain where the transfer is originated and the corresponding amount of deAsset is minted on the target chain.

Cross-Chain Transfers Execution Time

Cross-chain transfer through deBridge normally takes a few minutes and the delay is caused by two factors:

  1. The finality of the transaction on the blockchain where the transfer is originated

  2. Time required for claim transaction to get into the block on the destination chain

Each blockchain has a different block generation time and requires a different number of block confirmations for ensured transaction finality, thus before validating the transaction validators must wait for its finality.

💸