Who submits a bridge mint? The roles behind a cross-chain transfer

In a lock-and-mint bridge, a relayer or other executor usually submits the destination transaction that mints tokens, after the bridge accepts evidence of the source-chain deposit. The user starts the transfer and supplies a destination address; the bridge’s verification rules decide when minting is allowed. That separates the person who requests a transfer from the machinery that authorizes and completes it.

The distinction matters because “the bridge” is not one actor. A contract may hold the source asset, a validator group or proof system may check the deposit, and a relayer may pay to call the destination contract. In some designs, any account can submit a valid proof or execute a ready message. In others, a designated service handles delivery. The permissions and trust assumptions differ even when the wallet screen shows a similar progress bar.

Bitcoin wrapping makes the separation easier to see: BTC is locked under one system’s rules, then a representation is issued on another chain. For a fuller account of that lock-to-token path, see renbridge. The mint does not happen because a relayer claims the deposit occurred; it depends on whatever evidence and authorization the destination contract is built to accept.

What happens before a bridge mints tokens?

Before a mint, the source transaction must be visible and meet the bridge’s acceptance conditions. The user typically selects an asset and destination, approves or sends the source-side transfer, and pays the source network fee. Depending on the bridge, funds may be locked in a contract, sent to a custody address, or burned if the source token is itself a bridge-issued representation.

The bridge then checks that the event is real, belongs to the supported contract or address, and matches the intended amount and recipient. It must also decide when the source transaction is safe enough to act on. A chain with probabilistic finality may require a number of confirmations; another may expose a finality signal. Waiting longer reduces the chance that a reorganization erases the deposit, but adds delay. Acting earlier can improve speed while increasing the risk of issuing tokens against a source transaction that later disappears.

Once accepted, the transfer needs destination-side authorization. That can take the form of a threshold of validator signatures, a cryptographic proof checked by a contract, or another protocol-defined message. The destination contract enforces the rule. A relayer’s transaction carries the evidence; the relayer does not gain the authority to mint arbitrary balances just by submitting it.

Who actually submits the destination mint?

Usually, a relayer or executor sends the transaction that calls the destination contract. It watches for source events, waits for the required checks, gathers or retrieves the authorization data, and submits an execution call. If the contract verifies the evidence and the transfer has not already been processed, it can mint tokens to the specified recipient.

That submitter may be one operator, one service among several, or any participant willing to pay destination gas. Those models allocate operational control differently. A permissionless execution path can reduce reliance on a single delivery service, but someone still needs to monitor the transfer and pay to submit it. A managed executor can make delivery simpler for users, while concentrating a practical part of the process in an operator that must stay online and funded.

Verification and submission are separate jobs. A validator set may attest to a message without broadcasting the final transaction. Conversely, an open relayer can carry a message but cannot make an invalid proof pass the contract’s checks. When inspecting a transfer, look for the source transaction, the bridge’s recorded message or proof status, and the destination transaction. The wallet that initiated the transfer need not be the address that submitted the mint.

How does this differ from liquidity-based bridges?

A lock-and-mint bridge creates a destination representation backed by assets held or controlled on the source side. Its central question is whether the bridge’s authorization and backing remain sound. Returning to the source generally involves burning the representation and releasing the corresponding asset, subject to that system’s redemption rules.

A liquidity-based bridge can instead pay the user from destination-side inventory. A liquidity provider or solver advances the destination asset, then seeks settlement or reimbursement under the bridge’s design. The user may receive funds sooner, but speed depends on available liquidity, pricing and the settlement arrangement. The transfer need not involve a new mint for each user; it may move existing tokens from a pool.

Native-chain routes are another alternative when an asset can be withdrawn or issued directly on the destination network. They can avoid a wrapped claim on a bridge’s reserves, but availability depends on the asset and networks involved. There is no universal winner: lock-and-mint gives a clear custody-and-issuance model, liquidity routes can shorten the wait, and native issuance avoids some bridge-specific dependencies where it exists.

What should users check when a mint is pending?

First, confirm that the source transaction succeeded and reached the bridge’s required confirmation state. Then check whether the bridge has recognized the correct amount, destination chain and recipient. If those stages are complete but there is no destination transaction, execution may be waiting for a relayer, proof, or destination gas. The interface’s status and the bridge’s own records are more useful than repeatedly submitting the source transfer.

• Match the source transaction to the bridge’s deposit or message record.
• Check the destination address and network recorded for the transfer.
• Look for a destination transaction hash before treating the mint as complete.
• Use a retry or claim action only if the bridge marks the transfer eligible and explains what that action submits.

The trade-off to keep in view is straightforward: the user initiates the cross-chain move, but the system’s proof rules control whether issuance is valid, and its execution path determines who gets the mint transaction onto the destination chain. For any route, the useful signals are source finality, proof or attestation status, destination execution, and whether the asset is newly minted or paid from existing liquidity.