After some confusion and politicking around paying contributors who submitted late reports, it is time to clarify the way the grant payment process works and determine who is responsible to do what. The existing guidelines were ratified in YIP-100, but should be re-evaluated based on the new work done in designing and implementing the Re-Org and the Gov-Ops council.

Overview

The new compensation model developed in the Re-Org has 2 main parts. The application part and the payment part. In the application part, a contributor will apply for funding with specific deliverables and milestones that they aim to meet. These could be further broken down into monthly progress updates where a portion of the compensation is paid out after work has been open sourced, documented, and reviewed by token holders.

At the most basic, a contributor says what they plan to do and then at the end of the month they describe and show what they did in a compensation request post. If the work is finished, great! If not, they can describe what caused the slow-down and how they will move forward given the issues.

Once the post is up, token holders (or some delegated party) should determine if payment is warranted. As described here, this model is “optimistic” so it requires someone to dispute the payment request within a certain time period, otherwise it will be paid by default. If the request is not disputed then it will be added to the next on-chain proposal.

Parties

There are 3 main parties involved in this process: Contributors (grant recipients), token holders, and governance facilitators (Gov-Ops members).

Contributors

This role was described in the overview. They are responsible for doing the work promised and submitting a compensation request for the work done. The timings required are determined by the gov-ops council and token holders.

Token Holders

Token holders need to be aware of what scope contributors have promised and check to see whether the work done matches that scope. Any token holder can dispute a compensation request, pushing it to a vote. Token holders are also responsible for making sure that the initial scopes of work that contributors submit are reasonable and well defined so that they can be effectively reviewed when compensation is requested.

Gov-Ops

Gov-Ops is responsible for putting together an on-chain transaction based on approved, undisputed compensation requests. They are ultimately responsible for setting the deadlines for contributor reports since they control the timing of the actual payments. It is not Gov-Ops’ role to determine if a contributor should get paid outside of the defined rules for posting reports.

<aside> ❗ Gov-Ops members can dispute and vote on a contributor compensation request just like any other token holder if they think it is lacking or incorrect.

</aside>

Timings and Deadlines

In order for this system to run smoothly, all parties much know the rules and abide by them. We can set up a number of checks and balances to keep different actors honest. There are a few critical requirements for different deadlines.

  1. There must be enough time for contributors to submit compensation reports for the work they have done.
  2. There must be sufficient time for token holders to review a compensation request and determine whether it should be disputed or not.
  3. There must be sufficient time for token holders and contributors to review on-chain transactions proposed by Gov-Ops.
  4. All participants should generally understand the schedule and timing of events. Keeping this consistent on a month by month basis means that less active voters can schedule around it.
  5. On-chain transactions should be written to minimize voting disputes.

Lets put this all together and sketch out a rough timeline.

Compensation Timeline - Option 1

The timeline above shows:

Disputes

This schedule gives token holders 3 days, after the cutoff to submit compensation reports, to submit disputes of the work or documentation. Contributors who submit their compensation reports sooner will have more time to review and correct any issues that may be disputed. If reports are disputed shortly after the cutoff date then there should be time to vote on the dispute before finalizing the on-chain proposal.

Disputes should be formalized by posting the rationale for the dispute on the compensation request forum post, creating a snapshot vote, and posting about it on the discord.

Disputed transactions should only be removed from an on-chain transaction if quorum is reached and the final outcome of the vote is to not pay (not paying is the “for” vote). This means token holders can work with the contributor to correct their report during the voting period and abstain from voting if they feel the changes are satisfactory.

This way of organizing disputes allows them to be used as a way to enforce the norms of the governance system while giving the contributor time to fix issues or plead their case.

Conclusions

Creating a flexible system that is clear, legible, and fair is an incredibly important, but tricky dance between different parties. The system above provides a system based not on set dates, but defined windows needed to perform certain tasks. It is a framework of relative deadlines that can be used to maintain accountability while leaving some flexibility when needed.

Contributors are responsible for submitting reports on time and have clear expectations for when that needs to be, with a final reminder once the draft proposal is presented. The Gov-Ops council (specifically those who write the on-chain code) are responsible for keeping the schedule and including or removing contributors. The Gov-Ops contributors have leeway to make adjustments or variations if they see fit, but they are ultimately responsible to token holders.

Token holders can be confident that their review of contributor compensation requests and on-chain transactions should be reviewable on between the 6th and 8th, but can wait for the on-chain draft proposal to be sure.

If this is a model that contributors and token holders feel comfortable then it should be written into all new grant applications as part of the “contract” and followed as closely as possible going forward.


Comments and an Alternate Timeframe

Initial comments from Designer and Chilly focused on 2 points that are worth thinking about.

The first is whether there is enough time in the above schedule for disputes to be flagged and carried out. This carries over to the other sections and begs the question: how much time is enough time?

The second comment revolves around consistency for voters and contributors to know and schedule their activities on a month to month basis. Can we make it so that votes will always occur on particular days of the month so voters know when they need to participate?

After discussion of these issues with Designer, he proposed a solution that solves both concerns by changing the assumption that everything needs to happen quickly. The proposal is to use the full month in which compensation requests are filed as a review period. On chain transactions could then always be submitted on the 1st of the month and would include payouts requested in the prior month.

Compensation Timeline - Option 2

This change gives voters a much larger window to review, discuss, and potentially dispute compensation requests. This could be further formalized into 3 phases: A 1 week Compensation Request Phase, a 2 week Review Phase, and a 1 week dispute voting phase, and a day or 2 at the end of the month to update the on-chain proposal (this should be trivial, essentially uncommenting or deleting some lines of code).

The trade-off here is that Grant Recipient payments are slightly delayed compared to the other model. For regular contributors this shouldn’t be a problem as the cadence is still continuous and the only delay happens at the first payment. For intermittent contributors there would be a delay at every non-contiguous work event.

If we are really leaning into the grant recipients are contractors argument (which I agree with) then a 1 month delay on payment is not out of the ordinary. Typical contract employees submit invoices with a 30 day to pay window and often have to wait significantly longer than that to actually receive payment. Is it ideal? No, but it isn’t terrible, especially if it is done consistently and effectively.

My personal opinion is that this longer timeframe option is preferable and makes the system easier to understand and participate in for all users.