Gwei Name Service

.gwei post
donnoh.gwei

External bridges vs Rollups' security councils

Crossposted from X, where it was published on 20 January 2026.

When a token is bridged from chain to chain, someone needs to mint at destination. Sometimes, like with USDC, the entity that mints at destination is the same entity as the original token issuer, in this example Circle via CCTP. If this is the case, no additional trust and no additional intermediaries are present when moving or holding tokens on different chains.

Managing cross-chain transfers is complicated, and most token issuers (rightfully) decide to delegate such job to external providers. There are many examples: Wormhole, Chainlink CCIP, Axelar, LayerZero, Hyperlane. Such providers, to send you the token at destination, first need to mint it. This creates additional entities, outside the original issuer, that can either arbitrarily inflate token supplies or prevent tokens from being bridged back, causing loss of funds (i.e. rug you).

Don't be fooled by thinking that intent protocols, like Near Intents, necessary bypass these entities. While it is true that they allow you to get tokens at destination without minting, if the token you receive is not "native" to the destination chain, then someone had to mint it, and you are likely dependent on another bridge that you don't clearly see. For example, if you bridge using Across, you might get a token that was minted by LayerZero, inheriting its risks, even if you haven't touched LayerZero at all during the bridge operation. In general, if a token is there, someone had to mint it.

Most of these protocols mint tokens through "validator networks", or "guardians", or "attesters". In practice, they often have no differences with a simple multisig. As with all multisigs, there is a trade-off between safety and liveness: if the threshold is too low, then it takes less dishonest entities to sign a malicious message, and if it is too high, it takes less dishonest entities to cause a liveness failure, i.e. not sign a valid message. In this cases, we say that we rely on a "honest majority", and that the protocol fails in the presence of a dishonest minority, which could either cause a safety or a liveness failure, depending on the threshold.

Doing better than relying on intermediaries with honest majorities is hard. The main problem is that a chain usually has no visibility on what happens on another chain, and validating that someone sent some amount of a certain token on one chain and that the same amount needs to be minted on the other side is difficult without relying on a trusted intermediary that tells you what effectively happened.

Turns out, if you design a chain so that it has native visibility of another chain which gets fully validated, and you validate your state back, then you can have a bridge that doesn't rely on any committee. I will not explain how rollups work in this article, I just want to remind everyone that the whole goal of rollups is precisely to design chains that don't have to rely on honest majorities to get tokens from the outside.

While this might be obvious for Stage 2 rollups, some argue that if Security Councils are present, i.e. somewhat diverse multisigs that have the ability to immediately upgrade a rollup, then the security of rollup assets is equivalent to the ones managed by non-rollup bridge providers.

Many existing rollups are Stage 1, and are instantly upgradable by Security Councils.
Many existing rollups are Stage 1, and are instantly upgradable by Security Councils. The green or red man represents the "walkaway test", i.e. if it is possible to transact and exit in the absence of all permissioned operators, even minorities.

Stage 1 is exactly defined so that rollup bridged assets only rely on a honest minority assumption on the Security Council, meaning a dishonest majority needs to be dishonest to both cause a safety or a liveness failure, and a honest minority is enough to prevent it. Once again, this is possible only because minting of assets, and unlocking of assets, by default, does not rely on any entity and all messages get fully validated. Security Councils, who are supposed to be there only to protect from bugs, do not actively validate any message, unlike other external bridges, and are therefore not subject to the safety vs liveness tradeoff that is present when deciding on a threshold. Security Councils can therefore afford to have higher thresholds, and therefore better safety, without compromising liveness, at least in the absence of bugs.

Bugs are a big deal.
Bugs are a big deal. Read https://vitalik.eth.limo/general/2025/05/06/stages.html

The end goal of course remains Stage 2, where not even a honest minority assumption is needed. In the meantime, we should not forget that Stage 1 rollups can already provide better guarantees than external bridges.

StatusOn Ethereum since block 26269653
Blob0x01c11ed5…0749d1
Transaction0x0476ed03…c1d18e
Post hash0x634cd7f8…0d9830
More from donnoh.gweiShare

Posts on .gwei names are stored in Ethereum blobs and can be published by anyone. How it works →