Cross chain security — Safety, Liveness and Economic Security

3 min readMay 5, 2022

Useful concepts for analysing security of cross chain protocols.


Safety means nothing bad happens.

Think Ronin/wormhole hack. Someone steals ⅔ of the validators’ keys and is now able to validate a hostile transaction. Another example is someone finds a random bug which sends all the votes to themselves.

Ronin’s bridge validator set


Liveness asserts that something good will eventually happen.

Think censorship. Someone steals between ⅓ and ⅔ of the validators’ keys and the system stops running forever. It’s safe, but it’s useless.

Nothing bad will happen, but nothing good will either

Note that liveness and safety should not bleed into each other. For example in an optimistic system, if you break liveness you can also break safety. An attacker can use censorship to allow a fraudulent update to pass through the optimistic challenge window (30min for Nomad, 7 days for optimism) without being contended.

In contrast, it doesn’t matter how long you take to validate a zk proof, nothing bad will happen while everyone is waiting for the proof to come through.

Economic Security

Game theory, basically. A system is secure if the value to be lost is higher than the value that can be gained by attacking.


Economic security is a fundamental characteristic of Proof-of-Stake systems. Optimistic systems should have no economic limits to their security, but in practice they need to introduce some economic elements to keep liveness.

ZKs inherit their economic safety directly from the underlying chain they are settled on, but also may have issues with liveness.

Structural Security

“Define each process and its interactions.”

Think of **every** process and interaction, have them covered, and you’re good, lol.

Suzanne Ciani testing in prod

I think of structural security as the attack surface of the system. How many different types of systems are we relying on for good liveness and safety, and what are the interdependencies of each?

Generally, the more attack surfaces, the worse, but sometimes, the more the better. For example, we don’t want all Ethereum validators to use the same client software, because if there is a bug in it, then an attacker could take over Ethereum.

There is no easy way of measuring structural security, but try to understand all the elements of a system and how they interact.

Gravity bridge involves interactions between: Tendermint client, Cosmos SDK modules, Ethereum’s PoW, the EVM, relayers.

Nomad’s model involves: Ethereum’s blockchain and PoW mining software, EVMOS’ blockchain and PoS software, watchers, updaters, relayers, processors and the interactions between all of them.