[FINAL] Law of Chains v0.1

[system]

For a section-by-section summary of the Law of Chains, see here.

Law of Chains (v0.1)

The Law of Chains is an open neutrality framework that establishes certain protections for participants in the Superchain ecosystem. Its purpose is to promote core principles of user protection, decentralization and economic autonomy as foundations for the developing Superchain.

Version note. The Law of Chains is a living document, and should evolve alongside protocol innovation across the Collective. Version 0.1 of the Law of Chains is immediately applicable to the current, single-sequencer release of the OP Stack, and establishes fundamental principles: core expectations of users and economic participants, homogenous blockspace, and universal upgrades on a shared standard. Anticipated improvements to the OP Stack that remain technologically unspecified (e.g., shared sequencing and zero-knowledge proofs) are correspondingly economically unspecified in this initial version. As the Law of Chains evolves, two critical freedoms should be preserved: (1) the freedom of Optimism Governance to introduce new protocol constructions with different technological and economic specifications, and (2) the freedom of ecosystem participants to choose, at the appropriate time, with full information, and without coercion, whether to opt into those constructions.

Finally, part of the Law of Chains is this Important Disclaimer. To fully understand this document, you must read the disclaimer. It clarifies that the Law of Chains is not a legal contract, provides no legally enforceable warranties, representations, indemnities, rights, or obligations, and does not commit participants to any form of legal partnership or joint venture with any others. The Law of Chains is intended to function solely as a guiding framework for participants in the Collective and Optimism Governance.

1. Covered Participants.

   1. The Law of Chains applies to:
      • Users: The end users of OP Chain smart contracts and applications, and the developers and deployers of such smart contracts and applications.
        • Any party that holds assets or transacts on an OP Chain or deploys a smart contract to an OP Chain is acting in their capacity as a User.
      • Chain Governors: The party or smart contract responsible for deploying an OP Chain or configuring an OP Chain following deployment.
        • A party or smart contract “configures” an OP Chain by setting the configuration values that are parameterized by, but not specifically hardcoded into, the Protocol Contracts or offchain protocol software.
        • For example, in the future a Chain Governor might configure its OP Chain to run a particular OP Stack sequencing scheme (among various potentially compatible sequencing schemes) on the chain.
      • Chain Servicers: Sequencers, Proposers, and Challengers for an OP Chain.
   2. The identity or scope of Covered Participants may change over time. For example:
      • A Chain Governor may transition from being a single party to a decentralized governance system (e.g., where OP Chain configuration decisions are made by a ‘DAO’). In that case, the decentralized governance system would become the Chain Governor.
      • With future development milestones, Sequencers, Proposers, and Challengers may become separate categories of Covered Participants with expectations under the Law of Chains that are different from one another.
      • New, currently unidentified roles may emerge within the ecosystem and be included as additional categories of Covered Participants (e.g., zk-Provers).
   3. A single party may be a Covered Participant in multiple capacities. For example, a Chain Governor may also be a Chain Servicer, and a Chain Servicer may be any combination of Sequencer, Proposer, and Challenger. In such cases, the party’s expectations under the Law of Chains are determined separately, as relevant to each respective role.
   4. The Law of Chains only applies to Covered Participants of OP Chains: i.e., those that have affirmatively opted-in, and followed any relevant governance process to be committed to and covered by the Law of Chains. It does not extend to chains running on the OP Stack which are not “OP Chains.”

2. The Platform. In addition to Covered Participants, the Law of Chains establishes expectations for the Platform itself. The Platform is not an individual OP Chain; it is the fundamental protocol on which all OP Chains run today, and in the future, which will evolve into the Superchain.

3. User Protections. Users are to be protected with assurances that are (a) highly similar to the assurances afforded to analogous users of Ethereum and (b) as uniform as possible for all Users across all OP Chains. This means ensuring, at minimum:

   • State Transition and Messaging Validity: OP Chain state transitions, and cross-chain messages sent to or from OP Chains, must only be finalized if they follow the rules defined by the most recent Optimism Governance-approved release of the OP Stack. For example, the User Protection to state transition and messaging validity would be violated by:
     • For Chain Servicers, a:
       • Sequencer that represents an L2 block (e.g., by serving an eth_getBlockByNumber RPC request) to a User where that block does not match the result of the op-geth, op-node, and L1 Ethereum node services.
       • Proposer that proposes an output which does not match the result of the batch-submitter service in coordination with aforementioned software.
       • Challenger that does not challenge the aforementioned proposal in a timely manner.
   • Security, Uptime, and Liveness: Block production, sequencing, and bridging must satisfy uniform standards for security, uptime, and liveness across all OP Chains. For example, the User Protection to security, uptime, and liveness would be violated by:
     • A Chain Servicer that:
       • Illegitimately censors, reorders, or limits transactions (e.g., by running off-chain sequencing code that is not approved by Optimism Governance, or by colluding with L1 validators to artificially inflate sequencer batch submission costs) in order to extract a profit or violate User Protections.
       • Frequently experiences unreasonable downtime, such that User access to the OP Chain is regularly degraded.
       • Does not promptly address emergency bug fixes or other security compromises.
     • A Chain Governor that configures the OP Chain in such a way that Users indirectly cannot transact (e.g., by setting a prohibitively high gas markup).
   • Universal, Governance-Approved Upgrades: OP Chains must upgrade together under OP Stack releases that are approved by Optimism Governance. Such upgrades must be backwards compatible with prior OP Stack releases such that User Protections are not compromised. For example, the User Protection to universal, governance-approved upgrades would be violated by:
     • A Chain Servicer that facilitates an upgrade of the OP Chain to an Ethereum bridge implementation that is not identical to the implementation shared by all other OP Chains.
     • A Chain Servicer that facilitates a change to the OP Chain’s L2 smart contract execution semantics in a way that breaks previously safe assumptions (e.g., by allowing a timelock contract to unlock ahead of schedule).

   For the avoidance of doubt, any unilateral attempts by a Chain Servicer or Chain Governor to migrate an OP Chain to an unapproved release of the OP Stack or to an entirely different technical stack – i.e., a “Unilateral Migration” attempt – would violate the User Protections described above:

   • Changing the rules of the existing OP Chain to the rules of the other stack violates the User Protection to state transition validity.
   • Migrating assets from the existing OP Chain bridge via a non-standard withdrawal violates the User Protection to messaging validity.
   • Migrating funds directly out of the existing OP Chain bridge via an upgrade violates the User Protection to universal, governance-approved upgrades.

   This does not mean that a Chain Governor or Chain Servicer should not take any action to move users to a new technical stack. It does mean that there must be a voluntary migration transaction taken on a per-User basis, similar to the historical migration between Uniswap versions on L1.

4. Chain Governor Protections. The configuration choices afforded to Chain Governors by releases of the OP Stack are to be preserved according to the following principles:

   • Economic Autonomy: Chain Governors may make their own free economic choices in the marketplace within existing OP Stack parameters established by the Platform, so long as those decisions are otherwise consistent with the Law of Chains. Moreover, Chain Governors should not be retroactively deprived of economic reward that resulted from decisions that were valid at the time they were made. For example, the Chain Governor Protection to economic autonomy would be violated by upgrades that:
     • Deny the ability of a Chain Governor to choose to run a single-sequencer OP Stack sequencing scheme (even where governance has approved a release of the OP Stack which supports an alternative sequencing scheme).
     • Deny the ability of a Chain Governor that runs a single-sequencer configuration to set a configurable profit margin for sequencing on its OP Chain.
     • Remove network fee revenue previously accrued to an L2 fee vault by a Chain Governor, or limit the ability of the Chain Governor to legitimately collect additional revenue or access those historical or legacy assets earned and presently owned by them.
     • Introduce mechanisms designed directly to prevent Chain Governors from encouraging a voluntary per-User migration to a different chain (since the possibility of voluntary exit is critical for Users as well as Chain Governors, the ability of a Chain Governor to legitimately exit the system should be respected regardless of Chain Governor conduct).
   • Technical Configurability: Chain Governors may make basic technical configurations permitted to them by the OP Stack. This should include the ability for the Chain Governor to change the Sequencer on its OP Chain between those which have been approved by Optimism Governance, and to appoint a new Chain Governor to take its place in the event it elects to make such a transition.

5. Chain Servicer Protections. The participatory expectations of Chain Servicers are to be preserved according to the following principles. Like Chain Governor Protections, Chain Servicer Protections are focused on the Chain Servicer’s expectations of economic autonomy and technical configurability within, initially, the framework of an OP Stack single-sequencer sequencing scheme:

   • Economic Autonomy: Chain Servicers may make their own free economic choices in the marketplace within existing OP Stack parameters established by the Platform, so long as those decisions are otherwise consistent with the Law of Chains. Moreover, Chain Servicers should not be retroactively deprived of economic reward that resulted from decisions that were valid at the time they were made. For example:
     • If a Chain Governor makes changes to parameters, or Optimism Governance approves an upgrade, which impacts the margin that a Chain Servicer (e.g., in its capacity as Sequencer) may earn going forward, the Chain Servicer may cease operations if economically nonviable under the new margin.
     • If a Chain Servicer has previously accumulated assets to an L2 fee vault contract, it may access those assets and any upgrade removing such assets or access would be a violation.
   • Technical Configurability: Chain Servicers may make basic technical configurations permitted to them by the OP Stack. This includes changing the hotkey used for batch submission in a Sequencer capacity, or the hotkey used for proposing in a Proposer capacity.

6. Platform as Commons. The Platform is the fundamental public good on which all ecosystem participants, as a Collective, rely. It establishes the underlying economics applicable to all OP Chains, backstops the security assumptions of all OP Chains, and exists for the benefit of all OP Chains. On behalf of the entire Collective, therefore, it is essential that its basic Platform Requirements be preserved:

   • Sustainability: The Platform must be able to economically sustain itself and the public goods that support it.
   • Security: The Platform must be able to prevent or respond to Security or Stability Incidents that would impact it.
   • Survival: The Platform must be able to evolve in response to threats that pose a real, existential risk to the Platform as whole.

   The Collective should thoroughly consider any claim that a protocol upgrade or modification is necessary or appropriate to preserve a Platform Requirement:

   • Violations of Participant Protections are to be avoided wherever practicable to do so, and minimized, reasonable, and proportionate to the need posed by the Platform Requirement wherever it is not.
     • For example, Platform downtime imposed in connection with protocol upgrades is acceptable (even though it marginally violates a series of Participant Protections for a limited period of time), but wherever practicable, that downtime should be limited, communicated well in advance, and Covered Participants should be provided with substantial time to prepare in a way that minimizes adverse impact.
   • A proposed response to one Platform Requirement should always beg the question of what other Platform Requirements could be collaterally undercut in the process.
     • For example, a proposed upgrade may be allegedly justified in the name of the Platform Requirement of survival, while violating the Chain Governor Protection to economic autonomy. But of course, very few projects may launch an OP Chain if the Platform is not a fair, predictable commons on which to build. And less OP Chains on the Platform could undercut the Platform Requirement of sustainability. In that case, the threat to the Platform Requirement of survival should predominate the threat to the Platform Requirement of sustainability in order to justify such a change.

7. Users First. Subject to any Platform Requirements, User Protections must not be violated, including by the exercise or enforcement of any other Participant Protections. In the event there is a conflict between different Participant Protections, (a) User Protections will supersede all other Participant Protections and (b) conflicts among other Participant Protections will be resolved in the following order of priority: first, as required by the Platform; second, as necessary or appropriate to ensure the protection of User Protections; and third, in a manner otherwise consistent with the interpretive principles of Section 9 below.

8. Enforcement. The Law of Chains is intended to be enforced solely through resolutions of Optimism Governance. Participant Protections are not, should not be relied on as, and do not create legally binding or enforceable rights or obligations independent of any actual, separate legal agreement between independent contracting parties (which the Law of Chains is not).

   This means that standing alone, the Law of Chains is fundamentally social in nature: it establishes social expectations for (a) how Covered Participants should conduct themselves, (b) how Optimism Governance can step in to remedy a violation, and (c) how to evaluate future upgrades. For example:

   • If a Sequencer impermissibly censors users, or intentionally represents a faulty state to users, Optimism Governance can intervene by executing an upgrade to replace the Sequencer on all OP Chains it serviced.
   • If an invalid proposal is submitted and a Challenger fails to use a Challenger Key to delete the proposal, Optimism Governance can intervene by executing an upgrade to replace the Challenger.
   • If an upgrade to the OP Stack is proposed, which is insufficiently backwards compatible, Optimism Governance can validly reject the proposal on those grounds.

   As Optimism Governance evolves, further accountability and enforcement mechanisms may evolve alongside it.

   Finally, for the avoidance of doubt, no Covered Participant is required under the Law of Chains to take actions that it reasonably believes are contrary to applicable law.

9. Interpretation.

   1. In interpreting the scope, authority, and meaning of the Law of Chains, the guiding principles contained in the Working Constitution will apply as follows:
      • Governance minimization. The OP Stack and OP Chains should be designed, operated, and governed in a manner that progressively and programmatically (a) removes the ability of ecosystem participants to violate the Law of Chains and therefore (b) removes the need for Optimism Governance to proactively enforce it. For example, future releases of the OP Stack should enable:
        • Chain Governors to exercise Chain Governor Protections via (and solely to the extent permitted by) configurable parameters that are encoded and enforced at the Protocol Contract level.
        • Anyone to act as a Proposer permissionlessly, removing the ability of any single Proposer to censor User withdrawals.
        • Anyone to act as a Challenger permissionlessly, removing the need for the Law of Chains to require affirmative conduct by any single Challenger.
        • Fault proof implementations that remove Chain Servicers’ ability to violate the User Protection to state transition validity.
      • Forking. The ability to fork and exit the system remains a critical mechanism to protect individual freedoms. However, the prohibition against Unilateral Migrations clarifies that exit by individual Chain Servicers or Chain Governors should not undermine the individual freedom of Users, who should have the option to migrate, rather than being forced into it.
      • Anti-plutocracy. Like Optimism Governance as a whole, enforcement of the Law of Chains cannot ultimately be the domain of OP token holders alone; the influence of the Token House must be balanced with Citizenship.
      • Impact = Profit. The Superchain ecosystem will, like all digital commons, be impacted by marketplace dynamics. In cases where these dynamics give rise to conflicts for Optimism Governance to resolve, the resolution should strive to preserve Platform Requirements and protect Participant Protections, while interpreting the Law of Chains in a manner that rewards all ecosystem participants commensurate with their Collective contributions.
   2. It is further understood that the Law of Chains will require adaptation to changing circumstances as the Collective defines itself, evolves, and grows iteratively over time. Accordingly, the Law of Chains adopts additional interpretive principles:

      • Long-term applicability. As the Law of Chains is applied to events such as the Superchain Migration, which will involve significant and unforeseen changes to protocol specifications and code, it should be interpreted and updated in a way that favors flexibility, adaptability, and consistency with the principles underlying the Law of Chains, as opposed to rigid adherence to its text. For example:

        • Optimism Governance may approve future releases of the OP Stack that cause some of the specific references and examples included in this document to no longer apply. This should not undermine ecosystem participants’ adherence to the Law of Chains’ underlying principles, or inhibit the legitimacy of efforts by Optimism Governance to enforce it.

      • Modularity and evolution. The modular design of the OP Stack opens the door for alternate L2 constructions in the future, which may make known tradeoffs (e.g., between decentralization and performance, or between composability and economic autonomy) that establish fundamentally different User expectations. For example:

        • A future L2 construction might move data availability off of L1 to reduce fees, but decrease fundamental censorship resistances properties.
        • A future L2 construction might include a decentralized sequencing network which facilitates cross-OP Chain composability, but decreases the ability of individual OP Chains to have independently configured economic systems.

        The mere fact that such a protocol is less censorship resistant or more uniform in its economic model than a current OP Chain does not mean that Optimism Governance should reject its inclusion in a release of the OP Stack for failure to uphold particular Participant Protections. Instead, Optimism Governance should consider whether, or how, to expand the Law of Chains to facilitate the Superchain’s ongoing evolution.

      • Reputational awareness. Optimism Governance must understand that the decisions it makes are never in a vacuum, and the manner in which it applies the Law of Chains will establish its reputation for existing – but also future – ecosystem participants. For example (and as noted above), undermining the settled expectations of Chain Governors will not just impact current participation, it will also pose significant long-term risk of driving away future Chain Governors, and corresponding fee revenue. “The most important scarce resource is legitimacy.”

10. Always. Stay Optimistic .

---

DEFINITIONS

“Challengers” = the Ethereum address authorized to delete output proposals for an OP Chain.

“Collective” = the Optimism Collective, including participants in the Superchain ecosystem.

“Covered Participants” = Users, Chain Governors, and Chain Servicers.

“OP Chain” = a production L2 blockchain running on the OP Stack and which has affirmatively opted-in and followed any relevant governance process to be committed to and covered by the Law of Chains.

“OP Stack” = an Optimism Governance-approved, standardized, shared, and open-source development stack release that powers the Optimism L2 blockchain protocol; together with all future such releases.

“Optimism Governance” = the governance system for the OP Stack, OP Mainnet, and the Superchain, which is currently the bicameral system of the Token House and the Citizens’ House; and future iterations thereof.

“Participant Protections” = User Protections, Chain Governor Protections, and Chain Servicer Protections, collectively.

“Proposers” = the L1 Ethereum wallet or smart contract authorized to append output root hashes for an OP Chain, which form the basis for withdrawals and other L2-to-L1 messages.

“Protocol Contracts” = the OP Stack smart contacts that comprise the onchain code that powers an OP Chain.

“Security or Stability Incident” = bugs or defects, unplanned maintenance, or stability, integrity, availability, non-repudiation or other security issues with the OP Stack, Protocol Contracts, or any OP Chain.

“Sequencers” = the node(s) providing block production services which produces transaction confirmations and state updates, constructs and executes L2 blocks, and submits L2 block data transactions to layer 1.

“Superchain” = a proposed network of L2 rollups that share bridging, security, data availability, and communication layers; which uses the OP Stack as a common development stack, and Optimism Governance as the common governance system.

[gigamesh]

This is really great to see! Tiny note/question:

@system

The Platform is not an individual OP Chain; it is the fundamental protocol on which all OP Chains run today, and in the future, which will evolve into the Superchain.

Given “platform” is typically used to refer to centralized frontends, I’m curious why that is the term being used. Maybe Superchain Protocol would be more clear?

[hyprboom]

Not a question, more of a comment.

I love the spirit in which this document was created - focused on users and on optimism. It is also incredibly thorough. As I was reading it, I did have a question on the difference between end users vs developers - but it was covered and defined in the document (though I kind of had to dig for it).

In any case, really great start and looking forward to everybody’s feedback.

[bakgwei]

Very very thorough, and for me - as a non-techie - sometimes hard to digest in it fullest meaning. Though the glossary at at the end also helped, thanks for that.

[kemzy]

I support this.
well captured, and understandable even for a non-techie

[sam.ng]

Hello,

As someone who spend too much time on Twitter (or should i say X lul sounds bad), often end up fully immersed in the various discussions that take place on the platform (it is what it is). Recently noticed some ambiguity and misunderstanding concerning some points raised in a Twitter post that Optimism did yesterday. From my perspective, there seemed to be a certain degree of miscommunication that needs to be addressed, and I do so with the utmost respect for all parties involved.

A series of differing posts caught my attention, primarily asserting that any chains constructed on Optimism will have no alternative but to adhere to the sequencers chosen by the Optimism collective. Such a scenario, as depicted by these posts, hints towards a possible deficiency in modularity and sovereignty, thereby potentially complicating the process of accruing value for builders within the Optimism ecosystem.

Nevertheless, it’s essential to highlight that this interpretation appears to stem from a misunderstanding of the original Twitter post. The matter is clarified more comprehensively in this forum post, as can be inferred from the following quote:

@system

Modularity and evolution. The modular design of the OP Stack opens the door for alternate L2 constructions in the future, which may make known tradeoffs (e.g., between decentralization and performance, or between composability and economic autonomy) that establish fundamentally different User expectations. For example:

• A future L2 construction might move data availability off of L1 to reduce fees, but decrease fundamental censorship resistances properties.
• A future L2 construction might include a decentralized sequencing network which facilitates cross-OP Chain composability, but decreases the ability of individual OP Chains to have independently configured economic systems.

To further decode this misinterpretation by the community regarding the announcement made on Twitter, I’d like to elaborate on a few things:

First and foremost, the OP Stack codebase grants you complete autonomy to utilize it as you see fit. However, it’s widely understood that for the Superchain network to function cohesively, making it feel like “many chains that behave as one chain,” the individual chains within this network (termed as “OP Chains”) must adhere to a relatively standardized security model. This requisite stands apart from what you are capable of achieving with the OP Stack codebase.

The post, in essence, highlights that any significant alterations to the OP Stack codebase could potentially result in your chain being incompatible with the Superchain network-of-chains. The phrase “OP Chain” is a specific reference to the chains operating within the Superchain network, clearly distinguishable from a “chain constructed on the OP Stack.”

In summary, despite the liberty to modify the OP Stack codebase as per your requirements, certain alterations could compromise your chain’s compatibility with the Superchain network. This network relies on a fairly consistent security model to ensure its proper functioning. Hence, the need to make a clear distinction between OP Chains and chains built on the OP Stack is quite apparent.

In my perspective, it’s crucial to tread towards maintaining modularity and ensuring sovereignty for builders, taking into consideration what they aim to construct. For instance, facilitating composability between different app-chains for building financial applications makes sense, given the existing interaction between dapps on Ethereum today (e.g., Uniswap with Aave). This proves beneficial for builders in that specific space. Also, giving the flexibility to builders to manage their sequencer set might lead to new mechanism we are not used to today. Yes, like seeing a dapp token useful, it could be used for staking to propose blocks and even to pay for txs fees. Would definitely be game changer but would introduce some research to maintain interoperability in some cases. That being said, the financial domain certainly won’t be the sole utilization of crypto, at least I hope so.

In the context of a game, it’s more sensible to have your own sequencer, as the need for composability diminishes significantly when you are engaging in a game. The value should primarily be accruing to the sequencer(s) elected by the company. The choice of sequencer is not the only option that OP builders should (will?) have. This is where data availability comes into the picture.

Consider this scenario: publishing data representing hundreds of millions (wen trillions ser ?) of DeFi interactions should be accomplished on a data availability layer that is economically secure and decentralized. On the contrary, social or gaming chains do not require the same level of security but demand more throughput than what the Ethereum data availability layer can currently provide. Consequently, it would make sense to investigate various data availability solutions (e.g., Celestia, which recently announced close collaboration with the OP Stack).

By the way I am not sure if a comprehensive dashboard exists that displays a) OP Chains, which are a part of the Superchain vision (e.g Base ?), illustrating a single logical chain for end-users, and b) chains solely based on the OP Stack (e.g Mantle ?). I am eager to interact with the community to explore potential solutions that simplify the understanding for everyone, myself included, given my humble knowledge levels.

Hope that makes sense!

[cpoetter]

the document is a good start to understand the scope of OP Chains and the difference to OP Stack only chains. I also like that the document is intentionally a v.01, leaving much room for improvements and iterations.

[sam.ng]

Absolutely, however, what I had in mind was a type of interface or dashboard that would display OP chains on one side, while concurrently presenting chains constructed from the OP stack on the other (if it doesnt exist yet).

well, found this so editing this post with it meanwhile :

[ksett]

Love to see the proposal and a framework for interactions being created. It is a little unclear to me what the threshold for violation is and who determines what is “reasonable” or required deviations from the standards set forth.

“Violations of Participant Protections are to be avoided wherever practicable to do so, and minimized, reasonable, and proportionate to the need posed by the Platform Requirement wherever it is not.”

I believe 8. enforcement needs clarification as well. specifically from " it establishes social expectations for (a) how Covered Participants should conduct themselves, (b) how Optimism Governance can step in to remedy a violation, and (c) how to evaluate future upgrades.", b is not established anywhere in this proposal from what I can see.

[Sinkas]

I think the following quote from Law of Chains v0.1: Section-by-Section Overview answers the question to an extent. If the Law of Chains is intended to be enforced solely through resolutions of Optimism Governance, then it’s probably up to the “challenger” to make their point on why they believe something is past the threshold of reasonable, as supported by the Law of Chains and the Optimism Constitution.

@system

Sec. 8 – Enforcement: The Law of Chains is intended to be enforced solely through resolutions of Optimism Governance. Governance may use protocol upgrades, or other governance processes, to remedy violations and promote compliance. For example, Sequencers that violate User Protections may be removed.

[nickbtts]

Hello!

I’m worried the implications of mandate expansion could have deleterious effects on OP Mainnet.

As we know, OP chains cede some tech sovereignty to the Optimism governance houses in order to ensure Superchain inclusion. This, of course, means that the teams or DAOs operating these chains will require a presence in governance, ensuring their voice is heard when impactful changes are being made to standards and/or inclusions. It is easy to view general execution environments, such as OP Mainnet, as complementary within the Superchain, assuming shared sequencing and messaging are robustly built, but the reality is somewhat different: only a relatively small percentage of sequencer fees from OP Chains is returned to governance. Op Mainnet, on the other hand, returns all of the sequencer revenue. With a finite number of users, capital and builders, generalised rollups across the board are in competition for that delta in value, despite OP Chains working under the same umbrella.

With this in mind, the Law Of Chains raises a few questions. Firstly, if post-vote the ‘platform’ is the Superchain, where does that leave OP Mainnet in terms of governance representation? Who exactly is representing the home of many projects and builders, as OPlabs do not participate in governance? Secondly, if the OP Stack and Superchain are the core OPLabs products, is the core Optimism team’s priority the onboarding new OP Chains, or new protocols to OP Mainnet? Other teams will be aggressively doing the latter to competing generalised rollups, and as previously mentioned, even if protocols are kept within the Superchain, it is disadvantageous to the Collective for a protocol to deploy to other environments other than OP Mainnet.

For a project with high transaction volume, remaining on OP Mainnet would also be deleterious; your environment has no champion, and you have no share of the revenue generated. If you have the tech headroom, operating your own OP Chain within the Superchain is the logical move, or indeed deploying to a competing environment which offers some kind of CSR or grants, and has a powerful voice within governance, one you can be part of.

Growth experiments and builder grants are currently one of the main ‘carrots’ to build on Optimism Mainnet. However, it does not take a leap of imagination to see a future whereby said grants become applicable across the ecosystem, especially with the aforementioned growing governance voices of competing OP Chains.

What can be done about this? There’s no ideal solution, but separating OP Mainnet and the Superchain as products, with dedicated teams for each, could be a longer term goal. The Law Of Chains could provide guarantees that growth experiment and builder grants would be awarded to projects primarily deploying on OP Mainnet. A dedicated vision, and roadmap for said vision, for the future of OP Mainnet would make it a more attractive place to build long term.

All in all, the Law of Chains is an important and well thought out charter for the Superchain, and a way to ensure some value is captured and recycled throughout the Optimism ecosystem. However, without any clear vision, dedicated team or enshrinement of rights for Optimism Mainnet, we may well see it simply fade away as a place to build, deploy and transact (and maybe this is part of the long term strategy, but if so I believe now is the time for that to be communicated). Superchain isn’t close yet from a technical POV, so OP Mainnet needs to have a visible future in order to attract foundational platforms that generate network effect.

All views are my own.

[hirokennelly]

gm gm! Thank you for putting forth Law of Chains v0.1 to the Collective.

---

FYI, I’m submitting this response on behalf of DAOstewards.

---

For some context: DAOstewards is a BanklessDAO-affiliated meta-governance group carrying Bankless values into the greater web3 ecosystem. Bankless is a movement stewarded by BanklessDAO, whose mission is to help people learn about and use decentralized, permissionless, and censorship-resistant technology to achieve financial self-sovereignty, security, and prosperity.

It’s on behalf of the BanklessDAO community that DAOstewards provides this feedback. Integrity is a guiding principle of the Bankless Nation, which means we operate transparently and build trust through radically public discourse. To this end we want to advocate for greater clarity about the Law of Chains so that we can have a fruitful public discourse.

We’d like to present a few considerations for future drafts:

1. One core member of DAOstewards’ Optimism workstream is a former attorney who knows the effort and care taken in crafting this initial framework. However, while the dense legalese may be comprehensible to a trained attorney, it’s very difficult for most people to really understand what is being proposed.

2. Core principles are shared and this is evident from introduction but the language following this is challenging for the non-technical user. While extremely thorough and clearly well considered, the text is dense and relies on the user’s prior knowledge of blockchain architecture, which reduces the impact of the principled language throughout.

3. Bankless Publishing asked a practicing crypto lawyer @lawpanda to review the Forum post and provide his comments, which you can find here. As he highlights, the Law of Chains is a social contract and not a binding legal document, and one of the challenges / opportunities will be to create non-legally-binding ‘teeth’ to enforce the social norms captured within the document. As a social contract that defines the minimum standards for Superchain participants, the boundaries of this contract must be clearly understood by ecosystem participants regardless of their level of legal and technical expertise.

4. Combine the dense language with the very human fear of seeming ill-informed, and this hard-to-parse proposal gets very little Forum action, as evidenced by the silence in what should be an active hall, in some way analogous to what we see in the Working Constitutional Forum post.

5. Finally, an Executive Summary at the top of this Forum post and other official communique from the Collective or the Foundation summarizing the proposal in clear, simple language would be an immeasurable benefit.

Many members of BanklessDAO have been working to share the Optimistic Vision through our decentralized media nodes so it would be very helpful if documentation as important as this could be produced in plain English. This would greatly assist our team of international translators and would also be more welcoming for people new to the space no matter what their first language. And we’re certain this effort would not be helpful to the Bankless Nation alone. As we build radically new financial systems, let’s also use language to describe what we are attempting to build in ways that enable the many diverse members of the Collective to give their energy and input into these important discussions to help us all flourish.

Respectfully,

-DAOstewards

[kaereste]

The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.

We’ve put a lot of thought into the Law of Chains and there are some things we’d like to point out that might be worth addressing.

1. Paragraph 1 states that the Law of Chains applies to Users, Chain Governors and Chain Servicers. We think it might be worthwhile to distinguish two other groups that have a tremendous impact on the network and its’ dynamics - Superchain Builders and the OP Token Holders.

   Both groups have an existential interest in the Superchain future and might have interests/pain points that are not necessarily in line with the groups already mentioned. Not taking their perspective into account, and especially merging them all within one broad ‘Users’ group might result with misunderstandings. One such misunderstanding would be in the case of a conflict between asset holders and smart contract deployers.

   As stated in §7.a: In the event there is a conflict between different Participant Protections, User Protections will supersede all other Participant Protections.
   Users are defined us Any party that holds assets or transacts on an OP Chain or deploys a smart contract to an OP Chain is acting in their capacity as a User.

   So in a conflict between asset holders and smart contract deployers, who has the priority?

2. It might be useful to elaborate a bit on what “The Platform” is. Since the Law of Chains defines how we collectively manage the “Platform” it is crucial that everyone has a shared understanding, at least on a higher level, of what The Platform is.

An important distinction to be made is between what constitutes the common infrastructure managed and governed by the collective and what are the parameters that each Superchain member-chain governs independently on its own.

If this has not yet been decided and is deliberately not specified in the Law of Chains, it would be worth stating this directly and mentioning the process that will lead to its clarification.

3. In §6, we read: Survival: The Platform must be able to evolve in response to threats that pose a real, existential risk to the Platform as whole.

We’re curious to know how is the Platform going to address this issue?

In our opinion addressing this would require allocating some form resources since in order to evolve, the Platform needs a team or even multiple teams working on it and The Collective needs to be able to define the direction in which it wants the Platform to evolve (i.e. define the development road-map and ensure its execution).

The other requirements mentioned in the ‘Platform as Commons’ section, sustainability and security, are already being addressed by the OP chains sharing the revenue, and by the Security Council. However, we don’t really understand how survival is going to be addressed in the future.

4. In the current context of the Law of Chains, we are not sure about the exact meaning of Governance minimisation. While we agree with the overall approach of turning rules enforced only on the social layer into code-enforced mechanisms, we also think that it needs to be further specified.
   What governance mechanisms, structures or processes do we envision in the future and how do we see the role of each of the governance participants within those are just some of the questions that immediately come to mind.

5. There is also the question of how is the Law of Chains going to be maintained in the future?

It is stated that the Law of Chains will require adaptation to changing circumstances as the Collective defines itself, evolves, and grows iteratively over time, but there is no mention of a process for these iterations to take place.

The first version of Law of Chains has been drafted by the Foundation and will be ratified by the Collective, but how is it going to be worked it in the future? If we want the Optimism ecosystem to be sufficiently decentralised, then we shouldn’t just be voting on the changes but rather we should collectively be discussing the required adaptations. How will we ensure that all relevant stakeholders will participate and have a say in the discussion?

6. Lastly, the Law of Chains provides a structure for the rules of participation in the Superchain, but it does not currently define any process or rules regarding how will we onboard/offboard participants to the Superchain.

Right now this seems to be handled by the Foundation, as we saw with the Base announcement, but what would that process look like in the future? In the “Future Of Optimism Governance” blog post, it is mentioned that This meta-governance power marks the end of the Foundation’s stewardship of the evolution of Collective governance and entrusts the governance community with continued experimentation towards a healthy end-state for Optimism.

It is our understanding that the Foundation’s role as a steward of The Collective will come to an end at some point in the future. When that happens, who will be responsible for onboarding and offboarding participants to the Superchain?

In our opinion The Law of Chains is a good step towards a better future of decentralized management of Superchain, but now it needs a lot of discussion about its clarification. We are definitely willing to take part in those discussions and to help brainstorm ideas around it.

If anybody wants to discuss the Law of Chains or any other issues regarding Optimism Governance, we would like to invite you to our Optimism Office Hours taking place every Tuesday, 3pm UTC at https://meet.google.com/pem-jzrh-gkq.

[Sator]

Question: Under Superchain, who and/or what has the authority to interpret the Law of Chains in case of divergence/conflicts? Would it be the existing governing entities (token house, citizen house, the foundation) or a new impartial entity specifically designated to interpret the law similar to a “judicial branch”? And if we indeed need a new justice body, what would be its member’s election process?

@system

Interpretation.

1. In interpreting the scope, authority, and meaning of the Law of Chains, the guiding principles contained in the Working Constitution will apply as follows:

[blairforce.eth]

This has me so optimistic on where we’re headed. In addition to this insightful post, the recent Bankless episode regarding the Superchain really helped answer the questions I had on how it’s intended to work and the vision moving forward. Definitely recommend it to everyone out there.

[Antoine]

Introduction

If the Law is not a legal contract, it’s hard to call it a Law. It’s a charta or an agreement or a declaration. On top a Law is normally binding and there is a way to enforce it. Here I think the enforcement part is hard to imagine.

Living document: There is a very nice approach in 14 States of the USA: The mandatory vote on a constitutional convention (Mandatory vote about whether a statewide constitutional convention shall be held - Ballotpedia). This could be a way to make sure that the doc is living even down the road as “no constitution is forever”.

In the following a couple of remarks different § and an advocacy for introducing sorition based tools to the Law of chains.

On §7: I think this is were we need an instantiation of the users. A way for them to voice their articulated concerns. For this I think there should be a sortition based “User chamber” when there is a tough choice to be made.

On §8: Here too, a very strong way of enforcment and judgement by peers would be a sortition based jury system. It would be a peer review, accountable, representative, non vested mechanism.

On 9 and the non plutocratic principle. One major reason why City states in the Italian Renaissance used sortition was to extend the scope of participants to governance and counteract plutocracry. I think here it would be particularly relevant.

I would love to engage further and jump on a twitter space or call or whatever to pursue that discussion.

Good job and thanks for all what you are doing.

On a broader note: This kind of document and exploration is the seed for future proof governance system. I think that they will grow and mature and be the basis of many many collectives in the future. I have a doubt that we can really minimize Human gouvernance. But I am convinced that we can do it with tools from the 21st Century (deliberative governance) and not rely only on tools from the 19th or 20th Century (Voting, elections, polls).

[shaneMkt]

The “Law of Chains” framework covers many important governance aspects and would bring greater clarity and cohesiveness to the future plans of the Superchain ecosystem. It’s great that the Optimism community is engaged early on this! The “Definitions” section was also helpful in understanding the technical terms that will be commonly associated with the Superchain ecosystem.

One topic that might be brought up by the Optimism community in the future would be how the expected growth of the Superchain would align with the Optimistic Vision, and specifically, how this would impact Optimism mainnet and OP token holders, while protecting their interests. Perhaps in the next version, the Law of Chains framework can start addressing this topic in some capacity.

[Base]

We contributed to writing the first draft of the Law of Chains, and are committed to use the Law of Chains as a guide for improved decentralization, neutrality, and contribution to public goods. These initiatives will not only strengthen Base, but the foundation on which the Superchain and the global, open, onchain economy can be built. We will continue to support and shape this framework as it is reviewed and adopted by the Optimism Collective Governance.

Though we would like to show our support in the upcoming vote, we do not currently have the technical ability to vote (working on making it happen!) and are still listening to community feedback and refining our overall strategy around our governance involvement (give us feedback here). We will share more updates with the Community as we progress.

[ben-chain]

@kaereste

Paragraph 1 states that the Law of Chains applies to Users, Chain Governors and Chain Servicers. We think it might be worthwhile to distinguish two other groups that have a tremendous impact on the network and its’ dynamics - Superchain Builders and the OP Token Holders.
[…]
So in a conflict between asset holders and smart contract deployers, who has the priority?

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.

@kaereste

It might be useful to elaborate a bit on what “The Platform” is. Since the Law of Chains defines how we collectively manage the “Platform” it is crucial that everyone has a shared understanding, at least on a higher level, of what The Platform is. An important distinction to be made is between what constitutes the common infrastructure managed and governed by the collective and what are the parameters that each Superchain member-chain governs independently on its own. If this has not yet been decided and is deliberately not specified in the Law of Chains, it would be worth stating this directly and mentioning the process that will lead to its clarification.

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.

@kaereste

In §6, we read: Survival: The Platform must be able to evolve in response to threats that pose a real, existential risk to the Platform as whole.

We’re curious to know how is the Platform going to address this issue?

In our opinion addressing this would require allocating some form of resources since in order to evolve, the Platform needs a team or even multiple teams working on it and The Collective needs to be able to define the direction in which it wants the Platform to evolve (i.e. define the development road-map and ensure its execution).

The other requirements mentioned in the ‘Platform as Commons’ section, sustainability and security, are already being addressed by the OP chains sharing the revenue, and by the Security Council. However, we don’t really understand how survival is going to be addressed in the future.

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.

@kaereste

In the current context of the Law of Chains, we are not sure about the exact meaning of Governance minimisation. While we agree with the overall approach of turning rules enforced only on the social layer into code-enforced mechanisms, we also think that it needs to be further specified.
What governance mechanisms, structures or processes do we envision in the future and how do we see the role of each of the governance participants within those are just some of the questions that immediately come to mind.

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.

@kaereste

There is also the question of how is the Law of Chains going to be maintained in the future?

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.

@kaereste

It is our understanding that the Foundation’s role as a steward of The Collective will come to an end at some point in the future. When that happens, who will be responsible for onboarding and offboarding participants to the Superchain?

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.

@kaereste

In our opinion The Law of Chains is a good step towards a better future of decentralized management of Superchain, but now it needs a lot of discussion about its clarification. We are definitely willing to take part in those discussions and to help brainstorm ideas around it.

If anybody wants to discuss the Law of Chains or any other issues regarding Optimism Governance, we would like to invite you to our Optimism Office Hours taking place every Tuesday, 3pm UTC at https://meet.google.com/pem-jzrh-gkq

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.

[ben-chain]

Each covered participant is responsible for making their own reasonable decisions, but ultimately governance is responsible for deciding whether they agree with those decisions.
Again in the spirit of governance minimization, we believe the Collective should seek to optimize the objectivity of protections and the ability to determine their violations so that it’s transparent and clear to any parties whether or not certain actions are in violation.
Finally, in enforcing the Law of Chains, governance should be keenly aware of the interpretive principle of reputational awareness. Its decisions will create precedent and shape expectations for all Collective participants, now and in the future. Its legitimacy should be carefully safeguarded.