One more thought: Companies looking for top have to pay more to compete in the free-market, and the Pocket DAO has more than enough budget to be competitive with those taking a risk.
Some notable risks that must be accounted for when working for a DAO:
Paid in a volatile currency that change dramatically week to week. The amount you walk home with is always different month to month (especially with Coordinate where it’s design to have varying pay month to month depend on your standing with your peers)
Work is mostly on public display in some fashion. That is not the case with most other jobs where you work for company. This means you have to stake your public image on your job… which is on the internet forever.
Regulatory concerns since DAOs are not recognized companies and the crypto scene changes rapidly.
You do not have employee protection contracts or guarantees. You honestly never know what’s going to happen month to month.
There is a significant administrative overhead with orchestrating and managing your own benefits and accounting.
By nature, DAOs are less organized lending to more chaotic/drama infused work environment.
That is a start. I’ve worked for a DAO and have had to deal with these risks in real life. I’m sure there are more, but this is a Sunday
Because of these differences between working for a DAO and working for a traditional company, all quality DAO work should come with a competitive premium considering these inherent risks.
This really addresses some of the things I was pointing out as concerns in my earlier comments; with the current DAO proposal system, a 100K pokt budget is possible given DAO approval, but that’s definitely not the case with Coordinape, or at least, not in some obvious fashion. Increasing the pokt rewards in each epoch still doesn’t account for the vast disparity in the possible value of contributions.
One of the responses earlier was that DAO proposals remain an option, and if the UCI model is intended primarily for hobbyists, and the expectation is that full time projects will still make DAO proposals and seek approval, that seems like an acceptable way to delineate between the two.
However, if Coordinape becomes the default mechanism and all contributors are generally expected to use that system, it would run into the limits @shane describes (and yes, I intend to make a proposal myself once I make The Poktopus a full time role after the first of the year). We have a number of high caliber professionals in the community now working on larger projects with the ethos of “build it before you propose it”, so we need to maintain an easy route for them to seek and receive funding.
Providing clarification on the limits of Coordinape, and the continuation of the proposal model still satisfies my concerns here.
Stabilizing value will happen by the contributors. I’m personally not worried about that. What I’m worried about is having such a tiny pool of resources.
We quickly went from the idea of “let’s put good resources towards this and really encourage growth” to something that is targeted towards hobbyists and is not ideal for professionals.
The perfect example: A rising tide lifts all boats… unless the water is to shallow already for most boats… and especially shallow for large quality boats If we set the tide where only only small boats can participate, then we will have the contributors only be part-time hobbyists.
I just want us to be clear with who we are targeting. If we want top quality contributors we need to have more resources to start with. Quality professionals are going to be attracted to salaries better than the competition.
How have other Coordinape projects started? I suspect everyone has dealt with initial funding. I’d be curious what their experiences were.
At Pooltogether we’ve just started using KPI options for coordinape payments as well as to pay out grant recipients if they choose. We chose to do ours based on TVL for the protocol and do a 6 month time frame. It’s a good route to reward long term contributors and I don’t find it to be overly complicated. This is our first batch and we hope to make adjustments as we go and may be able to use it in other areas. We had an infographic made to show community members how ours work. Everybody seems very happy with them so far and it actually seems to be the perfect use case for them.
The purpose of our UCI is to provide our contributors with a stable income. Making them wait 6 months to redeem their rewards does the opposite.
We also already have revenue tied to our key KPI; by the design of Pocket’s protocol, block rewards are minted proportional to the number of relays coming through the network, and if our UCI is a % of this, this means monthly payments are going to be larger the more relays are coming through.
Clarifying question: does the token that is redeemed from the KPI Option need to be an ERC-20? How does that redemption work?
That is just the time frame we chose for our first batch and I’m thinking we may reduce to 3 months in the next batch. The time period could be set to whatever you choose but I can see how it would not be ideal for those using it as income and looking to sell the tokens right away. I do think it aligns incentives though for those who are committed to the long term growth of the protocol.
The KPI options would need to be ERC-20. The Pooltogether options are on Polygon to avoid the gas. For redemption you can go to the UI after the redemption date and redeem your tokens to unlock underlying collateral tokens. There would be a balance returned to treasury assuming the options did not reach the max payout.
While you can’t use the KPI for the fixed stable income but for incentives, it might be an option worth considering. It can help to align incentives based on the long or short term goals.
If we set the tide where only only small boats can participate, then we will have the contributors only be part-time hobbyists.