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:
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.
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.