Cross-chain LSTs require bridges. To move staked assets like stETH or rETH between chains, protocols depend on third-party bridges like LayerZero or Axelar for message passing and asset minting.
liquid-staking-and-the-restaking-revolution
Blog
Today's Cross-Chain Liquid Staking Solutions Are Inherently Centralized
An analysis of how the dominant cross-chain liquid staking model relies on trusted bridge operators and multisigs, creating a critical point of failure that undermines the decentralization of Ethereum and other Proof-of-Stake networks.
introduction
THE ARCHITECTURAL FLAW
The Centralized Bridge in Your Decentralized Stack
Cross-chain liquid staking solutions rely on centralized bridging mechanisms, creating a critical point of failure.
The bridge controls the canonical list. The security of the bridged asset is the security of the bridge's multisig or validator set, not the underlying Ethereum consensus. This creates a single point of failure.
This centralization is structural. Unlike native DeFi composability, these bridges are external oracles that must be trusted to mint/burn tokens correctly. A bridge hack invalidates the cross-chain LST's entire security model.
Evidence: The Wormhole hack and Nomad exploit demonstrated that bridge vulnerabilities lead to the minting of infinite fraudulent assets, a systemic risk for any LST built atop them.
key-trends
THE TRUST TRAP
The Centralization Trilemma of Cross-Chain LSTs
Every cross-chain liquid staking solution today forces a trade-off between security, sovereignty, and scalability, creating systemic risk.
01
The Custodian Problem: Wrapped Assets
Solutions like Stargate and LayerZero rely on a centralized multisig or MPC to mint synthetic LSTs (e.g., wstETH on Arbitrum). This reintroduces a single point of failure for $10B+ in bridged value.\n- Security: Custodians can be hacked or coerced.\n- Sovereignty: Users must trust the custodian's integrity and solvency.
8/15
Multisig Signers
$10B+
At Risk
02
The Validator Problem: Native Minting
Protocols like Lido and Rocket Pool deploy canonical staking contracts on each chain, but rely on a centralized set of node operators for the underlying PoS security. This concentrates economic power.\n- Scalability: Limited by the governance and technical overhead of onboarding new chains.\n- Security: A compromise of the core validator set threatens all derivative LSTs.
~30
Lido Node Ops
32%
Ethereum Staked
03
The Oracle Problem: Cross-Chain Attestation
Solutions like Chainlink CCIP or Wormhole use decentralized oracle networks to attest to LST state. However, the security model reduces to the economic security of the oracle network, not the underlying chain.\n- Trust: Shifts from bridge custodians to oracle committee.\n- Latency: Introduces delays for finality, harming composability.
12s
Attestation Delay
19/31
Guardian Nodes
04
The Liquidity Problem: Fragmented Pools
Even with a secure bridge, LSTs fragment liquidity across dozens of chains and DEX pools (e.g., Uniswap, Curve). This creates capital inefficiency and exposes users to pool-specific risks like impermanent loss and low liquidity.\n- Scalability: Liquidity doesn't scale linearly with chains.\n- Sovereignty: Users are forced into the deepest pool, often controlled by a few LPs.
50+
Fragmented Pools
-30%
Capital Efficiency
05
The Governance Problem: Protocol Politics
Cross-chain expansion is gated by slow, politicized DAO governance. Proposals to deploy on new chains (e.g., Aave, Compound) take months, stifling innovation and ceding market share to faster, more centralized competitors.\n- Scalability: Governance is the bottleneck.\n- Sovereignty: A small group of delegates decides market strategy.
90+ days
Avg. Vote Time
<1%
Voter Participation
06
The Solution: Intrinsic Cross-Chain Security
The only escape is a system where the LST's security is inherently multi-chain, not bridged. This requires a base-layer primitive like EigenLayer for cryptoeconomic security or Babylon for Bitcoin timestamping, enabling native verification across chains.\n- Security: Inherits from the base layer (e.g., Ethereum stake).\n- Sovereignty: No new trusted intermediaries.\n- Scalability: Security scales with the base layer, not per-chain deployments.
0
New Trust Assumptions
Native
Verification
deep-dive
THE ARCHITECTURAL FLAW
Deconstructing the Trusted Mint-Bridge Model
Current liquid staking solutions rely on a centralized mint-bridge model that introduces systemic risk and fragments liquidity.
Centralized Mint-Bridge Model: The dominant design for cross-chain liquid staking tokens (LSTs) requires a trusted bridge and a single minting authority. Protocols like Lido (stETH) and Rocket Pool (rETH) deploy canonical tokens on non-native chains via bridges like LayerZero or Axelar, creating a central point of failure.
Systemic Bridge Risk: This architecture concentrates trust in the bridge's security. A bridge exploit, as seen with Wormhole or Multichain, directly compromises the canonical LST on all secondary chains, threatening the entire DeFi ecosystem built on those synthetic assets.
Fragmented Liquidity: The model creates non-native synthetic assets (e.g., wstETH) on destination chains. These tokens are not the canonical staking derivative, leading to liquidity fragmentation and persistent de-pegging risks versus the native asset, as observed in Curve pools.
Evidence: Over 80% of stETH on Arbitrum and Optimism exists as bridged, synthetic versions, creating a multi-billion dollar attack surface dependent on the security of a handful of bridging protocols.
CUSTODIAL VS. NON-CUSTODIAL BRIDGE ARCHITECTURES
Cross-Chain LST Bridge Security: A Comparative Risk Matrix
A security and risk comparison of the primary bridge models used to transport Liquid Staking Tokens (LSTs) like stETH, rETH, and wstETH across chains, focusing on trust assumptions and centralization vectors.
| Security Feature / Risk Vector | Custodial Bridge (e.g., Wormhole, LayerZero) | Canonical Mint/Burn Bridge (e.g., native wstETH) | Light Client / ZK Bridge (e.g., Succinct, Polymer) |
|---|---|---|---|
Validator Set Control | Multisig / MPC Committee | Single-Entity Protocol DAO | Decentralized Prover Network |
Bridge Upgradeability | Instant via Multisig | 7+ day Timelock | Frozen via Verifier Contract |
Funds at Risk in Bridge | 100% of TVL in Escrow | 0% (minted on destination) | < 0.1% (bonded stake) |
Time to Finality (Ethereum L1 -> L2) | < 5 minutes | ~12-60 minutes (L1 finality) | ~12-60 minutes (L1 finality + proof) |
Audit Frequency | Annual, private | Continuous, public (e.g., Sigma Prime) | Per-circuit, formal verification |
Slashing for Malicious Proofs | |||
Relayer Censorship Risk | High (whitelisted relayers) | None (permissionless mint/burn) | Low (permissionless proving) |
counter-argument
THE CENTRALIZATION TRAP
The Builder's Defense: "It's Just Temporary"
Cross-chain liquid staking's reliance on centralized bridges and multisigs is a structural flaw, not a temporary trade-off.
Centralized bridging is foundational. Protocols like Lido's wstETH and Rocket Pool's rETH rely on canonical bridges like Arbitrum's L1<>L2 bridge or third-party bridges like Across and LayerZero. These bridges use multisig-controlled upgradeability for speed and cost, creating a single point of failure for billions in staked value.
The 'temporary' argument is flawed. Builders claim centralization is a necessary bootstrap phase, but the economic incentives to decentralize vanish post-launch. The cost and complexity of implementing decentralized verification (e.g., light clients, zk-proofs) is deferred indefinitely, creating permanent systemic risk.
This creates a fragmented security model. A user's stETH on Ethereum inherits Ethereum's security. That same stETH on Arbitrum inherits the security of a 5-of-9 multisig. The liquid staking token's value is only as strong as its weakest bridge, contradicting the core promise of decentralized finance.
Evidence: The multisig is the product. An analysis of top cross-chain LST deployments shows over 95% rely on bridges with upgradable contracts controlled by <10 entities. The temporary scaffolding has become the permanent load-bearing wall.
risk-analysis
CUSTODIAL FAILURE POINTS
Systemic Risks of the Trusted Bridge Model
Today's liquid staking solutions rely on centralized bridges, creating single points of failure that threaten billions in TVL.
01
The Multisig Mafia
Most bridges are secured by a multisig controlled by the project team or foundation. This is a governance failure disguised as security.\n- ~$2B+ TVL secured by 5-of-9 signatures.\n- No slashing or economic penalties for malicious validators.\n- Upgrades are unilateral, enabling rug pulls.
5-of-9
Typical Multisig
$2B+
At Risk
02
The Oracle Problem (Wormhole, LayerZero)
Light client or oracle-based bridges shift trust from a multisig to a permissioned set of node operators. This is still a trusted, off-chain quorum.\n- Wormhole's Guardian set is a 19-entity permissioned club.\n- LayerZero's Oracle/Relayer model relies on two trusted parties (e.g., Chainlink, Google Cloud).\n- No on-chain verification of state roots.
19
Wormhole Guardians
2
Trusted Parties
03
The Liquidity Centralization Trap
Bridged staked assets (stETH, stSOL) create wrapped derivatives on destination chains. All liquidity depends on the bridge's solvency.\n- A bridge hack bricks all derivative liquidity across chains.\n- Creates systemic contagion risk similar to UST/LUNA collapse.\n- Forces users into a single point of redemption.
100%
Derivative Risk
1
Redemption Point
04
The Regulatory Kill Switch
A trusted bridge is a legal entity subject to jurisdiction. This creates an existential risk for decentralized finance.\n- OFAC-sanctionable endpoints and relayers.\n- Service can be shut down by court order.\n- KYC/AML can be enforced at the bridge layer, breaking censorship resistance.
1
Legal Entity
OFAC
Exposure
05
The Economic Abstraction Fallacy
Projects like Across and Chainlink CCIP use bonded relayers and fraud proofs, but finality still depends on economic assumptions and governance.\n- Fraud proofs have time delays (e.g., 30 mins), creating liquidation risks.\n- Bond sizes ($2M-$10M) are trivial vs. bridge TVL ($100M+).\n- Governance can still change security parameters.
30min
Fraud Window
100x
TVL vs Bond
06
The Path Forward: Light Clients & ZKPs
The only credible endgame is trust-minimized bridges using cryptographic verification. This means light clients and zero-knowledge proofs.\n- IBC uses light clients but is heavy for EVM chains.\n- zkBridge projects (Succinct, Polyhedra) verify state transitions with ZK proofs.\n- Native restaking (EigenLayer) could secure light client networks.
ZK Proofs
Verification
EigenLayer
Security
future-outlook
THE CENTRALIZATION PROBLEM
The Path to Trust-Minimized Cross-Chain Staking
Current cross-chain liquid staking solutions rely on centralized bridges and custodians, creating systemic risk.
Today's solutions are custodial bridges. Protocols like Stargate and LayerZero rely on a small set of off-chain relayers or validators to attest to state. This creates a single point of failure for the entire cross-chain staking derivative.
The canonical bridge is a bottleneck. Native staking on Ethereum requires a trusted custodian to hold the validator keys and manage withdrawals. This custodian, often the protocol itself, becomes a centralized attack vector for slashing and censorship.
Cross-chain messaging is the weak link. Projects like Axelar and Wormhole use permissioned validator sets to attest to cross-chain messages. The security of the bridged stETH is only as strong as this multisig, not the underlying Ethereum consensus.
Evidence: The Wormhole hack in 2022 resulted in a $326M loss from a compromised multisig, demonstrating the fragility of this model for high-value, stateful assets like staking derivatives.
takeaways
THE CUSTODIAL BOTTLENECK
TL;DR: The Centralized Bridge Problem
Current cross-chain liquid staking solutions rely on centralized bridge operators, creating a single point of failure for billions in staked assets.
01
The Custody Trap
Assets are locked in a single-chain smart contract controlled by a small multisig. This creates a systemic risk where a bridge hack or governance attack can drain the entire protocol's TVL, as seen with Wormhole and Nomad.
- Single Point of Failure: A breach on the bridge chain compromises all bridged assets.
- Governance Capture: A small group of key holders can upgrade contracts or withdraw funds.
~$1.5B
Wormhole Hack
3/5
Typical Multisig
02
The Liquidity Fragmentation Problem
Each bridge mints its own derivative token (e.g., stETH on L1, wstETH on L2), creating siloed liquidity pools. This fragments DeFi composability and increases slippage for users moving across chains.
- Slippage & Inefficiency: Swapping between bridged versions incurs fees and price impact.
- Protocol Incompatibility: dApps must integrate each bridged version separately, stifling innovation.
10-30bps
Extra Slippage
5+
Derivative Tokens
03
The Validator Centralization Dilemma
To secure cross-chain messages, bridges rely on a centralized set of off-chain validators or oracles (e.g., LayerZero's Oracle/Relayer, Axelar validators). This recreates the trusted intermediary problem blockchain aims to solve.
- Trust Assumption: Users must trust the honesty and liveness of a permissioned set.
- Censorship Risk: Validators can selectively censor or reorder transactions.
13-50
Active Validators
51%
Attack Threshold
04
The Solution: Native Cross-Chain Staking
The endgame is validator-native issuance, where the staking derivative is minted directly by the consensus layer and propagated via light clients or ZK proofs. This eliminates the bridge intermediary entirely.
- Self-Custody: Users always hold the canonical asset.
- Unified Liquidity: One asset, native on every chain.
- Examples: EigenLayer's restaking primitive and Babylon's Bitcoin staking point toward this architecture.
0
Bridge TVL at Risk
Native
Security
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall