Madara Committee
--

#### What's the goal of this commitee ?

The Madara committee is responsible for the growth and development of the Madara stack. It should thoroughly monitor the work of every actor involved. It should also be responsible for events, hackathons, communication around Madara.
The committee is also in charge of setting up the best legal structure in order to recieve funding from the different actors of the ecosystem, and mitigate the risks of the contributors and companies building on top.

#### What's the value accrual model towards Madara ?

Madara is fully open-source, and the goal of the committee is not to make profits. The committee still should be able to get funds to fund development, and the most obvious way to do it is to hold the legal risk for the different companies using Madara, by running their sequencer(s) (cf: the Optimism foundation w/ the OP Stack). Other paths can be followed, with Gitcoin or grants from ecosystem, but it might be in a less scalable way.

If Madara launches a shared sequencing layer, similar to the [superchain](https://app.optimism.io/superchain), it's possible that we might have a token for economic security and fees. The token could also be used for governance in committee decisions.

#### How is Madara's IP structured ?

Madara's IP should belong to the Starknet Foundation. It's still uncertain how to deal with substrate forking or libraries maintained by Starkware.

#### What are the current actors involved in its development ?

- Pragma
- Web3MQ
- Kasar Labs
- Karnot
- Starkware Exploration Team
- Avail
- Radius
- Kakarot
- Herodotus

Future Actors
- Moonbeam
- Dusa Labs
- Nethermind
- Equilibrium
- Succint
- Espresso Systems

#### What are their missions ?

- Pragma
- First Madara app chain to go in production, with the goal of making cross-chain, high-frequency, programmable oracles a reality. It leverages Madara's flexibility as much as possible for its use case (custom hashing functions, storage layout, slashing at protocol level, autonomous contracts..)
- Web3MQ
- Implementing HotStuff in Madara
- Kasar Labs
- Leveraging Madara to build a Starknet full-node with [Deoxys](https://github.com/KasarLabs/deoxys/tree/deoxys/prod).
- [Barknet](https://github.com/KasarLabs/barknet), Sovereign rollup on Bitcoin
- Implement [Cairo Native](https://github.com/lambdaclass/cairo_native) in Madara, very important milestone for performance improvements.
- Karnot
- A RaaS which manages production grade infra for Madara based chains so that they can focus on their product.
- Aims to launch a Kusama like testnet for Starknet which shows the real power and configurability of Madara. This will be done in partnership with other companies mentioned.
- Avail
- Integrate Avail as a DA layer within Madara, launching app-chains with it in production
- Radius
- Implement an encrypted mempool within Madara, build a shared sequencer.
- Herodotus
- Implement Turbo to enable Madara chains interoperability thanks to storage proofs. Much more can probably be done.
- Cairo 1 Verifier for L3s (?)

- Nethermind
- Voyager Madara-compatible with a free-tier for app-chains under a certain TVL.
- Dusa Labs
- Autonomous Contracts

#### What's the process to on-board new actors ?

A few options are possible depending on the scope/duration of work
- **Grants** : Given a clear scope of work for a timeline < 6 months, the madara committee can give grants to one or a few independant developers.
- **Developer Partnerships** : For tasks that require regular maintenance and a longer timeline, a developer partnership similar to the ones given by the Foundation could be negotiated. It should define clear milestones and ensure alignment of both parties.
- **Only Dust** : For individual developers and smaller tasks.

#### Towards Production

The first goal of this committee should be to bring Madara in production around **Q2 2024**.

In order to reach this goal we need to identify the missing pieces:

- **L1<>L2 Messaging** : Being worked on by a group of independent developers, it's getting close to ready.
- **Starknet Compatibility** : Integration with wallets, compatbility with tooling and explorers. A lot of work has already been done on that front (CI tests) but lacks completeness (`starknet_simulateTransactions`)
- **Gomu gomu** : Performance has been neglected in favor of compatibility in the past few months. We should re-integrate benchmarking into the CI and on-board full time contributors to gomu gomu.
- **Security** : As we launch in production, we should find the correct actors to ensure the security of the stack.
- **SNOS** : The main missing piece is the [Starknet OS](https://hackmd.io/YCwgt6NwRTyKgqc5UcSNHA). It's on-going development and is necessary in order to integrate Madara with the prover. Closed source code is slowing us down as well as bugs in the VM itself. A fallback plan is also being worked on in python.
- **SHARP** : The fee model of using SHARP for Madara app-chains should be clearly defined with Starkware.
- **Verifier**: Madara chains would start as L2s in which case we would be reusing the L1 verifier. We will need more clarity from Starkware on how we can do this (or if we can at all).
- **Decentralized** : In a first step, Madara will be focusing on a single validator setup. We can experiment with multiple validators setup but a clear protocol needs to be defined for this to work. There needs to be incentives in place for different actors such as posting DA facts on the DA layer or electing leader based on some L1 stake (see [zaun](https://github.com/keep-starknet-strange/zaun)).
- **Usability** : Madara should have well defined docs/tutorials which make it easy for any new comer to start their own app chain.
- **Rebase Blockifier/VM** : What should be the frequency or triggers ? We should start the work on removing completely no_std from substrate. This should be done 1-2
- **RPC 0.5** : Integrate universal felt type
- **Performance**

Finally, incentivized testnets with more and more features at each release should be put in place to move faster and detecting bugs as soon as possible.

#### What the committee should look like?

The committe has to be constituted by actors from the Madara ecosystem, that are heavily involved in Madara. The members will have to allocate a few hours per week to debate the decisions, and also execute them. Madara is very early, and it is really important to be able to take decisions and execute them quickly. The number of members should be small at the beginning in order to be very efficient, 3 to 5 would be ideal for decision-making, but a higher number of non-decision making people would be beneficial for execution.
In terms of competences required from the different members, it should cover: technical expertise with Madara, technical expertise with Substrate, technical expertise with a similar stack in a more advanced phase (OP stack, or Arbitrum Orbit), legal expertise, growth & marketing expertise.