Bridging basics, explained

The short answer

A bridge moves value between chains that can't natively read each other's state. Most work by locking an asset on the source chain and minting a “wrapped” representation on the destination chain—an IOU, not the original asset—then burning that wrapped token and unlocking the original when you bridge back (Cube Exchange). Some newer designs skip wrapping entirely, using intent-based fills where a relayer fronts the destination-chain funds and gets reimbursed later. Both patterns are in production today, and which one a bridge uses changes what you're actually trusting when you use it.

Lock-and-mint, the default pattern

Send tokens to a bridge contract on the source chain, where they're locked. A validator set—or oracle, or light client—observes that deposit and instructs the destination chain to mint an equivalent wrapped token. To reverse it, you burn the wrapped token on the destination chain and the lock releases on the source (Yellow). That locked pool is the entire security model concentrated in one place—often called the honeypot problem, since a single contract or signer set can end up guarding hundreds of millions of dollars (BYDFi).

Wormhole is the incumbent messaging rail most Solana bridges route through, including the Portal frontend. Its guardian network validates state across 30+ chains through a proof-of-authority model requiring 13 of 19 guardian signatures to approve a message—a federated trust assumption, not a trustless one (Eco). Wormhole's newer Native Token Transfers standard uses burn-and-mint instead of locked liquidity pools, which removes some—not all—of the wrapped-asset friction that plagued earlier bridge designs.

Robinhood Chain's canonical bridge

Robinhood Chain runs on Arbitrum Orbit, so its canonical bridge is the same trustless Arbitrum bridge used across the Arbitrum ecosystem—security is inherited directly from Ethereum, with no third-party validator set to trust (Robinhood Chain docs). Depositing from Ethereum to Robinhood Chain typically confirms in about 10 minutes. Withdrawing runs the other direction and takes much longer: initiate the withdrawal on Robinhood Chain, wait out a roughly 7-day challenge period required by Arbitrum's fraud-proof system, then submit a claim transaction on Ethereum to actually receive the funds—a separate step that costs L1 gas.

Robinhood's own documentation also lists faster third-party routes—Across, Relay, and LiFi among them—for users who don't want to wait out the full withdrawal window, in exchange for a fee and a different trust model than the canonical bridge (DEXTools). See Robinhood Chain: the field guide for the network's broader context, and reading a block explorer for how to confirm a bridged deposit actually landed. What each of those two transactions actually costs is broken out in Solana vs. Robinhood Chain fees, compared.

Verifying a wrapped token before you trust it

A wrapped token's contract address is not the same address as the native asset, and it's not the same across every bridge either—two different bridges can each issue their own version of “wrapped ETH” on the same destination chain, with different backing and different risk. Before treating a wrapped token as equivalent to the real thing: find the official contract address in the project's own docs (not a search result or a link from someone in a chat), confirm it on a block explorer, and check who controls it—a multisig, a timelock, or a single key are very different risk profiles for the same-looking token.

For USDC specifically, prefer Circle's native Cross-Chain Transfer Protocol over a wrapped-IOU route wherever both chains support it—it burns and mints the canonical asset directly instead of relying on a bridge's own locked collateral (Eco).

What a bridged transfer's journal must reconstruct

1. Both legs, as separate events. The lock/burn on the source chain and the mint/unlock on the destination chain—two transactions, two fee payments, not one.
2. Which bridge and which trust model. Canonical (chain-inherited security), federated validator set, or a single custodian—each carries a different failure mode.
3. Wrapped vs. canonical asset received. Whether what landed on the destination chain is a native asset or an IOU dependent on the bridge staying solvent.
4. Time in transit. Minutes for most deposits; up to roughly a week for a canonical Arbitrum-style withdrawal challenge period—relevant for anyone reconstructing when funds were actually available to trade.

Before using the arrival as trading inventory, continue with bridge readiness before a trade to verify the destination asset, gas balance, remaining setup, and fresh route.

Official sources