The Treasury value temporarily hit the 750,000 LPT ceiling and reverted the reward cut to 0% as per the mechanism design. The Treasury has stopped accruing.
The recommendation is to restart the cut on the same terms as LIP-101 had previously passed:
treasuryRewardCutRate: 10%
The mechanism and ceiling are unchanged from the previous LIP. I’d welcome further discussion into whether the 750,000 LPT ceiling is the right number, but given it took 6 months to hit that ceiling this feels less urgent than turning on the rate cut again.
Implementation: the Security Committee set treasuryRewardCutRate to the agreed value after the result of the vote. There would be no other parameter changes.
Please share your thoughts on this topic during the open discussion period
While I support turning the treasury reward cut back on to ensure we don’t leave public goods funding stranded, we should use this opportunity to refine the mechanism.
Instead of routing the full 10% strictly to accrua which we just saw hit its ceiling in a mere 6 months we could introduce a burn mechanic directly here. For example, keeping the 10% cut but allocating 9% to the Treasury and 1% to be permanently burned.
This would elegantly tie into the ongoing discussion opened by dob regarding token sinks. It keeps the funding runway clear for the SPEs, slows down how fast we hit the 750k LPT ceiling again, and sends a strong deflationary signal to the market without adding extra costs for node operators or users.
I would like to stop allocating LPT to the treasury.
As delegator, this reduces the amount of LPT that I receive, while is used to fund projects that do not create much value. In the end, it just only creates more selling pressure on LPT.
It is an obvious fact that the projects funded LPT have not led to an increase in the LPT price.
I think it would be better to allocate a portion of actual network fees to the treasury instead. Wouldn’t that make the Foundation and Livepeer Inc. more focused on increasing real network fees than they are now?
Thanks @nhis and @kilout for the thoughtful responses.
@nhis I agree with the instinct but the treasury cut doesn’t change how much LPT is minted. It is redistributing inflation that is happening regardless. Taken to the limit, if 100% of emissions went to the treasury the direct sell pressure would disappear because those tokens would sit locked in the treasury instead of landing with those who do automatic round-by-round selling of rewards. Routing more to the treasury takes emissions off the market and reduces sell pressure, rather than adding to it.
The real driver of token pressure is the gross emission rate, and that’s the unfinished work from last year. If you reduce emissions you reduce the amount of new tokens that can be sold. The treasury cut % doesn’t move that by a single token.
The treasury funds public goods which right now means protocol security and the teams building what the network needs before demand can land. LPT having any price is underwritten by the security of the token, which is even more critical in the current environment of mythos level models being (sometimes) available. I agree on the premise of increasing LPT price through the treasury and I’d argue that to do that the cut should be higher, not lower.. but that’s a conversation for another thread. And you’re right that fees are where maximum alignment lives, and why I strongly agree with the need for a protocol fee.
@kilout I am aligned with the need to increase value flowing back to LPT via the protocol fee. Burning 1% of the treasury cut reduces the net amount of LPT being emitted, so it slows the rate of emissions, but it doesn’t create any natural LPT value capture mechanism. The protocol fee not only makes a direct link between fee creation and capture, but it has the secondary benefit of making recycled fees costly and creating a disincentive to fake demand. If reducing emissions is the goal, the emission parameters are the direct lever, rather than a burn bolted onto the treasury cut.
All of these are critical components to work on, but I think they should be separate from the treasury cut. Dilution needs to be tackled via the emissions parameters, value accrual needs to be locked in via the protocol fee, and funding public goods and go to market demand effort needs to be supported by the shared treasury There is nothing to stop us doing all three.
When price is challenging we tend to bias towards a scarcity mindset. But what is really needed is to increase the velocity of delivery and our efforts in the market, not reduce them. I don’t think there is any way to “thrift" our way to a better market and price dynamic. We can and need to be cost conscious and thoughtful about how funds are used, but also resist falling into zero-sum thinking.
Just wanted to get back to this thread now that things are progressing with Livepeer 2.0. In line with the original recommendation of restarting the treasury reward cut at 10% here are a few more points I would make as to why this is important to address now:
The treasury is currently at 589,000 LPT or approx $695K USD equivalent. This is ok in the short term but there are real unknowns ahead and we should plan for the different scenarios. Optionality is a lot of what a treasury is for.
Livepeer 2.0 has moved from a concept into delivery. The litepaper is due soon (with strong engagement in recent roadmap sessions) and the Agent preview with creators unlocks a more to close beta with some early traction. Behind these lie a pipeline of possible proposals that could touch on network development, go-to-market and significant protocol work.
The costs of action vs inaction and/or getting it wrong here are really not symmetric. If we hold at a 0% treasury cut and 2.0 sees strong traction, new funding might not arrive until a quarter late at the moment when it is needed most. One nightmare scenario of mine would be strong traction but that not converting into LPT price action because BME has been stalled waiting for audits to be funded or for the necessary onchain liquidity to support the burn. Compare this with the cost of action, which is that the cap will kick back in again and naturally reset the cut to 0% if the ceiling is hit.
I’ll bring this for a name and topic at the watercooler this week and if there’s support I’ll run a roadmap session so we can dive into the detail properly. I’m also happy to facilitate further discussion on the target rate itself, as well as settings around the ceiling, and anything else regarding parameters or sequencing that people might want to discuss. See you at the watercooler!
I am in favor of restarting the reward cut for all the reasons given.
Separately, it might be worth considering doubling or even tripling the cap for a few reasons:
The current token price means the Treasury doesn’t go as far as it used to
The Treasury is still ~78% full so if we were to restart the reward cut today, it’d be full again in ~2.5 months, absent any other allocations.
We can build up the Treasury for longer and avoid going back as frequently to ask for a restart.
With a larger pool, we can be more comfortable giving larger allocations to well-established public goods for a longer time frame. Eg, SPEs such as Live Infra probably only need to be funded annually or every 6 months at most, instead of quarterly.
Raising the cap would be a separate proposal of course, but it seems worth considering alongside restarting the cut, given the relatively tight timeline between restarting the reward cut and hitting the cap, especially if 2.0 or other initiatives take a bit longer to get going.
It feels like we have been here and discussing same scenario as previously, possible usage of treasury and possibly just allowing funds to sit idle. This would not be an issue if token price would be higher.
Thinking about it I would be in favour of treasury funds would be concentrated on demand side in form of usage credits on network.
Other thing would be to remove the cap totally but keep constant 3-4 allocation treasury. End of the day someone can make proposal to burn X amount of tokens if needed.
I’m in support of restarting the reward cut following all the reasons listed by @b3nnn. Additionally, we should consider increasing the cap to accommodate the anticipated traction from 2.0.
Hey all, thanks @Pon & @ibs for the additional inputs. We also ran a roadmap session yesterday before the watercooler and here is a quick summary of what the community shared there:
There’s wasn’t really any pushback on restoring the cut. We ask for blockers or reasons to vote no and nothing was shared.
Pressure came more in the other direction, with sentiment that 10% may be too low, particularly with most inflation flowing to passive delegators and, from there, likely outside the ecosystem
The strongest theme on the call was more around spending than the rate. There’s clear appetite to fund go-to-market and demand generation and examples raised included agentic demand bets, a transformer marketplace, customer signal work, provider listings, payment rails for agents. The need for funds to support protocol changes and token and liquidity aligned initiatives like the burn and onchain liquidity was also raised.
The consistent view was that the treasury should be spent continuously to support ecosystem goals and that this has not been used as much as it could to advance network success. We seem to have perhaps overcorrected a little as we build stronger controls and discipline to remove waste
On that basis, I think the outstanding question is whether it makes more sense to **restore at 10%, or go to 20%?
**
At 10% we adopt something the community is already familiar with. At 20%, the treasury replenishes faster to support the type of demand and ecosystem bets listed above, and creates some added pressure and incentive to support builders as the cap/ceiling is approached more quickly.
Please share your thoughts. We will wait for further input and then make a call on how to proceed by early next week. Many thanks
In favour of restarting the cut at 10%. Going higher feels like the wrong lever though the low token price is already squeezing operatorsand this is exactly the moment we’re being asked to migrate to 2.0 and keep capacity available and increase them.
On the ceiling: instead of just doubling or tripling the LPT number, what about revising it every 6 months through governance against a dollar target using a 30 day average price? A fixed LPT cap swings with the token either way too small when the price is down, oversized if it recovers, and we end up back here proposing another change. Revising it periodically gives more predictable funding capacity, and it’s the same approach already used to size the SPE budgets, so it’s nothing new to build.
In favor of restarting the cut at 10% or above. I have no strong opinion on the exact value and would recommend that some modeling be done to determine it, keeping in mind Orch profitability.
I have never been a fan of the cap. I don’t see the value it adds. If the worry is capital sitting idle or being misallocated, those are different problems with different solutions. (I’m also not sure that idle capital is a problem at all, except possibly as an opportunity cost. The worst-case idle capital scenario is that additional tokens are taken out of circulation…and we’re actively discussing BME in parallel.
Meanwhile, the Network Engineering SPE II proposal seeks to address allocation of funds. So all in all, I think proposal is an important part of a well-considered suite that will address ongoing funding as well as allocation.
Aside; I would be in favor of active treasury management instead of pure LPT accrual. The last few years have shown that an LPT-denominated treasury is a risk for sustainable protocol funding. Assets should not be disbursed in LPT either, as it only encourages selling to cover dev costs.
Yes turn it back on, and lets improve the protocol to keep it on… The protocol should keep the cap if we reach it, but upon depletion that lowers it below the cap, it should auto restart the inflow to refill.
There have been some very interesting suggestions around potentially changing the ceiling to a USD value rather than LPT, making the refill automatic, or even removing the cap and introducing some form of burn mechanism if the LPT balance becomes excessive. However, with Livepeer 2.0 on the horizon, the treasury structure may change again. So my thinking is why not just keep things simple for now, and restart the original 10% refill, allowing the treasury to build back up. And any further changes can be discussed and proposed in the near future once we know how Livepeer 2.0 is going to take shape.
I am in favor of turning the treasury cut back on. I would also be in favor of an increased cap but feel that we should be finding ways to spend the funds to improve the network or enable builders on the network so the cap should not be a continuous problem.
To reason comprehensively on the matter we need to think if the reason that the treasury exists is fullfilled. The treasury needs to provide liquidity towards protocol wide usefull efforts. The community if needed could allocate 750k LPT to a single proposal or multiple ones. Therefore, the fundamental utility of the treasury, can be fullfilled.
The questions become:
how much lpt the treasury can hold liquid at any given time?
does increasing the liquidity ceiling helps with anything?
what is the defined problem at which a parameter change remediates against?
Introducing a big ceiling can give wrong impressions on the market too, we can increase the amount of sterile liquidity staying dormant at the treasury, but we cannot control the rate and quality of conversion from idle capital to productive liquidity. Maybe the underlying problem is how to convert sterile liquidity into productive liquidity more efficiently.
Re: the discussion around increasing the cut, I’m not sure that’s the right lever, as how quickly the treasury fills hasn’t been the problem.
If the goal is a bigger treasury budget and reducing how often we have to come back to restart the cut, I agree with @j0sh that changing the cap is the more appropriate lever, as a separate proposal.
I’m supportive of restarting the reward cut. (And raising the cap should that be considered in this proposal). There is an exciting vision for the future of Livepeer across both the product and network layers, and funding the needed public goods via the treasury is one of the best investments that the collective token holders of Livepeer can make.
This doesn’t preclude better active treasury management, which is a separate worthwhile path.
I’d also like to push back against the narrative that treasury funding is actually a major contributor to negative LPT market impact. The amount that has been disbursed from the treasury is almost a negligible drop in the bucket relative to inflationary LPT emitted to node operators (who also have real costs!) and delegators. The 2.0 tokeneconomics, complete with rewarding the nodes doing real work, validators to prevent the self dealing/leaching, and MFS, aim to reduce the impact of the latter.
The protocol security, core dev on public goods as laid out in the Network Eng SPE II, and the upcoming GTM SPE proposals are all great examples of items that the protocol should be funding if the project is going to succeed at capturing demand, while keeping every participants’ value secure.
thanks all for the feedback. Now that Network Engineering SPE is approved I have opened a PR to move this into proposal. I will create a separate post for it shortly.
