We are grateful to the community for all of the terrific posts, feedback, & ideas for improvement.
Replying to doctor who:
Did you see our plan for the Oversight Committee which includes an independent Certified Public Accountant (CPA)? See here: OVERSIGHT & ACCOUNTABILITY - Google Docs
Thank you - we are working on a Conflict Policy and will release it soon.
What else would you like to see?
Replying to JD-Lorax:
The short answer is: we expect there will be a few failures along the way. Yet, at the same time, if we can internalize lessons learned and grow in our personal individual capacities thru failure, still, the ecosystem can strengthen.
Even failed initiatives can contribute useful open source code, and by working in an open manner, also contribute to community understanding of dead ends.
How do we protect against wasting money when failure is statistically inevitable at some level?
We start with small grants, we use the small grants to establish relationships and KPI reporting so that we can see a team start to prove itself, and then we provide medium-sized grants if/as success is being demonstrated; so that the typical pathway is for a team to âearnâ the privilege of being entrusted with a medium-sized grant after demonstrating some initial success.
As we get to medium-sized grants, we can also agree to milestone-based payment released milestones if/as it makes sense within the context of each project.
Please reference the response to Cosmos Founder JK (above) concerning his question re âminimalism at the Hub, and what this meansâ.
We do not believe we are building the canonical grant program for the Hub; instead we believe we will see a plurality of grant programs emerging over time.
We do not believe we have any natural right or programmatic role to set vision or strategy for the Hub; instead we believe that the vision and strategy will emerge one Hub gov proposal at a time; and we expect these changes to the canonical codebase to be hard-fought and time-consuming, given especially how important the Hub is within the ecosystem.
We do not believe that any sizeable number of projects that we fund need to necessarily be merged into the Hub codebase in order for the grant program to be successful in driving value for ATOM; some of the projects will be ecosystem initiatives, public goods, and tooling that does not need to be merged into Hub codebase at all; some of the projects certainly could be âcore infraâ but with adherence to the ideas of minimalism described in our response to Cosmos Founder JK, we would expect these âcore infraâ projects to be tested in other zones, to need to prove themselves to become worthy of consideration by Hub gov, and then to win the support of Hub gov on the merits thru the ordinary Hub gov process.
We are trying to break the conundrum: âthe Hub is so important thus we canât commit to funding something at the Hub unless we can be âcertainâ about it; but since we canât be certain about anything before it is built & tested therefore we shouldnât fund anything at all & do nothing.â
To break this conundrum (and the stagnation that results), we need a program of R&D and experimentation, and this R&D needs to be done as a parallel activity. Testing of core infra ideas can happen in other zones, and then core infra upgrades should be merged into Hub codebase only after significant testing, audit, and refinement thereby giving time for larger community review so that precision, security, and timelessness of code can be enshrined via principle of minimalism, and most likely only after fierce fights like we saw with Litecoin SEGWIT and then Bitcoin SEGWIT.
TLDR; So what is the grant program doing? It is funding teams in the R&D stage pursuing ideas that can add value to ATOM holders: open source, public goods, and ecosystem initiatives. Some core infra projects, but, only after testing & community confidence is proved should any code be merged into Hub codebase according to the regular process of Hub gov.
The DAO has its own internal governance.
If someone within the DAO team is âmissing in actionâ or âfailing to performâ we will replace them via majority vote by our internal DAO governance.
As a DAO, our commitment to the community is to operate as a high-performance team & to go over and above in delivery of the mandate, and we would request that the community assess performance at the team level, and not an individual team member level.
If the DAO team does not perform on itâs mandate, then weâd like the community to fire our entire team by not renewing our mandate; or by holding a special gov vote to terminate our program mid-cycle.
If community gov held a vote that concluded âno confidenceâ in a specific team memberâs integrity or efficacy, at that point the DAO gov would be foolish to ignore the communityâs wishes b/c by going against the community likely the entire DAO mandate would be at risk of non-renewal or termination.
Of course, as a technical matter, a decision to fire an individual member would be a DAO gov decision.
As before, thank you for asking these productive questions, which are very much helping us to sharpen the presentation of our vision for the grant program.