Validate bridged WBTC by chain, contract and delivery

Because bridges can deliver different token contracts on different chains, an app should credit bridged WBTC only after verifying the destination chain, exact token address and completed transfer against an approved route.

This makes the credit depend on the asset actually received, rather than a ticker or a user’s description of the transfer.

For a cross-chain deposit, “WBTC” is not a sufficient identifier: the chain and contract address together identify the token the app is being asked to credit. Across’s API documentation separates supported chains from supported tokens and provides token addresses by chain. Its route checks are therefore a useful first step, while an app should still verify the destination transfer it relies on. For details on that route-specific question, see AcrossBridge destination-token support.

What should the app verify before accepting a route?

It should verify the exact origin and destination chain IDs, the origin and destination token contract addresses, and the amount and recipient expected for the transfer. The ticker, name, logo and token decimals are metadata; they do not establish that a contract is the app’s approved WBTC representation. The ERC-20 interface exposes functions such as name, symbol and decimals, but those values are supplied by the token contract.

Use a maintained allowlist keyed by chain ID and contract address, and update it through a controlled process when supported assets change. If the app uses a bridge API, query its current token and route data instead of assuming that support for WBTC on one destination implies support on another. Across documents /swap/tokens as a way to retrieve supported tokens for cross-chain swaps; a quote or route response can establish what the bridge currently offers for a particular transfer, but it does not replace the app’s own asset policy.

How can the app confirm delivery on the destination?

It should wait for the bridge’s destination-side transfer to reach the app’s defined settlement state, then match that transfer to the expected recipient and token contract. A source-chain deposit event shows that funds entered the route; it does not, by itself, prove that the destination recipient received the expected asset. Use the bridge’s transfer identifier or status mechanism to connect the source deposit to destination execution, and account for the destination chain’s reorganization and finality rules.

When the receiving account is controlled by the app, compare its token balance immediately before and after delivery. The ERC-20 balanceOf method returns a contract’s reported account balance; a balance delta can help reconcile the amount actually received. It should be checked alongside the bridge record and transfer logs, since unrelated transfers during the same interval can make a raw balance change ambiguous.

How should the app handle amount and accounting differences?

Keep amounts in integer base units through verification and accounting. ERC-20 decimals determine how a raw integer is displayed, not how the contract performs the transfer. Read decimals from the approved token configuration, apply explicit conversions at the interface boundary, and compare the delivered raw amount with the route’s expected output after any disclosed fee or swap.

A practical crediting gate should require all of the following:

• The destination chain and contract match the app’s supported WBTC entry.
• The bridge status identifies the expected transfer as delivered.
• The recipient and raw amount reconcile with destination logs or a balance delta.
• The amount is converted using the approved token’s decimals and recorded once.

If any check fails or the route is still pending, leave the deposit uncredited and surface its status for reconciliation. The safer default is to credit only the verified destination asset and amount, with the bridge record retained as the link between chains.