Design Rationale


The Namada Ethereum bridge system consists of:

  • A set of Ethereum smart contracts.
  • An Ethereum full node run by each Namada validator, to watch Ethereum events emitted by the bridge's smart contracts.
  • A set of validity predicates (VPs) on Namada.
    • A Bridge pool VP, to validate transfers to Ethereum and escrowed NAM.
    • An Ethereum bridge VP, to protect writes to Namada storage key sub-spaces containing Ethereum event tallies.
  • Two relayer utilities, to call the Ethereum smart contracts.
    • One for performing validator set updates on the Ethereum smart contracts.
    • Another to aid in submitting batches of transactions to Ethereum.

This basic bridge architecture should provide for almost-Namada consensus security for the bridge and free Ethereum state reads on Namada, plus bidirectional message passing with reasonably low gas costs on the Ethereum side.


On Namada, the validators are full nodes of Ethereum and their stake is also accounting for security of the bridge. If they carry out a forking attack on Namada to steal locked tokens of Ethereum their stake will be slashed on Namada. On the Ethereum side, there exists a limit to the amount of assets that can be locked to limit the damage a forking attack on Namada can do. To make an attack more cumbersome there also exists a limit on how fast wrapped Ethereum assets can be redeemed from Namada. This does not add more security, but rather makes the attack more inconvenient, and allows governance time to react.