If you move crypto from one blockchain to another, it is tempting to imagine the asset travelling across a digital bridge.
That is not really what happens.
Ethereum cannot simply look at Solana and recognise that you have deposited 1 ETH there. Each blockchain keeps its own state and follows its own rules. A system is needed to establish that something happened on one network before another network can act on that information.
That system is a crypto bridge.
The important question is not only how a bridge moves value between chains, but how it proves that the move actually happened. That verification step is what makes cross-chain activity possible — and what has made bridges such attractive targets for attackers.
How do crypto bridges move assets between blockchains?
A crypto bridge creates a connection between two otherwise separate blockchain environments.
Imagine that you hold ETH on Ethereum and want to use its value on another network. The destination blockchain cannot simply take Ethereum’s word for it. It needs some mechanism to establish that the relevant amount of ETH was deposited or otherwise accounted for on the source chain.
One common design locks the original asset in a smart contract on the source blockchain. Once the deposit has been confirmed, a corresponding representation can be created on the destination chain.
This is where wrapped tokens come in. A wrapped token is designed to represent an asset that exists elsewhere. The token on the destination chain is not the original ETH sitting on Ethereum; it represents a claim connected to the asset held by the bridge.
The basic relationship matters.
If a bridge has 10,000 units of an asset locked on one side and issues 10,000 corresponding tokens on the other, those two quantities need to remain properly linked. If the bridge creates tokens without the necessary backing, users may end up holding an asset that no longer represents what they think it does.
That is the fundamental problem a bridge has to solve: maintaining a reliable relationship between activity on two different blockchains.
What happens to your crypto when you use a blockchain bridge?
There is no single mechanism used by every bridge.
With a lock-and-mint model, the original asset is locked on the source chain and a corresponding representation is issued on the destination chain. To reverse the process, the representation can be destroyed and the original asset released.
A burn-and-mint model works differently. Instead of keeping the original token locked while creating a wrapped version, the token is burned on one network and an equivalent amount is issued on another. This can reduce the need for wrapped representations, although it depends on the issuer or protocol being able to control issuance across the relevant chains.
There are also systems based on liquidity pools. Rather than minting a representation of the user’s asset, these protocols maintain pools of assets on different networks. A user deposits one asset on one chain and receives an equivalent asset from liquidity available on another.
From the user’s perspective, these mechanisms can look remarkably similar: select a network, choose an asset and confirm the transaction.
Underneath the interface, however, they make different assumptions about where the funds are held, who controls them and how the two sides are kept in sync.
That distinction becomes crucial when something goes wrong.
How do crypto bridges verify that a cross-chain transaction is real?
This is the hardest part of the problem.
Suppose you deposit 100 ETH on Ethereum. How does another blockchain know that the deposit actually happened?
One approach is to use a group of validators or guardians that monitor the source chain and sign a message confirming the event. The destination-side smart contract then checks those signatures before approving the corresponding action.
Wormhole, for example, uses a Guardian network to validate and sign cross-chain messages. Its current documentation describes a 19-Guardian network in which a supermajority of Guardians must sign the same message for it to be treated as valid.
Another design may use multisig, short for multi-signature, where several keys are required to authorise an operation.
More sophisticated systems attempt to verify information from the source blockchain more directly, reducing the amount of trust placed in an external group.
This creates an important distinction between blockchain security and bridge security.
Ethereum might be operating exactly as designed while the bridge connecting it to another network is compromised.
The blockchain does not need to be hacked for the bridge to fail.
Why are crypto bridges so vulnerable to hacks?
Bridges sit at an awkward intersection.
They need to understand events on one blockchain, communicate that information to another and often control or coordinate significant amounts of value along the way. That creates a larger and more complicated attack surface than a transaction that stays within a single network.
The critical question is therefore not simply whether a bridge is “decentralised”.
It is:
Who has the authority to say that a cross-chain transaction is valid?
If that authority is concentrated in a small number of keys, compromising those keys may be enough to release funds.
If the verification logic contains a bug, an attacker may be able to make the destination chain accept an event that never occurred.
And if the bridge’s smart contracts are incorrectly configured, a valid-looking message may trigger an action it was never supposed to authorise.
Research into bridge attacks has repeatedly identified the interaction between on-chain and off-chain components as a source of additional risk.
What can the biggest bridge hacks teach us about crypto bridge security?
The major incidents are useful because they show that there is no single way for a bridge to fail.
In the Ronin Bridge attack, attackers obtained enough validator keys to authorise fraudulent withdrawals. The incident demonstrated the danger of concentrating operational control, even when a system uses multiple signatories.
Wormhole illustrated a different problem. In 2022, an attacker exploited a flaw in the verification process and was able to create roughly $326 million worth of ETH on Solana without the corresponding deposit being properly secured on Ethereum.
Then came Nomad, where a faulty configuration caused messages that should have been rejected to be treated as valid. Once the vulnerability became visible, other users were able to reproduce the exploit and withdraw funds.
These incidents are often grouped together as “bridge hacks”, but their causes were not identical. Security failures can come from stolen keys, flawed verification, incorrect configuration or vulnerabilities in the underlying smart contracts.
That is why simply checking whether a bridge has been audited is not enough.
An audit can identify code vulnerabilities. It cannot, by itself, eliminate every risk created by governance, key management or the assumptions built into the bridge’s architecture.
Are newer crypto bridges trying to reduce the need for trust?
Yes, but this does not mean the problem has disappeared.
Some bridge designs use light clients, which are systems capable of verifying relevant information about another blockchain without relying entirely on an external group of signers.
Others use zero-knowledge proofs, which allow one system to verify that a particular computation or condition is correct without reproducing every step of the underlying process.
There are also intent-based systems. Instead of requiring the user to follow a specific cross-chain route, the user states the desired outcome — such as receiving a certain amount of an asset on another network — while another participant handles the execution.
These approaches can change the security model considerably. But they do not create a universal definition of “trustless”.
They simply move the trust assumption.
A user might trust a validator set in one system, a smart contract and cryptographic proof in another, or a network of liquidity providers in a third.
That is why comparing bridges only by fees or transaction speed can miss the most important difference between them.
What should you check before using a crypto bridge?
For users, the most useful questions are surprisingly straightforward.
Who verifies the transaction? A bridge controlled by a small group of signers has a different risk profile from one that relies more heavily on on-chain verification.
How many signatures are required? The number matters, but so does who controls those keys and whether the signers are genuinely independent.
What happens if one key is compromised? A robust design should not make a single compromised credential enough to drain the system.
Has the smart contract been audited? Audits are useful, but they should be treated as one security measure rather than a guarantee.
Is there a native alternative? If the destination network or application supports the asset directly, avoiding a bridge may remove an additional layer of risk.
And for a first transaction, sending a small amount is sensible. It gives you an opportunity to verify the destination network, token and withdrawal process before putting a larger balance through the same system.
The deeper lesson is that using a crypto bridge is not simply a matter of moving an asset from Chain A to Chain B.
You are relying on a mechanism to establish that the two chains agree about what happened.
That mechanism might depend on smart contracts, validators, cryptographic proofs, liquidity providers or some combination of them. The more directly the system can verify the state of the source blockchain, the less it may need to rely on a separate group of intermediaries — but every design still has assumptions that users need to understand.
A bridge is therefore only as strong as the proof connecting its two sides.
And that is the question worth asking before using one: not just where your crypto is going, but who — or what — is being trusted to prove that it got there.