Native bridge vs. third-party bridge: which one holds your funds?

15 October 2026

The short answer: both hold your funds, but in different ways, and the risk profile is not the same. A native bridge is built by the team behind the destination chain (or the asset's home chain) and typically holds your tokens in a single, centralized smart contract or multisig. A third-party bridge is operated by an independent project, and it holds your funds in its own liquidity pools or lockup contracts. Neither holds your funds the way a bank does, and neither is immune to failure. The real question is: who do you trust with your money while your transaction is in flight, and what happens if that trusted party gets hit?

What a native bridge actually does

A native bridge is the official bridge for a given network. Think of the bridge that the team behind Arbitrum runs to move ETH onto Arbitrum, or the one that the Optimism team maintains. When you deposit ETH into a native bridge, the bridge contract on Ethereum locks your ETH. A corresponding contract on the destination chain mints a representation of that ETH - often called a canonical wrapped token. The process is symmetrical: when you want to go back, the bridge burns the wrapped token and unlocks the original.

The key detail is where the funds sit. In a native bridge, the funds are typically held in a smart contract that the bridge team controls, often through a multisig wallet. The team can pause the bridge, and in some cases, they can upgrade the contract to change how it works - including potentially draining it if their private keys are compromised. The upside is that the destination chain's ecosystem treats this wrapped asset as the "real" one, so you get the canonical version of the token, not a third-party's promise about it.

What a third-party bridge actually does

A third-party bridge - like those run by projects such as Stargate, Across, or Wormhole (though Wormhole is more of a messaging layer) - does not rely on the destination chain's official contracts. Instead, it operates its own set of contracts on both the source and destination chains. The mechanics vary, but the core idea is often the same as a native bridge when it comes to lock-and-mint, or it might use a liquidity pool model where the bridge's own liquidity providers front the tokens on the destination side.

With a liquidity pool bridge, you deposit token A on the source chain. The bridge's smart contract takes that deposit, and a separate contract on the destination chain pays out token B from a pool of pre-funded liquidity. The bridge's operators earn fees from this service. Your funds are not locked in the same way they would be with a native bridge; instead, you are trusting the bridge's operators to maintain sufficient liquidity on the other side. If the bridge's smart contract has a bug, or if the operators' keys are stolen, the pool can be drained, and your claim on the destination side becomes worthless.

Where the Funds Actually Sit During a Transfer

Both types of bridges share a common feature: while your transaction is in flight, your funds are not in your wallet. They are in the bridge's contract. This is a period of trust. The difference is the degree of that trust.

• Native bridge: Your funds sit in a contract controlled by the destination chain's team. The team can pause withdrawals, and they can upgrade the contract. They can also, in theory, steal the funds if their multisig is compromised. However, the contract is usually audited by the same team that built the chain, and the wrapped asset is recognized as canonical by all applications on that chain. The risk is concentrated in a single point of failure: the team's operational security.

• Third-party bridge: Your funds sit in a contract controlled by an independent project. That project may have its own token, its own governance, and its own security model. Some third-party bridges use a validator quorum (a group of signers that must approve transactions) to secure the bridge. Others rely on economic incentives, where validators post collateral that can be slashed if they misbehave. The risk is not just the project's competence; it is also the project's financial health. If the bridge's liquidity pool is too small to cover a large withdrawal, you might not get your funds out at all.

Which one is safer for your funds?

There is no blanket answer. A native bridge from a well-established chain like Arbitrum is generally considered lower risk than a small third-party bridge that has been audited only by a firm with no reputation. But a native bridge that was rushed to market, with a single multisig, might be riskier than a third-party bridge that uses a proven validator set and has a large insurance fund.

The more useful question is: what are you trying to do? If you want the canonical wrapped asset on the destination chain - the one that all the major decentralized applications recognize as the "real" token - then a native bridge is the way to go. If you are moving a smaller amount and you care more about speed or lower fees, a third-party bridge might be fine, but you need to check its security model first.

How to Evaluate a Bridge Before You Send Funds

Before you send anything, do the following, in order:

1. Check whether the bridge is the canonical one for the destination chain. Look at the destination chain's official documentation or its block explorer. Does the bridge address match the one listed there? If not, you are likely on a phishing site.

2. Look at who controls the bridge contract. Is it a multisig? If so, how many signers are there, and who are they? A 3-of-5 multisig is very different from a 13-of-15 quorum. More signers usually means more security, but only if the signers are independent and not all controlled by the same entity.

3. Check the bridge's audit history. Has the contract been audited by a reputable firm? Has it been through multiple audits? Have there been any reported incidents? A bridge that has never been hacked might not be safer; it might just not have been tested yet.

4. See if there is a delay or a rate limit. Some bridges have a built-in 7-day withdrawal period for security reasons. Others have daily limits. If a bridge has no limits at all, be suspicious. If it has a long delay, ask yourself why.

5. Look at the liquidity on the destination side. If you are using a liquidity pool bridge, can you see the size of the pool? If the pool is small, your withdrawal might fail or be delayed. If the pool is large, you are still trusting the bridge's operators to not run off with it.

The Bottom Line

Both native and third-party bridges are custodial in the sense that you do not control your funds while the transfer is in progress. The difference is who the custodian is and what happens if that custodian fails. Native bridges tend to be more integrated into the ecosystem, which can mean better recognition of your wrapped asset, but they also concentrate risk in a single team. Third-party bridges offer more choice and sometimes better speed or fees, but they introduce an additional layer of trust in an independent project's code and operations.

Your job, as a user, is to understand which risk you are taking on. Read the bridge's documentation. Look at the multisig. Check the audits. And if something feels off, do not send your funds. The bridge will still be there tomorrow, but your money might not be.

Back to bridges