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

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 11 months 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 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.

provides a handy method
Data flow for the claim method