And now I’ll put my governance hat on…
While I’m excited to see the external contributors agree to the standard development process, I don’t feel we’re aligned yet on what is appropriate for governance or, more precisely, the specifics of the grant mechanism. As with previous misalignments, I don’t blame anyone for this, rather it’s a result of us being in uncharted territory.
I have some very specific feedback that would apply to any proposal that seeks to adopt this approach to their grant:
- If we’re calling this a retroactive funding proposal, this shouldn’t go to a vote until the work is complete and the DAO can assess the real impact. Publishing a retroactive funding proposal in advance of completing the work is bad practice because it just leads to speculation and disagreement about the fair value of a contribution, as we’ve seen here.
- If you’re going to include a cliff/vest, there should be clearly defined terms of termination, e.g. in the case that the work is not delivered. You’re promising future contributions, such as “commitment to support” and delivering “technical talks” and “design documents”. What are the accountability mechanisms for these promises? Does support include an SLA? Should failure to deliver on these promises void the cliff/vest? If you or the DAO do not feel comfortable with the can of worms that this opens, or with answering how a dispute over terminating the cliff/vest would be resolved, then we either should remove the cliff/vest and any deliverables that have yet to be delivered, or we should make this a true retroactive funding proposal and not vote until all deliverables are complete.
- If we’re using a cliff/vest, considering how volatile the token can be, it makes no sense to denominate the grant upfront in $USD, a practice typically reserved for situations where the contributor has specific development costs they plan to cover (as was the case with Poktfund’s latest mobile wallet proposal). $2M at today’s prices could become $200k ($0.015) or $20M ($1.50) at any time during the vest. Considering we’re at an all-time low price for the token in public markets, it’s more likely to be the latter. If asking for a $USD budget and applying a vest, the tokens to be disbursed should be calculated at the time of each vest, not upfront. If you believe enough in the future fair value of POKT such that the previous treatment sounds unattractive, you should just ask for a POKT-denominated grant.
- The DAO should not be staking tokens on behalf of grant recipients. This is not a can of worms I feel comfortable opening.
With the above critiques in mind, I would recommend the following next steps for your proposal:
- Rescind the current proposal and focus on delivering your external contribution according to the standard development process laid out by the Core Dev Team.
- If/when the light client has been approved by the Core Dev Team and released on mainnet, submit a new PEP.
- The new PEP should be budgeted in one of 2 ways:
- USD-denominated, with vesting amounts calculated using the price at the time of the payment, not upfront,
- POKT-denominated, with a fixed amount upfront that unlocks over time, independent of POKT price.
- The new PEP should be budgeted in one of 2 ways: