Transferring assets from Ethereum to Namada

In order to facilitate transferring assets from Ethereum to Namada, there will be two internal accounts with associated native validity predicates:

• #EthBridge - Controls the /eth_msgs/ storage and ledger of balances of minted wrapped Ethereum assets (ERC20 tokens) structured in a "multitoken" hierarchy. Also contains in escrow Namada tokens which have been sent to Ethereum, pertaining to pending wNAM transfers.
• #EthBridgePool - Holds gas fees to be paid to relayers of transfers to Ethereum, as well assets (other than wNAM) in escrow, pertaining to pending transfers to Ethereum.

Wrapped ERC20

If an ERC20 token is transferred to Namada, once the associated TransferToNamada Ethereum event is included into Namada, validators mint the appropriate amount to the corresponding multitoken balance key for the receiver, or release the escrowed native Namada token.

pub struct EthAddress(pub [u8; 20]);
 
/// An event transferring some kind of value from Ethereum to Namada
pub struct TransferToNamada {
    /// Quantity of ether in the transfer
    pub amount: Amount,
    /// Address on Ethereum of the asset
    pub asset: EthereumAsset,
    /// The Namada address receiving wrapped assets on Namada
    pub receiver: Address,
}

Example

For 10 DAI i.e. ERC20(0x6b175474e89094c44da98b954eedeac495271d0f (opens in a new tab)) to atest1v4ehgw36xue5xvf5xvuyzvpjx5un2v3k8qeyvd3cxdqns32p89rrxd6xx9zngvpegccnzs699rdnnt

#EthBridge
    /ERC20
        /0x6b175474e89094c44da98b954eedeac495271d0f
            /balance
                /atest1v4ehgw36xue5xvf5xvuyzvpjx5un2v3k8qeyvd3cxdqns32p89rrxd6xx9zngvpegccnzs699rdnnt 
                += 10

Namada tokens

Any wrapped Namada tokens being redeemed from Ethereum must have an equivalent amount of the native token held in escrow by #EthBridge. Once the associatedTransferToNamada Ethereum event is included into Namada, validators should simply make a transfer from #EthBridge to the receiver for the appropriate amount and asset.

Replay protection

Transfer to Namada events are processed in order of their nonce, which is assumed to be a monotonically growing sequence number. While not strictly necessary, since these operations only increment the balance of some token owner in storage, and addition is governed by the commutative property, it is still important to process these events in order, such that Namada can discard older events, and not replay balance updates.