Matched Transfers

crosschain.bridges.matched_transfers pairs outbound bridge transactions on the source chain with their corresponding inbound delivery transactions on the destination chain. Each row represents a single confirmed end-to-end bridge transfer with both legs reconciled, along with hydrated token amounts, USD values, spread, and latency metrics.

Only matched pairs are included — outbound transactions that could not be matched to an inbound delivery (e.g. in-flight, refunded, or missing data) are excluded from this view. Query the per-direction tables (crosschain.bridges.bridges_outbound_transfers, crosschain.bridges.messaging_protocols_outbound_messages, crosschain.bridges.bridge_aggregators_outbound_transfers) if you need to see unmatched outbound activity.

Protocol Coverage

Matched transfers are produced for 18 bridge and messaging protocols, grouped by bridge_type:

Bridge Type	Protocols
`bridge`	across_v3, debridge_dln, debridge_gate, gas_zip_lz_v2, mayan_mctp, mayan_swift, relay, stargate_v2, usdt0
`messaging_protocol`	axelar, chainlink_ccip, circle_cctp_v1, circle_cctp_v2, hyperlane, layerzero_v2, socket_dl_v1, wormhole
`bridge_aggregator`	bungee_v3

Coverage Limitations

Some protocols are only partially represented in matched_transfers. Most are ingested as outbound/inbound rows in crosschain.bridges.bridges_outbound_transfers and crosschain.bridges.bridges_inbound_transfers but do not appear in matched_transfers, because the two legs share no on-chain identifier that can be linked without off-chain data — join to the per-direction outbound/inbound tables for comparable coverage. Others appear in matched_transfers but are still building complete history. Consumers computing absolute bridge volume from matched_transfers will undercount the protocols below.

Volume totals and percentiles sourced only from crosschain.bridges.matched_transfers are biased against the protocols below. Prefer week-over-week ratios, or fall back to the per-direction tables when reporting absolute volumes.

Protocol	Where it appears	Why it isn’t matched
`rhino_v2` (Rhino.fi)	outbound + inbound	Off-chain routing. `BridgedDeposit` / `BridgedDepositWithId` on the source chain carries no `destination_chain`. `BridgedWithdrawal*` / `SwapWithData` on the destination chain carries no `source_chain` and no order id linking back to the deposit.
`mayan_legacy_swap`, `wormhole_swap` (Mayan legacy / Wormhole legacy swaps)	outbound + inbound	Both settle through Solana as a hub — even EVM→EVM routes go source EVM → Solana auction+fill → destination EVM. There is no shared identifier connecting the source EVM tx to the Solana order. The Wormhole `post_message` on Solana could be linked to the destination inbound via VAA, but that hop is a same-token payout — using it would report near-zero spread and a tiny latency that has nothing to do with the user’s real cross-chain trade. Use `mayan_swift` / `mayan_mctp` for matched Mayan volume.
`gas_zip_v1`	outbound only	The destination payout is a plain native-token transfer from a Gas.zip-controlled EOA — no event, memo, or unique identifier tying it to the source-side `Deposit`. Joining by `(recipient, chain, amount)` is unsafe: v1 explodes a single deposit into one row per destination and splits the amount equally. Use `gas_zip_lz_v2` (matched by LayerZero GUID) for current Gas.zip volume.
`relay` (Relay)	matched	Rows are sourced from Relay’s API rather than reconstructed from on-chain events, so coverage depends on what the API returns. History is actively backfilling and remains incomplete — expect gaps in older periods and treat absolute historical volumes as a lower bound until the backfill completes.

Match Types

The match_type column describes how the outbound and inbound legs were paired:

exact: deterministic join on a protocol-native identifier (e.g. deposit_id, LayerZero guid, CCTP nonce, Wormhole sequence, Axelar command_id, order hash).
composite: joined on a combination of recipient address, token, amount, and a source→destination chain pair within a time window, for protocols where no single global identifier is emitted on both sides.

Spread & Latency

spread_percentage = (outbound_usd_amount - inbound_usd_amount) / outbound_usd_amount * 100. Nulled out when either USD amount is missing, the outbound amount is zero, or the absolute spread exceeds 25% (usually a sign of a mispriced token or mismatched pair).
latency_seconds = seconds elapsed from outbound to inbound block timestamp. Can be negative for intent-based protocols (Across, DeBridge DLN, Mayan Swift) where fillers front funds on the destination chain before the source-side transaction is finalized. Nulled out when outside the -3600s to 86400s range.

Sample Queries

Average bridge latency and spread by protocol over the last 7 days.

SELECT
    project,
    protocol,
    bridge_type,
    COUNT(*) AS matched_transfers,
    AVG(latency_seconds) AS avg_latency_seconds,
    MEDIAN(latency_seconds) AS median_latency_seconds,
    AVG(spread_percentage) AS avg_spread_pct,
    SUM(outbound_usd_amount) AS outbound_usd_volume
FROM crosschain.bridges.matched_transfers
WHERE outbound_block_timestamp >= CURRENT_TIMESTAMP - INTERVAL '7 days'
GROUP BY ALL
ORDER BY outbound_usd_volume DESC

Top cross-chain user flows (source → destination) by matched volume.

SELECT
    CONCAT(source_chain, ' > ', destination_chain) AS flow,
    project,
    COUNT(*) AS transfers,
    COUNT(DISTINCT outbound_sender_address) AS unique_users,
    SUM(outbound_usd_amount) AS usd_volume
FROM crosschain.bridges.matched_transfers
WHERE outbound_block_timestamp >= CURRENT_TIMESTAMP - INTERVAL '30 days'
  AND outbound_usd_amount IS NOT NULL
GROUP BY ALL
ORDER BY usd_volume DESC
LIMIT 50

Table Columns

Unique key: unique_id

Column Name	Data Type	Description
project	VARCHAR	The project or product name (e.g., `across`, `stargate`, `layerzero`).
protocol	VARCHAR	The specific protocol version identifier (e.g., `across_v3`, `stargate_v2`, `layerzero_v2`).
match_type	VARCHAR	How the outbound and inbound legs were matched: `exact` (deterministic ID match) or `composite` (matched on recipient + amount within a time window).
bridge_type	VARCHAR	Classification of the protocol: `bridge`, `messaging_protocol`, or `bridge_aggregator`.
source_chain	VARCHAR	The chain where the bridge transfer originates (outbound side).
destination_chain	VARCHAR	The chain where the bridge transfer is delivered (inbound side).
outbound_token_address	VARCHAR	The contract address of the token sent on the source chain.
outbound_token_symbol	VARCHAR	Token ticker symbol on the source chain (e.g., `USDC`, `ETH`).
outbound_amount_raw	VARCHAR	Raw outbound token amount, not adjusted for decimals.
outbound_amount	FLOAT	Decimal-adjusted outbound token amount.
outbound_usd_amount	FLOAT	USD value of the outbound transfer at the time of the transaction. NULL if price unavailable or exceeds the $2B cap.
inbound_token_address	VARCHAR	The contract address of the token received on the destination chain.
inbound_token_symbol	VARCHAR	Token ticker symbol on the destination chain.
inbound_amount_raw	VARCHAR	Raw inbound token amount, not adjusted for decimals.
inbound_amount	FLOAT	Decimal-adjusted inbound token amount.
inbound_usd_amount	FLOAT	USD value of the inbound transfer at the time of the transaction. NULL if price unavailable or exceeds the $2B cap.
spread_percentage	FLOAT	Percentage difference between outbound and inbound USD amounts: `(outbound - inbound) / outbound * 100`. NULL when either USD amount is missing, outbound is zero, or spread exceeds 25%.
outbound_block_timestamp	TIMESTAMP_NTZ(9)	Timestamp of the outbound (source chain) transaction.
inbound_block_timestamp	TIMESTAMP_NTZ(9)	Timestamp of the inbound (destination chain) transaction.
latency_seconds	BIGINT	Time in seconds from outbound to inbound delivery. Can be negative for intent-based protocols where fillers front funds. NULL when outside the `-3600` to `86400` second range.
outbound_sender_address	VARCHAR	The address that initiated the bridge transfer on the source chain (the user).
inbound_recipient_address	VARCHAR	The address that received funds on the destination chain (the user).
outbound_transaction_hash	VARCHAR	Transaction hash of the outbound bridge event on the source chain.
inbound_transaction_hash	VARCHAR	Transaction hash of the inbound delivery event on the destination chain.
outbound_recipient_address	VARCHAR	The bridge contract or relayer address that received the outbound transfer on the source chain.
inbound_sender_address	VARCHAR	The bridge contract or relayer address that sent the inbound transfer on the destination chain.
outbound_block_number	BIGINT	Block height of the outbound transaction on the source chain.
inbound_block_number	BIGINT	Block height of the inbound transaction on the destination chain.
outbound_unique_id	VARCHAR	Unique identifier for the outbound leg. Joins back to the `unique_id` column of the corresponding outbound source table (`bridges_outbound_transfers`, `messaging_protocols_outbound_messages`, or `bridge_aggregators_outbound_transfers`).
inbound_unique_id	VARCHAR	Unique identifier for the inbound leg. Joins back to the `unique_id` column of the corresponding inbound source table (`bridges_inbound_transfers`, `messaging_protocols_inbound_messages`, or `bridge_aggregators_inbound_transfers`).
join_key	VARCHAR	The protocol-specific key used to match outbound and inbound legs (e.g., `deposit_id`, `guid`, `nonce`, `order_id`).
unique_id	VARCHAR	A unique identifier for this matched transfer record.
_created_at	TIMESTAMP_NTZ(9)	Timestamp when this record was created in Allium.
_updated_at	TIMESTAMP_NTZ(9)	Timestamp when this record was last updated in Allium.

Overview

Data Verticals

Solana

Hyperliquid

Lighter

Bitcoin Ecosystem

EVM

Cosmos Ecosystem

Move Ecosystem

Other Ecosystems

Protocol Coverage

Coverage Limitations

Match Types

Spread & Latency

Sample Queries

Table Columns

​Protocol Coverage

​Coverage Limitations

​Match Types

​Spread & Latency

​Sample Queries

​Table Columns

Protocol Coverage

Coverage Limitations

Match Types

Spread & Latency

Sample Queries

Table Columns