I wrote a bunch of posts & comments on Optimism forums about first steps toward decentralizing and minimum viable decentralization earlier this year, but never posted them here on this blog or on Twitter (Edit: I forgot that I had a Twitter thread about this just 4 days ago lol). Recently, Vitalik wrote about the topic. Basically, what Vitalik calls Stage 1 is what I’m looking for. But here’s my opinion of Stage 1:

The rollup is fully open-sourced

The rollup has established governance (note: not necessarily token, it can be a relatively centralized governance, as long as it’s orderly and transparent)

The bridge has automated rate limiting and circuit-breakers. If there’s an anomalous level of withdrawals to L1 relative to long-term average, withdrawals are appropriately throttled and governance/security council is expected to take action. The throttling can get exponentially longer, to a certain point where it’s effectively paused (i.e. circuit breaker). (Note: this mostly applies to zk rollups & extra-protocol bridges, as optimistic rollup bridges have an inherent delay anyway.)

Fraud proofs and validity proofs are live & audited. Fraud proofs are permissionless, so anyone can post fraud proofs. (Note: in the early days, there can be a whitelist of fraud provers elected by governance)

Sequencers & validity provers can be solo.

However, users can submit transactions from L1 that the sequencer must include. If the sequencer is offline or censoring, then a different sequencer takes over (in case of zk rollups, also proving)

For simplicity, there can be a pool of reserve sequencers elected by governance (see: Lido). The top voted sequencer that’s available fills in, in case the lead sequencer is offline or censoring. Of course, reserve sequencers are appropriately incentivized. You only need one good sequencer/prover, so this should be fine.

There’s a security council consisting of top N (N= 8? 11? Maybe N can be dynamic, according top X% stake voting) elected delegates. The security council has rights to pause the network if 76% vote.

If possible, there should be some exit schemes available while the network is paused.

All upgrades must go through regular governance process, with appropriate delays. (E.g. >7 days for optimistic rollups)

Emergency upgrades following a network pause can have much shorter delays, with appropriate quorum and approval thresholds.

Alternatively, in the early days, security council can upgrade with short timelocks determined by approval level. E.g. if 100% approve, 2 hours; 76% → 24 hours etc. Wider L2 governance & in catastrophic cases perhaps even L1 social layer has some time to veto these upgrades, in case the security council is compromised. Immediate upgrade rights to security council should be avoided in this stage IMO.