All right, I’m excited to share some further thoughts.
Reminder on how I think this discussion should go:
Step one is airing the concerns. Check 
Step two is discussing the concerns. Check
Step three is discussing potential courses of action. In progress 
Step four is baking overall proposals until one “passes.” As I noted above: Once we have a working menu of live options, we can bake overall proposals. This is what James came out and did to start this conversation, but we need to take more stock of concerns and potential courses of action before we’re really ready to bake something real. In congress, bills get introduced symbolically to start a discussion all the time, and while they don’t pass in their initial form, they can lead to other bills later that make big things happen. I see James’s proposal as a symbolic bill that ignited a useful discussion. It’s not yet the true one big beautiful bill to make RSR great again, but it raises the question of what that ought to be.
Let’s have some video calls
In order to have a higher bandwidth conversation, develop and move these ideas faster, and get to a solution faster, let’s try doing some face-to-face calls.
If you are an active contributor to this thread or have something that you want to say but don’t want to write it down, join this first call and participate in the discussion. I would ask that everybody who joins the call plans to have their camera on and actively participate in the discussion, as having people lurking in a call like this will be a detraction from open communication and collaboration. No lurkers.
Here’s a link where you can put in your availability for three days next week so that we can pick a day and time that works the best for people who are actively following this thread:
(timeful tutorial here: https://www.youtube.com/watch?v=vFkBC8BrkOk)
More detail on RSR allocation for 2025
I shared these further numbers on RSR usage for 2025 in the community call this morning and I wanted to include them here for anyone who didn’t make it to that:
We’re pausing unlockings while we participate in this discussion
As you can see, we unlocked way more RSR than we actually allocated on net. As a result, there’s no pressing need for additional RSR unlocks right now.
I had preferred to have a deterministic unlocking schedule for the sake of clarity and certainty, but my sense is that the important promise we made was to never unlock any faster than the pre-determined Bitcoin curve. For now, we will pause unlocks. If we don’t end up changing the emission schedule, then at some point we’ll just start them again on the same pre-determined schedule, but with a delay in time. There won’t be any unlocks that go faster in order to catch up; rather, there will just be a gap in time where no unlocking happened, and then unlocks will pick up along the same schedule as was determined before but on a later date. However, one purpose of this discussion is to consider whether there’s some better way to proceed, and as I’ve shown in my post above, I have an open mind about that.
Here are some ideas of mine for what might make sense:
Comparison to startup fundraising for inspiration
In a startup company, new shares are issued when it’s time to raise funds. Everybody gets diluted, but at the same time, if things are going well, the valuation of the shares has gone up, and so everyone is happy and willing to be diluted. The company has to prove that it has made progress and that its future looks bright in order to issue and sell those additional shares and in order for investors to be willing to buy them. This holds the company’s management accountable to making progress in order to unlock the ability to cause dilution and bring in further capitalization.
One thing to note here is that startup company valuations are only measured when funding rounds happen. There is no liquid secondary market for their shares. This provides a nice clean upward trajectory in valuation, though it does have the downside of no liquidity. Narratively, though, this makes it easier to stomach dilution because you don’t really see any volatility in valuation when investors are only taking a look every year or two and the valuation at each fundraise continues to go up. In our case, we’re not talking about shares in a company; we’re talking about a crypto token that’s traded on open markets, so as we’ll see in a minute, the analogy is not perfect.
Sometimes companies need to raise more capital even when things have not gone well. When you do a fundraise at a lower valuation than prior funding rounds, that’s called a down round, and nobody likes it because it means you have to take dilution and you have to stomach a lower valuation at the same time. Sometimes it’s the right thing to do; maybe progress didn’t go as well as planned, but the prospects overall still look promising, and so it’s worth raising further capital and continuing, as opposed to giving up and letting everything go to zero.
In this forum thread, people have talked a lot about emissions not being tied to progress, and for me it was clarifying to think about this analogy, since startup companies do tend to follow a pattern more like what some are calling for.
Let’s look at how this could apply to RSR:
In theory, we could do something similar for Reserve and RSR. What if RSR was only unlocked when we proved some degree of progress and some additional need for further capital?
In thinking this idea through, though, there’s an obvious difference that needs to be taken into account, which is that there are no venture capitalists involved to make a judgment about whether progress has been satisfactory. Instead, I would assume that we would rely on the RSR holders themselves. If we’re talking about a decentralized body of thousands of token holders, we can’t expect them to do the job that lifetime professional investors would do. We’ve seen lots of limitations of DAO governance play out throughout DeFi’s history already so far.
The method that comes to my mind for how to address this would be to hash out and agree on in advance a series of pre-defined milestones so we could come to basic agreement on the trajectory we want the project to traverse, then rely on the RSR holders only to vote yes or no on whether a given milestone has been reached, as opposed to having a fully open debate every single time about whether it’s appropriate to do a further unlocking.
It’s tempting to think that maybe everything could be programmed deterministically on chain to happen in response to certain onchain numeric metrics, but realistically I don’t think that would end up being feasible. Even something as simple as TVL of index DTFs is not automatically available on chain, because the index protocol is specifically designed not to need oracle price feeds. The protocol itself doesn’t know its own TVL in dollar terms by default. I also think milestones we care about would likely end up referring to more nuanced features of the situation than something as simple and potentially gameable as TVL.
If we could figure out good milestones in advance (easier said than done!), it could be really nice to have emissions only occur when progress has happened.
Potential issues
As I called out above, market price for RSR is volatile, unlike illiquid startup company shares. It very well could be that the price at one milestone in unlocking would be lower than in the past, even if positive progress has occurred and the project is arguably more advanced and more valuable. So you don’t quite get the same “it’s fine to be diluted because the pie is worth more overall” property.
There also could be situations where progress doesn’t go as well as we would hope, and RSR that had been unlocked is consumed. If that happened, we would need to have some ability to do something similar to a down round, where RSR holders would have the option, perhaps through a supermajority vote or something, to approve the release of additional RSR even though a milestone hasn’t been hit, if they deem that that is the best way forward. In a circumstance like that I would think that the RSR unlocked would be deducted proportionally from all future tranches that would have been attached to future milestones. Basically: spending capital that was earmarked for the future in the present. That’s something that everyone would want to avoid but would need to be able to agree to do if it was deemed appropriate.
What about burning?
Some proposals in this thread suggested that, in response to progress on the project, we burn RSR from the treasury. At first, I found this very counter-intuitive. As I said before, any burning, from my perspective, needs to be permanent, as opposed to burning RSR but also giving ourselves the ability to mint further RSR in the future. That just adds further uncertainty, kicks the can down the road, and I believe is going to cause massive FUD for projects that go that direction.
If RSR that’s burned is permanently burned, when is it appropriate to do so? Maybe the answer really is in response to progress. If we were to burn predetermined amounts over time in response to progress and we knew that we were going to burn it for sure right now, why wouldn’t we just burn it right now? The whole reason why I’m generally wary of burning RSR right now is that we don’t know how much we’ll need over the course of time to do what we need to do.
So what about this: what if every time we hit a milestone, we burn RSR if and only if there’s some left over from the last unlocking (i.e., we came in under budget)? Let’s say there’s, to pick a simple number, 3 billion RSR that’s unlocked to get to the next milestone. When you get to the next milestone, let’s say there’s still 500 million RSR left. Because we got to the next milestone, we’re unlocking some further amount (say, another 3 billion). Rather than keeping that extra 500 million RSR around, maybe this is the time where we’ve learned, “okay, we didn’t need that,” so some of it could be burned. A reward to all of us for reaching a goal and proving we didn’t need more effort to get there.
But here’s a twist. In order to fully align the incentives of founders, like me, and community members who want RSR to be burned, what if instead of burning 100% of that RSR, half of it is burned and half of it is distributed as compensation to the founders? This incentivizes the founders, who are arguably very involved and able to take steps to reach milestones more efficiently, to be as efficient as possible, and to increase the excess RSR and thus drive up the burn number. We could even take it so far as having such founders, like myself, only receive any further RSR through this mechanism, no other RSR compensation, such that if milestones were not reached under budget, no RSR comp accrues to them at all. I had this idea because I’ve been puzzled about how to compensate myself. If things go really well and Reserve does awesomely, I feel like I deserve to be compensated well. If Reserve does poorly, I don’t really feel like I deserve more upside, and this is a mechanism that could get at that pretty elegantly.
This founder reward pool could be applied to people other than me down the line as well. But for now, I can only speak for myself in saying that I would be open to foregoing all other RSR compensation with a high risk, high accountability, high potential reward arrangement like this.
This also clearly aligns incentives for avoiding a “down round” situation because if that happens, the RSR that’s available for all future milestone tranches gets eaten into. That reduces the likelihood that when future milestones are hit, there will be excess left over, which reduces the amount that’s burned but also reduces the amount that goes to a founder reward. Thus, everyone would be incentivized to cooperate on using resources efficiently.
Further details
If we went this direction, there would, of course, be further details to work out, chief among them being:
-
What the milestones would be (again, easier said than done, though trying and failing could still produce useful planning and goal alignment for the project)
-
How much RSR would be allocated for each one
There’s also the question of who receives the RSR when it’s unlocked. Presently, the locked RSR is the property of Confusion Capital. There could be a mechanism where, by default, it would continue to unlock and be allocated by Confusion Capital, but RSR holders would have some ability to vote to change that if they decided to.
What about selling impact?
Even with a system like this I expect there would still be fear around the moments where RSR got unlocked. Even if milestones had been reached and things were going well, if a huge chunk of RSR were unlocked at once maybe that would be seen as problematic.
There could perhaps be some rate limiting mechanism for how quickly the RSR could be withdrawn, similar to what we’ve done in the past with the Slow and Slower Wallets. There could in theory be some commitment in place by Confusion Capital or whoever the recipient of the unlocking RSR is not to sell that RSR for less than a certain price, say 0.01 or maybe in the future as the milestones progress, some rising schedule of prices.
And there’s ongoing concern about when and if team members are selling their RSR. This would apply to any founder reward as well… I’m sure many would be worried about what would happen to it once unlocked. One possible idea there that’s occurred to me is: what if team members were compensated not with RSR tokens directly but with options to purchase RSR tokens at a certain price, say again 0.01 or maybe some higher set of prices over time. That way you wouldn’t know exactly when people would sell. But you would know that they would have no reason or a way to sell for less than some price that perhaps we as a community would determine is a reasonable level or valuation for the project overall.
These ideas obviously come with downsides, and I don’t really feel at all confident in saying that I think we should go these directions. In particular, team compensation in options rather than directly in tokens would just be less valuable per RSR token to the people receiving it. So we might need to spend more RSR tokens per team member for the same level of compensation incentive, and thus, we might just be less efficient in allocating that resource. Similarly, if the project treasury could only sell above a certain price. That restricts its ability to capitalize and fund project operations. And so we could be forced to stop operating for long periods of time if prices are low.
This also calls to mind another issue with the milestone approach overall: let’s say a bull market is in full swing, but a milestone hasn’t been reached, so no further RSR is getting unlocked. Five months after the end of the bull market, the milestone is finally reached and RSR gets unlocked. Well, now prices are low and it doesn’t seem like a reasonable time to sell and capitalize. This is in contrast to how we currently approach treasury operations: buying when prices are low and selling when markets are healthy and prices are high. As you may begin to see from our published numbers, this has produced a responsible pattern of buying and selling, and we may get less of that discretionary benefit if we lock ourselves in to only being able to unlock and sell RSR at certain points in the project which would likely be disconnected from crypto market cycles.
Let’s discuss
Let me know what you think about these different directions, or what ideas this sparks for you. I will, of course, spend some time in the upcoming call next week, discussing these directions along with others that people bring. Even if there’s an idea that it seems like I’ve passed over based on the views I shared in my prior post, if it’s something that you still think makes sense and you think I’m not getting it, I do invite you to bring it back up and try to explain what I seem to be missing.
On the one hand, as I said this morning on the community call, our number one priority needs to be getting product-market fit for DTFs so we can’t take too much time away from that core activity for this RSR health discussion and for thinking about emissions. On the other hand, these are core features of our ecosystem and we need to get them right and we need to approach them in ways that take into account our plurality of perspectives. So I’ll be proceeding with the goal of making my interactions and work on this topic time-efficient but not rushing the timeline on the calendar to finalize what we’re going to do here, in order to make sure there’s ample space to work through the relevant discussions.
Looking forward to talking to some of you next week and reading responses here from others.
A note on composing these posts
I’m using an app called Wispr Flow to compose my posts here. It’s a voice transcription tool that does a pretty good job and speeds up the process. I wanted to share that in case others would find it helpful to do the same thing.
I’ve noticed a lot of these posts feel like they were composed using LLMs, and it makes it a little bit difficult to tell which ideas are coming from the person who is posting and which ideas are inserted through the writing process by the LLM’s embedded assumptions. That’s not necessarily a problem, LLMs can be smart and can be good inspiration. But to the extent that LLMs are being used to simplify the writing process, I would just point out voice transcription as another way to efficiently participate in long-form writing with words that come directly from you.