Specs: Ethereum bridge recovery multisig

anoma / namada

Rust implementation of Namada, a Proof-of-Stake L1 for interchain asset-agnostic privacy

https://namada.net

GNU General Public License v3.0

2.39k stars 948 forks source link

Specs: Ethereum bridge recovery multisig #170

Closed cwgoes closed 1 year ago

cwgoes commented 2 years ago

As discussed with @adrianbrink

Require all Namada validators to create an Ethereum address and sign it
Create a threshold 2/3 multisignature contract on Ethereum with voting weights and addresses of the validators
Keep that contract up to date when there are validator set updates
After a delay period with no regular updates, the contract can recover the funds in the Namada bridge contract

cwgoes commented 2 years ago

cc @Fraccaman

Fraccaman commented 2 years ago

The current contract implements a recovery mechanism but there is no delay period. How should that be implemented?

cwgoes commented 2 years ago

We should keep a timestamp of the last (regular) header update from Namada, and recovery from the multisig can only be initiated if now - lastUpdateTimestamp > delayPeriod. delayPeriod can be a week or something like that.

cwgoes commented 1 year ago

@Fraccaman @batconjurer have we implemented a recovery multisig yet, or not yet?

batconjurer commented 1 year ago

@cwgoes Not yet, no

sug0 commented 1 year ago

I presume this is related to https://github.com/anoma/ethereum-bridge/issues/62 ??

cwgoes commented 1 year ago

Yes, unless you had another, different plan for enabling emergency withdrawals.

sug0 commented 1 year ago

@cwgoes was just checking. all namada side things are complete, then. only the smart contracts need to be updated, so I'm closing the issue on this side