[FINAL] Law of Chains v0.1

In the case of a conflict like this, we believe the general priority is preserving the semantics of the EVM execution. This conclusion is supported by the principle that it is the users’ expectations (e.g., of homogenous block space and valid state transitions) that the Law of Chain seeks to protect, not their interests (e.g., financial interests that arise independently of the expectation of User Protections, and which may contradict). These expectations apply equally to asset holders and application developers. For example, in the event where a network split, bug, or divergence causes contention between contract deployer and asset holder, we believe governance should make a decision based not on desires of those stakeholders but on the expected behavior of the EVM (e.g., the Ethereum yellowpaper) and any L2-related extensions to that specification.

The particular configuration parameters of each Chain Governor are not explicitly specified in the Law of Chains. As stated in the introduction, the Law of Chains is meant to be a long-standing document that applies over many versions of the protocol, and is as independent of future configurability options as possible.
More information about these specific configuration options should become clear as the Collective iterates through future releases, protocol upgrades, and governance docs. In recognition of the interpretive principles of long-term applicability, and modularity and evolution, we expect this can take the form of an auxiliary document rather than modifying the Law of Chains itself, similar to the difference between the Working Constitution and the Operating Manual.
Notably, the protocol code will ultimately define many of the configuration options available to chain governors, which means updates to that Law of Chains’
Operating Manual equivalent will evolve alongside protocol upgrade proposals.
In this context, the importance of the interpretive principle of governance minimization is also clear. Most if not all configuration choices should ultimately be structured as, and constrained by, protocol parameters that are self-enforcing, rather than reliant on procedural documentation and other offchain mechanisms. This could take time to fully and securely implement, but is a desirable end state all the same that should be iterated towards over time.

Yes – we believe this would require allocating resources to further the development of the Platform. So far, the Collective has supported this development by deploying grants (from the Governance Fund, Partner Fund, Seed Fund, and Unallocated buckets of the OP token treasury), among other ways. In the medium term, we expect RetroPGF to become the primary mechanism that drives and incentivizes the further development of the Platform.
Beyond resource allocation, it’s possible that some form of protocol upgrade in the future could be proposed to governance in response to an existential threat. But it’s difficult to talk in specifics about the actions that governance may need to take to respond to existential threats, as those are not known (by definition) and hard to predict.

We’ve illustrated one possible evolution of Optimism’s governance system in a post here. The document excludes many implementation details, and it’s up to the Collective to define good processes for iterating towards and operationalizing each responsibility listed within.

To start, updates to the Law of Chains may be proposed by the Foundation, subject to governance approval. Separately, any procedural changes that impact the security model of OP Chains and/or the Superchain will also be subject to governance approval.

Over time (as detailed here) these metagovernance powers must become the responsibility of the governance community; from initiation to approval and implementation.

As mentioned above, and in the spirit of governance minimization, programmatic enforcement of the Law of Chains is key. Ultimately protocol upgrades will define the specific application of many of the protections outlined in LoC. Therefore it’s possible that in the future the application of the Law of Chains is in effect interpreted by governance via the protocol upgrades it chooses to approve or reject.

If the Law of Chains is ratified by the Token House, the next step is detailing the specific processes to operationalize the first application of the LoC.
More specifically, this will involve a process for governance to maintain an “allowlist” of approved Sequencers that are committed to upholding the Law of Chains. Once the Sequencer is approved by governance, it will be up to that Sequencer to onboard Chain Governors that want to use their services. Note that this is an initial implementation of Superchain governance and the applications of Law of Chains, and we expect the exact governance processes that enforce the LoC to evolve over time to become increasingly permissionless.
The Operating Manual will be updated to include more detail on the new governance proposal types that will support these responsibilities.

:heart: Apart from the dedicated Superchain community call and Season 5 Foundation AMA, if additional sessions to discuss the Law of Chains are necessary, please let us know.