Governance Stage 0

[l-monninger]

Summary

As discussed internally, Stage 0 of Movement Governance is based on the following commandments:

1. Movement Labs Engineering SHALL manage all Movement Labs participation in the Movement Network with secrets its software delivery controls.
2. Movement Labs Engineering SHALL prevent direct access to these secrets to the maximum extent possible.
3. Movement Labs MAY provide controlled rollback methods for its participation.
4. Movement Labs Engineering SHALL facilitate network forks as a highly-usable feature, so as to allow for continuity and recoverability if governance designs fail.
5. Movement Labs Engineering SHALL define the procedures governing for emergency forks prior to mainnet.
6. Movement Labs Engineer SHALL commit to defining "Stage 1" (TBD) governance for discrete software units in https://github.com/movementlabsxyz/MIPs-legacy.

This discussion concerns how practically and technologically to adhere to these commandments. It is intended as parent discussion for more specific child discussions.

Participation

There are the followed forms direct participation in the Movement Network in which Movement Labs can engage.

• Staking on MCR and attesting with Movement Network validators.
• Sequencing blocks and sending signed blobs to the Celestia DA.
• Calling various role-restricted methods on MOVEToken, Movement Staking, Custodial Token, and MCR smart contracts, to perform actions such as updating settlement parameters, minting token, and approving various custodians.
• Generally, running a node with particular logic.

As the owner of the Movement repository, Movement Labs can also heavily influence the available versions of the network and associated proposals.

All of this is ultimately correlated with influence over the network, including on token balances therein.

Thus, ensuring this participation is not simply left in the hands of one engineer with one key is both a protection against internal breaches and also disincentive for would-be attempts at external breaches.

Strategies

In some form or another, all the software correlates of Movement Network participation can be governed by (a) restricting delivery to an authenticated set of secrets and (b) ensuring said secrets are not themselves directly accessible. The following are strategies concerning this premise.

Smart Contract Governance Logic: smart contract delivery can generally be easily restricted to a set of secrets. Common upgrade and proxy patterns can ensure basic governance rules are applied insofar as the underlying chain is not exploited.

Tamper-proof Compute for Pipelines and Runtime: nodes running upgrade logic can themselves be required to be tamper proof or submit attestations, i.e., sensitive upgrade logic can be run in an enclave. This approach can be used to cover non-smart contract upgrades. However, unless the upgraded software is also run in an enclave, this is necessarily incomplete.

Multiple Secrets: regardless of what is being upgraded, using multiple secrets will make it at least as difficult as one secret to exploit. Generally, it will make

Inaccessible Secrets: secrets can be generated in a TPM, enclave, or similar and never directly accessed.