[VeBetterDAO Proposal] Max allocation surplus to fund a Dynamic Base Allocation pool instead of going to the Treasury

VeBetterDAO
1

Fund a Dynamic Base Allocation (DBA) pool with surplus B3TR from Dapps that achieve max. allocation

Proposal Summary

This proposal will focus on adding more balance to VeBetterDAO. There are clear signs of segregation between the projects. A handful of big dapps receive most of the weekly allocation while the many smaller dapps, and new projects, fight for the scraps.

While I do still think removing the initial base allocation was a good idea, it introduced this unbalance between the popular projects and the rest. This proposal does not in any way seek to slow down the popular applications. In fact - it will make sure when apps go viral, the whole VeBetterDAO ecosystem profits.

Currently, when a dapp reaches the 20% max. allocation in a round, the surplus B3TR is donated to the Treasury. This proposal seeks to change this behavior. Instead of funding the treasury, the surplus B3TR will fund a DBA pool for that round where every single dapp that meet the participation criteria will get their equal share.

While the max. allocation isn’t achieved that often yet, it’s already noticeable that some dapps are growing exponentially. By funding the dynamic base allocation pool with the surplus B3TR every round - every single dapp that meets the criteria will get an allocation boost when other dapps become increasingly popular. As the smaller dapps will receive more funds - they have more means to attract new users with marketing, increased rewards, etc.

It’s then up to every single dapp to use the dynamic base allocation to grow.

Proposal Changes

  • Modified: Surplus B3TR will no longer be donated to the VeBetter Treasury but will fund a Dynamic Base Allocation pool. Dapps that meet the weekly criteria will receive their share of the DBA pool.

Only Dapps that meet the participation criteria will take part in the DBA pool. These are the criteria. DBA pool rewards are sent out after a round ended.

  • Only dapps that rewarded B3TR with proofs in the round that ended are eligible for the rewards
  • Dapps that receive more than 7.5% of the weekly allocation are excluded
  • Dapps that are not fully endorsed are excluded
    • Dapp that entered the round with 100 or more points and went below 100 is accepted
    • Dapp that entered the round with less than 100 and ends the round with 100 or more is accepted

When there is no dapp that reaches max. allocation in a round, the DBA pool will be 0.

The DBA pool will be shared equally amongst all dapps that meet the criteria above.

Motivation

As mentioned before, this proposal seeks to bring back balance in VeBetterDAO - by rewarding the whole ecosystem when specific dapps outperform the rest. By introducing the DBA pool, B3TR that would end up in the Treasury is now equally reallocated to the ecosystem where dapps can use the extra funds to get more users and thus more votes.

FAQ

Q: Why fund a Dynamic Base Allocation pool and not simply return the B3TR back into the allocation pool?
A: When you add the surplus B3TR back into the allocation pool, it will just go to the “next big dapp” in line - feeding the unbalance even more.

Q: Why the certain criteria?
A: The original base allocation was removed because we wanted to protect the DAO from lazy dapps who’s sole purpose to exist was siphoning B3TR away for their own gain. By adding these criteria, only dapps that are active and actively supported get the share. Which means potential bad actors will not receive extra funding besides their voting allocation. We also make sure the DBA pools goes towards the dapps that need it, to recreate the balance.

Q: Why split it evenly and not let the dapp who reached the max. allocation decide where the surplus goes? In the end it’s their votes.
A: The max. allocation is there for a reason. It’s to limit the amount of power and influence a single project can get within the DAO. When you would allow a dapp to select their own favorites to receive the surplus, you will extend their power and reach and could lead to favoritism and centralization. That’s why, to keep the balance, DBA is equally shared amongst all dapps that meet the criteria.

2 Likes
2

Hello there, here is a quick recap on the execution status of this proposal.

This proposal will be executed in multiple steps in order to have faster release times and allow the x2earn apps to receive their B3TR tokens.

The first step will be to change, in the XAllocationPool contract, the address where all the unallocated rewards are being sent (which is currently the VeBetter Treasury) to a newly deployed contract (DynamicBaseAllocationPool) that will act, initially, as a wallet/treasury, from where VeBetter team will be able to distribute surplus allocation to the apps.

Our goal is, with time, to make the DynamicBaseAllocationPool contract capable of performing all the needed calculations (e.g.: what apps should receive the surplus allocation) on chain so that anyone can trigger the distribution (as it currently happens with starting rounds and claiming app rewards), but such functionality cannot be currently achieved for the following reasons:

  1. We do not have an on-chain way to check how many actions with sustainable proofs an app performed in a specific round;

  2. We do not have snapshots/capability of knowing (on-chain) how the endorsement of an app evolved during a round;

  3. Even if we add the above functionalities in the VeBetterPassport and X2EarnApps contracts, we would need to test the scalability of such solution and be sure it could serve a high number of apps.

For the above reasons, the second step of this implementation will be to create an internal script that will perform all the needed calculations off-chain and distribute the dynamic rewards to the apps that are eligible based on the criteria described in the proposal.

External tools, such as indexers or veDelegate, can listen to events emitted by the DynamicBaseAllocationPool contract to know which apps received the extra allocation and what quantity.

The third step would be to align our frontend and indexers to be able to show correctly the data in the VeBetter dashboard, so all voters are correctly informed of how many B3TR tokens each app received.

The last step of our solution will be to make, first of all, this process as secure and as less prone to errors possible, and to try to move as many parts as possible on-chain, so that VeBetter team won’t be the only entity responsible for distributing those rewards, making the process more transparent and secure.

Lastly we would like to underline how the core team thinks that the following rule, voted in the proposal, is very vague and easily falsified: “dApps that didn’t reward B3TR with proofs in the finished round are excluded”. For example an app that is not even live on mainnet but is endorsed could manually perform a “distribute with proof” action which would qualify it as eligible for this surplus allocation. We strongly recommend to make this rule clearer or to add a specific amount of actions that would need to be perfomed, e.g.: 20, 100, etc., otherwise it risks to be a useless rule. Anyway, the team will execute as voted and will check that the app performed at least 1 action with proof in the round.

Technical comments

Checks to perform when filtering apps that should receive the surplus allocation:

  • We get all apps

  • We loop through all the apps and: a) check that the app was eligible for voting in that round b) check if the app rewarded at least 1 action with proofs (we can check if there is any RewardDistributed in that round from that app)

  • We exclude apps that received more than 7.5% votes (we call the xAllocationPool.getAppShares(roundId, appId))

  • We exclude all apps that are not fully endorsed (dApps that remained the full round in grace period or dApps that were already not included in the round are excluded.)
    More precisly:

    1. dApps that entered the fished round with 100 or more points and went below 100 are to be accepted
    2. dApps that entered the round with less than 100 and ends the round with 100 are to be accepted.
    3. This means only dApps that remained the full round in grace period or dApps that were already not included in the round are excluded.

    We look for AppEndorsementStatusUpdated events in that round and check how the endorsement statatus changed.

  • Funds are shared equally for the remaining apps.

1 Like
3

Hello everyone, we just executed this proposal!

The implementation consists of:

  • XAllocationPool contract sending unallocated B3TR to a new DBAPool contract and storing the unallocated amounts per round
  • A new DBAPool contract that will equally distribute the unallocated B3TR to a list of apps (gated by a DISTRIBUTOR_ROLE). The filtering of eligible apps is done offchain, the contract is handling the amounts to prevent any possible error/hack of the offchain service and to prevent any possible issue with the params.
  • The filtering is done off chain following the above criteria:
    1. App was eligible for voting in the round
    2. App rewarded at least 1 action during the round
    3. App received less than 7.5% of total votes
    4. App was fully endorsed during the round (not in grace period for entire round)

Round 66, 67, and 68 were distributed.
66: VeChain Explorer | Tx
67: VeChain Explorer | Tx
68: VeChain Explorer | Tx
Next rounds will be distributed after each new rounds starts.

Funds are deposited into the X2EarnRewardsPool contract for the app (same as with weekly allocation, no fund is sent to any team member address).

To track those, devs can track deposits into the X2EarnRewardsPool contract from the DBAPool contract, or by looking for the following event in the DBAPool contract:

/**
   * @notice Emitted when funds are distributed to an app
   * @param appId The ID of the app
   * @param amount The amount of funds distributed
   * @param roundId The round ID
   */
  event FundsDistributedToApp(bytes32 indexed appId, uint256 amount, uint256 indexed roundId);

The address of the DBAPool contract: 0x98c1d097c39969bb5de754266f60d22bd105b368
Contract verified on sourcify: 0x3fc8C37EE90Df9Db22FE5f30875f64F663Ba498A on VeChain (100009)

4

Show those numbers on the governance portal
UI was updated to show correctly the total amount of allocation received by apps (vote allocation + dba)

Next steps:

  • See if everything can be moved on chain (low priority currently since we want to move forward with other proposals and integrations as well)