Upstate’s Cross-Chain Bridge Risks: 3 Common Mistakes and Safer Solutions

Cross-chain bridges have become essential infrastructure for moving assets between blockchains, but they also concentrate risk. Each bridge is a complex system of validators, smart contracts, and relayers—and history shows that even well-funded projects can lose millions overnight. This guide from Upstate focuses on three common mistakes we see in bridge deployments and offers concrete safer solutions. Whether you're a developer integrating a bridge or a treasury manager choosing where to allocate liquidity, the goal here is to help you avoid the most predictable failure modes.

Where Cross-Chain Bridges Show Up in Real Work

Bridges appear in two main contexts: as a user moving tokens between chains, and as a protocol developer integrating cross-chain functionality. For users, the mistake is often choosing a bridge based solely on low fees or fast confirmation times without understanding its security model. For developers, the pressure to ship quickly can lead to shortcuts—like forking an unaudited bridge contract or using a small validator set without proper decentralization.

In a typical scenario, a DeFi protocol wants to offer its token on Ethereum, Arbitrum, and Optimism. The team picks a bridge that seems popular, deploys a liquidity pool, and announces the multi-chain expansion. Within weeks, they discover that the bridge's validator set has only three nodes, all run by the same entity. A single compromise drains the pool. This is not a hypothetical—several high-profile exploits followed exactly this pattern.

Another common use case is the NFT bridge for cross-chain art. Here, the risk is different: metadata consistency and mint authority. If the bridge doesn't properly verify that a token is locked on the source chain before minting on the destination, an attacker can mint unlimited copies. We've seen this happen with bridges that relied on a single oracle instead of a consensus mechanism.

The key takeaway: bridges are not a commodity. Each one has a different trust model, and matching that model to your use case is the first step toward safety.

Foundations Readers Confuse

Two concepts that cause the most confusion are trustless vs. trust-minimized and canonical vs. third-party bridges. A truly trustless bridge would require no external assumptions beyond the security of the underlying blockchains—but in practice, almost all bridges rely on some trusted set of validators, oracles, or relayers. A trust-minimized bridge reduces that reliance through cryptographic schemes like threshold signatures or optimistic verification, but it's not zero trust.

Canonical bridges are built by the chain's core team—like Arbitrum's native bridge or Polygon's PoS bridge. They are generally considered more secure because they are maintained by the same team that secures the chain itself. Third-party bridges (e.g., Wormhole, Multichain, Synapse) are independent projects that often support many chains simultaneously. They offer more flexibility but introduce additional risk because their security depends on a separate set of validators and smart contracts.

Another foundational confusion is between lock-mint and burn-mint mechanisms. In lock-mint, tokens are locked in a smart contract on the source chain, and an equivalent amount is minted on the destination. In burn-mint, tokens are burned on the source and minted on the destination. Both are vulnerable if the bridge's validators collude to unlock tokens without burning them on the destination. The difference matters for auditability and for how liquidity is managed.

We also see teams confuse bridge security with smart contract security. A bridge can have perfect Solidity code but still be insecure if its validator set is centralized or if the relayer network is vulnerable to censorship. Security is a system property, not a code property.

Why These Confusions Lead to Mistakes

When a team believes a bridge is trustless but it's actually trust-minimized, they may skip monitoring the validator set. When they confuse canonical with third-party, they might choose a bridge that lacks ongoing maintenance. And when they focus only on contract audits, they miss the operational risks that cause most exploits.

Patterns That Usually Work

After observing dozens of bridge integrations, three patterns consistently reduce risk. First, use a canonical bridge when one exists. For example, if you're moving ETH to Arbitrum, use Arbitrum's native bridge—it's simple, audited, and maintained by the same team. The trade-off is that canonical bridges may be slower or support fewer assets, but for core assets, it's the safest path.

Second, implement a threshold signature scheme (TSS) for validator sets. Instead of a single multi-sig, TSS requires a threshold of validators to sign off on each message. This distributes trust and makes it harder for a small number of compromised keys to drain the bridge. Many modern bridges like Chainlink CCIP use this approach.

Third, monitor the bridge actively. Set up alerts for large transfers, validator set changes, and contract upgrades. Use tools like Tenderly or Forta to watch for anomalous behavior. The most successful bridges have dedicated monitoring teams that respond within minutes to suspicious activity.

These patterns work because they align incentives: canonical bridges align with the chain's security, TSS reduces the blast radius of a key compromise, and monitoring provides early warning. They are not foolproof, but they raise the cost of an attack significantly.

When to Use Each Pattern

Canonical bridges are best for high-value, core assets. TSS is ideal for bridges that need to support many chains with a moderate number of validators. Active monitoring is a must for any bridge holding more than $1 million in total value locked (TVL).

Anti-Patterns and Why Teams Revert

Despite knowing better, many teams still fall into anti-patterns. The most common is using a bridge with a small, static validator set. We see this especially in early-stage projects that want to launch quickly. They set up a 3-of-5 multi-sig and call it a day. But a multi-sig is not a bridge—it's a manual approval process that doesn't scale and is vulnerable to social engineering.

Another anti-pattern is ignoring liquidity pool risks. Some bridges use liquidity pools on the destination chain to facilitate swaps. If the pool is imbalanced or has low liquidity, an attacker can manipulate the price and drain the bridge. This happened with several bridges that used automated market makers without proper slippage protections.

Why do teams revert to these unsafe patterns? Pressure to ship, lack of budget for security, and overconfidence in audits. An audit only checks the code at a point in time; it doesn't protect against future upgrades or operational failures. We've seen teams that passed multiple audits still lose funds because they ignored the validator set.

The fix is to treat bridge security as an ongoing process, not a one-time event. That means regular reviews, penetration testing, and a clear incident response plan.

Common Excuses and Why They Fail

“We'll decentralize later” is a dangerous promise. Bridges that start centralized rarely become decentralized because the operational overhead increases. “Our bridge is audited” is not enough—ask for the audit report and check what was in scope. “We have insurance” may help with user compensation but doesn't prevent the exploit.

Maintenance, Drift, and Long-Term Costs

Bridges require ongoing maintenance that many teams underestimate. Smart contracts need to be upgraded as the underlying chains change—Ethereum's EIP-1559, for example, affected how gas fees are calculated, which broke some bridges. Validator nodes need to be updated, and the relayer network needs to be monitored for latency or failures.

Over time, bridges tend to drift from their original security model. A bridge that started with 10 validators may lose participation and end up with 5. A bridge that used a specific oracle may switch to a cheaper one without proper testing. These drifts happen gradually and often go unnoticed until an exploit occurs.

The long-term cost of maintaining a bridge is often higher than building it. Teams should budget for at least one full-time security engineer per bridge, plus periodic external audits. For smaller teams, it may be more cost-effective to use a bridge-as-a-service provider that handles maintenance—but then you trade control for convenience.

We recommend conducting a quarterly review of each bridge's security posture, including validator set health, contract upgrade history, and incident response drills. This is not optional; it's the price of keeping user funds safe.

Cost-Benefit of Different Maintenance Levels

A minimal maintenance approach (monitoring only) might cost $50k/year in tools and part-time staff. A full in-house team with regular audits could run $500k/year. For a bridge with $100 million TVL, that 0.5% annual cost is reasonable insurance.

When Not to Use This Approach

There are situations where using a bridge at all is the wrong call. If your use case is a small testnet or a proof-of-concept, the overhead of securing a bridge isn't worth it—just use a single chain. If the asset you want to bridge is highly volatile or has low liquidity on the destination chain, the price impact alone could cost more than any fee savings.

Another case: if you don't have the resources to monitor the bridge, don't use one. A bridge that isn't actively watched is a ticking bomb. We've seen projects that deployed a bridge, then forgot about it for six months. When they finally checked, the validator set was down to two nodes and the contract had been upgraded without their knowledge.

Finally, if the bridge you want to use has no public audit, no clear validator set, and no incident history, stay away. Transparency is a minimum requirement. If the team behind the bridge isn't willing to share details, assume the worst.

In these cases, consider alternatives: use a single-chain strategy until you can afford proper bridge security, or use a centralized exchange as a bridge (with the understanding that you trust that exchange). The latter is not decentralized, but for small amounts, it may be acceptable.

Signs You Should Not Bridge

You cannot afford to lose the assets. You have no monitoring in place. The bridge's documentation is sparse or contradictory. The validator set is controlled by a single entity. These are red flags that should make you reconsider.

Open Questions and Common FAQs

We often hear the same questions from teams evaluating bridges. Here are the most frequent ones, with our best answers based on current practices.

What is the safest bridge today?

There is no single safest bridge because safety depends on your use case. For moving ETH between L2s, canonical bridges are safest. For cross-chain messaging, Chainlink CCIP has a strong security model with TSS and multiple independent validators. Always check the current state of the bridge's validator set and recent audits.

How many validators are enough?

There's no magic number, but we recommend at least 7 validators with a threshold of 5, and they should be run by independent entities. Geographic and cloud diversity also matter—if all validators are on AWS in us-east-1, a single outage can halt the bridge.

Should I build my own bridge or use an existing one?

For most teams, using an existing bridge is safer and cheaper. Building a bridge requires deep expertise in cryptography, distributed systems, and smart contract security—and even then, mistakes are easy to make. Only build if you have a dedicated team and a unique requirement that no existing bridge meets.

How often should I audit my bridge?

At least once a year, and after every major upgrade. Some teams do audits before every mainnet deployment. The cost is high, but it's lower than the cost of an exploit.

What happens if a bridge is exploited?

It depends on the bridge's design. Some bridges have pause mechanisms that can stop withdrawals. Others rely on social coordination to fork the chain. In most cases, users lose funds. That's why prevention is critical.

Summary and Next Steps

Cross-chain bridges are powerful but fragile. The three common mistakes we've covered—over-reliance on unaudited bridges, ignoring liquidity pool risks, and skipping emergency drills—are avoidable with proper planning. Start by auditing your current bridge setup: check the validator set, review recent upgrades, and set up monitoring. If you're planning a new bridge integration, choose a canonical bridge when possible, implement TSS for validator sets, and budget for ongoing maintenance.

Your next three moves: (1) Run a tabletop exercise simulating a bridge exploit—who gets called, what gets paused, how do you communicate with users? (2) Review your bridge's incident history and compare it to alternatives. (3) Set up a dashboard that tracks validator health, TVL changes, and contract upgrade events. These steps won't eliminate all risk, but they will put you ahead of most teams.

We'll continue to publish practical guides on cross-chain security at Upstate. In the meantime, stay safe out there—and remember that the best bridge is the one you don't need.