Burn-Mint-Equilibrium (BME) 2.0 and Token Emissions - Topic Specific Thread

Research & Protocol Improvements
1

This is a thematic topic thread related to the proposed Livepeer 2.0 Protocol Updates. There will be many such threads in the coming days and weeks to dive into each topic in detail.

This thread covers the Burn-Mint-Equilibrium token model in Livepeer 2.0. This new concept updates the LPT value accrual model such that as network fees rise, supply of LPT is reduced through LPT buy-backs and burns. A series of governance parameters are suggested in order to control this mechanism.

BME Value Flow

As a quick overview:

  1. User of the network pay fees in USDC to node operators through PM tickets.
  2. Node operators redeem these tickets, crediting them with fees for the round.
  3. Node operators receive BMENodeCut % of these fees, and the rest go into the BME.
  4. The USDC fees in the BME are used to buy back LPT from a DEX, and burn that, reducing LPT supply.
  5. Nodes are compensated with inflationary LPT rewards in proportion to the fees that they generated.

Over time as the emissions curve for LPT reduces the amount of inflationary LPT, fees play a greater role in node operator compensation. The governance parameters listed below can be adjusted to find the balance needed to balance out LPT supply reduction vs node operator compensation/incentives vs validator/treasury funding requirements. There is significant research and examples of this mechanism in place in other DePIN protocols to arrive at a near equilibrium between token emissions and fees that we can draw from in subsequent governance discussions. This thread is focused more on an introduction to the technical mechanics.

Livepeer BME Parameter Definitions

Fee flow, emission distribution, and DEX execution parameters — initial governance values

Fee Flow

Parameter Group Definition Starting Value
BMENodeCut Fee Percentage of gross fees retained directly by the node operator in the fee currency (e.g. stablecoin or ETH). Paid immediately at job settlement, before any LPT purchase. Node operators’ direct compensation for work performed. 30%
BMENetworkFee Fee Percentage of gross fees routed to the protocol to purchase LPT on the designated DEX. The purchased LPT is then subject to BMEBurnPercentage before the remaining pool is distributed to treasury and validators via emissions. At starting values, 100% burn means no fee-side LPT reaches treasury or validators. 70%
BMEBurnPercentage Fee Percentage of LPT purchased with BMENetworkFee that is permanently burned (sent to the zero address). The remainder, if any, would flow into the reward pool. At 100%, the full purchased LPT is burned and the reward pool is funded exclusively by emissions. At sub-100% values, unburned LPT is added to the round’s reward pool before the emission split is applied. 100%
BMETreasuryCut Fee Percentage of the fee-side reward pool (post-burn) allocated to the DAO treasury. At BMEBurnPercentage = 100% this is always zero regardless of this parameter’s value, since there is no post-burn pool. Becomes active if BMEBurnPercentage is reduced below 100% in future governance. 0%
BMEValidatorCut Fee Percentage of the fee-side reward pool (post-burn) allocated to validators and their delegators. Same dependency on BMEBurnPercentage as BMETreasuryCut — inactive at 100% burn. Validators are compensated exclusively through emissions at starting values. 0%

Emission Distribution

Parameter Group Definition Starting Value
NodeEmissionShare Emission Percentage of round LPT emissions allocated to node operators. Distributed proportionally to each node’s share of work completed in the round, weighted by that node’s aggregate validator multiplier score. This is the primary incentive for node operators to perform quality work at starting values. 70%
ValidatorEmissionShare Emission Percentage of round LPT emissions allocated to the validator set and their delegators. Distributed proportionally to each validator’s delegated stake. Validators may set individual reward cuts that determine how much they retain vs. pass to delegators. This is the primary compensation for the validator scoring role. 25%
TreasuryEmissionShare Emission Percentage of round LPT emissions allocated to the DAO treasury. Accumulates for governance-approved expenditure on grants, development, and ecosystem growth. Governed by existing Livepeer treasury parameters. 5%

DEX Execution

Parameter Group Definition Starting Value
BMELiquidityPool DEX On-chain address of the primary liquidity pool used to execute LPT purchases. Should be the deepest available LPT pool to minimize slippage and manipulation exposure. Governable to allow migration if a deeper pool emerges. TBD
BMETWAPInterval DEX The lookback window (in seconds or blocks) over which the time-weighted average price of LPT is calculated prior to executing a buy. Longer intervals are more resistant to price manipulation but introduce lag relative to spot price. Standard range across DeFi protocols is 30 minutes to 2 hours. 3600s
BMEBuyFrequency DEX How often accumulated BMENetworkFee proceeds are deployed to purchase LPT. Batching purchases reduces gas overhead and makes buy timing less predictable to front-runners. Expressed in rounds. One purchase per round is the recommended starting cadence. 1 round
BMEMaxSlippage DEX Maximum acceptable deviation between the TWAP reference price and the actual execution price, expressed as a percentage. If slippage would exceed this threshold the transaction reverts and accumulated fees roll over to the next buy interval. Prevents sandwich attacks from extracting value during large buys. 1%

A note on the DEX parameters - These are listed out as a starting point for awareness, however the design of the DEX purchasing methodology was outside the scope of establishing the initial BME params, and can be spec’d out in the future. This mechanism can be borrowed from other DeFI and DePIN protocols that use protocol-native token purchase contracts.

Accounting Identities

BMENodeCut + BMENetworkFee = 100% of gross fees. 30% + 70% = 100%

BMEBurnPercentage + BMETreasuryCut + BMEValidatorCut = 100% of purchased LPT. 100% + 0% + 0% = 100%

NodeEmissionShare + ValidatorEmissionShare + TreasuryEmissionShare = 100% of round emissions. 70% + 25% + 5% = 100%

Fee flow at starting values
Node operators receive 30% of gross fees directly in fee currency. The remaining 70% buys LPT on the DEX using a 1-hour TWAP with 1% max slippage, executed once per round. 100% of purchased LPT is burned. The round emission pool is funded exclusively by the existing LPT issuance schedule: 70% to node operators (multiplier-weighted), 25% to validators and delegators, 5% to treasury.

Note on BMETreasuryCut and BMEValidatorCut
These parameters are dormant at BMEBurnPercentage = 100% but should be defined now so that reducing the burn percentage in future governance automatically activates fee-side distribution without requiring a parameter addition.

Token Emissions Schedule

A hotly anticipated topic is how the LPT emissions schedule should be adjusted for 2.0. Some common beliefs are that:

  • Current inflation is high, and the dilution and sell pressure created are a net negative for attracting new participants and current committed participants.
  • Yet inflationary issuance is still required during a pre-scale bootstrapping period.
  • Emissions should be somewhat reflective of network utility and fees. They should adjust downwards as the network scales and fees make up a majority of participation incentives.
  • Some think a predictable max-supply is necessary for the market to accept LPT. This is debatable.

While I wanted to share the technical BME parameters and mechanics in this thread so the community could begin debating them, a spec’d out strong opinion on the issuance curve still requires more research and work before laying out a candidate. Instead, let me share some core ideas that are influencing the design:

  1. Continue emissions are current level, but set an issuance curve that leans to declining issuance over time, removing the participation target based mechanism that raises and lowers it.
  2. Have the emissions capped as % multiplier of fees generated over given time epochs. For example, having every 2 years. In year 0 emissions can target 32x network fees, year 2 16x…year 4 8x…year 8 2x…year 12 0.5x…year 16…0.125x, etc. Ultimately, for values less than 1, the BME burn % parameter can arrive at an equilibrium between newly issued LPT and bought/burned LPT, essentially establishing a time period for a max LPT cap, even if that ultimate # is unknown and based on fee value.

Note - there are lots of complexities in the above regarding unpredictable fee volumes, LPT price, onchain price oracles, needed incentives for validation or public goods, etc. Very open to a simpler fixed declining emissions curve, and leaving the governance params of the future to adjust and manage the impact.

A note on MFS impacts

The above parameters are laid out in the scope of the initial Livepeer 2.0 ideas. However an interesting modification to some of the concepts has been proposed in the MFS thread.

Should that version of the protocol concepts be adapted, these same parameters would likely still be introduced, though they may start with different initial values. In the above proposal, even though I mentioned 30% as the starting value for the BMENodeCut, there’s an argument that it could be 0% with all fees going to the BME. Under MFS, you’d likely want a higher BMENodeCut since you still need to incentivize nodes to compete for fees even if they have low stake - for example 50%.

Under MFS, it’s possible that the ValidatorEmissionsShare would be 0% or something low, rather than 25% - an attractive possibility of dramatically reducing the costs to the network and dilution to LPT holders. That also sets a path to LPT emissions being truly in equilibrium with fees at some point, not requiring ongoing inflation to fund an expensive validator set.

Thanks for your initial reaction and feedback on these BME and token emissions concepts. There is clearly more work to do to arrive at a final spec, but as we’ve seen from other community feedback sessions and threads, there will be lots of community input that informs those designs come the end of August. We’ll host a community call on these topics the week of the 17th!

1 Like
2

Coming from a ‘regular guy’ (not a programmer, not an orchestrator) who has made a significant investment in LPT and believes in the project, here are my thoughts and questions/concerns. If these have already been answered, I apologize for the being redundant.
(1) I like the idea of removing the 100 orchestrator cap. I believe if the network is going to compete for market share, it’s going to need more than 100 orchestrators to do it. And like you said, not just GPU but also CPU power.
(2) The idea of buying up liquidity and burning coins is great. Scarcity creates value.
(3) I don’t think a longer unbonding period would be a problem for most of us who are truly invested in the project. 7 days isn’t a long time, so I don’t think that doubling or even quadrupling the unbonding period wouldn’t be a major issue for most delegators.

(4) My primary question/concern is this: With these changes, how would delegators be rewarded or compensated for staking their share of the network? Right now, most rewards come from newly minted coins and if I understand correctly, as the network becomes busier, rewards will slowly shift from inflation payouts to fee sharing. This would encourage many orchestrators to adjust their payout models (as many right now keep the ‘fees’ and give away the ‘rewards’). So, to put it plainly, how would this affect a person like me who has a large number of coins staking?

Thank you for your time and your work on this!

2 Likes
3

I share the same concern as Aaron, as someone who also has a significant amount of LPT staked and intends to remain committed to the network long term.

On the fundamental side, I really like the proposed direction. Reducing inflation, using network revenue to buy back LPT, and burning those tokens to create scarcity and stronger value accrual for LPT holders is, in my opinion, a very positive change.

However, Aaron’s question raises an important point about the incentive to remain a delegator rather than simply becoming a passive LPT holder.

If emissions progressively decline, and therefore the rewards distributed to delegators through reward cuts decline as well, what would economically incentivize us to keep our LPT bonded?

Would the expectation be that orchestrators/validators progressively compensate for lower reward cuts by sharing a larger portion of their actual network fees with delegators through higher fee cuts?

Otherwise, if most of the economic benefit ultimately comes from LPT buybacks and burns, a holder could potentially benefit from the resulting scarcity without taking the additional constraint of staking and the unbonding period.

In that situation, there could be little difference between holding LPT liquid in a wallet and keeping it bonded, especially as emissions approach very low levels.

I personally have no issue with a longer unbonding period, and I would actually prefer to keep my LPT staked and actively contributing to the network. But there needs to remain a clear economic incentive for delegators to accept that additional constraint.

So I think the key question is: in the long-term BME model, what is the intended economic reward for providing stake to the network, beyond simply benefiting from LPT scarcity as a holder?

I think clarifying this would be very valuable for long-term delegators.

2 Likes
4

Thanks for the feedback. To respond to the common feedback from both @Sparta and @aaronwade regarding the motivation for delegating under reduced inflation:

I think that these questions are particularly valid under the original 2.0 proposal - where delegation on validators elect the set and help carry governance weight, but don’t necessarily subject themselves to more security or economic skin-in-the-game to prevent misbehavior. More stake on a node brings value and does increase the cost-of-attack on the network by taking over the validator set, so it should be rewarded appropriately according to the market.

However, I’ll actually answer this in the context of the MFS Proposal in which the role of delegation plays a more active role in node operation and security. If you haven’t seen that proposed alteration to 2.0, please give it a read.

  1. There is value to the network in delegation in that it provides more security on node operator behavior. If the stake on a node can be frozen with zero rewards (or even slashed) under misbehavior, then there is a higher cost of attack on the network, and users can use those nodes to fulfill requests with higher confidence. But of course this value has to be incentivized.

  2. Even though reward %s may decline as fees rise, it does not mean that they decline to zero. Combine this with rising fees, and delegators should be looking at their total incentive and return rather than just inflation percentage. Ultimately the market will determine the rewards for delegation. Nodes will need to set their reward/fee cuts to the rate that attract delegation if delegation is in fact something that node operators need to attract in order to maximize their own rewards. In the MFS proposal, it is necessary for any newer node who hasn’t built up enough stake to maximize their reward potential. So yes, they should be willing to share their fees and rewards generously until they achieve that milestone themselves. Delegators have an opportunity continuously “activate” newer nodes, which help the network decentralize and scale.

  3. I should note that this is a big change from the behavior of current delegation - which can effectively be “set-it-and-forget-it.” I think it can be argued that this isn’t necessarily helping the network tremendously and is being overcompensated. However active delegators under MFS could significantly outearn inactive ones, and help the network significantly in the process.

1 Like
5

I’d agree with ‘set it and forget it’ except that some orchestrators bait delegators with low fee/reward cuts and then raise them once enough “set it and forget it.” By the time the delegators realize it, the orchestrator has stolen hundreds, if not thousands, of reward coins (happened to me).
As far as the ‘overcompensated’ comment. If prices were stable, I’d totally agree. Unfortunately, even rewards over 40% APY can’t keep up with the rate the coin is falling.
With all that said, that’s why I agree with many of the proposals going forward.

1 Like
6

This all seems sensible, and I am supportive of a stronger link between fees and token value.

On that note, regarding the emissions schedule:

If we take:

X = value of LPT emissions
Y = value of purchased + burned LPT

As long as X > Y it will be cheaper to manufacture fees for rewards, than to buy LPT outright. This is part of why the 2.0 proposal has so much attention towards validation and economic lock-up as a way to address the self-dealing problem, among other pathological behaviors.

At equilibrium (X = Y) then self-dealing is not likely to be profitable, and fees should better reflect network value. To me, this poses a bootstrapping question: how fast we are willing to accelerate towards that point, vs how much we should resist those behaviors through protocol design or a “collective conscience” such as a validator constitution?

It’s probably worth modeling a range of outcomes under various parameters. This isn’t the place to speculate on the token price, but it’s also worth considering the second-order effects if the equilibrium price is lower than it is today, eg impact to other ecosystem-funded initiatives such as the Foundation and ongoing projects.

1 Like
7

I wanted to throw this thought out there:

Instead of trying to build Livepeer 2.0 around a primarily transitional phase from inflation to Burn-Mint-Equilibrium, build Livepeer 2.0 around Burn-Mint-Equilibrium and use a centralized router as a temporary means to manage the transition.

From what I’m seeing, most of the complexity in Livepeer 2.0 is actually around having Livepeer 2.0 be both an inflation-enabled protocol and a Burn-Mint-Equilibrium. Burn=Mint is a very straightforward design, and it would make Livepeer 2.0 very clean to implement and launch, but the ecosystem isn’t quite large enough to fully switch to Burn=Mint, so there needs to be a way to still have an inflationary structure, and this is what is bringing the vast majority of the complexity.

Suggestion

Make Livepeer 2.0 focused on what the network should become, which is a healthy, balanced Burn-Mint-Equilibrium, and leverage a temporary Foundation-owned router to soft-manage the transition to that mature network.

This adds some temporary, neutral centralization, but it dramatically reduces the complexity of what Livepeer 2.0 needs to be. Things like inflation distribution, self-dealing, and basic QoS could be handled much more easily with a low-profile router. Trying to make those elements operate in a fully decentralized manner is incredibly complex and requires significant social engagement from validators, operators, Foundation, etc. just to make the network work properly. Instead, a router would basically eliminate much of that orchestration burden by transparently managing anything that isn’t part of the mature Livepeer 2.0 vision, and only while the network grows.

I’ve gotten to know many at the Foundation over the past few months, and I believe the ecosystem as a whole feels they could be fair stewards of the temporary components the network would need during the transition period to full Livepeer 2.0.

Quantifiable Benefits

1. Dramatically reduce technical debt and cost — By not having to make every component of the growth phase decentralized, development complexity drops significantly. This can allow Livepeer 2.0 to launch faster and likely reduce development costs to get there.

2. Faster development cycles — When you have really complex decentralized systems trying to balance inflation, making changes takes much more time. If the goal of Livepeer is to offer competitive services to users and an approachable marketplace for service providers, then it would be in Livepeer’s best interest to allow balancing and correction features to be implemented quickly instead of through heavy network upgrades and smart contract changes. By putting the complex parts inside of a router, making needed changes to keep Livepeer competitive can be done very quickly.

3. Development focus — Keep Livepeer 2.0 a really clean, mature design that is meant for a scalable future. Keep decentralization focused on the larger vision, without being burdened by this temporary growth phase we are in.

4. Socially viable — Systems that require many participants to be engaged in the ins and outs of the protocol just to keep the ecosystem balanced typically end up more imbalanced most of the time (from my experience). A router that handles inflation distribution in a fair and transparent manner requires significantly less social coordination, allowing the network to collectively focus on improvements that drive value to users. I think a large portion of network energy will end up going into trying to balance Livepeer 2.0 instead of expanding it.

There are probably more reasons, but I think this gives a general shape of where my mind is.

What Would This Router Be?

This would primarily be a load balancer the Foundation runs that acts as a router between users and operators. It doesn’t have to be user-facing; it could just be a service that handles routing requests to service providers. Livepeer would continue to maintain an ecosystem of user-facing gateways, as this router would be different from those.

Anything the network needs that isn’t part of the mature vision of Livepeer 2.0 could be handled inside this router. During this growth phase, the extra inflation could be easily distributed to quality providers. Self-dealing mechanisms can be much more straightforward to implement. Basic QoS could be easier to implement from a centralized router first, and later transferred to something like the SDK (the SDK would be downstream from what works with the router).

Under the hood, the router would just be operating on Livepeer 2.0 economics, but with the inflation allocation going through the Foundation. The protocol could still mint directly to users, but the actual allocation logic would be off-chain through the router. That logic would still be open source, and it would be derived from real network data and objective patterns. All the allocation principles being discussed would still be implemented, just more efficiently through the router.

How Long Would This Router Be Active?

Most likely it would just be a temporary way to help balance the network until Burn-Mint-Equilibrium is reached. At that point, the network is able to balance itself since inflation isn’t part of the system.

I could see Livepeer learning a lot from a Foundation-run router, which could actually evolve into something that orchestrators run themselves as part of their stack. What started off centralized could simply merge into what operators run. I could also see the SDK likely absorbing some of its features as well. I personally do not think this would be a sunk cost on a temporary solution — I see it as progressive decentralization, where features tried in the router could be pushed to the edges as they mature.

Conclusion

Since the call two weeks ago about Validators in Livepeer 2.0, I’ve been trying to think through how things could be balanced, and most of the time the “solution” comes back to something that doesn’t work well in a decentralized manner. Once I separated what the real mature vision of Livepeer 2.0 is that @dob has been shaping, from what is just part of getting the network to that point, things started to clear up for me, because most of the complexity is around components we only temporarily need.

Before going too deep into what this router would be, I wanted to first see if this is something the network would be open to seriously considering. I’d be happy to contribute more to the discussion and flesh this idea out more, if this is seen as a viable direction.

Curious on folks’ thoughts :slight_smile:

8

For clarity, the router concept is not so much about who governs the reward logic, because much of the governance could still be on-chain, through validators, through an SPE, or through the Foundation… the router concept itself is more about HOW it is run. If all the logic for inflation distribution, self-dealing safeguards, balancing, etc are running fully within the smart contract and the node client itself, that is a lot of work to build in a fully distributed fashion.

If that logic is all able to run in a streamlined router like service, then it dramatically reduces the technical debt. It can still be governed any designated body, but it is able to run as a dedicated service to the network during this transition growth phase before Burn-Mint-Equilibrium is fully activated.

Just wanted to make that clarification :+1: