Credit cross-chain deposits after destination settlement

Credit a cross-chain deposit when the bridge’s required source-chain condition is met and the corresponding transfer is verified on the destination chain. A source transaction hash proves only that a transaction was submitted; it does not prove that the bridge accepted the deposit or delivered the mapped asset. Keep funds pending while either condition is unresolved. For a separate explanation of how a relay bridge routes transfers, see the linked guide. The accounting rule is the same across bridge designs: credit the state transition the bridge actually completed, not a status label that may precede it.

What does “credited” mean for a cross-chain deposit?

“Credited” should mean that the recipient can use the destination asset and that the deposit has reached the settlement state your service recognizes. That is stricter than seeing the source transaction in a block. A bridge may wait for a source-chain threshold, verify a message, and then call a destination contract that mints, releases, or transfers tokens. Each step can have a distinct status.

Separate operational progress from the balance a user can spend. A useful state model is:

• Observed: the source transaction or deposit event is visible, but the required source-chain security condition is not yet satisfied.
• Accepted: the bridge’s verification mechanism has accepted the source event or message.
• Delivered: the destination transaction has executed and the expected recipient and asset have received value.
• Settled: the delivery has met the destination-chain finality policy used for available balances.

The names are internal; the evidence behind each state matters. A system may show an early “deposit detected” notification, but that should not silently increase a withdrawable balance. If product design requires showing funds sooner, expose them as pending and keep them out of spendable totals until the settlement rule passes.

How should confirmation and finality affect the credit?

Set the source threshold according to the chain and the bridge’s verification design; there is no universal confirmation count that makes every deposit safe. A block can be included yet later removed by a reorganization. Some consensus systems provide probabilistic confidence as additional blocks arrive, while others have a protocol finality condition. Bridge contracts and message verifiers may impose their own acceptance requirements on top.

Use the strongest condition the bridge actually relies on. If it verifies source-chain state through a light client, follow that client’s accepted-header and finality rules. If it relies on a validator or attester quorum, require the bridge’s specified quorum and signature checks. If a bridge has a challenge period, distinguish a message that has been submitted from one whose challenge window has completed. A generic “confirmations” setting cannot replace these protocol conditions.

Destination execution is a separate gate. The relayer or user may submit a claim, but the transaction can fail, remain pending, or execute with an unexpected result. Verify the destination transaction receipt and the bridge’s delivery event, then confirm that the event identifies the expected recipient, token, amount, and message or deposit identifier. Where available balance depends on destination finality, wait for that condition too. An explorer’s success label is useful for investigation; it is not a substitute for checking the relevant contract event and canonical chain state.

What should an exchange or wallet verify before making funds available?

Match the source event to one destination delivery and apply the bridge’s asset mapping before updating the user’s balance. This prevents a valid transaction on the wrong network, token, or recipient from being mistaken for the expected deposit. It also prevents retries from creating duplicate credits when the same bridge message is submitted more than once.

At minimum, the accounting path should verify:

• The source chain, deposit contract, event type, sender or depositor, and transaction status.
• The required source finality or bridge-specific verification condition.
• The destination chain, bridge contract, delivery event, recipient, asset, and net amount after fees or conversion.
• A unique message or deposit identifier, with idempotent handling of retries and repeated notifications.

Keep the original source and destination transaction references with the ledger entry. If the bridge reports a source deposit but no destination delivery appears, leave the amount pending and investigate the message state rather than inferring success from elapsed time. If the source event disappears from the canonical chain or the destination call fails, reverse or hold the pending entry according to the documented recovery path. Do not erase the audit trail when correcting a balance.

The practical rule is simple: source inclusion starts the deposit; bridge verification authorizes the cross-chain action; destination execution delivers it. Make funds available only at the final state your risk policy supports, and label earlier states as pending. That keeps confirmation speed tied to the bridge’s actual security mechanism instead of to a convenient but ambiguous status.