Cross-Chain Technology: How Blockchains Exchange Data and Assets

Scope and the core definition

Cross-chain technology refers to the mechanisms that allow separate blockchain networks to exchange data, tokens, or messages. A blockchain by itself is intentionally isolated: its nodes validate only its own state, and its smart contracts cannot natively read another chain's ledger. Cross-chain systems add a verification layer between two or more chains so that an event on chain A can be trusted and acted upon on chain B.

This article covers the technical models behind that verification, a runnable procedure for confirming a cross-chain transfer, and the operational tradeoffs. It does not recommend a specific bridge or endpoint; for concrete endpoint and provider choices, the RPC Assistant answers are the right destination. The goal here is that you can reason about any cross-chain system you encounter and measure it yourself.

• Cross-chain = verification and transport between independent ledgers.
• Multichain = deploying or holding assets on several chains independently; it does not by itself move state between them.
• Interoperability is the outcome; bridges and messaging protocols are the implementations.

Assumptions and prerequisites

The procedure below assumes you have read access to at least two JSON-RPC endpoints (one per chain involved in the transfer), a shell with curl and jq, and the transaction hash of the source-chain leg of a cross-chain transfer. No private keys are required for verification, which is deliberate: reading chain state should never require signing authority.

If you are building rather than auditing, you will also want a way to reach both networks reliably. Managed multi-chain RPC access is covered in the multi-chain RPC endpoints guide, and per-network details live in the supported networks directory. Keep endpoints in environment variables so the same scripts work across environments.

export SRC_RPC_URL="RPC_URL_FOR_SOURCE_CHAIN"
export DST_RPC_URL="RPC_URL_FOR_DESTINATION_CHAIN"
export SRC_TX_HASH="0x..."
export BRIDGE_CONTRACT="0x..."

The four cross-chain models and their trust assumptions

Almost every cross-chain system reduces to one of four transport models, and the model determines who you must trust. Lock-and-mint bridges custody the original asset in a contract on the source chain and mint a representation on the destination chain. Burn-and-unlock bridges destroy the representation on one side and release the original on the other. Light-client relays verify the source chain's consensus proofs directly on the destination chain, minimizing external trust but costing significant compute and engineering. General message-passing layers transport arbitrary payloads and let the destination contract decide what to do with them.

The critical question for any of these is: what set of parties could cause a fraudulent release? In a lock-and-mint bridge with a multisig validator set, that set is the signers. In a light-client relay, it is the source chain's validator majority. In an optimistic messaging system, it is whoever can successfully challenge within the dispute window. Write that answer down before you integrate, because it is the actual security boundary, not the bridge's marketing page.

• Lock-and-mint: custodial on the source side; wrapped asset on the destination side.
• Burn-and-unlock: canonical asset released on the destination side; representation burned on the source side.
• Light-client relay: cryptographic verification of source consensus; higher cost, lower external trust.
• Message passing: arbitrary payloads; security depends on the verifier and the destination contract's validation.

Mental model: source event, attestation, destination execution

Every cross-chain transfer has three phases. First, a source event is emitted: a deposit, a burn, or a message send, recorded in a transaction receipt on the source chain. Second, an attestation is produced: validators sign, a light client proves, or an oracle reports that the event occurred. Third, destination execution happens: a contract on the destination chain checks the attestation and mints, releases, or executes.

When a transfer appears stuck, it is almost always because one of these three phases has not completed. Separating them turns a vague "bridge is slow" complaint into a specific question: did the source event finalize, did the attestation reach quorum, and did the destination transaction revert? The verification procedure below answers each in order.

Step 1: confirm the source-chain event and its finality

Start by fetching the source transaction receipt. You are looking for a successful status and the log emitted by the bridge contract. The log's topics and data encode the destination chain, recipient, amount, and a nonce or message ID that the destination side will reference. Save that identifier; it is the join key between the two chains.

curl -s "$SRC_RPC_URL" \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["'"$SRC_TX_HASH"'"]}' \
  | jq '{status: .result.status, block: .result.blockNumber, logs: [.result.logs[] | select(.address == (env.BRIDGE_CONTRACT | ascii_downcase))]}'

Step 2: check attestation and destination execution

With the message ID in hand, query the destination chain for the transaction that consumed it. Many bridges expose a read method such as isMessageProcessed(bytes32) or emit a MessageReceived event; the exact selector depends on the protocol, so inspect the bridge's verified contract interface before calling. If the destination transaction exists, check its status. If it reverted, the revert reason usually names the failed check: insufficient attestation signatures, expired deadline, or a slippage guard.

A useful diagnostic is to compare timestamps. The gap between source finality and destination execution is the bridge's effective latency, and it is the number worth tracking over time rather than any advertised figure.

curl -s "$DST_RPC_URL" \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"'"$BRIDGE_CONTRACT"'","data":"0x..."},"latest"]}' \
  | jq '.result'

Reproducible measurement: building a latency and success table

To compare routes or monitor a bridge over time, record one row per transfer with the fields below, then aggregate. Do not fill in numbers you have not observed; the table is a template, and the values must come from your own runs against live endpoints.

Run the same script against a batch of historical transfers to get a distribution rather than a single anecdote. Report p50 and p95 latency and the revert rate. This is the only honest way to characterize a cross-chain route, and it is reproducible by anyone with the same transaction hashes.

Troubleshooting stuck and failed transfers

If the source receipt is missing, the transaction has not been mined or was dropped; re-broadcast or check the nonce. If the source receipt succeeded but no attestation appears, the validator set may be below quorum, the relayer may be lagging, or the message may be queued behind a rate limit. If the destination transaction reverted, decode the revert data against the bridge ABI before retrying anything.

Never "fix" a stuck transfer by manually calling release functions on the destination bridge unless you fully understand the attestation check; that is exactly the path attackers use. Escalate through the bridge's documented recovery process, and treat any third party offering to unstick a transfer for a fee as hostile until proven otherwise.

• Missing source receipt: mining or nonce problem, not a bridge problem.
• Source confirmed, no attestation: quorum, relayer, or rate-limit issue.
• Destination revert: decode revert data; check deadline and slippage guards.
• Unexpected release: treat as a security incident and preserve logs.

Limitations and tradeoffs of cross-chain designs

Cross-chain systems expand the attack surface beyond either chain's own consensus. A bridge's verifier set, its contract upgrade authority, and its rate limits are all part of the trust model, and each adds a failure mode that does not exist on a single chain. Wrapped assets also introduce representation risk: the wrapper is only as redeemable as the custody contract behind it.

There is a real tradeoff between latency and assurance. Light-client verification is slower and more expensive but relies on cryptography rather than a committee. Committee-based bridges are faster and cheaper but concentrate trust. Neither is universally correct; the right choice depends on the value at stake and how much latency your application can tolerate. Document the choice explicitly in your architecture.

Operational next steps

Once you can verify transfers, the next step is making that verification continuous. Instrument your monitoring to poll both chains for the message ID, alert on transfers that exceed your measured p95 latency, and alert separately on destination reverts. Keep the source and destination RPC endpoints independent of the bridge's own infrastructure so a bridge outage does not blind your monitoring.

For production workloads, dedicated nodes reduce the variance that shared endpoints introduce during congestion, and the dedicated node offering is the place to start. If you are still choosing endpoints, the RPC Assistant's endpoint guidance and the RPC pricing page cover the concrete options, while the API service documentation explains how managed access is provisioned. Whichever route you take, keep the verification script in version control so the measurement method stays reproducible.