Technical Judge Group

Objective

The mission of the Technical Judge group is to maximize the number of developers building on MVC.

Initial technical judge group member

The builder program will be assessed by technical judge group initially from five MVClabs member from early contributor group + one Technical Committee members initially.

Technical judge member expansion, appointement and replacement

4 out of 7 Committee member's consent or a DAO proposal [60% consent] can dismiss any judge group member. All member can submit application to become technical judge group member and under review and consent by either 3 out of 7 committee member or 60% Technical Judge Group member. The judge group is 6 to 9 members.

Avoid conflict of interest:

Judge group member should not have pose judgement on their own development project to avoid conflict of interest.

Technical judge member Internal voting

An internal vote limited to Technical Judge Group. The voting result

The collective vote of initial technical judge members will be communicated to the committee for evaluation. MVCDAO will then share the outcome with the project initiator for review.

Important: The project initiator has a one chance for resubmission for assessment.

If over 57% of the internal votes (Technical Judge member) support the project with it's costs weigh, it will be moved to the Committee member for further review, if there is less than 3 out of 7 objection within 48 hours, we will upload the project for DAO on-chain approval for seven days. If DAO proposal pass with 60% consent. MVCDAO will start to issue space distribution to applicant by the end of each quarter with 5 month emission schedule.

Technical Judge member Role

The following summarizes the basic budget and parameters of the Technical Judge group

• Budget: Justify the budget used

• Grant Size: <Depends

• Support: Successful grants require 57% Technical Judge Group Members to adopt a proposal or approve an action.

Rubric for Proposals

Review Rubric

The Rubric for grading initial proposals should be used by Hackathon members based on the criteria in the table below.

Reach Components	0	1	2	3
Developer Presence	Team has no developers	Team has a few developers	Team has many developers	N/A
Developer Draw	Project unlikely to draw more developers to MVC	Project likely to draw more developers to MVC	Project likely to draw many developers to MVC	Project likely to draw a large number of developers or a new desirable class of developers to MVC
Merits	0	1	2	3	4
Developer Commitment	No commitment attraction	Mercenary commitment attraction (stays until benefits end)	Commitment attraction (1 to 3 months after rewards end )	Commitment attraction (1 year after rewards end)	Commitment attraction (2+ years after rewards end)
Likelihood of success	Clear flaw in design that cannot be easily remedied	Difficult to see the project continuing for more than a year	Reasonable chance that the project has intermediate-to-long-term success (+1 Year)	Project is likely to generate long-term, sustainable value for the Optimism ecosystem	Project has substantial likelihood to generate long-term, sustainable value for the Optimism ecosystem
Grant size	Grant size significantly outweighs projected benefit	Grant size is considerably larger than expected benefit	Grant size is proportional to expected benefit	Expected benefit outweighs grant size	Expected benefit meaningfully exceeds grant size
Team assessment	Team does not substantiate ability to deliver on plan	Team does not show significant ability to deliver on plan	Team shows reasonable ability to deliver on plan	Team shows significant ability to deliver on plan	Team exceeds what is required to deliver on plan
Milestones	0	1	2
Milestone Trackability	Not trackable	Somewhat trackable	Easily trackable
Milestone Orientation	Not oriented toward brining more devs to MVC	Oriented towards brining more devs to MVC	Oriented toward more devs and toward making project composable with MVC ecosystem
Other	0	1	2
Demo included (binary yes/no)	No demo included	Demo included	High quality demo included
	-2	-1	0	1	2
Discretionary Factors (comment required)**

**Reviewers will have a discretionary score to apply to the overall rubric of (-2 to 2). An explanation must be included with the assignment of any discretionary score.

Grants from the treasury given directly to builders, projects and protocols are required by the MVCDAO to be vested in three months. There are two reasons:

1. This creates long-term incentive alignment with MVC. The Collective will be most successful with a community of builders and users who care about the MVCs vision and are on board with the work required to get there. Locking grants helps prevent grantees from treating the treasury as a short-term fix and aborting.

2. Space is a governance token. It is not intended to fully fund an operations or the cost of running a business. Locking token grants helps communicate to interested parties that the primary purpose of Space is for governance and incentive alignment, not for cash.