@Yeti this is a smart idea, but it could lead to issues down the line.
Your idea assumes that accounting is still done in CKB, so nothing should really change from the Community DAO accounting perspective, but this actually does not hold true for corner cases.
Let’s assume the following scenario happens:
- Project asks for 30k USDC, so 3 milestones or more.
- Community DAO approve funding for project.
- Community DAO (informally) exchanges the approved CKB for USDC.
- Project is not able to progress, so its development is abandoned.
There are a couple issues:
- The conversion rate expressed in the proposal is never gonna be the same as the one in step 3 for two reasons: voting takes a relatively long time and CKB price moves fast, see recent Upbit listing.
- At step 4 Community DAO now has both CKB and USDC funds, differently from the initial assumption that nothing would change in the Community DAO accounting.
An Alternative Funding System
While replying to @jm9k, I realized that actually there is an easy way to offset CKB volatility without messing up the Community DAO funding logic.
Funding Expenditure
Project expresses intended expenditure as a single asset or as a mix of multiple assets.
For example, a project baked by a Chinese team for a bridge between Ethereum and Nervos L1 could express its funding expenditure as a mix of CNY, CKB and ETH.
For example, just throwing some numbers around it could be:
- 700k CNY (~ 100k USD)
- 120k CKB
- 2 ETH
CKB Allocation Request
Project requires the current value in CKB of the Funding Expenditure multiplied by a certain safe-multiplier SM, which up to the project, based on expected timelines and perceived volatility risks.
The idea is that, even if CKB price plummets, the project has the necessary funding for reaching its goal.
For example:
Value(700k CNY + 120k CKB + 2 ETH) = 7.2M CKB
SM = 0.01465/0.00677 = 2.2
(Today CKB price divided by the three months low)AllocationRequest = 2.2 * 7.2M CKB = 16M CKB
Voting
As usual voting happens on the CKB Allocation Request, but with the added clause that the extracted value must not be in excess of Funding Expenditure.
A successful vote sets apart Allocation Request CKB from Community DAO fund to be used by the project, so it’s a form of funding guarantee.
Milestones
Milestones are defined with goals to reach and request of assets. Payments happen always and only in CKB.
For example:
- Milestone: Project deploys on testnet.
- Requested assets: 350k CNY (~50k USD)
- Payments could happen in blocks of 100k CKB
- Value(350k CNY) = 3380499 CKB
- Community DAO sends 3.4M CKB to the project.
- Project extracts 350k CNY of value.
- Project documents final conversion rate incurred (inclusive of fees, possibly capped at 6%), involved amounts and excess of CKB (received but not spent).
- Committee double check conversion rates: if the conversion rates are reasonable, no proof is necessary. Then again this is a trust based system, so if any member of the Community DAO committee feels this trust has been violated by a project, the committee has the authority to challenge conversion rates and hold further payments until an agreement is reached.
Project Completion
At project completion any excess of CKB balance held by the project is refunded back to the Community DAO.
Remaining CKB Allocation Request is released back to Community DAO, now free to be requested by other projects.
Considerations
All in all I don’t see too many drawbacks in this additional funding system. It involves slightly more accounting by both parties, but not so much that makes it impractical.
I don’t believe a voting is required for these rules as:
- It offer an additional funding system, it is not meant to replace the previous one and the projects can opt-in to it.
- Community DAO could implement this with an informal agreement, as suggested previously by @Yeti.
- Allocation Requests are always expressed in CKB and they cannot be exceeded by the project without going thru an additional Community DAO funding round.
What are your thoughts on this?