Guide

Finding the transaction to search

The transaction hash is the best thing to search. It names one specific transfer, and every covered bridge can find its swap from at least one side. An address search depends on the bridge having recorded that exact address, and some bridges can reach an address's history only within a window of days.

Either side works. Search the deposit (the transaction where funds left the wallet into the bridge) or the payout (the transaction where funds arrived from the bridge). Bridge Wizard identifies the swap from either one and verifies the other.

How to find it.

• In the wallet app. A swap or bridge entry in the wallet's history usually shows the transaction hash, or links to it on a block explorer.
• On a block explorer. Open the address, look at its transfers around the time in question, and find the one sent to (or received from) a bridge contract or a labelled bridge address. On Bitcoin, a swap deposit often carries a memo in an OP_RETURN output.
• Here. Search the address. Bridge Wizard reads the address's recent transactions, finds the ones sent to a known bridge, and resolves them for you.

Where to look, by chain. On Ethereum-style explorers, the Transactions and Token Transfers tabs, where bridge contracts are often labelled. On Tronscan, the Transfers tab (TRC-20 for USDT). On mempool.space, the transaction's outputs, including any OP_RETURN memo. On Solana explorers, the list of signatures for the address.

How a cross-chain transfer moves

Blockchains cannot see each other. A bridge moves value between two of them by doing something on each side: the sender makes a deposit on the source chain (to the bridge's contract, vault or a one-time deposit address), and the bridge, or a solver working for it, makes a payout to the recipient on the destination chain. If the payout cannot be made, a refund goes back to the sender. In between there may be a message, a signature, a swap or a step on the bridge's own chain.

A messaging bridge (LayerZero, Wormhole, Axelar) carries a message that an app acts on: Stargate, USDT0, Portal or Squid moves the money. An intent bridge (Relay, Across, deBridge, Mayan Swift, NEAR Intents) has a solver pay the recipient from its own funds and be repaid from the deposit. A liquidity network (THORChain, Maya, Chainflip) swaps native assets through its own pools, often from a one-time deposit address. An atomic swap (Garden) locks both sides to the same secret. An exchange service (HiFiSwap, Bridgers) takes the deposit and pays out from an order record its operator keeps.

How Bridge Wizard connects the two sides

Paste a transaction from either side, a wallet address, or a bridge's own reference, and Bridge Wizard asks every covered bridge at once whether it recognizes it.

1. Forward, from a deposit. If you have the transaction that sent the funds in, the tool finds the swap it funded and shows where the money went: the payout transaction, the recipient and the amount. If the payout has not happened yet, the card says Payout pending and how long ago the deposit was made.
2. Backward, from a payout. If you have the transaction that received the funds, the tool finds the swap that paid it and shows where the money came from: the deposit transaction, the sender and the amount. Most bridges can be searched by the payout directly. Harbor cannot, so for Harbor the tool finds when the payout confirmed and searches Harbor's public list of swaps for the days before it (48 hours at first; you can widen that to 14 days or all of Harbor's history, which starts on 2025-11-06).
3. Refunds and steps in between. A refund, or a transaction the bridge made along the way (a NEAR transaction, a THORChain internal leg), leads to the swap it belongs to, and the card says which it is.
4. By a bridge's own reference. An order id, request id, swap id, deposit channel, VAA id or message id opens the swap it names. A bare number is tried at every bridge that numbers its swaps; when more than one has it, you choose which one you mean.
5. One card per swap. Each card shows the source on the left and the destination on the right, marks the transaction you searched, and says in one sentence what happened. When an aggregator (LI.FI) and the bridge it routed through (for example Relay) both report the same deposit and payout, they are one swap and one card, "LI.FI via Relay".
6. Checking it on chain. Where the chains allow, the tool reads the transactions themselves: the note (OP_RETURN) in a Bitcoin deposit against the memo the bridge recorded; the note in a THORChain or Maya payout naming the deposit; the one-time deposit address a sender paid; the contract a deposit reached; and what the source transaction sent and whom the payout transaction paid. Each check is shown on the side it verifies.

Searching by address. Paste a wallet address to list every bridge swap it sent or received. Each bridge is searched as its own API allows, and each says what that covers (the sender only, the sender and the recipient, and so on). A date range is optional; it is offered when a bridge can reach an address's history only within a window of days, and it narrows every bridge to that period.

Sent using. Most swaps are built by an app (a wallet, an exchange widget, an aggregator) that records a short code in the swap to collect its fee. The card names the app behind that code from a reference table with a source for every entry, showing the app the user touched rather than the routing layer behind it. The code identifies the interface, not the person, and a careful user can set or leave it out.

Why ordinary block explorers miss bridged transfers

A block explorer shows one chain. On the source chain it shows the deposit going to a bridge contract, a vault or a fresh deposit address, and there the trail stops. On the destination chain the payout comes from the bridge, a solver or a pool that pays thousands of people, so nothing on that chain points back to the sender.

• No shared identifier on chain. The two transactions usually share no hash, address or amount: the payout is a different asset, less fees, often from a solver's own wallet, sometimes minutes or days later.
• The link lives in the bridge's own record. Only the bridge's indexer, API or message knows which deposit paid which payout. Bridge Wizard asks each bridge's own public record, then checks what it says against the chains.
• Many bridges, many formats. Each bridge stores hashes differently (with or without 0x, upper or lower case, base58), and some can be searched only by one side. The tool tries each form each bridge needs and says plainly when a side is not searchable.
• Batches, buses and aggregators. One payout can settle several swaps, one delivery can carry many users' transfers, and an aggregator can route through a bridge that has its own record. The tool shows the one that is yours, and merges records of the same swap into one card.

Using data request targets

Under "Sent using" on a card, Data request targets lists who may hold records about the swap, most actionable first: the stablecoin issuer when USDT or USDC was received, the app that built the transaction, any routing aggregator, and the bridge's operator (or a plain statement that a decentralized protocol has no operator holding user records).

1. Act on a freeze first. When USDT or USDC was received and may still be in the recipient's wallet, the issuer can sometimes freeze it. Time matters more than anything else on the list.
2. Cite the identifiers. Each target lists the swap's identifiers (transaction hashes, addresses, order or request ids) with a time window around the swap. "Copy request details" copies them as text for a request draft.
3. Ask for the records it holds. Each record type is marked "documented", with the page where the entity says it collects it, or "typical for this type of service" when no official page confirms it.
4. Send it where the entity says. A law enforcement channel is listed only where the entity itself publishes one, with its source and the date it was checked. Otherwise the card says none was found and links to The Block Record.

Push notification tokens

A wallet app that sends notifications holds a push token for the phone it runs on. The token is issued by Apple (APNs) or Google (FCM), and the platform that issued it can associate it with an account and a device. When a wallet app's records are available, asking for the push token tied to the wallet, then asking Apple or Google about that token, can lead from a self-custody wallet to an account. The data request targets mark which wallet apps document collecting push tokens.

These are investigative leads, not legal advice. Whether an entity holds these records, and the process required to obtain them, varies by entity and jurisdiction. No contact is ever guessed, and nothing is fetched to build the list.

Coverage

What each bridge can be searched by: its deposit (source) transaction hash, its payout (destination) transaction hash, a wallet address, and its own reference for a swap, with the known gaps.

No match means none of the covered bridges recognized the search. It does not mean the transaction was not bridged: it may have gone through a bridge this tool does not cover yet. A bridge that could not be reached, was busy, or does not take that kind of search is marked "not checked" and is not counted as a no match.

Who it is for

• Investigators and law enforcement following funds that crossed a bridge, who need the other side, the app that built the swap and who holds records.
• Compliance and risk teams screening a deposit or a withdrawal whose funds arrived from, or left for, another chain.
• Exchange and wallet support answering "where did my transfer go?" with the payout transaction, or a clear "payout pending" or "refunded".
• Victims and their counsel documenting where stolen funds went, with a report that keeps every response and its SHA-256.
• Researchers and journalists checking a claim about a bridged transfer against each bridge's own record and the chains.

The report

The Bridge Wizard Report is a standalone Excel workbook: a Summary sheet (the answer, as on the card, then the query, payout time, days searched and method), a Swap sheet (every field of the swap, by bridge, and the on-chain checks), an Evidence sheet (the raw record from each bridge, the URL it came from, its SHA-256, and the raw verification responses) and, when a card lists them, the data request targets. An address search's report lists every swap found. The SHA-256 of each response lets anyone reproduce the retrieval.

Privacy

Nothing you enter is stored. The hash, address or reference you enter is relayed through this site's own functions to each bridge's public API or explorer service, to public block explorers and RPC nodes to read transactions, and for Tron checks to TronGrid; Harbor is queried by date only, never by your hash. None of them sees your IP.

Usage statistics. Bridge Wizard counts searches and which bridges and wallet apps appear in results, to improve coverage; it never records what you searched. When a search finishes, the page sends only the kind of search, whether it found a swap, the names of the bridges, routing layers and apps in the result, and the conditions shown (pending, refunded and the like), added to that day's totals. No hash, address, amount, time of day or IP address is kept. Your theme and whether you hid the highlights are remembered in your own browser only. We count searches by country, time zone, hour of day and referring site. We do not store IP addresses or anything you search.

Frequently asked questions