Call For Changes To Making A Proposal On f(x)Core #11 in monday board

[kenorb]

Thanks @Richard for detailed explanation. Please find below my comments.

@Richard

There are a few things I would like to highlight here with regards to amount granted and success rate for applicants:

1. Max amount across the various grants amount to about $100,000

Agreed, grants can be always split across different stages of the project. Larger grants comes with bigger risks and disagreements.

@Richard

2. Concept testing: Successful applicants would first and foremost have a well-researched and test concept and have some prior work to show.
3. Team’s relevant experience to build and deploy a sustainable and workable application […].
4. Milestones and deliverables: Having clear concise milestones and deliverables is key here, payouts will be made according to each quantifiable milestone made or based on a quantifiable metrics for example “Fully integrated metamask to Dapp” or “Reached/acquired 500 unique users”

Agreed. Maybe some community poll could be a good feedback for each project about details for quantifiable milestones.

@Richard

Moving forward

According to the discussion and concerns raised by the community, we are exploring the following options to further improve the governance voting mechanism.

• Quorum to pass the proposal
  1. Amend the quorum requirement
  2. Retain the same quorum requirement but the team validators are required to vote and disclose the voting guidelines.
  3. Retain the same quorum requirement and no team validators are allowed to vote to maintain the neutrality but set up a slashing mechanism to punish the public validators who didn’t vote.

I think Quorum limit is fair (and should retain), the problems is more about too many tokens bonded on validators which are not voting at all in order to stay neutral.
However to stay neutral, it’s enough they can vote to Abstain (as already mentioned) to reach the Quorum, then the rest of validators could have their final vote.
Another workaround could be posting a community poll on a forum which can influence the vote on behalf of team’s validators.

@Richard

• Voting in a committee of 6 reviewers to review grant applications

I could understand that other grant programs does that, however I think centralizing decentralized blockchain is always a bad idea.
Uniswap is a specific technology, and they’re focusing in specific areas. In our case it’s a decentralized blockchain and we’re talking about variety of different projects utilizing it.
So giving a power to 6 reviewers who decide on future of our projects could limit our overall potential, and can introduce further limitations, rules and regulations.

---

In Summary

Personally I think the current decentralized approach should work fine, all we need to do is to find the better and fair approach.

What are our current problems? The following posts should sumarize this (credits to @FrenchXCore):

• FunctionX DAO governance - #11 by FrenchXCore
• DAOverse creation proposal - Welcome to the DAOverse - #241 by FrenchXCore
• FunctionX DAO governance - #2 by FrenchXCore

So what we can do? Pick one (I’m pretty sure there are more solutions):

1. Team’s validators can vote to Abstain to reach Quorum and be neutral at the same time. Most likely this won’t be possible as per Zac comment on the last discussion meeting.
2. Team’s vote can be influenced based on a community poll on the forum.
3. Team can appoint few validators which can vote and it can repeat the same vote based on majority on the last day (still neutral).
4. Team can distribute team’s FX delegation evenly to validators which can vote. Pros? Quorum problem is solved. Cons? It’s understandable that team doesn’t want to risk, including slashing. So this can be based on some simple formula given the amount of non-team delegation, uptime and so on. But how bad it can be? 0.1% slash from being off-line from 2mln delegated per validator is just 2k (for each validator) and comparing it to the amount of deposits being lost it’s nothing.

I think the above approaches are much simpler to apply than changing the whole process, only because we’re not enough decentralized.

In summary, applying further centralization ideas to fix our decentralization issues could only do more harm than good.