BRIP-0006: Baseline Cutting Board Automation

BRIPs
1

This BRIP proposes a default ‘baseline’ validator reward allocation strategy - aka ‘cutting board’. This default cutting board will be automatically maintained by the Berachain Foundation using a simple, clearly specified protocol. The cutting board will act as a ‘fallback’ strategy for validators that choose not to proactively manage their reward allocation themselves. The mechanism that triggers the ‘fallback’ will be defined and managed by the Proof of Liquidity protocol.

Some of the benefits of this BRIP will include:

  1. Greater economic efficiency for PoL as idle BGT emissions are redirected to active incentives.
  2. More BGT flowing to more vaults, which benefits all protocols that manage vaults.
  3. Ease-of-use improvements for validators as they can choose to revert to the baseline strategy with no effort and still automatically earn incentives.

https://github.com/berachain/BRIPs/blob/main/meta/BRIP-0006.md

Feedback encouraged.

1 Like
2

Thank you for the proposal, @GrizzlyBera :folded_hands:

A few questions and thoughts:

  • Will vaults with a BGT capture above a certain threshold (e.g., x%) be excluded from the automation? Otherwise, this could lead to centralization around a few large vaults.

  • How many vaults will be included in the automation tool per validator? The current 30% maximum seems a bit high if the goal is to promote broader pool and token growth across the ecosystem.

  • If 30 validators are included in the automation tool, how will the allocation be balanced to ensure a relatively fair incentive rate among them? Considering there are currently around 40 incentivized vaults, it might be worth exploring ways to distribute some BGT toward smaller or non-incentivized ones.

Thanks again for pushing this forward!
WinnieSwap public answer: https://x.com/winnieswap/status/1982750006252535920

3

generally supportive.

Few questions:

  1. What will be the threshold for inactivity?

  2. Today, what share of the overall validator weight counts as inactive?

  3. “Currently, the strategy will rely on Pyth as the authoritative source of pricing incentive tokens in USD.” I don’t think this is a good idea, since incentive tokens aren’t currently required to have a Pyth oracle (eg some bera LSTs, like the largest incentivizer osBGT). Have we done the analysis on what share of whitelisted tokens have a pyth oracle?

4

Also support the last part

We have very good relation with Seda which offer a way more programmability and verifiability. We can build the oracle ourself - know the team pretty well and there is a good reason why Hyperliquid and HIP3 is running on it on most part instead of Pyth

5

Generally support this proposal as a safety net for those that wont be managing their cutting boards either by themselves or via BRIP-0005 (i still think a sidecar or a simple script that validators can then tailor according to their own parameters would be great to have).

I think the one thing to scope out here is when do we consider one inactive? The proposal mentions its X time after last cutting board activity, but what if that validator simply doesnt need to update as the vaults to which it directed are still good for them? As an example, i remember we have had that where we didnt have to change it for a week or more since we were happy with the distribution.

So the question is, should inactivity count as when was the last time they updated the cutting board, or when their allocation becomes inefficient (eg, no more bribes in a specific vault). If so, how many vaults would count as being inactive?

Eg, if a cutting board has:

vault 1: 30%
vault 2: 30%
vault 3: 30 %
vault 4: 10%

And only vault 4 is without any bribes. IMO that should still be considered fine.

6

Thank you for the questions / thoughts.

  • There is currently no logic that would explicitly exclude any set of vaults. The initial allocation logic of the baseline cutting board will only consider vault incentives in setting the strategy.
  • The current proposal does not change any other parameters of PoL, such as the maximum allowed allocation. This can definitely be considered in the future but the current set of changes are biased towards being as minimal as possible.
  • All validators are subject to the baseline mechanism; there is no target or any assumptions about how many validators will use the baseline at any given time. In fact, in the ideal version of this system, no validators revert to the baseline because they are all proactively managing their allocations.

Hope this helps.

7

Thank you.

  • The inactivity period is a governance-managed parameter. The proposal for the initial threshold is 7 days.
  • One important nuance of the mechanism is that validators are not required to change their allocation within the defined period. They only need to show activity. So it is perfectly valid to simply set the same allocation; the analogy is something like a file ‘touch‘. This is necessary because it’s not possible for the simple protocol to distinguish between ‘true’ inactivity and ‘intended‘ inactivity. If validators proactively manage their allocation we expect very few to revert to baseline at any given time.
  • As mentioned above, the expectation is that very few validators will be subject to the baseline strategy at any given time and the bias is to keep the initial implementation as simple and robust as possible. As such, the initial proposal seeks to defer the complexity of dynamically pricing every possible incentive token. This is not expected to have a material impact on the top incentive tokens and the BGT allocated to them since a substantial majority of active validators include allocations that track these tokens.
    Moreover, if the community comes to a consensus on additional oracles a/o price feeds to include, the current bot design can incorporate them easily.

Thanks again.

8

Thanks for this.

Answered above, but the tl;dr is that it’s not necessary to change the allocation of the current cutting board within the timeframe. It is only necessary to show activity and ‘touch‘ the current allocation by submitting a transaction.

1 Like
9

Thank you for the effort so far on this BRIP! Some feedback to consider:

  1. It would be better if this were an opt-in / opt-out system. Changing the risk / reward profile of validators should be done explicitly.

  2. Requiring a recurring touchpoint to keep allocations from changing places an operational burden on teams who are opinionated about their allocations. With an opt-in / opt-out mechanism, teams can express their preferences without additional recurring work.

Thanks again for the effort here :saluting_face: