# Get v10supported chains
Source: https://docs.debridge.com/api-reference/appcontrollerv10/get-v10supported-chains
/dln-details/swagger/create-tx.json get /v1.0/supported-chains
# Get v10supported chains info
Source: https://docs.debridge.com/api-reference/appcontrollerv10/get-v10supported-chains-info
/dln-details/swagger/create-tx.json get /v1.0/supported-chains-info
# Get v10token list
Source: https://docs.debridge.com/api-reference/appcontrollerv10/get-v10token-list
/dln-details/swagger/create-tx.json get /v1.0/token-list
# Generates a transaction that cancels external call in the given order
Source: https://docs.debridge.com/api-reference/dln/generates-a-transaction-that-cancels-external-call-in-the-given-order
/dln-details/swagger/create-tx.json get /v1.0/dln/order/{id}/extcall-cancel-tx
This endpoint generates a transaction that cancels external call in the given order.
# Generates a transaction that cancels the given order
Source: https://docs.debridge.com/api-reference/dln/generates-a-transaction-that-cancels-the-given-order
/dln-details/swagger/create-tx.json get /v1.0/dln/order/{id}/cancel-tx
This endpoint generates a transaction that cancels the given order. This transaction must be published to the destination chain of the order. Unlocked funds would be transferred to the address specified as the orderAuthority of the given order on the source chain. This transaction can only be executed by th orderAuthority of the given order on the destination chain
# This endpoint returns the data for a transaction to place a cross-chain DLN order.
Source: https://docs.debridge.com/api-reference/dln/this-endpoint-returns-the-data-for-a-transaction-to-place-a-cross-chain-dln-order
/dln-details/swagger/create-tx.json get /v1.0/dln/order/create-tx
This endpoint returns the data for a transaction to place a cross-chain DLN order.
# This endpoint returns the data of order.
Source: https://docs.debridge.com/api-reference/dln/this-endpoint-returns-the-data-of-order
/dln-details/swagger/create-tx.json get /v1.0/dln/order/{id}
This endpoint returns the data of order.
# This endpoint returns the status of order.
Source: https://docs.debridge.com/api-reference/dln/this-endpoint-returns-the-status-of-order
/dln-details/swagger/create-tx.json get /v1.0/dln/order/{id}/status
This endpoint returns the status of order.
# This endpoint returns the status of order.
Source: https://docs.debridge.com/api-reference/dln/this-endpoint-returns-the-status-of-order-1
/dln-details/swagger/create-tx.json get /v1.0/dln/tx/{hash}/order-ids
This endpoint returns the status of order.
# Returns information about Solana transactions in a given block range
Source: https://docs.debridge.com/api-reference/orderevents/returns-information-about-solana-transactions-in-a-given-block-range
/dln-details/swagger/monitoring.json get /api/OrderEvents/solanaDepositsAndWithdrawals
# Get external call processed events by orderId
Source: https://docs.debridge.com/api-reference/orders/get-external-call-processed-events-by-orderid
/dln-details/swagger/monitoring.json get /api/Orders/{orderId}/externalCallProcess
# Get filtered list of orders (ordered by block timestamp desc) max page size: 100
Source: https://docs.debridge.com/api-reference/orders/get-filtered-list-of-orders-ordered-by-block-timestamp-desc-max-page-size:-100
/dln-details/swagger/monitoring.json post /api/Orders/filteredList
# Get order by events by creation transaction hash
Source: https://docs.debridge.com/api-reference/orders/get-order-by-events-by-creation-transaction-hash
/dln-details/swagger/monitoring.json get /api/Orders/creationTxHash/{creationTxHash}
# Get order by events by orderId
Source: https://docs.debridge.com/api-reference/orders/get-order-by-events-by-orderid
/dln-details/swagger/monitoring.json get /api/Orders/{orderId}
# Returns lite order model by order Id
Source: https://docs.debridge.com/api-reference/orders/returns-lite-order-model-by-order-id
/dln-details/swagger/monitoring.json get /api/Orders/{orderId}/liteModel
# Returns number of orders in Created or Canceling state where given user (wallet) is initiator (sender of CreateEvent's transaction)
Source: https://docs.debridge.com/api-reference/orders/returns-number-of-orders-in-created-or-canceling-state-where-given-user-wallet-is-initiator-sender-of-createevents-transaction
/dln-details/swagger/monitoring.json get /api/Orders/getInitiatorsPendingOrdersCount
# Returns order offers for unlock authorities
Source: https://docs.debridge.com/api-reference/orders/returns-order-offers-for-unlock-authorities
/dln-details/swagger/monitoring.json post /api/Orders/getForUnlockAuthorities
# Returns order state by order Id
Source: https://docs.debridge.com/api-reference/orders/returns-order-state-by-order-id
/dln-details/swagger/monitoring.json get /api/Orders/{orderId}/state
# Returns aggregated information about users, that used given referral code
Source: https://docs.debridge.com/api-reference/referralprogram/returns-aggregated-information-about-users-that-used-given-referral-code
/dln-details/swagger/monitoring.json get /api/ReferralProgram/{referralCode}/referredUsers
# Returns referral code which user used in first DeBridge order
Source: https://docs.debridge.com/api-reference/referralprogram/returns-referral-code-which-user-used-in-first-debridge-order
/dln-details/swagger/monitoring.json get /api/ReferralProgram/referrerCode/{walletAddress}
# Returns referral statistics for given referral code
Source: https://docs.debridge.com/api-reference/referralprogram/returns-referral-statistics-for-given-referral-code
/dln-details/swagger/monitoring.json get /api/ReferralProgram/{referralCode}/summary
# Retrieves the SameChainSwapDTO object for a given swap ID.
Source: https://docs.debridge.com/api-reference/samechainswap/retrieves-the-samechainswapdto-object-for-a-given-swap-id
/dln-details/swagger/monitoring.json get /api/SameChainSwap/{swapId}
# Retrieves the SameChainSwapDTO object for a given transaction hash.
Source: https://docs.debridge.com/api-reference/samechainswap/retrieves-the-samechainswapdto-object-for-a-given-transaction-hash
/dln-details/swagger/monitoring.json get /api/SameChainSwap/{chainId}/tx/{transactionHash}
# Get daily statistics for given timespan
Source: https://docs.debridge.com/api-reference/satistics/get-daily-statistics-for-given-timespan
/dln-details/swagger/monitoring.json get /api/Satistics/getDaily
# Returns locked assets statistics for given address
Source: https://docs.debridge.com/api-reference/satistics/returns-locked-assets-statistics-for-given-address
/dln-details/swagger/monitoring.json get /api/Satistics/{takerAddress}/lockedAssets
# Returns orders statistics summary for all time
Source: https://docs.debridge.com/api-reference/satistics/returns-orders-statistics-summary-for-all-time
/dln-details/swagger/monitoring.json get /api/Satistics/getAllTime
# Returns orders statistics summary for last 24 hours
Source: https://docs.debridge.com/api-reference/satistics/returns-orders-statistics-summary-for-last-24-hours
/dln-details/swagger/monitoring.json get /api/Satistics/getLatestTwentyFourHours
# Get v10chainestimation
Source: https://docs.debridge.com/api-reference/single-chain-swap/get-v10chainestimation
/dln-details/swagger/create-tx.json get /v1.0/chain/estimation
# Get v10chaintransaction
Source: https://docs.debridge.com/api-reference/single-chain-swap/get-v10chaintransaction
/dln-details/swagger/create-tx.json get /v1.0/chain/transaction
# Adds signature for the terms and conditions
Source: https://docs.debridge.com/api-reference/termsandconditions/adds-signature-for-the-terms-and-conditions
/dln-details/swagger/monitoring.json post /api/TermsAndConditions/signConditions
# checks if the user has signed the terms and conditions
Source: https://docs.debridge.com/api-reference/termsandconditions/checks-if-the-user-has-signed-the-terms-and-conditions
/dln-details/swagger/monitoring.json get /api/TermsAndConditions/{signatoryAddress}/hasSigned
# Returns current terms and conditions
Source: https://docs.debridge.com/api-reference/termsandconditions/returns-current-terms-and-conditions
/dln-details/swagger/monitoring.json get /api/TermsAndConditions/current
# Get list of tokens from a specific chain, transferred with DLN, sorted by popularity
Source: https://docs.debridge.com/api-reference/tokenmetadata/get-list-of-tokens-from-a-specific-chain-transferred-with-dln-sorted-by-popularity
/dln-details/swagger/monitoring.json get /api/TokenMetadata/popularTokens/{chainId}
# Get list of tokens, transferred with DLN, sorted by popularity
Source: https://docs.debridge.com/api-reference/tokenmetadata/get-list-of-tokens-transferred-with-dln-sorted-by-popularity
/dln-details/swagger/monitoring.json get /api/TokenMetadata/popularTokens
# Returns ids of orders, that were created in a transaction
Source: https://docs.debridge.com/api-reference/transaction/returns-ids-of-orders-that-were-created-in-a-transaction
/dln-details/swagger/monitoring.json get /api/Transaction/{orderCreationTransactionHash}/orderIds
# Returns lite order models list by order tx hash
Source: https://docs.debridge.com/api-reference/transaction/returns-lite-order-models-list-by-order-tx-hash
/dln-details/swagger/monitoring.json get /api/Transaction/{transactionHash}/liteModels
# Returns users leaderboard (at the top of the board are users, that have generated the most fees)
Source: https://docs.debridge.com/api-reference/users/returns-users-leaderboard-at-the-top-of-the-board-are-users-that-have-generated-the-most-fees
/dln-details/swagger/monitoring.json post /api/Users/usersLeaderboard
# Returns users leaderboard (at the top of the board are users, whose referrals have generated the most fees)
Source: https://docs.debridge.com/api-reference/users/returns-users-leaderboard-at-the-top-of-the-board-are-users-whose-referrals-have-generated-the-most-fees
/dln-details/swagger/monitoring.json post /api/Users/referralProgramLeaderboard
# Affiliate Fees
Source: https://docs.debridge.com/dln-details/affiliates/affiliate-fees
Referral Code, Same-Chain and Cross-Chain Affiliate Fees, and Additional Considerations for Cross-Chain Affiliate Fees.
# Referral Code
To enable affiliate fees, a referral code must be included in the `create-tx` request
[parameters](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters). Further details on obtaining a referral code and its
additional use-cases are available in the Referrers and Integrators Overview sections.
# Affiliate Fees
Affiliate fees can be earned through both cross-chain and same-chain swaps by including the appropriate parameters in the request. This allows
integrators to monetize swap activity within their applications.
# Cross-Chain Affiliate Fees
To enable affiliate fees for cross-chain swaps, the following [parameters](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters)
must be included when creating an order:
* `affiliateFeePercent`: The percentage of the order input amount allocated as the affiliate fee.
* `affiliateFeeRecipient`: The address or public key of the affiliate fee beneficiary. This must be:
* A public key on Solana
* A wallet address on EVM chains
Affiliate fees become available once an order reaches the `ClaimedUnlock`
[state](/dln-details/integration-guidelines/order-creation/order-tracking-api/order-states).
* On EVM chains, the affiliate fee is [automatically transferred to the specified recipient when a solver claims the
order](/dln-details/dln-specifics/order-fulfillment/claiming-order)
* On Solana, the fee must be withdrawn manually. Further details on withdrawing affiliate fees are provided
[here](/dln-details/affiliates/withdrawing-affiliate-fees).
### Additional Considerations for Cross-Chain Affiliate Fees
Gas costs for affiliate fee transfers are capped at 2300 gas on EVM chains. If the `affiliateFeeRecipient` is a contract that requires more gas to
process the transfer, the affiliate fees will not be sent, but the order will still be processed normally. In those cases, affiliate fees have to be
claimed manually by calling `DlnSource.withdrawUnclaimedAffiliateFees(...)`. The caller can be anyone, but the specified beneficiary must be the
`affiliateFeeRecipient` set in the request.
# Same-Chain Affiliate Fees
Affiliate fees are supported for same-chain swaps as well. These swaps use the same `affiliateFeePercent` and `affiliateFeeRecipient`
[parameters](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters), with [Solana requiring additional
configuration](/dln-details/affiliates/affiliate-fees#solana).
### EVM Chains
Affiliate fees for same-chain swaps on EVM chains are handled automatically during the swap transaction execution and they are not subject to the 2300
gas limit on transfers, as the cross-chain affiliate fees are.
### Solana
For same-chain swaps on Solana:
* The `affiliateFeeRecipient` **must be a Jupiter referral key**.
* Referral keys can be generated at [https://referral.jup.ag/dashboard](https://referral.jup.ag/dashboard).
* Earned fees can be claimed via the [Jupiter Referral Dashboard](https://referral.jup.ag/dashboard).
# Auto Cancellation
Source: https://docs.debridge.com/dln-details/affiliates/auto-cancellations
How auto cancellations work for orders with a referral code.
# Overview
Auto cancellation can be enabled for orders associated with a [referral
code](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#referral-code). This mechanism improves user
experience by automatically cancelling unfulfilled orders after a timeout period.
This feature is strictly available through an approval from deBridge. To enable this feature, deBridge must be contacted.
***
## How it works
* **Timeout duration:** 5 minutes for unprofitable orders, 15 minutes for other causes (e.g. compliance issues)
* **Condition:** If an order is not fulfilled within this period, it is automatically cancelled, along with any external calls (hooks)
* **Benefit:** Users do not need to manually cancel the order on the destination chain, greatly improving the UX
* **Cost:** The cancellation fee is subsidized by deBridge
* **Market orders:** Only market orders can be cancelled, not [limit
orders](/dln-details/integration-guidelines/order-creation/creating-order/quoting-strategies#limit-order-not-recommended).
***
## Returned funds and asset types
Upon cancellation, returned funds are generally not the same asset originally sent.\
When orders are created, tokens are swapped for [**reserve assets**](/dln-details/dln-specifics/reserve-assets) to simplify solver book balancing.\
Assets with sufficient on-chain liquidity remain tradable.
In most cases, USDC will be used. If the reserve asset on one chain is USDC, but on another it is ETH, wETH or USDC - USDC will be used on both the
source and destination chains.
The refund asset and amount can be found in `create-tx` response payload by inspecting the `srcChainTokenOut`
[field](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/response#srcchaintokenout-optional). The entire input amount
and all of the [fees incurred by creating an order](/dln-details/overview/fee-structure) are returned to the user.
If the `srcChainTokenOut` is not present in the response payload, the refund asset is specified in `srcChainTokenIn`
[field](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/response#srcchaintokenin).
The reason for that is that [pre-order-swap was not performed](/dln-details/dln-specifics/bridging-non-reserve-assets#pre-order-swap) because the
order input asset was a [reserve asset](/dln-details/dln-specifics/reserve-assets).
***
## Required integration parameters
When auto cancellation is enabled - `dstChainOrderAuthorityAddress`
[parameter](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#authorities-and-recipient-address) will be
overridden to a deBridge-controlled address to [cancel orders on the destination
chain](/dln-details/integration-guidelines/order-creation/cancelling-order). Cancellation costs will be subsidized by deBridge in this case.
The `srcAllowedCancelBeneficiary`
[parameter](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#cancellation-beneficiary) must be set to
the user's wallet address. This address acts as the beneficiary of returned funds in the event of a cancellation. **If not set correctly, funds may be
lost**. It is recommended for partners to set the `srcAllowedCancelBeneficiary` parameter to a user-controlled address explicitly.
If not set, the `srcChainOrderAuthorityAddress` will be used as a [fallback](/dln-details/affiliates/auto-cancellations#fallbacks).
### Fallbacks
If [`srcChainOrderAuthorityAddress` parameter](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#authorities-and-recipient-address)
is set in `create-tx` requests, the value of it will be used as `srcAllowedCancelBeneficiary` if `srcAllowedCancelBeneficiary` is not set explicitly.
***
## Feature request steps
* Integrator gives an explicit, unambiguous approval for the feature to be switched on
* Integrator sets the `create-tx` [request parameters correctly](#required-integration-parameters)
* Integrator confirms the parameter settings via an established communication channel
* deBridge reviews several recent orders created by the integrator after the settings confirmation
* deBridge switches the feature on and confirms it to the integrator
# Integrators Overview
Source: https://docs.debridge.com/dln-details/affiliates/integrators
How integrators earn deBridge Points, generate referral links, and track integration activity.
# Overview
We’re super excited to introduce and announce the deBridge points program, an ecosystem initiative we have launched for all our stakeholders including
current and future project partners and integrators to have a way to gain points based on the value and fees they have provided to the deBridge
ecosystem which will be rewarded later this year.
Points are meant to act as a significant incentive for projects to facilitate integration as points will be accumulated based on users' activity (25%
goes to the specific integrator) and this will give each project a say in the future governance and value-creation within the deBridge ecosystem.
# How does it work?
Projects can integrate our cross-chain infrastructure in different ways — deBridge messaging, deBridge Widget, and deBridge API — to start
accumulating points. Your users will earn 100 points for every \$1 in fees paid to the protocol. Similarly, paying \$10 in fees will earn 1000 points
for this example transaction, and you will receive 25%.
We believe those who have used deBridge and our applications deserve a share in our collective and future success. The launch of this program is a
medium to incorporate decentralized governance and hand over power to the community in the future which includes users, project integrators, community
members, and other stakeholders.
# How to start accumulating points?
Here are our go-to docs with details on how to get started in the best possible way:
* [deBridge Messaging](/dmp-details/dmp/protocol-overview)
* [deBridge API](/dln-details/integration-guidelines/order-creation/creating-order/quick-start)
* [deBridge Widget](/dln-details/widget/deBridge-widget)
# How to make sure your integration activity is accounted for?
All projects need to generate the specific referral link that they pass on the backend of the deBridge integration they do to make sure they get the
25% referring bonus. Here’s how you do it:
* Go to [https://app.debridge.com/refer](https://app.debridge.com/refer)
* Pick Polygon and click generate - it is the cheapest option and covers all of the supported chains, including Solana.
* Pass `referralCode` parameter to all DLN API queries, or specify it for all deBridge smart contract calls
* Go to the [statistics page](https://app.debridge.com/statistic) and see your stats live
Please share the code with us if you haven’t already.
# Where to see your deBridge points
You will be able to see your deBridge points by visiting this website and connecting the wallet address you used to generate the referral link:
[https://explorer.debridge.com/statistic/](https://explorer.debridge.com/statistic/)
# FAQ
### How to check your points
You can check your current points here: [https://explorer.debridge.com/statistic/](https://explorer.debridge.com/statistic/)
### I forgot to add a tracking/referral code to the backend. What can I do?
It’s crucial that you add your code as soon as possible for your users and you to get points. Otherwise, they will not be accounted for. See the
step-by-step guide above for what needs to be done.
### What’s the future purpose of deBridge points?
For projects, it’s a primary way of getting a say in future governance and value-creation within the deBridge ecosystem.
### How long will the points program last for?
More details on this will be shared after the points program is live, but we can say that it will not be for an extensive period.
# Using Referral Codes in Integrations
Source: https://docs.debridge.com/dln-details/affiliates/referral-code
Learn how to use referral codes in deBridge integrations to track orders and unlock advanced features.
# Referral Codes for Integrators
When integrating deBridge into a product, the **referral code** can be attached to every order. This is more than just a way to track
traffic — it’s a powerful identifier that allows:
* **Tracking all orders created through an integration**
* **Measure performance and usage** of an integration in real time
* **Enable or disable certain features** on a per-integrator basis
***
## Why referral codes matter
For integrators, the referral code acts as a unique ID in the deBridge ecosystem. Every order sent with the referral code is linked back to the integration,
giving both the integrator and deBridge:
* **Analytics visibility** — see how many orders are being processed from an integration platform, along with the volumes
* **Feature toggles** — activate or deactivate specific features for a specific integration, like [auto-cancellations](/dln-details/affiliates/auto-cancellations)
* **Custom support** — faster debugging and troubleshooting when the referral code is provided
***
## Adding the referral code
When creating an order via the API, include the `referralCode`
[parameter](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#referral-code) in the request.
If integrating via the [Widget](/dln-details/widget/deBridge-widget), the referral code is set via `r=xxxxx` parameter.
## Tracking orders via `referralCode`
Tracking the orders via a referral code is simple, the examples can be seen
[here](/dln-details/integration-guidelines/order-creation/order-tracking-api/tracking-orders#by-referralcode) or on
[GitHub](https://github.com/debridge-finance/api-integrator-example/blob/master/src/scripts/orders/queries/get-orders-by-referral-code.ts).
# Referrers Overview
Source: https://docs.debridge.com/dln-details/affiliates/referrers
Overview of the deBridge Points program and how individual referrers earn and track rewards.
# What is the Points Program?
The points program is an exciting ecosystem initiative we have launched for all our stakeholders, partners, integrators, users, and others to gain
points based on the value and fees they have provided to the deBridge ecosystem.
# How does the referral and tracking process work?
The deBridge referral and tracking process is straightforward and intuitive for integrators, users, and other stakeholders to start tracking the
activity (volume, fees, and transactions) they drive with their specific referral code.
It’s fully on-chain — all the activity that a unique referral code generates can be fully tracked via our [statistics
page](https://app.debridge.com/statistic) after connecting the wallet that has generated the referral/tracking code.
# Individual referrals
If you’ve referred users to deBridge apps, you will get 25% of the points generated by any new users you’ve brought to deBridge. A new user is one who
hasn’t visited our apps before and came to our app for the first time via your unique referral code.
In addition, we want to prevent the possibility for users to do sybiling via self-referrals to get rewards and benefits as that doesn’t have a
positive impact on the deBridge protocol and ecosystem.
# Why does it matter?
We believe anyone who has used deBridge and our applications and/or helped drive activity and volume towards the protocol deserves a share in our
collective and future success. The referring component is an important possibility for anyone to start sharing their links with their follower base,
network, and/or friends, and get some rewards by doing so.
With the points program, we will be granting deBridge points to referrers proportionally to the fees that are being generated for the protocol. Once
again, referrers get 25% of all points from the users they refer.
# Getting started as an individual referrer
Go to [https://app.debridge.com/refer](https://app.debridge.com/refer) and pick Polygon. It is the cheapest option and covers all the supported chains, including Solana. Click
"generate" and your referral code will be displayed on the screen.
Share your referral link publicly and start driving activity towards the deBridge protocol.
Check your accumulated points at [https://explorer.debridge.com/statistic/](https://explorer.debridge.com/statistic/) and follow us on X to stay updated on the latest announcements
from deBridge.
Welcome to deBridge Points, and thanks for helping us spread the word!
# Withdrawing Affiliate Fees
Source: https://docs.debridge.com/dln-details/affiliates/withdrawing-affiliate-fees
Withdrawing Cross-Chain Affiliate Fees and Same-Chain Affiliate Fees
# Cross-Chain Affiliate Fees
Affiliate fees can be specified by any integration using the [DLN API](/dln-details/integration-guidelines/order-creation/authentication) or the [deBridge
Widget](/dln-details/widget/deBridge-widget). The fees are free to be distributed to the designated beneficiary once [liquidity is unlocked by a
solver](/dln-details/dln-specifics/order-fulfillment/claiming-order) from a fulfilled order—typically within a few hours after the order execution.
### EVM chains
On EVM chains, affiliate fees are automatically transferred to the specified beneficiary address as part of the transaction in which the solver
unlocks liquidity. No additional action is required.
An additional consideration is that gas costs for **affiliate fee transfers are capped at 2300 gas**. If the `affiliateFeeRecipient` is a contract that
requires more gas to process the transfer, the affiliate fees will not be sent, but the order will still be processed normally. In those cases,
affiliate fees have to be claimed manually by calling `DlnSource.withdrawUnclaimedAffiliateFees(...)`. The caller can be anyone, but the specified
beneficiary must be the `affiliateFeeRecipient` set in the request.
### Solana
On Solana, affiliate fees must be claimed manually by the beneficiary. This is done by invoking the `withdrawAffiliateFee` method of the DLN program. A
complete working example for claiming affiliate fees in bulk is available
[here](https://github.com/debridge-finance/api-integrator-example/blob/master/src/scripts/affiliates/sol-batch-withdraw.ts).
```typescript theme={null}
import { Solana } from "@debridge-finance/dln-client"
import { Connection, PublicKey, clusterApiUrl } from "@solana/web3.js";
function findAssociatedTokenAddress(wallet: PublicKey, tokenMint: PublicKey)
: [PublicKey, number] {
return PublicKey.findProgramAddressSync(
[wallet.toBytes(),
new PublicKey("TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA").toBytes(),
tokenMint.toBytes()],
new PublicKey("ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL")
);
}
const solanaClient = new Solana.DlnClient(
// Replace with dedicated RPC for production
new Connection(clusterApiUrl("mainnet-beta")),
new PublicKey("src5qyZHqTqecJV4aY6Cb6zDZLMDzrDKKezs22MPHr4"),
new PublicKey("dst5MGcFPoBeREFAA5E3tU5ij8m5uVYwkzkSAbsLbNo"),
new PublicKey("DEbrdGj3HsRsAzx6uH4MKyREKxVAfBydijLUF3ygsFfh"),
new PublicKey("DeSetTwWhjZq6Pz9Kfdo1KoS5NqtsM6G8ERbX4SSCSft"),
)
type Order = {
orderId: string;
beneficiary: PublicKey;
giveToken: PublicKey;
}
// Load the order using known data or fetch via transaction hash
// const order = await solanaClient.getOrderFromTransaction(
// { giveChain: ChainId.Solana, txHash: "CREATE_TX_HASH" }
// );
const order: Order = { /* order data */ };
// Build and send the withdraw transaction
const [associatedTokenAddress] = findAssociatedTokenAddress(
order.beneficiary,
order.giveToken
);
const tx = await solanaClient.source.withdrawAffiliateFee(
order.orderId,
order.beneficiary,
associatedTokenAddress
);
// Send the transaction...
```
# Same-Chain Affiliate Fees
Same-Chain Swaps also support affiliate fees using the same `affiliateFeePercent` and `affiliateFeeRecipient` parameters as cross-chain swaps.
### EVM Chains
Affiliate fees for same-chain swaps on EVM chains are handled automatically during the swap transaction execution. No additional configuration is
required.
### Solana
Earned fees can be claimed via the [Jupiter Referral Dashboard](https://referral.jup.ag/dashboard), as specified in the [affiliate fees
article](/dln-details/affiliates/affiliate-fees#solana).
# Bridging Non-Reserve Assets
Source: https://docs.debridge.com/dln-details/dln-specifics/bridging-non-reserve-assets
Bridging Non-Reserve Assets: Overview and Pre-Order-Swap.
# Overview
The [deBridge Liquidity Network (DLN)](/dln-details/overview/introduction) protocol supports bridging any liquid token from the source
chain to the destination chain, not just [reserve assets](/dln-details/dln-specifics/reserve-assets). While the actions taken by the system are similar to those used
when [bridging reserve assets](/dln-details/dln-specifics/bridging-reserve-assets), the internal flow differs and introduces considerations
that must be communicated clearly for a seamless end-user experience.
```mermaid theme={null}
sequenceDiagram
actor User
participant CreateTx
participant Aggregators
participant ERC20_Contract
participant dln as DlnContracts
rect rgba(230, 230, 255, .15)
Note right of User: Get Transaction
and Estimate
User ->> CreateTx : get(...)
activate CreateTx
CreateTx ->> Aggregators : simulate(...)
activate Aggregators
Aggregators -->> CreateTx : simulation response
deactivate Aggregators
CreateTx -->> User : response
deactivate CreateTx
end
opt inputAssetType == ERC20
User ->> ERC20_Contract : approve(actorAddr, tx.to, amount)
ERC20_Contract -->> User : approve tx receipt
end
User ->> User : sign response.tx
rect rgba(240, 240, 240, .15)
Note right of User: Create Order
Transaction
Note right of User: Atomic
User ->> dln : submit signed response.tx
activate dln
opt inputAssetType == ERC20
dln ->> ERC20_Contract : transferFrom(actorAddr, dlnAddr, amount)
end
dln ->> Aggregators: swap()
dln ->> dln : finishCreatingOrder()
deactivate dln
dln -->> User : transaction receipt
end
```
### Pre-Order-Swap
Cross-chain settlements are executed in [reserve assets](/dln-details/dln-specifics/reserve-assets) to simplify operations for solvers.
As a result, whenever a non-reserve asset is bridged, it must first be swapped into a reserve asset before the order is
created—a process referred to as the **Pre-Order-Swap**.
The `create-tx` API automatically handles this swap step. It queries DeFi aggregators in the background to simulate the swap
and produce `response.tx.calldata` (see step 1a in the diagram). The API is optimized to select the best available rate.
Once a user signs and submits `response.tx`, the DLN smart contracts initiate the process by transferring the approved
non-reserve assets to themselves (step 3a). The actual **Pre-Order-Swap** is executed via an Automated Market Maker (AMM)
(step 3b). Given the potential for price slippage, **the destination chain estimate is based on the minimum amount a user
would receive from the swap**.
If integrators prefer to manage the swap path manually, they can perform the conversion to [reserve assets](/dln-details/dln-specifics/reserve-assets)
themselves before calling the `create-tx` endpoint -- ensuring complete control over the swap route.
This design—basing estimates on the minimum outcome of the **Pre-Order-Swap** -- helps shield users from market volatility and
reduces the likelihood of orders being ignored due to insufficient profitability from a solver's perspective.
Once the swap completes, the [reserve assets](/dln-details/dln-specifics/reserve-assets) are locked within the protocol until the order
is either [fulfilled or cancelled](/dln-details/integration-guidelines/order-creation/order-tracking-api/order-states).
If the order is [cancelled](/dln-details/integration-guidelines/order-creation/cancelling-order), the locked [reserve
assets](/dln-details/dln-specifics/reserve-assets) are returned to the user. It is important to note that the user will receive reserve assets back
\-- not the original non-reserve assets used at the start of the process.
# Bridging Reserve Assets
Source: https://docs.debridge.com/dln-details/dln-specifics/bridging-reserve-assets
Order creation flow and asset handling when bridging reserve assets.
This page outlines the behavior of input assets during order creation and provides a visual representation of the process for creating
an order using reserve assets.
When interacting with the `create-tx` API, the [response]() includes a `tx` field. To create an order, it is sufficient to sign the
transaction and submit it to the network. The `data` field within `tx` contains all necessary instructions for creating an order
on the source chain.
The simplest scenario occurs when bridging [reserve assets](/dln-details/dln-specifics/reserve-assets) from the source chain to the destination chain.
In this case, the order creation process on the initiator’s side consists of three distinct steps:
* Step 1: Call `create-tx` API with the required [parameters]().
* Step 2: After receiving the [response](), call `approve` on the ERC-20 contract of the [reserve assets](/dln-details/dln-specifics/reserve-assets).
The spender should be set to `response.tx.to` value, and the approved amount should match the value specified in the transaction, with [caveats]().
* Note: This step is required only for ERC-20 assets.
* Step 3: Sign response.tx and submit the transaction. This action locks the specified amount of [reserve assets](/dln-details/dln-specifics/reserve-assets)
on the source chain until the order is either [claimed by a solver]() or [cancelled by an authorized entity]().
```mermaid theme={null}
sequenceDiagram
actor User
participant CreateTx
participant Aggregators
participant ERC20_Contract
participant dln as DlnContracts
rect rgba(230, 230, 255, .15)
Note right of User: Get Transaction
and Estimate
User ->> CreateTx : get(...)
activate CreateTx
CreateTx ->> Aggregators : simulate(...)
activate Aggregators
Aggregators -->> CreateTx : simulation response
deactivate Aggregators
CreateTx -->> User : response
deactivate CreateTx
end
opt inputAssetType == ERC20
User ->> ERC20_Contract : approve(actorAddr, tx.to, amount)
ERC20_Contract -->> User : approve tx receipt
end
User ->> User : sign response.tx
rect rgba(240, 240, 240, .15)
Note right of User: Create Order
Transaction
Note right of User: Atomic
User ->> dln : submit signed response.tx
activate dln
opt inputAssetType == ERC20
dln ->> ERC20_Contract : transferFrom(actorAddr, dlnAddr, amount)
end
dln ->> dln : finishCreatingOrder()
deactivate dln
dln -->> User : transaction receipt
end
```
Once these steps are completed, the bridging process from the user's perspective is finished. The next actions involve either
[monitoring the order’s status]() or [initiating cancellation](). Additional details on how solvers fulfill the order on the destination
chain are available [here](/dln-details/dln-specifics/order-fulfillment/order-fulfillment).
# Claiming an Order
Source: https://docs.debridge.com/dln-details/dln-specifics/order-fulfillment/claiming-order
Claim flow for unlocking source-chain assets after fulfillment.
Each `orderId` is deterministic and uniquely identifies an order. To successfully fulfill the order, the solver must use the same parameters that were
specified when the order was originally created. After successful fulfillment, the solver creates another transaction to trigger a cross-chain message
via the deBridge Messaging Protocol (DMP) to the source chain changing the [order
state](/dln-details/integration-guidelines/order-creation/order-tracking-api/order-states) to `SentUnlock`. This message unlocks the input reserve
assets, allowing the solver to claim them.
If any parameters, such as the token amount or beneficiary, differ from the original order, the resulting `orderId` will not match. In such cases,
the solver’s deposit cannot be matched to a valid order on the source chain, rendering the fulfillment ineffective and ensuring the input funds
remain locked and secure on the source chain.
```mermaid theme={null}
sequenceDiagram
actor Solver
participant DlnSource
participant DMP
rect rgba(240, 240, 240, .15)
note right of Solver: Send Unlock
Solver ->> DMP : sendCrossChainMessage(orderId)
activate DMP
DMP -->> Solver : ack
DMP ->> DlnSource : unlockOrder
deactivate DMP
end
rect rgba(230, 230, 255, .15)
note right of Solver: Claim Input Assets
Solver ->> DlnSource : claimOrder(...)
activate DlnSource
DlnSource -->> Solver : claimReceipt
deactivate DlnSource
end
```
To finalize the process, the solver calls the `DlnSource.claimUnlock(...)` method on the source chain. This updates the order status to
`ClaimedUnlock`, and the initially locked order input reserve assets are transferred to the solver. At this point, the order is considered
claimed and fulfilled and its state is `ClaimedUnlock`. Affiliate fees are also automatically paid out on EVM chains, and they are ready
for withdrawal on Solana.
# Detecting an Order
Source: https://docs.debridge.com/dln-details/dln-specifics/order-fulfillment/detecting-order
How solvers detect newly created orders and begin fulfillment.
The sequence diagram below demonstrates how the fulfillment process begins. After a beneficiary successfully creates an order in
`DlnSource` smart contract, a solver will be listening to emitted events.
```mermaid theme={null}
sequenceDiagram
actor Solver
participant DlnSource
participant SimulateService
actor Beneficiary
Beneficiary ->> DlnSource : CreateOrder()
rect rgba(240, 240, 240, .15)
note right of Solver: Simulate Order
DlnSource ->> Solver : CreatedOrder(orderId)
Solver ->> SimulateService : simulateOrder(orderId)
activate SimulateService
SimulateService -->> Solver : simulationResult
deactivate SimulateService
end
```
Solvers will detect the `CreatedOrder` event:
```solidity theme={null}
event CreatedOrder(
Order order,
bytes32 orderId,
bytes affiliateFee,
uint256 nativeFixFee,
uint256 percentFee,
uint32 referralCode
);
```
This event emits an `Order` struct, which provides the information necessary to either fulfill or cancel the order.
Further details about the Order structure can be found here.
Solvers evaluate whether an order is worth fulfilling based on its profitability, which they simulate on their infrastructure.
To ensure orders are attractive to solvers, integrators must configure them so that the spread between input assets and wanted
assets covers all associated costs, including operating expenses and all of the fees. Additional considerations around profitability
are discussed in the following section.
Solvers typically begin by simulating the order to evaluate its profitability. Unprofitable orders are ignored. However, if market conditions
change, solvers may re-simulate previously ignored orders to reassess their viability.
# Fulfilling an Order
Source: https://docs.debridge.com/dln-details/dln-specifics/order-fulfillment/fulfilling-order
Fulfillment steps on the destination chain and related solver actions.
After the `OrderCreated` event is detected, and solvers deem the order profitable, they enter the next stage of the process, illustrated by the green background in the diagram below.
```mermaid theme={null}
sequenceDiagram
actor Solver
participant DlnDestination
participant SwapService
actor Beneficiary
rect rgba(240, 240, 240, .15)
note right of Solver: Fulfil Order (Destination Chain)
Solver ->> DlnDestination : fulfillOrder(...) with reserve assets
activate DlnDestination
alt reserveAssetsWanted == false
note right of DlnDestination: Pre-Fill Swap
DlnDestination ->> SwapService : swapReserveToWanted()
activate SwapService
SwapService -->> DlnDestination : wantedAssets
deactivate SwapService
else
note right of DlnDestination: No swap needed
end
DlnDestination ->> Beneficiary : transferWantedAssets(amount)
DlnDestination -->> Solver : fulfilReceipt
deactivate DlnDestination
end
```
# Order Fulfillment
Source: https://docs.debridge.com/dln-details/dln-specifics/order-fulfillment/order-fulfillment
Order fulfillment steps, solver transactions, and cost considerations for DLN orders.
This page outlines secondary but relevant concepts related to order creation. While not central to the core flow for creating an order,
they are important for transparency and for understanding various fields in the create-tx API response.
Order fulfillment involves three distinct steps:
* Detecting the created order on the source chain
* Fulfilling the order on the destination chain
* Claiming the order on the source chain
In total, a solver performs three transactions during the lifecycle of an order:
* Fulfilling the order on the destination chain
* Sending unlock message via DMP from destination to the source chain
* Claiming the locked order input assets on the source chain
The gas fees associated with those transactions are considered operating costs and should be factored in when creating an order.
```mermaid theme={null}
sequenceDiagram
actor Solver
participant DlnSource
participant SimulateService
participant DlnDestination
participant SwapService
participant DMP
actor Beneficiary
Beneficiary ->> DlnSource : CreateOrder()
rect rgba(240, 240, 240, .15)
note right of Solver: Simulate Order
DlnSource ->> Solver : CreatedOrder(orderId)
Solver ->> SimulateService : simulateOrder(orderId)
activate SimulateService
SimulateService -->> Solver : simulationResult
deactivate SimulateService
end
alt not simulationResult.profitable
note right of Solver: Order Ignored
else simulationResult.profitable
rect rgba(240, 240, 240, .15)
note right of Solver: Fulfil Order (Destination Chain)
Solver ->> DlnDestination : fulfillOrder(...) with reserve assets
activate DlnDestination
alt reserveAssetsWanted == false
note right of DlnDestination: Pre-Fill Swap
DlnDestination ->> SwapService : swapReserveToWanted()
activate SwapService
SwapService -->> DlnDestination : wantedAssets
deactivate SwapService
else
note right of DlnDestination: No swap needed
end
DlnDestination ->> Beneficiary : transferWantedAssets(amount)
DlnDestination -->> Solver : fulfilReceipt
deactivate DlnDestination
end
rect rgba(240, 240, 240, .15)
note right of Solver: Send Unlock
Solver ->> DMP : sendCrossChainMessage(orderId)
activate DMP
DMP -->> Solver : ack
DMP ->> DlnSource : unlockOrder
deactivate DMP
end
rect rgba(230, 230, 255, .15)
note right of Solver: Claim Input Assets
Solver ->> DlnSource : claimOrder(...)
activate DlnSource
DlnSource -->> Solver : claimReceipt
deactivate DlnSource
end
end
```
# Pre-Fill Swap
Source: https://docs.debridge.com/dln-details/dln-specifics/order-fulfillment/pre-fill-swap
Pre-fill swap behavior for reserve assets before destination transfer.
Solvers exclusively hold reserve assets to simplify accounting and minimize risk exposure. The Pre-Fill-Swap section is highlighted in the diagram
below. It illustrates an intermediary step in order fulfillment process that occurs **when requested assets are not [reserve
assets](dln-details/dln-specifics/reserve-assets)**.
```mermaid theme={null}
sequenceDiagram
participant DlnDestination
participant SwapService
actor Beneficiary
activate DlnDestination
alt reserveAssetsWanted == false
note right of DlnDestination: Pre-Fill Swap
DlnDestination ->> SwapService : swapReserveToWanted()
activate SwapService
SwapService -->> DlnDestination : wantedAssets
deactivate SwapService
else
note right of DlnDestination: No swap needed
end
DlnDestination ->> Beneficiary : transferWantedAssets(amount)
deactivate DlnDestination
```
When the order requests [reserve assets](dln-details/dln-specifics/reserve-assets), this swap step is skipped, as solvers are expected to maintain
sufficient balances of reserve assets at all times.
The DLN supports requesting arbitrary assets on the destination chain. When **requested assets are not reserve assets**, the solver performs a
**Pre-Fill-Swap**, which is similar in concept to a [Pre-Order-Swap](/dln-details/dln-specifics/bridging-non-reserve-assets#pre-order-swap), but
reversed. In this case, the solver swaps [reserve assets](dln-details/dln-specifics/reserve-assets) for the requested assets and transfers the
guaranteed amount to the beneficiary address on the destination chain specified in the order.
# Reserve Assets
Source: https://docs.debridge.com/dln-details/dln-specifics/reserve-assets
What reserve assets are and how solvers use them in DLN.
[deBridge Liquidity Network (DLN)](/dln-details/overview/introduction) operates as a free and competitive market where solvers fulfill cross-chain
orders if doing so is profitable. Solvers are responsible for covering the order execution costs (gas fees). These costs include
transferring the bridged assets to the beneficiary on the destination chain, as well as the fees required to claim the assets that were
initially bridged by the user on the source chain. These combined expenses constitute the [operating expenses](/dln-details/overview/fee-structure) for solvers.
Although DLN enables the bridging of arbitrary liquid assets across supported networks, settlement between chains is always performed
in a limited set of predefined tokens known as reserve assets.
To reduce operational complexity, DLN is designed such that solvers only need to maintain liquidity in a small set of reserve assets.
These assets currently include:
* ETH on Ethereum, Arbitrum, Base, and Linea
* wETH on Avalanche, BNB Chain, and Polygon
* USDC (issued by Circle Inc.) on all DLN-supported chains
* USDT on TRON
This model ensures reliable settlement and minimizes the capital management burden on solvers while still supporting a wide variety of
bridged tokens. Further details about operating costs and fees are available [here](/dln-details/overview/fees-supported-chains).
In most cases, USDC will be used. If the reserve asset on one chain is USDC, but on another it is ETH or wETH, USDC will be used on both the source
and destination chains.
# Authentication
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/authentication
Authentication requirements and rate limits for the DLN API.
The DLN API is open to everyone with a limited RPS and doesn't require authentication. To make sure we keep delivering a
high-quality service, we've introduced a requirement for commercial integrations to authenticate requests with dedicated API keys.
Please fill in [the Authentication Request form](https://forms.gle/doWLQpr8oemphoaf9) so we can provide you with a dedicated API
key and custom limits.
[https://forms.gle/doWLQpr8oemphoaf9](https://forms.gle/doWLQpr8oemphoaf9)
## Rate Limits
deBridge Liquidity Network API offers generous RPM limits for unauthenticated requests, but authenticated requests with API keys
receive significantly higher limits. This ensures that commercial integrations can operate smoothly without hitting rate limits
while still allowing developers to experiment and build with the API.
| Authentication Status | Rate Limit (RPM) |
| --------------------- | ---------------- |
| Unauthenticated | 50 |
| Authenticated | 300 |
More details on how to use your API key and the benefits of authentication can be found in the [API documentation](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#authentication).
# Cancelling an Order
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/cancelling-order
Handling an unfulfilled order – cancellations on the destination chain, response payload, and important considerations.
It can be the case that the given order remains unfulfilled for a prolonged period of time. The reason for this may be that the order became
unprofitable, and no one is willing to fulfill it. In this case, the order must be cancelled to unlock the input amount of funds.
[Limit orders](/dln-details/integration-guidelines/order-creation/creating-order/quoting-strategies#limit-order-not-recommended) have a high potential
of remaining unfulfilled for prolonged periods of time, until the market conditions are met. One example of such an order is a [0.01 SOL for 20.000
POL limit order](https://app.debridge.finance/order?orderId=0x5aa527db4bb244bb30b05d443db3370e42d29c4a1364601deb54e632f7c70c51) which was created for
demonstration purposes of this article.
The only way to cancel the order is to initiate the cancellation procedure on the chain it was intended to be fulfilled on (the `dstChainId` parameter
from `create-tx` call payload). During the cancellation process, the order enters a `OrderCancelled`
[state](/dln-details/integration-guidelines/order-creation/order-tracking-api/order-states#order-states), which prevents fulfillment. A cross-chain
message is sent through the deBridge cross-chain messaging infrastructure to the DLN contract on the source chain to unlock the given funds. **The
funds locked on the source chain are returned in full including affiliate and protocol fees**.
The cancellation procedure can only be initiated by the `dstChainOrderAuthorityAddress` in a separate transaction on the destination chain. Such
transaction can be requested by calling the `/v1.0/dln/order/:id/cancel-tx` endpoint:
```
https://dln.debridge.finance/v1.0/dln/order/0x5aa527db4bb244bb30b05d443db3370e42d29c4a1364601deb54e632f7c70c51/cancel-tx
```
This gives the response from which the transaction data can be extracted to be signed and broadcasted to the destination chain, described by the
following TypeScript type:
```typescript theme={null}
export type CancelTxResponsePayload = {
cancelBeneficiary: string; // Source chain input funds recipient after cancellation
chainId: number; // Chain to submit on
data: string; // TX data
from: string; // Allowed tx sender address
to: string; // TX `to`
value: string; // TX `value`
}
```
Detailed runnable script on how to cancel an order is available in [the accompanying examples
repository](https://github.com/debridge-finance/api-integrator-example/blob/master/src/scripts/orders/cancellation/cancel-order.ts).
Several considerations:
* the transaction can be submitted only to the chain where the order has been intended to be fulfilled on, designated with `chainId` field in the response
* the transaction call would be accepted only if made by the `dstChainOrderAuthorityAddress` specified during the given order creation, designated
with `from` field in the response
* the funds locked on the source chain upon order creation are returned to the `srcChainOrderAuthorityAddress` specified during the given order
creation, designated with the `cancelBeneficiary` response field
* the `value` for the transaction is always positive, needed to cover:
* the deBridge cross-chain messaging protocol fee (measured in the blockchain native currency where the message is being sent from) to make a
cancellation message accepted. Consider looking at [the list of supported chains and fees](/dmp-details/dmp/fees-supported-chains) and [details on
retrieving the deBridge protocol fee](dln-details/integration-guidelines/smart-contracts/placing-orders);
* a small amount to cover the gas on the source chain, which gives an incentive to keepers for the successful claim of the cross-chain message on
the source chain. In other words, this is a prepayment for potential gas expenses, that will be transferred by the protocol.
## Further reading
* [Automatic Cancellations](/dln-details/affiliates/auto-cancellations)
# API Parameters
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters
List of API parameters and descriptions. Deep dive into certain parameters.
Below is a succinct breakdown of the parameters used in the `create-tx` API endpoint. Detailed descriptions and usage examples are
provided in dedicated subpages.
## Notable API Categories
There are several categories of parameters that are particularly important to understand when working with the `create-tx`
endpoint:
### Authentication
| **Parameter** | **Example Value** | **Description** |
| ------------- | ----------------- | ----------------------------------- |
| `accesstoken` | `xx789x` | Access token generated by deBridge. |
### Directional Parameters
These parameters define the origin and destination of the transaction, including the assets being sold on the source chain and the
assets being purchased on the destination chain.
| **Parameter** | **Example Value** | **Description** |
| ------------------ | -------------------------------------------- | ---------------------------------------------------- |
| `srcChainId` | `56` | Internal chainId of the supported source chain. |
| `srcChainTokenIn` | `0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d` | Input asset address (what the user sells). |
| `dstChainId` | `43114` | Internal chainId of the supported destination chain. |
| `dstChainTokenOut` | `0x9702230A8Ea53601f5cD2dc00fDBc13d4dF4A8c7` | Output asset address (what the user buys). |
### Offer Parameters
These parameters specify the amounts of tokens to be sold and received. The API can also be configured to automatically determine
the output amount to ensure a reasonably profitable market order.
| **Parameter** | **Example Value** | **Description** |
| ------------------------- | --------------------------------- | ---------------------------------------------------------------------------------------------- |
| `srcChainTokenInAmount` | `100000000000000000000` or `auto` | Amount of input token (with decimals). Can be `auto` if `dstChainTokenOutAmount` is specified. |
| `dstChainTokenOutAmount` | `auto` or `100000000000000000000` | Amount of output token. Recommended to use `auto` for optimal solver matching. |
| `prependOperatingExpense` | `true` | Adds estimated operating expense to input token. Recommended for better UX. |
### Authorities and Recipient Address
Optional parameters defining entities authorized to patch/cancel the order, and the recipient of funds on fulfillment. Typically
user addresses are used.
> These parameters are optional. However, omitting them means the API won't return a signable transaction payload until wallet
> connection.
**Ensure** `dstChainOrderAuthorityAddress` is user-accessible — otherwise funds may become inaccessible.
| **Parameter** | **Example Value** | **Description** |
| ------------------------------- | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `srcChainOrderAuthorityAddress` | `0xd8dA...ABCD` or `862oLANN...` | Set the source chain authority address to the user's address. Used as fallback for [`srcAllowedCancelBeneficiary`](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#cancellation-beneficiary) if the latter is not set explicitly. |
| `dstChainOrderAuthorityAddress` | `0xd8dA...ABCD` or `862oLANN...` | Can cancel order on destination chain. **Must be controlled by the user.** |
| `dstChainTokenOutRecipient` | `0xd8dA...ABCD` or `862oLANN...` | Recipient of funds on destination chain after fulfillment. Typically the user's address. |
### Affiliate Fee Parameters
These settings define the affiliate fee recipient and amount.
| **Parameter** | **Example Value** | **Description** |
| ----------------------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| `affiliateFeePercent` | `0.1` | Percentage of input amount to assign as affiliate fee. |
| `affiliateFeeRecipient` | `0xd8dA...ABCD` or `862oLANN...` | Address (EVM) or pubkey (Solana) that will receive affiliate fees once order reaches `ClaimUnlocked` state. |
### Referral Code
Optional tracking and reward parameter.
| **Parameter** | **Example Value** | **Description** |
| -------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `referralCode` | `31805` | Integrator's referral code. [Can be generated in-app](/dln-details/affiliates/integrators#how-to-make-sure-your-integration-activity-is-accounted-for%3F). |
### Cancellation Beneficiary
Optional parameters, but required for [auto-cancellations](/dln-details/affiliates/auto-cancellations) to work.
| **Parameter** | **Example Value** | **Description** |
| ----------------------------- | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `srcAllowedCancelBeneficiary` | `0xd8dA...ABCD` or `862oLANN...` | Address receiving the source chain input funds in an event of cancellation. More information available in the [auto-cancellations article](/dln-details/affiliates/auto-cancellations). |
### Transaction Estimation
For EVM chains, the API can be configured to validate the resulting transaction and provide an estimate of its gas consumption.
This is particularly useful for ensuring that all of the conditions for executing the transaction are met before submission, such
as sufficient token balances and approvals.
| **Parameter** | **Example Value** | **Description** |
| ---------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `enableEstimate` | `true` or `false` | Forces the API to validate the resulting transaction and estimate its gas consumption. When enabled, the estimate is returned at `tx.gasLimit` in the response object. |
To estimate a transaction, `senderAddress` must be set to the address that will execute it. This address must hold:
* Enough of the input token to cover `srcChainTokenInAmount`
* Enough native currency to cover the protocol [fixed fee](/dln-details/overview/fee-structure#fixed-fee)
If `srcChainTokenIn` is an ERC-20 token, an approval must be provided for the specified `srcChainTokenInAmount` to the spender
specified in the
[`tx.to` from the response](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/response#tx)
**before** the endpoint is called.
Failing to provide a valid approval will result in an error response.
### Solana-Specific Parameters
| **Parameter** | **Example Value** | **Description** |
| ------------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `skipSolanaRecipientValidation` | `true` or `false` | When set to `true`, skips the validation of the Solana `dstChainTokenOutRecipient` address. The validation is in place to prevent accidental loss of funds. Might be necessary when the recipient address is a program-derived address (PDA) or a multi-sig. |
## Example Request
The following example shows a complete `create-tx` API request:
> [https://dln.debridge.finance/v1.0/dln/order/create-tx?srcChainId=56 \&srcChainTokenIn=0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d \&srcChainTokenInAmount=100000000000000000000\&dstChainId=43114 \&dstChainTokenOut=0x9702230A8Ea53601f5cD2dc00fDBc13d4dF4A8c7 \&dstChainTokenOutAmount=auto \&dstChainTokenOutRecipient=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 \&srcChainOrderAuthorityAddress=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 \&dstChainOrderAuthorityAddress=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 \&affiliateFeePercent=0.1 \&affiliateFeeRecipient=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045](https://dln.debridge.finance/v1.0/dln/order/create-tx?srcChainId=56\&srcChainTokenIn=0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d\&srcChainTokenInAmount=100000000000000000000\&dstChainId=43114\&dstChainTokenOut=0x9702230A8Ea53601f5cD2dc00fDBc13d4dF4A8c7\&dstChainTokenOutAmount=auto\&dstChainTokenOutRecipient=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045\&srcChainOrderAuthorityAddress=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045\&dstChainOrderAuthorityAddress=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045\&affiliateFeePercent=0.1\&affiliateFeeRecipient=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045)
This request demonstrates how all core parameters are combined to generate a valid and executable cross-chain order.
# Deep Dive
Reference to common and interesting use-cases. Deep dive into certain parameters.
### Estimation Only
The `create-tx` endpoint is designed for both estimation and transaction construction. It can be safely called without specifying
[authority or recipient addresses](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#authorities-and-recipient-address)
when a wallet address is not yet available—for example, during early stages of interaction in a dApp. In such cases, the endpoint
can still be used to suggest input or output token amounts.
Once the wallet address becomes available, the same `create-tx` request can be repeated with the necessary parameters to retrieve
a [full transaction call](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/response#tx).
To maintain solver profitability and ensure the order remains valid upon submission, it is recommended to allow the API to compute
a reasonable output amount. This is achieved by setting the `dstChainTokenOutAmount` parameter to `auto` in both the estimation
and transaction calls.
Additionally, orders should be submitted within 30 seconds of retrieving the transaction from the API. This expiration window
helps ensure the order remains profitable for solvers at the time of on-chain placement.
### `prependOperatingExpenses`
The prependOperatingExpenses setting is a boolean. It is recommended to enable this option:
```
prependOperatingExpenses = true
```
#### Enabled (prependOperatingExpenses=true)
When enabled, operating expenses are calculated separately from the spread and added on top of the input token amount, making all
fees fully transparent. This approach helps clarify exactly what is being paid in fees.
For example, swapping 100 USDC on Arbitrum for 100 USDC on Polygon in our application displays a small fee (just over \$0.03),
shown above the red line in the figure below. This represents the solver's operating expenses.
![Prepend Operating Expenses]()
* **ERC20 Approval**: The total amount (including operating expenses) must be approved using the `approve` function. This value is
provided in `response.estimation.srcChainTokenIn.amount`.
* **Buffer Recommendations**: Estimates may need to be refreshed if there is a delay between generating the response and
submitting `response.tx`. Updated operating expenses might require a new approval.
* **Fulfillment Likelihood**: When `response.tx` is signed and submitted within 30 seconds, the probability of successful
execution is over 99.9%.
#### Disabled (prependOperatingExpenses=false)
When disabled, `response.estimation.srcChainTokenIn.amount` equals the `srcChainTokenInAmount` specified in the original
`create-tx` request. In this case, the
[operating expenses](/dln-details/overview/fee-structure#runtime-costs-built-into-the-spread) are subtracted directly from the
spread between the input value and `response.estimation.dstChainTokenOut`.
In this case, an additional error should be covered. It occurs when the input amount is too small to pay for the order costs.
```json theme={null}
{
"errorCode": 12,
"errorId": "ERROR_LOW_GIVE_AMOUNT",
"errorMessage": "Given amount of input asset is too small to cover operational costs of Takers, cannot estimate reasonable outcome of an order",
"reqId": "79a2c431-e52c-48c0-a12e-2a9960644a59"
}
```
[Sample error request](https://dln.debridge.finance/v1.0/dln/order/create-tx?prependOperatingExpenses=false\&dstChainTokenOutAmount=auto\&srcChainId=137\&dstChainId=42161\&srcChainTokenIn=0x3c499c542cef5e3811e1192ce70d8cc03d5c3359\&dstChainTokenOut=0xaf88d065e77c8cc2239327c5edb3a432268e5831\&srcChainOrderAuthorityAddress=0x55a8f5cce1d53d9ff84ec0962882b447e5914db8\&dstChainOrderAuthorityAddress=0x55a8f5cce1d53d9ff84ec0962882b447e5914db8\&dstChainTokenOutRecipient=0x55a8f5cce1d53d9ff84ec0962882b447e5914db8\&srcChainTokenInAmount=100000\&referralCode=31085\&senderAddress=0x55a8f5cce1d53d9ff84ec0962882b447e5914db8).
Both modes produce the same execution outcome, but enabling `prependOperatingExpenses` typically provides a clearer breakdown of
the fee structure for end users.
### Minimum Input Amounts
When creating an order with Solana as the destination chain and when `dstChainTokenOut` is
[SOL](/dln-details/integration-guidelines/order-creation/creating-order/specifying-assets#sol-native-sol), the required minimum
output amount for SOL is **0.001 (1000000 lamports)**.
This is due to the minimum balance requirement for SOL accounts on the Solana network, which ensures that accounts remain
rent-exempt and can cover transaction fees.
Due to shifting market conditions, the minimum input amount for tokens on the source chain may vary.
It is recommended to determine the minimum input amount for a given token by creating a
[reverse-market order](/dln-details/integration-guidelines/order-creation/creating-order/quoting-strategies#reverse-market-order)
with the `dstChainTokenOutAmount` set to `1000000` and the `srcChainTokenInAmount` set to `auto`.
This approach allows following the market conditions, without hardcoding specific minimum input amounts for each token.
# API Response
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/response
Detailed descriptions of the `create-tx` API response structure.
There are several sections to a `create-tx` response. You can see a full, real-world API response example
[here](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/response-example).
They are:
## USD Value Fields
The response contains several fields that provide estimated USD values for the assets involved in the trade. These fields are for
informational purposes only and are not intended for real-time trading decisions.
### `usdPriceImpact`
Estimated price impact of the trade, expressed as a input amount USD value percentage. Can be both postive and negative, depending
on the direction of the USD price movement caused by the trade.
When the value is high, it is strongly advised to let the user know about the potential price impact of their trade. The exact
threshold for what constitutes a "high" value may vary depending on the specific use case and user preferences.
### `protocolFee`
Estimated fee charged by the DLN protocol for facilitating the trade. Equal to `costDetails` entry with `type` `DlnProtocolFee`
`payload.feeAmount` value.
### `protocolFeeApproximateUsdValue`
Estimated USD value of the `protocolFee`. For informative purposes only – not for real-time trading.
## `estimation`
This field contains gas and fee-related estimates used in the transaction planning process.
## `srcChainTokenIn`
This field is always present. Represents the structure of what the user wants to sell on the source chain.
| **Field Name** | **Type** | **Description** |
| ----------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| `address` | `string` | Source chain input asset address – what the user is trying to sell on the source chain. |
| `chainId` | `integer` | Source chain ID. |
| `decimals` | `integer` | Source chain input asset decimals. |
| `name` | `string` | Source chain input asset name. |
| `symbol` | `string` | Source chain input asset symbol. |
| `amount` | `string` | Source chain input asset amount, taking the decimals into account. May differ from `srcChainTokenInAmount` if operating expenses were prepended. |
| `approximateOperatingExpense` | `string` | Solver's operating expense for this swap. |
| `mutatedWithOperatingExpense` | `boolean` | Signifies if the request had prepended operating expenses. |
| `approximateUsdValue` | `integer` | Approximate USD value of the source chain input assets. For informative purposes only – not for real-time trading. |
| `originApproximateUsdValue` | `integer` | Approximate USD value before operating expenses were prepended. Only present if the input asset was **not** a reserve asset. |
***
## `srcChainTokenOut` *(optional)*
This field is only present if the input asset was not a reserve asset and had to be
[pre-swapped](/dln-details/dln-specifics/bridging-non-reserve-assets#pre-order-swap).
| **Field Name** | **Type** | **Description** |
| --------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `address` | `string` | Source chain output asset address – what the input asset was swapped for during the [pre-order-swap](/dln-details/dln-specifics/bridging-non-reserve-assets#pre-order-swap). |
| `chainId` | `integer` | Source chain ID. |
| `decimals` | `integer` | Source chain output asset decimals. |
| `name` | `string` | Source chain output asset name. |
| `symbol` | `string` | Source chain output asset symbol. |
| `amount` | `string` | Source chain output asset amount, taking the decimals into account. |
| `maxRefundAmount` | `string` | Solver’s maximum refundable operating expense. |
| `approximateUsdValue` | `integer` | Approximate USD value of the output asset. For informative purposes only – not for real-time trading. |
***
## `dstChainTokenOut`
This field is always present. Represents the structure of what the user wants to receive on the destination chain.
| **Field Name** | **Type** | **Description** |
| ----------------------------------- | --------- | ---------------------------------------------------------------------------------------------------- |
| `address` | `string` | Destination chain output asset address – what the user wants to receive when the order is fulfilled. |
| `chainId` | `integer` | Destination chain ID. |
| `decimals` | `integer` | Destination chain output asset decimals. |
| `name` | `string` | Destination chain output asset name. |
| `symbol` | `string` | Destination chain output asset symbol. |
| `amount` | `string` | Destination chain output asset amount, taking the decimals into account. |
| `approximateUsdValue` | `integer` | Approximate USD value of the output asset `amount`. Informative only. |
| `recommendedAmount` | `string` | Recommended output asset amount, considering fees and taker margin. |
| `recommendedApproximateUsdValue` | `integer` | Approximate USD value of `recommendedAmount`. Informative only. |
| `maxTheoreticalAmount` | `string` | The maximum theoretical output amount that users can receive. |
| `maxTheoreticalApproximateUsdValue` | `integer` | Approximate USD value of `maxTheoreticalAmount`. Informative only. |
## `costDetails`
An array describing the cost components associated with the trade. Each entry has a `type` field. Possible cost types include:
* `PreSwap`
* `PreSwapEstimatedSlippage`
* `DlnProtocolFee`
* `TakerMargin`
* `EstimatedOperatingExpenses`
* `AfterSwap`
* `AfterSwapEstimatedSlippage`
Each of the fields in the `costDetails` entries, aside from `PreSwap` and `AfterSwap`, has the `payload.feeAmount` field, which is
a string representing the fee amount, specified in the base (smallest) units of the asset (e.g., wei for Ethereum).
All the `costDetails` entries have `chainId`, `tokenIn`, `tokenOut`, `amountIn`, `amountOut`.
Cost details can be used to break down the various fees and costs associated with the trade, providing transparency and insights
into how the final amounts are calculated. This can be particularly useful for users and integrators to understand the fee
structure and make informed decisions about their trades.
## **`tx`**
Only `data` field is present for Solana, while all the fields are present for EVM-based chains.
* `data`: The data that must be signed and submitted. It contains all necessary information to initiate a
[cross-chain order](/dln-details/dln-specifics/bridging-reserve-assets), including cases involving
[non-reserve assets](/dln-details/dln-specifics/bridging-non-reserve-assets). It is either a calldata (for EVM-based chains) or
a serialized transaction (for Solana).
* `to`: Destination address for the transaction. Acts as the spender in the `approve` call for ERC-20 tokens. Applicable to EVM
source chains only.
* `value`: [Flat fee](/dln-details/overview/fees-supported-chains) in the source chain's native currency charged by the DLN
protocol. Applicable to EVM source chains only.
* `gasLimit`: Simulated, estimated gas limit for the transaction for EVM chains. Present if
[`enableEstimate` flag](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#transaction-estimation)
was set to `true` in the request.
## **`prependedOperatingExpenseCost`**
Estimated operating cost added to the transaction, adjusted for token decimals. Present only if the request was made with
`prependOperatingExpenses` enabled.
## **`order`**
An object containing details required to facilitate the cross-chain trade.
* **`approximateFulfillmentDelay`**\
Estimated delay, in seconds, for the order to be fulfilled.
* **`salt`**\
Randomized value used to ensure uniqueness in the order hash.
* **`metadata`**\
Additional contextual information about the order.
## **`orderId`**
A deterministic identifier for the order. The same ID is used on both source and destination chains and can be used to
[track order status](/dln-details/integration-guidelines/order-creation/order-tracking-api/tracking-orders).
## **`fixFee`**
[Flat fee](/dln-details/overview/fees-supported-chains) charged in the source chain's native currency. This matches `tx.value` for
EVM-based chains.
## **`userPoints`**
The number of deBridge points that the user will get for this trade.
## **`integratorPoints`**
The number of deBridge points that the integrator will get for this trade.
## **`estimatedTransactionFee`**
Estimated transaction fee for the source chain, expressed in the source chain's native currency. This is an estimate of the gas
cost for executing the transaction.
For both Solana and EVM-based chains, the `estimatedTransactionFee` field contains a `total` – in wei for EVM-chains or lamports
for Solana, and a breakdown of the fee components in the `details` object.
## Solana
For Solana, `estimatedTransactionFee.details` fields are:
| Field | Value (lamports) | Comment | SolScan Link |
| ----------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| `nonceMaster` | `1002240` | Unique for each user - only paid once, the first time users create a deBridge order. | [Link](https://solscan.io/account/Bah1BsjAHVYWV6hNgnQ72g9eFGBuWkeuETdQwtMUGqbD#transfers). |
| `giveOrderState` | `17115840` | Give order state account rent and [`fixedFee`](/dln-details/overview/fees-supported-chains) | [Link](https://solscan.io/account/DSbotE7UyqU2yGAGbj1Xkd4WMsMeAaVHaokvLL7LL8Ka). |
| `giveOrderWallet` | `2039280` | Give order wallet rent. | [Link](https://solscan.io/account/CoZPnKSCF2iLVuHozE56wwffL2mRFtjaxdWfUe23sqkN). |
| `txFee` | `5000` | Transaction fee for the Solana network. | |
| `priorityFee` | `4000000` | Can be updated by partners. [Example](https://github.com/debridge-finance/api-integrator-example/blob/master/src/utils/solana.ts). [Update function](https://github.com/debridge-finance/api-integrator-example/blob/master/src/utils/index.ts#L136C17-L136C34). | |
| **total** | **24162360** | Total costs, without updating the priority fee. | |
## EVM
For EVM-based chains, `estimatedTransactionFee.details` fields are:
* `gasLimit`
* `baseFee`
* `maxFeePerGas`
* `maxPriorityFeePerGas`
Unlike for Solana, EVM `fixedFee` is not included in the `estimatedTransactionFee.total` value, as it is placed separately as
`tx.value` in the transaction.
# Response Example
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/response-example
Example create-tx response showing key fields and values.
If we take a look at request below, where we are trading 1000 ARB on Arbitrum for Matic on Polygon, it will produce the following JSON response.
> [https://dln.debridge.finance/v1.0/dln/order/create-tx?srcChainId=42161
> \&srcChainTokenIn=0x912ce59144191c1204e64559fe8253a0e49e6548
> \&srcChainTokenInAmount=1000000000000000000000
> \&dstChainId=137
> \&dstChainTokenOut=0x0000000000000000000000000000000000000000
> \&dstChainTokenOutAmount=auto
> \&dstChainTokenOutRecipient=0x55A8f5cce1d53D9Ff84EC0962882b447E5914dB8
> \&srcChainOrderAuthorityAddress=0x55A8f5cce1d53D9Ff84EC0962882b447E5914dB8
> \&dstChainOrderAuthorityAddress=0x55A8f5cce1d53D9Ff84EC0962882b447E5914dB8
> \&senderAddress=0x55A8f5cce1d53D9Ff84EC0962882b447E5914dB8
> \&prependOperatingExpenses=true
> \&affiliateFee=0.1
> \&affiliateFeeBeneficiary=0x55A8f5cce1d53D9Ff84EC0962882b447E5914dB8
> \&referralCode=31805](https://dln.debridge.finance/v1.0/dln/order/create-tx?srcChainId=42161\&srcChainTokenIn=0x912ce59144191c1204e64559fe8253a0e49e6548\&srcChainTokenInAmount=1000000000000000000000\&dstChainId=137\&dstChainTokenOut=0x0000000000000000000000000000000000000000\&dstChainTokenOutAmount=auto\&dstChainTokenOutRecipient=0x55A8f5cce1d53D9Ff84EC0962882b447E5914dB8\&srcChainOrderAuthorityAddress=0x55A8f5cce1d53D9Ff84EC0962882b447E5914dB8\&dstChainOrderAuthorityAddress=0x55A8f5cce1d53D9Ff84EC0962882b447E5914dB8\&senderAddress=0x55A8f5cce1d53D9Ff84EC0962882b447E5914dB8\&prependOperatingExpenses=true\&affiliateFee=0.1\&affiliateFeeBeneficiary=0x55A8f5cce1d53D9Ff84EC0962882b447E5914dB8\&referralCode=31805)
```json theme={null}
{
"estimation": {
"srcChainTokenIn": {
"address": "0x912ce59144191c1204e64559fe8253a0e49e6548",
"chainId": 42161,
"decimals": 18,
"name": "Arbitrum",
"symbol": "ARB",
"amount": "1000097362178910640486",
"approximateOperatingExpense": "97362178910640486",
"mutatedWithOperatingExpense": true,
"approximateUsdValue": 337.491121850529,
"originApproximateUsdValue": 337.458266178442
},
"srcChainTokenOut": {
"address": "0xaf88d065e77c8cc2239327c5edb3a432268e5831",
"chainId": 42161,
"decimals": 6,
"name": "USD Coin",
"symbol": "USDC",
"amount": "336778910",
"maxRefundAmount": "1182866",
"approximateUsdValue": 336.77891
},
"dstChainTokenOut": {
"address": "0x0000000000000000000000000000000000000000",
"chainId": 137,
"decimals": 18,
"name": "Polygon",
"symbol": "MATIC",
"amount": "1414379129275580318365",
"recommendedAmount": "1414379129275580318365",
"maxTheoreticalAmount": "1427196423556434769924",
"approximateUsdValue": 334.305266698456,
"recommendedApproximateUsdValue": 334.305266698456,
"maxTheoreticalApproximateUsdValue": 337.334786078531
},
"costsDetails": [
{
"chain": "42161",
"tokenIn": "0x912ce59144191c1204e64559fe8253a0e49e6548",
"tokenOut": "0xaf88d065e77c8cc2239327c5edb3a432268e5831",
"amountIn": "1000097362178910640486",
"amountOut": "337961776",
"type": "PreSwap"
},
{
"chain": "42161",
"tokenIn": "0xaf88d065e77c8cc2239327c5edb3a432268e5831",
"tokenOut": "0xaf88d065e77c8cc2239327c5edb3a432268e5831",
"amountIn": "337961776",
"amountOut": "336778910",
"type": "PreSwapEstimatedSlippage",
"payload": {
"feeAmount": "1182866",
"feeBps": "35",
"estimatedVolatilityBps": "35"
}
},
{
"chain": "42161",
"tokenIn": "0xaf88d065e77c8cc2239327c5edb3a432268e5831",
"tokenOut": "0xaf88d065e77c8cc2239327c5edb3a432268e5831",
"amountIn": "336778910",
"amountOut": "336644199",
"type": "DlnProtocolFee",
"payload": {
"feeAmount": "134711",
"feeBps": "4",
"feeApproximateUsdValue": "0.134711"
}
},
{
"chain": "137",
"tokenIn": "0x3c499c542cef5e3811e1192ce70d8cc03d5c3359",
"tokenOut": "0x3c499c542cef5e3811e1192ce70d8cc03d5c3359",
"amountIn": "336644199",
"amountOut": "336509542",
"type": "TakerMargin",
"payload": {
"feeAmount": "134657",
"feeBps": "4"
}
},
{
"chain": "137",
"tokenIn": "0x3c499c542cef5e3811e1192ce70d8cc03d5c3359",
"tokenOut": "0x3c499c542cef5e3811e1192ce70d8cc03d5c3359",
"amountIn": "336509542",
"amountOut": "336476680",
"type": "EstimatedOperatingExpenses",
"payload": {
"feeAmount": "32862"
}
},
{
"chain": "137",
"tokenIn": "0x3c499c542cef5e3811e1192ce70d8cc03d5c3359",
"tokenOut": "0x0000000000000000000000000000000000000000",
"amountIn": "336476680",
"amountOut": "1422201236073987248230",
"type": "AfterSwap",
"payload": {
"amountOutBeforeCorrection": "1422201236073987248230"
}
},
{
"chain": "137",
"tokenIn": "0x0000000000000000000000000000000000000000",
"tokenOut": "0x0000000000000000000000000000000000000000",
"amountIn": "1422201236073987248230",
"amountOut": "1414379129275580318365",
"type": "AfterSwapEstimatedSlippage",
"payload": {
"feeAmount": "7822106798406929865",
"feeBps": "55",
"estimatedVolatilityBps": "55"
}
}
],
"recommendedSlippage": 0.9
},
"tx": {
"value": "1000000000000000",
"data": "0x4d8160ba000000000000000000000000912ce59144191c1204e64559fe8253a0e49e654800000000000000000000000000000000000000000000003637239428a726d96600000000000000000000000000000000000000000000000000000000000001400000000000000000000000006131b5fae19ea4f9d964eac0408e4408b66337b50000000000000000000000000000000000000000000000000000000000000160000000000000000000000000af88d065e77c8cc2239327c5edb3a432268e5831000000000000000000000000000000000000000000000000000000001412d69e00000000000000000000000055a8f5cce1d53d9ff84ec0962882b447e5914db8000000000000000000000000ef4fb24ad0916217251f553c0596f8edc630eb660000000000000000000000000000000000000000000000000000000000000940000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007a4e21fd0e90000000000000000000000000000000000000000000000000000000000000020000000000000000000000000c7d3ab410d49b664d03fe5b1038852ac852b1b29000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000002a000000000000000000000000000000000000000000000000000000000000004e000000000000000000000000000000000000000000000000000000000000001c402020000003d0200000011d53ec50bc8f54b9357fbfe2a7de034fc00f8b3000000000000000d8dc8e50a29c9b65e0100000000000000000000000000000000000000000a0000002e020000006f38e884725a116c9c7fbf208e79fe8828a2595f010100000000000000000000000000000001000276a40a020000003d020000006ce9bc2d8093d32adde4695a4530b96558388f7e0000000000000028a95aaf1e7d5d23080100000000000000000000000000000000000000000a0000006102000000b1026b8e7276e7ac75410f1fcbbe21796e8f7526af88d065e77c8cc2239327c5edb3a432268e5831010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010009046d15912ce59144191c1204e64559fe8253a0e49e6548af88d065e77c8cc2239327c5edb3a432268e5831663dc15d3c1ac63ff12e45ab68fea3f0a883c25100000000000000000000000068151dea000000540000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001510000000000000000000000001424e3304f82e73edb06d29ff62c91ec8f5ff06571bdeb2900000000000000000000000000000000000000000000000000000000000000000000000000000000912ce59144191c1204e64559fe8253a0e49e6548000000000000000000000000af88d065e77c8cc2239327c5edb3a432268e5831000000000000000000000000000000000000000000000000000000000000016000000000000000000000000000000000000000000000000000000000000001a000000000000000000000000000000000000000000000000000000000000001e00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000663dc15d3c1ac63ff12e45ab68fea3f0a883c25100000000000000000000000000000000000000000000003637239428a726d966000000000000000000000000000000000000000000000000000000001412d69d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000c7d3ab410d49b664d03fe5b1038852ac852b1b29000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000003637239428a726d96600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002707b22536f75726365223a2264654272696467652d346663642d396531662d393161373561343166333562222c22416d6f756e74496e555344223a223333382e3534393433323535393439343835222c22416d6f756e744f7574555344223a223333382e3436323735373036353236383134222c22526566657272616c223a22222c22466c616773223a302c22416d6f756e744f7574223a22333337393631373736222c2254696d657374616d70223a313734363231333137382c22526f7574654944223a2264356636393531372d343162362d346237632d616435302d623032663132313261373130222c22496e74656772697479496e666f223a7b224b65794944223a2231222c225369676e6174757265223a22634552725149787330784b50584d3670726d4c484f4e553757324b762b365839646a6c4b385a6972746361762b66617a744c46646e33775a2f6c5277317533487a4d5649554d7a65507a567476303663782b386742754174594651714f626e6159624d6d6b7774786e6848346b4a336c3278544f733134457639585735386b54757069496c48494f7a565479644f4a693838707238746c753534757353514b55453142707353356a35456651415577303137626271384b557670496943346f685050506b66514d33457a4c575a3362427976504367646e6442332f4444597433544e5970525262474e36476e623375664a682f5a696e4f3749666d49587576625a5046316a335a2f77327a333655774d495866732f334142333376774d5a6d4d4f2b7747774637696c5a7a3770783865646336695a5939672b5368735852354a37794f4e467072773674495831652b674757464637513d3d227d7d00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000424b930370100000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000196926a90a000000000000000000000000000000000000000000000000000000000000003600000000000000000000000000000000000000000000000000000000000007c3d000000000000000000000000000000000000000000000000000000000000038000000000000000000000000000000000000000000000000000000000000003a0000000000000000000000000af88d065e77c8cc2239327c5edb3a432268e5831000000000000000000000000000000000000000000000000000000001412d69e000000000000000000000000000000000000000000000000000000000000016000000000000000000000000000000000000000000000004cac74145fd542829d000000000000000000000000000000000000000000000000000000000000008900000000000000000000000000000000000000000000000000000000000001a000000000000000000000000055a8f5cce1d53d9ff84ec0962882b447e5914db800000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000002200000000000000000000000000000000000000000000000000000000000000260000000000000000000000000000000000000000000000000000000000000028000000000000000000000000000000000000000000000000000000000000000140000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001455a8f5cce1d53d9ff84ec0962882b447e5914db8000000000000000000000000000000000000000000000000000000000000000000000000000000000000001455a8f5cce1d53d9ff84ec0962882b447e5914db80000000000000000000000000000000000000000000000000000000000000000000000000000000000000014555ce236c0220695b68341bc48c68d52210cc35b00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000042010100000066d986c862e659010000000000000000000000009d8242d55f1474ac4c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"to": "0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251"
},
"prependedOperatingExpenseCost": "97362178910640486",
"order": {
"approximateFulfillmentDelay": 3,
"salt": 1746213179552,
"metadata": "0x010100000066d986c862e659010000000000000000000000009d8242d55f1474ac4c0000000000000000000000000000000000000000000000000000000000000000"
},
"orderId": "0x19499ede9b21fa5cc0ce5f74a155482576ff7d85b51863fb5231dbf648300b6a",
"fixFee": "1000000000000000",
"userPoints": 198.47,
"integratorPoints": 49.62
}
```
# Cross-Chain Order Creation
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/creating-order/creating-order
Creating cross-chain orders with the deBridge Liquidity Network API: a step-by-step guide to using the `create-tx` endpoint for estimating outcomes and constructing transactions, along with best practices for quoting strategies and timing guarantees.
The `create-tx` endpoint is intended to be used for both estimating and constructing order transactions. There are detailed breakdowns of parameters
and the response fields.
We do recommend reading deeper into these articles, but if you want to get up and running, have a look at the quick start section.
Swagger specs of `create-tx` can be found here.
# Paired Quote and Transaction
The `create-tx` ednpoint is intentionally dual-purpose:
* It estimates a realistic, market-aware outcome (`estimation`)
* It constructs a ready-to-sign transaction (`tx`) whenever the call includes the necessary wallet data
This design intentionally removes the distinction between “get quote” and “build transaction” that exists in typical single-chain swap APIs.
A detailed parameter reference & field-by-field response breakdown lives in the [API
Parameters](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters) and [API
Response](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/response) sub-pages, while Swagger specs for `create-tx`
can be explored [here](/api-reference/dln/this-endpoint-returns-the-data-for-a-transaction-to-place-a-cross-chain-dln-order). For a hands-on
walk-through, see the [Quick Start](/dln-details/integration-guidelines/order-creation/creating-order/quick-start) section of the docs.
# Why Quote and Transaction Are Paired
DLN works with *intent-based orders* that traverse two independent blockchains, two swaps, and several off-chain actors (API, solvers, validators). An
accurate quote must already account for:
* Source-chain liquidity and gas
* Destination-chain liquidity and gas
* A solver’s operating expenses and target margin
* Short-term market volatility during the time the order is in flight
* Generating that quote is the most computationally expensive step; producing the transaction payload afterwards is trivial. A “lightweight quote” would be misleading and would cause orders to be ignored by solvers.
# How the `create-tx` Endpoint Behaves
| **Scenario** | **Returned Fields** | **Typical Use-Case** |
| ----------------------------------------------------------------- | --------------------- | -------------------------------------- |
| All required fields present (wallet connected, amounts known) | `estimation` and `tx` | Production trade flow |
| Wallet address missing (connect-wallet screen, fiat on-ramp flow) | `estimation` | Pre-trade previews, fiat on-ramp flows |
If dstChainTokenOutRecipient, srcChainOrderAuthorityAddress, or dstChainOrderAuthorityAddress are absent, the API withholds tx. Recipient and authorities parameters are required for creating the transaction. Replay the same call once addresses are known to receive the full response pair.
# Do Not Replay the Quote Into a Second Call
Passing the returned `srcChainTokenInAmount` and dstChainTokenOutAmount back to `create-tx` forces the endpoint into [limit-order quoting
strategy](/dln-details/integration-guidelines/order-creation/creating-order/quoting-strategies) (both amounts fixed). Limit orders can drive solver profit negative, so they
are typically ignored—use the original quote + transaction pair and let the user sign immediately.
Replay-and-fixing the amounts:
* Converts a healthy market order into a potentially unattractive limit order
* Slashes the fulfillment probability
Placing limit orders is fine but they can end up being unprofitable and remain unfilled. If more than \~30 seconds have passed, request a fresh
quote-plus-transaction pair instead of re-using stale numbers. Profitable market orders are filled within seconds; unprofitable ones linger until they
become profitable or the user cancels them.
# Timing Guarantees
Quotes remain solvent if the paired transaction is signed and broadcast within \~30 seconds. Beyond that window:
* Gas cost or price movements may exceed the solver’s margin.
* Solvers will skip the order; users must cancel and retry.
For ERC-20 flows with `prependOperatingExpenses=true`, approve a slightly higher allowance (≈ +30 %) or approve infinity to avoid a second approval if operating expenses drift upward while the user is signing.
```typescript theme={null}
// 1. Preview (wallet not yet connected)
const preview = await fetch(
'/dln/order/create-tx?srcChainId=56&srcChainTokenIn=&srcChainTokenInAmount=1000000&' +
'dstChainId=43114&dstChainTokenOut=&dstChainTokenOutAmount=auto'
).then(data => data.json());
// preview.estimation is present; preview.tx is undefined.
// 2. User connects wallet; replay with authority/recipient addresses
const full = await fetch(
'/dln/order/create-tx?srcChainId=56&srcChainTokenIn=&srcChainTokenInAmount=1000000&' +
'dstChainId=43114&dstChainTokenOut=&dstChainTokenOutAmount=auto&' +
'dstChainTokenOutRecipient=&srcChainOrderAuthorityAddress=&' +
'dstChainOrderAuthorityAddress='
).then(data => data.json());
// full.estimation and full.tx are now present.
// Sign full.tx within 30 s for >99.9 % fill probability.
```
# Key Takeaways
* One endpoint, one response—never separate quote retrieval from transaction generation.
* The estimate/transaction pair maximizes fulfillment probability by eliminating UI-induced latency.
* When wallet addresses are unknown, call `create-tx` for estimation only, then repeat once addresses are set.
* Re-using quoted amounts in a second request reduces the likelihood of order fulfillment and should be avoided.
Following this pattern ensures that orders hit the network with fresh spreads, remain attractive to solvers, and settle cross-chain in seconds.
# Quickstart
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/creating-order/quick-start
deBridge Liquidity Network API Quickstart – EVM and Solana.
# Disclaimer
The provided code is for demonstration purposes only and is supplied "as is" without warranties of any kind. Users are responsible
for reviewing, testing, and validating the code before executing transactions with real funds. We are not liable for any losses or
damages resulting from its use.
# Overview
[This repository](https://github.com/debridge-finance/api-integrator-example) serves as a practical resource for integrators
aiming to get started with hands-on examples of using the deBridge Liqudity Network protocol via API.
More details on submitting chain-specific orders can be found
[here](/dln-details/integration-guidelines/order-creation/creating-order/creating-order).
# EVM
[Included](https://github.com/debridge-finance/api-integrator-example/blob/master/src/scripts/orders/example-swap.ts) is a
comprehensive TypeScript script demonstrating the transfer of 0.1 USDC from Polygon to Arbitrum. The script outlines all necessary
steps for completing a cross-chain swap between the two networks. It also includes examples for executing the approve function on
ERC-20 tokens and showcases various deBridge API integrations.
# Solana
There are also examples of
[creating an order from Polygon (EVM) to Solana](https://github.com/debridge-finance/api-integrator-example/blob/master/src/scripts/orders/poly-usdc-to-sol.ts)
and
[from Solana to Polygon (EVM)](https://github.com/debridge-finance/api-integrator-example/blob/master/src/scripts/orders/sol-usdc-to-poly.ts),
along with submitting a versioned transaction.
# Quoting Strategies
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/creating-order/quoting-strategies
Possible quoting strategies explained in detail.
DLN supports multiple quoting strategies that allow users to control how much is spent on the source chain and how much is
received on the destination chain. Each strategy is defined by how the `srcChainTokenInAmount` and `dstChainTokenOutAmount` fields
are set in the order input.
## Quoting Strategies Overview
### Market Order (Recommended)
```ts theme={null}
const orderInput: deBridgeOrderInput = {
...,
srcChainTokenInAmount: "",
dstChainTokenOutAmount: "auto",
...
};
```
* Default and most commonly used strategy.
* User defines the exact input amount.
* Protocol determines the best output amount.
✅ Recommended for most standard transfers.
Requirements:
* `srcChainTokenInAmount` = fixed numeric value
* `dstChainTokenOutAmount` = "auto"
***
### Market Order with Full Balance Utilization
```ts theme={null}
const orderInput: deBridgeOrderInput = {
...,
srcChainTokenInAmount: "max",
dstChainTokenOutAmount: "auto",
...
};
```
* Spends the full wallet balance.
* Useful for account abstraction, batch transfers, smart wallets.
Requirements:
* `srcChainTokenInAmount` = "max"
* `dstChainTokenOutAmount` = "auto"
A hands-on example can be found
[here](https://github.com/debridge-finance/api-integrator-example/blob/master/src/scripts/orders/max-bnb-to-poly.ts).
***
### Reverse Market Order
```ts theme={null}
const orderInput: deBridgeOrderInput = {
...,
srcChainTokenInAmount: "auto",
dstChainTokenOutAmount: "",
...
};
```
* User specifies how much to **receive**.
* Protocol calculates how much must be spent.
* Ideal for payment flows or contract interactions.
Requirements:
* `srcChainTokenInAmount` = "auto"
* `dstChainTokenOutAmount` = fixed numeric value
An interesting use-case is improving user experience by
[determining the minimum input token amount dynamically](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#minimum-input-amounts).
***
### Limit Order (Not Recommended)
```ts theme={null}
const orderInput: deBridgeOrderInput = {
...,
srcChainTokenInAmount: "",
dstChainTokenOutAmount: "",
...
};
```
* Defines both input and output amounts.
* Treated as a limit order.
* Will only be fulfilled if a solver accepts the exact terms.
Not recommended for production — risk of non-fulfillment.
Requirements:
* Both values must be fixed.
***
## Example: Order Input Structure
```ts theme={null}
const arbUsdcAddress = "0xaf88d065e77c8cc2239327c5edb3a432268e5831";
const bnbUsdcAddress = "0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d";
const usdcDecimals = 18;
const amountToSend = "0.01";
const amountInAtomicUnit = ethers.parseUnits(amountToSend, usdcDecimals);
const orderInput: deBridgeOrderInput = {
srcChainId: "56",
srcChainTokenIn: bnbUsdcAddress,
srcChainTokenInAmount: amountInAtomicUnit.toString(),
dstChainTokenOutAmount: "auto",
dstChainId: "42161",
dstChainTokenOut: arbUsdcAddress,
dstChainTokenOutRecipient: wallet.address,
account: wallet.address,
srcChainOrderAuthorityAddress: wallet.address,
dstChainOrderAuthorityAddress: wallet.address,
referralCode: 31805,
};
```
***
## Choosing a Strategy
| **Use Case** | **Recommended Strategy** |
| ---------------------------------- | ------------------------------- |
| Standard transfer with known input | Market Order |
| Full wallet balance transfer | Market Order with Full Balance |
| Target fixed destination output | Reverse Market Order |
| Exact 1-to-1 trade (limit) | Limit Order *(not recommended)* |
# Refreshing Estimates
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/creating-order/refreshing-estimates
How and when the estimates should be refreshed.
## Transaction Submission Timing
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 — i.e., the period between receiving the `create-tx` response and submitting it
on-chain. Transactions may remain valid for extended periods, especially when no [pre-order-swap](/dln-details/dln-specifics/bridging-non-reserve-assets) is
involved or the [pre-order-swap](/dln-details/dln-specifics/bridging-non-reserve-assets) is between stablecoins.
***
## Handling Operating Expense Fluctuations
When the `prependOperatingExpenses` [parameter](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters) 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's a delay — typically more than a minute — before
submitting `response.tx`, operating expenses may increase. In that case the estimate should be refreshed. If the updated expense exceeds the approved
amount, an additional approval step is required, degrading the experience.
### Recommendation
* **Set token allowance to infinity** if user experience allows
* **Or** add a 30% buffer when setting the allowance to absorb changes
```ts theme={null}
const { approximateOperatingExpense } = response.estimation.srcChainTokenIn;
const approveAmount = srcChainTokenInAmount + approximateOperatingExpense * 1.3;
```
This ensures the approved amount remains sufficient even if gas costs or execution fees rise before submission.
***
You can find more examples in the [code reference](https://github.com/debridge-finance/api-integrator-example/tree/master/src/scripts/orders)
# Specifying Assets
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/creating-order/specifying-assets
How to specify assets when creating an order.
# Specifying Assets
When creating an asset movement, it is essential to correctly specify the assets that will be included in a cross-chain order or a same-chain swap.
This section shows how to do it, and covers some special cases. This article is relevant for both same-chain swaps and cross-chain orders.
Hands on examples can be found in the [examples repository](https://github.com/debridge-finance/api-integrator-example/tree/master).
## EVM and SPL tokens
When specifying EVM or SPL tokens in an asset movement, token's contract/program address must be provided.
### EVM Example
```typescript theme={null}
const orderInput: deBridgeOrderInput = {
srcChainId: '42161',
srcChainTokenIn: "0xaf88d065e77c8cc2239327c5edb3a432268e5831", // USDC Arbitrum
srcChainTokenInAmount: "1000000", // 1 USDC (6 decimals)
dstChainId: '137',
dstChainTokenOut: "0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359", // USDC Polygon
dstChainTokenOutRecipient: recipientAddress,
account: senderAddress,
srcChainOrderAuthorityAddress: senderAddress,
dstChainOrderAuthorityAddress: recipientAddress,
};
```
### Solana Example
```typescript theme={null}
const orderInput: deBridgeOrderInput = {
srcChainId: '7565164',
srcChainTokenIn: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", // USDC Solana
srcChainTokenInAmount: "1000000", // 1 USDC (6 decimals)
dstChainId: '137',
dstChainTokenOut: "0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359", // USDC Polygon
dstChainTokenOutRecipient: evmUserAddress,
account: solWallet.publicKey.toBase58(),
srcChainOrderAuthorityAddress: solWallet.publicKey.toBase58(),
dstChainOrderAuthorityAddress: evmUserAddress,
};
```
## Native Assets
When specifying native assets, such as ETH on Ethereum or SOL on Solana, predefined identifiers for these assets must be used.
### EVM Example
On EVM chains, the native asset (e.g., ETH on Mainnet, ETH on Arbitrum, MATIC on Polygon, BNB on BNB) is represented by the zero address:
`0x0000000000000000000000000000000000000000`.
```typescript theme={null}
const orderInput: deBridgeOrderInput = {
srcChainId: '137',
srcChainTokenIn: "0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359", // USDC Polygon
srcChainTokenInAmount: "1000000", // 1 USDC (6 decimals)
dstChainId: '56',
dstChainTokenOut: "0x0000000000000000000000000000000000000000",
dstChainTokenOutRecipient: recipientAddress,
account: senderAddress,
srcChainOrderAuthorityAddress: wallet.address,
dstChainOrderAuthorityAddress: recipientAddress
};
```
Wrapped versions of native assets (e.g., WETH, WMATIC) should be specified using their respective contract addresses.
### Solana Example
On Solana, we have two cases to consider: SOL and WSOL. It is important to not confuse the two.
#### SOL (Native SOL)
The native SOL asset is represented by the special identifier: `11111111111111111111111111111111`.
In this example, native SOL is moved to MATIC on Polygon:
```typescript theme={null}
const orderInput: deBridgeOrderInput = {
srcChainId: '7565164',
srcChainTokenIn: "11111111111111111111111111111111", // SOL native token
srcChainTokenInAmount: "100000000", // 0.1 SOL (9 decimals)
dstChainId: '137',
dstChainTokenOut: "0x0000000000000000000000000000000000000000", // Polygon native token
dstChainTokenOutRecipient: evmUserAddress,
account: solWallet.publicKey.toBase58(),
srcChainOrderAuthorityAddress: solWallet.publicKey.toBase58(),
dstChainOrderAuthorityAddress: evmUserAddress,
};
```
#### WSOL (Wrapped SOL)
The wrapped SOL asset is represented by the special identifier: `So11111111111111111111111111111111111111112`.
This example exchanged SOL for WSOL on Solana through a same-chain swap:
```typescript theme={null}
const sameChainSwapInput: SameChainSwapInput = {
chainId: '7565164',
tokenIn: "11111111111111111111111111111111", // native SOL
tokenInAmount: "100000000", // 0.1 SOL (9 decimals)
tokenOut: "So11111111111111111111111111111111111111112", // WSOL
tokenOutRecipient: solWallet.publicKey.toBase58(),
senderAddress: solWallet.publicKey.toBase58(),
};
```
# Integrating Hooks
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/hooks/integrating-hooks
Hooks integration guidelines.
The DLN API provides a convenient high-level interface to attach hooks to orders upon requesting [an order creation transaction](/dln-details/integration-guidelines/order-creation/creating-order/creating-order). The API takes the
burden of proper hook data validation, encoding, cost estimation, and simulation, ensuring that an order would get filled on the destination chain and
there is no technical inconsistencies that may prevent it. This is especially important for atomic success-required hooks, as an error during such
hook execution would prevent an order from getting filled, and an order's authority would need to initiate [a cancellation procedure](/dln-details/integration-guidelines/order-creation/cancelling-order) from the
destination chain, which increases friction and worsens UX.
To specify the hook, use the `dlnHook` parameter of the [`create-tx` endpoint](/api-reference/dln/this-endpoint-returns-the-data-for-a-transaction-to-place-a-cross-chain-dln-order). The value for this parameter must be a JSON object that describes the
hook for the given destination chain. Depending on the destination chain, different templates are available.
# Serialized instructions hook for Solana
To set the hook to be executed upon filling order on Solana (dstChainId=7565164), the following template should be used:
```typescript theme={null}
{ type: "solana_serialized_instructions"; data: "0x..." }
```
where data is represented as a versioned transaction with one or more instructions. Thus, only *non-atomic success-required* hooks are supported.
To craft a proper versioned transaction, use the [Creating Hook data for Solana](/dln-details/integration-guidelines/order-creation/hooks/solana-hook-data) guide.
```typescript theme={null}
dlnHook: JSON.stringify({
type: "solana_serialized_instructions";
data: "0x000000000000000001000000000000000000000000010000000000000000010000000000000000135d3e6be2a2ae5274cfe4007df2f62ed31c618f048337fd1435ca2dee2a0d5d12000000000000001968562fef0aab1b1d8f99d44306595cd4ba41d7cc899c007a774d23ad702ff60101fd97b70d573d364ef44769540777b1ecdc21b88ff7def38c45d020e271c589dc00010000000000000000000000000000000000000000000000000000000000000000000062584959deb8a728a91cebdc187b545d920479265052145f31fb80c73fac5aea00009845350d27001686985bbc5c4a3646c928d7de27ddab09f2de56d21537201c4300019845350d27001686985bbc5c4a3646c928d7de27ddab09f2de56d21537201c4300010c1e5ba8fe0ec5c5e44d12c2b6317a8781ca19ddb0e1532b136f418e1d588f9500010c1e5ba8fe0ec5c5e44d12c2b6317a8781ca19ddb0e1532b136f418e1d588f95000106ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a900000000000000000000000000000000000000000000000000000000000000000000000006a7d517187bd16635dad40455fdc2c0c124c68f215675a5dbbacb5f0800000000008c97258f4e2489f1bb3d1029148e0d830b5a1399daff1084048e7bd8dbe9f8590000ef0d8b6fda2ceba41da15d4095d1da392a0d2f8ed0c6c7bc0f4cfac8c280b56d00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000974d0b69f43d964da48af118a28037ab921a95eae1e637497b22867ce416255a00016be7362bf52e4ea29063d29ab43a832253ed7c68b62cf68e8d706a2f9531c1eb0001c6fa7af3bedbad3a3d65f36aabc97431b1bbe4c2d2f6e0e47ca60203452f5d610000040000000000000000736f6c"
})
```
# Transaction call hook for EVM
To easily attach an atomic success-required hook that executes an arbitrary transaction call via the default [Universal
hook](/dln-details/protocol-specs/evm-chains-hook-anatomy#universal-hook), the DLN API provides a simple shortcut for that:
```typescript theme={null}
{
type: "evm_transaction_call";
data: {
"to": "0x...",
"calldata": "0x...",
"gas": 0
}
}
```
The `data.to` and `data.calldata` properties represent the transaction call that should be made, as explained in the [Universal hook](/dln-details/protocol-specs/evm-chains-hook-anatomy#universal-hook) section. The `gas`
property must be specified if:
* the underlying call handles errors gracefully, which leads to [underestimation of gas](https://x.com/AlexSmirnov__/status/1538903343455772673).
* the transaction call can't be estimated currently, which leads to inability of the DLN API to properly estimate transaction costs.
The following snippet produces a dlnHook parameter that results a hook to deposit 0.1 USDC to AAVE on behalf of `0xc31dcE63f4B284Cf3bFb93A278F970204409747f`:
```typescript theme={null}
const query = new URLSearchParams({
// other parameters were omitted for clarity
dstChainId: 137,
dstChainTokenOut: '0x3c499c542cef5e3811e1192ce70d8cc03d5c3359',
dstChainTokenOutAmount: '100000',
dlnHook: JSON.stringify({
type: "evm_transaction_call";
data: {
"to": "0x794a61358D6845594F94dc1DB02A252b5b4814aD",
"calldata": "0x617ba0370000000000000000000000003c499c542cef5e3811e1192ce70d8cc03d5c335900000000000000000000000000000000000000000000000000000000000186a0000000000000000000000000c31dce63f4b284cf3bfb93a278f970204409747f0000000000000000000000000000000000000000000000000000000000000000",
"gas": 0
}
})
})
```
Full working example can be seen [here](https://github.com/debridge-finance/api-integrator-example/blob/master/src/scripts/hooks/evm-evm/basic.ts).
This simple shortcut would be transparently converted by the DLN API to a hook with the following properties:
```typescript theme={null}
{
fallbackAddress: dstChainTokenOutRecipient,
target: '0x0000000000000000000000000000000000000000',
reward: 0,
isNonAtomic: false,
isSuccessRequired: true,
targetPayload: {
to: dlnHook.data.to,
callData: dlnHook.calldata.data,
gas: dlnHook.data.gas
}
}
```
# Arbitrary hook for EVM
To provide a complete customization of a hook, the DLN API offers a template that fully replicates the
[HookDataV1](/dln-details/protocol-specs/evm-chains-hook-anatomy) struct:
```json theme={null}
{
"type": "evm_hook_data_v1",
"data": {
"fallbackAddress": "0x...",
"target": "0x...",
"reward": "0",
"isNonAtomic": boolean,
"isSuccessRequired": boolean,
"targetPayload": "0x"
}
}
```
The DLN API would encode it and inject into an order.
# Hook validity considerations
To ensure best and frictionless user experience, the DLN API would refuse to return a transaction to create an order if it is impossible to
fulfill an order with the given hook.
The hook is attached to the order during order's placement on the source chain, however actual fulfillment occurs on the destination chain. If the
attached hook is success-required and exits unsuccessfully upon fulfillment, it prevents the entire order from getting filled. This would necessitate
an order's authority to initiate [a cancellation procedure](/dln-details/integration-guidelines/order-creation/cancelling-order) from the destination chain, which increases friction and worsens UX.
To prevent this, the DLN API constructs a potential transaction to fulfill the order to be created, and simulates this transaction internally to
ensure that the order to be created could actually be filled. If such simulation causes an error, that points to the problem within the hook, the API
would refuse to return a transaction, but would return an error with details instead, so you can debug the potential fulfillment transaction to find a
pitfalls in the hook:
```json theme={null}
{
"errorId": "HOOK_FAILED",
"errorPayload": {
"potentialFulfillOrderTxSimulation": {
"simulationInput": {
"chainId": number,
"blockNumber": number,
"tx": {
"from": string,
"to": string,
"data": string,
"value"?: string
},
},
"simulationError": {
"errorName": string,
"data": string,
}
}
}
}
```
# Solana Hook Data
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/hooks/solana-hook-data
Solana-specific hook data.
# Order creation
Make sure that you're creating order with `receiver=exe59FS5cojZkPJVDFDV8RnXCC7wd6yoBjsUtqH7Zai` (hex:
`0x09b966be097f46dcf58ebaae2365f56b74cd218a2b8c62468ffa4c53d484b053`)
This is the program that deserializes calldata, converts it into Solana TransactionInstructions and executes them via CPI.
# Intro
Solana calldata is a serialized `TransactionInstruction` list with additional metadata (see next sections). It can be serialized using a wasm module
built by deBridge.
After order fulfillment funds are transferred to the AUTHORITY\_PLACEHOLDER (in case take token is native sol). When take token is SPL token funds are
being transferred to the WALLET\_PLACEHOLDER.
During calldata execution (via UI or automatic executor) executor (entity that sends transaction with ExecuteExternalCall instruction) transfers
*rewards* amount of native Sol to AUTHORITY\_PLACEHOLDER and receives *expenses* amount of take token from WALLET\_PLACEHOLDER.
Each calldata instruction is signed by AUTHORITY\_PLACEHOLDER during execution, no additional signatures could be passed to the CPI.
# Expenses
Determine how much lamports your instruction spends on the destination network (most often, for account creation). Record this value as expenses. Each
instruction is technically worth 5000 lamports (since we can't determine how many resources it will spend in advance, the implication is that it can
be executed in a separate transaction). Therefore, 5000 + expenses is the estimate of how much lamports will cost the execution.
## Rewards
Reward is an amount that covers taker expenses (expenses field) and makes execution of calldata profitable for executor => makes calldata to be
executed automatically. Reward for each instruction is deducted from the wallet placeholder amount. Rewards can't be native sol. Rewards are set by
the DLN API.
# Pubkey substituion
Determine which accounts in the instruction are input-dependent and cannot be passed directly from the user for security reasons.
For example, if there is a PDA in the destination network that depends on some unique transfer identifier, then we need to form `PubkeySubstitutions`
## Expenses
As well as pubkey substitutions, placeholders could be used to substitute extcall accounts, but placeholders can't be used to calculate ATA during
extcall execution. At the moment we have the following placeholders:
* **Wallet Placeholder**: `J4vKrc4pCdtiHpxFDfBy4iyZ22Uf7fBjJyJ817k4673y` - if you set this pubkey to some account, it will be replaced by actual
ExtcallWallet during execution. ExtcallWallet is a [token
account](https://github.com/solana-labs/solana-program-library/blob/523156a0cdd9cada27036bd72d326bc40c00f85f/token/program/src/state.rs#L83-L106) that
contains order's take tokens (in case take token is an SPL token. When native Sol is used ExtcallWallet will be empty).
* **ExtcallMetaPlacehoder**: `7cu34CRu47UZKLRHjt9kFPhuoYyHCzAafGiGWz83GNFs` will be replaced by ExtcallMeta. ExtcallMeta contains such info as order take
token, take token amount, execution state, orderId.
* **Authority Placeholder**: `2iBUASRfDHgEkuZ91Lvos5NxwnmiryHrNbWBfEVqHRQZ` will be replaced by ExtcallAuthority account during execution. Extcall authority
is an owner/authority account for ExtcallWallet. It is this account that manages [expenses](#expenses). When take token of the order is native Sol, funds will
be transferred here (not to the ExtcallWallet)
If both placeholder and substitution are used for the same account, only substitution will be performed.
# DataSubstitution
If you need a transfer amount as part of your transfer and it cannot be calculated in advance, then you must use `DataSubstitution`. One substitution is
now available (`SubmissionAuthWalletAmount`) which works as follows. Takes the `account_index` account of the current instruction, interprets it as a
token account, takes its balance, chooses its encoding (big endian, little endian), uses `substration` and inserts it into the current instruction by
`offset` before calling it.
# Calldata serialization
Instructions should be serialized one by one, final calldata is a concatenation of separately serialized instructions.
Solana's TransactionInstructions could be serialized into calldata format using
[`@debridge-finance/debridge-external-call`](https://www.npmjs.com/package/@debridge-finance/debridge-external-call) npm package:
```typescript theme={null}
import * as wasm from "@debridge-finance/debridge-external-call";
import { PublicKey, TransactionInstruction } from "@solana/web3.js";
/**
* Substitutes amount at offset with `walletBalance(accounts[account_index]) - subtraction`
*/
type AmountSubstitution = {
/**
* big or little endian
*/
is_big_endian: boolean;
/**
* At what offset substitution should be done
*/
offset: number;
/**
* index of account in TransactionInstruction.keys to get balance for
*/
account_index: number;
/**
* Amount to deduct from wallet balance
*/
subtraction: number;
};
/**
* Since we don't know submissionAuth at the moment of calldata preparation we can prepare substitution to replace
* account at `index` with actual ATA(submissionAuth, tokenMint) during execution
*/
type WalletSubstitution = {
/**
* Token mint to calculate ATA for
*/
token_mint: string;
/**
* Account at this index will be replaced with ATA(submissionAuth, tokenMint) during execution
*/
index: number;
};
/**
* Structure required by wasm module
*/
interface IExtIx {
keys: {
pubkey: string;
isSigner: boolean;
isWritable: boolean;
}[];
data: Buffer;
programId: string;
}
function ixToIExtIx(ix: TransactionInstruction): IExtIx {
return {
keys: ix.keys.map((meta) => ({
pubkey: meta.pubkey.toBase58(),
isSigner: meta.isSigner,
isWritable: meta.isWritable,
})),
programId: ix.programId.toBase58(),
data: ix.data,
};
}
function serialize(
instruction: TransactionInstruction,
substitutions?: {
amountSubstitutions?: AmountSubstitution[];
walletSubstitutions?: WalletSubstitution[];
},
expense?: bigint,
reward?: bigint,
isInMandatoryBlock: boolean = false,
) {
const ixWrapper = new wasm.ExternalInstructionWrapper(
reward,
expense,
isInMandatoryBlock,
substitutions?.amountSubstitutions ?? [],
substitutions?.walletSubstitutions ?? [],
ixToIExtIx(instruction),
);
return ixWrapper.serialize();
}
const ix1: TransactionInstruction;
const ix2: TransactionInstruction;
const serializedIx1 = serialize(ix1, undefined, 1000n);
const serializedIx2 = serialize(ix2, undefined, 2000n);
const calldata = Buffer.concat([serializedIx1, serializedIx2 /** rest serialized instructions if any */]);
```
# Order States
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/order-tracking-api/order-states
Order states explained. Order lifecycle state-machine diagram.
In the figure below, the order states are represented in a state-machine diagram, with the actions that trigger each state transition.
```mermaid theme={null}
stateDiagram-v2
%% --- states declared explicitly so we can style them ---
state Start
state End
state Created
state Fulfilled
state SentUnlock
state ClaimedUnlock
state OrderCancelled
state SentOrderCancelled
state ClaimedOrderCancel
%% --- initial entry ---
[*] --> Start
%% --- transitions from Start / Created ---
Start --> Created : Order Created on Source Chain
Created --> Fulfilled : Order Fulfilled on Destination Chain
Created --> OrderCancelled : Order Cancelled on Destination Chain
%% --- fulfilled path ---
Fulfilled --> SentUnlock : Cross-Chain Message Sent
SentUnlock --> ClaimedUnlock : Order Claimed by Solver
ClaimedUnlock --> End
%% --- cancelled path ---
OrderCancelled --> SentOrderCancelled : Cross-Chain Message Sent
SentOrderCancelled --> ClaimedOrderCancel : Order Claimed on Source Chain
ClaimedOrderCancel --> End
%% --- styling for Start / End nodes ---
style Start fill:#90EE90,stroke:#333,stroke-width:1px,color:#000
style End fill:#FF6347,stroke:#333,stroke-width:1px,color:#fff
```
According to the DLN API, an order must be in one of these states:
| State | Description |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Created** | An order placed by a user on the DLN is pending fulfillment. |
| **Fulfilled** | The order on the destination chain has been completed by a solver. The full amount of the requested assets has been successfully transferred to the `dstChainTokenOutRecipient`. |
| **SentUnlock** | After fulfilling the order, the solver initiates the unlock procedure on the destination chain. A cross-chain message is sent via DMP to unlock the input assets locked on the source chain. |
| **ClaimedUnlock** | The unlock process is finalized, and the solver receives the input assets. The affiliate fee is directed to the `affiliateFeeRecipient` on the source chain. |
| **OrderCancelled** | The `dstChainOrderAuthorityAddress` has started the cancellation process on the destination chain. |
| **SentOrderCancel** | A cross-chain message is sent via DMP from the destination to the source chain. It unlocks the input assets on the source chain to be claimed by the `srcAllowedCancelBeneficiary`. |
| **ClaimedOrderCancel** | The source chain input assets have been claimed by the `srcAllowedCancelBeneficiary`. The cancel procedure is finalized. |
# Tracking Orders
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/order-tracking-api/tracking-orders
Tracking Orders and their states via REST API.
***
# Tracking Orders via API
Once an order has been successfully created on-chain, its state can be monitored using several available methods, depending on the use case. For a
full overview of order states and their transitions, refer to the [Order
States](/dln-details/integration-guidelines/order-creation/order-tracking-api/order-states) documentation.
## Key Completion States
Orders progress through multiple internal states. However, from the perspective of the end-user experience, the following states indicate successful completion:
* `Fulfilled`
* `SentUnlock`
* `ClaimedUnlock`
Any of these states can be treated as successfully completed final states for application-level logic.
## Quick Start
* **Base URL:** `https://dln-api.debridge.finance`
* **Full endpoint reference:** [Swagger](/api-reference/orders/get-order-by-events-by-orderid)
* **Examples:** See the implementation examples in this [GitHub
repository](https://github.com/debridge-finance/api-integrator-example/tree/master/src/scripts/orders/queries).
## Querying Orders
### By Wallet Address
The [`POST /api/Orders/filteredList`](/api-reference/orders/get-filtered-list-of-orders-ordered-by-block-timestamp-desc-max-page-size:-100)
endpoint retrieves the current state and historical data for all orders associated with a wallet address. This endpoint is also used to populate the
trade history view in [deExplorer](https://app.debridge.com/orders).
Pagination is supported via `skip` and `take` parameters.
#### Example: Fetching Completed Orders for a Wallet
```ts theme={null}
const URL = 'https://dln-api.debridge.finance/api/Orders/filteredList';
const requestBody = {
orderStates: ['Fulfilled', 'SentUnlock', 'ClaimedUnlock'],
externalCallStates: ['NoExtCall'],
skip: 0,
take: 10,
maker: '0x441bc84aa07a71426f4d9a40bc40ac7183d124b9',
};
const data = await post(URL, requestBody);
```
#### Example: Filtering Completed Orders by Destination Chain (e.g. HyperEVM)
```ts theme={null}
const requestBody = {
giveChainIds: [],
takeChainIds: [100000022], // Internal HyperEVM Chain Id
orderStates: ['Fulfilled', 'SentUnlock', 'ClaimedUnlock'],
externalCallStates: ['NoExtCall'],
skip: 0,
take: 10,
maker: '0x441bc84aa07a71426f4d9a40bc40ac7183d124b9',
};
```
### By `referralCode`
Orders created through specific integrations can also be tracked by using the `referralCode` parameter attached to each API request.
```ts theme={null}
const requestBody = {
giveChainIds: [],
// All of these are considered to be fulfilled
// from the end-user's perspective
orderStates: ['Fulfilled', 'SentUnlock', 'ClaimedUnlock' ],
externalCallStates: ['NoExtCall'],
skip: 0,
take: 3,
referralCode: "31805",
};
```
### By Transaction Hash
For inspecting a specific order, use:
```
GET /api/Orders/creationTxHash/{hash}
```
**Example:**
> [https://dln-api.debridge.finance/api/Orders/creationTxHash/
> 0x3fe11542154f53dcf3134eacb30ea5ca586c9e134c223e56bbe1893862469bc5](https://dln-api.debridge.finance/api/Orders/creationTxHash/0x3fe11542154f53dcf3134eacb30ea5ca586c9e134c223e56bbe1893862469bc5)
If multiple orders were created in a single transaction, this endpoint returns data only for the **first** order.
#### Multiple Orders Created in the Same Transaction
To retrieve all order IDs:
```
GET /api/Transaction/{hash}/orderIds
```
**Example:**
> [https://dln-api.debridge.finance/api/Transaction/
> 0x40ee524d5bb9c4ecd8e55d23c66c5465a3f137be7ae24df366c3fd06daf7de7e
> /orderIds](https://dln-api.debridge.finance/api/Transaction/0xac3724d09ec7c1cdf3b6f845ce2fb6f84a8748d7f26f5f173c072cbaac6333ef/orderIds)
**Response:**
```json theme={null}
{
"orderIds": [
"0x9ee6c3d0aa68a7504e619b02df7c71539d0ce10e27f593bf8604b62e51955a01"
]
}
```
#### Example:
```ts theme={null}
export async function getOrderIdByTransactionHash(txHash: string) {
const URL = `https://dln-api.debridge.finance/api/Transaction/${txHash}/orderIds`;
const response = await fetch(URL);
if (!response.ok) {
const errorText = await response.text();
throw new Error(`Failed to get orderIds: ${response.statusText}. ${errorText}`);
}
const data = await response.json();
if (data.error) {
throw new Error(`DeBridge API Error: ${data.error}`);
}
return data;
}
```
### By `orderId`
Use this endpoint:
```
GET /api/Orders/{orderId}
```
**Example:**
> [https://dln-api.debridge.finance/api/Orders/
> 0x9ee6c3d0aa68a7504e619b02df7c71539d0ce10e27f593bf8604b62e51955a01](https://dln-api.debridge.finance/api/Orders/0x9ee6c3d0aa68a7504e619b02df7c71539d0ce10e27f593bf8604b62e51955a01)
**Response:**
```json theme={null}
{
"status": "ClaimedUnlock"
}
```
#### Example:
```ts theme={null}
export async function getOrderStatusByOrderId(orderId: string) {
const URL = `https://dln-api.debridge.finance/api/Orders/${orderId}`;
const response = await fetch(URL);
if (!response.ok) {
const errorText = await response.text();
throw new Error(`Failed to get order status: ${response.statusText}. ${errorText}`);
}
const data = await response.json();
if (data.error) {
throw new Error(`DeBridge API Error: ${data.error}`);
}
return data;
}
```
### Order Fulfillment Transaction
When order fulfillment transactions are important in the integration, they can be found inside of an each `order` returned by the API by referencing
the `fulfilledDstEventMetadata.transactionHash` field.
## Affiliate Fee Settlement
If set during order creation, the affiliate fee is automatically transferred to the `affiliateFeeRecipient` once the order reaches the `ClaimedUnlock`
status on EVM-based chains, and on Solana it is [manually withdrawable](/dln-details/affiliates/withdrawing-affiliate-fees).
# Submitting the Transaction
Source: https://docs.debridge.com/dln-details/integration-guidelines/order-creation/submitting-the-transaction
Learn how to submit a transaction using the deBridge Liquidity Network API – signing requirements, broadcasting, and practical examples.
# General
The transaction call retrieved from the DLN API must be signed by a user who is willing to sell the asset, and then broadcasted to the source chain.
# EVM
The `tx` object has the following structure and is ready to be signed and broadcasted:
```json theme={null}
{
"estimation": { ... },
"tx": {
"data": "0xfbe16ca70000000000000000000000000000000[...truncated...]",
"to": "0xeF4fB24aD0916217251F553c0596F8Edc630EB66",
"value": "5000000000000000",
},
}
```
Field names from the `tx` object are self-explanatory:
* `to` field defines where the transaction should be sent to, and typically you should expect the address of one of the smart contracts responsible
for forwarding;
* `data` field defines the transaction content, containing instructions related to swaps planned on the source or (and) on the destination chains,
bridging settings, etc;
* `value` is the amount of native blockchain currency that must be sent along with the transaction.
First, the `value` is always positive, even if the input token is an ERC-20 token. This is because the underlying DLN protocol takes a fixed amount in
the native currency, so the API always includes it as the transaction value. In the above example, the `value` equals the current fixed fee, which is
0.005 BNB on the BNB Chain.
Second, in case the input token is an ERC-20 token, a user needs to give approval to the smart contract address specified in the `tx.to` field prior
to submitting this transaction so it can transfer them on the behalf of the sender. This can be typically done by calling either `approve()` or
`increaseAllowance()` methods of the smart contract which implements the token you are willing to swap. Approve at least the amount that has been
specified as the `estimation.srcChainTokenIn.amount` response property.
Other than that, the transaction is ready to be signed by a user and broadcasted to the blockchain. It is also worth mentioning that the given
transaction data can be used as a part of another transaction: a dApp can bypass the given to, data and value to your smart contract, and make a
low-level call. There is even a possiblility to create multiple transactions for different orders, and perform several low-level calls.
The affiliate fee is paid only after the order gets fulfilled, and the taker requests order unlock during the unlock procedure.
# Solana
For DLN trades coming from Solana the `tx` object returned by DLN API has only one field - `data` which is hex-encoded
[VersionedTransaction](https://docs.solana.com/developing/versioned-transactions)
To convert the hex-encoded string into `VersionedTransaction` decode hex to buffer using any library and call
`VersionedTransaction.deserialize(decoded)`.
Make sure you properly set transaction priority fees based on the current load of the Solana network. Refer to one of these guides to learn more about
how to estimate tx fee parameters:
* [Triton guide](https://docs.triton.one/chains/solana/improved-priority-fees-api)
* [Helius guide](https://docs.helius.dev/solana-apis/priority-fee-api)
More info about sending versioned transactions
[here](https://docs.phantom.com/solana/sending-a-transaction-1#signing-and-sending-a-versioned-transaction).
## Example
```typescript theme={null}
import { VersionedTransaction, Connection, clusterApiUrl, Keypair } from "@solana/web3.js";
function encodeNumberToArrayLE(num: number, arraySize: number): Uint8Array {
const result = new Uint8Array(arraySize);
for (let i = 0; i < arraySize; i++) {
result[i] = Number(num & 0xff);
num >>= 8;
}
return result;
}
function updatePriorityFee(tx: VersionedTransaction, computeUnitPrice: number, computeUnitLimit?: number) {
const computeBudgetOfset = 1;
const computeUnitPriceData = tx.message.compiledInstructions[1].data;
const encodedPrice = encodeNumberToArrayLE(computeUnitPrice, 8);
for (let i = 0; i < encodedPrice.length; i++) {
computeUnitPriceData[i + computeBudgetOfset] = encodedPrice[i];
}
if (computeUnitLimit) {
const computeUnitLimitData = tx.message.compiledInstructions[0].data;
const encodedLimit = encodeNumberToArrayLE(computeUnitLimit, 4);
for (let i = 0; i < encodedLimit.length; i++) {
computeUnitLimitData[i + computeBudgetOfset] = encodedLimit[i];
}
}
}
const wallet = new Keypair(); // your actual wallet here
const connection = new Connection(clusterApiUrl("mainnet-beta")); // your actual connection here
const tx = VersionedTransaction.deserialize(Buffer.from(tx.data.slice(2), "hex"));
// make sure to set correct CU price & limit for the best UX
updatePriorityFee(tx, NEW_CU_PRICE, NEW_CU_LIMIT);
const { blockhash } = await connection.getLatestBlockhash();
tx.message.recentBlockhash = blockhash; // Update blockhash!
tx.sign([wallet]); // Sign the tx with wallet
connection.sendTransaction(tx);
```
# Same-Chain Swaps
Source: https://docs.debridge.com/dln-details/integration-guidelines/same-chain-swaps/engineer
An engineering walkthrough for integrating DLN’s same-chain swaps with executable transactions, affiliate fees, and production-grade tracking.
A product surface wants single-network token conversions that behave like reliable transactions, not optimistic quotes. The integration path is
intentionally compact: first, ask for a quote; then, once the sender and recipient are known, request the fully constructed transaction. Under the
hood, DLN simulates routes across multiple aggregators and returns calldata that targets **`DeBridgeRouter`** on EVM, or a serialized transaction on
Solana. The result is an estimation-then-execution loop that stays responsive and grounded in market reality, with the added benefit of **adaptive
slippage** that takes real-time conditions into account.
### What this guide covers
* Endpoints and request shapes to obtain quotes and ready-to-send transactions.
* EVM and Solana submission flows based on the provided TypeScript examples.
* Where affiliate fee parameters plug into the flow.
* Tracking and observability via the Stats API for histories and per-swap lookups.
* Freshness and slippage guidance for resilient UX at scale.
> Reference: [DLN OpenAPI specification](/api-reference/single-chain-swap/get-v10chaintransaction).
> Reference: [Stats API for order tracking](/api-reference/orders/get-filtered-list-of-orders-ordered-by-block-timestamp-desc-max-page-size:-100).
***
## Architecture in brief
A same-chain swap never leaves its origin network. The DLN API handles route discovery and simulation, returning:
* **EVM**: `tx` with `to`, `data`, and (when required) `value`, crafted to call **`DeBridgeRouter`**.
* **Solana**: `tx.data` containing a hex-encoded `VersionedTransaction` that is deserialized, updated with a recent blockhash, signed, and sent.
This design keeps the UI responsive before a wallet is connected, and returns an executable payload once sender and recipient are known.
***
## Endpoints
### Get a quote (estimation)
Use **`GET /v1.0/chain/estimation`** to retrieve a quote for the desired pair. This step is suitable when the wallet is not connected or recipient is
not yet known.
**Minimal request - SOL for USDC on Solana**
```json theme={null}
{
"chainId": "7565164",
"tokenIn": "11111111111111111111111111111111", // SOL on Solana
"tokenInAmount": "200000",
"tokenOut": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", // USDC on Solana,
"slippage": "auto" // Default value
}
```
* The response contains pricing, route details, aggregator comparison, and costs metadata used to inform UI and future submission.
* The recommended value for slippage parameter is `auto`. The API selects a minimum reasonable slippage band from live market conditions and simulations.
```json theme={null}
{
"estimation": {
"tokenIn": {
"address": "string", // token address
"name": "string", // token name
"symbol": "string", // token symbol
"decimals": 0, // token decimals
"amount": "string", // input amount
"approximateUsdValue": 0 // approximate USD value of input amount
},
"tokenOut": {
"address": "string", // token address
"name": "string", // token name
"symbol": "string", // token symbol
"decimals": 0, // token decimals
"amount": "string", // output amount
"minAmount": "string", // minimum output amount
"approximateUsdValue": 0 // approximate USD value of output amount
},
"slippage": 0, // slippage percentage (e.g. 0.5 for 0.5%)
"recommendedSlippage": 0, // recommended slippage percentage based on route simulation and volatility
"protocolFee": "string", // protocol fee amount in tokenIn
"estimatedTransactionFee": { // estimated transaction fee details
"total": "string",
"details": {
"giveOrderState": "string",
"giveOrderWallet": "string",
"nonceMaster": "string",
"txFee": "string",
"priorityFee": "string",
"gasLimit": "string",
"gasPrice": "string",
"baseFee": "string",
"maxFeePerGas": "string",
"maxPriorityFeePerGas": "string"
},
"approximateUsdValue": 0 // approximate USD value of the total estimated transaction fee
},
"costsDetails": [ // Breakdown of costs and fees
{
"chain": "string",
"tokenIn": "string",
"tokenOut": "string",
"amountIn": "string",
"amountOut": "string",
"type": "string",
"payload": {
"feeAmount": "string",
"feeBps": "string",
"amountOutBeforeCorrection": "string",
"estimatedVolatilityBps": "string",
"actualFeeAmount": "string",
"actualFeeBps": "string",
"subsidyAmount": "string",
"feeApproximateUsdValue": "string"
}
}
],
"comparedAggregators": [ // List of queried aggregators and their rates
{
"name": "string",
"amount": "string",
"approximateUsdValue": 0,
"priceDrop": 0,
"imageUrl": "string"
}
]
}
}
```
### Get an executable transaction
Use **`GET /v1.0/chain/transaction`** to obtain the **same quote fields** plus a **tx object** ready to be signed and broadcast.
**Minimal request - USDC for MATIC on Polygon**
```json theme={null}
{
"chainId": "137",
"tokenIn": "0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359", // USDC on Polygon
"tokenInAmount": "200000",
"tokenOut": "0x0000000000000000000000000000000000000000", // Native token (MATIC on Polygon)
"tokenOutRecipient": "",
"senderAddress": "",
"slippage": "auto" // Default value
}
```
**Response Highlights**
```json theme={null}
{
/* same content as in /estimation */
"tx": {
"to": "",
"data": "0x...",
"value": "0x..."
}
}
```
On **Solana**, the `tx` object contains only:
```json theme={null}
{
/* same content as in /estimation */
"tx": { "data": "0x" }
}
```
***
## Compared Aggregators
DLN’s same-chain swaps leverage multiple DeFi aggregators to ensure competitive pricing and route diversity. Response payload for both estimation and
transaction endpoints includes the `comparedAggregators` field, which lists the aggregators queried during route discovery. This transparency allows
integrators to understand the aggregator choice and provides insights into the liquidity sources considered for the swap.
## EVM submission flow
The EVM submission sequence mirrors a typical ERC-20 flow plus a single call to `DeBridgeRouter`:
* Fetch estimation with `/v1.0/chain/estimation` to present the quote.
* Request transaction and quote via `/v1.0/chain/transaction` once the sender and recipient are known.
* Ensure allowance for `tokenIn` toward `tx.to` - the `DeBridgeRouter` contract. [Deployed contracts](/dln-details/overview/deployed-contracts) page
should be consulted for the correct address.
* Send the main transaction using the returned `tx` object.
**Skeleton (TypeScript) aligning with the provided example**
```typescript theme={null}
// Pseudocode stitched to the structure of the provided EVM example
const swap = await createDeBridgeSameChainSwap({
chainId: "137", // Polygon chainId
tokenIn: "0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359", // USDC on Polygon
tokenInAmount: "200000",
tokenOut: "0x0000000000000000000000000000000000000000", // Native token (MATIC on Polygon)
tokenOutRecipient: senderAddress,
senderAddress
});
// 1) Validate response
const tx = swap?.tx;
if (!tx?.to || !tx?.data) throw new Error("Invalid tx");
// 2) Approve if needed - only for ERC-20 tokenIn
const required = BigInt(swap.tokenIn.amount);
const currentAllowance = await erc20.allowance(senderAddress, tx.to);
if (currentAllowance < required) {
const approveTx = await erc20.approve(tx.to, required);
await approveTx.wait();
}
// 3) Submit the transaction
const sent = await signer.sendTransaction(tx);
const receipt = await sent.wait();
```
#### Complete EVM example
The full, production-ready script (logging, receipt checks, explorer links) is available
[here](https://github.com/debridge-finance/api-integrator-example/tree/master/src/scripts/same-chain/poly-usdc-to-matic.ts) and can
be reused for inspiration in real integrations.
***
## Solana submission flow
The Solana variant returns a serialized `VersionedTransaction` ready to be deserialized, refreshed, signed, and sent:
* Request transaction and quote via `/v1.0/chain/transaction` with Solana chain id.
* Deserialize the hex `tx.data` into a `VersionedTransaction`.
* Refresh `blockhash` with `getLatestBlockhash()` and set `tx.message.recentBlockhash`.
* Optionally, adjust CU price/limit using a helper (as in the provided example).
* Sign and send the raw transaction, then confirm.
**Skeleton (TypeScript) aligning with the provided Solana example**
```typescript theme={null}
const swap = await createDeBridgeSameChainSwap({
chainId: "7565164", // Solana chainId
tokenIn: "11111111111111111111111111111111", // SOL on Solana
tokenInAmount: "200000",
tokenOut: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", // USDC on Solana
tokenOutRecipient: solWallet.publicKey.toBase58(),
senderAddress: solWallet.publicKey.toBase58()
});
// Deserialize hex-encoded VersionedTransaction
const tx = VersionedTransaction.deserialize(Buffer.from(swap.tx.data.slice(2), "hex"));
// Refresh blockhash and (optionally) adjust CU price/limit, then sign
const { blockhash } = await connection.getLatestBlockhash();
tx.message.recentBlockhash = blockhash;
// updatePriorityFee(tx, NEW_CU_PRICE, NEW_CU_LIMIT); // as in the github example
tx.sign([solWallet]);
// Send and confirm
const sig = await connection.sendRawTransaction(tx.serialize(), { skipPreflight: false });
```
#### Complete Solana example
The full script (simulation, CU sizing, prioritization fee median, and final submission) is available
[here](https://github.com/debridge-finance/api-integrator-example/tree/master/src/scripts/same-chain/sol-usdc-to-sol.ts) and can be
reused for inspiration in real integrations.
***
## Affiliate fees
Affiliate fees are supported in the same-chain flow. The parameters used are `affiliateFeePercent` and `affiliateFeeRecipient`.
More details are available in the the [Same-Chain Affiliate Fees article](/dln-details/affiliates/affiliate-fees#same-chain-affiliate-fees).
The higher the affiliate fee, the worse rates the users using the app will get.
***
## Tracking and observability
Tracking is performed with the [**Stats API**](). The default order history endpoints now include same-chain swaps when requested explicitly.
### Wallet histories (filtered list)
For listing same-chain swaps of a single wallet `POST https://dln-api.debridge.finance/api/Orders/filteredList` should be used with a `filterMode:
"SameChain"` parameter.\`:
Allowed values for `filterMode` are:
* `"CrossChain"` (default)
* `"SameChain"`
* `"Mixed"`
**Example request**
```json theme={null}
{ "skip": 0, "take": 1, "maker": "", "filterMode": "SameChain" }
```
```json theme={null}
{
"orders": [
{
"orderId": { /* order ID object - with bytes, bytes array and string values */ },
"creationTimestamp": 1759141461, // Unix timestamp
"giveOfferWithMetadata": {
"chainId": { /* chain ID object with different representations */ },
"tokenAddress": { /* token address object - with different representations */ },
"amount": { /* amount object - with different representations */ },
"metadata": { /* input token metadata */
"decimals": 6,
"name": "Dephaser JPY",
"symbol": "JPYT",
"logoURI": null
},
"decimals": 6,
"name": "Dephaser JPY",
"symbol": "JPYT",
"logoURI": null
},
"takeOfferWithMetadata": {
"chainId": { /* chain ID object with different representations */ },
"tokenAddress": { /* token address object - with different representations */ },
"amount": { /* amount object - with different representations */ },
"metadata": { /* output token metadata */
"decimals": 18,
"name": "AntHive",
"symbol": "ANTH",
"logoURI": null
},
"decimals": 18,
"name": "AntHive",
"symbol": "ANTH",
"logoURI": null
},
"state": "Fulfilled", // Swap state
"affiliateFee": {
"beneficiarySrc": { /* affiliate fee beneficiary address object - with bytes, bytes array and string values */ },
"amount": { /* amount object - with bytes, bytes array and string values */ }
},
"createEventTransactionHash": { /* transaction hash object - with bytes, bytes array and string values */ },
"tradeType": "SameChain"
}
],
"totalCount": 24
}
```
Same-chain swaps do not create an on-chain DLN order entity. The Stats API maps same-chain data into an order-like representation purely for
consistency in histories and dashboards.
### Single order lookup
To get details of a single order from the transaction hash, `GET https://dln-api.debridge.finance/api/SameChainSwap/${chainId}/tx/${transactionHash}`
should be used with `chainId` and `transactionHash` parameters. Response structure is identical to the order object in the filtered list.
***
## Freshness and slippage
Quotes are tied to current market conditions and route simulations. Signing and submission should occur shortly after a transaction payload is
received; stale quotes should be refreshed **every 30 seconds**. The recommended value for `slippage` parameter is `"auto"`. The API selects a minimum
reasonable slippage bound based on volatility and route simulation, a design that reduces execution risk without forcing conservative hard-coding.
***
## Example links
* [EVM same-chain swap script (USDC → native on
Polygon)](https://github.com/debridge-finance/api-integrator-example/tree/master/src/scripts/same-chain/poly-usdc-to-matic.ts).
* [Solana same-chain swap script (USDC →
native)](https://github.com/debridge-finance/api-integrator-example/tree/master/src/scripts/same-chain/sol-usdc-to-sol.ts).
* [Estimation-only script demonstrating
`/v1.0/chain/estimation`](https://github.com/debridge-finance/api-integrator-example/tree/master/src/scripts/same-chain/estimation/estimation-example.ts).
* [Filtered history script using `api/Orders/filteredList` with
`filterMode`](https://github.com/debridge-finance/api-integrator-example/tree/master/src/scripts/same-chain/queries/get-same-chain-swaps.ts).
***
## Production checklist
* Fetch the `estimation` endpoint for quotes before the wallet is connected; request the `transaction` endpoint for quotes and a transaction object
once `senderAddress` and `tokenOutRecipient` are known.
* Prefer adaptive `slippage` with `auto`.
* On EVM, ensure `tokenIn` allowance toward the `DeBridgeRouter` target in `tx.to`.
* Refresh quotes every 30 seconds if signing is delayed to avoid staleness.
* Use Stats API `filterList` endpoint with `filterMode: "SameChain"` for observability.
# Same-Chain Swaps
Source: https://docs.debridge.com/dln-details/integration-guidelines/same-chain-swaps/executive
How DLN’s same-chain swaps work, what makes them reliable, and how to ship them fast.
Same-chain swaps in DLN enable seamless token-for-token conversions on a single network. Instead of crossing chains, the operation remains localized,
yet leverages the same design principles that drive DLN’s broader market order execution. Routing, simulation, and transaction construction are all
part of the swap process where deBridge API does the heavy lifting, creating an efficient and resilient experience. The developers get to focus on
building dapps, while deBridge ensures that users receive reliable quotes and executable transactions. Additionally, with [affiliate
fees](/dln-details/integration-guidelines/same-chain-swaps/executive#affiliate-fees) supported, deBridge integrations can be monetized effectively.
At a high level, the flow is straightforward: before a user connects their wallet to the app, an **estimation** request to the DLN API is used to
fetch the quote for a chosen pair. Once the wallet is connected, the **transaction** endpoint should be used. It delivers the quote, just like the
**estimation** endpoint, but with the addition of yielding a ready-to-submit payload, which completes the swap. Behind this simple sequence, the API
carries out substantial work: it evaluates routes across several aggregators, reconciles live market conditions, and generates transactions structured
to succeed in execution rather than exist as optimistic quotes. Dapps usually deal with slippage statically - they set it to some value and forget
about it. This approach leads to subpar user experience when markets start shifting. With deBridge, users remain protected from adverse market effects
with **adaptive slippage** as the core focus of same-chain swaps. After years of refinement, deBridge developed a way to set slippage dynamically,
based on real-time conditions and route simulations. This mirrors DLN’s philosophy across all orders—providing both grounded estimates and final
transaction calls from a single request sequence.
For integrators, two immediate benefits emerge. First, there is no need to manually pre-compute complex slippage or routing logic. Second, the user
experience remains responsive: an estimate can be fetched before wallet details are available, and then repeated with additional information to
receive an executable payload. The API is intentionally designed to minimize latency - if the users like what they see, they can proceed to sign and
submit quickly, because milliseconds matter.
### Reliability of quotes
DLN’s API emphasizes "minimum reasonable" outcomes through market-aware protections. When intermediary swaps are required (for example, when moving
between volatile assets and their paired counterparts), DeFi aggregators are queried and the route is simulated prior to returning calldata. The
result is a quote grounded in what can be executed at the time of request, rather than an idealized price projection.
Given that market conditions shift rapidly, the returned quotes carry a freshness expectation: **signing and submission should occur within
approximately 30 seconds**, after which re-quoting is recommended. Interfaces that integrate DLN are therefore expected to encourage timely
confirmations or refresh estimates automatically.
### Contracts and integration model
On EVM chains, **same-chain swaps consistently route through the `DeBridgeRouter`**. The API abstracts away low-level venue interaction, delivering
transaction objects that are pre-targeted and structured for execution. On Solana, the response is intentionally minimal: the `tx` field contains a
single hex-encoded `VersionedTransaction` that can be deserialized and signed by wallets.
### Integration simplicity
The same-chain swap process is designed to be as straightforward as possible, with a tight API surface that minimizes complexity and potential points
of failure, ensuring a smooth integration experience and superb user experience.
The flow relies on two key endpoints:
* **`/v1.0/chain/estimation`** — provides a quote, usable prior to wallet connection or before recipient details are specified.
* **`/v1.0/chain/transaction`** — repeats the request with wallet and recipient information, returning a ready-to-sign transaction object.
Both are documented in the public [**OpenAPI
reference**](/api-reference/single-chain-swap/get-v10chaintransaction).
### Adaptive slippage and slippage management
Explicit slippage can be provided, but the recommended practice is to defer to the API’s automatic controls. DLN interprets `auto` as a dynamic
guardrail derived from live conditions and route simulation, thus providing **adaptive slippage** in the response. This approach provides resilience
in volatile markets, instead of relying on a slippage value that doesn't adapt to the market conditions. Manual overrides should be reserved for
exceptional cases; otherwise, automatic limits ensure consistency and protection.
### Affiliate fees
Affiliate fees transform same-chain swaps from a pure utility into a monetizable integration pathway. At the protocol level, every swap request can
carry parameters that define both the affiliate fee percentage and the recipient of those fees. This ensures that each executed swap can
simultaneously deliver value to end users and revenue back to the integrator.
On EVM chains, settlement occurs automatically during the swap transaction execution. On Solana, integration
leverages Jupiter’s referral infrastructure, where referral keys act as the designated recipient, and accumulated fees can be claimed via the Jupiter
dashboard.
Because affiliate fees are embedded in the request layer, no additional complexity is introduced to the swap flow itself. The estimation and
transaction endpoints function as usual, with affiliate metadata included transparently. This design aligns with DLN’s guiding principle of minimizing
integration friction while unlocking new revenue streams for integrators.
### Tracking and observability
Swap outcomes are tracked through the **Stats API**. Queries can be performed using `filteredList` for wallet histories, or by transaction hash for a
single order, or by the referral code for the integration.
Same-chain Swaps are available in the [deBridge Explorer](https://explorer.debridge.com/) under the **Same-Chain** filter.
For tracking orders related to an integration, referral code must be generated and included in requests. Instructions for generating a referral code
are available in the [referrers guide](/dln-details/affiliates/referrers).
### Summary
DLN’s same-chain swaps are designed to eliminate fragility from a straightforward action. The API performs live simulation during estimation,
constructs transactions that are execution-ready, applies conservative automatic limits with adaptive slippage, and enforces freshness to prevent
stale quotes. With a single router contract on EVM chains and a minimal serialization path on Solana, the integration process prioritizes robustness
and clarity. Built-in support for affiliate fees and referral tracking adds a monetization layer without increasing integration complexity, while
observability through the Stats API and Explorer reinforces transparency across all activity. For detailed request and response specifications, the
[**OpenAPI reference**](https://dln.debridge.finance/v1.0#/single%20chain%20swap/SingleSwapControllerV10_getChainTransaction) and [Integration
Guidelines](/dln-details/integration-guidelines/same-chain-swaps/engineer) provide full coverage.
# Filling Orders
Source: https://docs.debridge.com/dln-details/integration-guidelines/smart-contracts/filling-orders
How to fulfill DLN orders via smart contracts.
We are going to release a reference documentation for fulfilling orders placed on the deBridge Liquidity Network Protocol soon. Until this, please
look at the documentation on [dln-taker](https://github.com/debridge-finance/dln-taker#dln-taker) — our open source service for solvers that automates
order estimation and fulfillment.
# Introduction
Source: https://docs.debridge.com/dln-details/integration-guidelines/smart-contracts/introduction
Overview of DLN smart contracts and direct on-chain integration.
The deBridge Liquidity Network Protocol is an on-chain system of smart contracts where users place their cross-chain limit orders, giving a specific
amount of input token on the source chain (`giveAmount` of the `giveToken` on the `giveChain`) and specifying the outcome they are willing to take on the
destination chain (`takeAmount` of the `takeToken` on the `takeChain`).
The given amount is being locked by the `DlnSource` smart contract on the source chain and anyone with enough liquidity (called **Solvers**) can attempt to
fulfill the order by calling the `DlnDestination` smart contract on the destination chain supplying the requested amount of tokens the user is willing
to take. After the order is fulfilled, the supplied amount is immediately transferred to the recipient specified by the user, and a cross-chain
message is sent to the source chain via the deBridge infrastructure to unlock the funds, effectively completing the order.Getting ready to make
on-chain calls
The DLN Protocol consists of two contracts: the `DlnSource` contract responsible for order placement, and the `DlnDestination` contract responsible for
order fulfillment.
Currently, both contracts are deployed on the supported blockchains effectively allowing anyone to place orders in any direction. Contract addresses
can be found [here for DMP](/dmp-details/dmp/deployed-contracts), [here for DLN](/dln-details/overview/deployed-contracts) and ABIs/IDLs can be
found here: [Trusted Smart Contracts](https://github.com/debridge-finance/abis-and-idls)
# Placing Orders
Source: https://docs.debridge.com/dln-details/integration-guidelines/smart-contracts/placing-orders
Placing orders on the deBridge Liquidity Network: order preparation, on-chain placement, tracking order status, and cancellation procedures.
# Estimating the order
First, decide which tokens you are willing to sell on the source chain and which tokens you are willing to buy on the destination chain. Say, you're
selling 1 wBTC on Ethereum and buying a reasonable amount of DOGE on BNB.
The deBridge Liquidity Network Protocol is completely asset-agnostic, meaning that you can place an order giving wBTC or WETH, or any other asset.
However, solvers mainly hold USDC and ETH on their wallets' balance and execute only the orders where the input token is either a USDC token or a
native ETH. Thus, for a quick fulfillment of the order placed in the deBridge Liquidity Network Protocol, it's recommended to pre-swap your input
token to any of these reserve-ready tokens before placing an order.
On the other hand, DLN is an open market, so anyone can become a solver and execute orders with custom input tokens or profitability.
Let's assume you've swapped your 1 wBTC to 25,000 USDC which will be then used upon order creation.
Second, calculate the reasonable amount of tokens you are willing to receive on the destination chain upon order fulfillment according to the current
market condition and the protocol fees. Simply speaking, give at least 4 bps (DLN protocol fee) + 4 bps (Taker's incentive) = 8 bps + \$6 (expected gas
expenses taken by the taker to fulfill the order). This amount is laid in as a spread of the limit order, or margin between input and output tokens.
Getting back to the example, the math below gives us a reasonable amount of DOGE we are willing to take:
```typescript theme={null}
25,000 * (10,000 - 8) / 10,000 - 6 = 24,974 DOGE
```
10,000 is a basis point denominator. More details [here](https://en.wikipedia.org/wiki/Basis_point).
Third, make sure you have enough Ether to cover the protocol fee, which is being taken by `DlnSource` smart contract for order creation. You are advised
to query `DlnSource.globalFixedNativeFee()` function to retrieve this value. For example, the `globalFixedNativeFee` value for the Ethereum blockchain
would be `1000000000000000`, which resolves to 0.001 ETH.
# Placing order on-chain
To place an order
* set USDC token approval to allow the `DlnSource` contract spend tokens on your behalf,
* call the `DlnSource.createOrder()` method
```solidity theme={null}
function createOrder(
OrderCreation calldata _orderCreation,
bytes calldata _affiliateFee,
uint32 _referralCode,
bytes calldata _permitEnvelope
) external payable returns (bytes32 orderId);
```
## Preparing OrderCreation struct
`OrderCreation` has the following structure:
```solidity theme={null}
struct OrderCreation {
// the address of the ERC-20 token you are giving;
// use the zero address to indicate you are giving a native blockchain token (ether, matic, etc).
address giveTokenAddress;
// the amount of tokens you are giving
uint256 giveAmount;
// the address of the ERC-20 token you are willing to take on the destination chain
bytes takeTokenAddress;
// the amount of tokens you are willing to take on the destination chain
uint256 takeAmount;
// the ID of the chain where an order should be fulfilled.
// Use the list of supported chains mentioned above
uint256 takeChainId;
// the address on the destination chain where the funds
// should be sent to upon order fulfillment
bytes receiverDst;
// the address on the source (current) chain who is allowed to patch the order
// giving more input tokens and thus making the order more attractive to takers, just in case
address givePatchAuthoritySrc;
// the address on the destination chain who is allowed to patch the order
// decreasing the take amount and thus making the order more attractive to takers, just in case
bytes orderAuthorityAddressDst;
// an optional address restricting anyone in the open market from fulfilling
// this order but the given address. This can be useful if you are creating a order
// for a specific taker. By default, set to empty bytes array (0x)
bytes allowedTakerDst; // *optional
// set to an empty bytes array (0x)
bytes externalCall; // N/A, *optional
// an optional address on the source (current) chain where the given input tokens
// would be transferred to in case order cancellation is initiated by the orderAuthorityAddressDst
// on the destination chain. This property can be safely set to an empty bytes array (0x):
// in this case, tokens would be transferred to the arbitrary address specified
// by the orderAuthorityAddressDst upon order cancellation
bytes allowedCancelBeneficiarySrc; // *optional
}
```
## Preparing other arguments
Subsequent arguments of the `createOrder()` method can be safely omitted by specifying the default values:
* `_affiliateFee` can be set to empty bytes array (`0x`); this argument allows you to ask the protocol to keep the given amount as an affiliate fee in
favor of affiliate beneficiary and release it whenever an order is completely fulfilled. This is useful if you built a protocol and place orders on
behalf of your users. To do so, concat the address and the amount into a single bytes array, whose length is expected to be exactly 52 bytes.
* `_referralCode` can be set to zero (`0`); it is an invitation code to identify your transaction. If you don't have it, you can get one by pressing the
INVITE FRIENDS button at app.debridge.com. Governance may thank you later for being an early builder.
* `_permitEnvelope` can be set to empty bytes array (`0x`); it allows you to use an EIP-2612-compliant signed approval so you don't have to give a prior
spending approval to allow the `DlnSource` contract to spend tokens on your behalf. This argument accepts `amount` + `deadline` + `signature` as a single
bytes array
## Making a call
Once all arguments are prepared, you are ready to make the call. Make sure you supply the exact amount of native blockchain currency to the `value` to
cover the DLN protocol fee (`globalFixedNativeFee`).
```solidity theme={null}
// preparing an order
OrderCreation memory orderCreation;
orderCreation.giveTokenAddress = 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48; // USDC
orderCreation.giveAmount = 25000000000; // 25,000 USDC
orderCreation.takeTokenAddress = abi.encodePacked(0xba2ae424d960c26247dd6c32edc70b295c744c43);
orderCreation.takeAmount = 2497400000000; // 249,740 DOGE
orderCreation.takeChainId = 56; // BNB Chain
orderCreation.receiverDst = abi.encodePacked(0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045);
orderCreation.givePatchAuthoritySrc = 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045;
orderCreation.orderAuthorityAddressDst = abi.encodePacked(0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045);
orderCreation.allowedTakerDst = "";
orderCreation.externalCall = "";
orderCreation.allowedCancelBeneficiarySrc = "";
// getting the protocol fee
uint protocolFee = DlnSource(dlnSourceAddress).globalFixedNativeFee();
// giving approval
IERC20(orderCreation.giveTokenAddress).approve(dlnSourceAddress, orderCreation.giveAmount);
// placing an order
bytes32 orderId = DlnSource(dlnSourceAddress).createOrder{value: protocolFee}(
orderCreation,
"",
0,
""
);
```
Whenever the call to `DlnSource.createOrder()` succeeds, it will return a unique `orderId` which can be used to track, cancel and fulfill the order.
Additionally, `CreatedOrder` event is emitted. It contains the `Order` structure which is important in specifying how to fulfill or cancel the order.
```solidity theme={null}
event CreatedOrder(
Order order,
bytes32 orderId,
bytes affiliateFee,
uint256 nativeFixFee,
uint256 percentFee,
uint32 referralCode
);
```
# Tracking order status
There is no way to know the order status on the chain where the order was placed. You need to switch to the chain it is intended to be fulfilled on
(the `takeChainId` property of the order).
You have two options to programmatically find whenever an order has been fulfilled or cancelled on the destination chain (not the chain where you
placed it): either by querying the `DlnDestination.takeOrders()` getter method, or by capturing the `FulfilledOrder()` and `SentOrderCancel()` events
emitted by the `DlnDestination` contract.
The `DlnDestination.takeOrders()` getter method is defined as follows:
```solidity theme={null}
function takeOrders(bytes32 orderId)
external
view
returns (
uint8 status,
address takerAddress,
uint256 giveChainId
);
```
It returns the status property which indicates:
-status=0: the given order is neither fulfilled nor cancelled,
-status=1: the given order is successfully fulfilled (funds sent to the given receiver)
-status=2: unlock procedure has been initiated upon fulfillment to unlock the given funds on the source chain, as per taker request
-status=3: cancel procedure has been initiated to unlock the given funds on the source chain, as per order's orderAuthorityAddressDst request
Alternatively, you can capture events emitted by the `DlnDestination` contact:
```solidity theme={null}
event FulfilledOrder(Order order, bytes32 orderId, address sender, address unlockAuthority);
event SentOrderCancel(Order order, bytes32 orderId, bytes cancelBeneficiary, bytes32 submissionId);
```
Events are emitted:
* `FulfilledOrder` whenever the order has been successfully fulfilled.
* `SentOrderCancel` whenever the cancel procedure has been initiated, as per order's `orderAuthorityAddressDst` request.
# Canceling order
The only way to cancel the order is to initiate the cancellation procedure on the chain it was intended to be fulfilled on (the `takeChainId` property
of the order). During the cancellation process, the order is marked as cancelled (to prevent further fulfillment) and a cross-chain message is sent
through the deBridge cross-chain messaging infrastructure to the `DlnSource` contract on the source chain to unlock the given funds. The funds locked on
the source chain are returned in full including affiliate and protocol fees.
To initiate the cancellation procedure, call the `DlnDestination.sendEvmOrderCancel()` method on the destination chain as follows:
```solidity theme={null}
function sendEvmOrderCancel(
Order memory _order,
address _cancelBeneficiary,
uint256 _executionFee
) external payable;
```
* mind that only the `orderAuthorityAddressDst` address specified during the order creation is allowed to perform this call for the given order;
* you need to cover the deBridge cross-chain messaging protocol fee (measured in the blockchain native currency where the message is being sent from)
to make a cancellation message accepted. Consider looking at the details on retrieving the deBridge protocol fee;
* for the `_order` argument, use the `Order` structure obtained from the `CreatedOrder()` upon order creation;
* for the `_cancelBeneficiary` argument, use the address you'd like the given funds to be unlocked to on the source chain. Whenever the
`allowedCancelBeneficiarySrc` has been explicitly provided upon order creation, you are only allowed to use that value;
* for the `_executionFee` argument, specify the amount of native blockchain currency (in addition to the deBridge protocol fee) to provide an
incentive to keepers for the successful claim of the cross-chain message on the destination chain. In other words, this is a prepayment for
potential gas expenses on the destination chain, that will be transferred by the protocol. Otherwise, you'd need to find the cross-chain transaction
in the [deExplorer](https://explorer.debridge.com/) and claim it manually. Consider understanding how the cross-chain call is handled.
Finally, you are ready to initiate a cancellation procedure:
```solidity theme={null}
uint protocolFee = IDebridgeGate(DlnDestination(dlnDestinationAddress).deBridgeGate())
.globalFixedNativeFee();
uint executionFee = 30000000000000000; // e.g. 0.03 BNB ≈ \$10
DlnDestination(dlnDestinationAddress).sendEvmOrderCancel{value: protocolFee + executionFee}(
order,
0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045,
executionFee
);
```
# MCP Server
Source: https://docs.debridge.com/dln-details/mcp/mcp-server
Connect AI coding agents to deBridge for cross-chain swaps
Ask your AI assistant to bridge 1 ETH from Arbitrum to Solana. Get a quote in seconds. Click one link to execute.
The deBridge MCP Server ([`@debridge-finance/debridge-mcp`](http://npmjs.com/package/@debridge-finance/debridge-mcp)) gives AI
agents direct access to the deBridge Liquidity Network — search 40,000+ tokens, get quotes for cross-chain and same-chain swaps,
generate transaction data, and create shareable [deBridge App](https://app.debridge.finance) links based on
[custom linking](/dln-details/widget/app). No API keys required.
## How It Works
The MCP server is a stateless proxy that translates MCP tool calls into deBridge REST API requests. It does no heavy computation,
keeps no state, and stores nothing. The AI agent never talks to the deBridge API directly — all requests flow through the server.
```mermaid theme={null}
sequenceDiagram
participant Agent as AI Agent
participant Server as MCP Server
participant API as deBridge API
Agent->>Server: MCP tool call (e.g. create_tx)
Server->>API: REST request
API-->>Server: JSON response
Server-->>Agent: Tool result
Agent->>Agent: Presents result to user
```
The server calls public deBridge APIs, which provide a generous 50 requests per minute rate limit without authentication.
## Use Cases
* **Developers building on deBridge** — test quotes, check token addresses, and verify chain IDs without leaving the IDE. The MCP
server turns an AI assistant into a live deBridge API explorer.
* **Power users in AI chat** — get quick swap quotes as part of a broader conversation. One click on the generated link to execute
the swap.
* **Analysts and content creators** — query live pricing data conversationally. Compare bridge rates across chains for reports and
research.
* **Trading bots and dashboards** — autonomous agents that monitor prices across chains and generate swap links when conditions
are met.
* **Integrate with the existing AI agents** — any agent that supports MCP servers can use this to offer deBridge swaps without
building their own API integration and expand their capabilities into DeFi space.
## Quick Start
Add this to your MCP configuration file:
```json theme={null}
{
"mcpServers": {
"debridge-mcp": {
"command": "npx",
"args": [
"-y",
"@debridge-finance/debridge-mcp@latest"
]
}
}
}
```
This works for most AI coding agents (Cursor, Claude Code, Windsurf, Cline, etc.). See [Configuration](#configuration) for
framework-specific paths and options.
**Claude Desktop** requires HTTP transport. Start the server with `MCP_TRANSPORT=http npx -y
@debridge-finance/debridge-mcp@latest`, then configure the URL `http://localhost:3000/mcp`. See [Configuration](#configuration)
for details.
## Tools
### `get_instructions`
Returns the built-in workflow guide that describes the recommended sequence for using the deBridge MCP tools.
No parameters.
Call this first to understand the recommended workflow before using other tools.
### `search_tokens`
Resolves token names, symbols, or addresses to contract addresses across supported chains.
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ------------------------------------ |
| `query` | string | Yes | Token name, symbol, or address |
| `chainId` | string | No | Filter by chain ID |
| `name` | string | No | Filter by token name (partial match) |
| `limit` | number | No | Max results (default: 10) |
Results are ranked by relevance: exact symbol match → exact name match → starts-with → substring.
**Example:**
```json theme={null}
{
"query": "USDC",
"chainId": "1"
}
```
```json theme={null}
{
"tokens": [
{
"symbol": "USDC",
"name": "USD Coin",
"address": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
"decimals": 6,
"chainId": "1"
}
]
}
```
### `get_supported_chains`
Lists all blockchain networks supported by DLN.
No parameters.
**Example response:**
```json theme={null}
{
"chains": [
{ "chainId": "1", "chainName": "Ethereum" },
{ "chainId": "56", "chainName": "BNB Chain" },
{ "chainId": "137", "chainName": "Polygon" },
{ "chainId": "42161", "chainName": "Arbitrum" },
{ "chainId": "7565164", "chainName": "Solana" }
]
}
```
### `create_tx`
Get quotes for cross-chain swaps.
| Parameter | Type | Required | Description |
| ------------------------------- | ------- | -------- | --------------------------------------- |
| `srcChainId` | string | Yes | Source chain ID |
| `srcChainTokenIn` | string | Yes | Source token address |
| `srcChainTokenInAmount` | string | Yes | Amount in smallest units (wei/lamports) |
| `dstChainId` | string | Yes | Destination chain ID |
| `dstChainTokenOut` | string | Yes | Destination token address |
| `dstChainTokenOutRecipient` | string | Yes | Recipient wallet address |
| `srcChainOrderAuthorityAddress` | string | Yes | Sender's wallet address |
| `dstChainOrderAuthorityAddress` | string | Yes | Recipient's authority address |
| `dstChainTokenOutAmount` | string | No | Output amount or `"auto"` (default) |
| `prependOperatingExpenses` | boolean | No | Include operating expenses in input |
All token amounts must be in the smallest unit of the token. For example, 1 USDC = `"1000000"` (6 decimals), 1 ETH =
`"1000000000000000000"` (18 decimals). Use `search_tokens` to find the correct `decimals` value.
The native token (ETH, BNB, MATIC, etc.) is represented by the zero address: `0x0000000000000000000000000000000000000000`.
SOL on Solana is represented with `11111111111111111111111111111111` and Wrapped SOL (WSOL) is represented with
`So11111111111111111111111111111111111111112`.
### `estimate_same_chain_swap`
Estimates a same-chain token swap. Returns the expected output amount, fees, slippage, and aggregator comparisons.
| Parameter | Type | Required | Description |
| ----------------------- | ------ | -------- | --------------------------------------------- |
| `chainId` | string | Yes | Chain ID (native or deBridge internal) |
| `tokenIn` | string | Yes | Input token address (zero address for native) |
| `tokenInAmount` | string | Yes | Amount in smallest units (wei/lamports) |
| `tokenOut` | string | Yes | Output token address |
| `tokenOutAmount` | string | No | Expected output or `"auto"` (default) |
| `slippage` | string | No | Slippage tolerance or `"auto"` (default) |
| `affiliateFeePercent` | number | No | Affiliate fee percentage |
| `affiliateFeeRecipient` | string | No | Affiliate fee recipient address |
This tool accepts both native chain IDs (e.g. `4326` for MegaETH) and deBridge internal IDs.
### `get_trade_dapp_url`
Generates a shareable deBridge App URL for a given trade.
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | ------------------------------------------------ |
| `inputChain` | string | Yes | Source chain ID |
| `outputChain` | string | Yes | Destination chain ID |
| `amount` | string | Yes | Human-readable amount (e.g., `"1.5"`) |
| `inputCurrency` | string | No | Source token address (empty for native) |
| `outputCurrency` | string | No | Destination token address (empty for native) |
| `dlnMode` | string | No | `"simple"` or `"advanced"` (default: `"simple"`) |
Unlike `create_tx`, this tool uses human-readable amounts — pass `"1.5"` for 1.5 ETH, not the wei value.
**Example output:**
```
https://app.debridge.finance/order?inputChain=1&outputChain=42161&inputCurrency=&outputCurrency=&amount=1.5&dlnMode=simple
```
## Workflow
The recommended sequence for performing a swap:
1. **Resolve chains** — call `get_supported_chains` to find the chain IDs for the source and destination networks.
2. **Resolve tokens** — call `search_tokens` with the chain ID to get the token contract addresses and decimals.
3. **Get a quote** — call `create_tx` for cross-chain swaps or `estimate_same_chain_swap` for same-chain swaps.
4. **Share a link** — call `get_trade_dapp_url` to generate a deBridge App URL the user can open to execute the swap.
The MCP server never touches private keys or signs transactions. The user always completes the swap themselves: open the
generated link, connect their wallet, review, and sign. This browser handoff is a deliberate security boundary — the server
handles pricing and quoting, while the user retains full control over execution.
## Example
**Prompt:** `Bridge 1 ETH from Arbitrum to USDC on Solana`
1. **Resolve chains** — call `get_supported_chains` to find that Arbitrum is `42161` and Solana is `7565164`.
2. **Resolve source token** — call `search_tokens` with `query: "ETH"` and `chainId: "42161"` to get the native token address
(`0x0000000000000000000000000000000000000000`, 18 decimals).
3. **Resolve destination token** — call `search_tokens` with `query: "USDC"` and `chainId: "7565164"` to get the USDC address on
Solana.
4. **Create the transaction** — call `create_tx` with the resolved addresses and `srcChainTokenInAmount: "1000000000000000000"` (1
ETH in wei). The response includes the estimated output amount and transaction data.
5. **Generate a link** — call `get_trade_dapp_url` with `inputChain: "42161"`, `outputChain: "7565164"`, `amount: "1"`, and the
resolved token addresses.
6. **User completes the swap** — the user opens the generated link in their browser, connects their wallet, and signs the
transaction.
## Configuration
The standard configuration works for most frameworks:
```json theme={null}
{
"mcpServers": {
"debridge-mcp": {
"command": "npx",
"args": [
"-y",
"@debridge-finance/debridge-mcp@latest"
]
}
}
}
```
```bash theme={null}
claude mcp add debridge npx -- -y @debridge-finance/debridge-mcp@latest
```
Add to `.cursor/mcp.json` (project) or `~/.cursor/mcp.json` (global):
```json theme={null}
{
"mcpServers": {
"debridge-mcp": {
"command": "npx",
"args": [
"-y",
"@debridge-finance/debridge-mcp@latest"
]
}
}
}
```
Add to `.vscode/mcp.json`:
```json theme={null}
{
"servers": {
"debridge-mcp": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@debridge-finance/debridge-mcp@latest"]
}
}
}
```
Add to `~/.codeium/windsurf/mcp_config.json`:
```json theme={null}
{
"mcpServers": {
"debridge-mcp": {
"command": "npx",
"args": [
"-y",
"@debridge-finance/debridge-mcp@latest"
]
}
}
}
```
Clone [the repository](https://github.com/debridge-finance/debridge-mcp/tree/main) and build from source:
```bash theme={null}
docker build -t debridge-mcp .
docker run -p 3000:3000 debridge-mcp
```
## Environment Variables
| Variable | Default | Description |
| --------------- | --------- | ----------------------------------------- |
| `MCP_TRANSPORT` | `stdio` | Set to `"http"` for HTTP streaming mode |
| `PORT` | `3000` | HTTP server port (HTTP mode only) |
| `HOST` | `0.0.0.0` | HTTP server bind address (HTTP mode only) |
## Resources
* [GitHub Repository](https://github.com/debridge-finance/debridge-mcp)
* [npm Package](https://www.npmjs.com/package/@debridge-finance/debridge-mcp)
* [DLN API Documentation](/dln-details/integration-guidelines/order-creation/authentication)
* [deBridge App](https://app.debridge.finance)
# Overview
Source: https://docs.debridge.com/dln-details/other-ways-to-integrate
Overview of widget, app linking, and smart contract integration options.
The other ways to integrate the deBridge Liquidity Network are:
### Widget
* Integrate cross-chain and same-chain swaps within minutes
* Flexible, yet battle-tested module
* [Details](/dln-details/widget/deBridge-widget)
### App Linking
* Create sharable links with your [referral code](/dln-details/affiliates/referrers) and earn points
* Useful for individual referrers or integrators
* [Details](/dln-details/widget/app)
### MCP Server
* Connect AI coding agents to deBridge for cross-chain and same-chain swaps
* Works with Claude Code, Cursor, VS Code, Windsurf, and other MCP-compatible tools
* [Details](/dln-details/mcp/mcp-server)
### Smart Contracts
* See how deBridge trusted smart contracts work
* Interact directly with the smart contracts (not recommended)
* [Details](/dln-details/integration-guidelines/smart-contracts/introduction)
For a vast majority of use-cases, it is not advised to interact with the contracts directly. It is advised to create transaction data through
[`create-tx`](/dln-details/integration-guidelines/order-creation/creating-order/creating-order) API calls.
Forming DLN orders is a complex task that requires a lot of underlying infrastructure to get just right, with transactions being simulated across
several aggregators for every supported chain.
# deBridge Hooks
Source: https://docs.debridge.com/dln-details/overview/deBridge-hooks
deBridge Hooks is a core feature of the DLN protocol that allows users, protocols, and market makers to attach arbitrary on-chain actions to the orders that would get executed upon their fulfillment.
The DLN protocol allows users to place cross-chain orders with an arbitrary on-chain action attached as an inseparable part of it,
enabling cryptographically signed operations to be performed on the destination chain upon order fulfillment.
An action itself — called a hook — is a raw destination chain-specific data, that represents either an instruction (or a set of instructions) to be
executed on Solana, or a hook enriched with a custom payload, or even a transaction call to be executed on a EVM-based chain. A hook can perform
actions of any complexity, including operations on the outcome of the order. This effectively enriches the interactions between users and protocols,
enabling cross-chain communications that were not possible before. A few possible use cases:
* Asset distribution: one can place a cross-chain order that buys an asset and immediately distributes it across a set of addresses;
* Blockchain abstraction: a dApp can place a cross-chain order that buys an asset and deposits it onto the staking protocol on behalf of a signing
user;
* User onboarding: a service can place a cross-chain order (from a user's familiar blockchain to a blockchain a user has not tried before) that buys a
stable coin and tops up user's wallet with a small amount of native blockchain currency to enable the user to start submitting transactions right
away;
* Action triggers: a cross-chain order could trigger conditional actions that emit events, change state, even to prevent an order from being filled;
* Anything else you might thought about!
Additionally, a hook is bundled with a bunch of properties (hook metadata) that define hook behavior.
Information passed through hooks is non-authenticated by default, so you can't know who was the real sender unless you pass an authenticated
signature in the hook itself, and verify the signature in the called program/smart contract.
In case you need to authenticate a smart contract as a sender, you must use the [deBridge messaging protocol](/dmp-details/dmp/protocol-overview).
# Hooks are a part of an order
Orders are identified by a [deterministic order ID](/dln-details/protocol-specs/deterministic-order-id), and the hash of the hook's raw data is essentially a part
of this ID (see the last two fields of the [deterministic order ID](/dln-details/protocol-specs/deterministic-order-id)), so once a user signs-off an order with a
hook, he eventually makes a cryptographic confirmation that he is willing to sell input asset for output asset AND execute a specific action along
with the output asset on the destination chain.
The proper execution of the hook during order fulfillment is guaranteed by [`DlnDestination`](/dln-details/overview/deployed-contracts) — the DLN smart contract responsible for filling orders,
which ensures that the given hook along with other properties of the order actually matches the given order ID. This means that trying to spoof a hook
would lead to a different ID of a non-existent order, so the solver is compelled to pass specific hook data, otherwise, he won't be able to unlock
liquidity in the source chain upon fulfillment.
# Hooks are trustless
DLN is an open market, so anyone can place arbitrary orders (even non-profitable, or having fake hooks), and anyone with available liquidity can be a
solver and fill any open order. The [`DlnDestination`](/dln-details/overview/deployed-contracts) smart contract simply ensures that the requested amount is provided in full and further forwarded
either to the recipient or to a hook's target (via the [`DlnExternalCallAdapter`](/dln-details/overview/deployed-contracts) smart contract). This means that a hook's target should be designed with
an assumption that anyone can place and fill arbitrary orders with arbitrary hooks, and thus never expose permissions only on the fact that the caller
is a trusted DLN contract because the DLN contract here is only an intermediary, not a guard.
# Hooks atomicity
Even though hooks are an inseparable part of DLN orders, their execution scenario is a matter of hook configuration.
Hooks can be *success-required* and *optional-success*:
* *success-required* hooks ARE REQUIRED to finish successfully. If the hook gets reverted, the entire transaction gets reverted as well, which is
guaranteed by the DLN smart contract.
* *optional-success* hooks ARE ALLOWED to fail. In the event of failure, the DLN smart contract would send the order's outcome further to the fallback
address specified as a part of a hook envelope.
Hooks can be *atomic* and *non-atomic*:
* *atomic hooks* ARE REQUIRED to be executed atomically along with the order fulfillment. In other words, the order with such a hook is either filled and
the hook is executed, or not at all. Mind that if the hook is an success-required hook and it fails, the entire order would not get filled, and the
order's authority would need to cancel the order.
If the hook is a *success-optional* hook and its' execution fails, then the order would get filled, and the order's outcome would get sent further to
the fallback address specified as a part of a hook envelope.
* *non-atomic hooks* ARE ALLOWED (but not required) to be executed later, which is up to the solver who fills the order. If the solver fills the order but
does not execute a hook, the order is marked is filled, but its outcome is stored securely in the DLN intermediary contract along with the hook,
waiting until anyone (an arbitrary third party, like a solver) initiates a transaction to execute the hook, OR until the trusted authority of an order
on the destination chain cancels the hook to receive the order's outcome in full.
Smart contracts on the EVM-based chains support all the options above. Smart contracts on Solana only support non-atomic success-required hooks due to
the limitations of the chain.
# Hook cancellation policy
Even though hooks are an indivisible part of orders placed onto DLN, their execution and cancellation flow may vary.
Atomic hooks are executed along with an order fulfillment, so they either succeed, or silently fail (if they are optional-success hooks), or revert
and prevent the order from getting filled (if they are success-required hooks). In the worst-case scenario, when they get reverted, the assigned
authority of an order in the destination chain may only cancel the entire order.
Non-atomic hooks are allowed to be executed later in a separate transaction after an order gets filled. In this case, the hook (along with the outcome
of an order) remains pending execution in the intermediary smart contract, and the trusted authority of an order on the destination chain may cancel
the hook and receive the order's outcome in full.
# Who pays for hook execution?
Submitting a transaction to execute a hook implies paying a transaction fee. The deBridge Hooks engine provides two
distinct ways to incentivize solvers and other trustless third parties to submit transactions to execute hooks.
The most straightforward way to cover hook execution is to lay the cost in the spread of an order: say, there is an order to sell 105 USDC on Solana
and buy 100 USDC on Ethereum with a hook that deposits the bought amount to the LP: in this case, the difference between sell amount and buy amount (5
USDC) must cover all the fees and costs, including the cost of this hook execution. This is the preferred approach for atomic hooks that target
EVM-based chains because in this case, the hook is part of the execution flow of a transaction that fills the order.
Additionally, hook metadata may explicitly define a reward that the deBridge Hooks engine contract should cut off from the order's outcome (before the
outcome is transferred to a hook) in favor of a solver who pays for a transaction: for example, there could be an order to sell 106 USDC on Ethereum,
buy 101 USDC on Solana with a hook that deposits exactly 100 USDC to the LP and leaves 1 USDC as a reward. This approach works for non-atomic hooks,
and the smart contract guarantees that a solver would get exactly the specified amount of the outcome.
The DLN API simplifies a hook's cost estimation by automatically simulating transactions upon order creation.
# Common pitfalls
A common source of frustration is a blockchain where a hook is expected to run: hooks are built for destination chains. For example,
an order that sells SOL on Solana and buys ETH on Ethereum would get placed on Solana with the hook data encoded specifically for EVM, and vice versa.
Atomic success-required hooks that get reverted would prevent their orders from getting fulfilled, causing users' funds to stuck, which would require
users to initiate a [cancellation procedure](/dln-details/integration-guidelines/order-creation/cancelling-order). This increases friction and worsens the overall user experience, so it is advised to carefully test hooks,
and estimate potential fulfillments before placing orders with such hooks in production. The API [takes the burden](/dln-details/integration-guidelines/order-creation/hooks/integrating-hooks) of proper hook data validation,
encoding, and hook simulation, ensuring that an order can get filled on the destination chain.
# Examples
* [Order from Ethereum to Solana](https://app.debridge.com/order?orderId=0xd78af2a21f4c7dc1fb11e85fff608739d8af167b4ff91b03bc3a097822fcc966) with a non-atomic hook
* [Order from Ethereum to Polygon](https://app.debridge.com/order?orderId=0x401c8eb93a1358bbe2924e98446ed35fbb73dabd638aa183de3aca0af2582a40) with an atomic success-required hook
# Availability
deBridge Hooks are available on all supported blockchains. Hooks can be encoded programmatically while interacting directly with smart
contracts or passed to the DLN API via a simple high-level interface.
Further reading:
* [Easy usage with the DLN API: Integrating deBridge hooks](/dln-details/integration-guidelines/order-creation/hooks/integrating-hooks)
* Technical specification: [Hook data](/dln-details/protocol-specs/hook-data)
# Deployed Contracts
Source: https://docs.debridge.com/dln-details/overview/deployed-contracts
deBridge Liquidity Network deployed contracts
The following smart contracts have been deployed across supported chains to power the DLN:
# Solana
| **Smart Contract** | **Address** | **Description** |
| ------------------ | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------- |
| `DlnSource` | [src5qyZHqTqecJV4aY6Cb6zDZLMDzrDKKezs22MPHr4](https://solscan.io/account/src5qyZHqTqecJV4aY6Cb6zDZLMDzrDKKezs22MPHr4) | Used to place orders on DLN |
| `DlnDestination` | [dst5MGcFPoBeREFAA5E3tU5ij8m5uVYwkzkSAbsLbNo](https://solscan.io/account/dst5MGcFPoBeREFAA5E3tU5ij8m5uVYwkzkSAbsLbNo) | Used to fulfill and cancel DLN orders |
## IDLs
The IDLs can be found [here](https://github.com/debridge-finance/abis-and-idls/tree/master/idls).
# EVM-based Chains
| | DlnSource | DlnDestination | DeBridgeRouter | DlnExternalCallAdapter | ExternalCallExecutor |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **Description** | Used to place orders on DLN | Used to fulfill and cancel orders placed on DLN | Intermediary contract used exclusively by the DLN API to swap input asset for one of the settlement assets prior to order creation, if necessary | Intermediary store and the engine for DLN Hooks that implement `IExternalCallExecutor` | Universal DLN Hook (implementing `IExternalCallExecutor`) that executes arbitrary transaction calls via a payload |
| **Github** | [LINK](https://github.com/debridge-finance/dln-contracts/blob/main/contracts/DLN/DlnSource.sol) | [LINK](https://github.com/debridge-finance/dln-contracts/blob/main/contracts/DLN/DlnDestination.sol) | | [LINK](https://github.com/debridge-finance/dln-contracts/blob/main/contracts/adapters/DlnExternalCallAdapter.sol) | [LINK](https://github.com/debridge-finance/dln-contracts/blob/main/contracts/adapters/ExternalCallExecutor.sol) |
| **Chain** | | | | | |
| Ethereum | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://etherscan.io/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://etherscan.io/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://etherscan.io/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9](https://etherscan.io/address/0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9) | [0xAE0361b1C3454b297129e01046057F1D294c7974](https://etherscan.io/address/0xAE0361b1C3454b297129e01046057F1D294c7974) |
| BNB Chain | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://bscscan.com/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://bscscan.com/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://bscscan.com/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9](https://bscscan.com/address/0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9) | [0xAE0361b1C3454b297129e01046057F1D294c7974](https://bscscan.com/address/0xAE0361b1C3454b297129e01046057F1D294c7974) |
| Polygon | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://polygonscan.com/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://polygonscan.com/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://polygonscan.com/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9](https://polygonscan.com/address/0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9) | [0xAE0361b1C3454b297129e01046057F1D294c7974](https://polygonscan.com/address/0xAE0361b1C3454b297129e01046057F1D294c7974) |
| Robinhood | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://robinhoodchain.blockscout.com/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://robinhoodchain.blockscout.com/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://robinhoodchain.blockscout.com/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a](https://robinhoodchain.blockscout.com/address/0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a) | [0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA](https://robinhoodchain.blockscout.com/address/0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA) |
| Arbitrum | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://arbiscan.io/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://arbiscan.io/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://arbiscan.io/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9](https://arbiscan.io/address/0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9) | [0xAE0361b1C3454b297129e01046057F1D294c7974](https://arbiscan.io/address/0xAE0361b1C3454b297129e01046057F1D294c7974) |
| Avalanche | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://snowscan.xyz/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://snowscan.xyz/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://snowscan.xyz/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9](https://snowscan.xyz/address/0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9) | [0xAE0361b1C3454b297129e01046057F1D294c7974](https://snowscan.xyz/address/0xAE0361b1C3454b297129e01046057F1D294c7974) |
| Linea | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://lineascan.build/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://lineascan.build/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://lineascan.build/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9](https://lineascan.build/address/0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9) | [0xAE0361b1C3454b297129e01046057F1D294c7974](https://lineascan.build/address/0xAE0361b1C3454b297129e01046057F1D294c7974) |
| Base | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://basescan.org/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://basescan.org/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://basescan.org/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9](https://basescan.org/address/0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9) | [0xAE0361b1C3454b297129e01046057F1D294c7974](https://basescan.org/address/0xAE0361b1C3454b297129e01046057F1D294c7974) |
| Optimism | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://optimistic.etherscan.io/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://optimistic.etherscan.io/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://optimistic.etherscan.io/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9](https://optimistic.etherscan.io/address/0x61eF2e01E603aEB5Cd96F9eC9AE76cc6A68f6cF9) | [0xAE0361b1C3454b297129e01046057F1D294c7974](https://optimistic.etherscan.io/address/0xAE0361b1C3454b297129e01046057F1D294c7974) |
| Story | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://storyscan.xyz/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://storyscan.xyz/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://storyscan.xyz/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a](https://storyscan.xyz/address/0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a) | [0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA](https://storyscan.xyz/address/0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA) |
| Cronos | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://explorer.cronos.org/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://explorer.cronos.org/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://explorer.cronos.org/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a](https://explorer.cronos.org/address/0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a) | [0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA](https://explorer.cronos.org/address/0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA) |
| HyperEVM | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://hyperevmscan.io/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://hyperevmscan.io/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://hyperevmscan.io/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a](https://hyperevmscan.io/address/0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a) | [0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA](https://hyperevmscan.io/address/0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA) |
| Injective | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://blockscout.injective.network/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://blockscout.injective.network/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://blockscout.injective.network/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a](https://blockscout.injective.network/address/0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a) | [0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA](https://blockscout.injective.network/address/0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA) |
| Monad | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://mainnet-beta.monvision.io/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://mainnet-beta.monvision.io/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://mainnet-beta.monvision.io/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a](https://mainnet-beta.monvision.io/address/0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a) | [0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA](https://mainnet-beta.monvision.io/address/0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA) |
| MegaETH | [0xeF4fB24aD0916217251F553c0596F8Edc630EB66](https://mega.etherscan.io/address/0xeF4fB24aD0916217251F553c0596F8Edc630EB66) | [0xE7351Fd770A37282b91D153Ee690B63579D6dd7f](https://mega.etherscan.io/address/0xE7351Fd770A37282b91D153Ee690B63579D6dd7f) | [0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251](https://mega.etherscan.io/address/0x663DC15D3C1aC63ff12E45Ab68FeA3F0a883C251) | [0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a](https://mega.etherscan.io/address/0xE93356b0b87c71A7F4957DCEBEd05BefA8cB624a) | [0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA](https://mega.etherscan.io/address/0x05bD82Dbb7c5C2Cf571112bD1ad4e7c02E10eBEA) |
| TRON | [TX2Ut1reF59i2WPzsYVoMfA25EkUkavnd5](https://tronscan.org/#/address/TX2Ut1reF59i2WPzsYVoMfA25EkUkavnd5) | [TXCbCdoHjg28g36X5jnWTP88mRzx54RqXp](https://tronscan.org/#/address/TXCbCdoHjg28g36X5jnWTP88mRzx54RqXp) | [TRsqznGXF7mSYhRxU49L3HY13QW1v9yBZa](https://tronscan.org/#/address/TRsqznGXF7mSYhRxU49L3HY13QW1v9yBZa) | [TE8ZZHE8QEbjQLZCZv1PFKqiz2rCd7oPBV](https://tronscan.org/#/address/TE8ZZHE8QEbjQLZCZv1PFKqiz2rCd7oPBV) | [TJuJ19AsSBahPvg2j5AS3v37TtnmuMmeDL](https://tronscan.org/#/address/TJuJ19AsSBahPvg2j5AS3v37TtnmuMmeDL) |
## ABIs and Interfaces
The ABIs and the interfaces can be found [here](https://github.com/debridge-finance/abis-and-idls/tree/master/abis).
# Fee Structure
Source: https://docs.debridge.com/dln-details/overview/fee-structure
This page gathers every fee that can affect a DLN trade, explains how each one is calculated, and shows where to fetch the real‑time values.
One key reason the create-tx API is the recommended integration method is its ability to handle fee structure complexity. Accurately calculating each fee parameter under real-time market conditions—and balancing incentives across all stakeholders—is non-trivial. Excessive fees can deter end users, while insufficient fees may result in unfillable orders, negatively affecting both solvers and the application's success.
# Order‑Creation Fees (always paid)
When an order is placed, the protocol levies two mandatory fees:
* **Flat fee** – a fixed amount in the source‑chain native token paid to deBridge validators for processing the eventual unlock message. The current value is stored in DlnSource.globalFixedNativeFee().
* **Variable protocol fee (4 bps)** – deducted from the input token. This value is set in the percentFee field returned by create-tx and is visible in the DlnSource contract.
Both fees are fully refunded if the order is cancelled.
# Runtime Costs (built into the spread)
Because DLN has no central liquidity pool (0-TVL model), additional costs must be baked into the order, so a solver is willing to fulfil it:
**Taker margin (≈ 4 bps)** – the solver’s profit. The API inserts it automatically when creating a market or a reverse-market order. If a limit order (not recommended) is created, integrators need to make sure that the margin remains or the order may be ignored.
**Operating expenses** – the gas a solver spends on three transactions (fulfil, send unlock, claim). The API estimates the amount and exposes it under `estimation.costsDetails` when `prependOperatingExpenses=true`.
Recommendation – set prependOperatingExpenses=true so the estimate is added on top of srcChainTokenInAmount. This makes the fee transparent to the user and avoids approval mismatches. More information can be found here.
# Optional Fees
## Affiliate Fee
Affiliate fee is a share of the input token sent to a beneficiary when the order hits ClaimedUnlock. Configure with affiliateFeePercent and affiliateFeeRecipient. Details can be found in the Affiliate Fees article.
## Hook Execution Reward
If a non‑atomic hook is attached to an order, reward parameter in HookDataV1 may be set. The solver receives this amount before the hook runs.
# Additional Costs
* Pre‑Order‑Swap slippage (converting a non‑reserve input asset into a reserve asset during order placement).
* Pre‑Fill‑Swap slippage (converting a reserve asset into the requested asset on the destination chain).
* Gas for ERC‑20 approvals.
* Quote staleness if the user signs more than \~30 s after fetching it.
Slippage can be inspected in `estimation.costsDetails` and acted upon in runtime.
# Getting Live Values
| Fee Type | Source |
| ---------------------------- | -------------------------------------------------------------- |
| **Flat fee** | `DlnSource.globalFixedNativeFee()` or `response.tx.value` |
| **Variable fee** | `DlnSource.percentFeeBps()` or `costsDetails → DlnProtocolFee` |
| **Operating expenses** | `costsDetails → EstimatedOperatingExpenses` |
| **Recommended taker margin** | `costsDetails → TakerMargin` |
These values should always be queried at quote time; never hard‑coded. Calls to `create-tx` API will already calculate everything
according to supplied request parameters.
# Example
Sell 1000 USDC on Arbitrum, buy USDC on Polygon (auto‑quote) with `prependOperatingExpenses` set to `true`.
Flat fee: 0.001 ETH
Variable fee: 0.04 % × 1 000 = 0.40 USDC
Taker margin: 0.40 USDC
Operating expenses: ≈ 0.03 USDC
The user would need to approve either an unlimited amount for the ERC-20 contract or approve the amount calculated below:
```typescript theme={null}
function getEstimatedOperatingExpenseFeeAmount(response: ApiResponse)
: string | undefined {
return response.estimation.costsDetails.find(
(detail) => detail.type === "EstimatedOperatingExpenses"
).payload.feeAmount;
}
const response: ApiResponse = /* fetch or assign your create-tx response */;
const inputAmount = Bigint("1000000000"); // 1000USDC on Polygon, 6 decimals
const operatingExpense = Bigint(getEstimatedOperatingExpenseFeeAmount(response));
// Add 30% buffer for operating expenses
const adjustedOperatingExpense = (operatingExpense * 13n) / 10n; // multiply by 1.3
const totalApproveAmount = inputAmount + adjustedOperatingExpense;
```
The reason for leaving a buffer for operating expenses is that gas prices may spike if the transaction is not signed and submitted within approximately 30 seconds of receiving the create-tx response. Sometimes that happens if the user is idle. To account for this, quotes should be refreshed every \~30 seconds until the transaction has been submitted on-chain.
Total expenses are: \~0.83 USDC.
The user approves for \~1000.39 USDC on Polygon.
The user receives \~999.2 USDC on Polygon (Variable fee and Taker margin are taken out of the input token amount) and sees 0.001 ETH leave their Arbitrum wallet. If the order cancels, everything is refunded.
# Best Practice Checklist for Integrators
* Always call create-tx to create a market order or a reverse-market order unless intentionally placing a limit order (not recommended).
* Enable prependOperatingExpenses .
* Refresh the quote after 30 s if the order is not submitted.
* Either approve an unlimited allowance for ERC-20 tokens, or include a 30% buffer over the estimated operating expenses to account for cases where the transaction is not approved and submitted within 30 seconds of receiving the create-tx response. This ensures that the approval remains valid even if the quote is refreshed and prevents the need for users to repeat the approval step.
* Show the flat fee and the spread components separately in the UI.
* Surface a warning if the solver margin drops below \~4 bps for limit orders.
# Fees and Supported Chains
Source: https://docs.debridge.com/dln-details/overview/fees-supported-chains
DLN Protocol overview
deBridge charges a small fee when an order is created through DlnSource smart contracts.
The fee is what users pay for confidence and decentralization. It consists of two parts:
* A flat fee is paid in the native gas token of the chain where the order is created
* A variable fee of 4bps is paid in the input token
| Chain | Chain ID | Internal Chain ID | Flat Fee |
| --------- | --------- | ----------------- | ---------- |
| Arbitrum | 42161 | 42161 | 0.001 ETH |
| Avalanche | 43114 | 43114 | 0.05 AVAX |
| BNB Chain | 56 | 56 | 0.005 BNB |
| Ethereum | 1 | 1 | 0.001 ETH |
| Polygon | 137 | 137 | 0.5 MATIC |
| Robinhood | 4663 | 4663 | 0.001 ETH |
| Solana | 7565164 | 7565164 | 0.015 SOL |
| Linea | 59144 | 59144 | 0.001 ETH |
| Optimism | 10 | 10 | 0.001 ETH |
| Base | 8453 | 8453 | 0.001 ETH |
| Story | 1514 | 100000013 | 0.01 IP |
| Cronos | 25 | 100000019 | 15 CRO |
| HyperEVM | 999 | 100000022 | 0.05 WHYPE |
| TRON | 728126428 | 100000026 | 4 TRX |
| Injective | 1776 | 100000029 | 0.09 INJ |
| Monad | 143 | 100000030 | 2 MON |
| MegaETH | 4326 | 100000031 | 0.001 ETH |
The fee is fully refunded in case an order is cancelled.
Protocol fees can be changed. Hence, for any on-chain interactions with deBridge,
fees must not be hardcoded but queried dynamically from the state of the DLN smart contract.
Please refer to Estimating the order to learn how to query the actual flat fee from the smart contract.
# Introduction
Source: https://docs.debridge.com/dln-details/overview/introduction
Introduction to the deBridge Liquidity Network (DLN) – a 0-TVL cross-chain trading infrastructure that enables near-instant settlement, limit orders, zero slippage, and more. Learn about the DLN API and how to get started with building cross-chain experiences.
# deBridge Liquidity Network (DLN)
deBridge Liquidity Network uses a 0-TVL cross-chain trading infrastructure to facilitate high-performance cross-chain exchange.
Instead of using liquidity pools, the DLN executes all trades asynchronously through a self-organized liquidity network, providing
developers and projects with the ability to leverage the fastest cross-chain experience on the market and transfer liquidity and
information with faster time to finality than any legacy cross-chain solution.
![Bridging]()
By shifting the cross-chain paradigm from bridging to networking, deBridge enables myriad unique features for applications and
users:
* Near-instant settlement
* Limit orders for any cross-chain trade
* Zero slippage on any order size
* Unlimited market depth
* Guaranteed rates and low fees
* Native token trading (no custodial risks of wrapped assets)
* Zero locked liquidity at risk (0-TVL)
* Rapidly scalable (can process any trading volume)
* Gasless limit orders (users can commit orders without any upfront costs — tokens are deducted only if execution is guaranteed on
the destination chain) (coming soon)
* Order + call data allows adding instructions to be executed together alongside order fulfillment
The [DLN API](/dln-details/integration-guidelines/order-creation/authentication) provides developers an effortless way to interact
with the DLN protocol and trade across chains in seconds with deep liquidity, limit orders, and protection against slippage and
MEV. The API takes the burden off of building complex and sometimes painful interactions with blockchain RPCs and smart contracts
by providing a complete set of RESTful endpoints, sufficient to quote, create, and manage trades during their whole lifecycle.
# Next Steps
The next steps would be to:
* delve into the specifics with the [protocol overview](/dln-details/overview/protocol-overview).
* start building with [the DLN API](/dln-details/integration-guidelines/order-creation/authentication)
* integrate [deBridge Widget](/dln-details/widget/deBridge-widget) within minutes into an app
* use the [MCP Server](/dln-details/mcp/mcp-server) to integrate DLN into AI agents
# SDK & API License Agreement
Source: https://docs.debridge.com/dln-details/overview/legal
License agreement for using the deBridge SDK and APIs.
Last Updated: 01 October 2025
This API licence agreement (this "Agreement") is entered into as of the date which the Client first accesses, downloads or utilises the Licensor's
APIs (the "Effective Date"), and is a legally binding contract between DXTECH INC., a company incorporated under the laws of Panama (the "Licensor")
and you (the "Client", together with the Licensor the "Parties", and each a "Party"), and applies to the use of the API (as defined herein) and
associated SDK and documentation, available through `https://debridge.com` (the "Website"). If you do not agree to be bound by the terms and
conditions of this Agreement, please do not proceed with the use of the API.
YOU ARE ENTERING A LEGALLY BINDING CONTRACT: BY COPYING, DOWNLOADING, OR OTHERWISE USING THE LICENSOR'S API OR SDK YOU ARE EXPRESSLY AGREEING TO BE
BOUND BY ALL TERMS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THIS AGREEMENT, YOU ARE NOT AUTHORIZED TO COPY, DOWNLOAD, INSTALL OR
OTHERWISE USE THE LICENSOR'S API or SDK.
WE MAY AMEND ANY PORTION OF THIS AGREEMENT AT ANY TIME BY POSTING THE REVISED VERSION OF THIS AGREEMENT AND UPDATING THE "LAST UPDATED" DATE ABOVE.
THE CHANGES WILL BECOME EFFECTIVE IMMEDIATELY AND SHALL BE DEEMED ACCEPTED BY YOU THE FIRST TIME YOU USE OR ACCESS THE API AFTER THE INITIAL POSTING
OF THE REVISED AGREEMENT AND SHALL APPLY ON A GOING-FORWARD BASIS WITH RESPECT TO YOUR USE OF THE API. IN THE EVENT THAT YOU DO NOT AGREE WITH ANY
SUCH MODIFICATION, YOUR SOLE AND EXCLUSIVE REMEDY ARE TO TERMINATE YOUR USE OF THE API.
WHEREAS:
1. The Client desires to license the Licensor's APIs (as defined herein) for the purpose of offering the Cross-chain Bridge Services to the end users
of the Client’s Product (as defined below); and
2. The Licensor desires to license the APIs to the Client for the purposes of the Client providing the Cross-chain Bridge Services to the end users of
the Client’s Product.
NOW THEREFORE in consideration of the mutual covenants and agreements contained in this Agreement and other good and valuable consideration (the
receipt and sufficiency of which are hereby acknowledged by each of the Parties), the Parties hereto agree as follows:
For the purpose of this Agreement:
“deBridge API” or "API" means the Licensor's "deBridge Liquidity Network (DLN)" application program interface(s) and associated SDK and documentation
for a cross-chain smart router algorithm which is an informational service that provides routing information that is used by the DLN Protocol
(deBridge API and its related services), which may include object code, software libraries, software tools, sample source code, published
specifications and documentation. deBridge API shall include any future, updated or otherwise modified version(s) thereof furnished by deBridge (in
its sole discretion) to Client.
"Client's Product" means any web application, mobile application, platform or business offered by the Client to its end users, including the
Cross-chain Bridge Services provided by the Client to its end users.
"Content" means any data and content received by the Client through the APIs, for example pricing or other market data.
"Relevant Blockchain Network" means the Solana blockchain network or such other blockchain network on which the API may provide services in respect
of.
"Cross-chain Bridge Services" means the service relating to decentralised cross-chain bridging of digital assets or cross-chain communications, or
similar services offered directly by the Client to its end users via the Client's Product.
"Term" shall have the meaning ascribed to it in Clause 16(a).
1. API LICENSE
* 1) Subject to the terms and conditions of this Agreement, the Licensor hereby grants to the Client a limited, non-exclusive, non-sublicensable,
non-transferable and non-assignable licence during the Term to: (i) use the API for the purpose of the Cross-chain Bridge Services provided via
the Client's Product; (ii) use the APIs to develop, test, and support the Client's Product; and (iii) display the Content received from the
APIs within the Client's Product. For the avoidance of doubt, the Client agrees that it has no right to distribute or allow access to the
stand-alone APIs to any person.
* 2. The Client agrees that it will devote such resources and undertake such work as may be necessary to integrate the API with the Client’s
Product. The Client agrees that it is solely responsible for the Client's Product, including the development, operation, maintenance and end
user support for the Client's Product.
* 3. In order to access the APIs, the Client must obtain the API keys from the Licensor via their documentation. The Client will be able to obtain
the necessary keys, tokens, passwords and/or other credentials (collectively, "Keys"), for accessing the APIs and managing the Client’s access
to the APIs. The Client acknowledges that it may be required to subscribe and pay for unique API Keys from the Licensor in order to qualify for
higher rate limits for APIs. The Client may only access the APIs with the Keys issued to the Client by the Licensor. The Client acknowledges
that access to the APIs may not always be available. The Client may not sell, transfer, sublicense or otherwise disclose its Keys to any other
party or use them with any other Client's Product or any other purpose other than that expressly permitted by the Licensor. The Client is
responsible for maintaining the secrecy and security of the Keys. The Client is fully responsible for all activities that occur using the Keys,
regardless of whether such activities are undertaken by the Client or a third party. The Client is responsible for maintaining up-to-date and
accurate information (including a current email address and other required contact information) for the Client’s access to the APIs. The
Licensor may discontinue the Client’s access to the APIs if such contact information is not up-to-date and/or the Client does not respond to
communications directed to such coordinates.
* 4. By providing access to the APIs and the Content, the Licensor is solely providing a technical service to the Client which allows the Client to
provide Cross-chain Bridge Services to its end users. The Licensor is not a party to any such agreement for Cross-chain Bridge Services between
the Client, the end user, or any counterparty to said Cross-chain Bridge Services.
* 5. The Client shall use reasonable efforts to cooperate with the Licensor during the Term of this Agreement, including without limitation
providing relevant information, providing relevant documents, and participating in relevant discussions.
2. API DOCUMENTATION
* 1) The Client agrees that its use of the APIs and display of the Content must comply with the technical documentation, usage guidelines, call volume
limits and other documentation related to the APIs, as the same may be updated by the Licensor from time to time (collectively, the "API
Documentation"), access to which the Client acknowledges having received from the Licensor. In the event of any conflict between the API
Documentation and this Agreement, this Agreement shall control.
3. FEES
* 1) The API is provided free of charge below prescribed rate limits as set out in the API documentation. Licensor reserves the right to charge fees
for future use of or access to API or SDK. If the Licensor decides to charge for access to the API or SDK, the Client does not have any
obligation to continue to use such API or SDK. The Client agrees to consult with the Licensor prior to setting the parameters for any fees
charged to its end users for the Cross-chain Bridge Services.
* 2. All sums payable under this licence are exclusive of goods and services tax, withholding tax or and any relevant local sales taxes, for which
the Client shall be responsible.
* 3. If the Client fails to make any payment due to the Licensor under this agreement by the due date for payment, the Client shall pay interest on
the overdue amount at the rate of 6% per annum. Such interest shall accrue on a daily basis from the due date until actual payment of the
overdue amount, whether before or after judgment. The Client shall pay the interest together with the overdue amount.
4. RESTRICTIONS
Except as expressly authorised under this Agreement or by the Licensor in writing, the Client agrees it shall not (and shall not permit or authorise
any other person to):
* 1. use the APIs or the Content in any manner that is not expressly authorised by this Agreement;
* 2. use the APIs or develop or use the Client's Product (i) for any illegal, unauthorised or otherwise improper purposes or (ii) in any manner which
would violate this Agreement or the API Documentation, breach any laws, regulations, rules or orders (including those relating to virtual assets,
intellectual property, data privacy, data transfer, international communications or the export of technical or personal data) or violate the
rights of third parties (including rights of privacy or publicity);
* 3. remove any legal, copyright, trademark or other proprietary rights notices contained in or on materials it receives or is given access to
pursuant to this Agreement, including the APIs, the API Documentation and the Content;
* 4. charge, directly or indirectly, any fees (including any unique, specific, or premium charges) for use of, or access to, the Content, the APIs or
the Client’s integration of the APIs in the Client's Product, except as approved in writing by the Licensor;
* 5. sell, lease, share, transfer or sublicense any Content obtained through the APIs, directly or indirectly, to any third party;
* 6. use the APIs in a manner that, as determined by the Licensor in its sole discretion, exceeds reasonable request volume, constitutes excessive or
abusive usage, or otherwise fails to comply or is inconsistent with any part of the API Documentation;
* 7. access the APIs for competitive analysis or disseminate performance information (including uptime, response time and/or benchmarks) relating to
the APIs;
* 8. use the APIs in conjunction with, or combine content from the APIs with, content obtained through scraping or any other means outside the APIs;
* 9. (i) interfere with, disrupt, degrade, impair, overburden or compromise the integrity of the APIs, the Licensor’s systems or any networks
connected to the APIs or the Licensor’s systems (including by probing, scanning or testing their vulnerability), (ii) disobey any requirements,
procedures, policies or regulations of networks connected to the APIs or the Licensor’s systems, (iii) attempt to gain unauthorised access to
the APIs, the Licensor’s systems or any information not permitted by this Agreement or circumvent any access or usage limits imposed by the
Licensor or (iv) transmit through the Client's Product or the use of the APIs any (A) content that is illegal, tortious, defamatory, vulgar,
obscene, racist, ethnically insensitive, or invasive of another person’s privacy, (B) content that promotes illegal or harmful activity, or
gambling or adult content, (C) viruses, worms, defects, Trojan horses, or any other malicious programs or code or items of a destructive nature
or (D) materials that could harm minors in any way;
* 10. copy, adapt, reformat, reverse-engineer, disassemble, decompile, download, translate or otherwise modify or create derivative works of the APIs,
the Content, the API Documentation, the Licensor’s website, or any of the Licensor’s other content, products or services, through automated or
other means;
* 11. interfere with the Licensor’s business practices or the way in which it licenses or distributes the APIs;
* 12. make any representations, warranties or commitments (i) regarding the APIs or (ii) on behalf of the Licensor; or
* 13. take any action that would subject the APIs to any third-party terms, including without limitation any open source software licence terms.
* 14. The All trades/intents created through the deBridge API can be fulfilled only by a solver that is verified and designated by deBridge, and shall
not be available for fulfilment by any other party.
* 15. The APIs shall not be used for aggregation purposes. As per the API Agreement, access is not granted for use-cases such as aggregation for
bridging or routing providers, or consolidation across multiple providers.
* 16. The Client shall not use the APIs for the purposes of trade aggregation, routing consolidation, or any similar functionality that combines or
re-routes orders across multiple liquidity providers, protocols, or services. Any use-case involving aggregation is expressly prohibited and not
within the scope of the license granted under this Agreement.
5. PROPRIETARY RIGHTS
* 1) The Licensor owns all rights, title, and interest, intellectual property in and to the APIs (including without limitation all output and
executables or derivative works of the APIs), and, subject to the foregoing, the Client owns all rights, title, and interest in and to the
Client's Product. Except to the limited extent expressly provided in this Agreement, neither Party grants, and the other Party shall not acquire,
any right, title or interest (including, without limitation, any implied licence) in or to any property of the other Party. All rights not
expressly granted herein are deemed withheld.
* 2. The Licensor does not store, send, or receive digital assets. This is because digital assets exist only by virtue of the ownership record
maintained on the Relevant Blockchain Network. Any creation or transfer of title that might occur in respect of any digital asset occurs on the
Relevant Blockchain Network (on the relevant contractual terms applicable to such creation and/or transfer), and the Licensor does not have any
role or responsibility in such transactions. the Licensor cannot guarantee that it, or any party can effect the transfer of such title or right
to any digital asset. Accordingly, the Licensor cannot provide any guarantee, warranty or assurance regarding the authenticity, uniqueness,
originality, quality, marketability, legality or value of any digital assets received in connection with the Cross-chain Bridge Services.
* 3. There may be various vulnerabilities, failures or abnormal behaviour of software relating to digital assets (e.g., token contract, wallet, smart
contract), or relating to the Relevant Blockchain Network, and the Licensor cannot be responsible for any losses in connection with the same,
including without limitation any losses in connection with (i) user error, such as forgotten passwords or incorrectly construed smart contracts
or other transactions, (ii) server failure or data loss, (iii) corrupted wallet files, or (iv) unauthorised access or activities by third
parties, including but not limited to the use of viruses, phishing, brute-forcing or other means of attack against the API, the Relevant
Blockchain Network, or the Client's or its end user's digital wallet.
6. AVAILABILITY, SECURITY AND STABILITY
* 1) The Licensor makes no guarantees with respect to the performance, availability or uptime of the APIs or the Content. The Licensor may conduct
maintenance on or stop providing any of the APIs or the Content at any time with or without written notice to the Client. The Licensor may change
the method of access to the APIs and API Documentation at any time.
* 2. The Parties agree that it is in the best interests of both Parties that the Licensor maintain a secure and stable environment. In the event of
degradation or instability of the Licensor’s system or an emergency, the Licensor may, in its sole discretion, temporarily suspend access to the
APIs or the Content under this Agreement without any requirement to provide prior notice to the Client.
7. CLIENT'S OBLIGATIONS
* 1) The Client agrees to report to the Licensor any errors or difficulties discovered related to the APIs and the characteristic conditions and
symptoms of such errors and difficulties.
* 2. The Client shall endeavour to inform the Licensor with respect to the interoperability and compatibility of the Client's Product with the
Licensor’s systems, the APIs and the Cross-chain Bridge Services as contemplated herein, and any issues or problems with respect thereto. The
Client agrees it will use its best efforts to achieve full interoperability and compatibility with the APIs. The Licensor agrees to use
commercially reasonable efforts to assist the Client with resolving any such issues or problems arising from the interoperability and
compatibility of the Client's Product with the APIs.
* 3. The Client agrees that the Licensor may monitor the use of the APIs to ensure quality, improve the APIs, and verify the Client’s compliance with
the terms of this Agreement.
* 4. The Client shall obtain and maintain in force (or as applicable procure the obtaining and maintenance in force of) all necessary licenses,
permissions, authorisations, consents and permits which may be necessary or desirable for the offering of the Client's Product.
* 5. The Client acknowledges and agrees that all reporting, information gathering and other obligations under applicable know-your-client, anti-money
laundering and anti-terrorist financing laws with respect to the Client’s end-users are the responsibility of the Client and the Licensor shall
not be responsible or have any liability for any of the foregoing. The Client agrees to provide such information to the Licensor if reasonably
requested by the Licensor.
* 6. Without prejudice to the foregoing, upon written request from the Licensor, the Client shall use all efforts to block any specific digital wallet
or address from accessing the Client's Product and/or the API integration.
* 7. The Client acknowledges and agrees that it shall be responsible for implementing and enforcing end user transaction limits to ensure each of its
end users do not use the Cross-chain Bridge Services to complete transactions or a series of transactions that would, alone or in the aggregate
based on transaction size result in reporting obligations by either Party under applicable anti-money laundering and anti-terrorist financing
laws.
* 8. The Client agrees to immediately notify the Licensor if (i) the Client becomes aware of any security event, including any cybersecurity breach,
attack or economic exploit relating to the Client's Product (ii) the Client's Product or the Cross-chain Bridge Services become subject to any
legal or regulatory investigation or action, or (iii) the Client loses any intellectual property rights in the Client's Product or becomes aware
of any third-party claim in respect of the same.
* 9. The Client shall be responsible for all customer service for all its products and services (including the Client's Product).
* 10. The Client acknowledges and agrees that any swap surplus, positive slippage or equivalent proceeds resulting from the execution of trades via
the API shall be retained by the Licensor.
8. FEEDBACK
In the event the Client chooses to provide the Licensor with feedback, suggestions or comments regarding the APIs or the API Documentation, or the
Client and its end users’ use thereof, the Client agrees to provide a fully-paid up, royalty-free, non-exclusive, worldwide, transferable,
sublicensable, irrevocable right and license under all of the Client’s intellectual property rights to the Licensor to use, copy, modify, create
derivative works, distribute, publicly perform, grant sublicenses to, and otherwise exploit in any manner such feedback, suggestions or comments, for
any and all purposes, with no obligation of any kind to the Client.
9. REPRESENTATIONS AND WARRANTIES
Each Party represents and warrants to the other Party that:
* 1. it is duly organised, validly existing and in good standing under the laws of the jurisdiction in which it was organised and has the power to
enter into this Agreement and perform its obligations hereunder;
* 2. this Agreement has been duly authorised, executed and delivered by it and is a legal, valid and binding obligation of it, enforceable against it
by the other Party in accordance with its terms, except as enforcement may be limited by bankruptcy, insolvency and other laws affecting the
rights of creditors generally and except that equitable remedies may be granted only in the discretion of a court of competent jurisdiction; and
* 3. the execution and delivery of this Agreement by it and the consummation of the transactions herein provided for will not result in the violation
of, or constitute a default under, or conflict with or cause the acceleration of any obligation of it under: (i) any contract or agreement to
which it is a party or by which it is bound; (ii) any provision of its constating documents, by-laws or resolutions; (iii) any judgment, decree,
order or award of any court, governmental body or arbitrator having jurisdiction over it; or (iv) any applicable law, statute, ordinance,
regulation or rule.
10. CONFIDENTIALITY
* 1) The Parties agree that for purposes of this Agreement, "Confidential Information" means all information which is non-public, confidential or
proprietary in nature, whether transferred in writing, orally, visually, electronically or by other means, disclosed by one Party (the
"Disclosing Party") to the other Party (the "Receiving Party"), including the APIs, the Content (including all improvement, derivatives,
modifications and the like), the Application, the terms of this Agreement and any reports, analyses or notes that are based on, reflect or
contain Confidential Information. Confidential Information shall not include any information that: (i) is or becomes generally known to the
public other than as a result of a disclosure, in violation of this Agreement, by the Receiving Party, its affiliates or any of their officers,
directors, employees, agents, advisors, accountants, lawyers, auditors or representatives who have been informed of the Confidential Information
(collectively, the "Representatives"); (ii) was available or known to the Receiving Party or its Representatives before its disclosure hereunder;
(iii) is or becomes available to the Receiving Party or its Representatives from a source other than the Disclosing Party or its Representatives,
provided that the source of such information was not known by the Receiving Party or its Representatives to be prohibited from disclosing such
information to the Receiving Party or its Representatives by a legal, contractual or fiduciary obligation; or (iv) has otherwise been
independently acquired or developed by the Receiving Party or its Representatives without violating any obligations under this Agreement.
* 2. Each Receiving Party hereby agrees: (i) to hold the Confidential Information in confidence and to take reasonable precautions to protect such
Confidential Information (including all precautions the Receiving Party employs with respect to its own Confidential Information); (ii) not to
divulge any Confidential Information to any person except its Representatives, subject to the conditions stated below; (iii) not to use any
Confidential Information except for the purposes set forth in this Agreement; (iv) not to copy or reverse engineer any Confidential Information;
and (v) to be liable for any breaches by the Receiving Party’s Representatives of the provisions of this Agreement dealing with restrictions on
disclosure and use of the Confidential Information. Any Representative given access to the Confidential Information must have a legitimate "need
to know" and shall be permitted access to the Confidential Information only to the extent necessary to allow them to assist the Receiving Party
in meeting its obligations under this Agreement. Each Receiving Party further agrees that prior to granting such Representatives access to the
Confidential Information, the Receiving Party shall inform such Representatives of the confidential nature of the Confidential Information and of
the confidentiality obligations of this Agreement and require such Representatives to agree to abide by all the terms included herein.
* 3. If a Receiving Party or any of its Representatives is requested to disclose any Confidential Information in connection with any legal or
administrative proceeding or investigation, or is required by law, regulation, stock exchange or regulatory authority to disclose any
Confidential Information, such person will: (i) promptly notify the Disclosing Party of the existence, terms and circumstances surrounding such a
request or requirement (unless prohibited by law, regulation or order of a court or administrative tribunal) so that the Disclosing Party may
seek a protective order or other appropriate remedy, or waive compliance with the provisions of this Agreement; and (ii) if, in the absence of a
protective order, such disclosure is required in the opinion of such person's counsel, such person may make such disclosure without liability
under this Agreement, provided that such person only furnishes that portion of the Confidential Information which is legally required, gives the
Disclosing Party notice of the information to be disclosed as far in advance of its disclosure as practicable (unless prohibited by law,
regulation or order of a court or administrative tribunal) and, upon the Disclosing Party's request and at the Disclosing Party's expense,
cooperates in any efforts by the Disclosing Party to ensure that confidential treatment shall be accorded to such disclosed Confidential
Information.
* 4. As soon as practicable after termination of this Agreement or receipt of a notice from the Disclosing Party to the Receiving Party, the Receiving
Party shall: (i) at its election, either destroy or return to the Disclosing Party all Confidential Information furnished by the Disclosing Party
which is in tangible or electronic form, including any copies which the Receiving Party or its Representatives have made; and (ii) certify to the
Disclosing Party, in writing, that the Receiving Party has done the foregoing. Any Confidential Information that is not returned or destroyed,
including, without limitation, any oral Confidential Information, will remain subject to the confidentiality obligations set forth in this
Agreement. Notwithstanding the foregoing, the Receiving Party may retain: (A) one copy of the Confidential Information solely for evidentiary
purposes in the event of any dispute or proceeding based on or arising from this Agreement; (B) copies of any computer records and files
containing any Confidential Information that have been created pursuant to the Receiving Party’s automatic electronic archiving and back-up
procedures until such computer records and files have been deleted in the ordinary course; and (C) one copy of any Confidential Information to
the extent retention of such Confidential Information is required to comply with applicable law or regulation.
* 5. Each Receiving Party understands and agrees that monetary damages would not be a sufficient remedy for any breach of this Clause 10 by the
Receiving Party or its Representatives and that, in addition to all other remedies, the Disclosing Party shall be entitled to specific
performance or injunctive or other equitable relief as a remedy for any such breach. Each Receiving Party agrees to waive, and to cause its
Representatives to waive, any requirement for the securing or posting of any bond or security in connection with such remedy.
11. PUBLICITY
* 1) Subject to the obligations under Clause 10 each of the Parties agrees that the other Party may disclose and publicise the existence of the
business relationship between the Licensor and the Client on its website and in promotional and marketing materials upon consent of the other
Party.
* 2. Subject always to the Licensor's marketing and communications criteria for co-marketing of products (at its sole discretion), the Parties shall
use reasonable efforts to mutually engage in cross-marketing activities to highlight the co-operation between the Parties in official
communications.
* 3. The Parties shall mutually agree on the contents, scope and medium of publicity for the other Party's brand or all associated advertising,
promotional or marketing materials (including on social media), including without limitation clearly featuring the other Party's brand on
applications, websites, Video tutorials, co-authoring marketing materials on Twitter Spaces, Discord Stages, or Community Events, public
relations and/or relevant social media posts and announcements.
12. INDEMNITY
The Client agrees that the Licensor and its affiliates and their respective shareholders, directors, officers, employees, representatives, agents,
contractors, customers and licensees (collectively, the "Indemnified Parties") shall have no liability whatsoever for, and the Client shall indemnify
and hold harmless the Indemnified Parties from and against, any and all claims, losses, damages, liabilities, costs and expenses (including reasonable
lawyer’s fees) arising from, in connection with or related to: (a) any use the Client or its end users makes of the API, the Content or the
Cross-chain Bridge Services; (b) the Client’s relationships or interactions with any end users or third party distributors of the Client's Product;
(c) the Client's Product; (d) the Client’s breach of the terms of this Agreement or (e) the gross negligence, wilful misconduct or fraud of the
Client, its affiliates and their respective shareholders, directors, officers, employees, representatives, agents, contractors, customers and
licensees.
13. WARRANTY DISCLAIMER
* 1) TO THE FULLEST EXTENT PERMITTED BY LAW, THE APIS AND THE CONTENT ARE PROVIDED "AS IS" AND "WITH ALL FAULTS" AND THE LICENSOR DISCLAIMS ALL
REPRESENTATIONS, WARRANTIES AND GUARANTEES, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING INFRINGEMENT OF THIRD PARTY RIGHTS OR IMPLIED
WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT AND FITNESS FOR ANY PARTICULAR PURPOSE. THE LICENSOR MAKES NO REPRESENTATION, WARRANTY OR
GUARANTEE RELATED TO USEABILITY, EFFECTIVENESS, RELIABILITY, ACCURACY, OR COMPLETENESS OF THE APIS OR THE CONTENT, THAT THE LICENSOR WILL
CONTINUE TO OFFER THE APIS OR THE CONTENT OR THAT USE OF THE APIS OR THE CONTENT WILL BE RELIABLE, EFFECTIVE, SECURE, TIMELY, UNINTERRUPTED,
ERROR-FREE OR MEET THE CLIENT’S OR ITS END USERS’ REQUIREMENTS OR EXPECTATIONS.
* 2. The Client acknowledges that the API and Content, or any software in respect of the same cannot be wholly free from defects, errors, security
vulnerabilities, viruses, errors, failures, bugs or loopholes which may be exploited by third parties, or other harmful components and the
Licensor gives no warranty or representation that the API or Content, or any software in respect of the same will be wholly free from defects,
errors, security vulnerabilities, viruses, errors, failures, bugs or loopholes which may be exploited by third parties, or other harmful
components.
* 3. The Client acknowledges that the Licensor does not warrant or represent that the API, Content, or any software in respect of the same will be
compatible with the Client's Product, any other software or systems, or that the integration will proceed as intended.
* 4. The Licensor does not warrant or represent that the usage of the API and/or the Content by the Client will not give rise to any legal liability
on the part of the Client or any other person.
14. SERVICES DISCLAIMER
* 1) Neither the Licensor nor the API provides any digital asset exchange or brokerage service. Where the Client or any end user of the Client's
Product makes the decision to transact utilising the API or the Content, then such decisions and transactions and any consequences flowing
therefrom are such transacting party's sole responsibility.
* 2. THE API FUNCTIONS SOLELY AS A BACK-END SUPPORTING TECHNICAL SERVICE FOR ON-CHAIN TOKEN CROSS-CHAIN BRIDGE SERVICES, AND IN NO CIRCUMSTANCES SHALL
THE LICENSOR, THE API OR THE CONTENT BE CONSTRUED AS A DIGITAL ASSET EXCHANGE, BROKER, DEALER, FUND MANAGER, FINANCIAL INSTITUTION, CUSTODIAN,
ROBO-ADVISOR, INTERMEDIARY, OR CREDITOR;
* 3. THE API DOES NOT FACILITATE OR ARRANGE DIGITAL ASSET TRANSACTIONS BETWEEN COUNTERPARTIES, INCLUDING WITH RESPECT TO ANY TRANSACTIONS THAT OCCUR
IN CONNECTION WITH ANY DECENTRALISED EXCHANGE, LIQUIDITY POOL OR OTHER CENTRALISED OR DECENTALISED FINANCE PRODUCT / FACILITY, WHICH TRANSACTIONS
OCCUR ON SUCH PLATFORM, PROTOCOL AND/OR THE RELEVANT BLOCKCHAIN NETWORK. THE LICENSOR IS NOT A COUNTERPARTY TO ANY DIGITAL ASSET TRANSACTION
FACILITATED BY THE API, THE CONTENT OR THE CLIENT'S PRODUCT. NEITHER THE LICENSOR, THE API OR THE CONTENT PROVIDES FINANCIAL ADVISORY, LEGAL,
REGULATORY, OR TAX SERVICES DIRECTLY, INDIRECTLY, IMPLICITLY, OR IN ANY OTHER MANNER, AND YOU SHOULD NOT CONSIDER ANY API OR CONTENT TO BE A
SUBSTITUTE FOR PROFESSIONAL FINANCIAL, LEGAL, REGULATORY, TAX OR OTHER ADVICE. THE LICENSOR DOES NOT SUPPORT OR ENDORSE ANY DECENTRALISED
EXCHANGE, LIQUIDITY POOL OR OTHER CENTRALISED OR DECENTALISED FINANCE PRODUCT / FACILITY, AND EACH SUCH ENTITY OR BUSINESS IS AN INDEPENDENT
AGENT WITH NO EMPLOYMENT OR OTHER CONTRACTUAL RELATIONSHIP WITH THE LICENSOR.
15. LIMITATION OF LIABILITY
* 1) TO THE FULL EXTENT PERMITTED BY LAW, IN NO EVENT WILL THE LICENSOR BE LIABLE FOR ANY LOSS OF USE, LOST OR INACCURATE DATA (INCLUDING WITHOUT
LIMITATION PRICES OR QUOTES), ERRORS, FAILURE OF SECURITY MECHANISMS, INTERRUPTION OF BUSINESS, COST OF PROCUREMENT OF SUBSTITUTE GOODS, SERVICES
OR TECHNOLOGY OR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY KIND (INCLUDING LOST PROFITS OR LOST DATA), REGARDLESS OF THE
FORM OF ACTION, WHETHER IN CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY OR OTHERWISE, EVEN IF INFORMED OF THE POSSIBILITY OF SUCH
DAMAGES IN ADVANCE. TO THE FULL EXTENT PERMITTED BY LAW, IN NO EVENT WILL THE LICENSOR’S AGGREGATE LIABILITY FOR ANY AND ALL CLAIMS, LOSSES,
DAMAGES, LIABILITIES, COSTS AND EXPENSES (INCLUDING REASONABLE LAWYER’S FEES) ARISING FROM, IN CONNECTION WITH OR RELATED TO THIS AGREEMENT, THE
APIS AND THE CONTENT EXCEED THE HIGHER OF (I) USD 200 OR (II) THE PORTION OF THE FEES PAID BY THE CLIENT TO THE LICENSOR IN THE THREE (3) MONTHS
PRIOR TO SUCH CLAIM. NOTWITHSTANDING ANYTHING TO THE CONTRARY, THE LICENSOR HAS NO WARRANTY, INDEMNIFICATION OR OTHER OBLIGATION OR LIABILITY
WITH RESPECT TO THE CLIENT'S PRODUCT OR ITS COMBINATION, INTERACTION, OR USE WITH ANY CROSS-CHAIN BRIDGE SERVICES, THE APIS OR THE CONTENT.
* 2. Without prejudice to the generality of the foregoing, the Client acknowledges that the API(s) and Content is provided "as-is", so the Licensor
shall not be liable in any manner for any direct, indirect, special, incidental or consequential loss, damage, liability, costs or expenses
suffered by the Client due to any incorrect, delayed or lost data, price information, quotes, routing or any other attribute, information or
factor relating to the API(s) or Content, regardless of the form of action, whether in contract, tort (including negligence), strict liability or
otherwise, and whether or not due to defects, errors, security vulnerabilities, viruses, errors, failures, bugs or loopholes which may be
exploited by third parties, or other harmful components.
* 3. The Client acknowledges and agrees that this Clause 15 reflects a reasonable allocation of risk and that the Licensor would not have entered into
this Agreement without these liability limitations.
* 4. This Clause 15 will survive notwithstanding any limited remedy’s failure of essential purpose.
16. TERMINATION; SURVIVAL
* 1) This Agreement shall commence as of the Effective Date until terminated in accordance with the provisions herein (the Term).
* 2. Either Party may terminate this Agreement immediately if the other Party:
* * 1. breaches any material term of this Agreement and such breach has not been rectified within 15 days of notice of such breach to the other Party;
or
* * 2. (A) becomes insolvent, (B) fails to pay its debts or perform its obligations in the ordinary course of business as they mature, (C)
admits in writing its insolvency or inability to pay its debts or perform its obligations as they mature or (D) become the subject of any
voluntary or involuntary proceeding in bankruptcy, liquidation, dissolution, receivership, attachment or composition or general assignment for
the benefit of creditors that is not dismissed with prejudice within 30 days after the institution of such proceeding.
* 3. Notwithstanding any of the provisions herein, the Licensor shall have the right to terminate this Agreement upon ten (10) days' written notice to
the Client.
* 4. Upon termination of this Agreement, the Licensor may immediately revoke all of the Keys provided to the Cross-chain Bridge Services and/or the
APIs. The Parties shall also comply with the provisions regarding Confidential Information under Clause 10(b). Any termination of this Agreement
shall automatically terminate the licenses granted hereunder.
* 5. Clauses 4, 5, 10, 12, 13, 15, 16 and 17 (and any accrued rights to payment) shall survive termination of this Agreement.
17. GENERAL
* 1) Except as may be otherwise specifically provided in this Agreement and unless the context otherwise requires, in this Agreement: (i) the terms
"Agreement", "this Agreement", "the Agreement", "hereto", "hereof", "herein", "hereby", "hereunder" and similar expressions refer to this
Agreement in its entirety and not to any particular provision hereof; (ii) references to a "Clause" or "Schedule" followed by a number or letter
refer to the specified Clause of or Schedule to this Agreement; (iii) the division of this Agreement into sections and the insertion of headings
are for convenience of reference only and shall not affect the construction or interpretation of this Agreement; (iv) words importing the
singular number only shall include the plural and vice versa and words importing the use of any gender shall include all genders; (v) the word
"including" is deemed to mean "including without limitation"; (vi) the terms "Party" and "the Parties" refer to a Party or the Parties to this
Agreement; (vii) any reference to this Agreement means this Agreement as amended, modified, replaced or supplemented from time to time; (viii)
any reference to a statute, regulation or rule shall be construed to be a reference thereto as the same may from time to time be amended,
re-enacted or replaced, and any reference to a statute shall include any regulations or rules made thereunder; (ix) any time period within which
a payment is to be made or any other action is to be taken hereunder shall be calculated excluding the day on which the period commences and
including the day on which the period ends; and (x) whenever any payment is required to be made, action is required to be taken or period of time
is to expire on a day other than a "Business Day", being any day other than a Saturday, Sunday or statutory holiday in Panama on which commercial
banks in Panama are open for business, such payment shall be made, action shall be taken or period shall expire on the next following Business
Day.
* 2. The Parties agree that they are independent contractors under this Agreement and nothing in this Agreement authorises either Party to act as a
legal representative or agent of the other for any purpose. It is expressly understood that this Agreement does not establish a franchise
relationship, partnership, principal-agent relationship, or joint venture. Neither Party shall have the power to bind the other with respect to
any obligation to any third Party.
* 3. This Agreement shall be interpreted and enforced in accordance with, and the respective rights and obligations of the Parties shall be governed
by, the laws of Panama. Any controversy or dispute which arises out of or is related to this Agreement, and interpretation, application,
performance or termination thereof, must be decided by arbitration, following an attempt at Conciliation, administered by Panama Conciliation and
Arbitration Centre in accordance with its procedural rules for the time being in force. The tribunal shall consist of 1 arbitrator, who shall
have exclusive authority to decide all issues relating to the interpretation, applicability, enforceability and scope of this Agreement
(including this arbitration agreement). The language used in the arbitral proceedings shall be English. Each Party irrevocably submits to the
jurisdiction and venue of such tribunal. Judgment upon the award may be entered by any court having jurisdiction thereof or having jurisdiction
over the relevant Party or its assets.
* 4. No amendment or waiver of any provision of this Agreement shall be binding on any Party unless consented to in writing by such Party. No waiver
of any provision of this Agreement shall constitute a waiver of any other provision, nor shall any waiver of any provision of this Agreement
constitute a continuing waiver unless otherwise expressly provided.
* 5. If any provision of this Agreement is determined by a court of competent jurisdiction to be invalid, illegal or unenforceable in any respect, all
other provisions of this Agreement shall nevertheless remain in full force and effect so long as the economic or legal substance of the
transactions contemplated hereby is not affected in any manner materially adverse to any Party hereto.
* 6. This Agreement shall ensure to the benefit of and shall be binding on and enforceable by and against the Parties and their respective successors
or heirs, executors, administrators and other legal personal representatives, and permitted assigns.
* 7. No Party may assign any of its rights or benefits under this Agreement, or delegate any of its duties or obligations, except with the prior
written consent of the other Party. Notwithstanding the foregoing, any Party may assign and transfer all of its rights, benefits, duties and
obligations under this Agreement in their entirety, without the consent of the other Party, to: (i) an affiliate, provided that the assignor
shall continue to be subject to the rights and obligations of this Agreement; or (ii) a purchaser of all or substantially all of the business of
the assignor, provided that the assignor promptly provides notice to the non-assigning Party, the successor in interest has agreed to assume all
of the assignor’s rights and obligations and the non-assigning Party has the right to terminate the Agreement upon receipt of notice of transfer
if the successor in interest, in the non-assigning Party’s sole reasonable determination, is a competitor of the non-assigning Party.
* 8. Any notice or other communication required or permitted to be given hereunder shall be in writing and shall be delivered by e-mail or similar
means of recorded electronic communication to the contact details set out in the signature page. Any such notice or other communication shall be
deemed to have been given and received, in the case of electronic mail, at the time that it is received in recipient’s inbox in readable form,
provided that such electronic mail is kept on file (whether electronically or otherwise) by the sending party and the sending party does not
immediately receive an automatically generated message from the recipient’s electronic mail server that such electronic mail could not be
delivered to such recipient. Any Party may at any time change its contact details for service from time to time by giving notice to the other
Party in accordance with this Clause 17(8).
* 9. This Agreement constitutes the entire agreement between the Parties with respect to the subject matter hereof and supersedes all prior
agreements, understandings, negotiations, and discussions, whether written or oral. There are no conditions, covenants, agreements,
representations, warranties, or other provisions, express or implied, collateral, statutory or otherwise, relating to the subject matter hereof
except as provided herein.
* 10. Time shall be of the essence of this Agreement.
* 11. Each Party will pay for its own costs and expenses incurred in connection with the negotiation, preparation, execution and performance of this
Agreement, and the transactions contemplated herein, including the fees and expenses of legal counsel, financial advisors, accountants,
consultants and other professional advisors and software development expenses.
* 12. Neither Party hereto shall be responsible for any failure to perform its obligations under this Agreement if such failure is caused by acts of
God, war, strikes, revolutions, lack or failure of transportation facilities, laws or governmental regulations or other causes that are beyond
the reasonable control of such Party. Obligations hereunder, however, shall in no event be excused but shall be suspended only until the
cessation of any cause of such failure.
* 13. Each of the Parties hereto shall, from time to time hereafter and upon any reasonable request of the other, do, execute, deliver or cause to be
done, executed and delivered, all further acts, documents and things as may be required or necessary for the purposes of giving effect to this
Agreement.
* 14. This Agreement and all documents contemplated by or delivered under or in connection with this Agreement may be executed and delivered in any
number of counterparts, with the same effect as if all Parties had signed and delivered the same document, and all counterparts shall be
construed together to be an original and will constitute one and the same agreement.
# Market and Limit Orders
Source: https://docs.debridge.com/dln-details/overview/market-and-limit-orders
Market and Limit Orders: Joining the deBridge Liquidity Network Protocol as a Solver and Minimization of volatility risks for Solvers.
The main trade-off of the deBridge Liquidity Network design is that order execution is not guaranteed in advance, just as it is not guaranteed by classical bridges based on liquidity pools, where a transaction may fail in the destination chain if slippage exceeds the slippage tolerance specified by the sender.
With the deBridge Liquidity Network Protocol, a transaction can’t fail on the destination chain. An order is either fulfilled or not fulfilled, and if it’s not fulfilled, it means there is no taker willing to take the order. This may happen due to the following reasons:
The order doesn’t generate sufficient profit for a taker. In this case, it’s a limit order that will be fulfilled as soon as market conditions will make it profitable
The order bears certain systemic risks. The advantage of the deBridge Liquidity Network Protocol is that it allows risks to be dynamically priced. Takers may not be willing to fulfill orders coming from chains where exploit or ecosystem-level hacks have happened. In this case, takers will expect a bigger premium laid into the spread of the order so that additional risks are compensated
Users can place orders to exchange any assets at any price, but if the order premium covers all overhead costs for takers and brings them a profit, they are economically incentivized to fulfill the order as fast as possible. In this case, this is a market order that will be settled shortly.
To facilitate the creation of market orders, deBridge provides a Quick Start Guide. Any integrator or an app can query the API in order to retrieve the recommended price for the order for their users and secure its immediate execution. The quote recommended by the API lays in a spread that includes a 4bps incentive for takers and covers overhead costs such as gas.
## Joining the deBridge Liquidity Network Protocol as a Solver
Solvers perform active on-chain liquidity management by fulfilling limit orders created through DLN.
Check [this Github Repository](https://github.com/debridge-finance/dln-taker) to learn more about how to get started as a Solver in DLN.
Solvers don't need to lock liquidity into pools, they always maintain ownership over their funds and have the
sole ability to fulfill limit orders they deem profitable.
![Creating an order diagram]()
## Minimization of volatility risks for Solvers
To minimize price fluctuation risks for takers, all transactions formed through DLN API automatically route any swap through the paired asset (USDC or
ETH). For example, if the user wants to exchange a token (e.g. AAVE on Ethereum) for another volatile token (e.g. Matic on Polygon), then DLN API will
form the transaction data where AAVE is [pre-swapped](/dln-details/dln-specifics/bridging-non-reserve-assets#pre-order-swap) into USDC, and a
USDC->Matic DLN order is created in the same transaction.
On the destination chain, solvers may hold USDC or ETH on a balance sheet of their on-chain addresses and swap their
asset into the token requested in the order (e.g. MATIC), and fulfill it in the same transaction. When `DlnDestination.sendUnlock()`
is called, the solver will receive the same paired asset (e.g. USDC) on the source chain, avoiding any price
fluctuations of volatile assets.
# Protocol Overview
Source: https://docs.debridge.com/dln-details/overview/protocol-overview
DLN Protocol overview
deBridge uses a high-performance cross-chain trading infrastructure that consists of two layers:
* Protocol layer: on-chain smart contracts
* Infrastructure layer: solvers who perform off-chain matching and on-chain settlement of trades
The deBridge Liquidity Network Protocol is represented by a set of smart contracts that can be called by any on-chain
address to create limit orders for cross-chain trades. When an order is created, the Maker provides a specific amount
of an input token on the source chain and specifies the parameters of the order, such as the token address and the
amount he accepts to receive in the destination chain.
The given amount is then temporarily locked by the DLN smart contract on the source chain, and any on-chain address
(named a solver) with sufficient liquidity in the destination chain can attempt to fulfill the order by calling the
corresponding method of DLN smart contract and supplying the liquidity as requested by the maker in the DLN order
parameters. After the order is fulfilled, a solver initiates a cross-chain message to be sent by the DLN smart contract
to the source chain via the deBridge messaging protocol. When the message is delivered, it unlocks the funds on the
source chain to the solver’s address, effectively completing the order. Below is a graphic outlining the process:
![Order execution flow diagram]()
# Order Creation
Specifically, there are two contracts deployed per supported chain: the `DlnSource` and the `DlnDestination` contracts.
Whenever a maker decides to trade liquidity, it places an order by calling the `DlnSource.createOrder()` method on the
source chain, providing the typed structure with precise requirements, specifically: the destination chain id, the
address of a token, and the amount they expect to receive, the address of the receiver where the requested tokens
should be sent to on the destination chain, and other system parameters. The smart contract assigns a unique identifier
(hash) to the order, made of the values of its typed structure including the maker-specific determinants (address and
nonce). The given amount of input token is taken from the user by the DlnSource contract and locked until the order
is either unlocked or cancelled, which can happen only through the DlnDestination smart contract on the destination chain.
![Source Chain Order Creation]()
# Order fulfillment
Solvers perform off-chain tracking of all orders created through DlnSource smart contract, and whenever an order meets
the solver's requirements (for example, the profitability, the margin, or even if the input token is whitelisted),
they can attempt to fulfill the order by calling the `DlnDestination.fulfillOrder()` on the destination chain, supplying
the amount of tokens requested in the order, and the typed structure representing the order placed on the source chain
and order Id. At this point, no cross-chain communication is performed. The DlnDestination contract relies on the fact
that the given order being placed on another chain can only be handled once on the destination chain, so it calculates
the order identifier (hash) using the values from the given structure. It then checks that it matches the order Id
passed by the solver and if the order status hasn’t been assigned as fulfilled or cancelled. The smart contract processes
the order by pulling the necessary amount of requested tokens from the solver and sending it to the receiver address,
finally assigning ‘fulfilled status’ to the order.
![Destination Chain Order Fulfillment Diagram]()
If the order generates some profit for the one who fulfills it, then solvers will have fair competition for its fulfillment.
For example, an order to exchange 1000 USDC on BNB Chain for 990 USDC on Solana will bring 10 USDC profit to the solver that
is the first to fulfill the order. Solvers are free to set their own requirements for transaction finality on the source chain.
For example, solvers with an aggressive risk profile may decide to fulfill orders after one block confirmation and try to
replay the maker’s transaction in case a reorg of the source chain happens after the order is fulfilled on the destination chain.
# Unlocking fulfilled orders
The first solver that manages to change the status of the order in the DlnDestination smart contract to Fulfilled, gets the
ability to call `DlnDestination.sendUnlock()` method which sends a cross-chain message through deBridge infrastructure to the
`DlnSource` smart contract on the source chain. This message encodes a command to unlock funds initially locked for the given
order identifier, and sends them to the address specified by the solver.
![Unlocking Fulfilled Orders Diagram]()
When the `DlnSource` smart contract receives a message, before executing the command, it checks the identity of the message sender
(address and chain id), to make sure it matches the identity of the `DlnDestination` smart contract stored in its state.
If a maker decides to cancel their order, it must use a similar flow, and call the `DlnDestination.sendCancel()` method which will succeed
only if the order is neither at the `Fulfilled` nor `Cancelled` status. This method makes the smart contract send a cross-chain message to
the `DlnSource` contract that encodes a command to unlock funds to the maker's address and change the order status to `Cancelled`.
In this case, the `DlnDestination` contract on the destination chain acts as a source of trust for the propagation of the order status and
sending corresponding commands.
Note: In the lifecycle of an order, cross-chain communication (messaging) is only needed once the order has achieved its final status
on the destination chain. This is so the `DlnDestination` smart contract can send a command to the `DlnSource` to unlock the
order’s liquidity to the solver's address (in case of fulfillment) or to the maker address (in case of cancellation).
When a cross-chain message is transferred through the deBridge infrastructure, strict finality requirements are applied before the
message is signed by validators. The number of required block confirmations needed for each chain can be found here.
# Risk distribution
Since the protocol doesn’t have any continuously locked liquidity, all DLN participants bear risks asynchronously.
Makers bear the risk of cross-chain infrastructure only during the short time span from the moment an order has been created,
until the moment when the order is fulfilled on the destination chain, which is typically an extremely short time period of seconds.
Solvers bear risks only from the moment an order has been fulfilled, until the moment when the liquidity is unlocked on the source chain.
These risks consist of two components:
* The risk of order reversal due to source chain reorganization or fork. This risk is taken by solvers consciously, and is controlled by
setting requirements for transaction finality: they fulfill orders only after the number of block confirmations in the source chain aligns
with their risk profile. For example, a solver may execute small orders as soon as they appear on the source chain, but wait for extra
block confirmations in the case of an exceptionally large order; more complex rules can be applied to meet the needs of solvers.
This also creates the potential to compete for orders that are not yet broadcasted, fulfilling them even BEFORE they are included on the source
blockchain, which is a win-win case: users get to receive the exact amount of funds they have requested quickly, and professional market makers
take profits according to their risk profiles without affecting users.
* Risk of the cross-chain messaging infrastructure. The collusion of consensus participants is a trade-off that is born by all interoperability
solutions without exception. The deBridge messaging infrastructure has a delegated staking and slashing module as part of the protocol design which
prevents any theoretical collusion of validators.
![Risk distribution diagram]()
# Use Cases
Source: https://docs.debridge.com/dln-details/overview/use-cases
Multiple ways of integration - which one is right?
# Integration Overview
There are several ways to integrate deBridge into your dApp, wallet, or protocol, depending on the specific use case. This section provides a high-level overview of the available integration methods: API, Widget, and Smart Contracts.
# deBridge API
Recommended for most production-grade integrations
→ Learn more about the API
The deBridge API is the most robust and flexible integration method, abstracting away the complexities of cross-chain trading, smart contract interactions, and blockchain infrastructure. It provides RESTful endpoints to quote, create, and manage trades throughout their lifecycle. This improves transaction success rates and user experience, while reducing engineering overhead.
Recommended if integrators:
* Want full control over the UX/UI
* Are building custom workflows or high-frequency trading logic
* Need integration with backend infrastructure
* Are targeting mobile-native or non-browser environments
Use cases:
Coming soon: examples such as exchange aggregators, non-custodial wallets, yield platforms, etc.
# deBridge Widget
Best for rapid integration and prototyping
→ Learn more about the Widget
The deBridge Widget enables any web-based project to offer cross-chain swaps in minutes. It’s a pre-built UI component embeddable via iframe, fully customizable with themes, chains, tokens, and more. It also supports JavaScript-based event listeners and method calls for deeper interaction.
Recommended if integrators:
* Want a fast time-to-market with minimal development effort
* Don’t need custom UX or transaction logic
* Are building a frontend-heavy app, or integrating within a website or mobile WebView
* Want to prototype or test before deeper integration
Use cases:
Coming soon: examples such as token swap pages, DeFi frontends, portfolio dashboards, etc.
# Smart Contract Integration (DLN Protocol)
Best for advanced and trustless DeFi integrations
→ Learn more about the DLN Protocol Smart Contracts
The deBridge Liquidity Network (DLN) Protocol enables direct interaction with on-chain smart contracts to place and fulfill cross-chain limit orders. Developers can work directly with DlnSource and DlnDestination contracts for advanced decentralized workflows. This provides maximum flexibility, trustless execution, and fine-grained control.
Recommended if integrators:
* Need a fully decentralized integration with no off-chain components
* Are building a protocol-level feature (e.g., DEX, bridge aggregator)
* Want to operate as a solver or liquidity provider
* Need deterministic on-chain behavior and verifiability
Use cases:
Coming soon: examples such as limit order protocols, liquidity relayers, solver networks, etc.
# Deterministic Order ID
Source: https://docs.debridge.com/dln-details/protocol-specs/deterministic-order-id
How DLN order IDs are derived, including inputs and hash format.
An order placed onto DLN is identified by a deterministic keccak256 hash derived from an array of bytes that contains all the properties of the order.
The array is designed to be cross-chain compatible, so the smart contracts residing on both EVM and Solana can easily reproduce it. The smart
contracts implementing the DLN protocol usually accept all these properties as a single data struct and derive an orderId programmatically to
guarantee the order with the proper orderId is being managed.
To get the deterministic orderId of the order, the array of bytes should contain its following properties:
| Bytes | Bits | Field |
| ----- | ---- | ------------------------------------------- |
| 8 | 64 | Salt |
| 1 | 8 | Maker Src Address Size (!=0) |
| N | 8\*N | Maker Src Address |
| 32 | 256 | Give Chain Id |
| 1 | 8 | Give Token Address Size (!=0) |
| N | 8\*N | Give Token Address |
| 32 | 256 | Give Amount |
| 32 | 256 | Take Chain Id |
| 1 | 8 | Take Token Address Size (!=0) |
| N | 8\*N | Take Token Address |
| 32 | 256 | Take Amount |
| 1 | 8 | Receiver Dst Address Size (!=0) |
| N | 8\*N | Receiver Dst Address |
| 1 | 8 | Give Patch Authority Address Size (!=0) |
| N | 8\*N | Give Patch Authority Address |
| 1 | 8 | Order Authority Address Dst Size (!=0) |
| N | 8\*N | Order Authority Address Dst |
| 1 | 8 | Allowed Taker Dst Address Size |
| N | 8\*N | \* Allowed Taker Address Dst |
| 1 | 8 | Allowed Cancel Beneficiary Src Address Size |
| N | 8\*N | \* Allowed Cancel Beneficiary Address Src |
| 1 | 8 | Is Hook Presented 0x0 - Not, != 0x0 - Yes |
| 32 | 256 | \* Hook Envelope Hash |
# EVM Chains Hook Anatomy
Source: https://docs.debridge.com/dln-details/protocol-specs/evm-chains-hook-anatomy
Learn about EVM Chain Hook Anatomy – Envelope v1, Hook data V1 layout, and Universal Hook.
During order fulfillment the `DlnDestination` smart contract performs standard routine procedures, including checking that the order is still open
(neither Fulfilled nor Cancelled) and that the requested amount of tokens were successfully pulled from the solver. Finally, it transfers the
requested amount of tokens to the order's recipient address, OR — if the hook raw data is provided — to the `DlnExternalCallAdapter` hook engine smart
contract address (accessible via `DlnDestination.externalCallAdapter`), immediately invoking it for hook handling.
`DlnExternalCallAdapter` is responsible for proper hook raw data decoding, hook execution, and guaranties that hook behavior conforms given
properties.
# Hook data V1 layout
DlnExternalCallAdapter expects the hook raw data (called externalCallEnvelope) to be an concatenation of two encodePacked'd data types, specifically:
* first byte: `uint8 envelopeVersion`
* subsequent bytes: `bytes envelopeData`
The `envelopeVersion` determines which data structure was used to encode the `envelopeData`.
## Envelope v1
The `envelopeVersion=1` is currently the only available version, and its corresponding structure for the `envelopeData` is `HookDataV1` as follows:
```solidity theme={null}
struct HookDataV1 {
// Address that will receive order outcome if the hook gets reverted.
// Mandatory for optional-success hooks
address fallbackAddress;
// The address of a smart contract that acts as a hook target.
// Must implement the IExternalCallExecutor interface
address target;
// Optional reward to pay to a solver who executes the hook
// Reward is being cut off the order outcome.
// Reasonable (but not mandatory) for non-atomic hooks
uint160 reward;
// False: atomic hook
// True: non-atomic hook
bool isNonAtomic;
// False: optional-success hook
// True: success-required hooks
bool isSuccessRequired;
// Arbitrary data to be passed to the target during the call
bytes targetPayload;
}
```
HookDataV1.target defines a target smart contract address that would get called by the DlnExternalCallAdapter hook engine smart. The target smart
contract MUST implement the IExternalCallExecutor interface with only two functions: onEtherReceived() and onERC20Received() — that get called (along
with order details and the payload) right after the native or ERC-20 token got transferred to it:
```solidity theme={null}
interface IExternalCallExecutor {
/**
* @notice Handles the receipt of Ether to the contract, then validates and executes a function call.
* @dev Only callable by the adapter. This function decodes the payload to extract execution data.
* If the function specified in the callData is prohibited, or the recipient contract is zero,
* all Ether is transferred to the fallback address.
* Otherwise, it attempts to execute the function call. Any remaining Ether is then transferred to the fallback address.
* @param _orderId The ID of the order that triggered this function.
* @param _fallbackAddress The address to receive any unspent Ether.
* @param _payload The encoded data containing the execution data.
* @return callSucceeded A boolean indicating whether the call was successful.
* @return callResult The data returned from the call.
*/
function onEtherReceived(
bytes32 _orderId,
address _fallbackAddress,
bytes memory _payload
) external payable returns (bool callSucceeded, bytes memory callResult);
/**
* @notice Handles the receipt of ERC20 tokens, validates and executes a function call.
* @dev Only callable by the adapter. This function decodes the payload to extract execution data.
* If the function specified in the callData is prohibited, or the recipient contract is zero,
* all received tokens are transferred to the fallback address.
* Otherwise, it attempts to execute the function call. Any remaining tokens are then transferred to the fallback address.
* @param _orderId The ID of the order that triggered this function.
* @param _token The address of the ERC20 token that was transferred.
* @param _transferredAmount The amount of tokens transferred.
* @param _fallbackAddress The address to receive any unspent tokens.
* @param _payload The encoded data containing the execution data.
* @return callSucceeded A boolean indicating whether the call was successful.
* @return callResult The data returned from the call.
*/
function onERC20Received(
bytes32 _orderId,
address _token,
uint256 _transferredAmount,
address _fallbackAddress,
bytes memory _payload
) external returns (bool callSucceeded, bytes memory callResult);
}
```
For orders buying ERC-20 token, the DlnExternalCallAdapter first transfers the token's amount to the hook's target, then invokes its onERC20Received()
method:
```solidity theme={null}
IERC20(order.takeToken).safeTransfer(hook.target, order.takeAmount);
IExternalCallExecutor(hook).onERC20Received(..., hook.targetPayload);
```
For orders buying native blockchain currency (ether, etc), the DlnExternalCallAdapter invokes the hook's target.onEtherReceived() method along with
the amount of native currency as a msg.value:
```solidity theme={null}
IExternalCallExecutor(hook).onEtherReceived{ value: order.takeAmount }(..., hook.targetPayload);
```
# Universal Hook
One the common ways to build cross-chain interactions is to make calls to arbitrary existing contracts, without the need to introduce custom
intermediaries (smart contracts that act as hooks). To facilitate this need, we've build a default Universal Hook — a pre-deployed implementation of
the IExternalCallExecutor and a part of the DLN deployment — that can act as a hook's target and is designed to transparently execute arbitrary
transaction calls bypassed through its targetPayload.
To reuse this hook, HookDataV1's target must be set to address(0) (this would tell the DlnExternalCallAdapter hook engine to switch to the universal
hook as a default hook implementation), and HookDataV1's targetPayload must represent the following encoded data struct:
```solidity theme={null}
struct UniversalHookPayload {
address to;
uint32 txGas;
bytes callData;
}
```
When called, the universal hook would makes a CALL to the given to address using the given callData.
The transfer of native blockchain currency is performed during the call itself:
```solidity theme={null}
payload.to.call{ gas: payload.txGas, value: order.takeAmount }(payload.callData);
```
Mind that ERC-20 token transfer during transaction call made by the Universal hook behaves differently: the universal hook does not transfer the token
to the to address (like the DlnExternalCallAdapter does when calling a hook's target), but sets a temporary allowance instead before making a call,
and reverts it back after the call:
```solidity theme={null}
IERC20(order.takeToken).approve(payload.to, order.takeAmount);
// payload.to must pull the tokens from the caller, using the size of the
// allowance as a reference amount
payload.to.call{ gas: payload.txGas }(payload.callData);
IERC20(order.takeToken).approve(payload.to, 0);
// the remainder not consumed by the payload.to is transferred to the fallback address
```
If the payload.to had pulled less amount than the order's outcome, the remainder is transferred to the given fallback address automatically.
If the call to the payload.to target gets reverted, the execution bubbles up to the DlnExternalCallAdapter hook engine who handles this failure
according to the hook's properties (revert entire call if the hook is a success-required hook; gracefully ignore the failure if the hook is a
success-optional hook).
# Hook Data
Source: https://docs.debridge.com/dln-details/protocol-specs/hook-data
Structure and encoding of hook data attached to DLN orders.
Hooks are on-chain actions that can be optionally attached to an order upon its creation, and become the inseparable and cryptographically signed part
of it, and are executed on the destination chain upon order fulfillment. An action can perform actions of any complexity, including operations on the
outcome of the order.
Orders are identified by [deterministic order ID](/dln-details/protocol-specs/deterministic-order-id), and the hash of the hook's raw data is essentially a part of this ID (see the last two fields of the
deterministic order ID reference), so once a user signs-off an order with a hook, he eventually makes a cryptographic confirmation that he is willing
to sell input asset for output asset AND execute a specific action along with the output asset on the destination chain.
The proper execution of the hook during order fulfillment is guaranteed by [`DlnDestination`](/dln-details/overview/deployed-contracts) — the DLN smart contract responsible for filling orders,
which ensures that the given hook along with other properties of the order actually match the given order ID. This means that trying to spoof a hook
would lead to a different ID of a non-existent order, so the solver is compelled to pass a specific hook data, otherwise they would fill the
non-existent order and eventually lose given funds forever.
The raw data itself is not generalized, which allows the implementations of the `DlnDestination` smart contract for different blockchain engines impose
different and platform-specific requirements.
Further reading:
* [Anatomy of a Hook for the EVM-based chains](/dln-details/protocol-specs/evm-chains-hook-anatomy)
* [Anatomy of a Hook for Solana](/dln-details/protocol-specs/solana-hook-anatomy)
# Solana Hook Anatomy
Source: https://docs.debridge.com/dln-details/protocol-specs/solana-hook-anatomy
Solana hook transaction layout and instruction requirements.
The hook raw data intended for Solana is represented as a versioned transaction with one or more instructions. Thus, only *non-atomic success-required
hooks* are supported.
To craft a proper versioned transaction, use the guide: [Creating Hook data for
Solana](/dln-details/integration-guidelines/order-creation/hooks/solana-hook-data)
# Custom Linking
Source: https://docs.debridge.com/dln-details/widget/app
Create custom no-code deBridge app links with preset swap parameters and referral codes.
The deBridge web application enables users to create custom links with a pre-defined set of parameters using URL query parameters. Users and
developers can use their own prefilled settings for deSwap or dePort.
| **Parameter** | **Description** |
| ---------------- | -------------------------------------------------------------------------------------- |
| `inputChain` | ID of the chain where deSwap is initiated. |
| `inputCurrency` | Token contract address of the input currency that will be swapped for output currency. |
| `outputChain` | ID of the destination chain. |
| `outputCurrency` | Token contract address of the output currency that input currency will be swapped for. |
| `r` | Your generated referral code. |
| `address` | Recipient address. |
| `amount` | Token amount to swap. |
# Example
```
https://app.debridge.com/deswap?inputChain=&inputCurrency=&outputChain=&outputCurrency=&r=&address=&amount=
```
## deSwap
BSC(USDC) - ETHEREUM (USDT)
```
https://app.debridge.com/deswap?inputChain=56&inputCurrency=0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d&outputChain=1&outputCurrency=0xdac17f958d2ee523a2206206994597c13d831ec7&r=111&address=0x0000000000000000000000000000000000000000
```
## dePort
BSC(USDC) - deUsdc
```
https://app.debridge.com/deport?inputChain=56&inputCurrency=0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d&r=111
```
# Chains and Tokens ID
The Chain IDs of all chains can be found at [https://chainlist.org/](https://chainlist.org/) or in the spreadsheet below:
| **ID** | **Chain** | **Token Request** |
| ------- | ------------------- | ---------------------------------------- |
| `1` | Ethereum | `GET https://tokens.1inch.io/v1.1/1` |
| `56` | Binance Smart Chain | `GET https://tokens.1inch.io/v1.1/56` |
| `128` | Heco | `GET https://tokens.1inch.io/v1.1/128` |
| `137` | Polygon | `GET https://tokens.1inch.io/v1.1/137` |
| `42161` | Arbitrum | `GET https://tokens.1inch.io/v1.1/42161` |
| `43114` | Avalanche | `GET https://tokens.1inch.io/v1.1/43114` |
| `250` | Fantom | `GET https://tokens.1inch.io/v1.1/250` |
# deBridge Widget
Source: https://docs.debridge.com/dln-details/widget/deBridge-widget
deBridge Widget - a customizable, drop-in UI component for cross-chain swaps. Learn about its features, integration steps, and event handling.
With just a few lines of code, all projects and developers can embed a cross-chain exchange between arbitrary assets within your app (mobile app,
website, dApp, etc.) based on the deBridge protocol. You can make the deBridge widget part of your app and you're fully free to customize colors,
fonts, chains, and tokens according to your design and preferences.
![Widget Image]()
# Requirements
The widget is based on web technology, that's why your app must support technology such as JavaScript, HTML, CSS or use webView to add the widget.
You can use any type of framework for the web app. The launch of the widget is going on through iframe embedded on the page. The API integration is
based on JavaScript.
# Widget embedding
The following steps are needed to add the widget:
* Connect js script to your app
```html theme={null}
```
* Add an html element with a unique id
* Generate js object with the description of the widget settings. You can use the [builder](https://app.debridge.com/widget) of deSwap Widget for
auto-generation js object.
* Initialize `deBridge.widget(initObject)`, where `initObject` contains the settings.
Initializing must be executed after connection from step 1.
# Widget object settings description
| **Parameter** | **Type** | **Description** |
| ---------------- | -------- | ------------------------------------------------------------------------------------------ |
| `element` | `string` | **(mandatory)** – Unique ID of the HTML element on the page |
| `v` | `string` | Widget version (possible value: `'1'`) |
| `mode` | `string` | Type of project (possible value: `'deswap'`) |
| `title` | `string` | Widget header |
| `width` | `number` | Width of the widget |
| `height` | `number` | Height of the widget |
| `inputChain` | `number` | ID of the input chain (possible values: `1`, `56`, `137`, `42161`, `43114`) |
| `outputChain` | `number` | ID of the output chain (same values as above) |
| `inputCurrency` | `string` | Address of the input token |
| `outputCurrency` | `string` | Address of the output token |
| `address` | `string` | Address of the receiver |
| `amount` | `string` | Amount to exchange |
| `lang` | `string` | Default language (possible values: `'en'`, `'fr'`, `'jp'`, `'ko'`, `'ru'`, `'vi'`, `'zh'`) |
| `styles` | `string` | Base64-encoded styles object |
| `theme` | `string` | Theme mode (possible values: `'dark'`, `'light'`) |
| `r` | `string` | Integrator referral code |
```json theme={null}
{
"element": "debridgeWidget",
"v": "1",
"mode": "deswap",
"title": "deSwap",
"width": "600",
"height": "800",
"inputChain": "56",
"outputChain": "1",
"inputCurrency": "0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d",
"outputCurrency": "0xdac17f958d2ee523a2206206994597c13d831ec7",
"address": "0x64023dEcf09f20bA403305F5A2946b5b33d1933B",
"amount": "10",
"lang": "en",
"mode": "deswap",
"styles": "eyJmb250RmFtaWx5IjoiQWJlbCJ9",
"theme": "dark",
"r": "3981"
}
```
## Styles
The styles field contains the fields:
```typescript theme={null}
{
appBackground: string,
appAccentBg: string,
chartBg:string,
primary: string,
secondary: string,
badge: string,
borderColor: string,
borderRadius: number,
fontColor:string,
fontColorAccent:string,
fontFamily: string
}
```
![Widget Styles]()
```html theme={null}
Widget Example
```
# deBridge Widget events and methods
## Widget Initialization
The widget is initialized asynchronously using:
```typescript theme={null}
const widget = await deBridge.widget(params);
```
## Events
The widget object supports several event listeners that respond to specific actions. Each event can be registered using:
```typescript theme={null}
widget.on('eventName', (event, params) => {
// Handle event logic here
});
```
### Available Events
### `needConnect`
* Triggered when the widget requires a connection.
* Example handler:
```ts theme={null}
widget.on('needConnect', (widget) => {
console.log('needConnect event', widget);
});
```
### `order`
* Triggered when an order is created.
* Parameters:
* `params.status`: Order status.
* Example handler:
```ts theme={null}
widget.on('order', (widget, params) => {
console.log('order params', params);
});
```
### `singleChainSwap`
* Triggered when a single-chain swap occurs.
* Example handler:
```ts theme={null}
widget.on('singleChainSwap', (widget, params) => {
console.log('singleChainSwap params', params);
});
```
### `bridge`
* Triggered when a deport transaction occurs.
* Parameters:
* `params.status`: Bridge status.
* Example handler:
```ts theme={null}
widget.on('bridge', (widget, params) => {
console.log('deport event', widget, params);
});
```
### `callData`
* Triggered when call data for an order is required.
* Example handler:
```ts theme={null}
widget.on('callData', (widget, params) => {
if (
params.createOrderParams.takeChainId == 137 &&
params.createOrderParams.takeTokenAddress == "0x2791..."
) {
return { to: "0x...", data: "0x..." };
}
return null;
});
```
### `inputChainChanged`
* Triggered when the input chain is changed.
* Example handler:
```ts theme={null}
widget.on('inputChainChanged', (widget, params) => {
console.log('inputChainChanged event', widget, params);
});
```
### `outputChainChanged`
* Triggered when the output chain is changed.
* Example handler:
```ts theme={null}
widget.on('outputChainChanged', (widget, params) => {
console.log('outputChainChanged event', widget, params);
});
```
### `inputTokenChanged`
* Triggered when the input token is changed.
* Example handler:
```ts theme={null}
widget.on('inputTokenChanged', (widget, params) => {
console.log('inputTokenChanged event', widget, params);
});
```
### `outputTokenChanged`
* Triggered when the output token is changed.
* Example handler:
```ts theme={null}
widget.on('outputTokenChanged', (widget, params) => {
console.log('outputTokenChanged event', widget, params);
});
```
## Methods
The widget object provides several methods to programmatically interact with it.
### `disconnect()`
Disconnects the connected wallet in the widget.
* Example usage:
```ts theme={null}
widget.disconnect();
```
### `changeInputChain(chainId)`
Changes the input chain to the specified `chainId`.
* Example usage:
```ts theme={null}
widget.changeInputChain(1);
```
### `changeOutputChain(chainId)`
Changes the output chain to the specified `chainId`.
* Example usage:
```ts theme={null}
widget.changeOutputChain(10);
```
### `changeInputToken(tokenAddress)`
Changes the input token using the given token address.
* Example usage:
```ts theme={null}
widget.changeInputToken('0x...');
```
### `changeOutputToken(tokenAddress)`
Changes the output token using the given token address.
* Example usage:
```ts theme={null}
widget.changeOutputToken('0x...');
```
### `setExternalEVMWallet(walletConfig)`
Connects an external EVM-compatible wallet.
* Example usage:
```ts theme={null}
widget.setExternalEVMWallet({
provider: window.phantom?.ethereum,
name: "Metamask",
imageSrc: 'https://app.debridge.com/assets/images/dln-details/wallet/metamask.svg'
});
```
### `setExternalSolanaWallet(walletConfig)`
Connects an external Solana-compatible wallet.
* Example usage:
```ts theme={null}
widget.setExternalSolanaWallet({
provider: window.solana,
name: "Phantom",
imageSrc: 'https://app.debridge.com/assets/images/dln-details/wallet/phenom.svg'
});
```
### `setReceiverAddress(address)`
Sets the receiver's wallet address.
* Example usage:
```ts theme={null}
widget.setReceiverAddress('0x...');
```
### `setAffiliateFee(feeConfig)`
Sets the affiliate fee for Solana and EVM networks.
* Example usage:
```ts theme={null}
widget.setAffiliateFee({
solana: {
affiliateFeePercent: '0.5',
affiliateFeeRecipient: 'B5...',
},
evm: {
affiliateFeePercent: '1',
affiliateFeeRecipient: '0x...',
}
});
```
# deBridge Widget builder
The builder is available at [https://app.debridge.com/widget](https://app.debridge.com/widget) and contains:
* Widget settings fields
* Widget preview
* Field with source code for embedding in the application
# Work Algorithm
* Fill in the fields of widget settings to see your future widget. All field changes are updated in real time.
* Once UI and other settings suit your requirements, you can just copy the source code to your project to embed the widget according to the "Widget
embedding" section.
# Getting Started
Source: https://docs.debridge.com/dmp-details/dePort/getting-started
Getting started with dePort – a native bridge for assets that allows protocols to bridge tokens and create utility for their synthetic representation on other chains.
![dePort]()
[dePort](https://app.debridge.com/deport) is a native bridge for assets that allows protocols to bridge tokens and create utility
for their synthetic representation (deTokens) on other chains.
dePort utilizes a lock-and-mint approach where the native token is locked/unlocked in a deBridgeGate smart contract on the native
(source) chain and its synthetic representation (deAsset) is minted/burnt in secondary (target) chains.
For each asset, under the native chain, we assume the unique blockchain where the token was originally created.
Secondary chains are blockchains supported by deBridge to which tokens can be transferred/bridged and where deAssets are minted.
# Collateralization
Each of the tokens locked in the native chain have the associated wrapped asset on the target chains. By design, the protocol
ensures that the total supply of each deAsset that can be minted on secondary chains is always 1:1 backed by the asset collateral
locked in the deBridgeGate smart contract on the native chain. That provides more secure and reliable user experience and
guarantees that the user will not face a liquidity imbalance problem which has been encountered in other bridging solutions, where
users face significant delays after they already locked liquidity in a bridge.
# Listing at deBridge
The deBridge protocol is universal and there are no listing requirements. Any arbitrary token can be bridged. If the token is
bridged for the first time, together with the validation transaction validators sign a unique deployId that is passed to the
destination chain and contains the following parameters:
* Native token smart contract address
* Native chain Id
* Token name
* Token symbol
* Decimals
The wrapped (deAsset) is deployed on the target chain automatically together with the first claim of the wrapped asset. Thus, no
additional actions are required from the user, listing is performed automatically by deBridge validators who sign a unique
deployment ID. At deBridge, we care about user experience and strive to minimize unnecessary actions to be performed by protocol
users.
# Transfer Flow
Source: https://docs.debridge.com/dmp-details/dePort/transfer-flow
dePort Transfer Flow: Transfers From Native (Source) Chain and Cross-Chain Transfers Execution Time.
![DePort Transfers Flow]()
# 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:
```solidity theme={null}
_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:
* The finality of the transaction on the blockchain where the transfer is originated
* 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.
# Cross-Chain Call Lifecycle
Source: https://docs.debridge.com/dmp-details/dev-guides/cross-chain-call-lifecycle
Lifecycle of a cross-chain call from submission to claim.
Blockchains by their nature are siloed environments that cannot directly communicate with each other. That is why any messaging protocol is a complex
set of components, making any cross-chain transaction a multistage process, so just initiating a cross-chain transaction typically is not enough. It
is important to understand how the deBridge infrastructure works so you can manage your submissions (either manually or even automatically)
consciously and confidently.
The following scheme visualizes a normal cycle of a typical cross-chain call, as it may look for the [conceptual cross-chain
dApp](https://github.com/debridge-finance/debridge-cross-chain-dapp-example) where Incrementor is used as an example of the smart contract that sends
a cross-chain message:
![Cross-chain Call Lifecycle]()
When a call to the `deBridgeGate.send()` method is made on the origin (source) chain, the gate contract validates the input (its args and the
`autoParams` struct), and if everything is correct (the data is unambiguous, the input asset covers the fees, etc), a special `Sent` event is emitted.
This event exposes the following details of the submission:
* `submissionId`, the identifier of the cross-chain transaction you've initiated;
* `debridgeId`, the cross-chain identifier of the input asset, needed to correctly handle tokens across supported chains;
* `args` and the `autoParams` structure that contains information about the passed message.
You are advised to monitor this event to ensure your submission has been accepted and the cross-chain transaction has been initiated.
[deBridge validators](https://app.debridge.com/validation-progress) listen for these events emitted by the deBridgeGate smart contract deployed on
all supported chains, and for each tracked event validator performs the following set of actions:
* waits a specific amount of block confirmations (12 block confirmations for supported EVM chains, and 256 block confirmations for the Polygon
network) to ensure the finality of the transaction where the event has been emitted,
* validates the args and the structure,
* if the data is correct, sign the message with its own private key, and publish the signature to Arweave.
Note: Validators' financial responsibility to be enabled through [Slashing and Delegated Staking](/dmp-details/dmp/slashing-and-delegated-staking).
After the minimum required number of validators have signed the message (eight at the time of writing, ⅔ of all possible signatures), the submission
is confirmed and may be claimed on the destination chain.
You can access the actual minimum required number of signatures by querying the `minConfirmations` property of the `signatureVerifier` contract:
```solidity theme={null}
ISignatureVerifier(IDebridgeGate(deBridgeGate).signatureVerifier).minConfirmations
```
To claim the submission, a claiming transaction should be crafted, signed, and sent to the blockchain. Such transaction must contain a call to the
`claim()` method of the `deBridgeGate` contract with the submission's data (taken from the `Sent` event) and minimal required number of validators'
signatures provided as its args.
Worth mentioning that such transactions may be signed and sent by anyone who is willing to pay the gas for its' execution on the destination chain.
There is no security implication because during the claiming phase the `deBridgeGate` contract first checks the integrity of the message (the args and
the `autoParams` struct that was initially passed to the `send()` method on the origin chain) by verifying each validator's signature against their public
key, and then executing the instructions this message contains.
There are three ways to trigger a claiming transaction:
* manually, by visiting [deExplorer](https://explorer.debridge.com/), where you can find your cross-chain transaction by its `submissionId` or even
by the hash of the origin transaction, then sign the prepared claiming transaction using the browser wallet (MetaMask, etc);
![Claim Details]()
* automatically, by specifying sufficient `executionFee` property within your submission: in this case, Claimers will execute the transaction and
deliver the message in case the supplied on the source chain `executionFee` (included gas) covers their gas on the destination chain.
Claimer may wait to deliver the message (submission) in case of gas price spikes (if the value of the included gas becomes less than the cost of
execution). In this case, you should trigger a claiming txn on your own, either manually or programmatically, and you'll receive back the supplied
included gas (instead of the Claimer service);
* programmatically, by constructing a claiming txn with a little help of [deSDK](https://github.com/debridge-finance/desdk) (this is what Claimer
service actually does automatically).
After the claiming txn is sent and included in the blockchain, and the `deBridgeGate.claim()` call succeeds, a special `Claimed` event is emitted by the
`deBridgeGate` contract signaling the successful completion of the cross-chain transaction. Voila!
# Development Tools
Source: https://docs.debridge.com/dmp-details/dev-guides/development-tools
Developer tools and resources for building with deBridge on top of deBridge Messaging Protocol.
Explore our [deBridge Developer Portal](https://debridge.finance/develop) to get started building secure and efficient cross-chain applications.
Development tools
* DLN API: is a high-performance cross-chain trading infrastructure built with deBridge with a unique 0-TVL design (no risks of locked liquidity).
* [deBridge widget](https://app.debridge.com/widget): offer seamless and secure bridging and cross-chain value transfers in any application with
our customizable widget.
* [debridge-hardhat](https://github.com/debridge-finance/hardhat-debridge) is a plugin for Hardhat that provides the toolkit for creating a
lightweight and blazing-fast emulation environment, behaving close to how the mainnet setup of the deBridge infrastructure does.
* [deSDK](https://github.com/debridge-finance/desdk) is a library to send, track, and claim submissions programmatically.
* [Solana transaction parser](https://github.com/debridge-finance/solana-tx-parser-public) is a powerful tool developed by the deBridge team to parse
Solana transactions and analyze them in a human-readable format.
# Building EVM Dapp
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/building-evm-dapp
Building an EVM dApp with deBridge: Cross-chain Counter and Incrementor contracts, crafting submissions, and understanding send() args.
deBridge is DeFi's internet of liquidity, enabling any amount of cross-chain interactions (bridging, value transfers, ext calls, etc) in a single
transaction. Due to the ability to simultaneously send messages and value deBridge acts as a unified framework for all cross-chain needs and is
capable of interconnecting any smart contract on any supported blockchain.
![Cross-Chain Message Diagram]()
This guide is a great starting point that covers all necessary topics to get you started building cross-chain interactions on top of the deBridge
protocol and its' infrastructure.
# Build your first deApp
Let's consider the following idea of the conceptual dApp consisting of two smart contacts: a `Counter` smart contract residing in one chain, where the
integer property (`counter`) is stored and can be incremented by a call initiated by and only by the `Incrementor` contract from another chain. In other
words, when we perform some action against the `Incrementor` contract, it initiates a cross-chain transaction (a submission, in terms of the deBridge
protocol) which is being started on one chain, relayed to, and then executed on another chain; during this cross-chain transaction, a `Counter` contract
is called. The following image presents a high-level overview of a cross-chain transaction we are going to achieve:
![Dapp Diagram]()
This document will guide you through building contracts, scripts and unit tests necessary to make this project happen. A self-contained source code of
this dApp can be found on [Github](https://github.com/debridge-finance/debridge-cross-chain-dapp-example)
Though hypothetical, this example may be used as a foundation for real-life cases, e.g. you may want to track the supply of your token issued across
multiple chains on one chain, or send price feeds and trigger events or even actions to buy or sell, etc.
# Making the Counter contract
Let's start with making the counter contract, responsible for keeping the integer property and accepting calls to increment it. Obviously, there
should be a property and a method:
```solidity theme={null}
contract CrossChainCounter {
uint256 public counter;
function receiveIncrementCommand(uint8 _amount) external {
counter = counter + _amount;
}
}
```
Looks simple! However, we need to put some security restrictions on this method: first, we must ensure it can be called by the `deBridgeGate` smart
contract only, and second, this call should occur only during the cross-chain transaction originating from the `Incrementor` smart contract at the
specific address on another chain. How can this be achieved?
The cross-chain transaction is a message from the origin chain with a payload that includes (among other info) the packed address of the initiator
(`nativeSender`) - i.e. an entity that actually initiated the transaction by calling the `deBridgeGate` contract on the origin chain. When the cross-chain
transaction is being relayed, the `deBridgeGate` contract on the destination chain temporarily exposes the state of the transaction it currently handles
via its properties and then calls a target smart contract (whose address is also a part of a payload) through its helper intermediary. It means that
the contract on the target address may access this data.
To make this happen, the `Counter` must know the `deBridgeGate` contract's address on the current chain, so it is reasonable to inject it via a constructor:
```solidity theme={null}
contract CrossChainCounter {
IDebridgeGate public deBridgeGate;
constructor(address deBridgeGate_) {
deBridgeGate = IDebridgeGate(deBridgeGate_);
}
}
```
Then, we can start putting restrictions on the `receiveIncrementCommand` method using a modifier. The first obvious check we must perform is to ensure
this method is called by the `deBridgeGate`'s helper intermediary - a `CallProxy` contract responsible for performing actual calls (the `deBridgeGate`
contract doesn't make calls directly for security considerations):
```solidity theme={null}
contract CrossChainCounter {
modifier onlyCrossChainIncrementor {
// caller must be CallProxy
require(msg.sender == deBridgeGate.callProxy())
// execute the rest
_;
}
}
```
It is implied by the protocol that such calls may occur only while `deBridgeGate` handles some cross-chain transactions relayed from another chain.
The not-so-obvious second check is related to our business logic: we want to ensure that a transaction is originating from the chain we know and from
the contract we trust. To make such validation happen, we must preliminarily store the trusted address in the `Counter` contract, for example like this:
```solidity theme={null}
contract CrossChainCounter {
uint256 trustedChain;
bytes trustedCrossChainCaller;
function addChainSupport(
uint256 _trustedChain,
address _trustedIncrementor
) external onlyAdmin {
trustedChain = _trustedChain;
trustedCrossChainCaller = abi.encodePacked(_trustedIncrementor);
}
}
```
Note that we store the packed version of the caller's address (mind that `trustedCrossChainCaller` is defined as bytes rather than the address): this
happens because the `deBridgeGate` smart contract stores the byte representation of the native sender address to ensure future compatibility with
non-EVM chains (e.g. Solana).
Later, after you deploy the `Incrementor` contract and get its address, we may let the `Counter` contract know about it by calling the `addChainSupport`
method.
As soon as the `Counter` contract starts storing the caller's address, the cross-chain transaction is allowed to originate from, we may reuse this data
and add the additional validation logic to the modifier:
```solidity theme={null}
contract CrossChainCounter {
modifier onlyCrossChainIncrementor {
// take the callProxy instance
ICallProxy callProxy = ICallProxy(deBridgeGate.callProxy());
// caller must be CallProxy
require(address(callProxy) == msg.sender);
// origin chain must be known
require(callProxy.submissionChainIdFrom() == trustedChain);
// native sender (initiator of the txn on the origin chain) must be trusted
// Bytes can't be compared directly, so take the hashes of them
require(
keccak256(callProxy.submissionNativeSender())
== keccak256(trustedCrossChainCaller)
);
// execute the rest
_;
}
}
```
That's it! Now if we apply the given modifier to the target `receiveIncrementCommand` method, it becomes properly protected from unauthorized calls and
ready to receive commands from the trusted contract on another chain:
```solidity theme={null}
contract CrossChainCounter {
function receiveIncrementCommand(uint8 _amount)
external
onlyCrossChainIncrementor // <-- mind the modifier applied
{
counter = counter + _amount;
}
}
```
# Making the `Incrementor` contract
Now after we have the `Counter` contract and know its interface, we may design the `Incrementor` contract, which is responsible for initiating the
cross-chain call to `Counter`'s `receiveIncrementCommand()`. First things first, we must let the `Incrementor` know where the `Counter` contract actually
resides, so we inject it with the chain ID and address of the `Counter` contract, and we also specify the address of the deBridgeGate contract as well:
```solidity theme={null}
contract CrossChainIncrementor {
IDebridgeGate deBridgeGate;
uint256 counterResidenceChainID;
address counterResidenceAddress;
constructor(
address deBridgeGate_,
uint256 counterResidenceChainID_,
address counterResidenceAddress_
) {
deBridgeGate = IDebridgeGate(deBridgeGate_);
counterResidenceChainID = counterResidenceChainID_
counterResidenceAddress = counterResidenceAddress_;
}
}
```
For the sake of simplicity, let's assume that anyone may invoke the Incrementor, so let its interface be as simple as follows:
```solidity theme={null}
contract Incrementor {
function increment(uint8 _amount) external payable {
deBridgeGate.send{value: msg.value}(/* ... */)
}
}
```
Crafting the deBridge submission (a cross-chain transaction) spins around the `deBridgeGate`'s `send()` method — the only entry point to initiate a
transaction. It accepts plenty of non-trivial variables and structs. Let's overview all of them to make our submission happen.
## A protocol fee
Worth mentioning that the `send()` method is marked as `payable` (meaning that it accepts ether during a call) and it is necessary to bypass enough
ether to cover the protocol fee (or global fixed native fee, according to the internal definition) taken in the native currency of the chain. How
much? The fee varies from chain to chain: for example, at the time of writing the fee on Ethereum is 0.001 ETH and the fee on Polygon is 0.5 MATIC.
Since fees can be changed by deBridge governance and are expected to be reduced as protocol scales, you are advised to retrieve the actual fee amount
by reading `deBridgeGate`'s `globalFixedNativeFee` property either on-chain:
```solidity theme={null}
uint protocolFee = deBridgeGate.globalFixedNativeFee;
```
or by making a call to the RPC node:
```solidity theme={null}
// ethers.js
const protocolFee = await deBridgeGate.globalFixedNativeFee();
// or web3.js
const protocolFee = await deBridgeGate.methods.globalFixedNativeFee().call();
```
Then pass the retrieved amount of ether to the call:
```solidity theme={null}
deBridgeGate.send{value: protocolFee}(/* ... */);
```
## Submission params
The gate accepts a variety of parameters through the `SubmissionAutoParamsTo` struct ([see its
definition](https://github.com/debridge-finance/debridge-contracts-v1/blob/main/contracts/interfaces/IDeBridgeGate.sol#L41)), so it is important to
understand each.
`executionFee` (or included gas) is the amount of the bridged asset that will be transferred to anyone who will deliver the message in the destination
chain. In other words, this is a prepayment for potential gas expenses on the target chain, that will be transferred by the protocol to the address
that claims the message. Anyone can run the keeper service to deliver messages and earn the executionFee. This is an advanced topic that runs out of
the scope of this document, so for the sake of simplicity just set this value to zero.
`flags` is a bitmask of [toggles](https://github.com/debridge-finance/debridge-contracts-v1/blob/main/contracts/libraries/Flags.sol) affecting the
behavior of the gate. The following flags are important to be set in our case:
* `REVERT_IF_EXTERNAL_FAIL` tells the `CallProxy` to revert the whole claim transaction in case the call to the receiver address (the callee contract on
the destination chain; it is the `Counter` contract in our case) fails. Select the proper behavior wisely, ensuring it is aligned with the design of
the callee contract: for example, the contract may fail deliberately and irretrievably so it may be reasonable to handle this call gracefully and
mark the whole cross-chain transaction as succeeded. Keep in mind that once the claim transaction succeeds it `submissionId` is marked as used, so you
cannot replay the transaction on the destination chain.
* `PROXY_WITH_SENDER` tells the `CallProxy` to expose the address that initiated the cross-chain transaction (submission) on the origin chain. Again,
choose wisely: as for our case, the `Counter` contract expects this data, so we need to ensure it's presented on the destination chain.
A complete list of flags with their description can be found on [EVM smart contract interfaces page](/dmp-details/dev-guides/evm/libraries/flags).
`fallbackAddress` is the address on the destination chain where the bridged funds will be transferred to in case the call to the receiver address fails
**and** `REVERT_IF_EXTERNAL_FAIL` is not set. Since we don't bridge any funds (only the calldata), this field is not very important though it is mandatory
to set it. Mind that this address must be packed into bytes.
`data` is the field for the `calldata` to execute on the destination chain. Not a big deal if the contracts reside on different chains: we can encode the
call using the interface of the contract to call. In our case, we can import the interface of the `Counter` (`ICrossChainCounter`) and use it with the
`encodeWithSelector` to produce valid instructions aligned with the interface of `Counter`'s `receiveIncrementCommand` method:
```solidity theme={null}
bytes memory counterCalldata = abi.encodeWithSelector(
ICrossChainCounter.receiveIncrementCommand.selector,
_amountToIncrementBy
);
```
Summing it up, here is the complete snippet that produces an `autoParams` struct with settings that suit our needs:
```solidity theme={null}
IDeBridgeGate.SubmissionAutoParamsTo memory autoParams;
autoParams.executionFee = _executionFee;
// Exposing nativeSender must be requested explicitly
// We request it bc of CrossChainCounter's onlyCrossChainIncrementor modifier
autoParams.flags = Flags.setFlag(
autoParams.flags,
Flags.PROXY_WITH_SENDER,
true
);
// If something happens, we need to revert the transaction to avoid this call being lost
autoParams.flags = Flags.setFlag(
autoParams.flags,
Flags.REVERT_IF_EXTERNAL_FAIL,
true
);
autoParams.data = abi.encodeWithSelector(
ICrossChainCounter.receiveIncrementCommand.selector,
_amountToIncrementBy
);
autoParams.fallbackAddress = abi.encodePacked(msg.sender);
```
Of course, you can craft the `autoParams` struct either on-chain (as in the example above) or off-chain using ethers.js or web3.js.
## The `send()` args
The last major step towards successful submission is the understanding of args of the send() method.
* `_tokenAddress` is the address of the ERC-20 token contract whose tokens you are willing to bridge additionally along with the `calldata`. If you are
willing to bridge the native currency (e.g. ETH from Ethereum), use the zero address (`address(0)`).
* `_amount` is the amount of tokens (of the contract specified in the first arg) you are willing to bridge. Dealing with bridged assets is an advanced
topic which out of the scope of this document, so in this example, it is enough to set this arg to zero. The following things are worth mentioning:
first, the gate cuts a small 0.1% fee off the bridged asset; second, if you bridge the native currency of the origin blockchain, you must not forget
to supply an additional amount to cover the protocol fee, but not include it in this arg value; third, the aforementioned `executionFee` (included
gas) is counted in the currency of this bridged asset, so its decimals must be in sync with this asset; fourth, ERC-20 tokens should not be
transferred in/out explicitly, use allowance and `safeTransferFrom` instead.
* `_chainIdTo` sets the destination chain ID. Consider looking at chainlist.org for known chain IDs, see the list of supported chains in our docs, or
query `deBridgeGate.getChainToConfig` on-chain property for programmatic access to the list of chains supported by deBridge.
* `_receiver` defines the address on the destination chain to receive bridged assets (if any) and be called by the `CallProxy` contract in case the call
data is given. In the given example, we must set this arg to the address of the `Counter` smart contract.
* `_permit` allows the caller to specify EIP-2612-compliant signed approval for the `deBridgeGate` contract to transfer the tokens specified in the
first arg. Not applicable here.
* `_useAssetFee` allows paying the protocol fee in the currency of the asset being bridged rather than the native currency of the blockchain. Not
applicable here.
* `_referralCode` is used to mark the submission with your own code, which will be used later.
* `_autoParams` is the encoded `autoParams` struct we've crafted in the previous chapter.
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 WAGMI button at [https://app.debridge.com/](https://app.debridge.com/). Governance may thank you later for being an early
builder.
The list of args is enormously long due to the internal complexity and the wide range of features deBridge protocol provides, but, however, there are
only three args you must care about right now: `_chainIdTo`, `_receiver` and `_autoParams`. The snippet that actually makes a call to the `deBridgeGate`
contract may look like this:
```solidity theme={null}
deBridgeGate.send{value: _protocolFee}(
address(0), // _tokenAddress, N/A
0, // _amount, N/A
counterResidenceChainID, // _chainIdTo
abi.encodePacked(counterResidenceAddress), // _receiver
"", // _permit, N/A
true, // _useAssetFee, N/A
0, // _referralCode, N/A
abi.encode(autoParams) // _autoParams
);
```
Of course, this call may be crafted on-chain in your own contract or off-chain. After this call to `deBridgeGate` is made within a blockchain, the
cross-chain transaction is being initiated.
## Accompanying and finishing a submission
Consider reading the [Lifecycle of a cross-chain](/dmp-details/dev-guides/cross-chain-call-lifecycle) call to get yourself familiar with how the cross-chain calls
are handled.
After our smart contract (`Incrementor` in our case) submits a new cross-chain call, the `deBridgeGate` contract emits a `Sent` event containing all
necessary details about the cross-chain call, including the `submissionId` — the global cross-chain identifier of such a call. The `submissionId` is
the important thing to identify our submission, so we must capture it either by parsing the event manually or using [deBridge SDK
(deSDK)](https://github.com/debridge-finance/desdk) which does [this action](https://github.com/debridge-finance/desdk#tracking-submissions) for us:
```solidity theme={null}
// find all submissions submitted in your transaction by its hash
// Obviously, a single transaction may contain multiple submissions:
// a contract may call deBridgeGate.send() multiple times, e.g. to submit data
// to different chains simultaneously - that's why Submission.findAll()
// returns an array of Submission objects
const submissions = await evm.Submission.findAll(transactionHash, context);
// take the first submission.
// DO YOUR OWN SANITY CHECKS TO ENSURE IT CONTAINS THE EXPECTED NUMBER OF SUBMISSIONS
const [submission] = submissions;
```
## Checking the status of the submission
The submission gets accepted by the validators after a transaction (containing the cross-chain call has been submitted) receives 12 block
confirmations (256 for the Polygon chain). This is a required transaction finality validators are waiting for to avoid the consequences of the network
divergence. You can monitor the finality of the transaction in a few ways: either using the preferred library (web3.js, ethers.js, or whatever) or
with a [little help of deSDK](https://github.com/debridge-finance/desdk#tracking-submissions):
```solidity theme={null}
// check if submission if confirmed: validator nodes wait a specific block
// confirmations before sign the message. Currently, 12 blocks is expected
// for most supported EVM chains (256 for Polygon).
const isConfirmed = await submission.hasRequiredBlockConfirmations();
```
The number of block confirmations required for sent messages can be found in Fees and Supported Chains section
## Pulling signatures
After the origin transaction receives enough block confirmations, we may start pulling the signatures. Currently, signatures are available through the
deBridge API: you can query them manually by calling the API directly, or use deSDK which additionally checks if enough signatures have been published
already:
```ts theme={null}
if (isConfirmed) {
const claim = await submission.toEVMClaim(evmDestinationContext);
// check if claim has been signed by enough validators
await isSigned = await claim.isSigned();
}
```
## Crafting transactions to claiming a submission
After the submission has been confirmed and signed by enough validators, it's time to craft a claiming transaction that will land down the submission
and execute the message on the destination chain.
To claim a submission, a call to the `deBridgeGate.claim()` method on the destination chain must be crafted using the data from taken from various
sources, which isn't an easy task, so there is deSDK which [takes the burden of data
preparation](https://github.com/debridge-finance/desdk#tracking-and-executing-claims):
```ts theme={null}
// the resulting tuple of args to be then passed to the deBridgeGate.claim() method
const claimArgs = await claim.getEncodedArgs();
// e.g. using ethers.js:
// await deBridgeGate.claim(...claimArgs, { gasLimit: 8_000_000 });
```
Then you can pass the args to the `deBridgeGate.claim()` method, and finally sign and broadcast your transaction and wait for the `Claimed` event. This
will indicate a successful submission completion.
Keep in mind that estimating gas for such transaction may have undesirable pitfalls that we have covered in our small research - this may be the case
if you turn off the `REVERT_IF_EXTERNAL_FAIL` flag. We recommend using professional transaction simulation services (offered by Tenderly or Blocknative)
rather than calling your RPC's `eth_estimateGas` endpoint.
# Further reading
* Consider using the [debridge-hardhat](https://github.com/debridge-finance/hardhat-debridge) plugin for Hardhat to test your contracts on the
emulated environment
* Find the [source code](https://github.com/debridge-finance/debridge-cross-chain-dapp-example) of the example project examined in this document,
along with tests and helper commands.
* Start using [deSDK](https://github.com/debridge-finance/desdk) to send, track and claim submissions programmatically
* Watch the walkthrough video on how to use deBridge emulator for your development environment:
debridge protocol advanced topics:
* [Gathering data for the claim](/dmp-details/dev-guides/gathering-data-for-claim)
* deBridge protocol flags explained (coming soon)
* Transaction bundling explained (coming soon)
* Execution fee explained (coming soon)
* Bridging arbitrary assets explained (coming soon)
# ICallProxy
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/interfaces/ICallProxy
ICallProxy interface details - functions.
## Functions
### submissionChainIdFrom
```solidity theme={null}
function submissionChainIdFrom() external returns (uint256)
```
Chain from which the current submission is received.
### submissionNativeSender
```solidity theme={null}
function submissionNativeSender() external returns (bytes)
```
Native sender of the current submission.
### call
```solidity theme={null}
function call(
address _reserveAddress,
address _receiver,
bytes _data,
uint256 _flags,
bytes _nativeSender,
uint256 _chainIdFrom
) external returns (bool)
```
Used for calls where native asset transfer is involved.
**Parameters:**
| Name | Type | Description |
| ----------------- | --------- | ------------------------------------- |
| `_reserveAddress` | `address` | Receiver if call to `_receiver` fails |
| `_receiver` | `address` | Contract to be called |
| `_data` | `bytes` | Call data |
| `_flags` | `uint256` | Behavior flags (see Flags library) |
| `_nativeSender` | `bytes` | Native sender |
| `_chainIdFrom` | `uint256` | Chain ID of the originating chain |
### callERC20
```solidity theme={null}
function callERC20(
address _token,
address _reserveAddress,
address _receiver,
bytes _data,
uint256 _flags,
bytes _nativeSender,
uint256 _chainIdFrom
) external returns (bool)
```
Used for calls where ERC20 transfer is involved.
**Parameters:**
| Name | Type | Description |
| ----------------- | --------- | ------------------------------------- |
| `_token` | `address` | Asset address |
| `_reserveAddress` | `address` | Receiver if call to `_receiver` fails |
| `_receiver` | `address` | Contract to be called |
| `_data` | `bytes` | Call data |
| `_flags` | `uint256` | Behavior flags (see Flags library) |
| `_nativeSender` | `bytes` | Native sender |
| `_chainIdFrom` | `uint256` | Chain ID of the originating chain |
# IDeBridgeGate
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/interfaces/IDeBridgeGate
IDeBridgeGate interface details - functions, events, and structs.
## Functions
### isSubmissionUsed
```solidity theme={null}
function isSubmissionUsed(
bytes32 submissionId
) external returns (bool)
```
Returns whether the transfer with the submissionId was claimed. submissionId is generated in `getSubmissionIdFrom`.
### getNativeInfo
```solidity theme={null}
function getNativeInfo(
address token
) external returns (uint256 nativeChainId, bytes nativeAddress)
```
Returns native token info by wrapped token address.
### send
```solidity theme={null}
function send(
address _tokenAddress,
uint256 _amount,
uint256 _chainIdTo,
bytes _receiver,
bytes _permit,
bool _useAssetFee,
uint32 _referralCode,
bytes _autoParams
) external
```
This method is used for the transfer of assets
[from the native chain](/dmp-details/dePort/transfer-flow#transfers-from-native-source-chain). It locks an asset in the smart
contract in the native chain and enables minting of deAsset on the secondary chain.
**Parameters:**
| Name | Type | Description |
| --------------- | --------- | ------------------------------------------------------------- |
| `_tokenAddress` | `address` | Asset identifier. |
| `_amount` | `uint256` | Amount to be transferred (note: the fee can be applied). |
| `_chainIdTo` | `uint256` | Chain id of the target chain. |
| `_receiver` | `bytes` | Receiver address. |
| `_permit` | `bytes` | deadline + signature for approving the spender by signature. |
| `_useAssetFee` | `bool` | use assets fee for pay protocol fix (only for special tokens) |
| `_referralCode` | `uint32` | Referral code |
| `_autoParams` | `bytes` | Auto params for external call in target network |
### claim
```solidity theme={null}
function claim(
bytes32 _debridgeId,
uint256 _amount,
uint256 _chainIdFrom,
address _receiver,
uint256 _nonce,
bytes _signatures,
bytes _autoParams
) external
```
Used for transfers [into the native chain](/dmp-details/dePort/transfer-flow#transfers-from-native-source-chain) to unlock the
designated amount of asset from collateral and transfer it to the receiver.
**Parameters:**
| Name | Type | Description |
| -------------- | --------- | --------------------------------------------------------------- |
| `_debridgeId` | `bytes32` | Asset identifier. |
| `_amount` | `uint256` | Amount of the transferred asset (note: the fee can be applied). |
| `_chainIdFrom` | `uint256` | Chain where submission was sent |
| `_receiver` | `address` | Receiver address. |
| `_nonce` | `uint256` | Submission id. |
| `_signatures` | `bytes` | Validators signatures to confirm |
| `_autoParams` | `bytes` | Auto params for external call |
### flash
```solidity theme={null}
function flash(
address _tokenAddress,
address _receiver,
uint256 _amount,
bytes _data
) external
```
Get a flash loan, msg.sender must implement IFlashCallback.
**Parameters:**
| Name | Type | Description |
| --------------- | --------- | ------------------------------- |
| `_tokenAddress` | `address` | An asset to loan |
| `_receiver` | `address` | Where funds should be sent |
| `_amount` | `uint256` | Amount to loan |
| `_data` | `bytes` | Data for sender's flashCallback |
### getDefiAvaliableReserves
```solidity theme={null}
function getDefiAvaliableReserves(
address _tokenAddress
) external returns (uint256)
```
Get reserves of a token available to use in DeFi.
**Parameters:**
| Name | Type | Description |
| --------------- | --------- | -------------- |
| `_tokenAddress` | `address` | Token address. |
### requestReserves
```solidity theme={null}
function requestReserves(
address _tokenAddress,
uint256 _amount
) external
```
Request the assets to be used in DeFi protocol.
**Parameters:**
| Name | Type | Description |
| --------------- | --------- | ------------------ |
| `_tokenAddress` | `address` | Asset address. |
| `_amount` | `uint256` | Amount to request. |
### returnReserves
```solidity theme={null}
function returnReserves(
address _tokenAddress,
uint256 _amount
) external
```
Return the assets that were used in DeFi protocol.
**Parameters:**
| Name | Type | Description |
| --------------- | --------- | ----------------- |
| `_tokenAddress` | `address` | Asset address. |
| `_amount` | `uint256` | Amount to return. |
### withdrawFee
```solidity theme={null}
function withdrawFee(
bytes32 _debridgeId
) external
```
Withdraw collected fees to feeProxy.
**Parameters:**
| Name | Type | Description |
| ------------- | --------- | ----------------- |
| `_debridgeId` | `bytes32` | Asset identifier. |
### getDebridgeChainAssetFixedFee
```solidity theme={null}
function getDebridgeChainAssetFixedFee(
bytes32 _debridgeId,
uint256 _chainId
) external returns (uint256)
```
Returns asset fixed fee value for specified debridge and chainId.
**Parameters:**
| Name | Type | Description |
| ------------- | --------- | ----------------- |
| `_debridgeId` | `bytes32` | Asset identifier. |
| `_chainId` | `uint256` | Chain id. |
## Events
### Sent
```solidity theme={null}
event Sent(
bytes32 submissionId,
bytes32 debridgeId,
uint256 amount,
bytes receiver,
uint256 nonce,
uint256 chainIdTo,
uint32 referralCode,
struct IDeBridgeGate.FeeParams feeParams,
bytes autoParams,
address nativeSender
)
```
Emitted once the tokens are sent from the original(native) chain to the other chain; the transfer tokens are expected to be
claimed by the users.
### Claimed
```solidity theme={null}
event Claimed(
bytes32 submissionId,
bytes32 debridgeId,
uint256 amount,
address receiver,
uint256 nonce,
uint256 chainIdFrom,
bytes autoParams,
bool isNativeToken
)
```
Emitted once the tokens are transferred and withdrawn on a target chain.
### PairAdded
```solidity theme={null}
event PairAdded(
bytes32 debridgeId,
address tokenAddress,
bytes nativeAddress,
uint256 nativeChainId,
uint256 maxAmount,
uint16 minReservesBps
)
```
Emitted when new asset support is added.
### MonitoringSendEvent
```solidity theme={null}
event MonitoringSendEvent(
bytes32 submissionId,
uint256 nonce,
uint256 lockedOrMintedAmount,
uint256 totalSupply
)
```
### MonitoringClaimEvent
```solidity theme={null}
event MonitoringClaimEvent(
bytes32 submissionId,
uint256 lockedOrMintedAmount,
uint256 totalSupply
)
```
### ChainSupportUpdated
```solidity theme={null}
event ChainSupportUpdated(
uint256 chainId,
bool isSupported,
bool isChainFrom
)
```
Emitted when the asset is allowed/disallowed to be transferred to the chain.
### ChainsSupportUpdated
```solidity theme={null}
event ChainsSupportUpdated(
uint256 chainIds,
struct IDeBridgeGate.ChainSupportInfo chainSupportInfo,
bool isChainFrom
)
```
Emitted when the supported chains are updated.
### CallProxyUpdated
```solidity theme={null}
event CallProxyUpdated(
address callProxy
)
```
Emitted when the new call proxy is set.
### AutoRequestExecuted
```solidity theme={null}
event AutoRequestExecuted(
bytes32 submissionId,
bool success,
address callProxy
)
```
Emitted when the transfer request is executed.
### Blocked
```solidity theme={null}
event Blocked(
bytes32 submissionId
)
```
Emitted when a submission is blocked.
### Unblocked
```solidity theme={null}
event Unblocked(
bytes32 submissionId
)
```
Emitted when a submission is unblocked.
### Flash
```solidity theme={null}
event Flash(
address sender,
address tokenAddress,
address receiver,
uint256 amount,
uint256 paid
)
```
Emitted when a flash loan is successfully returned.
### WithdrawnFee
```solidity theme={null}
event WithdrawnFee(
bytes32 debridgeId,
uint256 fee
)
```
Emitted when fee is withdrawn.
### FixedNativeFeeUpdated
```solidity theme={null}
event FixedNativeFeeUpdated(
uint256 globalFixedNativeFee,
uint256 globalTransferFeeBps
)
```
Emitted when `globalFixedNativeFee` and `globalTransferFeeBps` are updated.
### FixedNativeFeeAutoUpdated
```solidity theme={null}
event FixedNativeFeeAutoUpdated(
uint256 globalFixedNativeFee
)
```
Emitted when `globalFixedNativeFee` is updated by `feeContractUpdater`.
## Structs
### TokenInfo
```solidity theme={null}
struct TokenInfo {
uint256 nativeChainId;
bytes nativeAddress;
}
```
### DebridgeInfo
```solidity theme={null}
struct DebridgeInfo {
uint256 chainId;
uint256 maxAmount;
uint256 balance;
uint256 lockedInStrategies;
address tokenAddress;
uint16 minReservesBps;
bool exist;
}
```
### DebridgeFeeInfo
```solidity theme={null}
struct DebridgeFeeInfo {
uint256 collectedFees;
uint256 withdrawnFees;
mapping(uint256 => uint256) getChainFee;
}
```
### ChainSupportInfo
```solidity theme={null}
struct ChainSupportInfo {
uint256 fixedNativeFee;
bool isSupported;
uint16 transferFeeBps;
}
```
### DiscountInfo
```solidity theme={null}
struct DiscountInfo {
uint16 discountFixBps;
uint16 discountTransferBps;
}
```
### SubmissionAutoParamsTo
```solidity theme={null}
struct SubmissionAutoParamsTo {
uint256 executionFee;
uint256 flags;
bytes fallbackAddress;
bytes data;
}
```
### SubmissionAutoParamsFrom
```solidity theme={null}
struct SubmissionAutoParamsFrom {
uint256 executionFee;
uint256 flags;
address fallbackAddress;
bytes data;
bytes nativeSender;
}
```
### FeeParams
```solidity theme={null}
struct FeeParams {
uint256 receivedAmount;
uint256 fixFee;
uint256 transferFee;
bool useAssetFee;
bool isNativeToken;
}
```
# IDeBridgeToken
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/interfaces/IDeBridgeToken
IDeBridgeToken interface details - functions.
## Functions
### mint
```solidity theme={null}
function mint(
address _receiver,
uint256 _amount
) external
```
Issues new tokens.
**Parameters:**
| Name | Type | Description |
| ----------- | --------- | -------------------- |
| `_receiver` | `address` | Token's receiver. |
| `_amount` | `uint256` | Amount to be minted. |
### burn
```solidity theme={null}
function burn(
uint256 _amount
) external
```
Destroys existing tokens.
**Parameters:**
| Name | Type | Description |
| --------- | --------- | ------------------- |
| `_amount` | `uint256` | Amount to be burnt. |
# IDeBridgeTokenDeployer
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/interfaces/IDeBridgeTokenDeployer
IDeBridgeTokenDeployer interface details - functions and events.
## Functions
### deployAsset
```solidity theme={null}
function deployAsset(
bytes32 _debridgeId,
string _name,
string _symbol,
uint8 _decimals
) external returns (address deTokenAddress)
```
Deploy a deToken(`DeBridgeTokenProxy`) for an asset.
**Parameters:**
| Name | Type | Description |
| ------------- | --------- | ------------------------------------------ |
| `_debridgeId` | `bytes32` | Asset id, see `DeBridgeGate.getDebridgeId` |
| `_name` | `string` | The asset's name |
| `_symbol` | `string` | The asset's symbol |
| `_decimals` | `uint8` | The asset's decimals |
## Events
### DeBridgeTokenDeployed
```solidity theme={null}
event DeBridgeTokenDeployed(
address asset,
string name,
string symbol,
uint8 decimals
)
```
Emitted when a deToken(`DeBridgeTokenProxy`) is deployed using this contract
# IOraclesManager
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/interfaces/IOraclesManager
IOraclesManager interface details - events and structs.
## Events
### AddOracle
```solidity theme={null}
event AddOracle(
address oracle,
bool required
)
```
Emitted when an oracle is added.
**Parameters:**
| Name | Type | Description |
| ---------- | --------- | ------------------------------------------------------ |
| `oracle` | `address` | Address of an added oracle |
| `required` | `bool` | Is this oracle's signature required for every transfer |
### UpdateOracle
```solidity theme={null}
event UpdateOracle(
address oracle,
bool required,
bool isValid
)
```
Emitted when an oracle is updated.
**Parameters:**
| Name | Type | Description |
| ---------- | --------- | ------------------------------------------------------ |
| `oracle` | `address` | Address of an updated oracle |
| `required` | `bool` | Is this oracle's signature required for every transfer |
| `isValid` | `bool` | Is this oracle valid, i.e. should it be treated as one |
### DeployApproved
```solidity theme={null}
event DeployApproved(
bytes32 deployId
)
```
Emitted once the submission is confirmed by min required amount of oracles.
### SubmissionApproved
```solidity theme={null}
event SubmissionApproved(
bytes32 submissionId
)
```
Emitted once the submission is confirmed by min required amount of oracles.
## Structs
### OracleInfo
```solidity theme={null}
struct OracleInfo {
bool exist;
bool isValid;
bool required;
}
```
# ISignatureVerifier
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/interfaces/ISignatureVerifier
ISignatureVerifier interface details - functions and events.
## Functions
### submit
```solidity theme={null}
function submit(
bytes32 _submissionId,
bytes _signatures,
uint8 _excessConfirmations
) external
```
Check confirmation (validate signatures) for the transfer request.
**Parameters:**
| Name | Type | Description |
| ---------------------- | --------- | -------------------------------- |
| `_submissionId` | `bytes32` | Submission identifier. |
| `_signatures` | `bytes` | Array of signatures by oracles. |
| `_excessConfirmations` | `uint8` | override min confirmations count |
## Events
### Confirmed
```solidity theme={null}
event Confirmed(
bytes32 submissionId,
address operator
)
```
Emitted once the submission is confirmed by one oracle.
### DeployConfirmed
```solidity theme={null}
event DeployConfirmed(
bytes32 deployId,
address operator
)
```
Emitted once the submission is confirmed by min required amount of oracles.
# IWethGate
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/interfaces/IWethGate
IWethGate interface details - functions.
## Functions
### withdraw
```solidity theme={null}
function withdraw(
address receiver,
uint256 wad
) external
```
Transfer assets to a receiver.
**Parameters:**
| Name | Type | Description |
| ---------- | --------- | ------------------------------------- |
| `receiver` | `address` | This address will receive a transfer. |
| `wad` | `uint256` | Amount in wei |
# introduction
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/introduction
Method Parameters, AutoParams Structure, and Flags.
# Interaction with deBridge Infrastructure
Interaction with the deBridge infrastructure is as simple as calling the `send` method of the `debridgeGate` smart contract deployed on all supported
blockchains. The method can be called by any arbitrary address — either EOA or smart contracts.
```solidity theme={null}
function send(
address _tokenAddress,
uint256 _amount,
uint256 _chainIdTo,
bytes memory _receiver,
bytes memory _permit,
bool _useAssetFee,
uint32 _referralCode,
bytes calldata _autoParams
) external payable;
```
## Method 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 | [EIP-2612](https://eips.ethereum.org/EIPS/eip-2612) permit signature (if token supports it) |
| `_useAssetFee` | bool | Should be set to `false`. Reserved for future governance usage |
| `_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.com/](https://app.debridge.com/). Governance may thank you later for being an early builder.
***
## AutoParams Structure
`_autoParams` allows passing arbitrary messages and call data to be executed as an external call to the receiver address on the destination chain. It
also enables setting an `executionFee`, which rewards the wallet/keeper that completes the transaction. 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:
```solidity theme={null}
struct SubmissionAutoParamsTo {
uint256 executionFee;
uint256 flags;
bytes fallbackAddress;
bytes data;
}
```
| Parameter Name | Type | Description |
| ----------------- | ------- | ------------------------------------------------------------------------------------------------------ |
| `executionFee` | uint256 | Suggested reward (in tokens) paid to executor on the destination chain |
| `flags` | uint256 | Bitmask flags that define execution logic |
| `fallbackAddress` | bytes | Address to receive tokens if external call fails |
| `data` | bytes | Message/call data to be passed to the receiver on destination chain during the external call execution |
***
## Flags
Flags are a bitmask that customize transaction execution flow on the destination chain. You can combine multiple flags by setting respective bits to
`1` simultaneously.
```solidity theme={null}
library Flags {
uint256 public constant UNWRAP_ETH = 0;
uint256 public constant REVERT_IF_EXTERNAL_FAIL = 1;
uint256 public constant PROXY_WITH_SENDER = 2;
uint256 public constant SEND_HASHED_DATA = 3;
uint256 public constant SEND_EXTERNAL_CALL_GAS_LIMIT = 4;
uint256 public constant MULTI_SEND = 5;
}
```
| Flag Name | Value | Description |
| ------------------------------ | ----- | --------------------------------------------------------------------------------------- |
| `UNWRAP_ETH` | 0 | Automatically unwrap base asset (e.g., convert WETH to ETH) |
| `REVERT_IF_EXTERNAL_FAIL` | 1 | Revert entire tx if external call fails |
| `PROXY_WITH_SENDER` | 2 | Enforces sender validation via `submissionNativeSender` and `submissionChainIdFrom` |
| `SEND_HASHED_DATA` | 3 | Only hashed data is passed; used to prevent unauthorized claims |
| `SEND_EXTERNAL_CALL_GAS_LIMIT` | 4 | Specifies minimal gas limit for the external call (included in first 4 bytes of `data`) |
| `MULTI_SEND` | 5 | Executes data via Gnosis Multisend implementation inside deBridge `callProxy` |
***
`PROXY_WITH_SENDER` flag should be used if the receiving smart contract must validate that the message sender is trusted. When set, the deBridge
protocol stores `submissionNativeSender` and `submissionChainIdFrom`, allowing the recipient contract to verify the sender.
![External Call]()
The receiving smart contract can retrieve the `callProxy` address from the `debridgeGate` smart contract. Use
[`onlyControllingAddress`](https://github.com/debridge-finance/debridge-twap-oracle/blob/f981f700d07108fce5509fabd2fd0f10157ae6d6/contracts/debridge-twap-oracle/BridgeAppBase.sol#L62)
modifier or inherit from
[`BridgeAppBase.sol`](https://github.com/debridge-finance/debridge-twap-oracle/blob/f981f700d07108fce5509fabd2fd0f10157ae6d6/contracts/debridge-twap-oracle/BridgeAppBase.sol)
to implement this validation logic properly.
# Flags
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/libraries/flags
Flags library details - fields and functions.
## Variables
### UNWRAP\_ETH
```solidity theme={null}
uint256 public constant UNWRAP_ETH;
```
Flag to unwrap ETH
### REVERT\_IF\_EXTERNAL\_FAIL
```solidity theme={null}
uint256 public constant REVERT_IF_EXTERNAL_FAIL;
```
Flag to revert if external call fails
### PROXY\_WITH\_SENDER
```solidity theme={null}
uint256 public constant PROXY_WITH_SENDER;
```
Flag to call proxy with a sender contract
### SEND\_HASHED\_DATA
```solidity theme={null}
uint256 public constant SEND_HASHED_DATA;
```
Data is hash in DeBridgeGate send method
***
## Functions
### getFlag
```solidity theme={null}
function getFlag(
uint256 _packedFlags,
uint256 _flag
) internal returns (bool)
```
Get flag
#### Parameters:
| Name | Type | Description |
| ------------- | ------- | ----------------------- |
| \_packedFlags | uint256 | Flags packed to uint256 |
| \_flag | uint256 | Flag to check |
***
### setFlag
```solidity theme={null}
function setFlag(
uint256 _packedFlags,
uint256 _flag,
bool _value
) internal returns (uint256)
```
Set flag
#### Parameters:
| Name | Type | Description |
| ------------- | ------- | ----------------------- |
| \_packedFlags | uint256 | Flags packed to uint256 |
| \_flag | uint256 | Flag to set |
| \_value | bool | Is set or not set |
# CallProxy
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/periphery/CallProxy
CallProxy contract details - fields and functions.
Proxy to execute the other contract calls. This contract is used when a user requests transfer with specific call of other contract.
***
## Variables
### DEBRIDGE\_GATE\_ROLE
```solidity theme={null}
bytes32 public constant DEBRIDGE_GATE_ROLE;
```
Role allowed to withdraw fee
### submissionChainIdFrom
```solidity theme={null}
uint256 public submissionChainIdFrom;
```
Chain from which the current submission is received
### submissionNativeSender
```solidity theme={null}
bytes public submissionNativeSender;
```
Native sender of the current submission
***
## Functions
### initialize
```solidity theme={null}
function initialize() public
```
### call
```solidity theme={null}
function call(
address _reserveAddress,
address _receiver,
bytes _data,
uint256 _flags,
bytes _nativeSender,
uint256 _chainIdFrom
) external returns (bool _result)
```
Used for calls where native asset transfer is involved.
#### Parameters:
| Name | Type | Description |
| ---------------- | ------- | ------------------------------------------------------- |
| \_reserveAddress | address | Receiver of the tokens if the call to \_receiver fails |
| \_receiver | address | Contract to be called |
| \_data | bytes | Call data |
| \_flags | uint256 | Flags to change behavior; see Flags library for details |
| \_nativeSender | bytes | Native sender |
| \_chainIdFrom | uint256 | Id of a chain that originated the request |
***
### callERC20
```solidity theme={null}
function callERC20(
address _token,
address _reserveAddress,
address _receiver,
bytes _data,
uint256 _flags,
bytes _nativeSender,
uint256 _chainIdFrom
) external returns (bool _result)
```
Used for calls where ERC20 transfer is involved.
#### Parameters:
| Name | Type | Description |
| ---------------- | ------- | ------------------------------------------------------- |
| \_token | address | Asset address |
| \_reserveAddress | address | Receiver of the tokens if the call to \_receiver fails |
| \_receiver | address | Contract to be called |
| \_data | bytes | Call data |
| \_flags | uint256 | Flags to change behavior; see Flags library for details |
| \_nativeSender | bytes | Native sender |
| \_chainIdFrom | uint256 | Id of a chain that originated the request |
***
### externalCall
```solidity theme={null}
function externalCall(
address destination,
uint256 value,
bytes data,
bytes _nativeSender,
uint256 _chainIdFrom,
bool storeSender
) internal returns (bool result)
```
***
### receive
```solidity theme={null}
function receive() external
```
***
### version
```solidity theme={null}
function version() external returns (uint256)
```
Get this contract's version
# DeBridgeToken
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/periphery/DeBridgeToken
DeBridgeToken contract details - fields and functions.
ERC20 token that is used as wrapped asset to represent the native token value on the other chains.
***
## Variables
### MINTER\_ROLE
```solidity theme={null}
bytes32 public constant MINTER_ROLE;
```
Minter role identifier
### PAUSER\_ROLE
```solidity theme={null}
bytes32 public constant PAUSER_ROLE;
```
Pauser role identifier
### DOMAIN\_SEPARATOR
```solidity theme={null}
bytes32 public DOMAIN_SEPARATOR;
```
Domain separator as described in [EIP-712](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md#rationale)
### PERMIT\_TYPEHASH
```solidity theme={null}
bytes32 public constant PERMIT_TYPEHASH;
```
Typehash as described in [EIP-712](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md#rationale).
```
typehash = keccak256("Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)")
```
### nonces
```solidity theme={null}
mapping(address => uint256) public nonces;
```
Transfers counter
### \_decimals
```solidity theme={null}
uint8 internal _decimals;
```
Asset's decimals
***
## Functions
### initialize
```solidity theme={null}
function initialize(
string name_,
string symbol_,
uint8 decimals_,
address admin,
address[] minters
) public
```
Constructor that initializes the most important configurations.
#### Parameters:
| Name | Type | Description |
| ---------- | ---------- | ---------------------------------------- |
| name\_ | string | Asset's name. |
| symbol\_ | string | Asset's symbol. |
| decimals\_ | uint8 | Asset's decimals. |
| admin | address | Address to set as asset's admin. |
| minters | address\[] | The accounts allowed to mint new tokens. |
***
### mint
```solidity theme={null}
function mint(
address _receiver,
uint256 _amount
) external
```
Issues new tokens.
#### Parameters:
| Name | Type | Description |
| ---------- | ------- | -------------------- |
| \_receiver | address | Token's receiver. |
| \_amount | uint256 | Amount to be minted. |
***
### burn
```solidity theme={null}
function burn(
uint256 _amount
) external
```
Destroys existing tokens.
#### Parameters:
| Name | Type | Description |
| -------- | ------- | ------------------- |
| \_amount | uint256 | Amount to be burnt. |
***
### permit
```solidity theme={null}
function permit(
address _owner,
address _spender,
uint256 _value,
uint256 _deadline,
uint8 _v,
bytes32 _r,
bytes32 _s
) external
```
Approves the spender by signature.
#### Parameters:
| Name | Type | Description |
| ---------- | ------- | ----------------------- |
| \_owner | address | Token's owner. |
| \_spender | address | Account to be approved. |
| \_value | uint256 | Amount to be approved. |
| \_deadline | uint256 | The permit valid until. |
| \_v | uint8 | Signature part. |
| \_r | bytes32 | Signature part. |
| \_s | bytes32 | Signature part. |
***
### decimals
```solidity theme={null}
function decimals() public returns (uint8)
```
Asset's decimals
***
### pause
```solidity theme={null}
function pause() public
```
Pauses all token transfers. The caller must have the `PAUSER_ROLE`.
***
### unpause
```solidity theme={null}
function unpause() public
```
Unpauses all token transfers. The caller must have the `PAUSER_ROLE`.
***
### \_beforeTokenTransfer
```solidity theme={null}
function _beforeTokenTransfer(
address from,
address to,
uint256 amount
) internal
```
# DeBridgeTokenProxy
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/periphery/DeBridgeTokenProxy
DeBridgeTokenProxy contract details - functions.
This contract implements a proxy that gets the implementation address for each call from `DeBridgeTokenDeployer`. It's deployed by
`DeBridgeTokenDeployer`. Implementation is `DeBridgeToken`.
***
## Functions
### constructor
```solidity theme={null}
function constructor(
address beacon,
bytes data
) public
```
# SimpleFeeProxy
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/periphery/SimpleFeeProxy
SimpleFeeProxy contract details - fields and functions.
Helper to withdraw fees from DeBridgeGate and transfer them to a treasury.
***
## Variables
### debridgeGate
```solidity theme={null}
contract IDeBridgeGate public debridgeGate;
```
DeBridgeGate address
### treasury
```solidity theme={null}
address public treasury;
```
Treasury address
***
## Functions
### initialize
```solidity theme={null}
function initialize(
contract IDeBridgeGate _debridgeGate,
address _treasury
) public
```
### pause
```solidity theme={null}
function pause() external
```
### unpause
```solidity theme={null}
function unpause() external
```
### setDebridgeGate
```solidity theme={null}
function setDebridgeGate(
contract IDeBridgeGate _debridgeGate
) external
```
### setTreasury
```solidity theme={null}
function setTreasury(
address _treasury
) external
```
### withdrawFee
```solidity theme={null}
function withdrawFee(
address _tokenAddress
) external
```
Transfer collected fees for a token to the treasury.
#### Parameters:
| Name | Type | Description |
| -------------- | ------- | --------------------------------------- |
| \_tokenAddress | address | Address of a deToken on a current chain |
***
### withdrawNativeFee
```solidity theme={null}
function withdrawNativeFee() external
```
Transfer collected fees for a native token to the treasury.
### receive
```solidity theme={null}
function receive() external
```
### getbDebridgeId
```solidity theme={null}
function getbDebridgeId(
uint256 _chainId,
bytes _tokenAddress
) public returns (bytes32)
```
Calculates asset identifier.
#### Parameters:
| Name | Type | Description |
| -------------- | ------- | ---------------------------------------- |
| \_chainId | uint256 | Current chain id. |
| \_tokenAddress | bytes | Address of the asset on the other chain. |
***
### getDebridgeId
```solidity theme={null}
function getDebridgeId(
uint256 _chainId,
address _tokenAddress
) public returns (bytes32)
```
Calculates asset identifier.
#### Parameters:
| Name | Type | Description |
| -------------- | ------- | ---------------------------------------- |
| \_chainId | uint256 | Current chain id. |
| \_tokenAddress | address | Address of the asset on the other chain. |
***
### getChainId
```solidity theme={null}
function getChainId() public returns (uint256 cid)
```
Get current chain id.
***
### \_safeTransferETH
```solidity theme={null}
function _safeTransferETH(
address to,
uint256 value
) internal
```
Transfer ETH to an address, revert if it fails.
#### Parameters:
| Name | Type | Description |
| ----- | ------- | ------------------------- |
| to | address | recipient of the transfer |
| value | uint256 | the amount to send |
***
### version
```solidity theme={null}
function version() external returns (uint256)
```
Get this contract's version
# DeBridgeGate
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/transfers/DeBridgeGate
DeBridgeGate contract details - fields and functions.
Contract for assets transfers. The user can transfer the asset to any of the approved chains. The admin manages the assets, fees
and other important protocol parameters.
***
## Variables
### BPS\_DENOMINATOR
```solidity theme={null}
uint256 public constant BPS_DENOMINATOR;
```
Basis points or bps, set to 10,000 (equal to 1/10000). Used to express relative values (fees)
### GOVMONITORING\_ROLE
```solidity theme={null}
bytes32 public constant GOVMONITORING_ROLE;
```
Role allowed to stop transfers
### SUBMISSION\_PREFIX
```solidity theme={null}
uint256 public constant SUBMISSION_PREFIX;
```
Prefix to calculation `submissionId`
### DEPLOY\_PREFIX
```solidity theme={null}
uint256 public constant DEPLOY_PREFIX;
```
Prefix to calculation `deployId`
### deBridgeTokenDeployer
```solidity theme={null}
address public deBridgeTokenDeployer;
```
Address of `IDeBridgeTokenDeployer` contract
### signatureVerifier
```solidity theme={null}
address public signatureVerifier;
```
Current signature verifier address to verify signatures.
### excessConfirmations
```solidity theme={null}
uint8 public excessConfirmations;
```
Minimal required confirmations in case sent amount is big, has no effect if less than `SignatureVerifier.minConfirmations`
### flashFeeBps
```solidity theme={null}
uint256 public flashFeeBps;
```
Flash loan fee in basis points (1/10000)
### nonce
```solidity theme={null}
uint256 public nonce;
```
Outgoing submissions count
### getDebridge
```solidity theme={null}
mapping(bytes32 => struct IDeBridgeGate.DebridgeInfo) public getDebridge;
```
Maps debridgeId (see `getDebridgeId`) => bridge-specific information.
### getDebridgeFeeInfo
```solidity theme={null}
mapping(bytes32 => struct IDeBridgeGate.DebridgeFeeInfo) public getDebridgeFeeInfo;
```
Maps debridgeId (see `getDebridgeId`) => fee information
### isSubmissionUsed
```solidity theme={null}
mapping(bytes32 => bool) public isSubmissionUsed;
```
Returns whether the transfer with the `submissionId` was claimed.
### isBlockedSubmission
```solidity theme={null}
mapping(bytes32 => bool) public isBlockedSubmission;
```
Returns whether the transfer with the `submissionId` is blocked.
### getAmountThreshold
```solidity theme={null}
mapping(bytes32 => uint256) public getAmountThreshold;
```
Maps `debridgeId` (see `getDebridgeId`) to threshold amount after which
`Math.max(excessConfirmations,SignatureVerifier.minConfirmations)` is used instead of `SignatureVerifier.minConfirmations`
### getChainToConfig
```solidity theme={null}
mapping(uint256 => struct IDeBridgeGate.ChainSupportInfo) public getChainToConfig;
```
Whether the chain for the asset is supported to send
### getChainFromConfig
```solidity theme={null}
mapping(uint256 => struct IDeBridgeGate.ChainSupportInfo) public getChainFromConfig;
```
Whether the chain for the asset is supported to claim
### feeDiscount
```solidity theme={null}
mapping(address => struct IDeBridgeGate.DiscountInfo) public feeDiscount;
```
Fee discount for address
### getNativeInfo
```solidity theme={null}
mapping(address => struct IDeBridgeGate.TokenInfo) public getNativeInfo;
```
Returns native token info by wrapped token address
### defiController
```solidity theme={null}
address public defiController;
```
DefiController that can supply liquidity to staking strategies (AAVE, Compound, etc.)
### feeProxy
```solidity theme={null}
address public feeProxy;
```
Proxy to convert collected fees and transfer to Ethereum treasury
### callProxy
```solidity theme={null}
address public callProxy;
```
Address of the proxy to execute user's calls.
### weth
```solidity theme={null}
contract IWETH public weth;
```
Wrapped native token contract
### feeContractUpdater
```solidity theme={null}
address public feeContractUpdater;
```
Contract that can override `globalFixedNativeFee`
### globalFixedNativeFee
```solidity theme={null}
uint256 public globalFixedNativeFee;
```
Fallback fixed fee in native asset (used if chain fixed fee is 0)
### globalTransferFeeBps
```solidity theme={null}
uint16 public globalTransferFeeBps;
```
Fallback transfer fee in BPS (used if chain transfer fee is 0)
### wethGate
```solidity theme={null}
contract IWethGate public wethGate;
```
WethGate contract used for WETH withdraws affected by EIP1884
### lockedClaim
```solidity theme={null}
uint256 public lockedClaim;
```
Locker for claim method
***
## Functions
### initialize
```solidity theme={null}
function initialize(
uint8 _excessConfirmations,
contract IWETH _weth
) public
```
Constructor that initializes the most important configurations.
#### Parameters:
| Name | Type | Description |
| --------------------- | -------------- | ---------------------------------------------------------------- |
| \_excessConfirmations | uint8 | Minimal required confirmations in case of too many confirmations |
| \_weth | contract IWETH | Wrapped native token contract |
***
### send
```solidity theme={null}
function send(
address _tokenAddress,
uint256 _amount,
uint256 _chainIdTo,
bytes _receiver,
bytes _permit,
bool _useAssetFee,
uint32 _referralCode,
bytes _autoParams
) external
```
This method is used for the transfer of assets from the
[native chain](/dmp-details/dePort/transfer-flow#transfers-from-native-source-chain). It locks an asset in the smart contract in
the native chain and enables minting of deAsset on the secondary chain.
**Parameters:**
| Name | Type | Description |
| --------------- | --------- | ------------------------------------------------------------------ |
| `_tokenAddress` | `address` | Asset identifier. |
| `_amount` | `uint256` | Amount to be transferred (note: the fee can be applied). |
| `_chainIdTo` | `uint256` | Chain id of the target chain. |
| `_receiver` | `bytes` | Receiver address. |
| `_permit` | `bytes` | deadline + signature for approving the spender by signature. |
| `_useAssetFee` | `bool` | use assets fee for pay protocol fix (work only for specials token) |
| `_referralCode` | `uint32` | Referral code |
| `_autoParams` | `bytes` | Auto params for external call in target network |
### claim
```solidity theme={null}
function claim(
bytes32 _debridgeId,
uint256 _amount,
uint256 _chainIdFrom,
address _receiver,
uint256 _nonce,
bytes _signatures,
bytes _autoParams
) external
```
Is used for transfers [into the native chain](/dmp-details/dePort/transfer-flow#transfers-from-native-source-chain) to unlock the
designated amount of asset from collateral and transfer it to the receiver.
**Parameters:**
| Name | Type | Description |
| -------------- | --------- | --------------------------------------------------------------- |
| `_debridgeId` | `bytes32` | Asset identifier. |
| `_amount` | `uint256` | Amount of the transferred asset (note: the fee can be applied). |
| `_chainIdFrom` | `uint256` | Chain where submission was sent |
| `_receiver` | `address` | Receiver address. |
| `_nonce` | `uint256` | Submission id. |
| `_signatures` | `bytes` | Validators signatures to confirm |
| `_autoParams` | `bytes` | Auto params for external call |
### flash
```solidity theme={null}
function flash(
address _tokenAddress,
address _receiver,
uint256 _amount,
bytes _data
) external
```
Get a flash loan, msg.sender must implement IFlashCallback.
**Parameters:**
| Name | Type | Description |
| --------------- | --------- | ----------------------------------------------- |
| `_tokenAddress` | `address` | An asset to loan |
| `_receiver` | `address` | Where funds should be sent |
| `_amount` | `uint256` | Amount to loan |
| `_data` | `bytes` | Data to pass to sender's flashCallback function |
### deployNewAsset
```solidity theme={null}
function deployNewAsset(
bytes _nativeTokenAddress,
uint256 _nativeChainId,
string _name,
string _symbol,
uint8 _decimals,
bytes _signatures
) external
```
Deploy a deToken(DeBridgeTokenProxy) for an asset.
**Parameters:**
| Name | Type | Description |
| --------------------- | --------- | --------------------------------- |
| `_nativeTokenAddress` | `bytes` | A token address on a native chain |
| `_nativeChainId` | `uint256` | The token native chain's id |
| `_name` | `string` | The token's name |
| `_symbol` | `string` | The token's symbol |
| `_decimals` | `uint8` | The token's decimals |
| `_signatures` | `bytes` | Validators' signatures |
### autoUpdateFixedNativeFee
```solidity theme={null}
function autoUpdateFixedNativeFee(
uint256 _globalFixedNativeFee
) external
```
Update native fix fee. Called by our fee update contract.
**Parameters:**
| Name | Type | Description |
| ----------------------- | --------- | ----------- |
| `_globalFixedNativeFee` | `uint256` | new value |
### updateChainSupport
```solidity theme={null}
function updateChainSupport(
uint256[] _chainIds,
struct IDeBridgeGate.ChainSupportInfo[] _chainSupportInfo,
bool _isChainFrom
) external
```
Update asset's fees.
**Parameters:**
| Name | Type | Description |
| ------------------- | ----------------------------------------- | --------------------------------------- |
| `_chainIds` | `uint256[]` | Chain identifiers. |
| `_chainSupportInfo` | `struct IDeBridgeGate.ChainSupportInfo[]` | Chain support info. |
| `_isChainFrom` | `bool` | is true for editing getChainFromConfig. |
### updateGlobalFee
```solidity theme={null}
function updateGlobalFee(
uint256 _globalFixedNativeFee,
uint16 _globalTransferFeeBps
) external
```
Update fallbacks for fixed fee in native asset and transfer fee.
**Parameters:**
| Name | Type | Description |
| ----------------------- | --------- | ------------------------------------------------------------------------- |
| `_globalFixedNativeFee` | `uint256` | Fallback fixed fee in native asset, used if a chain fixed fee is set to 0 |
| `_globalTransferFeeBps` | `uint16` | Fallback transfer fee in BPS, used if a chain transfer fee is set to 0 |
### updateAssetFixedFees
```solidity theme={null}
function updateAssetFixedFees(
bytes32 _debridgeId,
uint256[] _supportedChainIds,
uint256[] _assetFeesInfo
) external
```
Update asset's fees.
**Parameters:**
| Name | Type | Description |
| -------------------- | ----------- | ------------------- |
| `_debridgeId` | `bytes32` | Asset identifier. |
| `_supportedChainIds` | `uint256[]` | Chain identifiers. |
| `_assetFeesInfo` | `uint256[]` | Chain support info. |
### updateExcessConfirmations
```solidity theme={null}
function updateExcessConfirmations(
uint8 _excessConfirmations
) external
```
Update minimal amount of required signatures, must be > `SignatureVerifier.minConfirmations` to have an effect.
**Parameters:**
| Name | Type | Description |
| ---------------------- | ------- | ------------------------------------- |
| `_excessConfirmations` | `uint8` | Minimal amount of required signatures |
### setChainSupport
```solidity theme={null}
function setChainSupport(
uint256 _chainId,
bool _isSupported,
bool _isChainFrom
) external
```
Set support for the chains where the token can be transferred.
**Parameters:**
| Name | Type | Description |
| -------------- | --------- | ------------------------------------------------- |
| `_chainId` | `uint256` | Chain id where tokens are sent. |
| `_isSupported` | `bool` | Whether the token is transferable to other chain. |
| `_isChainFrom` | `bool` | Is true for editing getChainFromConfig. |
### setCallProxy
```solidity theme={null}
function setCallProxy(
address _callProxy
) external
```
Set address of the call proxy.
**Parameters:**
| Name | Type | Description |
| ------------ | --------- | ----------------------------------------- |
| `_callProxy` | `address` | Address of the proxy that executes calls. |
### updateAsset
```solidity theme={null}
function updateAsset(
bytes32 _debridgeId,
uint256 _maxAmount,
uint16 _minReservesBps,
uint256 _amountThreshold
) external
```
Update specific asset's bridge parameters.
**Parameters:**
| Name | Type | Description |
| ------------------ | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `_debridgeId` | `bytes32` | Asset identifier. |
| `_maxAmount` | `uint256` | Maximum amount of current chain token to be wrapped. |
| `_minReservesBps` | `uint16` | Minimal reserve ratio in BPS. |
| `_amountThreshold` | `uint256` | Threshold amount after which `Math.max(excessConfirmations,SignatureVerifier.minConfirmations)` is used instead of `SignatureVerifier.minConfirmations` |
### setSignatureVerifier
```solidity theme={null}
function setSignatureVerifier(
address _verifier
) external
```
Set signature verifier address.
**Parameters:**
| Name | Type | Description |
| ----------- | --------- | --------------------------- |
| `_verifier` | `address` | Signature verifier address. |
### setDeBridgeTokenDeployer
```solidity theme={null}
function setDeBridgeTokenDeployer(
address _deBridgeTokenDeployer
) external
```
Set asset deployer address.
**Parameters:**
| Name | Type | Description |
| ------------------------ | --------- | ----------------------- |
| `_deBridgeTokenDeployer` | `address` | Asset deployer address. |
### setDefiController
```solidity theme={null}
function setDefiController(
address _defiController
) external
```
Set defi controller.
**Parameters:**
| Name | Type | Description |
| ----------------- | --------- | ------------------------ |
| `_defiController` | `address` | Defi controller address. |
### setFeeContractUpdater
```solidity theme={null}
function setFeeContractUpdater(
address _value
) external
```
Set fee contract updater, that can update fix native fee.
**Parameters:**
| Name | Type | Description |
| -------- | --------- | --------------------- |
| `_value` | `address` | New contract address. |
### setWethGate
```solidity theme={null}
function setWethGate(
contract IWethGate _wethGate
) external
```
Set wethGate contract, used for weth withdrawals affected by EIP1884.
**Parameters:**
| Name | Type | Description |
| ----------- | -------------------- | --------------------------------- |
| `_wethGate` | `contract IWethGate` | Address of new wethGate contract. |
### pause
```solidity theme={null}
function pause() external
```
Stop all transfers.
### unpause
```solidity theme={null}
function unpause() external
```
Allow transfers again.
### withdrawFee
```solidity theme={null}
function withdrawFee(
bytes32 _debridgeId
) external
```
Withdraw collected fees to feeProxy.
**Parameters:**
| Name | Type | Description |
| ------------- | --------- | ----------------- |
| `_debridgeId` | `bytes32` | Asset identifier. |
### requestReserves
```solidity theme={null}
function requestReserves(
address _tokenAddress,
uint256 _amount
) external
```
Request the assets to be used in DeFi protocol.
**Parameters:**
| Name | Type | Description |
| --------------- | --------- | ------------------ |
| `_tokenAddress` | `address` | Asset address. |
| `_amount` | `uint256` | Amount to request. |
### returnReserves
```solidity theme={null}
function returnReserves(
address _tokenAddress,
uint256 _amount
) external
```
Return the assets that were used in DeFi protocol.
**Parameters:**
| Name | Type | Description |
| --------------- | --------- | -------------------------- |
| `_tokenAddress` | `address` | Asset address. |
| `_amount` | `uint256` | Amount of tokens to claim. |
### setFeeProxy
```solidity theme={null}
function setFeeProxy(
address _feeProxy
) external
```
Set fee converter proxy.
**Parameters:**
| Name | Type | Description |
| ----------- | --------- | ------------------ |
| `_feeProxy` | `address` | Fee proxy address. |
### blockSubmission
```solidity theme={null}
function blockSubmission(
bytes32[] _submissionIds,
bool isBlocked
) external
```
Block or unblock a list of submissions.
**Parameters:**
| Name | Type | Description |
| ---------------- | ----------- | -------------------------------- |
| `_submissionIds` | `bytes32[]` | IDs of submissions to modify. |
| `isBlocked` | `bool` | True to block, false to unblock. |
### updateFlashFee
```solidity theme={null}
function updateFlashFee(
uint256 _flashFeeBps
) external
```
Update flash fees.
**Parameters:**
| Name | Type | Description |
| -------------- | --------- | --------------- |
| `_flashFeeBps` | `uint256` | New fee in BPS. |
### updateFeeDiscount
```solidity theme={null}
function updateFeeDiscount(
address _address,
uint16 _discountFixBps,
uint16 _discountTransferBps
) external
```
Update discount settings.
**Parameters:**
| Name | Type | Description |
| ---------------------- | --------- | --------------------------- |
| `_address` | `address` | Customer address. |
| `_discountFixBps` | `uint16` | Fix discount in BPS. |
| `_discountTransferBps` | `uint16` | Transfer % discount in BPS. |
### receive
```solidity theme={null}
function receive() external
```
### \_checkConfirmations
```solidity theme={null}
function _checkConfirmations(
bytes32 _submissionId,
bytes32 _debridgeId,
uint256 _amount,
bytes _signatures
) internal
```
### \_addAsset
```solidity theme={null}
function _addAsset(
bytes32 _debridgeId,
address _tokenAddress,
bytes _nativeAddress,
uint256 _nativeChainId
) internal
```
Add support for the asset.
**Parameters:**
| Name | Type | Description |
| ---------------- | --------- | ----------------------------------- |
| `_debridgeId` | `bytes32` | Asset identifier. |
| `_tokenAddress` | `address` | Address of the asset on this chain. |
| `_nativeAddress` | `bytes` | Address of asset on native chain. |
| `_nativeChainId` | `uint256` | Native chain ID. |
### \_send
```solidity theme={null}
function _send(
bytes _amount,
address _chainIdTo,
uint256 _permit
) internal returns (uint256 amountAfterFee, bytes32 debridgeId, struct IDeBridgeGate.FeeParams feeParams)
```
Locks asset on the chain and enables minting on the other chain.
**Parameters:**
| Name | Type | Description |
| ------------ | --------- | ---------------------------------------------- |
| `_amount` | `bytes` | Amount to be transferred (fee can be applied). |
| `_chainIdTo` | `address` | Target chain ID. |
| `_permit` | `uint256` | Deadline + signature for permit. |
### \_publishSubmission
```solidity theme={null}
function _publishSubmission(
bytes32 _debridgeId,
uint256 _chainIdTo,
uint256 _amount,
bytes _receiver,
struct IDeBridgeGate.FeeParams feeParams,
uint32 _referralCode,
struct IDeBridgeGate.SubmissionAutoParamsTo autoParams,
bool hasAutoParams
) internal
```
### \_applyDiscount
```solidity theme={null}
function _applyDiscount(
uint256 amount,
uint16 discountBps
) internal returns (uint256)
```
### \_validateToken
```solidity theme={null}
function _validateToken(
address _token
) internal
```
### \_claim
```solidity theme={null}
function _claim(
bytes32 _debridgeId,
bytes32 _receiver,
address _amount
) internal returns (bool isNativeToken)
```
Unlock the asset on the current chain and transfer to receiver.
**Parameters:**
| Name | Type | Description |
| ------------- | --------- | ----------------------------------------------------------- |
| `_debridgeId` | `bytes32` | Asset identifier. |
| `_receiver` | `bytes32` | Receiver address. |
| `_amount` | `address` | Amount of the transferred asset (note: fee can be applied). |
### \_mintOrTransfer
```solidity theme={null}
function _mintOrTransfer(
address _token,
address _receiver,
uint256 _amount,
bool isNativeToken
) internal
```
### \_safeTransferETH
```solidity theme={null}
function _safeTransferETH(
address to,
uint256 value
) internal
```
### \_withdrawWeth
```solidity theme={null}
function _withdrawWeth(
address _receiver,
uint256 _amount
) internal
```
### \_normalizeTokenAmount
```solidity theme={null}
function _normalizeTokenAmount(
address _token,
uint256 _amount
) internal returns (uint256)
```
### getDefiAvaliableReserves
```solidity theme={null}
function getDefiAvaliableReserves(
address _tokenAddress
) external returns (uint256)
```
Get reserves of a token available to use in DeFi.
**Parameters:**
| Name | Type | Description |
| --------------- | --------- | -------------- |
| `_tokenAddress` | `address` | Token address. |
### getDebridgeId
```solidity theme={null}
function getDebridgeId(
uint256 _chainId,
address _tokenAddress
) public returns (bytes32)
```
Calculates asset identifier.
**Parameters:**
| Name | Type | Description |
| --------------- | --------- | ------------------------------------ |
| `_chainId` | `uint256` | Current chain id. |
| `_tokenAddress` | `address` | Address of the asset on other chain. |
### getbDebridgeId
```solidity theme={null}
function getbDebridgeId(
uint256 _chainId,
bytes _tokenAddress
) public returns (bytes32)
```
Calculates asset identifier.
**Parameters:**
| Name | Type | Description |
| --------------- | --------- | ------------------------------------ |
| `_chainId` | `uint256` | Current chain id. |
| `_tokenAddress` | `bytes` | Address of the asset on other chain. |
### getDebridgeChainAssetFixedFee
```solidity theme={null}
function getDebridgeChainAssetFixedFee(
bytes32 _debridgeId,
uint256 _chainId
) external returns (uint256)
```
Returns asset fixed fee value for specified debridge and chainId.
**Parameters:**
| Name | Type | Description |
| ------------- | --------- | ----------------- |
| `_debridgeId` | `bytes32` | Asset identifier. |
| `_chainId` | `uint256` | Chain id. |
### getSubmissionIdFrom
```solidity theme={null}
function getSubmissionIdFrom(
bytes32 _debridgeId,
uint256 _chainIdFrom,
uint256 _amount,
address _receiver,
uint256 _nonce,
struct IDeBridgeGate.SubmissionAutoParamsFrom _autoParams,
bool _hasAutoParams,
address _sender
) public returns (bytes32)
```
Calculate submission id for auto claimable transfer.
**Parameters:**
| Name | Type | Description |
| ---------------- | ----------------------------------------------- | --------------------------------------------------------------- |
| `_debridgeId` | `bytes32` | Asset identifier. |
| `_chainIdFrom` | `uint256` | Chain identifier of the chain where tokens are sent from. |
| `_amount` | `uint256` | Amount of the transferred asset (note: the fee can be applied). |
| `_receiver` | `address` | Receiver address. |
| `_nonce` | `uint256` | Submission id. |
| `_autoParams` | `struct IDeBridgeGate.SubmissionAutoParamsFrom` | Auto params for external call. |
| `_hasAutoParams` | `bool` | True if auto params are provided. |
| `_sender` | `address` | Address that will call claim. |
### getDeployId
```solidity theme={null}
function getDeployId(
bytes32 _debridgeId,
string _name,
string _symbol,
uint8 _decimals
) public returns (bytes32)
```
Calculates asset identifier for deployment.
**Parameters:**
| Name | Type | Description |
| ------------- | --------- | ---------------------------------- |
| `_debridgeId` | `bytes32` | Id of an asset, see getDebridgeId. |
| `_name` | `string` | Asset's name. |
| `_symbol` | `string` | Asset's symbol. |
| `_decimals` | `uint8` | Asset's decimals. |
### getChainId
```solidity theme={null}
function getChainId() public returns (uint256 cid)
```
Get current chain id.
### version
```solidity theme={null}
function version() external returns (uint256)
```
Get this contract's version.
# DeBridgeTokenDeployer
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/transfers/DeBridgeTokenDeployer
DeBridgeTokenDeployer contract details - fields, functions, and structs.
Deploys a deToken (DeBridgeTokenProxy) for an asset.
***
## Variables
### tokenImplementation
```solidity theme={null}
address public tokenImplementation;
```
Address of deBridgeToken implementation
### deBridgeTokenAdmin
```solidity theme={null}
address public deBridgeTokenAdmin;
```
An address to set as admin for any deployed deBridgeToken
### debridgeAddress
```solidity theme={null}
address public debridgeAddress;
```
Debridge gate address
### getDeployedAssetAddress
```solidity theme={null}
mapping(bytes32 => address) public getDeployedAssetAddress;
```
Maps debridge id to deBridgeToken address
### overridedTokens
```solidity theme={null}
mapping(bytes32 => struct DeBridgeTokenDeployer.OverridedTokenInfo) public overridedTokens;
```
Maps debridge id to overridden token info (name, symbol). Used when autogenerated values are not ideal.
***
## Functions
### initialize
```solidity theme={null}
function initialize(
address _tokenImplementation,
address _deBridgeTokenAdmin,
address _debridgeAddress
) public
```
Constructor that initializes the most important configurations.
#### Parameters:
| Name | Type | Description |
| --------------------- | ------- | ----------------------------------------- |
| \_tokenImplementation | address | Address of deBridgeToken implementation |
| \_deBridgeTokenAdmin | address | Address to set as admin for deBridgeToken |
| \_debridgeAddress | address | DeBridge gate address |
***
### deployAsset
```solidity theme={null}
function deployAsset(
bytes32 _debridgeId,
string _name,
string _symbol,
uint8 _decimals
) external returns (address deBridgeTokenAddress)
```
Deploy a deToken for an asset
#### Parameters:
| Name | Type | Description |
| ------------ | ------- | ---------------- |
| \_debridgeId | bytes32 | Asset identifier |
| \_name | string | Asset name |
| \_symbol | string | Asset symbol |
| \_decimals | uint8 | Asset decimals |
***
### implementation
```solidity theme={null}
function implementation() public returns (address)
```
Beacon getter for the deBridgeToken contracts
***
### setTokenImplementation
```solidity theme={null}
function setTokenImplementation(
address _impl
) external
```
Set deBridgeToken implementation contract address
#### Parameters:
| Name | Type | Description |
| ------ | ------- | --------------------------------------------- |
| \_impl | address | Wrapped asset implementation contract address |
***
### setDeBridgeTokenAdmin
```solidity theme={null}
function setDeBridgeTokenAdmin(
address _deBridgeTokenAdmin
) external
```
Set admin for any deployed deBridgeToken.
#### Parameters:
| Name | Type | Description |
| -------------------- | ------- | -------------- |
| \_deBridgeTokenAdmin | address | Admin address. |
***
### setDebridgeAddress
```solidity theme={null}
function setDebridgeAddress(
address _debridgeAddress
) external
```
Sets core debridge contract address.
#### Parameters:
| Name | Type | Description |
| ----------------- | ------- | ----------------- |
| \_debridgeAddress | address | Debridge address. |
***
### setOverridedTokenInfo
```solidity theme={null}
function setOverridedTokenInfo(
bytes32[] _debridgeIds,
struct DeBridgeTokenDeployer.OverridedTokenInfo[] _tokens
) external
```
Override specific tokens name/symbol
#### Parameters:
| Name | Type | Description |
| ------------- | -------------------------------------------------- | ------------------------------------ |
| \_debridgeIds | bytes32\[] | Array of debridgeIds for tokens |
| \_tokens | struct DeBridgeTokenDeployer.OverridedTokenInfo\[] | Array of new name/symbols for tokens |
***
### version
```solidity theme={null}
function version() external returns (uint256)
```
Get this contract's version
***
## Structs
### OverridedTokenInfo
```solidity theme={null}
struct OverridedTokenInfo {
bool accept;
string name;
string symbol;
}
```
# OraclesManager
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/transfers/OraclesManager
OraclesManager contract details - fields and functions.
The base contract for oracles management. Allows adding/removing oracles, managing the minimal required amount of confirmations.
***
## Variables
### minConfirmations
```solidity theme={null}
uint8 public minConfirmations;
```
Minimal required confirmations
### excessConfirmations
```solidity theme={null}
uint8 public excessConfirmations;
```
Minimal required confirmations in case of too many confirmations
### requiredOraclesCount
```solidity theme={null}
uint8 public requiredOraclesCount;
```
Count of required oracles
### oracleAddresses
```solidity theme={null}
address[] public oracleAddresses;
```
Oracle addresses
### getOracleInfo
```solidity theme={null}
mapping(address => struct IOraclesManager.OracleInfo) public getOracleInfo;
```
Maps an oracle address to the oracle details
***
## Functions
### initialize
```solidity theme={null}
function initialize(
uint8 _minConfirmations,
uint8 _excessConfirmations
) internal
```
Constructor that initializes the most important configurations.
#### Parameters:
| Name | Type | Description |
| --------------------- | ----- | ------------------------------------------------------- |
| \_minConfirmations | uint8 | Minimal required confirmations. |
| \_excessConfirmations | uint8 | Minimal confirmations in case of too many confirmations |
***
### setMinConfirmations
```solidity theme={null}
function setMinConfirmations(
uint8 _minConfirmations
) external
```
Sets minimal required confirmations.
#### Parameters:
| Name | Type | Description |
| ------------------ | ----- | ------------------------------- |
| \_minConfirmations | uint8 | Minimal required confirmations. |
***
### setExcessConfirmations
```solidity theme={null}
function setExcessConfirmations(
uint8 _excessConfirmations
) external
```
Sets minimal required confirmations in case of too many confirmations.
#### Parameters:
| Name | Type | Description |
| --------------------- | ----- | ------------------------------------------------------- |
| \_excessConfirmations | uint8 | Minimal confirmations in case of too many confirmations |
***
### addOracles
```solidity theme={null}
function addOracles(
address[] _oracles,
bool[] _required
) external
```
Add oracles.
#### Parameters:
| Name | Type | Description |
| ---------- | ---------- | ------------------------------------------------------------------------- |
| \_oracles | address\[] | Oracles' addresses. |
| \_required | bool\[] | A transfer will not be confirmed without oracles having required set true |
***
### updateOracle
```solidity theme={null}
function updateOracle(
address _oracle,
bool _isValid,
bool _required
) external
```
Update an oracle.
#### Parameters:
| Name | Type | Description |
| ---------- | ------- | -------------------------------------------------------------- |
| \_oracle | address | An oracle address. |
| \_isValid | bool | Is this oracle valid (i.e. should it be treated as an oracle)? |
| \_required | bool | If true, a transfer will not be confirmed without this oracle. |
# SignatureVerifier
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/transfers/SignatureVerifier
SignatureVerifier contract details - fields and functions.
Used to verify that a transfer is signed by oracles.
***
## Variables
### confirmationThreshold
```solidity theme={null}
uint8 public confirmationThreshold;
```
Number of required confirmations per block after the extra check is enabled
### submissionsInBlock
```solidity theme={null}
uint40 public submissionsInBlock;
```
Submissions count in current block
### currentBlock
```solidity theme={null}
uint40 public currentBlock;
```
Current block
### debridgeAddress
```solidity theme={null}
address public debridgeAddress;
```
Debridge gate address
***
## Functions
### initialize
```solidity theme={null}
function initialize(
uint8 _minConfirmations,
uint8 _confirmationThreshold,
uint8 _excessConfirmations
) public
```
Constructor that initializes the most important configurations.
#### Parameters:
| Name | Type | Description |
| ----------------------- | ----- | ---------------------------------------------------- |
| \_minConfirmations | uint8 | Common confirmations count. |
| \_confirmationThreshold | uint8 | Confirmations per block after extra check is enabled |
| \_excessConfirmations | uint8 | Confirmations count in case of excess activity |
***
### submit
```solidity theme={null}
function submit(
bytes32 _submissionId,
bytes _signatures,
uint8 _excessConfirmations
) external
```
Check confirmation (validate signatures) for the transfer request.
#### Parameters:
| Name | Type | Description |
| --------------------- | ------- | -------------------------------- |
| \_submissionId | bytes32 | Submission identifier. |
| \_signatures | bytes | Array of signatures by oracles. |
| \_excessConfirmations | uint8 | Override min confirmations count |
***
### setThreshold
```solidity theme={null}
function setThreshold(
uint8 _confirmationThreshold
) external
```
Sets minimal required confirmations.
#### Parameters:
| Name | Type | Description |
| ----------------------- | ----- | ------------------ |
| \_confirmationThreshold | uint8 | Confirmation info. |
***
### setDebridgeAddress
```solidity theme={null}
function setDebridgeAddress(
address _debridgeAddress
) external
```
Sets core debridge contract address.
#### Parameters:
| Name | Type | Description |
| ----------------- | ------- | ----------------- |
| \_debridgeAddress | address | Debridge address. |
***
### isValidSignature
```solidity theme={null}
function isValidSignature(
bytes32 _submissionId,
bytes _signature
) external returns (bool)
```
Check is valid signature
#### Parameters:
| Name | Type | Description |
| -------------- | ------- | ---------------------- |
| \_submissionId | bytes32 | Submission identifier. |
| \_signature | bytes | Signature by oracle. |
***
### \_countSignatures
```solidity theme={null}
function _countSignatures(
bytes _signatures
) internal returns (uint256)
```
***
### version
```solidity theme={null}
function version() external returns (uint256)
```
Get this contract's version
# WethGate
Source: https://docs.debridge.com/dmp-details/dev-guides/evm/transfers/WethGate
WethGate contract details - fields, functions, and events.
Upgradable contracts cannot receive ether via `transfer` because of increased `SLOAD` gas cost. We use this non-upgradeable contract as the recipient
and then immediately transfer to an upgradable contract. More details about this issue can be found
[here](https://forum.openzeppelin.com/t/openzeppelin-upgradeable-contracts-affected-by-istanbul-hardfork/1616).
***
## Variables
### weth
```solidity theme={null}
contract IWETH public weth;
```
Wrapped native token contract
***
## Functions
### constructor
```solidity theme={null}
function constructor(
contract IWETH _weth
) public
```
### withdraw
```solidity theme={null}
function withdraw(
address receiver,
uint256 wad
) external
```
Transfer assets to a receiver.
#### Parameters:
| Name | Type | Description |
| -------- | ------- | ------------------------------------ |
| receiver | address | This address will receive a transfer |
| wad | uint256 | Amount in wei |
***
### \_safeTransferETH
```solidity theme={null}
function _safeTransferETH(
address _to,
uint256 _value
) internal
```
### receive
```solidity theme={null}
function receive() external
```
### version
```solidity theme={null}
function version() external returns (uint256)
```
Get this contract's version
***
## Events
### Withdrawal
```solidity theme={null}
event Withdrawal(
address receiver,
uint256 wad
)
```
Emitted when any amount is withdrawn.
# Gathering Data for the Claim
Source: https://docs.debridge.com/dmp-details/dev-guides/gathering-data-for-claim
Data sources and steps required to build a claim transaction.
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](https://github.com/debridge-finance/desdk#tracking-and-executing-claims), 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
Se`nt 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:
![Gathering Data for Claims]()
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.
# Off-Chain External Call Preparation
Source: https://docs.debridge.com/dmp-details/dev-guides/solana/off-chain-external-call-preparation
How to serialize and assemble off-chain external call data for Solana.
Instructions should be serialized one by one, final calldata is a concatenation of separately serialized instructions.
For the info about the rewards, substitutions, and expenses check the previous section.
Solana's `TransactionInstructions` could be serialized into calldata format using
[`@debridge-finance/debridge-external-call`](https://www.npmjs.com/package/@debridge-finance/debridge-external-call) npm package:
```typescript theme={null}
import * as wasm from "@debridge-finance/debridge-external-call";
import { PublicKey, TransactionInstruction } from "@solana/web3.js";
/**
* Substitutes amount at offset with `walletBalance(accounts[account_index]) - subtraction`
*/
type AmountSubstitution = {
/**
* big or little endian
*/
is_big_endian: boolean;
/**
* At what offset substitution should be done
*/
offset: number;
/**
* index of account in TransactionInstruction.keys to get balance for
*/
account_index: number;
/**
* Amount to deduct from wallet balance
*/
subtraction: number;
};
/**
* Since we don't know submissionAuth at the moment of calldata preparation we can prepare substitution to replace
* account at `index` with actual ATA(submissionAuth, tokenMint) during execution
*/
type WalletSubstitution = {
/**
* Token mint to calculate ATA for
*/
token_mint: string;
/**
* Account at this index will be replaced with ATA(submissionAuth, tokenMint) during execution
*/
index: number;
};
/**
* Structure required by wasm module
*/
interface IExtIx {
keys: {
pubkey: string;
isSigner: boolean;
isWritable: boolean;
}[];
data: Buffer;
programId: string;
}
function ixToIExtIx(ix: TransactionInstruction): IExtIx {
return {
keys: ix.keys.map((meta) => ({
pubkey: meta.pubkey.toBase58(),
isSigner: meta.isSigner,
isWritable: meta.isWritable,
})),
programId: ix.programId.toBase58(),
data: ix.data,
};
}
function serialize(
instruction: TransactionInstruction,
substitutions?: {
amountSubstitutions?: AmountSubstitution[];
walletSubstitutions?: WalletSubstitution[];
},
expense?: bigint,
reward?: bigint,
isInMandatoryBlock: boolean = false,
) {
const ixWrapper = new wasm.ExternalInstructionWrapper(
reward,
expense,
isInMandatoryBlock,
substitutions?.amountSubstitutions ?? [],
substitutions?.walletSubstitutions ?? [],
ixToIExtIx(instruction),
);
return ixWrapper.serialize();
}
const ix1: TransactionInstruction;
const ix2: TransactionInstruction;
const serializedIx1 = serialize(ix1, undefined, 1000n);
const serializedIx2 = serialize(ix2, undefined, 2000n);
const calldata = Buffer.concat([serializedIx1, serializedIx2 /** rest serialized instructions if any */]);
```
# On-Chain External Call Preparation
Source: https://docs.debridge.com/dmp-details/dev-guides/solana/on-chain-external-call-preparation
On-Chain External Call Preparation: Pubkey placeholders, Instruction, and Expenses.
Preparing an extcall to call programs on Solana is simple:
# Instruction
Identify the Instruction-s you need to call in Solana. For example, the following Instruction
```solidity theme={null}
Instruction {
// Constant
// 0x8c97258f4e2489f1bb3d1029148e0d830b5a1399daff1084048e7bd8dbe9f859
program_id: Pubkey::from_str("ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL").unwrap(),
accounts: vec![
// Pubkey Auth Placeholder, constant
AccountMeta {
// 0x1968562fef0aab1b1d8f99d44306595cd4ba41d7cc899c007a774d23ad702ff6
pubkey: Pubkey::from_str("2iBUASRfDHgEkuZ91Lvos5NxwnmiryHrNbWBfEVqHRQZ")
.unwrap(),
is_signer: true,
is_writable: true,
},
// Can be any - not important, will be replaced by substituion later
AccountMeta {
// 0x9f3d96f657370bf1dbb3313efba51ea7a08296ac33d77b949e1b62d538db37f2
pubkey: Pubkey::from_str("BicJ4dmuWD3bfBrJyKKeqzczWDSGUepUpaKWmC6XRoJZ")
.unwrap(),
is_signer: false,
is_writable: true,
},
],
// Constant
data: vec![1],
}
```
can be represented in Solidity as follows:
```solidity theme={null}
DeBridgeSolana.AccountMeta[] memory accountMetas = new DeBridgeSolana.AccountMeta[](2);
accountMetas[0] = DeBridgeSolana.AccountMeta({
// 2iBUASRfDHgEkuZ91Lvos5NxwnmiryHrNbWBfEVqHRQZ
pubkey: 0x1968562fef0aab1b1d8f99d44306595cd4ba41d7cc899c007a774d23ad702ff6,
is_signer: true,
is_writable: true
});
accountMetas[1] = DeBridgeSolana.AccountMeta({
// BicJ4dmuWD3bfBrJyKKeqzczWDSGUepUpaKWmC6XRoJZ
pubkey: 0x9f3d96f657370bf1dbb3313efba51ea7a08296ac33d77b949e1b62d538db37f2,
is_signer: false,
is_writable: true
});
DeBridgeSolana.ExternalInstruction memory externalInstruction = DeBridgeSolana.ExternalInstruction({
// [...]
instruction: DeBridgeSolana.Instruction({
// ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL
program_id: 0x8c97258f4e2489f1bb3d1029148e0d830b5a1399daff1084048e7bd8dbe9f859,
accounts: accountMetas,
data: hex"1"
})
});
```
# Expenses
Determine how much lamports your instruction spends on the destination network (most often, for account creation). Record this value as expenses. Each
instruction is technically worth 5000 lamports (since we can't determine how many resources it will spend in advance, the implication is that it can
be executed in a separate transaction). Therefore, 5000 + expenses is the estimate of how much lamports will cost the execution.
```solidity theme={null}
DeBridgeSolana.ExternalInstruction memory externalInstruction = DeBridgeSolana.ExternalInstruction({
// [...]
expense: 5000,
});
```
# Pubkey substituion
Determine which accounts in the instruction are input-dependent and cannot be passed directly from the user for security reasons.
For example, if there is a PDA in the destination network that depends on some unique transfer identifier, then we need to form `PubkeySubstitutions`.
This gives the following Solidity code:
```solidity theme={null}
bytes[] memory seeds = new bytes[](3);
seeds[0] = DeBridgeSolanaPubkeySubstitutions.getSubmissionAuthSeed();
seeds[1] = DeBridgeSolanaPubkeySubstitutions.getArbitrarySeed(
abi.encodePacked(bytes32(tokenId)) // input parameter
);
seeds[2] = DeBridgeSolanaPubkeySubstitutions.getArbitrarySeed(
abi.encodePacked(bytes32(splNativeMint)) // input parameter
);
DeBridgeSolana.PubkeySubstitutionTuple[] memory pubkeySubstitutions = new DeBridgeSolana.PubkeySubstitutionTuple[](1);
pubkeySubstitutions[0] = DeBridgeSolana.PubkeySubstitutionTuple({
u64: 1,
data: DeBridgeSolanaPubkeySubstitutions.serialize(
DeBridgeSolanaPubkeySubstitutions.BySeeds({
program_id: ASSOCIATED_TOKEN_PROGRAM, // input parameter
seeds: seeds,
bump: 0 // None
})
)
});
DeBridgeSolana.ExternalInstruction memory externalInstruction = DeBridgeSolana.ExternalInstruction({
// [...]
pubkey_substitutions: pubkeySubstitutions
});
```
If the user can't break protocol rules by passing any Pubkey, then you can take that key directly from the user's input and you don't need substitution.
## Pubkey placeholders
As well as pubkey substitutions, placeholders could be used to substitute extcall accounts, but placeholders can't be used to calculate ATA during extcall execution. At the moment we have following placeholders:
* **Wallet Placeholder** : `J4vKrc4pCdtiHpxFDfBy4iyZ22Uf7fBjJyJ817k4673y` - if you set this pubkey to some account, it will be replaced by actual
Submission Wallet during execution. Submission wallet is a [token
account](https://github.com/solana-labs/solana-program-library/blob/523156a0cdd9cada27036bd72d326bc40c00f85f/token/program/src/state.rs#L83-L106)
that contains transferred tokens during execution.
* **Submission Placehoder** : `7cu34CRu47UZKLRHjt9kFPhuoYyHCzAafGiGWz83GNFs` will be replaced by [Submission
account](https://github.com/debridge-finance/debridge-solana-sdk/blob/5c3f5149504daddab38d5383ae6c8c15efb4235c/src/debridge_accounts.rs#L59-L79)
during execution. Submission account contains transfer metadata such as native sender, send from chain, etc.
* **Authority Placeholder** : `2iBUASRfDHgEkuZ91Lvos5NxwnmiryHrNbWBfEVqHRQZ` will be replaced by Submission Authority account during execution.
Submission authority is an owner/authority account for Submission Wallet. It is this account that manages [On-Chain external call preparation for
Solana](/dmp-details/dev-guides/solana/on-chain-external-call-preparation#expenses).
If both placeholder and substitution are used for the same account, only substitution will be performed.
# DataSubstitution
If you need a transfer amount as part of your transfer and it cannot be calculated in advance, then you must use `DataSubstitution`. One substitution is
now available (`SubmissionAuthWalletAmount`) which works as follows. Takes the `account_index` account of the current instruction, interprets it as a
token account, takes its balance, chooses its encoding (big endian, little endian), use `substration` and inserts it into the current instruction by
`offset` before calling it.
```solidity theme={null}
// use DeBridgeSolanaDataSubstitutions to generate data substutions
DeBridgeSolana.DataSubstitution[] memory dataSubstitutions =
new DeBridgeSolana.DataSubstitution[](0);
DeBridgeSolana.ExternalInstruction memory externalInstruction = DeBridgeSolana.ExternalInstruction({
// [...]
data_substitutions: dataSubstitutions
});
```
This way you can transfer the whole wallet balance except for some part of it (e.g. for the next transfers).
# Reward
The last step is to set the reward. Since for almost any transfer it will depend on the difference between the price of the fee and the price of SOL
asset, it will almost always be reported externally. The reward should cover 5000 lamports and all expenses. In the execution phase, the executor
evaluates the 5000 + expenses in the translation token and if the reward covers the execution, then it executes the translation.
```solidity theme={null}
DeBridgeSolana.ExternalInstruction memory externalInstruction = DeBridgeSolana.ExternalInstruction({
// [...]
reward: 5000
});
```
# Final
This algorithm should be done for each instruction in your extcall. The total instruction set must be less than 10 kilobytes.
When you have prepared all the necessary instructions, you need to generate a binary buffer and send it through deBridge as external call:
```solidity theme={null}
DeBridgeSolana.ExternalInstruction memory externalInstruction = DeBridgeSolana.ExternalInstruction({
// [...]
});
// or import the lib: using DeBridgeSolanaSerializer for DeBridgeSolana.ExternalInstruction;
DeBridgeSolanaSerializer.serialize(externalInstruction);
```
# Sending Cross-Chain Messages
Source: https://docs.debridge.com/dmp-details/dev-guides/solana/sending-cross-chain-messages
Sending cross-chain messages from Solana using deBridge programs.
To streamline communication with deBridge programs on the Solana blockchain, the debridge-solana-sdk has been developed. This Rust SDK allows for easy and efficient connection to the deBridge infrastructure, which enables decentralized transfers of messages and value between different supported blockchains.
To start using our sdk, add it to dependencies by cargo:
```shell theme={null}
cargo add debridge-solana-sdk
```
If you use the Anchor framework, then your program calling for a deBridge send might look like this:
```rust theme={null}
use anchor_lang::prelude::*;
declare_id!("3botMWU4s1Lcs4Q2wQBkZqsCW1vc3N9H9tY9SZYVs5vZ");
#[program]
pub mod send_via_debridge {
use debridge_solana_sdk::prelude::*;
use super::*;
pub fn send_via_debridge(ctx: Context) -> Result<()> {
invoke_debridge_send(
// Debridge Instruction Data
SendIx {
// Chain id to which the tokens are sent
target_chain_id: chain_ids::POLYGON_CHAIN_ID,
/// Address in `target_chain_id` that will receive the transferred tokens
receiver: hex::decode("bd1e72155Ce24E57D0A026e0F7420D6559A7e651").unwrap(),
// Use of fee in transfer token (not currently enabled)
is_use_asset_fee: false,
// Amount of sending tokens. From this amount fee will be taken
amount: 1000,
// Additional data for tokens sending with auto external execution
submission_params: None,
// Referral code to track your transfers
referral_code: None,
},
// List of accounts used by debridge-program, generated on the client
ctx.remaining_accounts,
)
.map_err(|err| err.into())
}
}
#[derive(Accounts)]
pub struct SendViaDebridge {}
```
You can use any account in your logic. However, the remaining accounts you pass on will have to be created by the client. Our SDK provides an
[example](https://github.com/debridge-finance/debridge-solana-sdk/tree/master/example-program/ts-examples) of how to use the TypeScript library. For
this example it is:
```ts theme={null}
import { DeBridgeSolanaClient } from "@debridge-finance/solana-contracts-client";
import { AnchorProvider, Program, Wallet as AnchorWallet } from "@coral-xyz/anchor";
import { Connection, clusterApiUrl } from "@solana/web3.js";
import { crypto, helpers, WRAPPED_SOL_MINT } from "@debridge-finance/solana-utils";
const connection = new Connection(clusterApiUrl("mainnet-beta"));
const example = new Program(
ExampleIDL,
"3botMWU4s1Lcs4Q2wQBkZqsCW1vc3N9H9tY9SZYVs5vZ",
new AnchorProvider(connection, {} as unknown as AnchorWallet, {}),
);
const deBridge = new DeBridgeSolanaClient(connection, undefined, {
programId: "DEbrdGj3HsRsAzx6uH4MKyREKxVAfBydijLUF3ygsFfh",
settingsProgramId: "DeSetTwWhjZq6Pz9Kfdo1KoS5NqtsM6G8ERbX4SSCSft",
});
const chainTo = 137;
const receiver = "0xbd1e72155Ce24E57D0A026e0F7420D6559A7e651";
const amount = 1000;
const tokenMint = WRAPPED_SOL_MINT;
const builder = example.methods.sendViaDebridge(
amount,
Array.from(crypto.normalizeChainId(chainTo)),
helpers.hexToBuffer(receiver),
false,
);
const context = await deBridge.buildSendContext(
sender,
null,
tokenMint,
receiver,
chainTo,
false,
receiver,
);
builder.remainingAccounts([...context.asAccountMeta, { isWritable: false, isSigner: false, pubkey: deBridge.program.programId }]);
const tx = await builder.transaction();
```
The dependency packages that are used:
* [@debridge-finance/solana-contracts-client](https://www.npmjs.com/package/@debridge-finance/solana-contracts-client)
* [@debridge-finance/solana-utils](https://www.npmjs.com/package/@debridge-finance/solana-utils)
* [@coral-xyz/anchor](https://www.npmjs.com/package/@coral-xyz/anchor)
* [@solana/web3.js](https://www.npmjs.com/package/@solana/web3.js)
For detailed examples, within the SDK there is an
[example-program](https://github.com/debridge-finance/debridge-solana-sdk/tree/master/example-program) project that allows you to see examples of
various integrations and the corresponding client code for them. For example:
* [send\_via\_debridge](https://github.com/debridge-finance/debridge-solana-sdk/blob/7bb2ed38a135d3550dadfd00bdc78f50c19a701d/example-program/programs/debridge-solana-sdk-example/src/lib.rs#L38)
* [send\_via\_debridge\_with\_native\_fixed\_fee](https://github.com/debridge-finance/debridge-solana-sdk/blob/7bb2ed38a135d3550dadfd00bdc78f50c19a701d/example-program/programs/debridge-solana-sdk-example/src/lib.rs#L69)
* [send\_via\_debridge\_with\_exact\_amount](https://github.com/debridge-finance/debridge-solana-sdk/blob/7bb2ed38a135d3550dadfd00bdc78f50c19a701d/example-program/programs/debridge-solana-sdk-example/src/lib.rs#L140)
* [send\_via\_debridge\_with\_asset\_fixed\_fee](https://github.com/debridge-finance/debridge-solana-sdk/blob/7bb2ed38a135d3550dadfd00bdc78f50c19a701d/example-program/programs/debridge-solana-sdk-example/src/lib.rs#L69)
* [send\_via\_debridge\_with\_execution\_fee](https://github.com/debridge-finance/debridge-solana-sdk/blob/7bb2ed38a135d3550dadfd00bdc78f50c19a701d/example-program/programs/debridge-solana-sdk-example/src/lib.rs#L177)
* [send\_via\_debridge\_with\_external\_call](https://github.com/debridge-finance/debridge-solana-sdk/blob/7bb2ed38a135d3550dadfd00bdc78f50c19a701d/example-program/programs/debridge-solana-sdk-example/src/lib.rs#L211)
* [send\_message\_via\_debridge](https://github.com/debridge-finance/debridge-solana-sdk/blob/7bb2ed38a135d3550dadfd00bdc78f50c19a701d/example-program/programs/debridge-solana-sdk-example/src/lib.rs#L259)
* [check\_claiming](https://github.com/debridge-finance/debridge-solana-sdk/blob/7bb2ed38a135d3550dadfd00bdc78f50c19a701d/example-program/programs/debridge-solana-sdk-example/src/lib.rs#L371)
# Deployed Contracts
Source: https://docs.debridge.com/dmp-details/dmp/deployed-contracts
Deployed contracts for deBridge Messaging Protocol (DMP).
## deBridge IaaS Subscription
### Proxy & Implementation
| **Label** | **Address** |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------- |
| `Proxy` | [`0x2328Ee20fA271073328DC94e52Dd5b61aa0C91A7`](https://etherscan.io/address/0x2328Ee20fA271073328DC94e52Dd5b61aa0C91A7) |
| `Implementation` | [`0xf46b9e22a2a5B07bd2F601d9A59b4E01424f5E35`](https://etherscan.io/address/0xf46b9e22a2a5B07bd2F601d9A59b4E01424f5E35) |
## deBridge Messaging Protocol (DMP)
For deBridge Liquidity Network (DLN) contracts, please refer to [this article](/dln-details/overview/deployed-contracts).
### Solana
| **Smart Contract** | **Address** | **Description** |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `deBridge` | [`DEbrdGj3HsRsAzx6uH4MKyREKxVAfBydijLUF3ygsFfh`](https://solscan.io/account/DEbrdGj3HsRsAzx6uH4MKyREKxVAfBydijLUF3ygsFfh) | This contract is the main point of cross-chain interactions coming from users and protocols. It enables sending and execution of cross-chain messages. |
| `deBridge Settings` | [`DeSetTwWhjZq6Pz9Kfdo1KoS5NqtsM6G8ERbX4SSCSft`](https://solscan.io/account/DeSetTwWhjZq6Pz9Kfdo1KoS5NqtsM6G8ERbX4SSCSft) | Settings program stores validators' signatures and controls all protocols parameters such as fees, consensus algorithms, validators' public keys. |
### EVM
| | DeBridgeGate | DeBridgeToken | DeBridgeTokenDeployer | SignatureVerifier | CallProxy | WethGate |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Description** | Main entry point for cross-chain interactions; `send` moves messages + assets | Wrapped asset (deAsset) 1 : 1 collateral-backed | Factory that deploys new deAssets | Validates ≥ 2⁄3 validator signatures before execution | Executes the external call that accompanies a transferred message | Non-upgradeable Ether receiver that immediately forwards funds to an upgradeable contract, avoiding the `transfer` gas-limit issue(\[docs.debridge.com]\[1]) |
| **Github** | [LINK](https://github.com/debridge-finance/debridge-contracts-v1/blob/main/contracts/transfers/DeBridgeGate.sol) | [LINK](https://github.com/debridge-finance/debridge-contracts-v1/blob/main/contracts/periphery/DeBridgeToken.sol) | [LINK](https://github.com/debridge-finance/debridge-contracts-v1/blob/main/contracts/transfers/DeBridgeTokenDeployer.sol) | [LINK](https://github.com/debridge-finance/debridge-contracts-v1/blob/main/contracts/transfers/SignatureVerifier.sol) | [LINK](https://github.com/debridge-finance/debridge-contracts-v1/blob/main/contracts/periphery/CallProxy.sol) | [LINK](https://github.com/debridge-finance/debridge-contracts-v1/blob/main/contracts/transfers/WethGate.sol) |
| **Chain** | | | | | | |
| Ethereum | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://etherscan.io/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xf8A2902c0a5f817F5e22C82f453538d3f0734C2b](https://etherscan.io/address/0xf8A2902c0a5f817F5e22C82f453538d3f0734C2b) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://etherscan.io/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://etherscan.io/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://etherscan.io/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824) | [0xFCf83648b8cDeF62e5d03319a6f1FCE16e4D6A59](https://etherscan.io/address/0xFCf83648b8cDeF62e5d03319a6f1FCE16e4D6A59#code) |
| BNB Chain | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://bscscan.com/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xf8A2902c0a5f817F5e22C82f453538d3f0734C2b](https://bscscan.com/address/0xf8A2902c0a5f817F5e22C82f453538d3f0734C2b) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://bscscan.com/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://bscscan.com/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://bscscan.com/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824#code) | [0xFCf83648b8cDeF62e5d03319a6f1FCE16e4D6A59](https://bscscan.com/address/0xFCf83648b8cDeF62e5d03319a6f1FCE16e4D6A59#code) |
| Polygon | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://polygonscan.com/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xf8A2902c0a5f817F5e22C82f453538d3f0734C2b](https://polygonscan.com/address/0xf8A2902c0a5f817F5e22C82f453538d3f0734C2b) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://polygonscan.com/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://polygonscan.com/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://polygonscan.com/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA#code) | [0xFCf83648b8cDeF62e5d03319a6f1FCE16e4D6A59](https://polygonscan.com/address/0xFCf83648b8cDeF62e5d03319a6f1FCE16e4D6A59#code) |
| Robinhood | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://robinhoodchain.blockscout.com/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF](https://robinhoodchain.blockscout.com/address/0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://robinhoodchain.blockscout.com/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://robinhoodchain.blockscout.com/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://robinhoodchain.blockscout.com/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824) | |
| Arbitrum | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://arbiscan.io/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xf8A2902c0a5f817F5e22C82f453538d3f0734C2b](https://arbiscan.io/address/0xf8A2902c0a5f817F5e22C82f453538d3f0734C2b) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://arbiscan.io/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://arbiscan.io/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://arbiscan.io/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824#code) | |
| Avalanche | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://snowtrace.io/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF](https://snowtrace.io/address/0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://snowtrace.io/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://snowtrace.io/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://snowtrace.io/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824#code) | [0xFCf83648b8cDeF62e5d03319a6f1FCE16e4D6A59](https://snowtrace.io/address/0xFCf83648b8cDeF62e5d03319a6f1FCE16e4D6A59#code) |
| Linea | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://lineascan.build/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0x55C93b20Dd2F790AC429D6341a022A781791654A](https://lineascan.build/address/0x55C93b20Dd2F790AC429D6341a022A781791654A) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://lineascan.build/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://lineascan.build/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://lineascan.build/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824) | |
| Base | [0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF](https://basescan.org/address/0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF) | [0x0e4AdD4DC86Ae1Aa0FA43Bd7e6a9fB8Be2d5504d](https://basescan.org/address/0x0e4AdD4DC86Ae1Aa0FA43Bd7e6a9fB8Be2d5504d) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://basescan.org/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://basescan.org/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://basescan.org/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824) | |
| Optimism | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://optimistic.etherscan.io/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF](https://optimistic.etherscan.io/address/0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://optimistic.etherscan.io/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://optimistic.etherscan.io/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://optimistic.etherscan.io/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824) | |
| Story | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://internal.storyscan.xyz/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF](https://internal.storyscan.xyz/address/0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://internal.storyscan.xyz/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://internal.storyscan.xyz/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://internal.storyscan.xyz/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824) | |
| Cronos | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://explorer.cronos.org/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF](https://explorer.cronos.org/address/0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://explorer.cronos.org/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://explorer.cronos.org/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://explorer.cronos.org/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824) | - |
| HyperEVM | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://hyperevmscan.io/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF](https://hyperevmscan.io/address/0xc1656b63d9eeba6d114f6be19565177893e5bcbf) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://hyperevmscan.io/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://hyperevmscan.io/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0c79f5532f3b2a16ad1e4282a5daf81928a824](https://hyperevmscan.io/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824) | |
| Injective | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://blockscout.injective.network/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF](https://blockscout.injective.network/address/0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://blockscout.injective.network/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://blockscout.injective.network/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://blockscout.injective.network/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824) | - |
| Monad | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://monadvision.com/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF](https://monadvision.com/address/0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://monadvision.com/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://monadvision.com/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://monadvision.com/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824) | - |
| MegaETH | [0x43dE2d77BF8027e25dBD179B491e8d64f38398aA](https://mega.etherscan.io/address/0x43dE2d77BF8027e25dBD179B491e8d64f38398aA) | [0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF](https://mega.etherscan.io/address/0xc1656B63D9EEBa6d114f6bE19565177893e5bCBF) | [0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464](https://mega.etherscan.io/address/0x8244d6Ffe0695B30b2bAD424683Ee3bc534Ea464) | [0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c](https://mega.etherscan.io/address/0x949b3B3c098348b879C9e4F15cecc8046d9C8A8c) | [0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824](https://mega.etherscan.io/address/0x8a0C79F5532f3b2a16AD1E4282A5DAF81928a824) | |
| TRON | [TTGA4XQ419jodtFSMFiwYqfgG2uSLRBsnn](https://tronscan.org/#/contract/TTGA4XQ419jodtFSMFiwYqfgG2uSLRBsnn/code) | [TGEUpEMV7AVZU6VBFrRQDysrHJEmVMYsf8](https://tronscan.org/#/contract/TGEUpEMV7AVZU6VBFrRQDysrHJEmVMYsf8/code) | [TCsNzzAxD5RxWFbVnvCtyc91GyrGxC4NWd](https://tronscan.org/#/contract/TCsNzzAxD5RxWFbVnvCtyc91GyrGxC4NWd/code) | [TKFK32GKQs8379yRtuMkAmVMQ3Xo6xR7KX](https://tronscan.org/#/contract/TKFK32GKQs8379yRtuMkAmVMQ3Xo6xR7KX/code) | [TUo8FfeP9XJdfB8zoH2nJGLi7CL2LJ1Lin](https://tronscan.org/#/contract/TUo8FfeP9XJdfB8zoH2nJGLi7CL2LJ1Lin/code) | - |
# Fees and Supported Chains
Source: https://docs.debridge.com/dmp-details/dmp/fees-supported-chains
Fees and Supported Chains: Current flat fee for messages sent from different chains.
deBridge takes a flat fee for each cross-chain message transfer, which users pay for decentralization and confidence since half of all fees will go as
a reward to [deBridge validators](https://app.debridge.com/validation-progress) who will be [financially
liable](/dmp-details/dmp/slashing-and-delegated-staking) for the proper operation of the protocol as liquid assets staked for them will act as protocol financial
guarantees.
The fee is paid in the blockchain's native (gas) token. For example, if the transfer is performed from the Ethereum chain, then the fixed ETH amount
will be deducted from the user's wallet towards the protocol treasury on Ethereum.
Fees paid for every sent message can be seen in [deBridge Explorer](https://app.debridge.com/explorer) or retrieved from the state of the
[`DebridgeGate` smart contract](/dmp-details/dev-guides/evm/building-evm-dapp).
deBridge flat fees can be changed by governance. Hence, for any on-chain interactions with deBridge, fees must not be hardcoded but queried
dynamically from the state of the `DebridgeGate` smart contract.
# Current flat fee for messages sent from different chains
| **Chain** | **Chain ID** | **Internal Chain ID** | **Message Transfer Fee** | **Block Finality** |
| --------- | ------------ | --------------------- | ------------------------ | ------------------ |
| Arbitrum | 42161 | 42161 | 0.001 ETH | 12 |
| Avalanche | 43114 | 43114 | 0.05 AVAX | 12 |
| BNB Chain | 56 | 56 | 0.005 BNB | 12 |
| Ethereum | 1 | 1 | 0.001 ETH | 12 |
| Polygon | 137 | 137 | 0.5 MATIC | 256 |
| Robinhood | 4663 | 4663 | 0.001 ETH | 12 |
| Solana | 7565164 | 7565164 | 0.015 SOL | Status Finalized |
| Linea | 59144 | 59144 | 0.001 ETH | 12 |
| Optimism | 10 | 10 | 0.001 ETH | 12 |
| Base | 8453 | 8453 | 0.001 ETH | 12 |
| Story | 1514 | 100000013 | 0.01 IP | 12 |
| Cronos | 25 | 100000019 | 15 CRO | 12 |
| HyperEVM | 999 | 100000022 | 0.05 WHYPE | 12 |
| TRON | 728126428 | 100000026 | 4 TRX | 20 |
| Injective | 1776 | 100000029 | 0.09 INJ | 64 |
| Monad | 143 | 100000030 | 2 MON | 12 |
| MegaETH | 4326 | 100000031 | 0.001 ETH | 12 |
# Protocol Overview
Source: https://docs.debridge.com/dmp-details/dmp/protocol-overview
Protocol Overview: Background, Protocol Structure, and Off-chain validation.
deBridge Messaging Protocol (DMP) is the underlying cross-chain messaging protocol that powers all deBridge products, including
the deBridge Liquidity Network (DLN). DMP enables arbitrary data transfer, cross-chain execution and authenticated messages,
allowing developers to build complex cross-chain applications beyond just value transfer.
If you're looking to build cross-chain swaps, onboarding flows, or multi-step DeFi actions, you likely want to use the
[deBridge Liquidity Network](/dln-details/overview/introduction).
# Background
For a long time, bridges were viewed only as value transfer protocols and custodians responsible for locking assets on the source
chain and issuing wrapped representations of the assets on the destination chain.
The deBridge protocol drastically expands the concept of traditional bridges by introducing generic cross-chain message transfers.
Now developers and builders can interconnect any smart contracts across different blockchains to perform transfers of data and
transaction calls (messages that contain instructions to be executed, or CALLDATA) together with the value transfer in the same
transaction.
This opens up endless opportunities to build complex cross-chain interactions, such as multi-chain applications, next-layer
protocols, automated cross-chain arbitraging services, object or NFT bridges, and more!
As a generic messaging protocol and a cross-chain interoperability infrastructure, deBridge can be used to build any arbitrary
cross-chain applications (deApps). Notable solutions built on top of deBridge are:
* [deBridge Liquidity Network](https://app.debridge.com/) (DLN) — a high-performance cross-chain value transfer infrastructure
built on deBridge with 0-TVL design (no liquidity pools).
* [dePort](https://app.debridge.com/deport) — a native bridge for assets that allows protocols to bridge tokens and create utility
for their synthetic representation (deTokens) in other chains.
Your application can be the next one and this documentation and tutorials will help to dive into the protocol infrastructure and
elaborate on questions you might face while building your integration with deBridge.
# Protocol Structure
The protocol consists of 2 key layers:
* Protocol layer — on-chain smart contracts deployed in every blockchain supported by deBridge
* Infrastructure layer — off-chain validation nodes operated by validators who are elected by the deBridge governance
![DMP Layers]()
*The protocol layer* is a set of on-chain smart contracts used for asset management, routing of cross-chain transactions,
cross-validation of validators' signatures, and reaching consensus among validators as the transaction is treated as valid only if
the minimum required threshold of validators' signatures is achieved. The governance manages the parameters of the smart
contracts, such as fees, supported chains, the whitelist of elected validators, validators payout ratio, and more.
The infrastructure layer is represented by a set of reputable validators who operate a deBridge node alongside full nodes of every
blockchain supported by the protocol.
# Off-chain validation
For all bridging protocols, it’s important to have a chain-agnostic design and make the protocol operation fully independent of
the uptime of all supported blockchains. In case of downtime in any underlying blockchains, the protocol should keep processing
the transactions for all other chains.
deBridge has taken a unique approach with an off-chain transaction validation mechanic where validators don’t need to broadcast
any transactions and bear gas costs. Every cross-chain transaction initiated through the deBridge smart contract is assigned a
unique hash (Submission Id). deBridge validators are tracking all transactions that pass through the smart contract of the
protocol and soon as the transaction achieves its finality, each validator is obliged to sign the Submission by its private key.
The resulting signature is saved into Arweave, a decentralized data availability layer. Any arbitrary user or keeper can collect
validator signatures from Arweave and pass them to the DebridgeGate smart contract in the target chain alongside all transaction
parameters. Based on the passed set of parameters, the deBridge smart contract will restore a unique hash of the transaction and
cross-validate its signatures from all designated validators. In case the minimum required number of signatures is valid, the
DebridgeGate smart contract delivers the message on the destination chain by executing its' call data.
With this design, even in the eventuality that some blockchains experience downtime, deBridge will still remain fully functional
and all transactions going to the paused chain will be processed as soon as it resumes operation.
# Transaction Finality Requirements
Due to the probabilistic finality model of most blockchains, before the message is validated by the deBridge infrastructure,
validators wait for the required number of block confirmations before signing its Submission Id. The number of required block
confirmations is based on the social consensus of transaction finality in each supported blockchain.
# Delegated Staking and Slashing
Validators play a crucial role in interoperability protocols since in addition to being infrastructure providers, they also secure
the protocol by validating all cross-chain transactions passing through the protocol. Validators work for and are elected by the
governance and should bear financial responsibility for the service they provide, assured through the risk of being slashed in
case of validating a non-existent transaction or failing to maintain infrastructure uptime. Anyone can help to secure the protocol
by becoming a delegator and staking assets (e.g. ETH, USDC) for validators’ collateral. Both validators and their delegators
receive part of the protocol fees as an economic incentive for helping to secure the protocol and maintain its infrastructure.
# How it works
deBridge is DeFi's internet of liquidity — a foundational layer that enables users and protocols to transport any arbitrary
messages or CALLDATA across different chains enabling the ability to create any cross-chain solutions, such as deSwap — value
transferring protocol built on top of deBridge.
![DMP Flow Simplified]()
The ability to pass arbitrary data opens up opportunities for true cross-chain composability of smart contracts and protocols that
can now interact with each other despite they live in different blockchain ecosystems. An example would be an algorithmic
stablecoin protocol on Ethereum that opens positions in perpetual markets protocol on Solana or Arbitrum in order to maintain the
peg of its asset.
deBridge allows the building of a new generation of cross-chain protocols and applications that haven’t been possible in the past.
Some of the use cases are:
* Cross-chain swaps
* Multi-chain governance
* Cross-chain lending
* Cross-chain yield farming
For more details, check out the dedicated deBridge Messaging Protocol section.
# Security
Source: https://docs.debridge.com/dmp-details/dmp/security
Information about deBridge security audit processes and bug bounty program
# Has deBridge been audited?
Yes, deBridge's smart contracts have been audited by [Halborn](https://halborn.com/), [Zokyo](https://www.zokyo.io/), [Ackee
Blockchain](https://ackeeblockchain.com/) and [Neodyme](https://neodyme.io/).
Security will always be deBridge's main priority and it is vital for the protocol to be reliable and secure at all times. It’s one of the main
components that will determine the future progression of cross-chain interoperability, and as such the deBridge team will maintain this as a main
focus area both before and after the protocol launch.
Some of our key focus areas and security strategies can be found in [this blog
post](https://blog.debridge.finance/10-strategies-for-cross-chain-security-8ed5f5879946).
# Third-party security audits
deBridge protocol and periphery modules passed more than 25+ security audits. A comprehensive list of audit reports can be found in the [deBridge
GitHub repository](https://github.com/debridge-finance/debridge-security).
# Immunefi bug bounty program
deBridge has presented a \$200,000 Bug Bounty Program on Immunefi.
This bug bounty program is focused on preventing:
* Loss of user funds locked (principal) by freezing or theft
* Loss of governance funds
* Theft of unclaimed assets
* Permanent freezing of unclaimed assets
* Smart contract fails to deliver promised returns
* Unauthorized minting of wrapped assets that will lead them to lose peg
A more detailed description can be found on the [Immunefi website](https://immunefi.com/bounty/debridge/).
# Slashing and Delegated Staking
Source: https://docs.debridge.com/dmp-details/dmp/slashing-and-delegated-staking
Slashing and Delegated Staking: Responsibility of Validators, Delegated Staking, and Fees Distribution.
![Slashing and Delegated Staking]()
Delegated staking and slashing mechanics act as a backbone of protocol security and prevent economic incentives for validators to get into collusion
and forge messages.
A DelegatedStaking smart contract is part of the deBridge protocol and implements slashing and delegated staking logic. Anyone (including validators
themselves) can delegate liquidity for validators which act as a financial guarantee of validators' fairness. There are two ways to attract liquidity
into collateral:
# Responsibility of Validators
The liquidity delegated to validators may be used for slashing in case validators validated forged or censored message. In this case, anyone who had a
financial loss due to validator misbehavior will be compensated by deBridge governance from the amount slashed from the validator's collateral.
Thus, in addition to reputational risks, validators are financially responsible for the proper operation of the protocol and its fault tolerance.
There are two ways how validators can attract liquidity into collateral:
* Validators stake their own liquidity into collateral
* Validators attract liquidity from delegators and share rewards paid by the protocol
# Delegated Staking
Any user/wallet can increase the collateral of any validator if they believe that this validator is reliable, knows how to manage infrastructure, and
won't incur any breakdowns and delays in the processing and validation of transactions.
The whitelist of assets that can be staked is managed by governance. Initially, onlyETH, USDT, USDC assets will be available for staking. Stablecoins
allow hedging collateral during periods of market volatility to avoid shrinking of total collateral USD value during the bear market stages.
If the user decides to unstake any amount of staked assets, a cooldown period of 14 days should pass from the time of the unstaking request to the
moment the user is able to claim their assets. Later on, the cooldown period for unstaking will be reduced to 7 days. The cooldown period is needed
for several reasons:
* To avoid front-running, so that users do not stake opportunistically for a short period of time to capitalize on rewards during periods of high
volumes
* To give governance a time to slash validator collateral before delegators unstake their liquidity. Governance can pause/renew new stakes/unstakes
and ongoing cooldowns for specific validators or delegators. Also in case of failure, delegators who initiated unstaking (had active cooldown)
before the timestamp of the incident will not be slashed
Delegators can also transfer the stake between validators with a cooldown period of 2 days. This cooldown period is shorter since in case the user
initiated a transfer after the failure of the original validator, governance will still be able to slash their stake even if it has already been
transferred to another validator. Governance has the power to slash the stake of the specific validator (including a stake of all delegators who
staked for them) or slash a specific delegator in case the delegator manages to transfer the stake to another validator before slashing occurs.
Once unstaking or transfer of stake has been initiated, the delegator stops receiving protocol rewards on the stake under the cooldown period.
# Fees Distribution
As described in the protocol overview, deBridge infrastructure applies a small fee for each message and value transfer. Half of these fees are
transferred to the deBridge treasury controlled by governance. Another half is converted into ETH and used as a payout to validators and their
delegators. Each payout is evenly distributed among all active validators.
Each validator assigns a portion of protocol payouts profitSharingBPS to be shared with delegators. These basis points allow the validator to control
the ratio between personal/attracted amounts of liquidity. Governance can set a minimum value of this parameter to avoid a situation when validators
with a low personal stake assign profitSharingBPS close to zero to receive all the protocol payouts and limit the collateral of the protocol.
Delegators receive a payout proportional to the USD equivalent of their stake in the validator's collateral pool. In order to perform the proper
distribution of protocol rewards and correctly calculate a USD value of the volatile assets, the smart contract utilizes the oracle price feed of the
staked assets.
# Execution Model
Source: https://docs.debridge.com/home/architecture/execution-model
How deBridge executes cross-chain trades
Understanding how deBridge executes trades helps you build reliable integrations and debug issues when they arise.
## DLN Order Execution
The deBridge Liquidity Network uses a transaction-based model where users create orders by submitting transactions on the source
chain.
### Creating an Order
1. **Create Transaction**: API returns expected output, fees, and rates, along with transaction data ready to be signed
2. **Submit**: User signs and submits on source chain
3. **Order Created**: Smart contract emits event with order details
### Order Fulfillment
Once an order is created:
1. **Detection**: Solvers detect the new order
2. **Evaluation**: Solvers assess profitability
3. **Fulfillment**: Winning solver sends tokens to recipient on destination
4. **Unlock**: Solver claims locked tokens on source chain
```mermaid theme={null}
sequenceDiagram
participant User
participant Source Chain
participant Solver
participant Destination Chain
User->>Source Chain: Create order (lock tokens)
Source Chain-->>Solver: Order detected
Solver->>Destination Chain: Fulfill (send tokens to user)
Solver->>Source Chain: Claim unlock
Source Chain-->>Solver: Tokens released
```
### Time to Settlement
* **Order creation**: 1 block confirmation (\~12-15s on Ethereum)
* **Fulfillment**: Typically 10-60 seconds after creation
* **Total**: Usually under 2 minutes end-to-end
## Gas Payment
### DLN
* **User pays**: Gas on source chain for order creation
* **Solver pays**: Gas on destination chain for fulfillment
* **Included in rate**: Destination gas cost factored into quoted rate
## Error Handling
### DLN Order Failures
deBridge is completely decentralized and has no mechanism to hold deposited funds. **Users can always cancel their orders before
they're fulfilled**.
| Scenario | Outcome |
| --------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Order creation fails | User retains tokens, no order created |
| No solver fills order | User can cancel via smart contract call on the destination chain, or automatically via auto-cancellations if enabled |
## Tracking Execution
### DLN
Track order status via API polling. See
[Order Tracking](/dln-details/integration-guidelines/order-creation/order-tracking-api/tracking-orders).
## Cancellation
### DLN Orders
* **Before fulfillment**: User can cancel via smart contract call on the destination chain, or via auto-cancellations (if enabled
for the integration) where deBridge subsidizes the gas fees after a timeout
## Next Steps
* [Fees and Pricing](/home/architecture/fees-overview)
# Fees & Pricing
Source: https://docs.debridge.com/home/architecture/fees-overview
Understanding deBridge fee structure and pricing
deBridge fees are designed to be competitive while ensuring reliable execution.
## DLN Fees
### Fee Components
| Component | Description |
| ----------------- | ------------------------------------------------------------------------------------------------- |
| **Flat Fee** | Fixed amount in native gas token (e.g., 0.001 ETH on Ethereum, 0.015 SOL on Solana) |
| **Protocol Fee** | Fixed percentage on trade value |
| **Solver Margin** | Built into the quoted rate |
| **Gas Costs** | Destination gas taken from the spread or included in the quoted rate, depending on the parameters |
For more details on DLN fees, see the [DLN Fee Structure](/dln-details/overview/fee-structure) documentation.
### How Quotes Work
When you request a quote:
1. API calculates best available rate
2. Solver margins are competitive (market-driven)
3. Destination gas costs are estimated and can be included in the rate, depending on the parameters
4. You see the final output amount
*Actual rates depend on market conditions.*
## Affiliate Fees
Integrators can earn revenue through affiliate fees on DLN. More details on how to monetize your integration
are available in the [dedicated section below](/home/monetization/affiliate-fees).
### Fee Limits
* Maximum affiliate fee: 10% (1000 bps)
* Fees paid out automatically (EVM) or claimable (Solana)
### Documentation
* [Affiliate Fees Guide](/home/monetization/affiliate-fees)
* [DLN Affiliate Fees](/dln-details/affiliates/affiliate-fees)
* [Withdrawing Fees](/dln-details/affiliates/withdrawing-affiliate-fees)
## Next Steps
* [DLN Fee Structure](/dln-details/overview/fee-structure)
* [Supported Chains](/home/architecture/supported-chains)
* [Monetization & Affiliate Fees](/home/monetization/affiliate-fees)
# Supported Chains
Source: https://docs.debridge.com/home/architecture/supported-chains
Networks supported by deBridge products
deBridge supports a wide range of EVM chains and Solana across its products.
## Chain Coverage
| Chain | Chain ID | Internal Chain ID |
| --------- | --------- | ----------------- |
| Ethereum | 1 | 1 |
| Solana | 7565164 | 7565164 |
| Arbitrum | 42161 | 42161 |
| Avalanche | 43114 | 43114 |
| BNB Chain | 56 | 56 |
| Polygon | 137 | 137 |
| Robinhood | 4663 | 4663 |
| Optimism | 10 | 10 |
| Base | 8453 | 8453 |
| Linea | 59144 | 59144 |
| Story | 1514 | 100000013 |
| Cronos | 25 | 100000019 |
| HyperEVM | 999 | 100000022 |
| Monad | 143 | 100000030 |
| TRON | 728126428 | 100000026 |
| Injective | 1776 | 100000029 |
| MegaEth | 4326 | 100000031 |
**Internal Chain IDs** — Several chains use deBridge-specific internal chain IDs that differ from their standard chain IDs.
Internal chain IDs must be used when interacting with deBridge APIs.
## Getting Chain Information
### DLN Chains
For deBridge Liquidity Network supported chains and flat fee details, see
[DLN Fees & Supported Chains](/dln-details/overview/fees-supported-chains).
## Token Support
The deBridge Liquidity Network (DLN) supports a wide range of tokens on each chain.
### Reserve Assets
To reduce operational complexity, deBridge is designed in such a way that solvers only need to maintain liquidity in a small set
of reserve assets. These assets currently include:
* ETH on Ethereum, Arbitrum, Base, and Linea
* wETH on Avalanche, BNB Chain, and Polygon
* USDC (issued by Circle Inc.) on all supported chains
* USDT on TRON
### Non-Reserve Assets
Other liquid tokens are supported via on-chain swaps:
* Swap to reserve asset on source
* Cross-chain trade
* Swap to target asset on destination
## Adding New Chains
deBridge regularly adds support for new chains. For chains not yet supported:
* Contact the team for integration timeline
* Consider [IaaS](/home/products/iaas) for custom chain integration
## Detailed Documentation
* [DLN Fees & Supported Chains](/dln-details/overview/fees-supported-chains)
* [DMP Fees & Supported Chains](/dmp-details/dmp/fees-supported-chains)
* [Deployed Contracts](/dln-details/overview/deployed-contracts)
# deBridge Bundles
Source: https://docs.debridge.com/home/bundles
A new execution primitive for intent-based, chain-agnostic interactions.
Bundles are a new execution primitive for building chain-agnostic interactions in a single click. Bundles let users simply express **what outcome they
want** and the system handles the execution flow across chains, while users keep full self-custody of their assets. Having users and developers
wrestle with fragmented liquidity, native gas balances, RPC reliability, and cross-chain orchestration is a thing of the past.
Bundles are the foundation of deBridge's upcoming protocol evolution. They introduce a cleaner mental model for onchain experiences: **intents over
transactions**, with deterministic execution rules and a unified interface across environments, including EVM chains and Solana.
Bundles are currently in a **private rollout** with a limited set of integrators. This page is a public overview meant to explain the "why".
# From Transactions to Intents
Onchain UX breaks down when users are asked to think like infrastructure. They have to manage approvals, keep native tokens for fees, retry failed
actions, and check execution through multiple chains and tools. Even when everything works, the experience is not smooth.
Bundles shift the interaction model. Users don't stitch together steps; they express an **intent** - the desired result, and the underlying system
coordinates the required actions to reach that result according to predefined rules. This makes complex multi-step workflows feel like a single
operation, while keeping users in control of their assets.
# Why Bundles Matter
Bundles remove the most common execution pain points that make multi-chain products hard to build and harder to use. The result is a more reliable
runtime for applications and a dramatically simpler experience for users.
For users, Bundles reduce the overhead of "being multi-chain" by abstracting away mechanics like native-fee management and multi-step orchestration.
For developers, Bundles reduce the need to write repetitive boilerplate code for retries, landing transactions, and chain-by-chain edge cases.
# A Better Build Surface for Developers
Bundles are designed to let teams focus on product instead of plumbing. When the execution layer becomes consistent and intent-driven, developers can
spend their time on the actual user journey - onboarding, discovery, UX, and differentiation, rather than building and maintaining utility libraries.
This is the kind of primitive that unlocks a new class of apps: wallets that feel seamless across chains, agents that can act on outcomes rather than
raw transactions, and trading systems that can compose complex multi-chain steps into one coherent chain-agnostic operation.
# What You Can Build
Bundles are a building block for any product where users want outcomes, not operations. Common starting points include multi-chain onboarding flows,
one-click portfolio actions, cross-chain trading journeys, and application workflows that span multiple environments.
As the ecosystem expands, Bundles are intended to power experiences across apps, wallets, agents, and advanced trading systems-while keeping execution
deterministic and the interface consistent.
Single-click flows that feel native, even when execution spans multiple chains.
Composable journeys that package multiple steps into one user action.
Outcome-based actions that can include arbitrary logic without extra boilerplate code.
Intent-driven execution that is easier to reason about, test, and monitor.
# Availability
Bundles are available today to a select group of integrators under restricted access. Public, user-facing experiences powered by Bundles will roll out
in the near future.
If you're building a product where execution complexity is holding back UX, or where multi-chain support is becoming operationally expensive - Bundles
are designed for you.
# Request Access
If you'd like to evaluate Bundles for your product, request access to the private documentation and integration materials by contacting someone from
the team or by filling [this form](https://tally.so/r/wLV0Ey).
# Every Use Case Quickstart
Source: https://docs.debridge.com/home/guides/guides
Integration guides and quickstarts for all deBridge products
## deBridge Liquidity Network (DLN)
Build a cross-chain swap from Polygon to Arbitrum
Minimal steps to create your first order
Full order creation walkthrough
All available parameters and options
Drop-in UI component for cross-chain swaps
Single-chain swaps using DLN
Add PostHook contract calls to orders
Monitor order status and lifecycle
Get an API key for higher rate limits
On-chain integration (advanced)
## deBridge Messaging Protocol (DMP)
How cross-chain messaging works
End-to-end message flow
Build a cross-chain EVM application
Send messages from Solana
Tools for building and testing
Multi-chain asset deployment
# Affiliate Fees
Source: https://docs.debridge.com/home/monetization/affiliate-fees
Earn revenue by integrating deBridge into your application
# Monetize Your Integration
Affiliate fees let you earn a percentage of every swap that flows through your integration. Whether you're building a DeFi
aggregator, wallet, or trading interface — affiliate fees turn your integration into a revenue stream.
Affiliate fees are supported on the **deBridge Liquidity Network API**. The mechanism works the same way:
you specify a fee percentage and recipient address, and the fee is collected from each swap.
Affiliate fees require building an integration using the deBridge API (DLN) or Widget. For earning without writing
code, see [deBridge Points](/home/monetization/debridge-points) and [Custom Linking](/home/monetization/custom-linking).
## Why Affiliate Fees Matter
Maximum affiliate fee is 10% (1000 basis points). The fee is taken from the input amount before the swap. Keep in mind that
higher affiliate fees result in worse exchange rates for your users, so balance revenue with competitive pricing.
## How It Works
1. User initiates a swap through your integration
2. You specify your affiliate fee percentage and recipient address
3. deBridge collects the fee from the swap amount
4. Fee is sent to your wallet automatically (EVM) or manually claimed (Solana)
## Quick Implementation
### DLN API Integration
[Add parameters to your `create-tx` request](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#affiliate-fee-percent).
### Widget Integration
Add the parameters to your [widget configuration](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#affiliate-fee-percent).
## Receiving Your Fees
### EVM Chains
Affiliate fees are **automatically transferred** to your wallet when a solver claims the order. No action required on your part.
If your `affiliateFeeRecipient` is a smart contract requiring more than 2300 gas, fees won't be sent automatically. Call
`DlnSource.withdrawUnclaimedAffiliateFees(...)` to claim manually.
### Solana
Affiliate fees must be **manually withdrawn**. Use the `withdrawAffiliateFee` method of the DLN program.
For cross-chain swaps, see the [withdrawal guide](/dln-details/affiliates/withdrawing-affiliate-fees).
For same-chain swaps on Solana, the `affiliateFeeRecipient` must be a [Jupiter referral key](https://referral.jup.ag/dashboard).
## Getting Started
Generate your referral code at [app.debridge.com/refer](https://app.debridge.com/refer). Choose Polygon for the cheapest
option—it works across all chains including Solana.
Include `affiliateFeePercent` and `affiliateFeeRecipient` in your API calls or widget config.
Affiliate fees are sent directly to your `affiliateFeeRecipient` address—automatically on EVM chains, or via manual withdrawal
on Solana.
## Technical Deep-Dives
For detailed technical specifications, see the DLN reference documentation:
Complete API parameters and fee mechanics
Manual withdrawal process for Solana and edge cases
Using referral codes for tracking and features
Automatic order cancellation for improved UX
# Custom Linking
Source: https://docs.debridge.com/home/monetization/custom-linking
Create shareable swap links with your referral code—no coding required
Create custom deBridge links with pre-filled parameters and your referral code. Share them anywhere—social media, blog posts,
Discord—and earn from every swap.
## What You Can Do
* Create links with pre-selected chains and tokens
* Embed your referral code to earn [deBridge Points](/home/monetization/debridge-points)
* No coding or technical setup required
Your referral code only applies to **new users** who have never visited deBridge before and haven't made any transactions
through the protocol. Existing users won't be counted as your referrals.
## Step-by-Step Guide
Go to [app.debridge.com/refer](https://app.debridge.com/refer)
1. Connect your wallet
2. Select **Polygon** (cheapest option, works for all chains)
3. Click **Generate**
4. Save your referral code (e.g., `7895`)
Start with the base URL and add your referral code:
```
https://app.debridge.com/?r=YOUR_CODE
```
Example with referral code `4850`:
```
https://app.debridge.com/?r=4850
```
Customize the link further by pre-selecting chains and tokens.
Example: USDC on BSC → USDT on Ethereum with referral code:
```
https://app.debridge.com/?inputChain=56&inputCurrency=0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d&outputChain=1&outputCurrency=0xdac17f958d2ee523a2206206994597c13d831ec7&r=4850
```
Post your custom link on Twitter, Discord, Telegram, or your website. New users who swap through your link will contribute to your points.
## URL Parameters
| Parameter | Description | Example |
| ---------------- | ------------------------- | ---------------------- |
| `r` | Your referral code | `r=7895` |
| `inputChain` | Source chain ID | `inputChain=1` |
| `inputCurrency` | Source token address | `inputCurrency=0x...` |
| `outputChain` | Destination chain ID | `outputChain=137` |
| `outputCurrency` | Destination token address | `outputCurrency=0x...` |
| `amount` | Pre-filled amount | `amount=100` |
| `address` | Pre-filled recipient | `address=0x...` |
## Common Chain IDs
| Chain | ID |
| --------------- | ------- |
| Ethereum | `1` |
| BNB Smart Chain | `56` |
| Polygon | `137` |
| Arbitrum | `42161` |
| Avalanche | `43114` |
| Fantom | `250` |
| Optimism | `10` |
| Base | `8453` |
Find all chain IDs in the [supported chains section](/home/architecture/supported-chains).
## Example Links
### Basic Link with Referral Code
```
https://app.debridge.com/?r=7895
```
### ETH to Polygon USDC
```
https://app.debridge.com/?inputChain=1&outputChain=137&outputCurrency=0x3c499c542cef5e3811e1192ce70d8cc03d5c3359&r=7895
```
### BSC USDC to Ethereum USDT
```
https://app.debridge.com/?inputChain=56&inputCurrency=0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d&outputChain=1&outputCurrency=0xdac17f958d2ee523a2206206994597c13d831ec7&r=7895
```
## Track Your Points
Monitor your referral activity and accumulated points:
1. Go to [app.debridge.com/statistic](https://app.debridge.com/statistic)
2. Connect the wallet you used to generate your referral code
3. View your points accumulated and referred users
## Best Practices
Use a URL shortener for cleaner sharing on social media
Pre-fill chains and tokens relevant to your community
Use different referral codes for different campaigns to measure performance
Disclose that you earn from referrals—it builds trust
## Next Steps
* [Learn about deBridge Points](/home/monetization/debridge-points) and how they convert to DBR tokens
* [Build an integration](/home/monetization/affiliate-fees) to earn affiliate fees directly
* See the full [URL parameter reference](/dln-details/widget/app) for advanced options
# deBridge Points
Source: https://docs.debridge.com/home/monetization/debridge-points
Earn points for contributing to the deBridge ecosystem
The deBridge Points program rewards users, integrators, and referrers for contributing to the ecosystem. Points are earned based
on protocol fees and can translate to future governance participation.
## How Points Work
For every 1\$ in protocol fees paid, users earn 100 deBridge Points. **Referrers and integrators earn 25%** of the points
generated by users they refer.
## Points to DBR Conversion
At the end of each season, accumulated points are converted into
[DBR tokens](https://solscan.io/token/DBRiDgJAMsM95moTzJs7M9LnkGErpbv9v6CUR1DXnUu5). The conversion rate is announced when each
season concludes.
To stay informed about season endings and DBR distributions, follow deBridge on [X (Twitter)](https://x.com/debridge) and join
our [Discord](https://discord.gg/debridge).
## For Integrators
Integrating deBridge into your product? Your integration automatically earns 25% of all points generated by your users.
### Integration Methods
Choose how to integrate:
Full control and customization
Drop-in UI component
Custom cross-chain calls
### Setting Up Your Referral Code
To ensure your integration activity is tracked, you'll need a referral code. Beyond points tracking, referral codes enable
analytics, order tracking, and features like auto-cancellation. See the [Referral Codes guide](/home/monetization/referral-codes)
for full details.
Go to [app.debridge.com/refer](https://app.debridge.com/refer) and generate a referral code. Select Polygon for the cheapest option—it covers all chains.
Pass the `referralCode` parameter to all DLN API queries. Set the parameters up correctly for your integration path:
* **API**: Include `referralCode` in your [`create-tx` requests](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#referral-code)
* **Widget**: Set the `r` parameter in your [widget configuration](/dln-details/widget/deBridge-widget)
Check your stats at [app.debridge.com/statistic](https://app.debridge.com/statistic) to confirm orders are being tracked.
Share your referral code with the deBridge team for expedited support and feature access like
[auto-cancellation](/dln-details/affiliates/auto-cancellations).
## For Individual Referrers
Share deBridge with your network and earn 25% of points from new users who swap through your link.
### Getting Your Referral Link
Visit [app.debridge.com/refer](https://app.debridge.com/refer), connect your wallet, and generate a code.
Your referral link format: `https://app.debridge.com/deswap?r=YOUR_CODE`
Post on Twitter, Discord, Telegram—anywhere your network is active.
Self-referrals (referring yourself) are not counted to prevent gaming the system.
### Who Counts as a Referral?
A "new user" is someone who:
* Has never visited deBridge before
* Has never made any transactions through deBridge
* Visits deBridge for the first time through your referral link
You earn 25% of their points for all future activity.
## Check Your Points
View your accumulated points and referral statistics:
1. Go to [explorer.debridge.com/statistic](https://explorer.debridge.com/statistic)
2. Connect the wallet you used to generate your referral code
3. See your total points and referred users
## FAQ
Connect your wallet at [explorer.debridge.com/statistic](https://explorer.debridge.com/statistic).
No—points can only be tracked with a referral code attached. Add your code to all future transactions to start earning.
Points are converted to [DBR tokens](https://solscan.io/token/DBRiDgJAMsM95moTzJs7M9LnkGErpbv9v6CUR1DXnUu5) at the end of each
season. Follow [@debridge on X](https://x.com/debridge) or join our [Discord](https://discord.gg/debridge) for season
announcements.
Season end dates are announced on our socials. Follow [@debridge on X](https://x.com/debridge) or join our
[Discord](https://discord.gg/debridge) to stay informed.
Yes! Points and [affiliate fees](/home/monetization/affiliate-fees) are separate. You can earn both by including your referral code and affiliate fee parameters.
## Next Steps
Add direct revenue to your integration
Share pre-configured swap links
# Referral Codes
Source: https://docs.debridge.com/home/monetization/referral-codes
Track orders, unlock features, and enable auto-cancellation with referral codes
A referral code is your unique identifier when integrating with deBridge. Beyond tracking points and affiliate fees, it enables
analytics, feature toggles, and improved user experience.
### DLN Referral Codes
For [deBridge Liquidity Network (DLN)](/home/products/dln-overview) integrations, referral codes are generated on-chain and enable
additional features like auto-cancellation.
## What Referral Codes Enable
| Capability | Description |
| ------------------- | -------------------------------------------------------------------------------------------------------- |
| **Order Tracking** | See all orders created through your integration |
| **Analytics** | Monitor volume, fees, and user activity |
| **Feature Toggles** | Enable DLN features like [auto-cancellation](/dln-details/affiliates/auto-cancellations) per integration |
| **Custom Support** | Faster debugging with order attribution |
## Getting a Referral Code
Go to [app.debridge.com/refer](https://app.debridge.com/refer)
Connect the wallet you want associated with your code
Choose **Polygon** for the cheapest generation fee. The code works across all supported chains including Solana.
Click generate and save your code (e.g., `7895`)
## Using Your Code
### API Integration
Include `referralCode` in your
[`create-tx` requests](/dln-details/integration-guidelines/order-creation/creating-order/api-parameters/api-parameters#referral-code).
More details are available in the API documentation.
### Widget Integration
Set the `r` parameter in your [widget configuration](/dln-details/widget/deBridge-widget).
## Tracking Orders
Query all orders associated with your referral code using the tracking API:
See the full
[order tracking documentation](/dln-details/integration-guidelines/order-creation/order-tracking-api/tracking-orders#by-referralcode)
for available filters and response fields.
### Code Example
A complete working example is available on GitHub:
[get-orders-by-referral-code.ts](https://github.com/debridge-finance/api-integrator-example/blob/master/src/scripts/orders/queries/get-orders-by-referral-code.ts)
## Auto-Cancellation Feature
For DLN integrations, referral codes unlock **[auto-cancellation](/dln-details/affiliates/auto-cancellations)**—automatic
cancellation of unfulfilled orders after a timeout, improving user experience.
### How It Works
* **Unprofitable orders**: Cancelled after 5 minutes
* **Other issues**: Cancelled after 15 minutes
* **Cost**: Subsidized by deBridge
* **Result**: Users don't need to manually cancel failed orders
### Enabling Auto-Cancellation
This feature requires approval from deBridge:
1. Contact deBridge to request the feature
2. Configure required parameters (`srcAllowedCancelBeneficiary`)
3. deBridge reviews your integration
4. Feature is enabled for your referral code
When auto-cancellation is enabled, the `dstChainOrderAuthorityAddress` is overridden to a deBridge-controlled address. Ensure
`srcAllowedCancelBeneficiary` is set to the user's wallet to receive refunds.
See the full [auto-cancellation documentation](/dln-details/affiliates/auto-cancellations) for technical details.
## Technical References
Full referralCode parameter specification
Query orders by referral code
Automatic order cancellation setup
Widget configuration options
# dePort
Source: https://docs.debridge.com/home/products/deport-overview
Deploy your token on secondary chains using dePort's lock-and-mint solution
dePort is a native bridge for assets that allows protocols to deploy synthetic representations (deTokens) of their tokens across multiple chains using a lock-and-mint model. Built on the [deBridge Messaging Protocol (DMP)](/home/products/dmp-overview), dePort locks native tokens in a deBridgeGate smart contract on the source chain and mints corresponding synthetic assets (deAssets) on destination chains. dePort can also serve as a canonical bridge for chains connected via [deBridge IaaS](/home/products/iaas), providing cross-chain asset custody.
## Key Features
* **Lock-and-mint architecture**: Native tokens are locked on the source chain, synthetic deAssets are minted on destination chains
* **1:1 collateralization**: Total supply of each deAsset is always fully backed by collateral locked on the native chain — no liquidity imbalance risk
* **Automatic listing**: No listing requirements — any token can be bridged, and the deAsset is deployed automatically on first claim
* **Multi-chain routing**: Transfer deAssets between secondary chains directly, without routing through the native chain
* **Decentralized validation**: Validator consensus ensures cross-chain transfer integrity
* **Canonical bridge for IaaS chains**: Provides cross-chain asset custody for chains connected via deBridge Infrastructure-as-a-Service
## When to Use dePort
* **Token issuers** wanting multi-chain presence for their assets
* **Protocols** deploying synthetic representations across chains
* **Projects** needing 1:1 backed wrapped tokens with guaranteed collateralization
* **Multi-chain token distribution** without liquidity fragmentation
* **Canonical bridging** for chains connected via [IaaS](/home/products/iaas) — seamless custody of assets from other networks
## How It Works
1. **Lock**: The native token is locked in the `deBridgeGate` smart contract on the source chain. A unique `submissionId` is calculated from the transaction parameters.
2. **Validate**: deBridge validators track the event, wait for block finality, then sign the `submissionId` and submit it to the destination chain.
3. **Mint**: Once sufficient validator signatures are collected, the corresponding deAsset is minted on the destination chain. If the token is bridged for the first time, the deAsset contract is deployed automatically.
4. **Claim**: Any wallet can call the `claim` method with the transaction parameters and validator signatures. The smart contract reconstructs the `submissionId`, verifies signatures, and mints/unlocks the asset to the receiver.
## Architecture
```mermaid theme={null}
graph LR
A[User] -->|Lock token| B[deBridgeGate
Source Chain]
B -->|Emit event| C[Validators]
C -->|Sign submissionId| D[deBridgeGate
Destination Chain]
D -->|Mint deAsset| E[Receiver]
E -.->|Transfer deAsset| F[Other Chains]
```
## Documentation
Core concepts, collateralization, and listing
Technical transfer mechanics and validation
## Get Started
[Go to dePort Documentation](/dmp-details/dePort/getting-started)
# deBridge Liquidity Network
Source: https://docs.debridge.com/home/products/dln-overview
Foundational cross-chain trading infrastructure
The deBridge Liquidity Network (DLN) is the foundational trading infrastructure powering deBridge. It provides fast,
capital-efficient **cross-chain and same-chain swaps** with guaranteed rates and no slippage.
## Key Features
* **Cross-chain and same-chain swaps**: One API for both — no separate integrations needed
* **Near-instant settlement**: Trades complete in seconds, not minutes
* **0-TVL architecture**: No liquidity pools to hack
* **Guaranteed rates**: The quoted rate is the rate you get
* **Zero slippage**: No MEV, no front-running
* **Native tokens**: Receive real assets, not wrapped versions
* **Hooks support**: Execute contract calls with trades (PostHooks)
## Same-Chain Swaps
DLN isn't just for cross-chain — it also powers **same-chain token swaps** on both EVM chains and Solana through the same API. The
DLN API routes through multiple DeFi aggregators, simulates execution, and returns ready-to-sign transactions — so your
integration stays simple while users get competitive rates.
Key capabilities:
* **Adaptive slippage**: Instead of a static slippage value, DLN dynamically calculates a minimum reasonable bound based on
real-time conditions and route simulation — protecting users in volatile markets
* **Aggregator comparison**: The API queries multiple aggregators and returns the comparison in the response, giving integrators
full transparency into the routing decision
* **Execution-ready transactions**: The `/v1.0/chain/transaction` endpoint returns a fully constructed transaction (targeting
`DeBridgeRouter` on EVM, or a serialized `VersionedTransaction` on Solana) — no manual route building required
* **Built-in monetization**: [Affiliate fees](/dln-details/affiliates/affiliate-fees#same-chain-affiliate-fees) work identically
to cross-chain swaps — just include `affiliateFeePercent` and `affiliateFeeRecipient` in your requests
The integration flow is intentionally compact: call `/v1.0/chain/estimation` for a quote (just for quotes – user's address is
unknown), then `/v1.0/chain/transaction` once the sender is known. Sign and submit within \~30 seconds for best execution.
High-level overview of how same-chain swaps work
Endpoints, code examples, and production checklist
## Foundational Role
DLN sits at the top of deBridge's protocol stack:
1. **deBridge Messaging Protocol (DMP)** is foundational for DLN — providing the cross-chain messaging layer
2. **DLN** — providing the order fulfillment and solver network
## How to Integrate
DLN offers three integration paths depending on how much control you need:
* **[Widget](/dln-details/widget/deBridge-widget)**: Drop-in UI component — the fastest way to add cross-chain swaps to your app
* **[API](/dln-details/integration-guidelines/order-creation/creating-order/quick-start)**: Full programmatic control over order
creation, tracking, and hooks — best for custom UIs and backend integrations
* **[Smart contracts](/dln-details/integration-guidelines/smart-contracts/introduction)**: Direct on-chain integration for
specialized use cases. Note that accurate pricing depends on significant simulation infrastructure that the API already
provides, so smart contract integration is rarely the right choice
Most teams should start with the **Widget** (for speed) or the **API** (for flexibility).
Accurate pricing for solver profitability and competitive user rates requires significant simulation infrastructure. The
deBridge API provides this. Smart contract integration is available for very special cases but is not the primary integration
path.
## Architecture
```mermaid theme={null}
graph LR
A[User] -->|Create order| B[DLN Contract]
B -->|Emit event| C[Solver Network]
C -->|Fulfill| D[Destination Chain]
D -->|Tokens to user| E[User]
C -->|Claim| B
```
## Integration Options
Drop-in UI component
Full programmatic control
On-chain integration (not recommended for most use cases)
Universal swaps - same-chain and cross-chain.
## Documentation Sections
* **[Introduction](/dln-details/overview/introduction)**: Core concepts
* **[Protocol Overview](/dln-details/overview/protocol-overview)**: How DLN works
* **[API Integration](/dln-details/integration-guidelines/order-creation/creating-order/creating-order)**: Build with the API
* **[Hooks](/dln-details/integration-guidelines/order-creation/hooks/integrating-hooks)**: Add contract calls
* **[Tracking](/dln-details/integration-guidelines/order-creation/order-tracking-api/tracking-orders)**: Track orders
## Get Started
[Go to DLN Documentation](/dln-details/overview/introduction)
# deBridge Messaging Protocol
Source: https://docs.debridge.com/home/products/dmp-overview
Everything you need to know about deBridge's foundational cross-chain messaging layer
The deBridge Messaging Protocol (DMP) is the foundational messaging layer that enables arbitrary cross-chain communication. It is
foundational for the deBridge Liquidity Network (DLN), inheriting the same secure, decentralized messaging layer for custom
cross-chain applications.
## Key Features
* **Arbitrary data transfer**: Send any message across chains
* **Cross-chain contract calls**: Execute calls on remote chains
* **Decentralized validation**: Multi-validator consensus
* **Trustless claiming**: Anyone can claim with valid signatures
* **External calls**: Include execution instructions with messages
## When to Use DMP
Choose DMP when building:
* **Custom protocols**: Cross-chain applications with unique logic
* **Governance systems**: Multi-chain voting and execution
* **NFT bridges**: Lock-and-mint token transfers
* **State synchronization**: Keep data consistent across chains
* **Cross-chain automation**: Trigger actions across chains
* [**dePort**](/dmp-details/dePort/getting-started): Multi-chain asset deployment (synthetic asset creation)
## Architecture
```mermaid theme={null}
graph LR
subgraph Source Chain
A[Source Contract] -->|send| B[deBridgeGate]
end
subgraph Off-chain
C[Validators] -->|sign| D[Arweave]
D -->|signatures| E[Claimer]
end
subgraph Destination Chain
F[deBridgeGate] -->|execute| G[Receiver Contract]
end
B -->|monitor| C
E -->|claim| F
```
## How Messages Flow
1. **Send**: Contract calls `deBridgeGate.send()` with a message
2. **Validate**: Validators wait for finality, then sign
3. **Store**: Signatures stored on Arweave
4. **Claim**: Anyone can claim with sufficient signatures
5. **Execute**: Receiver contract processes the message
## Documentation Sections
* [**Protocol Overview**](/dmp-details/dmp/protocol-overview): Core concepts
* [**Security**](/dmp-details/dmp/security): Trust model
* [**EVM Guide**](/dmp-details/dev-guides/evm/building-evm-dapp): Build EVM dApps
* [**Solana Guide**](/dmp-details/dev-guides/solana/sending-cross-chain-messages): Solana integration
* [**Development Tools**](/dmp-details/dev-guides/development-tools): Testing and debugging
## Comparison with DLN
| Aspect | DMP | DLN |
| ----------- | ------------------------ | ------------------- |
| Purpose | Arbitrary messaging | Value transfer |
| Integration | Smart contract | API-based |
| Complexity | Higher | Lower |
| Flexibility | Maximum | Optimized for swaps |
| Use case | Custom protocols, dePort | Swaps, onboarding |
## Get Started
[Go to DMP Documentation](/dmp-details/dmp/protocol-overview)
# Infrastructure-as-a-Service
Source: https://docs.debridge.com/home/products/iaas
Connect your chain to deBridge for end-to-end interoperability across EVM and SVM ecosystems, including authenticated messaging, liquidity bridging, and cross-chain custody.
# deBridge IaaS
**deBridge IaaS** (Interoperability-as-a-Service) is the first service enabling complete cross-chain interoperability for **any
EVM or SVM blockchain** ecosystem. It's a turnkey solution that allows any chain to plug into deBridge infrastructure, solving all three pillars of interoperability simultaneously:
* [**Transfers of authenticated messages**](/dmp-details/dmp/protocol-overview)
* [**Native high-performance value exchange (liquidity bridging)**](/dln-details/overview/introduction)
* [**Cross-chain asset custody**](/dmp-details/dePort/getting-started)
![IaaS]()
Blockchain ecosystems no longer have to solve each hurdle individually but instead can open up to global composability from day one. As a complete solution, deBridge IaaS can enable any chain to become fully composable within the global DeFi ecosystem by attracting developers, users, and liquidity from outside their ecosystem. Teams get a [battle-tested system with 17 supported chains](/dmp-details/dmp/fees-supported-chains) instead of the complexities of building and maintaining a separate, fragmented interoperability system. deBridge IaaS allows teams to focus on building features that differentiate their chain instead of reinventing the wheel.
The subscription can be initiated by any on-chain address that pays the subscription fee.
Get started here to initiate an IaaS subscription for your chain: [https://app.debridge.com/subscriptions](https://app.debridge.com/subscriptions)
## Features and opportunities include
* [**deBridge Messaging**](/dmp-details/dmp/protocol-overview): Provides a decentralized infrastructure powering cross-chain message and data transfers — with authentication. deBridge allows smart contracts deployed across different EVM and SVM chains to establish an authenticated communication channel.
* [**DLN Cross-Chain Exchange**](/dln-details/overview/introduction): A high-performance cross-chain trading infrastructure built on deBridge with a unique 0-TVL design. DLN offers zero slippage on any order size, deeper market depth, fastest settlement times, and native asset trading without wrapped assets and risks of locked liquidity.
* [**dePort Asset Custody**](/dmp-details/dePort/getting-started): Allows for seamless custody of assets from other networks in just one click. Projects and DAOs can scale effortlessly into neighboring ecosystems and create utility for their assets across different chains.
## Who is it for?
deBridge IaaS is an end-to-end solution for blockchain ecosystems in the space, designed to make global interoperability easy and accessible.
With a simple subscription fee, blockchains can solve all three interoperability challenges and make their ecosystem instantly accessible and composable from (and between) any EVM or SVM chain.
## Limitations
There are certain KPI criteria used to evaluate chains before they are added to the [main deBridge app](https://app.debridge.com/) for liquidity transfers:
* Security
* TVL
* Daily transactions
* DAUs
Even if a chain is not listed in the main app, it remains fully accessible for [swaps](/dln-details/integration-guidelines/same-chain-swaps/executive) and [bridges](/dln-details/dln-specifics/bridging-non-reserve-assets) through [the DLN API](/dln-details/integration-guidelines/order-creation/creating-order/quick-start) and [deBridge widget](/dln-details/widget/deBridge-widget).
Users can bridge to and from the chain directly from the chain's own UI or landing page with the integrated widget. The chain is still supported at the infrastructure level, including [messaging](/dmp-details/dmp/protocol-overview), [deBridge custody (dePort)](/dmp-details/dePort/getting-started), [DLN hooks](/dln-details/overview/deBridge-hooks), and more.
## Pricing structure
deBridge IaaS uses an on-chain subscription-based model where the first year is paid in full upfront (120,000 USDC). After year one, the subscription can continue with monthly, quarterly, or annual payments.
After the first year, the available pricing options are:
* 11,000 USDC/month with monthly payments
* 10,000 USDC/month with quarterly or annual payments
Once the subscription is initiated on-chain via the [IaaS smart contract](https://etherscan.io/address/0x2328ee20fa271073328dc94e52dd5b61aa0c91a7), the deBridge team will perform all necessary deployments and deBridge validators will automatically start validating messages coming to and from the newly added ecosystem. DLN market makers automatically start receiving quotes on all trades created, receiving the ability to monetize their liquidity, and fulfill trades coming to or from a new chain.
deBridge validation nodes perform continuous state and balance-sheet validation. If any inconsistencies are discovered (e.g. if total supply of dePort-issued assets calculated by validators differs from the total supply observed on-chain), validators will automatically stop operation for this chain and terminate the subscription without issuing any refunds.
If a blockchain stops paying the IaaS subscription, there will be a grace period of up to 10 days. This allows users to move their funds if necessary before validation of cross-chain messages fully stops. If subscription is resumed, the subscription timer starts again the moment the first message is validated after the continuation.
## Risks for users
The process of IaaS subscription initialization is decentralized and performed through an IaaS smart contract, so deBridge doesn't perform due diligence on any blockchain ecosystems connected through IaaS and doesn't bear any responsibility for the quality and validity of the data returned by the chain's RPC endpoint, which is specified by the subscription's governance address as one of the parameters when initiating the subscription.
Users interacting with any IaaS chains should do their own research about the chain and its IaaS subscription parameters such as RPC and governance address (similar to how Uniswap users can interact with arbitrary tokens simply by specifying a token address).
## Getting started today
Get started by initiating an IaaS subscription for any chain [here](https://app.debridge.com/iaas).
# Quickstart
Source: https://docs.debridge.com/home/quickstart
Start building cross-chain experiences in minutes
# Get Started with deBridge
deBridge offers multiple integration paths depending on your needs. Choose the approach that best fits your use case.
**30 minutes to production**
Drop-in UI component for cross-chain swaps. Perfect for adding cross-chain functionality without building custom UI.
**Programmatic swaps**
Full control over cross-chain orders. Build custom UIs and integrate swaps into your existing flows using the proven DLN
infrastructure.
**Arbitrary data transfer**
Send messages and execute calls across chains via the deBridge Messaging Protocol. Build custom cross-chain applications.
## What's the Difference?
| Feature | Widget | deBridge Liquidity Network API |
| ---------------------- | -------------- | ------------------------------ |
| Custom UI | Limited | Full control |
| PostHooks | PostHooks only | PostHooks only |
| Fee structure | Flat + % | Flat + % |
| Integration complexity | Low | Medium |
## Next Steps
* Explore [use cases](/home/use-cases/swaps) to find the right product for your needs
* Read the [architecture overview](/home/architecture/execution-model) to understand how deBridge works
* Check out [supported chains](/home/architecture/supported-chains) and tokens
# FAQ
Source: https://docs.debridge.com/home/resources/faq
Frequently asked questions about deBridge
## General
deBridge is cross-chain infrastructure enabling fast, secure asset transfers and messaging across [17
blockchains](/dln-details/overview/fees-supported-chains) including EVM chains and Solana.
* **0-TVL architecture**: No liquidity pools to hack
* **Native tokens**: You receive real assets, not wrapped versions
* **Fast settlement**: Most trades complete in seconds
deBridge supports 17 blockchains:
* **Major chains**: Solana, Ethereum, Polygon, Base, Arbitrum, Optimism, Avalanche, BNB Chain
* **Additional chains**: Robinhood, Story, Cronos, HyperEVM, TRON, Injective, Monad, MegaETH, Linea
See [Fees and Supported Chains](/dln-details/overview/fees-supported-chains) for the full list with chain-specific fees.
Transaction speed depends on the source/destination chains and trade size:
* **Small amounts**: Solvers typically fulfill immediately after on-chain events are emitted (seconds)
* **Large amounts**: Solvers may wait for more block confirmations to mitigate chain reorg risk (minutes)
DLN uses a free market of solvers who assess and price chain reorg risks themselves. Most trades complete in under 2 minutes.
## Products
* **Widget**: Fastest integration (30 minutes), pre-built UI
* **API**: Custom UI, programmatic control, hooks support
**deBridge Liquidity Network (DLN)**:
* Cross-chain value/asset transfer
* API-based integration (Widget, REST API)
* Lower complexity, optimized for swaps
* Best for: cross-chain swaps, user onboarding
**deBridge Messaging Protocol (DMP)**:
* Arbitrary cross-chain messaging (any data)
* Smart contract integration required
* Higher complexity, maximum flexibility
* Foundation layer—DLN is built on top of DMP
* Best for: custom protocols, governance, state synchronization
| Aspect | DMP | DLN |
| ----------- | ------------------- | ------------------- |
| Purpose | Arbitrary messaging | Value transfer |
| Integration | Smart contract | API-based |
| Complexity | Higher | Lower |
| Flexibility | Maximum | Optimized for swaps |
Learn more: [DLN Overview](/home/products/dln-overview) | [DMP Overview](/home/products/dmp-overview)
Hooks let you execute arbitrary contract calls alongside trades:
* **PostHooks**: Execute after trades complete (e.g., swap to USDC then deposit into Aave)
## Integration
Choose the integration that fits your needs:
* **[Widget](/dln-details/widget/deBridge-widget)**: Easiest option—pre-built UI, 30-minute setup
* Use the [Widget Builder](https://app.debridge.com/widget) to customize
* **[DLN API](/dln-details/integration-guidelines/order-creation/creating-order/quick-start)**: Full programmatic control, custom
UI
* No API key required for basic usage
deBridge integration is API-based, so any language that can make HTTP requests works:
* **REST API**: JavaScript, Python, Go, Rust, Java, or any language
* **Widget**: HTML/JavaScript/React embed
* **Smart contract integration**: Solidity (EVM chains), Rust (Solana)
Documentation examples primarily use JavaScript/TypeScript, along with the [example repository](https://github.com/debridge-finance/api-integrator-example).
No API key required for basic usage of the DLN API. You can start creating orders and tracking them immediately.
* Use small amounts of real assets for testing on mainnets
* Track orders via the [tracking API](/dln-details/integration-guidelines/order-creation/order-tracking-api/tracking-orders) to verify behavior
deBridge does not support testnets. The protocol relies on extensive on-chain infrastructure across multiple chains, making testnet maintenance impractical.
For testing, use small amounts of real assets on mainnets. This also provides a more accurate representation of production
behavior.
## Fees & Pricing
**DLN** fees include:
1. **[Flat fee](/dln-details/overview/fees-supported-chains)**: Paid in native gas token (e.g., 0.001 ETH on Ethereum, 0.015 SOL on Solana)
2. **Variable protocol fee**: 4 bps (0.04%) of input amount
3. **Taker margin**: \~4 bps (0.04%) solver profit
4. **Operating expenses**: Gas costs for [fulfillment, unlock, and claim transactions](/dln-details/dln-specifics/order-fulfillment/order-fulfillment)
**Note**: All fees are fully refunded if an order is cancelled.
Optional: Integrators can add an [affiliate fee](/dln-details/affiliates/integrators) to monetize their integration.
See [Fee Structure](/dln-details/overview/fee-structure) for detailed breakdown.
Yes! Integrators can set an affiliate fee and earn on every trade. See [Affiliate Program](/dln-details/affiliates/integrators).
Yes. Orders can be cancelled automatically if they aren't fulfilled within 5-15 minutes, depending on the cancellation reason.
See [Auto-Cancellations](/dln-details/affiliates/auto-cancellations) for details.
## Security
deBridge is designed with security-first principles:
* **0-TVL**: No liquidity pools to hack—solvers provide liquidity on-demand
* **Decentralized model**: deBridge is fully decentralized with no ability to hold or retain user funds. Unfulfilled orders can always be [cancelled](/dln-details/integration-guidelines/order-creation/cancelling-order).
* **Multi-validator consensus**: For cross-chain messaging
* **Audited smart contracts**: By leading security firms
* **Bug bounty program**: Active responsible disclosure program
See [Security Overview](/home/security/security-overview).
If an order isn't filled, users can cancel and reclaim tokens after expiry.
With DLN, your tokens are deposited in a smart contract for the duration of the order (a few minutes at most), but you can cancel
and reclaim them if the order isn't fulfilled.
0-TVL means there are no shared liquidity pools sitting in contracts. Funds pass through per-order like water through pipes - funds are never pooled.
deBridge has undergone 25+ security audits by leading firms:
* **Auditors**: Halborn, Neodyme, Zokyo, Ackee Blockchain
* **Audit reports**: Available in the [deBridge GitHub repository](https://github.com/debridge-finance/debridge-security)
* **Bug bounty**: \$200,000 program on [Immunefi](https://immunefi.com/bounty/debridge/)
See [Security Overview](/home/security/security-overview) for more details.
## Troubleshooting
1. Check order status via the [tracking API](/dln-details/integration-guidelines/order-creation/order-tracking-api/tracking-orders)
2. Wait for solver fulfillment (usually \< 2 minutes)
3. If unfilled after expiry, [cancel the order](/dln-details/integration-guidelines/order-creation/cancelling-order) to reclaim funds
4. Contact support on [Discord](https://discord.com/invite/debridge)
Common reasons:
* Insufficient token balance
* Approval not granted
* Exceeded slippage tolerance (market conditions abruptly changed during execution, or the order was not submitted promptly -
within 30 seconds of receiving the response from deBridge API)
* [Discord](https://discord.com/invite/debridge) - Community and team support
* [GitHub](https://github.com/debridge-finance/) - Technical issues
* [Integration guides](/home/guides/guides) - Docs and examples
## Technical
Instead of liquidity pools, solvers provide liquidity on-demand:
1. User creates order (deposits tokens in smart contract)
2. Solver sends tokens directly to user on destination
3. Solver claims locked tokens on source
No shared pool = no honeypot to attack.
[Order IDs](/dln-details/protocol-specs/deterministic-order-id) are deterministically computed from order parameters (amounts, addresses, chains). This ensures:
* Unique ID per order
* Tamper-proof (changing params = different ID)
* Reproducible (can verify ID from params)
# Status & Limits
Source: https://docs.debridge.com/home/resources/status-limits
API endpoints, rate limits, and operational constraints
## API Endpoints
### deBridge Liquidity Network (DLN)
| API | Base URL | Purpose |
| ----------------------------------------------------------------------------------------------------------- | ----------------------------------- | ------------------------------------------------- |
| [Swap API](/dln-details/integration-guidelines/order-creation/creating-order/creating-order) | `https://dln.debridge.finance/` | Create and quote same-chain or cross-chain orders |
| [Order Tracking API](/dln-details/integration-guidelines/order-creation/order-tracking-api/tracking-orders) | `https://dln-api.debridge.finance/` | Track order status and history |
DLN offers **generous rate limits without requiring an API key**. Most integrations can operate without authentication.
| Access | Requests/Minute |
| --------------- | --------------- |
| Public (no key) | 50 |
| Authenticated | 300 |
Each endpoint has its own separate rate limit — they are not accumulated across APIs.
Need higher limits? See the [Authentication guide](/dln-details/integration-guidelines/order-creation/authentication) to request
an API key. To expedite the process, reach out to the team on [Discord](https://discord.com/invite/debridge).
Rate limit responses return `HTTP 429`. Implement exponential backoff in your integration to handle these gracefully.
## Trade Limits
deBridge APIs enforce trade size limits to ensure optimal performance and security. DLN comfortably supports
trades ranging from **1 USD to 5.5m USD** in value.
## Expiration
### DLN Orders
* Funds are deposited in smart contract until order is filled or cancelled
* User can always cancel and reclaim tokens
* Typical fill time: \< 2 minutes
deBridge is completely decentralized — there is no central authority that can pause or halt orders and lock the funds.
With DLN, users can cancel orders at any time to reclaim their assets.
### Gas Limits
Maximum gas per hook/transaction varies by the choice of source and destination chains and the market conditions.
## Support
* [Discord](https://discord.com/invite/debridge) - Real-time support
* [GitHub](https://github.com/debridge-finance/) - Bug reports and code examples
# Supported Tokens
Source: https://docs.debridge.com/home/resources/supported-tokens
How token support works in deBridge's free market model
deBridge operates as a self-organizing free economy where professional market makers called
[solvers](/home/architecture/execution-model) compete to fulfill cross-chain orders profitably. This model means that **any token
with sufficient on-chain liquidity can be traded** — as soon as a token is indexed by a DEX aggregator, it becomes available
through deBridge.
## Reserve Assets
While any liquid token can be traded, the settlement between chains always happens in a small set of **reserve assets**. This
design minimizes the capital management burden on solvers — they only need to maintain liquidity in these core assets rather than
hundreds of different tokens.
**Long-tail tokens** are any tokens that aren't reserve assets — this includes governance tokens, meme coins, newer DeFi tokens,
and thousands of other assets with DEX liquidity.
When you trade a long-tail token, here's what happens behind the scenes:
1. Your input token is swapped to a reserve asset on the source chain
2. The reserve asset is settled cross-chain
3. The reserve asset is swapped to your desired output token on the destination chain
### Reserve Assets by Chain
To reduce operational complexity, deBridge is designed in such a way that solvers only need to maintain liquidity in a small set
of reserve assets. These assets currently include:
* ETH on Ethereum, Arbitrum, Base, and Linea
* wETH on Avalanche, BNB Chain, and Polygon
* USDC (issued by Circle Inc.) on all supported chains
* USDT on TRON
When USDC is available on both chains, it is prioritized as the settlement asset for optimal efficiency.
## How Token Support Works
Token support in deBridge is determined by **market dynamics**, not a whitelist:
* **Liquidity determines availability** — If a token has sufficient liquidity on DEXs, solvers can profitably fulfill orders
involving it
* **Automatic indexing** — Once a token is indexed by an aggregator (like 1inch or Jupiter), it becomes tradable
* **No listing required** — There's no approval process or listing fee for new tokens
This means new tokens become available organically as their liquidity grows.
**Always verify token addresses and chains before trading.** Many tokens have similar names or tickers. Confirm you're using the
correct contract address from official sources to avoid sending funds to the wrong token.
## Fetching Supported Tokens
You can retrieve the full list of supported tokens via the API.
Returns all tokens available for trading on each chain
For popular chains, the token list response can be several hundred kilobytes. Consider caching the response and implementing
pagination in your application.
## Specifying Tokens in API Requests
When making API calls, specify tokens using their contract addresses and chain IDs.
For native tokens (ETH, POL, BNB, etc.), use the zero address:
* **EVM chains**: `0x0000000000000000000000000000000000000000`
And for SOL and Wrapped SOL on Solana, use the following addresses:
* **SOL**: `11111111111111111111111111111111`
* **Wrapped SOL**: `So11111111111111111111111111111111111111112`
## Documentation
Technical details on reserve asset mechanics
Complete guide to token specification in API
All networks supported by deBridge
Operating costs and fee structure
# Security Overview
Source: https://docs.debridge.com/home/security/security-overview
Understanding deBridge's security model and trust assumptions
deBridge is designed with security as a foundational principle, not an afterthought. This page provides an overview of the
security model across deBridge products. deBridge has settled over \$20 Billion in transfer volume with zero security incidents.
## Security Pillars
### 0-TVL Architecture
Traditional bridges have lost over \$2 billion to hacks targeting locked liquidity. deBridge eliminates this attack surface
entirely. Smart contracts act as pipes, not pools — funds pass through them briefly on a per-order basis, and there is no shared
liquidity sitting in contracts for attackers to target.
* **No shared liquidity pools**: No honeypot to attack
* **Per-order isolation**: Each trade is independent — no systemic risk
* **Solvers provide liquidity on-demand** from their own capital
* **Native tokens**: Users receive real assets, not wrapped representations
### Cancellation & Fund Recovery
Unfulfilled orders can always be cancelled — users are never locked out of their funds. Cancellation is initiated on the
destination chain and unlocks tokens on source in full, including all fees.
[Auto-cancellations](/dln-details/affiliates/auto-cancellations) can handle this automatically after a set timeout (typically 5–15 minutes).
See [cancelling an order](/dln-details/integration-guidelines/order-creation/cancelling-order) for the full flow and
[execution model](/home/architecture/execution-model) for how orders work.
## Product-Specific Security
### deBridge Liquidity Network (DLN) Security
* **Order determinism**: [Order ID](/dln-details/protocol-specs/deterministic-order-id) computed from parameters, tamper-proof
* **Guaranteed rates**: Quoted rate is locked — no slippage
* **Cancellation rights**: Users can cancel unfulfilled orders
DLN is built on top of the deBridge Messaging Protocol and inherits its security model, including multi-validator consensus and economic security guarantees.
### deBridge Messaging Protocol (DMP) Security
The messaging protocol uses a decentralized validator network:
* **Multi-validator consensus**: Messages require threshold signatures
* **Decentralized storage**: Signatures stored on Arweave
* **Trustless claiming**: Anyone can claim with valid signatures
For detailed DMP security, see [DMP Security](/dmp-details/dmp/security).
## Comparison to Traditional Bridges
| Risk | Traditional Bridges | deBridge |
| ------------------------ | ----------------------- | -------------------------------------------- |
| Locked asset theft | High (TVL honeypot) | Eliminated (0-TVL) |
| Wrapped token depegging | Possible | N/A (native tokens) |
| Validator key compromise | Single point of failure | Threshold required |
| Smart contract bugs | Affects all users | Isolated per trade |
| Funds stuck in escrow | Common | Mitigated (cancellation + auto-cancellation) |
## Audits
deBridge smart contracts are audited by leading security firms:
* Halborn
* Neodyme
* Zokyo
Audit reports are available in the [deBridge Security repository](https://github.com/debridge-finance/debridge-security).
## Bug Bounty
deBridge maintains an active [bug bounty program on Immunefi](https://immunefi.com/bug-bounty/debridge/information/) for responsible
disclosure of security vulnerabilities.
## Security Resources
* [DMP Security](/dmp-details/dmp/security)
* [Slashing & Delegated Staking](/dmp-details/dmp/slashing-and-delegated-staking)
* [DLN Deployed Contracts](/dln-details/overview/deployed-contracts)
* [DMP Deployed Contracts](/dmp-details/dmp/deployed-contracts)
# Chain Abstraction
Source: https://docs.debridge.com/home/use-cases/chain-abstraction
Build chain-abstracted apps with deBridge
Chain abstraction hides the complexity of multi-chain execution from users. They interact with your app without worrying about
which chain their assets are on or where execution happens.
deBridge is building a new execution primitive called **[Bundles](/home/bundles)** that makes chain abstraction a first-class
capability. Bundles let users express what outcome they want, and the system handles the execution flow across chains, abstracting
away fragmented liquidity, native gas balances, and cross-chain orchestration.
Bundles are currently in private rollout. See the [Bundles overview](/home/bundles) to learn more and request access.
# Hooks & Workflows
Source: https://docs.debridge.com/home/use-cases/hooks
Build complex cross-chain workflows with Hooks
Hooks enable arbitrary contract calls after cross-chain trades. This unlocks powerful workflows: move assets across chains, swap,
and deposit into a protocol — all in a single user action.
## What Are Hooks?
Hooks are contract calls that execute after your cross-chain swap completes. They let you trigger actions like deposits, staking,
or liquidity provision on the destination chain without requiring users to manage multiple transactions.
## DLN Hooks
DLN hooks are available for integrations using the deBridge Liquidity Network API.
* **Hooks**: Execute after cross-chain swaps — deposit, stake, add liquidity
* **Gas payment**: User pays gas on source chain
* **Caller identity**: DLN contract (not user's EOA) — target protocol must support beneficiary parameters like `onBehalfOf`
### DLN Hook Options
**EVM chains** support configurable hook behavior:
* **`isNonAtomic`** (true/false): When `false` (atomic), the hook executes within the same transaction as order fulfillment. When
`true` (non-atomic), the hook executes in a separate transaction.
* **`isSuccessRequired`** (true/false): When `true`, hook failure prevents the order from being filled. When `false`, the order
completes even if the hook fails.
**Solana** only supports non-atomic success-required hooks. The hook executes as serialized instructions after order fulfillment.
[DLN Hooks Guide](/dln-details/integration-guidelines/order-creation/hooks/integrating-hooks) |
[EVM Hook Anatomy](/dln-details/protocol-specs/evm-chains-hook-anatomy)
## Next Steps
* [DLN Hooks Guide](/dln-details/integration-guidelines/order-creation/hooks/integrating-hooks)
* [DLN EVM Hook Anatomy](/dln-details/protocol-specs/evm-chains-hook-anatomy)
# Cross-Chain Messaging
Source: https://docs.debridge.com/home/use-cases/messaging
Send arbitrary messages and execute calls across chains
Cross-chain messaging via the deBridge Messaging Protocol (DMP) is **not relevant to most API integrations**. It deals with
cross-chain authenticated messages and arbitrary data transfer — not value transfers or swaps. For swaps, onboarding, and hooks,
see the [deBridge Liquidity Network API](/dln-details/overview/introduction).
For use cases beyond asset transfers, the deBridge Messaging Protocol (DMP) enables arbitrary cross-chain message passing and
contract calls. DMP is the foundational messaging layer for the rest of the
[deBridge products](/home/products/dln-overview), which are built on top of it.
## When to Use DMP
DMP is the right choice when you need:
* **Arbitrary data transfer**: Send any data across chains
* **Cross-chain contract calls**: Trigger actions on remote contracts
* **Custom protocol building**: Build cross-chain applications from scratch
* **Governance**: Cross-chain voting and execution
### Primary Use Case: dePort
The most prominent use case for DMP is **[dePort](/dmp-details/dePort/getting-started)** — multi-chain asset deployment. dePort
uses DMP to create and manage synthetic representations of assets across chains, enabling protocols to deploy their tokens on
multiple chains with canonical bridging powered by deBridge's validator network.
## DMP vs DLN
| Aspect | DMP | DLN |
| -------------------------- | ---------------------------------------- | -------------------------------- |
| **Purpose** | Arbitrary messaging | Value transfer & swaps |
| **Data payload** | Any arbitrary data | Trade/swap instructions |
| **Execution** | Custom receiver contracts | Built-in fulfillment via solvers |
| **Integration complexity** | Higher (custom smart contracts required) | Lower (API-based) |
| **Authenticated messages** | Yes (via `PROXY_WITH_SENDER`) | N/A |
| **Use case** | Custom protocols, dePort. | Swaps, onboarding |
## How DMP Works
1. **Send message**: Contract calls `deBridgeGate.send()` with your data
2. **Validation**: deBridge validators wait for finality, then sign the message
3. **Storage**: Signatures stored on Arweave (permanent, decentralized)
4. **Claim**: Anyone can claim and execute on destination chain
5. **Execute**: Your receiver contract processes the message
```mermaid theme={null}
flowchart TD
subgraph src["Source Chain"]
direction LR
A["Source Contract"] -->|send| B["deBridge Gate"]
end
subgraph off["Off-Chain"]
direction LR
C["deBridge Validators"] -->|sign| D["Arweave"]
end
subgraph dst["Destination Chain"]
direction LR
E["deBridge Gate"] -->|execute| F["Receiver Contract"]
end
src -->|validate| off
off -->|claim| dst
```
## Key Concepts
### Authenticated Messages
DMP supports authenticated messages, allowing receiver contracts to verify the origin of cross-chain calls. When you set the
`PROXY_WITH_SENDER` flag, the [CallProxy](/dmp-details/dev-guides/evm/periphery/CallProxy) contract exposes:
* **`submissionNativeSender`**: The address that initiated the message on the source chain
* **`submissionChainIdFrom`**: The chain ID where the message originated
See the [Building EVM dApp guide](/dmp-details/dev-guides/evm/building-evm-dapp) for a complete example.
### Validators
deBridge validators:
* Monitor all supported chains
* Sign messages after finality is reached
* Store signatures in Arweave (permanent storage)
* Enable trustless claiming
## Getting Started with DMP
1. **Understand the protocol**: [Protocol Overview](/dmp-details/dmp/protocol-overview)
2. **Review security model**: [Security](/dmp-details/dmp/security)
3. **Build your dApp**: [Building EVM dApp](/dmp-details/dev-guides/evm/building-evm-dapp)
4. **Deploy and test**: [Development Tools](/dmp-details/dev-guides/development-tools)
## Next Steps
* [DMP Protocol Overview](/dmp-details/dmp/protocol-overview)
* [Cross-Chain Call Lifecycle](/dmp-details/dev-guides/cross-chain-call-lifecycle)
* [EVM Integration Guide](/dmp-details/dev-guides/evm/introduction)
* [Solana Integration Guide](/dmp-details/dev-guides/solana/sending-cross-chain-messages)
* [dePort — Multi-Chain Asset Deployment](/dmp-details/dePort/getting-started)
# User Onboarding
Source: https://docs.debridge.com/home/use-cases/onboarding
Choose how to onboard users and liquidity to your app with one-click deposits
Getting users onto your chain or into your protocol with assets from any source chain is a key cross-chain use case. The deBridge Liquidity Network supports deposit flows through hooks.
## deBridge Liquidity Network (DLN)
DLN with hooks is available for integrations where users are comfortable managing gas and submitting transactions directly.
### DLN Hook Limitations
DLN hooks execute in a trustless manner — the deposited funds are sent directly to the protocol contract during order fulfillment.
However, because the deposit is not executed by the user's wallet, the target protocol must have a function that accepts a
beneficiary address parameter.
**Compatible pattern**: Protocols like Aave V3 that offer `supply(asset, amount, onBehalfOf, referralCode)` work well — the
`onBehalfOf` parameter allows specifying who receives the deposit credit.
**Incompatible pattern**: Protocols that only offer `deposit(amount)` and credit `msg.sender` cannot be used with DLN hooks, since
the depositor would be the DLN contract, not the user.
## Next Steps
* [DLN Widget Integration](/dln-details/widget/deBridge-widget)
* [DLN Hooks Guide](/dln-details/integration-guidelines/order-creation/hooks/integrating-hooks)
* [Hooks & Workflows Use Case](/home/use-cases/hooks)
# Swaps
Source: https://docs.debridge.com/home/use-cases/swaps
Integrate cross-chain and same-chain swaps in your app
deBridge enables **cross-chain and same-chain swaps** from a single integration — with unified liquidity and non-custodial
execution.
Depending on your product and UX needs, you can integrate swaps in two different ways:
## deBridge Liquidity Network API
Full programmatic control over swaps using the proven DLN infrastructure. The deBridge Liquidity Network follows a familiar
**transaction-based model** — users sign and submit transactions directly, paying gas on the source chain.
* **Same-chain swaps**: Supported via [Same-Chain Swaps API](/dln-details/integration-guidelines/same-chain-swaps/executive)
* **Cross-chain swaps**: Full support with [PostHooks](/home/use-cases/hooks)
* **User experience**: Traditional — user pays gas on source chain
**Best for**: Integrations where users are comfortable with standard transaction flows
[DLN API Quickstart](/dln-details/integration-guidelines/order-creation/creating-order/quick-start) |
[API Documentation](/dln-details/integration-guidelines/order-creation/creating-order/quick-start)
## Widget
The fastest way to add swap functionality. The Widget is a drop-in UI component that uses the deBridge Liquidity Network API under
the hood.
* **Same-chain swaps**: Supported
* **Cross-chain swaps**: Supported
* **Customization**: Theme, default chains/tokens, supported assets
**Best for**: Quick integration with pre-built UI
[Widget Documentation](/dln-details/widget/deBridge-widget)
## Quick Comparison
| Aspect | DLN API | Widget |
| --------------------- | --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| **Same-chain swaps** | Yes | Yes |
| **Cross-chain swaps** | Yes | Yes |
| **Fee structure** | [Flat + %](/dln-details/overview/fee-structure#order%E2%80%91creation-fees-always-paid) | [Flat + %](/dln-details/overview/fee-structure#order%E2%80%91creation-fees-always-paid) |
| **Custom UI** | Full control | Limited |
| **Hooks support** | Yes (After-trade only) | Yes (After-trade only) |
| **Execution model** | Transaction-based | Transaction-based |
## How Swaps Work (High-Level)
1. **Define a swap** e.g. "Swap SOL on Solana to USDC on Base"
2. **deBridge finds routes & liquidity** The protocol identifies the best path for the swap, whether same-chain or cross-chain.
3. **Execution & settlement** The user signs and submits one transaction on the source chain, locking the input tokens.
4. **User receives tokens**
* **Same-chain** swaps execute atomically, within the same transaction they were created in.
* **Cross-chain** swaps are fulfilled by supplying the requested tokens on the destination chain, typically within a few
seconds.
deBridge protocol is comlpetely decentralized, and deBridge has no way of holding user funds. Should users choose to
[cancel](/dln-details/integration-guidelines/order-creation/cancelling-order) a cross-chain order, they can do so before the order
is filled on the destination chain.
Partners can also request to enable [auto-cancellations](/dln-details/affiliates/auto-cancellations) for their integrations.
## Swap Use Cases
* **Wallets & portfolio apps** — Add cross-chain and same-chain swaps directly into wallet interfaces, letting users trade any
token across chains without leaving the app.
* **Trading platforms & DEX aggregators** — Offer same-chain best-price execution via adaptive slippage alongside cross-chain
swaps, all through a single API.
* **DeFi protocols routing liquidity** — Move or rebalance protocol-owned liquidity across chains programmatically, with
guaranteed rates and zero slippage regardless of order size.
* **Cross-chain onboarding & workflows** — Combine a swap with follow-up actions using [Hooks](/home/use-cases/hooks): buy a token
on a new chain, top up native gas, and deposit into a protocol, all in a single transaction.
## Next Steps
* [DLN API Quickstart](/dln-details/integration-guidelines/order-creation/creating-order/quick-start)
* [Widget Integration](/dln-details/widget/deBridge-widget)
* [Same-Chain Swaps](/dln-details/integration-guidelines/same-chain-swaps/executive)
Yes — both options support same-chain and cross-chain swaps.
Yes. deBridge never takes custody of user funds. Assets are delivered directly to the destination wallet.
* DLN API / [Widget](/dln-details/widget/deBridge-widget): Flat fee + percentage fee
* DLN API: Full control - [Widget](/dln-details/widget/deBridge-widget): Limited customization
# What is deBridge?
Source: https://docs.debridge.com/home/welcome
Swap, bridge, and program actions across chains with non-custodial, 0-TVL execution
deBridge is a **non-custodial execution layer** for **cross-chain** and **same-chain** actions. It uses a 0-TVL architecture where
competitive solvers provide liquidity on-demand, with no shared liquidity pools.
deBridge handles liquidity, cross-chain messaging, and execution. For same-chain swaps, it compares outcomes across aggregators to
deliver the best rate. For cross-chain trades, it coordinates settlement through the [deBridge Liquidity Network (DLN)](/home/products/dln-overview).
deBridge has processed **\$20B+ in cross-chain volume** across 25+ blockchains and is non-custodial by design.
[Bundles](/home/bundles), a new execution primitive for intent-based, chain-agnostic interactions, is currently in private rollout.
***
## What Can You Build?
deBridge powers applications that need **cross-chain execution**. Typical use cases include:
* [Same-Chain and Cross-Chain Swaps](/home/use-cases/swaps) inside your app\
Let users trade any token across chains without leaving your product.
* [One-click onboarding and transactions](/home/use-cases/onboarding)\
Onboard users from any chain into your product.
* [Automated cross-chain workflows](/home/use-cases/hooks)\
Trigger DeFi actions across chains with hooks.
* [Chain abstraction](/home/use-cases/chain-abstraction) (coming soon)\
Build chain-abstracted apps with [Bundles](/home/bundles).
If your product spans multiple chains — or hides them entirely — **deBridge is the execution layer**.
***
## How It Works
deBridge coordinates cross-chain and same-chain execution end-to-end. For same-chain swaps, deBridge compares outcomes across
aggregators to deliver the best rate. For cross-chain trades, orders are fulfilled through the deBridge Liquidity Network.
A user or application specifies what they want to happen.\
*Example: "Swap SOL on Solana to USDC on Base."*
deBridge routes and executes the trade using:
* **Unified liquidity** from a [competitive network](/home/architecture/execution-model)
* **Secure cross-chain messaging** via the [deBridge Messaging Protocol](/home/use-cases/messaging)
* **MEV-protected settlement** to ensure predictable outcomes
* Optional [hooks](/home/use-cases/hooks) or contract calls run automatically
The outcome is delivered to the destination chain wallet. Quoted rates are guaranteed.
## Execution & Fund Safety
When a user creates an order, the input tokens are deposited into the `DlnSource` smart contract on the source chain. The order is
then fulfilled on the destination chain, delivering the requested tokens to the recipient.
Smart contracts act as pipes, not pools. Funds pass through briefly on a per-order basis.
* **No shared liquidity pools**\
Each order is independent. There is no pooled TVL for attackers to target.
* **Guaranteed recovery**\
If an order is not fulfilled, users can always
[cancel and reclaim](/dln-details/integration-guidelines/order-creation/cancelling-order) their tokens in full, including all
fees. [Auto-cancellations](/dln-details/affiliates/auto-cancellations) can handle this automatically.
* **No stuck funds**\
User funds are never held on a third-party address. The `DlnSource` contract ensures funds can always be either claimed after
fulfillment or returned to the user via cancellation.
This is enforced by deBridge's [0-TVL architecture](/home/architecture/execution-model).
***
## Integration Options
Low-code universal swaps
Programmatic routing and outcomes
Advanced conditional execution
***
## Getting Started
New to deBridge? Start here to understand the architecture.
Want to ship fast? Jump into integration guides.
Have a specific goal? Find your use case.
Building advanced flows? Learn about hooks.
***
## FAQ
No. deBridge executes [swaps](/home/use-cases/swaps), [contract calls](/home/use-cases/hooks), and conditional logic across
chains. It's an execution layer, not just a bridge.
Yes. deBridge is fully decentralized and cannot retain user funds. The [0-TVL
architecture](/home/architecture/execution-model) means there are no shared liquidity pools. Funds pass through smart contracts
on a per-order basis and can always be reclaimed via
[cancellation](/dln-details/integration-guidelines/order-creation/cancelling-order).
Yes. Same-chain and cross-chain execution are both supported through
the [deBridge Liquidity Network API](/dln-details/integration-guidelines/same-chain-swaps/executive).
If the transaction fails before an order is created, nothing happens and funds remain in the user's wallet. If an order was
created but not fulfilled, users can
[cancel and reclaim](/dln-details/integration-guidelines/order-creation/cancelling-order) their tokens in full.
[Auto-cancellations](/dln-details/affiliates/auto-cancellations) can also handle this automatically.
The user creates an order and deposits tokens into a smart contract on the source chain. The order is fulfilled on the
destination chain, delivering the requested tokens to the recipient. See the
[execution model](/home/architecture/execution-model) for details.
[dePort](/dmp-details/dePort/getting-started) enables multi-chain asset deployment — creating synthetic representations of
assets on other chains. It is powered by the [deBridge Messaging Protocol](/home/products/dmp-overview), the foundational
cross-chain messaging layer. dePort is primarily used for deploying synthetic assets across chains and is separate from the
swap/execution products (DLN).
# SDK & API License Agreement
Source: https://docs.debridge.com/overview/legal
License agreement for using the deBridge SDK and APIs.
Last Updated: 01 October 2025
This API licence agreement (this "Agreement") is entered into as of the date which the Client first accesses, downloads or utilises the Licensor's
APIs (the "Effective Date"), and is a legally binding contract between DXTECH INC., a company incorporated under the laws of Panama (the "Licensor")
and you (the "Client", together with the Licensor the "Parties", and each a "Party"), and applies to the use of the API (as defined herein) and
associated SDK and documentation, available through `https://debridge.com` (the "Website"). If you do not agree to be bound by the terms and
conditions of this Agreement, please do not proceed with the use of the API.
YOU ARE ENTERING A LEGALLY BINDING CONTRACT: BY COPYING, DOWNLOADING, OR OTHERWISE USING THE LICENSOR'S API OR SDK YOU ARE EXPRESSLY AGREEING TO BE
BOUND BY ALL TERMS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THIS AGREEMENT, YOU ARE NOT AUTHORIZED TO COPY, DOWNLOAD, INSTALL OR
OTHERWISE USE THE LICENSOR'S API or SDK.
WE MAY AMEND ANY PORTION OF THIS AGREEMENT AT ANY TIME BY POSTING THE REVISED VERSION OF THIS AGREEMENT AND UPDATING THE "LAST UPDATED" DATE ABOVE.
THE CHANGES WILL BECOME EFFECTIVE IMMEDIATELY AND SHALL BE DEEMED ACCEPTED BY YOU THE FIRST TIME YOU USE OR ACCESS THE API AFTER THE INITIAL POSTING
OF THE REVISED AGREEMENT AND SHALL APPLY ON A GOING-FORWARD BASIS WITH RESPECT TO YOUR USE OF THE API. IN THE EVENT THAT YOU DO NOT AGREE WITH ANY
SUCH MODIFICATION, YOUR SOLE AND EXCLUSIVE REMEDY ARE TO TERMINATE YOUR USE OF THE API.
WHEREAS:
1. The Client desires to license the Licensor's APIs (as defined herein) for the purpose of offering the Cross-chain Bridge Services to the end users
of the Client’s Product (as defined below); and
2. The Licensor desires to license the APIs to the Client for the purposes of the Client providing the Cross-chain Bridge Services to the end users of
the Client’s Product.
NOW THEREFORE in consideration of the mutual covenants and agreements contained in this Agreement and other good and valuable consideration (the
receipt and sufficiency of which are hereby acknowledged by each of the Parties), the Parties hereto agree as follows:
For the purpose of this Agreement:
“deBridge API” or "API" means the Licensor's "deBridge Liquidity Network (DLN)" application program interface(s) and associated SDK and documentation
for a cross-chain smart router algorithm which is an informational service that provides routing information that is used by the DLN Protocol
(deBridge API and its related services), which may include object code, software libraries, software tools, sample source code, published
specifications and documentation. deBridge API shall include any future, updated or otherwise modified version(s) thereof furnished by deBridge (in
its sole discretion) to Client.
"Client's Product" means any web application, mobile application, platform or business offered by the Client to its end users, including the
Cross-chain Bridge Services provided by the Client to its end users.
"Content" means any data and content received by the Client through the APIs, for example pricing or other market data.
"Relevant Blockchain Network" means the Solana blockchain network or such other blockchain network on which the API may provide services in respect
of.
"Cross-chain Bridge Services" means the service relating to decentralised cross-chain bridging of digital assets or cross-chain communications, or
similar services offered directly by the Client to its end users via the Client's Product.
"Term" shall have the meaning ascribed to it in Clause 16(a).
1. API LICENSE
* 1) Subject to the terms and conditions of this Agreement, the Licensor hereby grants to the Client a limited, non-exclusive, non-sublicensable,
non-transferable and non-assignable licence during the Term to: (i) use the API for the purpose of the Cross-chain Bridge Services provided via
the Client's Product; (ii) use the APIs to develop, test, and support the Client's Product; and (iii) display the Content received from the
APIs within the Client's Product. For the avoidance of doubt, the Client agrees that it has no right to distribute or allow access to the
stand-alone APIs to any person.
* 2. The Client agrees that it will devote such resources and undertake such work as may be necessary to integrate the API with the Client’s
Product. The Client agrees that it is solely responsible for the Client's Product, including the development, operation, maintenance and end
user support for the Client's Product.
* 3. In order to access the APIs, the Client must obtain the API keys from the Licensor via their documentation. The Client will be able to obtain
the necessary keys, tokens, passwords and/or other credentials (collectively, "Keys"), for accessing the APIs and managing the Client’s access
to the APIs. The Client acknowledges that it may be required to subscribe and pay for unique API Keys from the Licensor in order to qualify for
higher rate limits for APIs. The Client may only access the APIs with the Keys issued to the Client by the Licensor. The Client acknowledges
that access to the APIs may not always be available. The Client may not sell, transfer, sublicense or otherwise disclose its Keys to any other
party or use them with any other Client's Product or any other purpose other than that expressly permitted by the Licensor. The Client is
responsible for maintaining the secrecy and security of the Keys. The Client is fully responsible for all activities that occur using the Keys,
regardless of whether such activities are undertaken by the Client or a third party. The Client is responsible for maintaining up-to-date and
accurate information (including a current email address and other required contact information) for the Client’s access to the APIs. The
Licensor may discontinue the Client’s access to the APIs if such contact information is not up-to-date and/or the Client does not respond to
communications directed to such coordinates.
* 4. By providing access to the APIs and the Content, the Licensor is solely providing a technical service to the Client which allows the Client to
provide Cross-chain Bridge Services to its end users. The Licensor is not a party to any such agreement for Cross-chain Bridge Services between
the Client, the end user, or any counterparty to said Cross-chain Bridge Services.
* 5. The Client shall use reasonable efforts to cooperate with the Licensor during the Term of this Agreement, including without limitation
providing relevant information, providing relevant documents, and participating in relevant discussions.
2. API DOCUMENTATION
* 1) The Client agrees that its use of the APIs and display of the Content must comply with the technical documentation, usage guidelines, call volume
limits and other documentation related to the APIs, as the same may be updated by the Licensor from time to time (collectively, the "API
Documentation"), access to which the Client acknowledges having received from the Licensor. In the event of any conflict between the API
Documentation and this Agreement, this Agreement shall control.
3. FEES
* 1) The API is provided free of charge below prescribed rate limits as set out in the API documentation. Licensor reserves the right to charge fees
for future use of or access to API or SDK. If the Licensor decides to charge for access to the API or SDK, the Client does not have any
obligation to continue to use such API or SDK. The Client agrees to consult with the Licensor prior to setting the parameters for any fees
charged to its end users for the Cross-chain Bridge Services.
* 2. All sums payable under this licence are exclusive of goods and services tax, withholding tax or and any relevant local sales taxes, for which
the Client shall be responsible.
* 3. If the Client fails to make any payment due to the Licensor under this agreement by the due date for payment, the Client shall pay interest on
the overdue amount at the rate of 6% per annum. Such interest shall accrue on a daily basis from the due date until actual payment of the
overdue amount, whether before or after judgment. The Client shall pay the interest together with the overdue amount.
4. RESTRICTIONS
Except as expressly authorised under this Agreement or by the Licensor in writing, the Client agrees it shall not (and shall not permit or authorise
any other person to):
* 1. use the APIs or the Content in any manner that is not expressly authorised by this Agreement;
* 2. use the APIs or develop or use the Client's Product (i) for any illegal, unauthorised or otherwise improper purposes or (ii) in any manner which
would violate this Agreement or the API Documentation, breach any laws, regulations, rules or orders (including those relating to virtual assets,
intellectual property, data privacy, data transfer, international communications or the export of technical or personal data) or violate the
rights of third parties (including rights of privacy or publicity);
* 3. remove any legal, copyright, trademark or other proprietary rights notices contained in or on materials it receives or is given access to
pursuant to this Agreement, including the APIs, the API Documentation and the Content;
* 4. charge, directly or indirectly, any fees (including any unique, specific, or premium charges) for use of, or access to, the Content, the APIs or
the Client’s integration of the APIs in the Client's Product, except as approved in writing by the Licensor;
* 5. sell, lease, share, transfer or sublicense any Content obtained through the APIs, directly or indirectly, to any third party;
* 6. use the APIs in a manner that, as determined by the Licensor in its sole discretion, exceeds reasonable request volume, constitutes excessive or
abusive usage, or otherwise fails to comply or is inconsistent with any part of the API Documentation;
* 7. access the APIs for competitive analysis or disseminate performance information (including uptime, response time and/or benchmarks) relating to
the APIs;
* 8. use the APIs in conjunction with, or combine content from the APIs with, content obtained through scraping or any other means outside the APIs;
* 9. (i) interfere with, disrupt, degrade, impair, overburden or compromise the integrity of the APIs, the Licensor’s systems or any networks
connected to the APIs or the Licensor’s systems (including by probing, scanning or testing their vulnerability), (ii) disobey any requirements,
procedures, policies or regulations of networks connected to the APIs or the Licensor’s systems, (iii) attempt to gain unauthorised access to
the APIs, the Licensor’s systems or any information not permitted by this Agreement or circumvent any access or usage limits imposed by the
Licensor or (iv) transmit through the Client's Product or the use of the APIs any (A) content that is illegal, tortious, defamatory, vulgar,
obscene, racist, ethnically insensitive, or invasive of another person’s privacy, (B) content that promotes illegal or harmful activity, or
gambling or adult content, (C) viruses, worms, defects, Trojan horses, or any other malicious programs or code or items of a destructive nature
or (D) materials that could harm minors in any way;
* 10. copy, adapt, reformat, reverse-engineer, disassemble, decompile, download, translate or otherwise modify or create derivative works of the APIs,
the Content, the API Documentation, the Licensor’s website, or any of the Licensor’s other content, products or services, through automated or
other means;
* 11. interfere with the Licensor’s business practices or the way in which it licenses or distributes the APIs;
* 12. make any representations, warranties or commitments (i) regarding the APIs or (ii) on behalf of the Licensor; or
* 13. take any action that would subject the APIs to any third-party terms, including without limitation any open source software licence terms.
* 14. The All trades/intents created through the deBridge API can be fulfilled only by a solver that is verified and designated by deBridge, and shall
not be available for fulfilment by any other party.
* 15. The APIs shall not be used for aggregation purposes. As per the API Agreement, access is not granted for use-cases such as aggregation for
bridging or routing providers, or consolidation across multiple providers.
* 16. The Client shall not use the APIs for the purposes of trade aggregation, routing consolidation, or any similar functionality that combines or
re-routes orders across multiple liquidity providers, protocols, or services. Any use-case involving aggregation is expressly prohibited and not
within the scope of the license granted under this Agreement.
5. PROPRIETARY RIGHTS
* 1) The Licensor owns all rights, title, and interest, intellectual property in and to the APIs (including without limitation all output and
executables or derivative works of the APIs), and, subject to the foregoing, the Client owns all rights, title, and interest in and to the
Client's Product. Except to the limited extent expressly provided in this Agreement, neither Party grants, and the other Party shall not acquire,
any right, title or interest (including, without limitation, any implied licence) in or to any property of the other Party. All rights not
expressly granted herein are deemed withheld.
* 2. The Licensor does not store, send, or receive digital assets. This is because digital assets exist only by virtue of the ownership record
maintained on the Relevant Blockchain Network. Any creation or transfer of title that might occur in respect of any digital asset occurs on the
Relevant Blockchain Network (on the relevant contractual terms applicable to such creation and/or transfer), and the Licensor does not have any
role or responsibility in such transactions. the Licensor cannot guarantee that it, or any party can effect the transfer of such title or right
to any digital asset. Accordingly, the Licensor cannot provide any guarantee, warranty or assurance regarding the authenticity, uniqueness,
originality, quality, marketability, legality or value of any digital assets received in connection with the Cross-chain Bridge Services.
* 3. There may be various vulnerabilities, failures or abnormal behaviour of software relating to digital assets (e.g., token contract, wallet, smart
contract), or relating to the Relevant Blockchain Network, and the Licensor cannot be responsible for any losses in connection with the same,
including without limitation any losses in connection with (i) user error, such as forgotten passwords or incorrectly construed smart contracts
or other transactions, (ii) server failure or data loss, (iii) corrupted wallet files, or (iv) unauthorised access or activities by third
parties, including but not limited to the use of viruses, phishing, brute-forcing or other means of attack against the API, the Relevant
Blockchain Network, or the Client's or its end user's digital wallet.
6. AVAILABILITY, SECURITY AND STABILITY
* 1) The Licensor makes no guarantees with respect to the performance, availability or uptime of the APIs or the Content. The Licensor may conduct
maintenance on or stop providing any of the APIs or the Content at any time with or without written notice to the Client. The Licensor may change
the method of access to the APIs and API Documentation at any time.
* 2. The Parties agree that it is in the best interests of both Parties that the Licensor maintain a secure and stable environment. In the event of
degradation or instability of the Licensor’s system or an emergency, the Licensor may, in its sole discretion, temporarily suspend access to the
APIs or the Content under this Agreement without any requirement to provide prior notice to the Client.
7. CLIENT'S OBLIGATIONS
* 1) The Client agrees to report to the Licensor any errors or difficulties discovered related to the APIs and the characteristic conditions and
symptoms of such errors and difficulties.
* 2. The Client shall endeavour to inform the Licensor with respect to the interoperability and compatibility of the Client's Product with the
Licensor’s systems, the APIs and the Cross-chain Bridge Services as contemplated herein, and any issues or problems with respect thereto. The
Client agrees it will use its best efforts to achieve full interoperability and compatibility with the APIs. The Licensor agrees to use
commercially reasonable efforts to assist the Client with resolving any such issues or problems arising from the interoperability and
compatibility of the Client's Product with the APIs.
* 3. The Client agrees that the Licensor may monitor the use of the APIs to ensure quality, improve the APIs, and verify the Client’s compliance with
the terms of this Agreement.
* 4. The Client shall obtain and maintain in force (or as applicable procure the obtaining and maintenance in force of) all necessary licenses,
permissions, authorisations, consents and permits which may be necessary or desirable for the offering of the Client's Product.
* 5. The Client acknowledges and agrees that all reporting, information gathering and other obligations under applicable know-your-client, anti-money
laundering and anti-terrorist financing laws with respect to the Client’s end-users are the responsibility of the Client and the Licensor shall
not be responsible or have any liability for any of the foregoing. The Client agrees to provide such information to the Licensor if reasonably
requested by the Licensor.
* 6. Without prejudice to the foregoing, upon written request from the Licensor, the Client shall use all efforts to block any specific digital wallet
or address from accessing the Client's Product and/or the API integration.
* 7. The Client acknowledges and agrees that it shall be responsible for implementing and enforcing end user transaction limits to ensure each of its
end users do not use the Cross-chain Bridge Services to complete transactions or a series of transactions that would, alone or in the aggregate
based on transaction size result in reporting obligations by either Party under applicable anti-money laundering and anti-terrorist financing
laws.
* 8. The Client agrees to immediately notify the Licensor if (i) the Client becomes aware of any security event, including any cybersecurity breach,
attack or economic exploit relating to the Client's Product (ii) the Client's Product or the Cross-chain Bridge Services become subject to any
legal or regulatory investigation or action, or (iii) the Client loses any intellectual property rights in the Client's Product or becomes aware
of any third-party claim in respect of the same.
* 9. The Client shall be responsible for all customer service for all its products and services (including the Client's Product).
* 10. The Client acknowledges and agrees that any swap surplus, positive slippage or equivalent proceeds resulting from the execution of trades via
the API shall be retained by the Licensor.
8. FEEDBACK
In the event the Client chooses to provide the Licensor with feedback, suggestions or comments regarding the APIs or the API Documentation, or the
Client and its end users’ use thereof, the Client agrees to provide a fully-paid up, royalty-free, non-exclusive, worldwide, transferable,
sublicensable, irrevocable right and license under all of the Client’s intellectual property rights to the Licensor to use, copy, modify, create
derivative works, distribute, publicly perform, grant sublicenses to, and otherwise exploit in any manner such feedback, suggestions or comments, for
any and all purposes, with no obligation of any kind to the Client.
9. REPRESENTATIONS AND WARRANTIES
Each Party represents and warrants to the other Party that:
* 1. it is duly organised, validly existing and in good standing under the laws of the jurisdiction in which it was organised and has the power to
enter into this Agreement and perform its obligations hereunder;
* 2. this Agreement has been duly authorised, executed and delivered by it and is a legal, valid and binding obligation of it, enforceable against it
by the other Party in accordance with its terms, except as enforcement may be limited by bankruptcy, insolvency and other laws affecting the
rights of creditors generally and except that equitable remedies may be granted only in the discretion of a court of competent jurisdiction; and
* 3. the execution and delivery of this Agreement by it and the consummation of the transactions herein provided for will not result in the violation
of, or constitute a default under, or conflict with or cause the acceleration of any obligation of it under: (i) any contract or agreement to
which it is a party or by which it is bound; (ii) any provision of its constating documents, by-laws or resolutions; (iii) any judgment, decree,
order or award of any court, governmental body or arbitrator having jurisdiction over it; or (iv) any applicable law, statute, ordinance,
regulation or rule.
10. CONFIDENTIALITY
* 1) The Parties agree that for purposes of this Agreement, "Confidential Information" means all information which is non-public, confidential or
proprietary in nature, whether transferred in writing, orally, visually, electronically or by other means, disclosed by one Party (the
"Disclosing Party") to the other Party (the "Receiving Party"), including the APIs, the Content (including all improvement, derivatives,
modifications and the like), the Application, the terms of this Agreement and any reports, analyses or notes that are based on, reflect or
contain Confidential Information. Confidential Information shall not include any information that: (i) is or becomes generally known to the
public other than as a result of a disclosure, in violation of this Agreement, by the Receiving Party, its affiliates or any of their officers,
directors, employees, agents, advisors, accountants, lawyers, auditors or representatives who have been informed of the Confidential Information
(collectively, the "Representatives"); (ii) was available or known to the Receiving Party or its Representatives before its disclosure hereunder;
(iii) is or becomes available to the Receiving Party or its Representatives from a source other than the Disclosing Party or its Representatives,
provided that the source of such information was not known by the Receiving Party or its Representatives to be prohibited from disclosing such
information to the Receiving Party or its Representatives by a legal, contractual or fiduciary obligation; or (iv) has otherwise been
independently acquired or developed by the Receiving Party or its Representatives without violating any obligations under this Agreement.
* 2. Each Receiving Party hereby agrees: (i) to hold the Confidential Information in confidence and to take reasonable precautions to protect such
Confidential Information (including all precautions the Receiving Party employs with respect to its own Confidential Information); (ii) not to
divulge any Confidential Information to any person except its Representatives, subject to the conditions stated below; (iii) not to use any
Confidential Information except for the purposes set forth in this Agreement; (iv) not to copy or reverse engineer any Confidential Information;
and (v) to be liable for any breaches by the Receiving Party’s Representatives of the provisions of this Agreement dealing with restrictions on
disclosure and use of the Confidential Information. Any Representative given access to the Confidential Information must have a legitimate "need
to know" and shall be permitted access to the Confidential Information only to the extent necessary to allow them to assist the Receiving Party
in meeting its obligations under this Agreement. Each Receiving Party further agrees that prior to granting such Representatives access to the
Confidential Information, the Receiving Party shall inform such Representatives of the confidential nature of the Confidential Information and of
the confidentiality obligations of this Agreement and require such Representatives to agree to abide by all the terms included herein.
* 3. If a Receiving Party or any of its Representatives is requested to disclose any Confidential Information in connection with any legal or
administrative proceeding or investigation, or is required by law, regulation, stock exchange or regulatory authority to disclose any
Confidential Information, such person will: (i) promptly notify the Disclosing Party of the existence, terms and circumstances surrounding such a
request or requirement (unless prohibited by law, regulation or order of a court or administrative tribunal) so that the Disclosing Party may
seek a protective order or other appropriate remedy, or waive compliance with the provisions of this Agreement; and (ii) if, in the absence of a
protective order, such disclosure is required in the opinion of such person's counsel, such person may make such disclosure without liability
under this Agreement, provided that such person only furnishes that portion of the Confidential Information which is legally required, gives the
Disclosing Party notice of the information to be disclosed as far in advance of its disclosure as practicable (unless prohibited by law,
regulation or order of a court or administrative tribunal) and, upon the Disclosing Party's request and at the Disclosing Party's expense,
cooperates in any efforts by the Disclosing Party to ensure that confidential treatment shall be accorded to such disclosed Confidential
Information.
* 4. As soon as practicable after termination of this Agreement or receipt of a notice from the Disclosing Party to the Receiving Party, the Receiving
Party shall: (i) at its election, either destroy or return to the Disclosing Party all Confidential Information furnished by the Disclosing Party
which is in tangible or electronic form, including any copies which the Receiving Party or its Representatives have made; and (ii) certify to the
Disclosing Party, in writing, that the Receiving Party has done the foregoing. Any Confidential Information that is not returned or destroyed,
including, without limitation, any oral Confidential Information, will remain subject to the confidentiality obligations set forth in this
Agreement. Notwithstanding the foregoing, the Receiving Party may retain: (A) one copy of the Confidential Information solely for evidentiary
purposes in the event of any dispute or proceeding based on or arising from this Agreement; (B) copies of any computer records and files
containing any Confidential Information that have been created pursuant to the Receiving Party’s automatic electronic archiving and back-up
procedures until such computer records and files have been deleted in the ordinary course; and (C) one copy of any Confidential Information to
the extent retention of such Confidential Information is required to comply with applicable law or regulation.
* 5. Each Receiving Party understands and agrees that monetary damages would not be a sufficient remedy for any breach of this Clause 10 by the
Receiving Party or its Representatives and that, in addition to all other remedies, the Disclosing Party shall be entitled to specific
performance or injunctive or other equitable relief as a remedy for any such breach. Each Receiving Party agrees to waive, and to cause its
Representatives to waive, any requirement for the securing or posting of any bond or security in connection with such remedy.
11. PUBLICITY
* 1) Subject to the obligations under Clause 10 each of the Parties agrees that the other Party may disclose and publicise the existence of the
business relationship between the Licensor and the Client on its website and in promotional and marketing materials upon consent of the other
Party.
* 2. Subject always to the Licensor's marketing and communications criteria for co-marketing of products (at its sole discretion), the Parties shall
use reasonable efforts to mutually engage in cross-marketing activities to highlight the co-operation between the Parties in official
communications.
* 3. The Parties shall mutually agree on the contents, scope and medium of publicity for the other Party's brand or all associated advertising,
promotional or marketing materials (including on social media), including without limitation clearly featuring the other Party's brand on
applications, websites, Video tutorials, co-authoring marketing materials on Twitter Spaces, Discord Stages, or Community Events, public
relations and/or relevant social media posts and announcements.
12. INDEMNITY
The Client agrees that the Licensor and its affiliates and their respective shareholders, directors, officers, employees, representatives, agents,
contractors, customers and licensees (collectively, the "Indemnified Parties") shall have no liability whatsoever for, and the Client shall indemnify
and hold harmless the Indemnified Parties from and against, any and all claims, losses, damages, liabilities, costs and expenses (including reasonable
lawyer’s fees) arising from, in connection with or related to: (a) any use the Client or its end users makes of the API, the Content or the
Cross-chain Bridge Services; (b) the Client’s relationships or interactions with any end users or third party distributors of the Client's Product;
(c) the Client's Product; (d) the Client’s breach of the terms of this Agreement or (e) the gross negligence, wilful misconduct or fraud of the
Client, its affiliates and their respective shareholders, directors, officers, employees, representatives, agents, contractors, customers and
licensees.
13. WARRANTY DISCLAIMER
* 1) TO THE FULLEST EXTENT PERMITTED BY LAW, THE APIS AND THE CONTENT ARE PROVIDED "AS IS" AND "WITH ALL FAULTS" AND THE LICENSOR DISCLAIMS ALL
REPRESENTATIONS, WARRANTIES AND GUARANTEES, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING INFRINGEMENT OF THIRD PARTY RIGHTS OR IMPLIED
WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT AND FITNESS FOR ANY PARTICULAR PURPOSE. THE LICENSOR MAKES NO REPRESENTATION, WARRANTY OR
GUARANTEE RELATED TO USEABILITY, EFFECTIVENESS, RELIABILITY, ACCURACY, OR COMPLETENESS OF THE APIS OR THE CONTENT, THAT THE LICENSOR WILL
CONTINUE TO OFFER THE APIS OR THE CONTENT OR THAT USE OF THE APIS OR THE CONTENT WILL BE RELIABLE, EFFECTIVE, SECURE, TIMELY, UNINTERRUPTED,
ERROR-FREE OR MEET THE CLIENT’S OR ITS END USERS’ REQUIREMENTS OR EXPECTATIONS.
* 2. The Client acknowledges that the API and Content, or any software in respect of the same cannot be wholly free from defects, errors, security
vulnerabilities, viruses, errors, failures, bugs or loopholes which may be exploited by third parties, or other harmful components and the
Licensor gives no warranty or representation that the API or Content, or any software in respect of the same will be wholly free from defects,
errors, security vulnerabilities, viruses, errors, failures, bugs or loopholes which may be exploited by third parties, or other harmful
components.
* 3. The Client acknowledges that the Licensor does not warrant or represent that the API, Content, or any software in respect of the same will be
compatible with the Client's Product, any other software or systems, or that the integration will proceed as intended.
* 4. The Licensor does not warrant or represent that the usage of the API and/or the Content by the Client will not give rise to any legal liability
on the part of the Client or any other person.
14. SERVICES DISCLAIMER
* 1) Neither the Licensor nor the API provides any digital asset exchange or brokerage service. Where the Client or any end user of the Client's
Product makes the decision to transact utilising the API or the Content, then such decisions and transactions and any consequences flowing
therefrom are such transacting party's sole responsibility.
* 2. THE API FUNCTIONS SOLELY AS A BACK-END SUPPORTING TECHNICAL SERVICE FOR ON-CHAIN TOKEN CROSS-CHAIN BRIDGE SERVICES, AND IN NO CIRCUMSTANCES SHALL
THE LICENSOR, THE API OR THE CONTENT BE CONSTRUED AS A DIGITAL ASSET EXCHANGE, BROKER, DEALER, FUND MANAGER, FINANCIAL INSTITUTION, CUSTODIAN,
ROBO-ADVISOR, INTERMEDIARY, OR CREDITOR;
* 3. THE API DOES NOT FACILITATE OR ARRANGE DIGITAL ASSET TRANSACTIONS BETWEEN COUNTERPARTIES, INCLUDING WITH RESPECT TO ANY TRANSACTIONS THAT OCCUR
IN CONNECTION WITH ANY DECENTRALISED EXCHANGE, LIQUIDITY POOL OR OTHER CENTRALISED OR DECENTALISED FINANCE PRODUCT / FACILITY, WHICH TRANSACTIONS
OCCUR ON SUCH PLATFORM, PROTOCOL AND/OR THE RELEVANT BLOCKCHAIN NETWORK. THE LICENSOR IS NOT A COUNTERPARTY TO ANY DIGITAL ASSET TRANSACTION
FACILITATED BY THE API, THE CONTENT OR THE CLIENT'S PRODUCT. NEITHER THE LICENSOR, THE API OR THE CONTENT PROVIDES FINANCIAL ADVISORY, LEGAL,
REGULATORY, OR TAX SERVICES DIRECTLY, INDIRECTLY, IMPLICITLY, OR IN ANY OTHER MANNER, AND YOU SHOULD NOT CONSIDER ANY API OR CONTENT TO BE A
SUBSTITUTE FOR PROFESSIONAL FINANCIAL, LEGAL, REGULATORY, TAX OR OTHER ADVICE. THE LICENSOR DOES NOT SUPPORT OR ENDORSE ANY DECENTRALISED
EXCHANGE, LIQUIDITY POOL OR OTHER CENTRALISED OR DECENTALISED FINANCE PRODUCT / FACILITY, AND EACH SUCH ENTITY OR BUSINESS IS AN INDEPENDENT
AGENT WITH NO EMPLOYMENT OR OTHER CONTRACTUAL RELATIONSHIP WITH THE LICENSOR.
15. LIMITATION OF LIABILITY
* 1) TO THE FULL EXTENT PERMITTED BY LAW, IN NO EVENT WILL THE LICENSOR BE LIABLE FOR ANY LOSS OF USE, LOST OR INACCURATE DATA (INCLUDING WITHOUT
LIMITATION PRICES OR QUOTES), ERRORS, FAILURE OF SECURITY MECHANISMS, INTERRUPTION OF BUSINESS, COST OF PROCUREMENT OF SUBSTITUTE GOODS, SERVICES
OR TECHNOLOGY OR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY KIND (INCLUDING LOST PROFITS OR LOST DATA), REGARDLESS OF THE
FORM OF ACTION, WHETHER IN CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY OR OTHERWISE, EVEN IF INFORMED OF THE POSSIBILITY OF SUCH
DAMAGES IN ADVANCE. TO THE FULL EXTENT PERMITTED BY LAW, IN NO EVENT WILL THE LICENSOR’S AGGREGATE LIABILITY FOR ANY AND ALL CLAIMS, LOSSES,
DAMAGES, LIABILITIES, COSTS AND EXPENSES (INCLUDING REASONABLE LAWYER’S FEES) ARISING FROM, IN CONNECTION WITH OR RELATED TO THIS AGREEMENT, THE
APIS AND THE CONTENT EXCEED THE HIGHER OF (I) USD 200 OR (II) THE PORTION OF THE FEES PAID BY THE CLIENT TO THE LICENSOR IN THE THREE (3) MONTHS
PRIOR TO SUCH CLAIM. NOTWITHSTANDING ANYTHING TO THE CONTRARY, THE LICENSOR HAS NO WARRANTY, INDEMNIFICATION OR OTHER OBLIGATION OR LIABILITY
WITH RESPECT TO THE CLIENT'S PRODUCT OR ITS COMBINATION, INTERACTION, OR USE WITH ANY CROSS-CHAIN BRIDGE SERVICES, THE APIS OR THE CONTENT.
* 2. Without prejudice to the generality of the foregoing, the Client acknowledges that the API(s) and Content is provided "as-is", so the Licensor
shall not be liable in any manner for any direct, indirect, special, incidental or consequential loss, damage, liability, costs or expenses
suffered by the Client due to any incorrect, delayed or lost data, price information, quotes, routing or any other attribute, information or
factor relating to the API(s) or Content, regardless of the form of action, whether in contract, tort (including negligence), strict liability or
otherwise, and whether or not due to defects, errors, security vulnerabilities, viruses, errors, failures, bugs or loopholes which may be
exploited by third parties, or other harmful components.
* 3. The Client acknowledges and agrees that this Clause 15 reflects a reasonable allocation of risk and that the Licensor would not have entered into
this Agreement without these liability limitations.
* 4. This Clause 15 will survive notwithstanding any limited remedy’s failure of essential purpose.
16. TERMINATION; SURVIVAL
* 1) This Agreement shall commence as of the Effective Date until terminated in accordance with the provisions herein (the Term).
* 2. Either Party may terminate this Agreement immediately if the other Party:
* * 1. breaches any material term of this Agreement and such breach has not been rectified within 15 days of notice of such breach to the other Party;
or
* * 2. (A) becomes insolvent, (B) fails to pay its debts or perform its obligations in the ordinary course of business as they mature, (C)
admits in writing its insolvency or inability to pay its debts or perform its obligations as they mature or (D) become the subject of any
voluntary or involuntary proceeding in bankruptcy, liquidation, dissolution, receivership, attachment or composition or general assignment for
the benefit of creditors that is not dismissed with prejudice within 30 days after the institution of such proceeding.
* 3. Notwithstanding any of the provisions herein, the Licensor shall have the right to terminate this Agreement upon ten (10) days' written notice to
the Client.
* 4. Upon termination of this Agreement, the Licensor may immediately revoke all of the Keys provided to the Cross-chain Bridge Services and/or the
APIs. The Parties shall also comply with the provisions regarding Confidential Information under Clause 10(b). Any termination of this Agreement
shall automatically terminate the licenses granted hereunder.
* 5. Clauses 4, 5, 10, 12, 13, 15, 16 and 17 (and any accrued rights to payment) shall survive termination of this Agreement.
17. GENERAL
* 1) Except as may be otherwise specifically provided in this Agreement and unless the context otherwise requires, in this Agreement: (i) the terms
"Agreement", "this Agreement", "the Agreement", "hereto", "hereof", "herein", "hereby", "hereunder" and similar expressions refer to this
Agreement in its entirety and not to any particular provision hereof; (ii) references to a "Clause" or "Schedule" followed by a number or letter
refer to the specified Clause of or Schedule to this Agreement; (iii) the division of this Agreement into sections and the insertion of headings
are for convenience of reference only and shall not affect the construction or interpretation of this Agreement; (iv) words importing the
singular number only shall include the plural and vice versa and words importing the use of any gender shall include all genders; (v) the word
"including" is deemed to mean "including without limitation"; (vi) the terms "Party" and "the Parties" refer to a Party or the Parties to this
Agreement; (vii) any reference to this Agreement means this Agreement as amended, modified, replaced or supplemented from time to time; (viii)
any reference to a statute, regulation or rule shall be construed to be a reference thereto as the same may from time to time be amended,
re-enacted or replaced, and any reference to a statute shall include any regulations or rules made thereunder; (ix) any time period within which
a payment is to be made or any other action is to be taken hereunder shall be calculated excluding the day on which the period commences and
including the day on which the period ends; and (x) whenever any payment is required to be made, action is required to be taken or period of time
is to expire on a day other than a "Business Day", being any day other than a Saturday, Sunday or statutory holiday in Panama on which commercial
banks in Panama are open for business, such payment shall be made, action shall be taken or period shall expire on the next following Business
Day.
* 2. The Parties agree that they are independent contractors under this Agreement and nothing in this Agreement authorises either Party to act as a
legal representative or agent of the other for any purpose. It is expressly understood that this Agreement does not establish a franchise
relationship, partnership, principal-agent relationship, or joint venture. Neither Party shall have the power to bind the other with respect to
any obligation to any third Party.
* 3. This Agreement shall be interpreted and enforced in accordance with, and the respective rights and obligations of the Parties shall be governed
by, the laws of Panama. Any controversy or dispute which arises out of or is related to this Agreement, and interpretation, application,
performance or termination thereof, must be decided by arbitration, following an attempt at Conciliation, administered by Panama Conciliation and
Arbitration Centre in accordance with its procedural rules for the time being in force. The tribunal shall consist of 1 arbitrator, who shall
have exclusive authority to decide all issues relating to the interpretation, applicability, enforceability and scope of this Agreement
(including this arbitration agreement). The language used in the arbitral proceedings shall be English. Each Party irrevocably submits to the
jurisdiction and venue of such tribunal. Judgment upon the award may be entered by any court having jurisdiction thereof or having jurisdiction
over the relevant Party or its assets.
* 4. No amendment or waiver of any provision of this Agreement shall be binding on any Party unless consented to in writing by such Party. No waiver
of any provision of this Agreement shall constitute a waiver of any other provision, nor shall any waiver of any provision of this Agreement
constitute a continuing waiver unless otherwise expressly provided.
* 5. If any provision of this Agreement is determined by a court of competent jurisdiction to be invalid, illegal or unenforceable in any respect, all
other provisions of this Agreement shall nevertheless remain in full force and effect so long as the economic or legal substance of the
transactions contemplated hereby is not affected in any manner materially adverse to any Party hereto.
* 6. This Agreement shall ensure to the benefit of and shall be binding on and enforceable by and against the Parties and their respective successors
or heirs, executors, administrators and other legal personal representatives, and permitted assigns.
* 7. No Party may assign any of its rights or benefits under this Agreement, or delegate any of its duties or obligations, except with the prior
written consent of the other Party. Notwithstanding the foregoing, any Party may assign and transfer all of its rights, benefits, duties and
obligations under this Agreement in their entirety, without the consent of the other Party, to: (i) an affiliate, provided that the assignor
shall continue to be subject to the rights and obligations of this Agreement; or (ii) a purchaser of all or substantially all of the business of
the assignor, provided that the assignor promptly provides notice to the non-assigning Party, the successor in interest has agreed to assume all
of the assignor’s rights and obligations and the non-assigning Party has the right to terminate the Agreement upon receipt of notice of transfer
if the successor in interest, in the non-assigning Party’s sole reasonable determination, is a competitor of the non-assigning Party.
* 8. Any notice or other communication required or permitted to be given hereunder shall be in writing and shall be delivered by e-mail or similar
means of recorded electronic communication to the contact details set out in the signature page. Any such notice or other communication shall be
deemed to have been given and received, in the case of electronic mail, at the time that it is received in recipient’s inbox in readable form,
provided that such electronic mail is kept on file (whether electronically or otherwise) by the sending party and the sending party does not
immediately receive an automatically generated message from the recipient’s electronic mail server that such electronic mail could not be
delivered to such recipient. Any Party may at any time change its contact details for service from time to time by giving notice to the other
Party in accordance with this Clause 17(8).
* 9. This Agreement constitutes the entire agreement between the Parties with respect to the subject matter hereof and supersedes all prior
agreements, understandings, negotiations, and discussions, whether written or oral. There are no conditions, covenants, agreements,
representations, warranties, or other provisions, express or implied, collateral, statutory or otherwise, relating to the subject matter hereof
except as provided herein.
* 10. Time shall be of the essence of this Agreement.
* 11. Each Party will pay for its own costs and expenses incurred in connection with the negotiation, preparation, execution and performance of this
Agreement, and the transactions contemplated herein, including the fees and expenses of legal counsel, financial advisors, accountants,
consultants and other professional advisors and software development expenses.
* 12. Neither Party hereto shall be responsible for any failure to perform its obligations under this Agreement if such failure is caused by acts of
God, war, strikes, revolutions, lack or failure of transportation facilities, laws or governmental regulations or other causes that are beyond
the reasonable control of such Party. Obligations hereunder, however, shall in no event be excused but shall be suspended only until the
cessation of any cause of such failure.
* 13. Each of the Parties hereto shall, from time to time hereafter and upon any reasonable request of the other, do, execute, deliver or cause to be
done, executed and delivered, all further acts, documents and things as may be required or necessary for the purposes of giving effect to this
Agreement.
* 14. This Agreement and all documents contemplated by or delivered under or in connection with this Agreement may be executed and delivered in any
number of counterparts, with the same effect as if all Parties had signed and delivered the same document, and all counterparts shall be
construed together to be an original and will constitute one and the same agreement.