RFC: Curator Onboarding Framework

This is a request for comment for the community to discuss a framework for how vault curators should be onboarded to the Morpho UI.

While creation of vaults is permissionless, it’s desirable to limit the vaults displayed on the UI to those with known curators who have proven competence in their field and are unlikely to take malicious actions.

To create an objective and fair system, clear onboarding criteria are needed.

A few suggestions to start the conversation:

  1. Once a curator is whitelisted, it’s likely best that all their vaults should be eligible for display on the UI, since governance reviewing each vault is a lot of overhead
  2. A curator should have experience governing a certain minimum TVL, which the community can discuss to decide an appropriate floor
  3. A curator should possess sufficient technical expertise to handle onchain operations, including configuring new pools, running reallocation bots, and so on, or should collaborate with another curator or entity that has this skillset (ie, dual curator setups such as the Block Analitca x RiskDAO collaboration can be allowed)
  4. A curator should have a minimum duration of successful operations (ie, one year, input is appreciated on what would be an appropriate value)

Looking forward to your feedback on this matter.

6 Likes

I like this “optimistic” approach for whitelisted curators. It could be the best strategy for scaling.

However, I see a potential issue: this approach might incentivize curators to “fight for initial approval” and then deviate from their original intentions. For instance, a less-sophisticated curator might approach the DAO requesting whitelisting for a low-risk vault, only to later create high-risk, high-yield vaults to maximize returns.

This concern could affect how we evaluate curators. Given this potential “attack vector,” it might backfire and make the onboarding process unnecessarily complex, particularly impacting smaller curators with straightforward goals. This would conflict with our decentralization ethos and could limit Morpho’s growth to only “sophisticated, elite curators.”

I propose two ways to counter this while maintaining the “optimistic approach” for maximum growth:

  1. Implement a tier system for curators: Upon onboarding, the DAO or committee would assign curators a tier and approval to operate specific vault types. While sophisticated curators would have no limitations on vault creation, lower-tier/newer curators would have restrictions on which markets they can include in their vaults, with the risk of delisting if they exceed these boundaries.
  2. Establish a robust community-based or delegate-based delisting system: If we can quickly “veto” a vault from public exposure, this would reduce the incentive for curators to act against the DAO’s interests.

Additionally, we could introduce incentive mechanisms, such as requiring top-tier curators to “stake MORPHO” to gain the privilege of listing vaults with any markets/oracles.

I think by considering these post-onboarding mechanisms (like delisting or granular listing strategies) upfront, we could actually streamline the initial onboarding process! Hope to see this in the thread as well!

4 Likes

I agree with the @antonttc’s concern about getting the initial listing/onboarding as a curator and then later on introducing high risk vaults.

As a suggestion, I think it’d be beneficial for both borrowers and suppliers (vault depositors) to have a collateral risk assessment as a condition for getting their vault listed on the main UI (rather than leaving this up to the curator as a nice-to-have) for each collateral asset being added to a listed vault coming from a risk curator that is onboarded to the Morpho UI.

Ideally, this assessment should be accessible from (link on) the vault’s page on the UI, so everyone can check the risks involved after seeing vault’s current allocation in that market.

Risk scoring can/will only be another layer of “security” for suppliers on top of the conditions stated above.

Regarding other @OneTrueKirk’s suggestions (2., 3., and 4.), agree on each point, and I think those can be somewhat easily checked.

1 Like

[I am a member of the Blockchain at Berkeley governance team. My views do not represent those of the club.]

First, I think its important to note that this is more of a courtesy, as Morpho manages the website. Therefore, I would imagine that these votes occur off-chain.

As a permissionless system, I believe the UI should be inclusive and display each vault. Perhaps, users can input addresses of vaults / filter based on supply asset and be able to borrow/supply through the UI (there doesn’t have to be extensive detail on these “non-approved” vaults).

However, for vaults that are to be given a more detailed UI that are non-malicious, I think the DAO should be able to provide input on their inclusion/exclusion. Perhaps, every month, the DAO votes off-chain on Snapshot on a long list of vaults asking for their inclusion/exclusion to the “approved/safe” section of the UI. This regularity would both allow vault creators to plan their vault launch, and communicate with the DAO in a timely manner.

Thanks for the thoughtful comments everyone. I agree with the concern regarding curators greatly increasing the risk level of their vaults after onboarding.

To be clear, there are no limits on who can create what kind of vault (totally permissionless), and the DAO has no ability to impose these limitations. As such, this proposal’s scope is limited to the frontend.

My concern with using a collateral-asset based evaluation model is that it would require the DAO to continually evaluate numerous collateral assets, which is one of the primary roles of curators in the first place. Setting a framework at the curator onboarding level minimizes the overhead for the DAO.

I agree that risk scoring of collateral in the UI would be valuable (though is a separate question from choosing which curators to list on the frontend, and would likely be best done by independent third parties, rather than directly by the DAO).

Using a tier system makes sense, perhaps the UI could have two sections, “Core Vaults” whose curators are recognized by the DAO, and “Permissionless Vaults”, which has a warning for users and displays all other vaults.

One thing to consider is collection of a variety of information that is then made available to the users. Relevant information might include: is the curator anon/their corporate identity, conflicts of interest disclosures, pre-identified benchmark to judge longterm performance against, history of non-investment related losses on the platform like misconfigured oracles or key mismanagement, summary of experience and expertise, etc.

It could even be that no information is required, but filling out the form is required, and a user can see that the curator declined to provide information.

This would allow the UI to be more informational: it would provide users with some context other than assets, current yield, and curator. It also has the benefit of encouraging best practices while not gatekeeping users. If they see 10 curators and 8 of them have conflict of interest disclosures and 2 don’t, well, then that lets the user make their own informed decision about whether such disclosures are important to them.

It also removes a lot of the information gathering burden from Morpho and places it – and its veracity – on the curator.

This approach can help Morpho curators develop their own brand, with Morpho more clearly being the “plumbing” and emphasizing the role the curators play rather than the Morpho team. It also potentially heads off some bad user experience if a conservative user of the protocol ends up in a vault where the curator has a history of risky behavior, but they wouldn’t have that context.

As Curator on Morpho, we believe that adopting a simple and light onboarding system would be relevant, materialized by a forum proposal. This would include, among other things:

  • Some generic information about the curator: name, creation date, description, team information and the company registration
  • AUM managed within the ecosystem
  • Protocols the curator is involved with
  • Protocols the curator has been involved with
  • Which vault(s) the curator wishes to deploy
  • Does he want to have a focus on certain asset class or thematics

The whitelisting would then be discussed by the community but validated by the team to avoid potential blockage from curators or large MORPHO holders.

We do not believe it is relevant to create a tier system for curators. However, it is necessary to inform users about the curators’ activities better so that they can quickly assess their relevance at a glance.

That’s why we’ve thought about creating a new element in the UI that would allow anyone to find the essential information about a curator:

  • Total vaults managed on Morpho
  • Type of vault managed (classified based on specific metrics)
  • AUM managed over 30 days
  • Total bad debt incurred

With this information, users could quickly understand the curator’s profile and make their selection. This would naturally highlight the best actors, as a poor risk manager would naturally be set aside by the users.

1 Like

Some lending protocols use this methodology and gives a clear picture to the user. However, there’s still a debate about which vaults are whitelisted and why. It’s key to understand the benefits of being whitelisted and being featured this way.

We propose the following key points to advance the discussion:

Address an 1) applicant template, which we do not rule out including things such as:

The whitelisting process could not only be a procedure but also incorporate community preferences and a trial phase. Ideally, there should be no obstacles for curators with sufficient experience in onboarding vaults to the Morpho UI. However, the process should remain tight.

When making decisions about 2) eligibility, an approach could include community input along with the approval of risk advisors to be whitelisted. Finally, a system of 3) constant monitoring during a trial period, including staking by the curator, would be implemented.

The image above shows what the curator whitelist process could look like. We encourage feedback and welcome any questions!

Quick breakdown:

  1. The applicant must begin the process with a robust template that includes descriptions and requirements based on suggestions from risk advisors and current curators. Including relevant data such as

2)The template must undergo a quality and formatting check by a facilitator, followed by a more technical review by pre-selected risk advisors (who could be current curators).
3) This is where the DAO members come into play, and a poll is conducted to decide whether to proceed with the whitelisting. Ultimately, it is the users who will make deposits into the vaults.
4)The actual onboarding to the UI occurs here. We suggest two different ways to proceed:
a) A sustainable option is to decentralize the front end by pre-setting certain requirements for it. As an example, https://morpho.blockanalitica.com/ including an option to directly interact with the vaults - each curator must ensure to meet standards.
b) We agreed with

We believe a viable addition to the UI is to separate the curators by markets, e.g., ‘Steakhouse Market’ - This market division will allow curators to build their brand and reputation within Morpho.
Note: Kamino Finance, together with Ethena, did a good job by onboarding their own market separately from Main/Altcoins.
Example:

  1. We refer to the monitoring phase as a tool with predefined parameters to constantly assess and categorize a vault as healthy. It should allow the DAO to offboard vaults in case of deactivation or when parameters fall outside of expectations.

  2. The mentioned trial period will help reduce the workload and ensure that only curators deemed appropriate by the risk advisors onboard new vaults. During this period (365 days - just for reference), the curator should be able to onboard vaults effortlessly.

  3. The Staking & Lock module will reduce the risk of improper use of the protocol ensuring curators have skin in the game.

1 Like

I am wondering if some approach which allows users to import externally curated lists won’t make sense. For example, I believe 1inch was allowing to import a list of tokens at some point in the UI (like a Coingecko list). That will allow any community to implement curated lists, which are importable in the UI, while the default list is closely maintained by the Morpho team/DAO.

2 Likes

I think this is a very good direction that we should explore.

IMO “buying a potentially malicious token” vs “depositing into a potentially malicious contract” definitely have different security implications. Users now usually understand the risk of buying random tokens, but “deposit your real USDC into a weird Morpho Vault” is harder to interpret.

So I think importing curator list is definitely more dangerous. But maybe we can change it a bit and import a token and oracle list, or a market list, and all vaults created with those parameters are displayed.

Thanks everyone for your comments.

This could be a good addition indeed, forwarding to our Product Designer.

Existing risk curators have no real incentives to see other risk curators being listed, don’t you think it would create a veto opportunity for them instead?

I like the idea of the application form. This already provides a good first filter, as most unmotivated risk curators would not be willing to fill it I guess.

What’s not clear to me is who should be the facilitator and the risk advisor. As I said above, I fear that giving this right to existing risk curators alone is not wise, as they share conflicting goals.

For the monitoring part, this can be a good idea as well. One must clearly define the rules for each risk curator that could be removed from the UI, though, and I’m not sure how exhaustive we can be on the front. What happens if an unexpected issue is encountered? Should the Morpho Association reserve the right to unlist the risk curator?

3 Likes

I can think of 4 alternatives that might help here; I will rank them in order of preference:

1: Each curator should maintain his FE; e.g. gauntlet.morpho.org

Approval of new extensions starts with a proposal in the forum; all curators are obliged to vote and give their reasons. Morpho would decentralize from its FE.

Going a little deeper here, the FE can integrate the Aragon vote of each curator, incentivising the user to get involved; I agree that very little importance has been given to this implementation, and it is a key paradigm shift in building immutable infrastructure.

Points here: More Morpho essence, less intervention.

2: Design a tool that controls every single parameter that is set, e.g. on-chain liquidity and volatility of lend and borrow assets; everything a curator needs to set can be parameterised, so a tool that includes all criteria should be buildable. Possibly complex as no one has built it and it would solve major defi issues.

ChainRisk and Gearbox have developed some monitoring tools that may have something to contribute here.

Points here: More Morpho essence, possibly an immutable sc, if it works it could be a good industry standard.

3: Hire an external provider, risk specialist; not linked to protocol management, e.g. ChaosLabs.

This seems to be the default option and easier/faster to implement.

Points here: Perhaps less cost effective, “could” be done now, less decentralised, creates dependencies.

4: A junior capital mechanism, based on what Maker/Sky are designing for subdata, could be an alternative, although potentially complex to implement for a FE whitelist alone.

This is a high quality discussion about a key topic for the future of Morpho. I think the discussion would benefit from recalling a few points:

  • The vision is to make Morpho an essential infrastructure, a public good accessible to all. Accessibility of the Morpho UI should extend as much as possible not only to lenders and borrowers but also to market creators and vault managers.

  • The risks are at least of two kinds:
    – a medium risk, mentioned by @antonttc: users deposit in a vault perceived as low risk, then the curator starts unboarding high risk collateral. Most of the time, the reputation costs associated with this type of behavior will exceed the benefits. A tiered system proposed by @OneTrueKirk with curated and non curated vaults could solve this issue. We can discuss about the criteria to be curated in the UI, but what’s important is that non curated vaults also access the UI.
    – a critical risk: a curator onboards a market with a malicious price oracle, inflate the collateral and drain the vault by borrowing the assets.

There could be a fine line between a risky oracle and a malicious one but I think the distinction is important. Regarding the critical risk, there are a few safe-guards that come to my mind:

  • requiring a minimal time-lock for the vault to be added to the UI and displaying the timelock on the UI
  • decomposing the feed chain as done in monarchlend.xyz for transparency
  • extending the Morpho’s bug bounty to signalling malicious markets.
1 Like

Based on the excellent comments here and some offline discussion, I believe a good first step is an enhanced risk rating framework for curators, so that vault depositors can easily access information like the current and historical track record of vault risk management, the experience of the curator, and the vault configuration (timelock, guardian, and so on). This should be provided by a neutral third party who is not themselves a curator.

Will have some updates to share on an MVP soon, which the community can use as a basis for ironing out a longer term approach.

Overall, I’m aligned with the commenters who have suggested that a maximally permissionless approach is in keeping with Morpho’s values.

We are taking the initiative to share what could be an MVP, hoping it serves as inspiration for what is to come from the team. We strongly encourage active curators to share their insights and experiences in their role.

Curator Whitelisting

Overview of the Curator Whitelisting Process

The whitelisting process consists of 5 main phases:

  • Phase 1: Entry Point

    • Curators seeking whitelisting and display on the UI must submit the Curator Onboarding Template as a forum post under the #Curators tag, using the title format: "Curator Onboarding Proposal – [Name].
   1. Curator Onboarding Template

1. Curator Information:

      * Name / Team Name:

      * Contact Information:

      * Curator Bio:

        1. Brief Description: Short summary of the curator’s expertise and relevant experience.
        2. Curator Legal Profile: Attach company registration details (if applicable).
        3. Previous Vault Management Experience: List any past vaults or projects managed. Use "N/A" if none.
      * 2. Experience:

        1. Relevant Experience: Provide a summary of your contributions to Morpho or other DeFi protocols.
        2. Vault Management: Detail past vaults you’ve managed, their outcomes, and lessons learned.
        3. Incident History: If any past vaults experienced misconfigurations or user losses, provide details and corrective actions.
      * 3. Vault Creation Strategy:

        1. Vault Type & Risk Profile: Describe the vaults you intend to create (e.g., conservative, moderate, high-risk).
        2. Incentives Strategy: Outline any planned incentives for vault users.
        3. Intended Asset Class: List the types of assets your vaults will include.
      * 4. Compliance:

        1. Compliance and Legal Considerations: Are there any compliance or legal requirements you are considering?
      * 5. Security and Risk Management:

        1. Approach: Explain your risk management strategies (e.g., diversification, audits).
        2. Collateral Management: Detail how you plan to handle collateral.
      * 6. Transparency:

        1. Reputation: Mention any involvement with the Morpho community
        2. Conflict of Interest: Disclose any potential conflicts related to your vaults.
   
      * 7. Additional Information:

        1. ****Use this section to include any other relevant details
  • Phase 2: Facilitator & Community Feedback

    • Facilitator Review:
      1. The Facilitator, who may be the same as the forum moderator, reviews the submitted Curator Onboarding Proposal for procedural and formatting accuracy. Proposals must include all mandatory sections before being opened for feedback.
      2. The proposal is then opened for a 7-day community feedback period, during which DAO members can review and discuss.
  • Notes:

Community feedback can supplement or replace the facilitator’s role if necessary.

Mandatory requirements must be aligned with the technical capabilities of the curator. However, non-technical requirements, such as experience in managing vaults, can also be considered mandatory.

If meaningful discussion emerges during this comment, the DAO may opt to include an off-chain poll within the applicant thread to gather quantitative data on community sentiment regarding the curator’s onboarding.

  • Community Feedback:

    1. Members are encouraged to assess curators’ alignment with DAO goals and raise any risks or areas for clarification.
    2. Feedback may address both technical and non-technical considerations, such as experience, reputation, or potential conflicts of interest.
  • Phase 3: Compatibility Review & Approval

Risk Advisor Review

  • Proposals are evaluated for alignment with MorphoDAO’s technical and operational standards. Reviews may be conducted by:

    1. Active Curators: Experienced curators providing feedback in a transparent process with disclosed conflicts of interest.
    2. Neutral Third-Party: External reviewers enlisted for impartial evaluations.
  • Outcomes of the Review

    1. Approved: If the application meets all requirements, the Risk Advisor posts a “Compatibility Confirmed” comment summarising findings and confirming eligibility.
    2. Rejected: In cases where the applicant does not meet compatibility standards or demonstrates significant misalignment with DAO goals, the Risk Advisor will share the reason for rejection as a response in the application thread. Applicants are invited to reapply if improvements are made.
  • Cooling Down Period

  • If an application is rejected or sent back for revision, there is a 7-day cooling down period before the applicant can resubmit. This ensures applicants have enough time to address feedback and improve their proposals.

Phase 4: Integration & Trial Period

Vault Setup & Whitelisting

  • Curators who have met compatibility requirements are granted whitelist status, and the vaults they develop become eligible for display on the Morpho user interface.

Trial Period Monitoring

  • Curators enter a one-year trial period, during which their performance is monitored using one of the following approaches (TBD):
  1. Option A: Key Metrics Monitoring

    • Metrics like the following are considered:

      1. Time-lock: Improper configuration

      2. Liquidity Management: The vault’s native rate remains zero due to a lack of any deposits or mismanagement of liquidity flow, signaling inactivity.

    • Tools such as ChainRisk (or other alternatives) may be employed, but the DAO will evaluate the most suitable and cost-effective solution.

    • Alternatives:

      1. GearBox Risk Dashboard: https://risk.gearbox.foundation/events
      2. ChainRisk Real Time Parameters Recommendations: https://www.chainrisk.xyz/
    • Alerts for significant deviations are logged on-chain, ensuring transparency.

Concerns to discuss: How do users visualise the actual “Status” of each vault? In-app or outside morphoUI? - Will users be notified when a vault is unhealthy? - Are the parameters tailored to the risk aversion strategy of each curator?- Is there a warning period? - What parameters need to be altered? - How long does the warning period last? Is the vault off-boarded after the warning? - How does this affect the curator’s trial period?

  1. Option B: Time-Lock Notifications

    • During the one-year trial phase, continuous monitoring will track key events using the time-lock system, ensuring that users are notified whenever vault changes are scheduled. The UI could include a visible indicator, such as a banner or icon, on each affected vault during the time-lock period.
      1. Time-lock event display:

      2. Changes to vault configuration (e.g., enabling a market with a high LLTV or increasing a supply cap) trigger a “Time-lock in progress” status.

      3. Users are informed of configuration updates without explicit notifications, ensuring transparency without overloading communication.

      4. This approach may serve as an interim solution, providing value while the DAO evaluates the development of more comprehensive tools, such as a ‘healthy vs. unhealthy’ dashboard.

To consider: Skin-in-the-game

To align curators’ incentives with the protocol’s success, curators are required to:

  • Curators must stake $MORPHO tokens or provide collateral proportional to their vault’s risk exposure during the trial phase. This ensures that curators have a vested interest in the protocol’s overall success.

Phase 5: Offboarding & Warning Period

  • Warning Period
  • Flagged Vaults: Vaults identified as experiencing an incident or requiring intervention (e.g., due to misconfigured parameters or security risks) are flagged for review. Flags can be raised either:
    1. By the Curator: Curators are encouraged to self-report incidents to maintain trust. A defined warning period of 7 days is provided to address and resolve the issue. If the curator determines the vault cannot be restored or poses risks to users, they must submit a pull request to the front end, requesting its removal from the UI.
    2. By Monitoring Tools (See “Option A: Using Key Metrics”): Automated or third-party monitoring dashboards track key metrics and can trigger alerts when vaults require intervention.

Strike Policy

  • Curators could be subject to a strike system for significant vault issues like improper configurations or risks. (e.g “Two flagged incidents within 6 months”)
  • The policy should include a fair review process for each incident and a transparent appeals mechanism for curators contesting decisions.

Offboarding Process

  • Vaults that remain non-compliant are removed from the UI. The responsible team processes pull requests for removal promptly. A public summary explaining the reasons for removal is published within 7 days, ensuring DAO transparency.
  • In cases where the curator fails to act, the DAO may intervene, based on inputs from the Risk Advisors or Monitoring tools, to enforce offboarding via a pull request or similar process.

Vaults Display

Approach A: Maintaining Current Visualization Structure

Curator-managed vaults are integrated into the existing Morpho UI. These vaults would appear in a dedicated section while remaining under the management of the current front-end framework.

This setup ensures consistent vault presentation and minimizes risks of mismanagement or security vulnerabilities. While curators would oversee vault performance, any UI updates or changes would still require approval and implementation through the existing management process.

Approach B: Curator-Managed Subdomain

Each curator receives subdomains (e.g., curator.name.morpho), where they manage their vaults independently. Enabling independent management of their vaults while maintaining discoverability through Morpho UI.

This option empowers curators to take direct control of their vault interfaces. This approach requires clear compliance standards and resources to securely establish and maintain subdomains.

2 Likes

love to see the proposal and it looked great!

my thoughts are the key metrics monitoring is a priority target and method, because it also help users to actually make decisions themselves with all the info they have, rather than rely on people in the community/moderators, who may not fully understand everyone’s needs

the offboarding process should be more clear and more strict if needed, basically we need a quick and transparent way to remove bad actors quickly

Hello all,

Thank you very much for the thoughtful comments so far. We’ve been putting our heads together internally to come up with a process that has minimal overhead while being maximally permissionless, and came up with the following approach:

The Morpho Association can engage with a third party, neutral provider to create a Risk Score for Morpho vaults, to be provided in the user interface and take into account factors like the collateral types, the timelock used by the vault, the identity of the curator, the oracles used, and so on. Vaults with above a certain TVL or time active would receive a risk score. On the frontend, vaults could be sorted by users based on the score, and warnings provided in an automated way for vaults that do not meet key criteria or have dangerous configurations, for example, no timelock on adding new collateral assets.

This would allow us to pursue a blacklisting model instead of a labor-intensive whitelisting approach, which would not scale well as the Morpho Protocol curator set grows and deployments are made on new chains.

Under this model, the community would define what kind of metrics should be included in the risk score and their weighting (with an initial proposal from the third party provider), but not need to directly evaluate each prospective curator.

I’ll have more details to share on this soon, including the provider and the initial framework for the risk scoring, which can be modified with community feedback. Will post as a new top level thread when these details are available, but wanted to give an initial heads up given how much discussion there has been on this topic.

Regarding the proposal by @SEEDGov , I think the enhanced curator information in the onboarding template is a great idea, and we’re now having internal discussion about the best way to display more curator data in the frontend separately from the risk score discussed above.

5 Likes

I’m completely aligned with those objectives. The solution of assessments by an external auditor sounds great, provided a clear distinction is made between market risks (exotic collateral and oracles, high LTV, …) and curator risks (incompetent managers or with bad intentions).

1 Like

Thank you for the proposal. We strongly agree with the following two principles and look forward to sharing the framework:

  • design a process that has minimal overhead while being maximally permissionless
  • pursue a blacklisting model instead of a labor-intensive whitelisting approach

Rather than the evaluation methods themselves, we would like to share an idea on the design and improvement process of these methods that are based on the proposal to be shared later as @OneTrueKirk mentioned.

We believe that by incorporating such approaches, it could lead to more transparent operations.

Overview

Establishment of Curator Onboarding Oversight Committee

Purpose of the Committee

To reduce user harm caused by malicious Vaults or Curators while keeping Morpho permissionless, and to promote discussions aimed at achieving this goal.

Core Principles:

  • Design a process that has minimal overhead while being maximally permissionless
  • Pursue a blacklisting model instead of a labor-intensive whitelisting approach

Scope of Work:

  • Facilitate and promote discussions regarding the review of risk-scoring parameters in the UI
  • Develop RFPs for the selection of Service Providers
  • Provide recommendations to the DAO on the selection of Service Providers
  • Review the efforts of Service Providers chosen
  • Facilitate a regular process for re-evaluating and selecting Service Providers (including replacements)
  • Explore and propose improvements for Curator onboarding and Vault risk assessment

Expected Members:

  • Association members
  • Community representatives

Multiple members are expected for each group. Initially, the proportion of association members is expected to be higher.

Other Notes:

  • The reason for creating the Committee is to standardize processes currently being handled “internally” and to improve transparency by involving community members.
  • The Committee will focus primarily on facilitation, rather than decision-making itself. Decisions are to be made by DAO.