Can dePort change a token's name, symbol or decimals?

dePort preserves the original token's name, symbol and decimals when creating a synthetic representation. It does not provide custom destination metadata. The inherited decimal count determines the conversion between displayed quantities and the token's smallest units.

Are NFTs supported by dePort's lock-and-mint product?

dePort supports fungible ERC-20 and SPL tokens on supported networks, while its token-porting product excludes NFTs. DMP can support custom NFT bridges through separate messaging integrations. That broader capability does not establish NFT support in dePort.

How can deAssets move between secondary chains?

dePort supports transfers of deAssets between secondary chains without routing through the native chain. The backing remains on the original token's native chain under the lock-and-mint model. dePort burns the deAsset on the departing secondary chain and mints a corresponding amount on the receiving chain.

Is a DLN cross-chain limit order the same as a same-chain swap?

A cross-chain DLN limit order specifies trading conditions across networks, while a same-chain swap exchanges tokens within one network. The trading application allows limit orders only in USDC and does not provide them for same-chain trades. A cross-chain limit order needs a solver willing to accept its price and economics; placing it does not ensure execution.

Do Hooks authenticate the original sender for a destination contract?

Hooks do not authenticate the original sender by default. An application needing sender authentication must include and verify an authenticated signature in the hook. Authenticating a smart contract as the sender requires DMP. A hook target must not grant permissions simply because a DLN contract made the call, since anyone can create an order carrying arbitrary hook data.

Debridgefinance

Debridgefinance uses DLN for swaps and dePort for wrapped token deployment

Debridgefinance supports token exchanges through the deBridge Liquidity Network (DLN) and synthetic token deployment through dePort, which uses a lock-and-mint model. A cross-chain DLN swap delivers the requested destination asset from a solver's own liquidity. dePort locks the original token and mints a backed deAsset on another supported chain. The choice follows the intended outcome: exchanging an asset or deploying a representation of it across supported networks.

Updated on 16 October, 2026

Bottom line: dePort's collateral backing does not create trading liquidity, so a deployed deAsset can still need a market before it becomes tradable.

DLN swaps and dePort token deployment

DLN supports same-chain swaps and cross-chain trades, while dePort deploys synthetic representations backed by original tokens locked on their native chain. A same-chain swap exchanges tokens within one network. A cross-chain trade specifies an asset to receive on a different network. The destination token can differ from the input token.

dePort addresses a token's availability across networks. An issuer seeking a backed representation on a secondary chain needs asset deployment, which differs from buying an existing token. Once deployed, the representation still needs a market for trading. Creating its contract does not itself provide liquidity or establish an executable DLN route.

Does a DLN swap create a wrapped token?

A cross-chain DLN swap delivers the requested destination token using solver liquidity and does not deploy a new dePort representation. An order can request an asset already issued on the receiving network. Its destination asset field identifies the token deployment or native asset the solver must deliver.

Reserve assets can sit between the token supplied and the one received. These are the assets DLN uses to simplify solver balance management. A non-reserve input may be swapped during order placement, and a solver may convert a reserve asset into the requested destination token. These intermediary swaps do not change the requested output: fulfillment must provide the destination token and amount specified in the order.

A solver must accept the order's economics before fulfillment. Specifying an output does not guarantee a willing counterparty.

What backs a token deployed through dePort?

Each deAsset has one-to-one backing in collateral locked on the original token's native chain. The original token remains in the deBridgeGate contract while its synthetic representation exists on a supported destination chain. It differs from the capital a solver supplies to fulfill an exchange, because dePort's collateral backs the representation's supply. The destination representation has a separate token contract; the original contract does not move between networks.

Open full-size image

Validators wait for source-chain finality, then sign the transfer identifier. The destination contract verifies sufficient signatures when someone submits a claim. On a first transfer, that claim can deploy the deAsset contract automatically. Any wallet can submit valid claim data, while the signed transfer parameters determine the receiver.

DLN parameters define the requested exchange

A cross-chain DLN API request identifies a trade through its networks, asset identifiers and amount settings. These fields specify an exchange into an existing asset rather than instructing dePort to mint a new representation. Asset fields use network-specific token addresses or documented native-asset identifiers. Numeric input amounts use the source asset's smallest units. The input amount can instead be auto for a fixed output, or max for full-balance use with automatic output.

DLN parameters define the requested exchange
Parameter	Expected value	Network, asset or amount requirements
`srcChainId`	Supported source network ID	The network holding the input
`dstChainId`	Supported destination network ID	The network where output is required
`srcChainTokenIn`	Source token address or native-asset identifier	The asset's network-specific source identifier
`dstChainTokenOut`	Destination token address or native-asset identifier	The asset's network-specific destination identifier
`srcChainTokenInAmount`	Integer in smallest units, auto or max	Input decimals for integers; fixed output for auto; automatic output for max
Network IDs, asset identifiers and amount units must describe the same intended exchange.

Debridgefinance: Swap Assets or Create Wrapped Tokens?

What backs a token deployed through dePort?
DLN parameters define the requested exchange
Messaging, Hooks and chain integration
Does DLN's 0-TVL label also apply to dePort?

Open full-size image

Messaging, Hooks and chain integration

The deBridge Messaging Protocol (DMP) carries authenticated cross-chain messages and provides a shared foundation for DLN settlement and dePort deployment. DMP supports remote contract calls and authenticated data transfer. The receiving application determines how it processes that instruction. Sharing this layer does not make the products' asset custody equivalent.

Hooks attach destination-chain actions to DLN orders. Their supported actions include distributing purchased tokens or depositing them into another protocol. A non-atomic hook can remain pending after its order is fulfilled, leaving the output in an intermediary contract. That pending execution state differs from native collateral backing a deAsset.

Interoperability-as-a-Service (IaaS) infrastructure support does not ensure listing in the main application. A supported chain can remain accessible through an integrated widget or the DLN API.

Diagram: Messaging, Hooks and chain integration (Debridgefinance)

Open full-size image

Does DLN's 0-TVL label also apply to dePort?

DLN's 0-TVL design does not describe dePort's custody model, because dePort keeps native collateral locked to back synthetic tokens.

DLN's 0-TVL architecture uses no shared liquidity pools. An individual order can still deposit input tokens in a source-chain contract while it awaits fulfillment or cancellation. Solvers fund destination delivery from their own capital. Temporary order escrow and persistent backing collateral serve different purposes. A successful dePort deployment leaves backing in place, while a completed DLN exchange proceeds through source-side settlement.

DLN also inherits DMP's messaging trust assumptions. The protocol requires sufficient validator signatures before a cross-chain message can be claimed. Avoiding shared liquidity pools does not remove dependence on smart contracts or validator consensus. dePort additionally relies on the collateral retained in its native-chain custody contract.

Things people ask

Can dePort change a token's name, symbol or decimals?: dePort preserves the original token's name, symbol and decimals when creating a synthetic representation. It does not provide custom destination metadata. The inherited decimal count determines the conversion between displayed quantities and the token's smallest units.
Are NFTs supported by dePort's lock-and-mint product?: dePort supports fungible ERC-20 and SPL tokens on supported networks, while its token-porting product excludes NFTs. DMP can support custom NFT bridges through separate messaging integrations. That broader capability does not establish NFT support in dePort.
How can deAssets move between secondary chains?: dePort supports transfers of deAssets between secondary chains without routing through the native chain. The backing remains on the original token's native chain under the lock-and-mint model. dePort burns the deAsset on the departing secondary chain and mints a corresponding amount on the receiving chain.
Is a DLN cross-chain limit order the same as a same-chain swap?: A cross-chain DLN limit order specifies trading conditions across networks, while a same-chain swap exchanges tokens within one network. The trading application allows limit orders only in USDC and does not provide them for same-chain trades. A cross-chain limit order needs a solver willing to accept its price and economics; placing it does not ensure execution.
Do Hooks authenticate the original sender for a destination contract?: Hooks do not authenticate the original sender by default. An application needing sender authentication must include and verify an authenticated signature in the hook. Authenticating a smart contract as the sender requires DMP. A hook target must not grant permissions simply because a DLN contract made the call, since anyone can create an order carrying arbitrary hook data.