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

Was this helpful?

  1. The deBridge Messaging Protocol
  2. Development Guides

Gathering data for the claim

PreviousLifecycle of a cross-chain callNextDevelopment Tools

Last updated 1 year ago

Was this helpful?

To claim a submission, a call to the deBridgeGate.claim() method on the destination chain must be crafted using data taken from various sources. Though deSDK already provides a handy method for this, we explain here where to take and how to prepare this data.

  • _debridgeId, _amount, _receiver, _nonce can be taken from the corresponding args of the Sent event,

  • _chainIdFrom is obviously the ID of the origin chain,

  • _signatures is the string with the signatures concatenated without a delimiter (don't forget to strip hexadecimal prefixes from each but the first); signatures can be pulled from the deBridge API,

  • _autoParams is the encoded SubmissionAutoParamsFrom struct, which is the derivative of the SubmissionAutoParamsTo with nativeSender taken from the Sent event: so you need to decode _autoParams against the SubmissionAutoParamsTo struct, add the fifth element, and encode back against the SubmissionAutoParamsFrom struct.

This simple diagram shows the flow of the properties; dashed lines indicate the necessity of data decoding/encoding/unpacking/packing, while the straight line shows that the datum should be passed as is:

After all these elements are combined into one single call, you can sign and broadcast your transaction and wait for the Claimed event. This will indicate a successful submission.

Data flow for the claim method