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
          • Quoting Strategies
        • Monitoring Orders
          • 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
  • AutoParams structure
  • Flags

Was this helpful?

  1. The deBridge Messaging Protocol
  2. Development Guides
  3. Building an EVM-based dApp

EVM smart contract interfaces

Interaction with the deBridge infrastructure is as simple as calling the send method of debridgeGate smart-contract deployed on all supported blockchains. The method can be called by any arbitrary address — either EOA or smart contracts.

function send(
    address _tokenAddress,
    uint256 _amount,
    uint256 _chainIdTo,
    bytes memory _receiver,
    bytes memory _permit,
    bool _useAssetFee,
    uint32 _referralCode,
    bytes calldata _autoParams
) external payable;

The method accepts the following parameters:

Parameter Name
Type
Description

_tokenAddress

address

Address of the token being sent (address(0) for chain base assets like ETH)

_amount

uint256

Token amount to be transferred

_chainIdTo

uint256

Id of the receiving chain

_receiver

bytes

Address of the receiver

_permit

bytes

_useAssetFee

bool

Should also be set to False. (Reserved for future use by governance to accept fees in the form of the transferred token)

_referralCode

uint32

Your generated referral code

_autoParams

bytes

Structure that enables passing arbitrary messages and call data

If you integrate with or build applications on top of the deBridge infrastructure, make sure you specify your referral code that can be generated by pressing the INVITE FRIENDS button at https://app.debridge.finance/. Governance may thank you later for being an early builder.

AutoParams structure

_autoParams is a structure that allows passing arbitrary messages and call data to be executed as an external call to the receiver address on the destination chain. This structure also enables setting an executionFee, a reward suggested to any wallet or keeper that will complete the transaction on the target (destination) chain. It enables a crypto-economic design where gas fees are paid from the blockchain where the transaction is initiated. The _autoParams field has the following structure:

struct SubmissionAutoParamsTo {
    uint256 executionFee;
    uint256 flags;
    bytes fallbackAddress;
    bytes data;
}
Parameter Name
Type
Description

executionFee

uint256

Suggested reward (in Tokens) paid to anyone who will execute transaction on the destination chain

flags

uint256

Flags set specific flows for call data execution

fallbackAddress

bytes

In case execution of call data fails, all tokens will be transferred to the fallback address

data

bytes

Message/Call data to be passed to the receiver on the destination chain during the external call execution

Flags

Flags are a bit mask that allows customizing the transaction execution flow on the destination chain. The bit mask means you can set several flags simultaneously by setting the corresponding bit of flags variable to 1

library Flags {
    /// @dev Flag to unwrap ETH
    uint256 public constant UNWRAP_ETH = 0;
    /// @dev Flag to revert if external call fails
    uint256 public constant REVERT_IF_EXTERNAL_FAIL = 1;
    /// @dev Flag to call proxy with a sender contract
    uint256 public constant PROXY_WITH_SENDER = 2;
    /// @dev Data is hash in DeBridgeGate send method
    uint256 public constant SEND_HASHED_DATA = 3;
    /// @dev First 24 bytes from data is gas limit for external call
    uint256 public constant SEND_EXTERNAL_CALL_GAS_LIMIT = 4;
    /// @dev Support tx bundling (multi-send) for externall call
    uint256 public constant MULTI_SEND = 5;
}
Flag Name
Value
Description

UNWRAP_ETH

0

Automatically unwrap blockchain base asset

REVERT_IF_EXTERNAL_FAIL

1

Revert transaction if external call was not completed

PROXY_WITH_SENDER

2

Set in case receiving smart contract should validate sending chain id and address

SEND_HASHED_DATA

3

Pass hash of the call data instead of data itself. Only those who know the original call data will be able to claim the transaction on the target chain. If this flag is set, transaction won't be automatically claimed by external keepers.

SEND_EXTERNAL_CALL_GAS_LIMIT

4

Specify minimal gas limit to be passed to external call during the transaction claim. Gas limit should be passed in the first 4 bytes of the data

MULTI_SEND

5

PROXY_WITH_SENDER should be set whenever the receiving smart contract should check whether the message sender is trusted or not. If the flag was set during the claim transaction on the destination chain, the deBridge protocol will automatically store the submissionNativeSender address and submissionChainIdFrom, so that the receiving smart contract can read the properties and validate if the sender is trusted.

PreviousBuilding an EVM-based dAppNextInterfaces

Last updated 12 months ago

Was this helpful?

In case the token being passed supports , signed permits can be used instead of allowance approvals

With this flag passed call data will be executed through Gnosis multisend implementation embedded into deBridge callProxy. (Receiver address is not used in this case). Use to properly configure data for multisend

The receiving smart contract should retrieve the address of callProxy from the debridgeGate smart contract. You can use modifier or inherit it from to properly implement this validation logic.

onlyControllingAddress
BridgeAppBase.sol
EIP-2612
https://github.com/gnosis/ethers-multisend