I’m trying to figure out the value of “Bounties” for managing the treasury.
This comes from our experience managing Bounty 12 where the market value of KSM dropped 53% from inception to closure.
imo bounties are the best way to manage the treasury if there are stable assets.
Bounties protect against the risk of spend proposers running away with the funds or disappearing.
But until there are stable assets in the treasury I don’t yet understand how this oversight (without the ability to manage funds) is in the best interest of tokenholders (for projects that have demonstrated trustworthiness).
In practice, a bounty in a down market means the value of the requested amount can drop without possible intervention leading to further drawing on the treasury for a “top up” and further governance overhead for the project. This is a loss for tokenholders re: treasury and manpower.
In an up market, it would tie assets up from other projects. This is also a loss.
These risks imo are greater than the risk of a proposer running away (which risk can also be mitigated by PoW or Multi-sigs with trusted individuals).
Bounties make sense to me personally now only for projects over very long time horizons with very big asks.
Bounties will make all the sense in the world when there are stable assets in the treasury.
Do you have a different opinion? Why?
Just to clarify, I am PRO bounties. But my current position is they’re not ready yet. My current understanding is: until stable assets, they hurt token holders.
What should a bounty be used for? In my opinion, it should be used for any treasury funded program where 2 or more recipients are working independently with a payment for milestones or payment for services rendered structure. In either case of payment for personal or individual milestones or payment of services where funds are provided by treasury, these programs should be open to anyone where the member has no conflict of interest.
Using the bounty structure will allow the proponent to create structures that would hopefully outlast their participation in the program. Many people say that enterprise should come to polkadot, what they fail to realize is that polkadot is enterprise. Any formal business structures that are currently used can be recreated on-chain allowing individuals to come together to operate business services and systems. Instead of going outside of the existing bounty structures we should be working to fix the problems we experience with the existing ones. The power of polkadot is the power to iterate. We should focus conversation on ways to minimalize or reduce downside impact for bounty structures and figure out 1 or more mechanisms that allow latitude people are interested in having for their program designs. There are multiple ways problems can be solved and it’s possible to implement more than 1 of them so curators and proponents have options in how they can structure their programs.
Upsides of a bounty:
Creates a program that should or does clearly state who can join and what the criteria are for joining. This allows people to see that the program exists and join if they meet the criteria. With treasury funded group programs, we should be thinking about inclusion.
Administrative curation team that is impartial to the reward recipients that manage the program. This is crucial for the success of any program. These should be individuals that can generate reports about the status, successes, failures and state of the program.
Keeps funds in treasury - Bounties that are funded have their funds locked in the treasury and the bounty child mechanism for payments allows reports to be filed on chain using ipfs so that anyone can audit a program’s payments and related information.
Lasting power - A proponent of a bounty should be looking and interested in creating a system that can outlast them. Systems where multiple people are coming together to fill a task should be bounties and these systems and programs should be designed to operate forever, or until they become irrelevant.
Downsides of a bounty:
Basically, the only downside is price fluctuation (or at least the only one people talk about) of the underlying asset in respect to both the total value of the bounty as well as payments to members.
Are there any other upsides or downsides I’ve missed?
The risk is still kind of on token holders though, is it not? The lack of accountability, oversight, management, etc on ad-hoc managed bounty structures puts the same or more risk (imo) on token holders.
There is no strict requirement of bounty needs to payout in full amount. Curator can create a sub bounty and payout a right portion and refund the rest to treasury. In case DOT price dropped too much, we can also make another treasury spend proposal to top up bounty amount.
This is the problem I’m grappling with. A “top up” bounty proposal draws additional funds from the treasury. Where as a spend proposal can manage funds from the beginning and avoid withdrawing more assets.
Not sure what do you mean. Let me give an example.
Say we created a bounty for 100 DOT to do some work.
After 3 months, the work is completed and for various reasons, the reasonable payment amount will be 50 DOT instead of 100 DOT. Then the bounty curator can make a payout of 50 DOT and refund the remaining 50 DOT back to treasury.
If the bounty scope changed during the development and the expected payment amount increased from 100 DOT to 200 DOT, then a treasury spend proposal could be used to top up the bounty from 100 DOT to 200 DOT. However, the actual payout could only be 180 DOT instead of 200 DOT.
The bounty amount is really just an up to amount. It is then the curator to decide the actual payout amount.
The broad benefit of bounties is to ‘draw a line in the sand’ and signal intention for certain work to be done. Bounties, when done correctly, can serve as a beacon to draw contributors in a more directed way than an opaque pot of money.
One way of managing the risk of price fluctuations is to create a larger bounty to what could be a fair amount to cover the risk of price going down. Then as @xlc mentioned the curators can amend the bounty at the payout time if needed. It can indeed cause some overspending for the treasury but the spend proposal you are suggesting could cause a larger waste.
I gotta say, I disagree with you on bounties for managing the treasury. I mean, I get where you’re coming from with the whole stable assets thing, but I think bounties are still a valuable tool even without them.
First of all, let’s talk about the risks you mentioned. Yeah, there’s a risk that the value of the requested amount can drop in a down market, but that’s just the nature of the game. The market is volatile, and there’s always going to be risk involved. And sure, bounties tie up assets from other projects in an up market, but that’s just part of prioritizing which projects are most important at any given time.
But the thing is, bounties are still useful even with these risks. They protect against the risk of spend proposers running away with the funds or disappearing, which is a real concern. And while you mentioned that this risk can be mitigated by PoW or Multi-sigs with trusted individuals, that’s not foolproof either. There’s always a chance that something could go wrong, and bounties provide an additional layer of security.
Plus, bounties can incentivize the community to contribute to the ecosystem and help it grow. This is important for the long-term health of the project, and it’s not something that can be achieved through other means like PoW or Multi-sigs.
Now, I know you said that bounties make sense for projects over very long time horizons with very big asks, but I think they can be useful for smaller asks too. Every little bit counts, and even small contributions can add up over time.
So yeah, I’m a big believer in bounties for managing the treasury. They’re not a perfect solution, but they’re still a valuable tool that can help secure the ecosystem and incentivize community participation. And while stable assets would certainly make things easier, I don’t think they’re necessary for bounties to be effective.