Cross-chain bridges are protocols that transfer digital assets between two independent blockchain networks by locking assets on the source chain and minting equivalent representations on the destination chain. Bridge knowledge is a core domain for finance teams because bridge transactions generate paired events across 2 separate chains — creating reconciliation complexity that standard single-chain transaction processing does not address. The paired source and destination chain events produce a single accounting record for each cross-chain transfer.
Bridge transaction volume exceeded $150 billion in 2024 according to DeFiLlama bridge aggregator data. Organizations operating across multiple Layer 2 networks and Layer 1 chains routinely bridge assets between Ethereum, Arbitrum, Base, Optimism, Polygon, and Solana — generating bridge events that require specific accounting treatment, fee classification, and reconciliation logic.
What Are Cross-Chain Bridges and How Do They Work?
Cross-chain bridges are protocols that transfer digital assets between two independent blockchain networks by locking assets on the source chain and minting equivalent representations on the destination chain — or by using liquidity pools to swap native assets across chains without wrapping. Understanding bridge mechanics is essential among the crypto fundamentals for finance teams because bridge transactions produce paired events across separate chains that require specialized reconciliation.
Blockchain networks operate as independent state machines — Ethereum, Arbitrum, Polygon, and Solana each maintain separate transaction histories, account balances, and consensus mechanisms. A token existing on Ethereum cannot natively appear on Arbitrum because the two networks do not share state. Cross-chain bridges solve the interoperability problem by creating paired events: an action on the source chain (locking or burning) triggers a corresponding action on the destination chain (minting or unlocking).
The bridge transaction lifecycle follows a 5-step process from initiation to confirmation on the destination chain.
Initiate Bridge Transaction
The user submits a bridge request specifying the asset, amount, source chain, and destination chain. The bridge smart contract on the source chain receives the transaction.
Lock or Burn on Source Chain
The bridge smart contract locks the original asset in a custody contract (lock-and-mint model) or burns the asset permanently (burn-and-unlock model). The source chain transaction confirms with a transaction hash.
Relay Proof Across Chains
A relay network, validator set, or off-chain oracle monitors the source chain event and generates a cryptographic proof of the lock/burn action. The proof is transmitted to the destination chain bridge contract.
Mint or Unlock on Destination Chain
The destination chain bridge contract verifies the relay proof and mints a wrapped representation of the asset (lock-and-mint) or unlocks previously locked native assets (burn-and-unlock). A second transaction hash is generated.
Confirm and Reconcile
The crypto subledger matches the source chain transaction hash with the destination chain transaction hash using bridge contract addresses, amount correlation, and timestamp proximity. The paired events produce a single accounting record.
The 5-step process generates 2 on-chain transactions — one on the source chain and one on the destination chain — plus relay activity that occurs off-chain or on a relay chain. The crypto subledger correlates both on-chain events into a single bridge record.
What Are the Main Bridge Mechanisms?
The 4 main bridge mechanisms are lock-and-mint, burn-and-unlock, liquidity pool, and relay/validator — each producing different on-chain event patterns that affect how the subledger classifies and reconciles the bridge transaction.
Lock-and-Mint
Lock-and-mint bridges lock the original asset in a smart contract on the source chain and mint a wrapped representation on the destination chain. Wrapped ETH (WETH) on Arbitrum, Wrapped Bitcoin (WBTC) on Ethereum, and bridged USDC on Base are examples of lock-and-mint bridge outputs.
The locked asset remains in the bridge custody contract until a user initiates a return bridge. The wrapped token maintains a 1:1 relationship with the locked asset — 1 wrapped ETH on Arbitrum represents exactly 1 ETH locked in the Arbitrum bridge contract on Ethereum L1.
Burn-and-Unlock
Burn-and-unlock is the reverse operation: the wrapped token on the destination chain is burned (permanently destroyed), and the bridge releases the corresponding locked asset on the source chain. Bridging assets back from Layer 2 networks such as Arbitrum to Ethereum L1 follows the burn-and-unlock pattern.
Liquidity Pool Bridges
Liquidity pool bridges maintain paired pools of native assets on both chains — the user deposits the asset into the source chain pool and receives the native asset from the destination chain pool. Stargate Finance and Across Protocol operate liquidity pool bridges. The liquidity pool model avoids wrapped tokens entirely — the user receives the native asset on the destination chain, simplifying the accounting treatment.
Relay/Validator Bridges
Relay bridges use a validator set or relay chain to verify and forward cross-chain messages. LayerZero, Wormhole, and Axelar operate relay-based bridge infrastructure. The relay network monitors source chain events, generates attestations, and delivers proofs to the destination chain contract.
How Are Bridge Transactions Recorded in Accounting?
Bridge transactions between wallets controlled by the same entity are recorded as internal reclassification entries — no gain or loss is recognized because the economic ownership does not change. The wrapped token on the destination chain inherits the cost basis of the original asset on the source chain, adjusted for bridge fees and gas costs.
Original Cost Basis + Source Chain Gas + Bridge Protocol Fee + Destination Chain Gas Cost basis of 10 ETH ($25,000) + source gas ($15) + bridge fee ($5) + destination gas ($0.20) = wrapped ETH cost basis ($25,020.20) The cost basis carryover principle ensures that bridging does not create a taxable event. The same entity controls the assets before and after the bridge — the economic position remains unchanged. The bridge fees increase the cost basis of the destination chain asset.
| Account | Debit | Credit |
|---|---|---|
| Digital Asset Holdings — ETH (Arbitrum) | $25,020 | — |
| Digital Asset Holdings — ETH (Ethereum L1) | — | $25,000 |
| ETH Holdings (gas + bridge fee) | — | $20 |
The journal entry above reclassifies the ETH from the Ethereum L1 wallet sub-account to the Arbitrum wallet sub-account. The $20 in gas and bridge fees ($15 source gas + $5 bridge fee) increases the cost basis of the Arbitrum ETH position. The chart of accounts structure follows the wallet-level sub-account model — each chain-specific wallet maps to a separate sub-account within Digital Asset Holdings.
The return bridge — moving assets back from Arbitrum to Ethereum L1 — follows the burn-and-unlock pattern with its own gas and fee costs.
| Account | Debit | Credit |
|---|---|---|
| Digital Asset Holdings — ETH (Ethereum L1) | $25,045 | — |
| Digital Asset Holdings — ETH (Arbitrum) | — | $25,020 |
| ETH Holdings (gas + bridge fee) | — | $25 |
How Are Bridge Fees Classified?
Bridge fees are classified as operating expenses or cost basis adjustments depending on the underlying purpose of the bridge transaction — following the same classification framework applied to gas fees.
Three fee components comprise the total bridge cost:
- Source chain gas fee — The gas fee for executing the lock or burn transaction on the source chain, denominated in the source chain’s native token
- Bridge protocol fee — A fee charged by the bridge operator for the cross-chain relay service, denominated in the bridged asset or the source chain’s native token
- Destination chain gas fee — The gas fee for executing the mint or unlock transaction on the destination chain, denominated in the destination chain’s native token
| Bridge Purpose | Fee Classification | Account |
|---|---|---|
| Internal transfer (same entity, operational) | Operating expense or cost basis increase | Network Fee Expense or Digital Asset Holdings |
| Pre-trade positioning (bridge to execute a swap on destination chain) | Cost basis adjustment of the asset acquired in the subsequent trade | Digital Asset Holdings |
| Vendor payment (bridge and send to external party) | Cost of revenue or operating expense | Network Fee Expense |
The classification table above maps bridge purpose to fee treatment. Organizations document the bridge fee classification policy in the crypto accounting policy memo and apply the policy consistently across reporting periods.
What Reconciliation Challenges Do Bridge Transactions Create?
Bridge transactions create 3 reconciliation challenges: timing gaps, amount mismatches, and multi-chain transaction matching.
Timing Gaps
The time between the source chain event and the destination chain event ranges from minutes to 7 days depending on the bridge architecture. Optimistic rollup bridges (Arbitrum, Optimism, Base canonical bridges) impose a 7-day challenge period for L2-to-L1 withdrawals. ZK rollup bridges finalize within minutes to hours. Third-party bridges (Stargate, Across, Hop) complete within 2-15 minutes.
The timing gap creates a period during which the asset is locked on the source chain but not yet available on the destination chain — the subledger tracks this in-transit state as a separate “bridge pending” classification until the destination chain event confirms. The reconciliation engine flags bridge transactions that exceed the expected timing window as exceptions for manual review.
Amount Mismatches
The amount received on the destination chain differs from the amount sent on the source chain by the bridge protocol fee. A bridge of 10.000 ETH with a 0.002 ETH bridge fee results in 9.998 ETH minted on the destination chain. The subledger matches the paired events using a fee tolerance window rather than exact amount matching.
Multi-Chain Transaction Matching
- Identify the source chain transaction hash from the lock/burn event
- Identify the destination chain transaction hash from the mint/unlock event
- Verify the bridge contract addresses match a known bridge protocol registry
- Confirm the amounts match within the bridge fee tolerance window
- Validate the timestamp proximity falls within the expected bridge duration
- Record the paired events as a single internal reclassification entry
- Classify the bridge fees per the organization accounting policy
- Update the wallet sub-account balances on both chains
The reconciliation engine maintains a bridge protocol registry — a mapping of known bridge contract addresses to bridge operators and expected behavior (fee structure, timing range, token wrapping convention). The registry enables automated matching of bridge events without manual intervention for standard bridge transactions. Non-standard or unknown bridge contract interactions generate reconciliation exceptions for manual review.
DeFi accounting extends bridge reconciliation to more complex cross-chain operations — multi-hop bridges that route through intermediate chains, aggregator bridges that select the optimal path across multiple bridge providers, and cross-chain swap protocols that combine bridging and token exchange in a single transaction.