ARC-34 Governance proposal process

[SudoWeezy]

This ARC will be used to standardize the creation of new proposals for governance.

Questions that need to be answered have been listed in the Rationale part.

Please refer to this part and give your thought.

[oysterpack]

I interpret xGov funds as funds distributed for the proposal - not funds distributed to xGov individuals.

As a side note ... there is no need to have any xGov token

[zeus-algo]

How to submit:
Foundation to create xGov dedicated GitHub repo and make xGovs admins.

1. Problems that need a solution are created as 'issues' against the GitHub. Examples may be 'There's not enough online stake participating in consensus, new wallet creation is trending down, there's not enough visibility over key network metrics. There aren't enough wallets, or blockexplorers. Starting node is too complicated. Etc.'
2. Proposals MUST cite at least 1 problem raised in issues to be valid. This will separate discussion between the underlying problem and the solution. It also makes sure we're solving problems.
3. Proposals MUST also include:

• Straight forward arguments for how this proposal will address named problems
• An estimate of resources needed (e.g. headcount, financial)
• An estimate of deliverables and timeline
• A way for the author to be reached, (e.g. twitter handle, email, discord username)

The proposal MUST NOT include:

• Doxxed information or an appeal to authority (e.g. Trust me, I'm VP of Engineering at Google)
• Arguments for why the proposer themselves is the only one capable of solving the problem (e.g. We here at Zeus industries are uniquely positioned to solve this due to x)
• Any offer of compensation or bribery for accepting the proposal (e.g. Accept this and I'll give each xGov $1m)

[zeus-algo]

The proposal also MUST NOT include:

• obscene language or images
• any external links or downloads
• any instructions to go elsewhere on the web for more information, or for the xGovs to download anything

[zeus-algo]

Dependent on the project.

[zeus-algo]

I think this should be left up to xGovs best judgment, it may fluctuate greatly depending on how many proposals, the state of the network, community, etc.

Maybe a hard limit of 500 as naming a limit is always good.

[zeus-algo]

I like the idea of the proposals never needing to go to general governance.

If the xGovs are funding inappropriate proposals, the general governance decision should be voting out the xGovs rather than voting on each individual proposal.

[zeus-algo]

I don't see why there can't be windows but applications always be open. e.g. application window just rolls over to applications for next governance period.

[zeus-algo]

As part of the acceptance criteria, 1 xGov should be named and committed as the sponsor of the proposal, who is responsible for managing the milestones and deliverables as stated in the proposal

[CasiniNift]

Agreed with this statement. That way there is one person that follows the project from beginning to end.

[zeus-algo]

This should be left up to xGovs.

There could be clever solutions such as giving xGovs $5m each period to allot to proposals, and allowing them to keep the sqrt of funds that are left over to carry to the next period.

This would leave some incentive to both not spend all resources allocated to them nor be too restrictive with them.

[zeus-algo]

I like the idea of this being left up to the best judgement of the xGov sponsor.

Sometimes deadlines are missed, especially in something as difficult to estimate as software. The system needs to be flexible enough to not unduly punish missing milestones, while also maintaining accountability.

[zeus-algo]

Reforms to the xGov process should always been optional at the general governance level

[zeus-algo]

Field to specify resources needed to accomplish milestone

[zeus-algo]

Typo here: 'webiste'

[zeus-algo]

I don't know how I feel about allowing proposers to include a URL. It's a potential attack vector and unfair to require xGovs visit anonymous external links.

[zeus-algo]

There should be an enumerated list of possible values for this category field for organization/standardization.

xGovs may manage this list, have it's own process for submitting new ones, etc.

[zeus-algo]

Details about expectation of this details field should be decided.
Such as:
High level non-technical overview.
Length limit

[dominagiu]

Details about expectation of this details field should be decided. Such as: High level non-technical overview. Length limit

also in my opinion too general, I would add materials such as white papers, articles and all useful information to better understand the issue

[uhudo]

This depends on the selected and approved implementation of xGov, i.e. after finalization of ARC-33. However, in its bare minimum, submission of a proposal should include a hash of the proposal.

[uhudo]

Each proposal itself should describe how much funding it is asking for and how these funds should be distributed (i.e. delivered at each milestone). Moreover, the proposal itself should also describe if the project could be completed and to what extent with a reduced amount of funding, as well as what is the minimum funding it is asking for.

If the Governors approve together proposals that request a funding total larger than what is available, all should receive proportionally less funding down to their minimum requested amounts. The rational here being that it is better to give opportunity to many applicants as well as to build things in small steps. If a proposal successfully delivers on the scaled-down plan, it can reapply for further funding later on.

A problem arises if even the minimum requested amounts exceed the available funding. In this case, one option is to automatically reject all the proposals since the Governors should not be allowed to create debt. The proposals would need to be resubmitted and Governors would hopefully make a better overall decision. Another option would be to give priority to proposals asking small amounts of funding, in line with the previous rational of giving reduced funding in case of a great demand. This option would prevent stagnation.

[uhudo]

The only criteria for funding should be approval of the proposal by the general Governance vote.

[uhudo]

If the reviewers do not sign-off on the milestones, the project does not receive any further funding.

If the project sees in advance they will not be able to deliver on their obligations, an amendment to the project can be submitted as a new Governance proposal. If the amendment is not confirmed by the end of the next Governance period after the missed milestone, the funding would not commence.

If any Governor is of the opinion that the project and/or reviewers misled the Governors and/or reviewers, one can put up a proposal to the general vote to take legal action against the project to recover any granted funds.

[uhudo]

To what evaluation process is this referring to? The evaluation of a proposal to be up-voted by xGov, the evaluation of the proposal by Governors when the proposal is put to the general vote, or the evaluation of the project delivery?

[uhudo]

The same as any other proposal, just requiring a supermajority agreement (e.g. 66%).

[uhudo]

Depends on the implementation of xGov. In case of initiative referendums (as e.g. suggested in https://github.com/uhudo/xGov-initiative-referendums), it is common to require between 1% and 5% of voters to support the proposal before being put to the general vote. Hence, there could be a maximum of 20-100 proposals per voting period.

[uhudo]

Again, this depends on the implementation of xGov, thus on ARC-33. In case of initiative referendums, there is no application window required since initiatives can be started at any point.

[michaeltchuang]

Suggested change

	"RoapMap": "Explanation of what will be achieved",
	"Roadmap": "Explanation of what will be achieved",

@SudoWeezy I wasn't sure if this was a typo but I just wanted to doublecheck with you

[mccabe-david]

Or potentially, the hash of text. See my other comment.

[mccabe-david]

(proposal text)

[mccabe-david]

There is potential for spam proposals when we only consider Algo requested. We should have two vote totals. First one is for approval based on Algos (200 000 000 votes total split between all proposals described below), and the second one being approval based on overall sentiment (200 000 000 votes PER Proposal) with a 30% threshold to advance

[mccabe-david]

The second vote would allow us to approve/ignore proposals that are not grant-related .

[nonfungibleab]

If a proposal is not grant-related it probably won't meet the verification criteria upon submission.
@SudoWeezy could you confirm that please?

[nonfungibleab]

@SudoWeezy could you change this title to "xGov Proposal Process", please?

[nonfungibleab]

The Goal of this ARC is to clearly define the steps involved in submitting proposals for the xGov Program, to increase transparency and efficiency, ensuring all proposals a given proper consideration.

[nonfungibleab]

• Facilitation of community engagement

[nonfungibleab]

Could we increase this for up to 1.5 months? Depending on the volume of proposals, our team needs time to manage contracts and transfers, until such a time where we can automate this process.

[nonfungibleab]

Please remove "(1.5 months after the start of a governance)"
At the start of the voting period xGovs will vote on proposals using the voting tool hosted at [URL TBD]

[nonfungibleab]

The allocation of grants will consider the funding request amounts and the available amount of ALGO to be distributed.
For example, Proposal N requests 100,000 ALGO in a pool of 2,000,000 ALGO, representing 5% of the pool. Therefore, in order for Proposal N to be approved, it will need to receive 5% of the total votes available. If there are 20,000,000 ALGO in the Term Pool(s), then Proposal N needs 1,000,000 votes.

[nonfungibleab]

If too many applications are received in a short period of time. xGovs can elect to close applications, in order to be able to handle the volume appropriately.

[nonfungibleab]

Funding above 10,000 ALGO will require a milestone-based fund release plan.

[nonfungibleab]

Funding above 10,000 ALGO will require a milestone-based fund release plan.

[ShaperOfEntropy]

Having gone through all the finalized proposals of period 1, I find there need to be more targeted guidelines on what should be included in a proposal.

My suggestions:

• Please include references to all claims made (about teams qualifications, previous projects you worked on, any referenced statistics, etc.). This will simplify the work for xGovs, easing the process of verification, and thus increasing the chance of getting the needed votes.
• When describing deliverables for the milestone for which you are requesting the funding in the proposal, please keep in mind that xGovs will need to be able to (easily) verify your deliverables to sign-off on the last payment. To mitigate potential conflicts, define in as much detail as possible what the deliverables will actually be. The more information you provide, the better. Some examples:
  • The milestone is to build a smart contract and an app, and get it to testnet. Describe how the interface will look like, e.g. CLI, basic UI or fully styled UI with multi-wallet connectivity (providing any mock-ups is another plus), and what interactions will the users be able to do and any limitations (e.g. initially pay only with ALGO for a service and not ASAs).
  • The milestone is to build a community. Provide metrics you would consider the milestone sufficiently fulfilled, e.g. have X followers on Twitter/Instagram/Youtube, Y members on Discord where phone number verification is required to prove that members are human, or have Z posts over N days on Reddit with accounts older than M days.
  • The milestone is to audit a smart contract. Write where the results of the audit will be published, by which companies it will be done, etc.
• It is beneficial to address and reference the existing competition for your product. What are their limitations and why are you better? If you are bringing an existing solution from another chain to Algorand, include how used those are.
• What are your plans for long-term maintenance and sustainability of your product? Do you have a plan to monetize it or is it expected to become fully community driven?
• Who is the target user of your product and what's your general approach to reach them? E.g. if the product is a tool to ease creation of NFTs for creators, you have approached creators who would like to use it and spread it by word-of-mouth in the NFT community.
• When requesting larger amounts, please consider publicly doxxing. This should increase xGovs confidence in your good intentions due to increased accountability.
• Consider addressing how will the grant funds be spent. For example: X ALGO will be dedicated to covering transaction fees and opt-in costs for easier on boarding of new users, Y ALGO will be used to participate in consensus on a node run by the project to increase the reliability of your services by submitting your own transactions and blocks, Z ALGO will be sold on DEXs to pay for operational costs, N ALGO will be used as direct developer rewards vested over a period of half a year, M ALGO will be put in project treasury, K ALGO will be used for token buyback, L ALGO will be used as collateral for a loan, or anything else.
• If you have any video pitches or deck slides, include a link to them!
• Be pro-active in convincing xGovs to vote for your proposal. Engage on platforms like Algorand Forum, Algorand Discord, official Algorand Reddit or community-driven sub specifically for xGovs, and Twitter, where many community-driven spaces discuss xGov proposals.

Providing these information will ease the work of xGovs and minimize amount of spam/low-quality proposals.
I think this is crucial because if e.g. an xGov spends just 2 min on a spam/low-quality proposal, at 4.8k xGovs, this amounts to one full month of man-hours wasted for the community for each spam proposal.
I think the current implied ethos of the xGov program should change from "projects submit proposals and xGovs need to figure out which are worth supporting" to "projects submit proposals and convince xGovs to support them".