Once you support you can withdraw only at end of the lifecycle of the proposal, so no.
2 Likes
You’ve nailed the point: the issue isn’t abstaining itself, since that’s still a conscious choice by the user — the real problem is the automatic delegation that expresses abstention by default. It’s like someone deciding not to vote in a political election, but another person submits a blank ballot on their behalf without their direct consent.
1 Like
That is true its not extra rewards but it ensures they get the most in that round. If its the same as voting yes, it just gives a support phase less meaning.
Locking the VOT3 was and still is a necessary evil that shouldn’t be changed besides the amount required. If we give those who support the same voting power, whales in theory can support an entire proposal almost single handedly and then vote again to get the most rewards. You could add a limit one person can support with but that is circumvented with multiple wallets. We should not look to create more problems that need to be solved.
My main reasoning for removing rewards all together is that its unfair that only those who vote afterwards reap the benefits. And while it may be the maximum form of engagement, not that many people actively engage in it as compared to voting for dApp allocations. The actual voting phase on proposals might even be harder to pass in future if veDelegate removes automated abstentions. I believe we should make it for those who really give a damn, rewards or no rewards.
I understand where you’re coming from. But with the direction this proposal is heading, the core idea is that people who lock their VOT3 to support a proposal should still have voting power with those tokens. Since their VOT3 is already locked, this change doesn’t reduce the commitment—it just allows them to stay active and earn rewards through dApp voting while still backing a proposal.
This actually makes things fairer for everyone. Right now, supporters lose out on voting rewards while their tokens are tied up. This approach keeps their liquidity locked (so the risk stays), but it lets them participate fully. Whether whales support a proposal is always a possibility—but this system doesn’t increase that risk, it just evens the playing field.
That said, I think the main thing we need to focus on now is exactly what Dan pointed out: figuring out whether we need to adjust the amount of VOT3 required to support a proposal. I agree with him—it shouldn’t be too easy to reach, and I’m looking forward to the data Ben said he’d share on how other DAOs handle this.
Maybe discussions around abstains and veDelegate could be spun into a separate thread as I feel like that is an interesting discussion as well
Well if its only voting on dApp allocation then that is fine (although you will still earn less than those who vote in both) but I hadn’t read any posts here where that would be the case. I am just strongly against VOT3 used to support being used to vote on the same proposal. It defeats the purpose of having a support phase. In doing so would set a dangerous precedent.
If we focus on the other suggestions here we can make proposals much easier but still challenging to reach without changing the lock mechanic and then we won’t need to lock up everything and can earn voting rewards with what we have left.
To summarise my thoughts on the key points suggested here.
I completely agree on the following:
- Creating proposals here with at least a week in between submitting on the DAO
- GM NFT 2 on wards to create proposals
- B3MO AI Draft check
- Cap/decay on support requirement
I disagree on:
- Using the same VOT3 used to support in the voting phase in any capacity.
I agree in priniciple but with slight adjustments:
-
Stake to submit
– The amount is yet to be finalised but yes the proposer should be required to support their own proposal upon submission. But I don’t see a need to return the VOT3 unless it fails to reach support before the snapshot or until the voting phase has ended, similar to my previous point. -
VOT3 used to support being withdrawn
– The proposals deadline should end just before the snapshot and if it fails to reach support, only then the VOT3 is returned allowing those who supported to participate in the following round. If you support you support, no ifs/buts.
1 Like
Quoting these as I think these points have gone under the radar.
2 Likes
New System (Inspired by @ltcSpitfire)
In the reality of a DAO, the greater responsibility lies with the people who support bad proposals — not just the ones who write them. If there’s no risk in supporting, it becomes meaningless. This introduces real consequences and rewards to ensure skin in the game. I think we can rework the incentive.
Proposed Mechanism
Proposer:
Proposer’s VOT3 is locked through the Support stage, as usual, and they forfeit dApp allocation rewards during that time.
Supporters:
-
If the proposal passes the support threshold. (Which can be adjusted to an hour or so before voting round ends):
Their VOT3 remains active, and they earn dApp allocation rewards. -
If the proposal fails to reach the support threshold:
Their VOT3 is locked until the round ends, and they miss dApp allocation rewards.
This system encourages more thoughtful support — you’re rewarded if you help push a good idea forward, and penalized if you back a weak one. It also pairs well with the other features @Dan said:
- A forum post must be created at least 7 days before DAO submission to allow for community discussion.
- GM NFT Level 2 is required to create a proposal.
- A B3MO AI Draft Check is suggested before submission.
Now these changes all revolve around Incentive Structure & Proposal Flow. I think the next conversation could dive into Governance Mechanics cap or decay system, Vedelagte Abstains, etc..
We should also interface with the technical team and ask how long this implementation might take, I think it is right to understand the feasibility timelines as well.
Hi Dan,
My suggestion is: cap the support requirement at 5,000,000 VOT3.
This only applies when the dynamic threshold reaches the cap.
This cap should be re-evaluate periodically based on token price, supply and governance need.
Please evaluate whether it’s feasible.
Below is a lengthy ChatGPT analysis.
Community Support Threshold Analysis & Recommendation
1. Background
Currently, VeBetterDAO requires proposals to receive community support equal to 2% of the circulating supply of B3TR (as VOT3) before advancing to the formal voting phase.
This mechanism made sense in the early days of the DAO:
- Circulating supply was low, and concentrated token holdings meant higher governance risk;
- A relatively high support ratio helped filter out spam or malicious proposals.
However, as B3TR continues to be distributed weekly, the absolute number of tokens required is increasing significantly:
| Time | Circulating Supply | 2% Threshold | Approx. USD Value (at $0.10) |
|---|---|---|---|
| 2025 Q2 | ~212M | ~4.24M VOT3 | ~$424,000 |
| 2026 | ~400M | ~8M VOT3 | ~$800,000 |
| 2028 | ~600M | ~12M VOT3 | ~$1,200,000 |
If the 2% threshold remains constant, the community support requirement may become too high for most proposers to realistically achieve.
2. Benchmark: What Do Other DAOs Require?
| DAO | Requirement | Token Amount | Estimated USD Value |
|---|---|---|---|
| Uniswap | 1M UNI delegated | 1,000,000 UNI | ~$5,000,000 |
| Arbitrum | 1M ARB delegated | 1,000,000 ARB | ~$335,000 |
| Aave | 80K AAVE proposition power | 80,000 AAVE | ~$13,800,000 |
| Compound | 25,000 COMP held | 25,000 COMP | ~$1,000,000 |
| Curve | 2,500 veCRV locked | 2,500 veCRV | ~$1,786 |
3. Recommendation: Set a Cap for Community Support
To keep governance scalable and inclusive, introducing a cap on the total number of tokens required for proposal support:
3.1 Value-Based Benchmarking
When benchmarking proposal thresholds in USD-equivalent terms, it’s clear that major DAOs like Uniswap, Aave, and Compound have extremely high entry requirements, often ranging from $1M to over $10M in voting power or delegated tokens.
Where Does VeBetterDAO Fit?
Given that VeBetterDAO is still in a scaling phase:
- We should not blindly replicate top-tier thresholds like Uniswap or Aave — those DAOs operate at a different level of capital density;
- But we also should not drop below a level that fails to reflect proposal seriousness.
Choosing a value between $400K–$500K USD places us:
- Above the “too easy” zone (e.g., <$200K), where low-effort proposals could flood the system;
- Below the “elite-only” zone (>$1M+), which risks centralizing governance to only a few large holders;
- In line with Arbitrum, which has similar tokenomics scale and community dynamics.
In this context, a support threshold equivalent to ~5M VOT3 at $0.08–$0.10/token is a reasonable and well-balanced choice — serious but not exclusionary.
3.2：Token Supply-Based Analysis
Rather than anchoring the threshold in dollar value alone, we also analyzed the projected growth of B3TR supply over time — based on the 12-year linear emission schedule.
As visualized below, the absolute token amount required for proposal support increases rapidly with B3TR issuance, even under reduced ratio assumptions:
From the chart, we observe:
- At Week 20 (now), the 2% support threshold is ~4.2–4.4M VOT3;
- Once circulating supply reaches 1 billion, 2% = 20 million VOT3;
- Even 1% will eventually exceed 10 million tokens — a high bar for most community efforts.
Phased Ratio Reduction Model
To ensure long-term accessibility, a progressive reduction in the support ratio, aligned with token supply milestones:
Time Point Token Supply (est.) Suggested Ratio Support Required (VOT3) Est. USD Value (@ $0.10) 2025 Q2 (Now) ~212M 2% ~4.24M ~$424K 2026 Q2 ~400M 1.5% ~6M ~$600K 2027 Q2 ~600M 1% ~6M ~$600K 2029 Q2 ~800M 0.75% ~6M ~$600K 2031+ (Full) ~1B 0.5% ~5M ~$500K As shown in the chart above:
- A 2% threshold reaches the 5M mark around week 250 (roughly early 2026);
- A 1% threshold exceeds 5M by week 500 (late 2027);
- Even a 0.5% threshold approaches 5M in later stages (by 2031–2032).
4. Final Consideration:
In addition to the analysis above, some final points reinforce the rationale for setting this cap:
- Most mature DAOs include a “temperature check” phase before moving to an on-chain vote. In VeBetterDAO, the proposal support stage serves as the equivalent mechanism for early community signaling. As such, the threshold for support should not be as low as the initial submission requirement — it must reflect a meaningful level of consensus.
- Additionally, if VOT3 tokens deposited for proposal support will count toward voting power in the final vote. This change is likely to encourage more participation in the support phase.
Based on the above, I think a 5M cap is reasonable.
- It only applies when the dynamic threshold (e.g. 2%) exceeds 5M — otherwise, the ratio-based rule remains in effect;
The cap should be re-evaluated periodically based on B3TR price, token supply, and actual governance participation.
2 Likes
We should also interface with the technical team and ask how long this implementation might take, I think it is right to understand the feasibility timelines as well.
You can use me as a middleman for the technical team in this case. But what I would suggest is to keep those changes as small, but also effective, as possible. Doing big changes in the contracts does not pose only technical limitations but could introduce bugs or attack vectors.
I think what Quorum should be adjusted to should be discussed in that thread as well. As many proposals struggled with Quorum before those Vedelegate abstains.
If you look at the 2 currently voted proposals you can see how both of them already reached quorum, without veDelegate casting the votes of their users, so to me seems that the quorum does not have any issue, actually we even lowered that a few months ago.
I think we are at good point with this discussion. Personally I would like to take some extra time to address my initial concerns and the concerns of @ltcSpitfire .
I will try to do some simulations and try to come with some considerations around those concerns.
3 Likes
I share similar concerns with Spitfire regarding the VOT3 used in supporting a proposal should not be used to vote on the same proposal.
Yeah, sure, we can argue participation in supporting proposals from regular users is low, but I don’t think this should be addressed at expense of safety of DAO.
As Dan mentioned, we don’t want to introduce new vectors of attacks/abuse.
In short - I personally don’t want to change the lock-up period of VOT3 used for supporting proposals.
2 Likes
Would it be enough to say that those VOT3 tokens are available as voting power only for allocation rounds and not for proposals?
It will still add “skin in the game” because you will lose some rewards but not all. Plus large holders won’t be able to support and vote their own proposals
2 Likes
That sounds reasonable. Less penalty for supporting a proposal without introducing new vectors of possible abuse.
2 Likes
I like this idea and the balance it strikes — it encourages thoughtful participation by adding real cost to voting, but still avoids giving large holders undue influence over proposals. It feels like a fair middle ground.