Thanks for your inputs. From your questions, it seems there is a bit of confusion around the CGP’s approach to decentralization. The CGP is not a DAO, so it doesn’t make sense to form a roadmap that uses other DAOs as reference points for its own evolution.
The purpose of the Cartesi Community Grants Program is to give clarity around the selection process for issuing grants to developers, and to provide the means for the community to influence funding decisions. So although certain tools are common to both the CGP and some DAOs, it shouldn’t lead to the expectation of mirrored governance structures or operations. Moreover, our own ecosystem of developers is still relatively small compared to those of Gitcoin, ENS, and Optimism. As such, the scope of these groups’ needs differ, and don’t always warrant the full gamut of tools, processes, policies, and operations that are implemented elsewhere.
Three resources that you should take a look at are Program Instantiation Memo, the Processes and Guidelines, and the New Proposal Template (click “new topic” in the Submit a Proposal section, and it will auto-fill in the text field).
Now, with these points in mind, here’s some feedback to your points-
How can you get involved?
- The highest impact that a contributor can make at this point in our program’s lifetime is to take part in the feedback when a proposal is made on the forum. Awareness is important, but participation in proposal feedback is essential.
Proposals
- In the resources I linked, it will be clear that developers submit proposals for funding either proofs of concept for broader applications of Cartesi tech, or else more mature projects in the case that the POC was completed and successful.
- It will also be clear what the CGP deems as acceptable. For example, it will not fund portions of a project which seek to monetize some aspect of it, or closed source modules, etc.
- These resources also explain the proposal lifecycle, and how a proposal actually makes its way to Snapshot.
Voting
- Delegation is a good point! However, due to how the voting policy is implemented within Snapshot (tallying votes from staked CTSI, without double counting pool managers’ tokens), there is not a compatible voting policy for delegation which plays nice with the staked CTSI policy. The aim of our staked CTSI policy is twofold. First, we want to give control over funding to those who participate in maintaining the security of our network (by means of staking). Second, the policy mitigates certain attack vectors- for example, where someone may acquire large sums of CTSI just before a vote opens, vote with it, and then sell it.
- Perhaps an RFP could be for someone to implement a voting policy that is compatible with staked CTSI?
- There are no profiles of those who vote, but it is known (by ENS domain names for instance) that certain pool managers are active in our voting process.
I hope this can help you understand more about how the program functions, what the intentions are, and the tasks at hand (increasing participation in the feedback loop and proposal volume). Although our program is still quite young, you bring up great points and tools which can add value down the line when it matures into the growth stage.
In the coming weeks, as we nail down fine tunings to the next iteration of the CGP, I can share more details as they pertain to your original point about community calls, as I am a big proponent of giving the developer community a platform to showcase to each other what they’ve all been working on.
Let me know if you have any questions about the resources I linked.