Bridging Between EVM Chains from SSP

·8 min read·By SSP Editorial Team
Two EVM chains linked by a bridge, with an SSP 2-of-2 multisig co-signing the transfer

Bridging Between EVM Chains from SSP

Once you hold assets on more than one EVM chain, sooner or later you'll want to move value from one to another — ETH on Ethereum that you'd rather use on Base, a stablecoin on Polygon you need on BNB Smart Chain. That move is called bridging, and it's one of the most useful and most dangerous operations in crypto. Bridges are how the multi-chain world hangs together, but they have also been among the single largest sources of crypto losses. A clear-eyed approach to bridging EVM chains is essential for any self-custody user, and good crypto bridge safety habits are worth more than any feature.

This guide explains why bridging exists, how bridges work, why they carry outsized risk, and a practical framework for judging one before you use it. It assumes you already understand using SSP on Polygon, Base, and other EVM chains. Throughout, keep one thing in mind: the bridge is an external protocol, not part of SSP. SSP's job is to hold your assets and co-sign the transaction with 2-of-2; the bridging logic lives in someone else's smart contracts.

Why bridging exists at all

Each EVM chain is a separate ledger with its own state. Ethereum, Polygon, Base, BNB Smart Chain, and Avalanche don't natively share balances — a token on Ethereum is simply not visible or spendable on Polygon, even though your address can be identical across them. There is no built-in "send to another chain" button in the protocols themselves, because from each chain's point of view, the other chains don't exist.

That's a problem the moment you want to use value where it isn't. Say you hold ETH on Ethereum but want to interact with an app on Base, where fees are far lower. You can't just transfer it across; the two chains share no accounting. A bridge fills that gap. It's a system — almost always a set of smart contracts plus off-chain actors — that coordinates "I'll lock or burn your asset on chain A, and you'll receive a corresponding asset on chain B." Bridging is the connective tissue of a multi-chain world, and understanding it is part of understanding Ethereum in SSP and its wider EVM family.

How bridges actually work

Most bridges use one of a few mechanisms, and knowing which one you're using tells you a lot about the risk.

  • Lock-and-mint (lock-and-mint: lock the original, mint a stand-in). You deposit the native asset into a contract on the source chain, where it is locked. The bridge then mints a new representation of it on the destination chain. To go back, you burn the representation and the original is unlocked.
  • Burn-and-mint (burn-and-mint: destroy here, recreate there). The asset is burned on the source chain and an equivalent amount is minted on the destination. Supply moves rather than being held in a vault.
  • Liquidity-network bridges. Instead of minting, these keep pools of assets on both chains. You hand over your asset on one side and a liquidity provider releases the equivalent on the other, rebalancing later. Speed comes from the pool, not from locking and minting.

The critical insight for crypto bridge safety is what you receive on the far side. With lock-and-mint especially, the destination token is a representation — a bridged or "wrapped" version backed by the locked original — not the native asset itself. Two bridged versions of the "same" token, issued by different bridges, can coexist on one chain and are not interchangeable. Always confirm the exact token contract an app expects before relying on what you bridged.

Canonical bridges vs third-party bridges

Bridges also differ by who operates them, and that distinction matters for trust.

A canonical bridge (also called a native bridge) is the official bridge for a given chain, usually built by the team behind that network — for example, the native bridge a rollup uses to move assets to and from Ethereum. Its security is tied to the chain's own design, and the representation it issues is typically treated as the "real" bridged asset on that chain.

A third-party bridge is run by an independent project, often spanning many chains at once and frequently faster or more flexible than a canonical route. The trade-off is that you're trusting an additional system — its contracts, its operators, and whatever set of validators or signers it relies on. Neither category is automatically safe or unsafe, but the questions you should ask differ, and canonical routes generally carry fewer moving parts.

Why bridges are a top loss vector

Bridges concentrate value and complexity, which is exactly what attackers look for. A bridge often holds large reserves locked on one side, and the logic controlling their release is intricate. Historically, bridges have been among the largest sources of crypto losses, with individual incidents running into the hundreds of millions of dollars.

The failures tend to cluster around a few causes. Validator or multisig compromise is common: many bridges rely on a set of signers to authorize releases, and if enough of those keys are stolen or collude, funds can be drained regardless of how good the contracts are. Buggy contracts are the other big category — a flaw in how the bridge verifies deposits or mints representations can let an attacker fabricate withdrawals out of nothing. The point isn't to frighten you away from bridging, which is sometimes necessary, but to set expectations: a bridge is a high-value target, and a polished website tells you nothing about whether its release mechanism is sound.

A practical risk framework

Before bridging meaningful value, run through a short checklist. The independent tracker L2Beat's bridges section is a useful starting point for many of these answers, and the Ethereum Foundation's bridges overview explains the categories in neutral terms.

  • Who can move the funds? Is release controlled by the chain's own validity rules, or by an external set of signers? Fewer trusted parties generally means less to compromise.
  • What are the custody and validator assumptions? Understand whether your asset sits in a locked vault, a liquidity pool, or is burned and reminted — and who guards that mechanism.
  • Has it been audited, and by whom? Audits aren't guarantees, but their absence is a red flag. Look for reputable reviewers and whether findings were addressed.
  • Time-tested vs brand-new. A bridge that has secured large value through multiple market cycles has survived more adversarial pressure than one launched last month.
  • How much value does it hold (TVL)? Size cuts both ways: high total value locked signals adoption but also makes a bridge a bigger target. Read it as context, not a safety score.

Safer habits for an SSP user

The mechanics are out of your hands once you choose a bridge, but how you approach the operation is entirely in your control. A few habits go a long way:

  • Prefer canonical or official bridges when one exists for your route. Fewer trusted intermediaries usually means less to go wrong.
  • Double-check the destination chain and token contract. Confirm you're bridging to the network you intend, and that the asset you'll receive is the contract your destination app actually uses.
  • Beware fake bridge sites and phishing. Bridge front-ends are a favorite phishing target. Reach the interface through a link you trust, not a search ad or a message from a stranger, and verify the URL.
  • Start with a small test amount. Send a little first, confirm it arrives correctly on the other side, then move the rest. The cost of a test transfer is trivial next to the cost of a mistake.
  • Account for fees and finality time. You pay gas on both chains, and some routes have a waiting period before funds are final. Build that in rather than panicking when it isn't instant — and see gas fees on Ethereum, explained for self-custody users for how those fees work.
  • Connect via WalletConnect and co-sign with 2-of-2. You connect SSP to the bridge through WalletConnect, build the transaction, and approve it on your phone. The same two-device guarantee that protects every other SSP action protects the bridge transaction too — neither device alone can authorize it. Treat your recovery the same way you always do; seed phrase best practices still apply.

How this ties back to multiple EVM chains in SSP

Bridging is the operation that makes a multi-chain SSP setup genuinely useful: it's how value you hold on one EVM chain becomes value you can use on another. But it's worth being precise about the division of labor. SSP holds your assets and provides the 2-of-2 co-signing that authorizes the move; the bridge itself is an external protocol with its own contracts, operators, and risk profile that you are choosing to trust for that one transaction.

Keep those two ideas separate and bridging becomes far less mysterious. Pick the route carefully using the framework above, lean on canonical bridges where you can, test small, and let SSP do what it does best — keep the keys split across two devices so that even a bridge transaction needs both to say yes. From there, the rest of the EVM series is simply about using the chains you've connected with confidence.

Share this article

Related articles