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
    • Interacting with smart contracts
      • Introduction
      • Placing orders
      • Filling orders
      • Withdrawing Affiliate Fees
    • Interacting with the API
      • Authentication
      • Creating an Order
        • Quick Start
        • Reserve Assets
        • Bridging Reserve Assets
        • Bridging non-reserve assets
        • API Parameters
          • Estimation-Only
          • prependOperatingExpenses
        • API Response
          • JSON Example
        • Refreshing Estimates
        • Fees and operating expenses
        • Order Fulfillment
          • Detecting the Order
          • Fulfilling the Order
            • Pre-Fill-Swap
          • Claiming the Order
      • Tracking Order Status
        • Order States
      • Integrating deBridge hooks
        • Creating Hook data for Solana
      • Submitting an Order Creation Transaction
      • Cancelling the Order
      • Affiliate fees
    • Interacting with the deBridge App
      • Custom Linking
    • deBridge Widget
    • 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. DLN: The deBridge Liquidity Network Protocol
  2. Interacting with the API
  3. Creating an Order

Refreshing Estimates

PreviousJSON ExampleNextFees and operating expenses

Last updated 1 day ago

Was this helpful?

It is recommended that transactions returned by the create-tx API be signed and submitted within 30 seconds. When response.tx is submitted within this window, the likelihood of successful order execution exceeds 99.9%.

There is no explicit time-to-live (TTL) on the transaction itself—that is, the period between receiving the create-tx API and submitting it on-chain. Transactions may remain valid for extended periods, especially when no is involved or when the is between stablecoins.

Handling Operating Expense Fluctuations

When the prependOperatingExpenses is enabled, special attention must be paid to how token approval amounts are set. If the allowance exactly matches response.estimation.srcChainTokenIn.amount and there is a delay—typically more than a minute—before submitting response.tx, operating expenses may increase. In this case, the estimate should be refreshed. If the updated expense exceeds the approved amount, an additional approval step is required, degrading the experience.

To prevent this, it is recommended to set the token allowance to infinity. When a finite allowance is required, it is advisable to include a buffer—commonly around 30%—to absorb any increase in gas costs or execution fees between approval and submission.

const { approximateOperatingExpense } = response.estimation.srcChainTokenIn;
const approveAmount = srcChainTokenInAmount + approximateOperatingExpense * 1.3;

This ensures that the approved amount remains sufficient, even if costs rise slightly before the transaction is broadcast.

You can see the code examples .

🔁
response
pre-order-swap
pre-order-swap
parameter
here