If you have used a bridge to move funds onto Base, you have relied on a piece of infrastructure that most people never think about directly: a cross-chain messaging protocol. It is worth understanding, not because you need to use one yourself, but because it explains why some bridges you encounter behave so differently from others, and what you are actually trusting when you approve a bridge transaction.
What a bridge actually does, in the narrow sense
Our earlier guide on how to bridge to Base covers this from a user's point of view: a bridge locks or burns your asset on one chain and releases or mints an equivalent on another. That is the outcome you see. Underneath it, the bridge has to solve a harder problem first: how does the smart contract on the destination chain know that the lock or burn on the source chain actually happened?
Blockchains do not talk to each other on their own. Ethereum has no built in way of knowing what happened on Base, and Base has no built in way of knowing what happened on Solana or Arbitrum. Something has to observe the source chain, confirm the event was real, and deliver that information to the destination chain in a form its contracts can act on. That delivery job is what a cross-chain messaging protocol does.
Messaging is more general than bridging
A token bridge is one thing you can build once you have a way to pass messages between chains. But the same messaging layer can carry other kinds of information too: a vote result from a DAO on one chain that should trigger an action on another, a price update, a instruction to mint an NFT, or any other piece of data an application wants a contract on a different chain to see and act on.
This is why you will sometimes see "bridge" and "cross-chain messaging protocol" used almost interchangeably, even though they are not quite the same thing. The messaging protocol is the general purpose plumbing. A bridge for a specific asset is usually one application built on top of that plumbing, alongside others.
How the major messaging protocols differ
A few protocols currently handle a large share of cross-chain messages that involve Base and other EVM chains. They solve the same core problem in different ways, mostly around who is trusted to confirm that a message from the source chain is genuine.
- LayerZero uses a design where message delivery is split between separate parties, an oracle that reports the transaction header and a relayer that delivers the proof, with more recent versions allowing apps to choose a configurable set of independent verifiers. The idea is that no single party can forge a message on its own without the others noticing.
- Wormhole relies on a set of independent parties called Guardians who each observe the source chain and sign off on a message before it is considered valid on the destination chain. It has broad support across both EVM chains like Base and non-EVM chains such as Solana, which is part of why it shows up often in bridges that connect very different ecosystems.
- Axelar runs its own proof of stake network of validators who reach consensus on cross-chain messages, then relay them onward. It positions itself around general message passing between many chains rather than any single asset.
Circle's CCTP, which our guide on native USDC transfers and CCTP covers in more depth, takes a narrower and different approach still: rather than relying on an external network of validators, Circle itself attests that USDC was burned on the source chain before it will be minted on the destination chain. It is purpose built for one asset rather than general messages.
None of these designs is simply "better." Each one is a different answer to the same question: who do you trust to tell the destination chain that something real happened on the source chain, and how many of them have to agree before that message is acted on.
Why this matters to you, even if you never touch these protocols directly
Most people bridging into Base will never interact with LayerZero, Wormhole, or Axelar by name. You will use a bridge's interface, or a bridge aggregator that picks a route for you. But the messaging protocol underneath is part of what you are trusting when you use that bridge, alongside the bridge's own contracts.
A few practical takeaways follow from this:
- A bridge's security is only as strong as its weakest link. A bridge can have well audited contracts and still depend on a messaging layer with its own separate assumptions. Both matter.
- The same messaging protocol can power very different bridges. Two bridges that look unrelated on the surface may share the same underlying messaging layer, which means an issue with that layer could affect both at once.
- "Native" and "wrapped" assets sometimes trace back to this choice. Whether a bridge burns and mints a token natively, the way CCTP does for USDC, or locks it and issues a wrapped representation, often comes down to what the messaging protocol and the asset issuer have built together.
You do not need to evaluate these protocols yourself before using an ordinary bridge or aggregator. The people who build and maintain those tools have generally already made that assessment. But if you are moving a meaningful amount of value across chains for the first time on an unfamiliar route, it is reasonable to spend a few minutes looking up which messaging protocol a bridge relies on, alongside the checks covered in our bridging and aggregator guides.
The short version
Cross-chain messaging protocols are the general purpose layer that lets a contract on one chain learn about, and react to, an event on another chain. Token bridges are one application built on top of that layer, but not the only one. Protocols like LayerZero, Wormhole, and Axelar differ mainly in who confirms a message is genuine and how many parties have to agree, while purpose built systems like Circle's CCTP take a narrower approach for a single asset. Understanding this layer will not change how you use a bridge day to day, but it explains why bridge security write-ups often talk about more than just the bridge contract itself.
This is general information, not financial advice.