Branching Oracle-enshrined Rollup Governance

This is a great post. I wanna add some points why I think this is a very interesting idea allowing us to build very secure Oracle platforms.

  • Enhanced Security through Subjectivocracy: Traditional Oracle technologies are inherently susceptible to 51% of attacks. In the event that an entity controls more than half of the Oracle token, they can manipulate the outputs, thereby extracting capital. This limits the application scope of oracles, as the extractable capital should not exceed half of the oracle token’s market cap. The concept of subjectivocracy can alleviate this limitation, thereby providing a more secure oracle platform.
  • Economically Efficient Oracle Infrastructure: Subjectivocracy removes the need for oracles to maintain a high market capitalization as a safeguard against 51% attacks, thereby reducing their operational costs. This creates an opportunity for more economically efficient oracle infrastructures, especially for forkable assets.
  • Prompt Price Feed Resolution: Traditional oracle resolution mechanisms, like those utilized by UMA and Chainlink’s tier 2, may be considered too time-consuming for applications that demand quick liquidations, such as MKR (compare discussions from here ). In these cases, delayed resolutions can result in the insolvency of the protocols. L2 forks can address this issue: Following a brief escalation period(<hour), an L2 can be duplicated, allowing for the coexistence of both chains until a decision is reached. While both coin-staking and subjectivocracy are inherently slow processes, the latter allows for immediate activation via a fork.
  • Stable coin design: Stablecoin designs that depend not on their own oracle infrastructure, but rather depend on the rollup enshrined subjective oracle system could potentially be much more secure than traditional stablecoins. This itself is a significant advancement. We will soon append a small outline of such a stable coin in the thread.
  • Constitutional DAOs: DAOs have the risk that the token holders change over time and the initial promise of the DAO to customers is no longer kept since the new token holders implement new rules via governance. This can be countered by Constitutional DAOs. These DAOs would commit to a constitution at the founding process and then the L2’s enshrined allowlisted judges will approve each governance vote, if and only if they are according to the constitution. This design is especially important for DAOs that hold more capital than their governance token’s market cap is worth, as the governance could theoretically steal all the customer’s capital. One example is insurance DAOs, having capital reserves that are often bigger than the insurance DAO governance token’s market cap. Today, these DAOs are secured by multi-sig from founders, but we argue that the forkonomic layer with its subjectivocracially chosen judges provides a more decentralized, robust solution.
  • Significant forkable asset: It took us quite some time to realize that once a forkable ledger is built, the amount of forkable assets/ecosystem is quite significant. Of course, the gas/governance token of the forkable L2 is forkable, but also other tokens that are natively created in the forkable L2: DAOs can deploy on the L2 and thereby become forkable. Synthetics, like the stablecoin mentioned above and other utility tokens created on the chain, are other examples.
    While the forking process for these assets might require some design considerations, we believe that they are possible and practical in many cases. E.g. for a DAO the following three important non-forkable points need to be addressed:
    • Founder support, domains, and legal entities: Founders, the supporting legal entities, and foundations likely will only support one fork. While supporting both is possible, likely the entities will only focus on the fork that got the most subjective support. This means that the original domains and apps will only work on one fork. This will increase the network effects of the chosen fork. Nonetheless, other teams or sub-teams of the founder team can still support the application on the fork - though likely under a different brand. Hence, both forks can continue to exist.
    • Revenue streams from the non-forkable ecosystem: If a DAO has revenue streams from a non-forkable ecosystem, then it’s not immediately clear into which fork the revenue should go. But for all DAOs that use revenue streams for token-buybacks - as MakerDAO does - there is a nice practical solution: After a branching event, the DAO would just keep on burning the original token, the one that existed before the fork, or equivalently both fork tokens. This ensures that the revenue is going into the forks according to the price ratio of the tokens of the fork. Later on, after the team decided to only support one fork and deploys a new version of their contract - maybe due to advancement in the mechanism or an iteration of the product - they might decide to make the new fork’s DAO token to be the burnable token and thereby cut out the other fork from future revenue streams.
    • Non-forkable treasury assets: Some DAOs also wanna hold non-forkable assets like USDC, or tokenized treasury bills. For these kinds of assets, there is also a variety of solutions. Most likely DAOs would go for the following solution: In case of a fork, the DAO deploys a market on L1 that determines the price between the two forked DAO tokens. According to this market price, the non-forkable assets are split between the two DAOs forks. (Note that this setup does not allow someone to extract profitably DAO’s treasury assets, as long as the treasury value is smaller than the governance token assets )
      For all these points, there are reasonable solutions, and hence we believe that it is viable for DAOs to deploy on a forkable ledger and become forkable as well. Vitalik proposed that uniswap should become an oracle (see here). While uniswap declined at that time, the forkable L2 design enables any DAO to help the Oracle ecosystem by redeploying on the forkable L2 and use its market cap to secure the chain.
  • UX: Forking will have some drastic implications on UX. However, there only needs to be the possibility of forking, in order to make the systems secure. In practice, it will likely not happen frequently

Of course, these points have to outweigh the disadvantage that a forkable L2 is mostly designed to hold forkable assets and not hard assets like USDC. But once a stablecoin, some DAO deployments, insurance protocols, and synthetic protocols have been deployed to the forkable L2, a very interesting ecosystem could be created with better security properties than the existing one.

I am really curious how others are seeing the advantages of such a forkable L2.

1 Like