After the last Community Mining proposal which suggested allocating BPRO tokens to different growth goals of B.Protocol, didn’t reach the required quorum, we have taken the community feedback and submit this new proposal to the forum to get any additional feedback before it will go up for a Snapshot vote.
As the main feedback on the previous vote was to keep votes un-bundled, we recommend to set each of the following sections as a separate proposal on Snapshot (or use Scattershot vote as was proposed by some).
Below is a list of BPRO allocations that are covering different aspects of growth for B.Protocol.
Another proposal was presented lately by Visor which can be added to this “round” of votes as another separated vote if the community finds it interesting and relevant.
As the mission of B.Protocol is to become the backstop protocol for DeFi, the main growth vector is integrating with as many qualified lending and trading DeFi protocols which look to scale their liquidation system. Currently in B.Protocol v2, each integration consists of a unique liquidity pool that will be used for liquidations on the integrated platform. In order to incentivize early users to deposit into these pools, a liquidity mining program will be put in place that will include incentive rewards from both B.Protocol and the integrated protocol (where applicable), aiming to cover for approximately 10% APRs. With this allocation we estimate we can incentivise deposits of at least $10m into the different backstop pools, that can be used for up to $100m of liquidations.
We are happy to share that the team is discussing a few new native integrations for B.Protocol v2 and aiming to finalize the details in the coming weeks -
- MakerDAO new Vault (passed MKR governance vote).
- bZx (finalizing details).
- Rari Capital’s Fuse/Market.xyz (finalizing details).
- A few more platforms (to be announced soon).
For this purpose there is an initial (and quite immediate) need of allocating 200k BPRO that will be distributed to users who will deposit into the backstop pools of these new integrations (this is needed to finalize the incentive details of the joint LM programs). The distribution of the BPRO rewards to LPs will be made available to LPs only once the BPRO staking mechanism is in place.
Result if passed: Allocating 200k BPRO to a dedicated account under the control of the Multisig to be used as incentive rewards for new native integrations.
Similar to the previous proposal, and in order to better align users’ incentives with the growth of the protocol, it is proposed that a UMA’s KPI Options program will be used for a KPI-based LM.
For this purpose, 90k BPRO from the DAO Reservoir account will be deposited as collateral to mint 90k BPRO UMA Option tokens (ERC20), that will be distributed to Users according to the same conditions as the previous LM - 80/20 for debt/deposit on Maker and Compound v1 integrations, and full rewards for Liquity’s deposits (see numerical example below).
A floor price of 33% will be set and the options will mature after 3 months at the end of the 2nd LM phase (block number will be set once this proposal will go live as a Snapshot vote).
- If the TVL of B.Protocol reaches or exceeds $150m, the options will mature to 100% (1 BPRO per option).
- If the TVL fails to reach $150m the option will mature at the floor price (0.33 BPRO per option), and the remaining 60k BPRO will be returned to the DAO Reservoir account.
To better understand the distribution ratios, here is a numerical example according to today’s TVL (rounded) -
- Maker + Compound total deposit = $50m → *0.2=10
- Maker + Compound total debt = $10m → *0.8=8
- Liquity deposits = $10m → *1=10
These 10/8/10 are the normalized weights that will determine the allocations of the LM rewards, according to the total amount and time the funds were locked in B.Protocol.
The snapshot for the beginning block number of the BPRO LM 2nd phase will take place once this proposal is put up for a Snapshot vote and will not include retroactive rewards. The distribution of these BPRO rewards will be made available to users only once the BPRO staking mechanism is in place.
*As BPRO already got whitelisted on UMA and as the UMA DAO passed a “generic identifier” last month, this implementation can be executed without any further UMIPs submissions.
Result if passed - Deposit 90k BPRO from the DAO Reservoir into a BPRO KPI-Option program on UMA that will take DeFi Llama as its TVL source.
- KPI - $150m TVL.
- Floor price of the option - 0.33 BPRO.
- Fully matured price of the option - 1 BPRO.
Putting direct efforts in the growth, promotion and marketing of the protocol was raised by a few members on the forum and Discord. It was proposed that a new community based Growth Squad Fund will be formed to pursue this goal.
This proposal suggests, in accordance with the previous discussions on the forum, that a Growth Squad Fund will be funded by the DAO with 25k BPRO to be utilized towards certain growth KPIs as were suggested in this proposal.
Result if passed: Transfer 25k BPRO to a Growth Squad Fund account, controlled by the Growth Squad multisig.
Many users in DeFi consider the security of the protocols they are using as the leading measurement for their involvement. Last month, Immunefi launched a new Bounty Program for B.Protocol, with up to 50k BPRO bounties.
This proposal suggests that the DAO will dedicate a special vault with 50k BPRO to be used by the multisig if and only if payouts are needed to be made to bug hunters of the Immunefi program.
Result if passed - Transfer 50,000 BPRO to a dedicated account for Immunefi payouts if needed.
This (revised) proposal suggests 4 sections to be voted by the DAO to dedicate funds from its Reserve:
- 200,000 BPRO to be allocated towards incentivising new v2 integrations.
- 90,000 BPRO - to be deposited into a UMA KPI Options program which will be distributed to B.Protocol users according to the above conditions.
- 25,000 BPRO - to fund the B.Protocol Growth Squad Fund.
- 50,000 BPRO - to be deposited in a dedicated vault to be used for payouts to Immunefi Bug Hunters only if a critical bug will be found.