VeBetterDAO Proposal] Merit-Based DBA Adjustment & Max Allocation Reduction

VeBetterDAO
1

Current situation

The Dynamic Base Allocation (DBA) implemented in late 2025 is beneficial but suffers from specific structural issues that need addressing to scale with the growing number of applications.

  • Incentive Misalignment: Low quality dApps have little incentive to increase quality to gain votes. Currently, dApps with minimal voting support receive a significant share of the DBA, making it more lucrative to launch multiple low-effort dApps than to pursue quality.
  • Arbitrary Limits: The 7.5% upper limit creates perverse incentives. An app near that limit might benefit from reducing votes to secure a share of the DBA rather than pushing for more.
    • In addition, the dApps adding funds to the DBA (i.e. dApps above the max allocation) now also receive their share of the DBA, provided they meet all the other requirements. For dApps above the current 20% max allocation today, this still means a net reduction in allocations received.
  • Treasury Stagnation: Shifting 100% of the surplus to the DBA has neglected the treasury. With VeChain pushing for grants, a strong treasury is required.
  • Outdated Max Cap: The 20% max allocation worked well when there were fewer dApps, but with over 50 listed today, it is too high. Lowering this cap increases the DBA amount available to the wider ecosystem.

Proposal

I propose a modification to the distribution logic that balances fairness with performance:

  1. Reduce Max Cap: Lower the maximum allocation per app from 20% to 17.5%.
  2. Flat Distribution with Merit Cap: The DBA Pool is distributed evenly among all eligible dApps, but with a strict limit: an app’s DBA reward cannot exceed 2x its Vote Allocation.
  • Example: If a dApp receives 1,000 B3TR from votes, its max DBA reward is 2,000 B3TR.
  • Example: If a dApp receives 10,000 B3TR from votes, it receives the full flat share (approx. 9,700 B3TR).
  1. Treasury Overflow: Any funds exceeding the 2x Merit Cap flow to the VBD Treasury.
  2. Remove the 7.5% upper limit and the max allocation threshold for eligibility in the DBA share.

Data Reference: To see how these calculations affect distribution based on Round 81 allocations, please view the Analysis Spreadsheet here.

Technical Implementation

To implement this logic, the DBAPool.sol (https://github.com/vechain/vebetterdao-contracts/blob/main/packages/contracts/contracts/DBAPool.sol) contract requires an upgrade.

  • Current State: The distributeDBARewards function currently forces an equal split of the pot among provided App IDs.
  • Required Change: Update the function to accept an array of amounts alongside the appIds.
  • Workflow: The specific reward amounts are still calculated off-chain using the 2x rule and passed directly to the contract during the distribution transaction.

Benefits

  • Quality over Quantity: dApps must secure votes to unlock the DBA reward. The incentive to launch multiple low-quality dApps is severely diminished.
  • Ecosystem Growth: Reducing the max allocation increases the total DBA distributed to the broader ecosystem, benefiting average to highly voted dApps.
  • Treasury Funding: The treasury receives a consistent influx of B3TR from the overflow (approx. 150k B3TR per round based on current data), ensuring sustainability for future grants.

Risks and Counter-points

  • Risk: Vote manipulation risks increase.

  • Counter-point: This is already a risk. It is trackable on-chain and requires capital. By linking DBA reward limits to votes, we ensure that obtaining rewards requires genuine stake.

  • Risk: Decreasing max allocation punishes top-performing dApps.

  • Counter-point: The slight reduction allows for a healthier, more diverse ecosystem which nurtures the overall value of B3TR.

  • Risk: Niche high-quality dApps with low vote counts will struggle.

  • Counter-point: Grants are the appropriate avenue for these projects. The grant process allows for tighter quality control than the algorithmic DBA.

Added

  • Merit Cap: A rule where an app’s DBA reward cannot exceed 2x its Vote Allocation.
  • Treasury Overflow: A mechanism to route excess funds (from the Merit Cap) back to the VBD Treasury: 0xD5903BCc66e439c753e525F8AF2FeC7be2429593

Modified

  • Max Allocation %: Reduced from 20% to 17.5%.
  • Distribution Logic: Moves from a pure equal split to a “Flat Distribution with Merit Cap” system.
  • Contract Upgrade: DBAPool.sol updated to accept specific reward amounts rather than forcing an equal on-chain split.

Removed

  • Previous Cap Mechanism: The limit to receive from the DBA at 7.5% and the threshold at the max allocation (20% today) removed.

All other DBA functionality regarding proof requirements, endorsement status and distribution remain as-is.

3 Likes
2

This proposal was initially written as a vote % based split to the DBA but that implementation suffered from a few issues:

  • The calculations quickly become complex with multiple rounds of overflow/caps to handle. While the current calculations are handled off-chain, the intent is for that to be on-chain the future. We should try to reduce complexity.
  • The top 5 dapps gained the most, leaving the other 45 apps with a large decrease compared with today. The current DBA does a good job at ‘padding’ the middle dApps in terms of allocation, we don’t want to remove that in my opinion.
  • The proposal as written above achieves the intended effect (increased incentives to earn votes to benefit from the DBA) without the increased complexity.

Open questions:

Should we lower the max allocation to 15%?

20% has worked out well with fewer dApps but feels outdated with the growing amount of apps. However, it does increase the DBA pool significantly, meaning some voting tiers might benefit more from the DBA than from votes. It means an increased amount to the VBD treasury as well.

Is a 2x cap sufficient?

The Merit Cap at 2x was selected to not be overly restrictive or free. A lower cap further restricts the bottom dApps while a higher cap lessens the impact of the change to address the bottom end.

What’s next?

This proposal is intentionally written as a ‘phase 1’ to address the large issue with an overallocation on the DBA on the bottom end, significantly out-scaling the allocations received from the intended governance but further adjustments might be needed to address the final ‘quality’ of the dApp (navigators? change in the QF formula to not weigh super small voters as heavily?)

3

Great work on outlining the potential benefits and consequences of implementing this proposal. Since the rationale is to prevent malicious dApps from draining the treasury and walking away with most of their allocation, I would be interested in seeing an additional merit factor based on how much a dApp redistributes its allocation.
this would be calculated as an average taken since first allocation received : #B3TR received /#B3TR distributed.
Expected target 65% - if within 60_ 70 range factor = 1
if 30-60 F = 0.5
if below 30 F = 0.2
if 70 - 80 F= 2
if 80-90 = 3

4

Hey! Thanks. I fully agree with you, I did consider that but ultimately decided against it for this proposal because I think it’s an issue that affects the allocation as a whole and not specifically a DBA issue. The normal vote allocation suffers from the same issues, and in an effort to limit scope and complexity, I left it out.

I think it’s something we should definitely explore but it’s a larger issue and requires delicate implementation as well. It’s a perfect thing to have for phase 2 in my opinion - maybe the navigators ([VeBetterDAO Proposal] Activating Governance - From Lazy Votes to Curated Stewardship from @SunnyLu ) play a part in that process. While tying allocations to the b3tr distributed is a good idea, it doesn’t fully take into consideration market volatility, who gets the rewards, security, overall dApp quality (roadmap, revenue streams, impact) etc. How much a dapp distributes is just one factor to consider IMO.

So yes I agree with you, but I think it’s too complex of a topic to include in the scope of this proposal. I fear it would push the implementation of this months into the future (ties it with the result of the navigator proposal in a way) instead of relatively soon.

5

Fair enough. That’s precisely why referendums typically focus on a single question — adding multiple layers can distort intent and create unintended bias. This topic can be parked for a separate proposal, but it should eventually be addressed, as it may introduce unfairness between dApps if left unresolved.

2 Likes
6

victor-wu.eth (founder/owner of BigBottle) posted this as a response to my X post about this proposal:

Let me share my honest opinion—I hope you don’t mind. I deeply respect your contributions to the community.

However, during the initial DBA phase, the standard was set that 75% of weekly voting revenue had to be donated to users to qualify for DBA. I don’t know whether this standard was actually enforced. But from my perspective, it seems like you’re just going through the motions to prove you’re doing something.

Ultimately, are these Dapps the reason VeBetterDAO has become a shell of its former self? Aside from treating these underperforming Dapps with suspicion, have you ever considered whether their weekly earnings can even sustain meaningful development?

Oh, if you believe VeBetterDAO should eventually resemble a “survival of the fittest” scenario where only 3-5 Dapps remain, then I suppose you’re doing the right thing. I can understand your point about BigBottle’s weekly DBA income barely covering operational costs—and that’s without me selling a single B3TR token. If I did, some in the community would surely accuse me of “dumping tokens.” Honestly, I respect your work, but the current situation wasn’t caused by these Dapps or by me. Do you really find it burdensome to receive a few dozen dollars a month from DBA? If so, maybe you should try developing a few more Dapps yourselves.

I promised I’d copy it over here and respond for everyone’s awareness as an X post is easy to miss.

Addressing one concern at a time:

However, during the initial DBA phase, the standard was set that 75% of weekly voting revenue had to be donated to users to qualify for DBA. I don’t know whether this standard was actually enforced.

I have not seen this 75% reward distribution requirement anywhere. It’s not listed in the approved proposal, and the DBAPool.sol source specifically references the proposal criteria as the off-chain calculation parameters.

If there’s a 75% requirement somewhere I’ve missed I’ll happily see it, but I’ve never seen it in writing or enforced on-chain. Had it been part of the original proposal I likely would have taken a different approach on the DBA. However, I do have some concerns with that approach as well (see https://x.com/ReheatVet/status/1931938097287024689?s=20), but that’s another topic.

Ultimately, are these Dapps the reason VeBetterDAO has become a shell of its former self? Aside from treating these underperforming Dapps with suspicion, have you ever considered whether their weekly earnings can even sustain meaningful development?

I have considered that a great deal. Which is why I put it as a risk in the proposal:

Yes, I agree it’s a risk - especially at this valuation for B3TR. But even with the current DBA, I am seeing an extremely low development rate across almost every single dApp. Multiple projects lack roadmap, revenue plans (it’s very clear that we can’t keep relying on the allocations to fully fund development - dApps need outside revenue streams), communications or anything else to signify there’s development going on.

For as long as they can keep relying on other dApps’ success to gain 10X more than what voters decide their dApp is worth all things considered, I don’t see why they would spend the resources to develop something more than the bare minimum we’re seeing.

If you are struggling with votes, really trying, and can’t fund the dApp’s development/survival yourself, there is the grant process as described above.

Oh, if you believe VeBetterDAO should eventually resemble a “survival of the fittest” scenario where only 3-5 Dapps remain, then I suppose you’re doing the right thing.

Maybe it wasn’t clear, but the proposal was specifically updated NOT to have a scenario where 3-5 dApps remain. As noted here:

If what you’re saying is my intention, I would have proposed the original solution. But as I was calculating the results it would have, I realized it didn’t fit the vision I had. The DBA did a great job ‘smoothing out’ the top-heavy balance of the allocation, but it’s imbalanced at the very bottom end, as described in my proposal.

Further, I don’t think you’ve fully understood the open questions. As noted here:

By limiting the max allocation to 15%, I’m inviting dApps to have a larger overall DBA Pool, diminishing the strength of the top few dApps more than today. If I wanted a survival of the fittest, I wouldn’t lower the max allocation.

I intentionally left an open question to everyone. Is the cap I set fine, or is it too aggressive? We could bump it up to 3X to see how that plays out in calculations. But it feels like you are trying to attack me, saying I have a hidden agenda to kill lower allocated dApps, when the open questions I left was specifically addressed to concerns like yours.

I can understand your point about BigBottle’s weekly DBA income barely covering operational costs—and that’s without me selling a single B3TR token. If I did, some in the community would surely accuse me of “dumping tokens.”

The proposal never mentions BigBottle nor the $ value of the DBA. It’s addressing the issue that dApps are heavily favored to live on the DBA by doing the bare minimum instead of trying to climb ranks in votes. If you have no reason to earn votes, then the entire governance part of the DAO is broken. ‘Dumping tokens’ is not the concern I’m addressing with the proposal - if it was, I would’ve rather removed it (the DBA) altogether.

If my proposal is implemented, the same amount of B3TR is distributed weekly and can be sold just as well by the ‘new’ dApps getting it. That’s why I’m not focusing on the value / what dApps DO with the tokens they receive, it’s that the incentives are so grossly misaligned at the bottom end.

Honestly, I respect your work, but the current situation wasn’t caused by these Dapps or by me. Do you really find it burdensome to receive a few dozen dollars a month from DBA? If so, maybe you should try developing a few more Dapps yourselves.

Again, see point above. The proposal tackles the DBA distribution method, not the B3TR price specifically. But to your point - yes, it does bother me to see multiple dApps launch an app that promises rewards for scanning something and then have AI analyze it, with no development outside that ‘core loop’ for months., or ever.

But I don’t consider that a DBA issue per se, it’s more of an issue with low requirements for endorsements and/or creator NFT mints. We could address that issue in other ways unrelated to the DBA.

It doesn’t bother me that dApps get a few dozen dollars a month (per dApp), it bothers me that the tokens they get are handed to them for free for just existing.

And finally - I’ll take your statement about “developing a few more Dapps yourselves” as just low awareness:

  • Firstly, if my plan was to develop a few more dApps, I wouldn’t propose this proposal, as it actively would hurt me. It’s better for me to focus on one dApp and make it as good as I can to earn votes then. Without the proposal, multiple dApps of low quality is incentivized.
  • Secondly, I’ve spent the better part of a year developing WalletWatcher, with hundreds of hours of unpaid labor, with infrastructure costs paid by myself, to ultimately have a product that would benefit the DAO and VeChain as a whole so I’d like to think I have a very good understanding of the importance of “a few dozen dollars”.

I hope this clears things up a little bit. Please, if you do have concerns, don’t assume I have a hidden agenda to force a situation to occur when you’ve not seen the open questions I specifically left to discuss it.

3 Likes
7

Looks solid, cheers mate

1 Like
8

reheat I’ve thought it over carefully, and I believe I should leave a message here—otherwise, it would be disrespectful to you. First of all, I owe you an apology. Yesterday, I might have been feeling down. A lot of unfortunate things have happened over the past six months, which has made my emotions quite unstable. Secondly, I did miscalculate the DBA allocation. I’ve already added my thoughts on X yesterday—we might need to address other matters first before tackling this one. The issue isn’t these zombie apps, but rather why more new/high-quality apps aren’t coming in.

For example, could we evaluate a “Best Update Award” every three months? Each app could submit before-and-after comparisons, and then delegates (I saw this concept in your proposal discussions) could vote. Note that allowing only “no” votes would help prevent shady dealings (otherwise, “yes” votes might just be subjective, like saying “I like this”). Additionally, we should limit the voting power of dApps themselves. As I mentioned, many apps allocate 100% of votes to themselves internally, which is practically holding users hostage.

There are many more issues, but I won’t list them all here. My point is that while the current DBA is indeed a problem, it’s not the one we need to solve first—we have a lot more work ahead. The DBA does have its flaws, but they’re clearly not urgent.

On another note, I’ve been deeply immersed in Vibe Coding lately, so expect a massive update for BigBottle very soon.

9

Fully support this
There are too many dapps just “sitting on the DAO” with no real roadmap/feature improvement happening, its like they got the reward loop done, then just paused. To me only dApps that are continuously iterating to improve their dApp and attract users should be incentivised to keep doing so.

dApp owners should be investing in their own dApp - not just relying on the success of others. If the owner thinks “my app could go viral”, they should either invest in it themselves, seek a grant or ask for outside investors.

I’ve heard a few dApp owners complain they cannot meeting their operating costs with their allocation share - this to me is normal, cant expect something to be profitable from day1. dApps with a good roadmap should be running negative until they get user traction.

1 Like
10

I want to echo DaveL in throwing full support behind this DBA update.

What is the DAO?

Well, I believe it is first and foremost a business incubator - not a ‘forever reward machine.’ And so this update serves to halt the undeserved reward leakage at the bottom end, and instead weight reward towards the top end… and thereby making the weekly vote, the voice of the people, more meaningful.

The rewards must have a purpose - they must be a driver for innovation and performance… not just a reward for rewards sake. After over a year watching activity on the DAO, it can be quickly obvious which Dapps have scope and vision… and which Dapps are simply there to leech token from the system.

Under these market conditions, while things aren’t looking so rosy, the community should be using this time by looking to find the holes in the leaky boat - and plug those holes. This proposal update does just that… a community, vote based, check and balance AGAINST the unwarranted reward… and a vote FOR High Performance. So I applaud the proposal update author here.

Until the recent horrific market conditions, and the fact that grants are based in $B3TR token, I never saw the sense in distributing token back into the treasury… but, right now, knowing then actual Treasury numbers and what impact a successful $30K grant proposal would have upon the treasury (after conversion)… well, I am now behind this particular update as well. Makes total sense.

Generally speaking, the update fortifies the DAO. I look forward to supporting this one.

3 Likes
11

I have to agree with everything you reply with @reheat! I think this proposal will be necessary to make sure dapps get better to try to get more votes. Because atm some of them are just chilling with their dba

1 Like
12

I have serious concern about this proposal.

We used to have minimum allocation to each DApp to encourage and help the new DApps. And after running for a while, a proposal was issued and approved to remove base allocation due to the “lazy apps”. The goal is to optimize the resource (token) allocation to the user favorable applications.

And then, another proposal was issued to create DBA - it ends up averagely applications including lazy apps got more than the previous base allocations. It went backwards.

And if we reduce 20% cap to 15%, there will be more token goes to DBA.

Don’t get me wrong, reduction of cap is one of my ideas but it has to be implemented after Navigator plan which is the real solution to address “token allocation or distribution issues”.

And even putting 2x cap for everyone is not a good idea - think from this way: application got the allocation base on their performance and support from users, and then application will get “passive income without any efforts” twice than the earned portion. It doesn’t feel right.

Don’t forget the purpose of the design - let community (voting power) to decide the resource allocation to the right applications other than providing nutrition to everyone averagely.

The current issues are caused by “lazy votes” or “irresponsible votes” other than this change. I would say we should implement proposal to address “lazy votes” and then circulate back to this topic to iterate base on the results.

13

I tend to agree with everyone else here. There are many current issues, and I don’t believe the lazy voter proposal will force dApps to get better which is what this proposal is trying to solve. Maybe (strong maybe) the navigator phase would do that, but we’re still early on that proposal and it needs a lot of fleshing out.

The base allocation was too extreme, but the DBA was an overcorrection. This proposal tries to be in the middle and we need a fix because the value of b3tr needs to be saving.

What kinda changes would folks like to see who oppose to support it? Keep the max 20%? The lowering is to help refuel the treasury as well as defend against ghost voters. The lazy vote proposal would of course limit the rewards these ghost voters get, but doesn’t limit their vote power.

Is that something to be considered?

2 Likes
14

With the example seen in Analysis spreadsheet the distributed amount to dApps would increase only by ~20k b3tr, significantly increasing the weight of the votes (dApps with less votes will get less funding opposed to the current DBA distribution system). With that said, all depends on the overflow over the 15% max vote threshold combined with the voting behavior of users. And this is what we really want - less freeriding, more power to the voters.

See my comment above. In reality, the middle field of the dApps would get more (as seen in the example of round 81), while the lower field would get less. This is an improvement.
With the current situation, dApps with ~300 b3tr allocation get 6k DBA, but with the new system the DBA they receive would only be 2x from their allocation. Less funding to dApps that don’t receive the support of the voters.

Exactly! You already agree with Reheat what is proposing - an improved DBA distribution system, that is more dictated by the outcome of the voting, rather than distributing the DBA evenly.

No, I 100% disagree with this. Your proposal to address the lazy votes will not fix the problem caused by DBA, where dApps receiving a mere fraction of votes, get full DBA funding. See my audit on 7 affiliated dapps. Septet of the Dao
Even if the voting behavior changes, the bottom of the list would still get the full DBA funding, creating an unhealthy incentive to create multiple low-effort dApps. Even if a dApp receives 1 vote (theoretically), but they are endorsed and have distributed rewards with proof, they get full DBA. This can’t be fixed with how voters are rewarded.

Lazy vote proposal addresses how rewards are distributed to the voters, but it has very little to no effect to how easy it is to get free funding with DBA.

What Reheat proposes is a quick fix to reduce the free funds to the dApps that don’t necessarily bring value to the DAO. On top of that, this is based on voting behavior, reintroduces the flow of funds to the treasury.

1 Like
15

Hey everyone. Some updates on the proposal. Thanks for the comments everyone, sorry it’s taken a few days to reply. Long post incoming addressing questions and sharing updates. If you just want to see what’s changing, scroll down to the header for it.

Proposal goes up for support next round! Final call.

I’ll address things chronologically:
@victorGPT - thanks for responding here directly. Definitely no hard feelings, appreciate your concerns. I don’t want a proposal with no feedback given.

I 100% agree there are other issues, and your ideas are cool, but I think they’re best saved for either the Navigator’s proposal from @SunnyLu in some form, or a different proposal entirely. dApps not coming in and/or staying rather feels like a platform issue than a DBA-specific issue. By removing the incentive to just exist at the bottom and feed on the DBA, we can then tackle other issues. The issue is that most of them take time to develop, ideate on, and get to a good place. Addressing the DBA through this proposal is effectively a one-line code change and a change in the off-chain calculation, but it solves a large problem.

I don’t want to wait 6-12 months for other solutions while the free handouts from the DBA continue to exist on a weekly basis. See [VeBetterDAO community audit] - the septet of the DAO and [dApp Blacklisting] Immediate blacklist for vePet, VeDreamHome, VeMeal and Eatgreen for much of the reasons I don’t want to wait. (The latter is resolved, but I don’t want to see blacklist proposals on a monthly basis if we don’t have to)

Can’t wait to see whats next for BigBottle!

@DaveL , @GoldenShamrock and @MonkeyDCrypto - thanks!

@SunnyLu thanks for your comments as well! @Morb answered a lot of it in his response, and I echo pretty much every single thing he said, but I’ll pitch in a little bit as well.

Yep, fully agreed there. It went backwards. Removing the base allocation was the right call (even though I disagreed with it at the time due to uncertainties with the grant program that are now cleared up) . The DBA did help ‘smooth out’ the top-heavy allocations we see, but removing the treasury overflow entirely and having no protection for the imbalance at the bottom end, I don’t like. In addition, we’re seeing the DBA increase rapidly (from 3.57k per dapp at launch to 7k per dapp now), so the issues grow larger weekly.

Reducing the cap does increase the DBA pool, yes, but from my calculations we are not seeing an effective increase. Because of the merit cap, most of the increase in DBA pool just goes to the treasury and/or to dApps higher up in votes. More on the max allocation cap % later.

I disagree here. Firstly, the navigator plan needs more time. Both in planning (plenty of open discussions there IMO), and to see effects of phase 1 play out. And as I answered Victor above, I’d rather we get this proposal implemented first, given its ease of implementation and effect.

Second, I don’t think we will see a huge change in token allocations in the short term. Phase 1 will from what I’m seeing primarily address voter rewards, better distributing them to active voters over the lazy ones.

That’s good, but I don’t foresee much of a difference in actual allocations given that most voters for Mugshot and Greencart’s voters are using veDelegate already (93% and 88% of voters respectively used VD last round (ignoring QF, but still)). They’re already giving up 10%, knowingly or unknowingly, and will take time to transition over to manual voting if even possible (most use in-app voting so they’re never even exposed to manual voting).

With Navigators and phase 2, yes, things can change. But again, that’s realistically not in place anytime soon. We have the split endorsement proposal & cosmic climb in the pipeline as well, both requiring dev time.

Adjusting the DBA is a quick win as I see it. Small technical change and would likely distribute over a million B3TR to more voter-for dApps, while we ideate and implement the other solutions.

Same thing here really. The 2X cap is possibly giving too much to some dApps, but in a round-about way it does address lazy voters as well.

If we have 10 lazy voters to each active voter (in terms of raw accounts voting) - not unrealistic given the 85-93% VD usage we’re seeing (53% of total quadratic weight recent rounds) - the active voter’s impact is greatly reduced. From every round and dApp I’ve looked at, there’s a higher % of automated votes, the higher your allocation received.

By redirecting some of the ‘lazy voters’ votes back to the dApps that have a higher % share of active voters, we reduce the impact of the lazy voters, through the DBA (provided the dba respects actual votes received and isn’t an even split)

Maybe that doesn’t make sense, happy to explain my thought process further if needed.

And if we DO see a great effect from phase 1 & 2 of the lazy voter proposal (or other proposals/changes), and we see a better curve on allocations, then great, the DBA has limited/no effect. But the trend is going the wrong direction (doubled DBA in 3-4 months), so I don’t think we can afford to wait.

Now, some actual changes to the proposal:

The main goal of the proposal is to fix the imbalance at the bottom end. Reducing the max allocation is not the primary goal, but a) we can’t ever reduce it without first fixing the DBA distribution and b) the proposal removes the 7.5% and 20% threshold, so if we leave it at 20%, only the top 3 dApps benefit as shown here:

image
image1894×416 46.8 KB

That goes against the goal of this proposal as well as the original DBA proposal.

So a reduction is needed, but 15% might be too much of a shift at once. The goal of the proposal isn’t to strip allocation from Mugshot and Greencart, but when speaking with both Mugshot and Greencart, they’re both worried about such a large shift overnight (15% is ~ -69k respectively).

Therefore, I’ve updated the max allocation suggestion to 17.5%, up from the 15% it was at before. With the same round 81 calculation sheet from before, we see a ~ -32k change instead.

image
image1446×930 79.9 KB

Once the DBA is added back on top to them, we’re looking at an 18% effective max allocation. This still gives every dApp at the 2X Merit Cap a ~1.3k increase in their DBA allocation, and ~101K to the VBD Treasury from the dApps below the cap, without causing a huge decrease for Mugshot & Greencart.

Once the other proposals are executed, changing the max allocation number again might be worth revisiting, but for now I’d rather we fix the DBA and balance things as well as possible for every dApp in the DAO.

Finally, I plan on putting this proposal up for support next week. So last chance to adjust / give feedback on it. After that, it’s up to governance to see if it’s supported and approved or not.

3 Likes
16

It has been posted for support now!

2 Likes