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:
- User of the network pay fees in USDC to node operators through PM tickets.
- Node operators redeem these tickets, crediting them with fees for the round.
- Node operators receive
BMENodeCut% of these fees, and the rest go into the BME. - The USDC fees in the BME are used to buy back LPT from a DEX, and burn that, reducing LPT supply.
- 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:
- 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.
- 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!