Authors: Owsley and @wavey
Date: Jan 22, 2024
Summary
- Replace the original boost calculator with one deployed at
0xf89E5152C6ba530f398213dAC29519fc0Ef224e4
. - Configure
maxBoostPct
to 75 anddecayPct
to 125. - Introduce new boost callback architecture that separates delegate and receiver callbacks.
Motivation
- Boosts are a central part of the Prisma governance design. Experimentation is needed to explore what optimal parameters look like. Replacing the boost calculator with one that is more generalized and flexible is the first step in that direction.
- Slightly reducing the total amount of weekly max boost in the system will help encourage a more robust fee marketplace.
- A new callback architecture will enable liquid lockers to safely mint tokens even when claim selects a third party delegate. This will vastly increases boost fee revenue for PRISMA lockers who have enabled boost delegation.
Background
Boost Calculator:
- The boost calculator is responsible for allocating boosts to each user at the beginning of each week.
- There are three phases of boost for each user. Max boost (2x) is first, and when depleted, a Decay (<2x) phase begins, where all claims are decayed at a linear rate until the No boost (1x) phase is reached.
- Boost parameters (
maxBoostMul
,maxBoostPct
,decayPct
) set in the calculator help govern the amounts users will realize at each phase. - A user’s max boost allocation is calculated proportionally to their governance share, the total emissions released in the given week, as well as the
maxBoostablePct
value set in the boost calculator. - Similarly a
decayBoostPct
value in the calculator is used to configure how much many claims are possible within the decay phase. - A higher percentage leads to a larger amount of claimable emissions at that phase.
Callback Architecture:
- Today, Prisma users may claim emissions using boost purchased from a specified delegate. The delegate may elect to have custom code executed on each claim by registering a callback contract.
- This ability to trigger a delegate’s custom code is a key design feature of Prisma. It enables, for example, liquid lockers (Yearn, Convex, etc) to perform actions like mints and rewards transfers during user claims. This flow is natively supported by Prisma core contracts.
- Importantly, there is no native ability for a similar callback pattern to enable the receiver of a lock to execute custom code.
- This proposal defines a trustless new architecture and specification by which boost delegates may opt-in to enabling a receiver callback whenever a claimant uses their boost.
Specification
Target: 0x06bDF212C290473dCACea9793890C5024c7Eb02c (Vault)
Method: setBoostCalculator(address)
Parameters: boostCalculator=0xf89E5152C6ba530f398213dAC29519fc0Ef224e4
Target: 0xf89E5152C6ba530f398213dAC29519fc0Ef224e4 (BoostCalculator)
Method: setBoostParams(uint8,uint16,uint16)
Parameters: maxBoostMul=2, maxBoostPct=75, decayPct=125
Benefits
- We expect each of these changes to play a large role in a more competetive boost marketplace, increasing the value of each maxboost and giving buyers more access to boost sellers.
- By no longer requiring boosts to be purchased directly from liquid lockers when minting, lockers with boost delegation enabled can expect to profit from the efficiency gain.
- As more claims occur at less than max boost, emissions are added back to the unallocated supply. This increases the amount of PRISMA emissions available for the protocol on a longer timeframe.
tl;dr
We see the proposed changes to boost as creating a win-win scenario where:
- PRISMA lockers who have enabled boost delegation capture more fees from selling their boost
- Claims to liquid lockers occur with increased boost efficiency
Together these conditions increase the attractiveness to lock PRISMA and drive further value to the protocol as a whole.
Additionally, the generic architecture of the new boost calculator gives us the freedom to further fine-tune the boost parameters in the future.
Next Steps
The required smart contracts are already deployed. We welcome community feedback, and if overall sentiment is positive we will put up a snapshot vote soon and begin work on the front-end implementation.