Criteria for MainNet

[mfornet]

I propose we split the bridge deployment to mainnet in two stages.

1. In the first stage the bridge is deployed in its current state (almost), it only requires upgradability, but it would be unaudited, and not fully covered with tests so funds might be lost in case of severe bug.
2. In the second stage we are going to keep the state for the bridge (using upgradability if required), we should be able to claim that bridge is secure, and we public announce that it is production ready.

Motivation

• From the feedback received so far, I understand that developers are willing to test the bridge on mainnet (even though they know it won't be safe to use it for high volume financial applications).
• We need to have bridge running in mainnet for some period, and have early users testing it (either in expected and unexpected ways) to hit early bugs as fast as possible, before we can announce it to the big audience.
• Bridge in mainnet will increase motivation for hackers to do bug bounties (actually this might be a counter-argument if hackers don't reveal an issue and tries to exploit it later to steal funds).

Stage 1 Criteria

• Ropsten bridge and Rinkeby bridge should run for two weeks without any problem.
• We have alerts in place that allows us to react fast in case of any service failure (relayers, watchdog).
• God mode upgradability is implemented, tested (in synthetic tests in CI), and exercised (in Ropsten and Rinkeby bridges).
• Front-end and Step by Step Guide is ready to be used in mainnet (to transfers tokens from Ethereum to Near, and send them back).
• All tests in bridge related repositories should pass.

Stage 2 Criteria

• Four weeks without issues after bug bounties is started (Notice that bug bounty will not necessarily start immediately after stage 1).
• Code is audited internally and externally.
• Fast response guide about how to react in case of any issue. We should have a guide about all steps that needs to be done and have internal session to prepare bridge developers and on-call engineers in this regard.
• The code is extensively tested (we should define this criteria in: Outlining the testing scenarios #474)

For more considerations see previous critieria