Proposal: VeBetterDAO Community Execution Framework

VeBetterDAO
1

Executive Summary

This proposal introduces a next-phase evolution of VeBetterDAO governance: a Community Execution Framework designed to expand participation, unlock developer contribution, and strengthen decentralisation while preserving security and delivery discipline.

The purpose of this proposal is to formalise a scalable and decentralized execution structure that:

  • Opens the DAO to a broader developer community

  • Encourages builders to actively participate in governance-driven innovation

  • Aligns execution incentives with long-term ecosystem growth

  • Maintains strict security oversight through VeChain review and deployment

VeBetterDAO is entering a stage where governance must evolve from decision-making alone into structured, community-driven execution. This proposal represents a meaningful step toward that future.

Long-Term Vision and Rationale

VeBetterDAO’s long-term ambition is to become a truly community-driven ecosystem where governance decisions translate into high-quality, production-ready implementations without creating internal bottlenecks.

To achieve that, three elements must coexist:

  1. Clear Governance Authority— The DAO defines what should be built and approves budget caps.

  2. Open Builder Participation— Developers across the ecosystem can contribute directly to DAO growth.

  3. Strong Security and Delivery Guarantees— VeChain retains final review and deployment authority.

This framework is designed to strengthen all three pillars.

Rather than concentrating execution within a single internal team, this model invites the community to build alongside the Foundation. Proposal authors step into leadership roles, developers are incentivised through clear budget alignment, and VeChain ensures technical integrity.

The ambition is not incremental improvement; it is to establish VeBetterDAO as a governance system that is:

  • Scalable

  • Accountable

  • Secure

  • Decentralised in participation and execution

  • Clear in financial discipline

By embedding execution responsibility into governance itself, VeBetterDAO moves closer to the spirit of decentralisation: decisions are made by the DAO, and delivery is enabled by the ecosystem.

This proposal represents a structural evolution in how VeBetterDAO operates, positioning it for sustainable long-term growth.

Proposal Requirements (New Standard)

Every governance proposal that requires technical implementation must include:

  1. Maximum Implementation Budget

  2. Denominated in B3TR

  3. Paid from the VeBetter treasury

  4. Acts as a hard cap

  5. Ideal Development Timeline

  6. Estimated duration to complete the implementation

Proposals without a defined maximum budget and timeline will not be eligible for execution under this framework.

If additional funding is required beyond the approved maximum, a new governance proposal must be submitted.

Execution Process

Step 1 — Governance Approval

  1. Proposal is submitted with scope, maximum budget, and timeline.

  2. The DAO votes.

  3. If approved, the proposal moves into execution.

Step 2 — Proposal Author Becomes Execution Lead

Once approved:

  • The proposal author becomes responsible for execution coordination.

  • The author must:

  • Identify and select a developer or development team

  • Oversee implementation progress

  • Ensure delivery aligns with approved scope

The proposal author effectively acts as the product owner for that proposal.

There is no centralized Foundation-controlled developer selection mechanism under this model.

Step 3 — Development

The selected developer may implement:

  • Smart contracts

  • Frontend components

  • Integrations

All development must strictly follow the approved proposal scope. In case of development or changes needed on other VeChain services that VeBetter relys on, such as Lambdas, Indexer etc., the developer should get in touch with VeChain who will provide support.

Step 4 — Technical Review and Audit by VeChain

All code must be submitted to VeChain via pull requests.

VeChain acts as:

  • Technical reviewer

  • Security auditor

  • Final approver for merge and deployment

If the implementation meets standards:

  • VeChain approves the PR

  • Code is merged

  • Deployment to production is executed

If the implementation does not meet standards:

  • VeChain provides technical or security feedback

  • The developer must revise and resubmit

  • Approval occurs only once all requirements are satisfied

Step 5 — Treasury Payment Mechanism

The treasury payment process is status-driven and tied to proposal lifecycle updates on VeBetter.

1. Marking as “In Development”

Once governance has approved a proposal, the proposal author must:

  • Mark the proposal as“In Development”on VeBetter

  • Specify the final implementation budget, which must not exceed the maximum cap approved during the voting phase

  • Provide the selected developer’s:

  • Wallet address (to receive payment)

  • Developer nickname / identifier

No payment configuration may exceed the originally approved maximum budget.

2. Development and Review

The developer completes the implementation and submits PRs to VeChain.

VeChain conducts technical and security review. If revisions are required, the developer must update the code until it satisfies VeChain’s requirements.

3. Marking as “Completed” and Triggering Payment

Once:

  • The PR is approved

  • Code is merged

  • The implementation is deployed to production

VeChain will mark the proposal as“Completed”on VeBetter.

Marking the proposal as “Completed” automatically triggers payment from the VeBetter treasury in B3TR to the developer wallet address previously registered by the proposal author.

4. Developer Address Changes

If the developer wallet address needs to be modified during the implementation process, the proposal author must formally request the change to VeChain.

VeChain must approve and execute the address update before completion. No unilateral address changes are permitted by the proposer without VeChain validation.

This structure ensures:

  • Budget discipline (cap enforced at governance level)

  • Clear proposer accountability

  • Security validation before funds release

  • Automated payment only after successful deployment

  • Protection against unauthorized payout modifications

Governance and Neutrality Principles

  • Governance defines scope, budget, and timeline.

  • Proposal authors own delivery coordination.

  • Developers execute implementation.

  • VeChain ensures security and protocol integrity.

There is no execution priority for VeChain team.

If a proposal presents significant technical constraints or complexity, VeChain may propose itself as the implementing party under the same governance-approved budget.

Accountability Structure

  • Proposal Author → Responsible for delivery coordination.

  • Developer → Responsible for implementation quality and code integrity.

  • VeChain → Responsible for technical review, audit, merge, and deployment.

Final legal responsibility allocation will be aligned with legal counsel where necessary.

Proposal Implementation Guidelines for Proposers and Developers

To ensure long-term sustainability and architectural consistency, all proposers and developers must follow these principles when designing and implementing proposals:

1. Preserve Decentralization

Solutions must avoid introducing unnecessary intermediaries, centralized control layers, or single points of failure. Architectures should align with VeBetterDAO’s decentralized ethos and minimize trust assumptions.

2. Keep It Simple

Avoid over-architected systems, excessive abstraction, or unnecessarily complex mechanics. Implementations should be understandable, maintainable, and realistically deployable. Simplicity is preferred over sophistication.

3. Improve the System Structurally, Not Incrementally

Proposals should aim to improve the DAO framework holistically rather than repeatedly adjusting minor parameters or single variables. The focus should be on durable structural improvements that reduce the need for frequent rule changes.

Benefits

  • Scalable execution model

  • Clear treasury discipline through upfront budget caps

  • Incentive alignment via post-delivery payment

  • Reduced internal bottlenecks

  • Maintained security and deployment control

Considerations and Clarifications

Budget Definition and Developer Coordination

Proposal authors may not always know the exact implementation budget or developer from the start. In practice, proposers are encouraged to collaborate with developers during the discussion phase on Discourse to estimate scope, timeline, and costs before submission. This process aims to strengthen collaboration between idea creators and builders.

Technical Review and Auditing

At this stage, VeChain Foundation will act as the primary technical reviewer to guarantee security and protocol integrity, given that parts of the stack are not yet fully open sourced. As the ecosystem matures and more components become open, the review layer can expand to include additional independent auditors.

Conclusion

VeBetterDAO was created to pioneer a better model for incentivised, community-driven impact. As governance matures, our execution model must mature with it.

This proposal is about expanding participation, aligning capital with delivery and accountability and about stepping forward into a more decentralised, scalable future.

By embedding budget discipline into governance, empowering proposal authors to lead execution, opening the door to ecosystem developers, and maintaining VeChain’s uncompromising security oversight, we establish a governance system that is both ambitious and responsible.

This framework means:

  • VeBetterDAO is open to builders.

  • Governance decisions lead to real, production-grade outcomes.

  • Decentralisation is not theoretical, it is operational.

This will mark a meaningful evolution in how VeBetterDAO operates, transforming governance from a voting mechanism into a structured engine for ecosystem growth.

This is the next step toward a DAO that is not only participatory in decision-making, but powerful in execution.

3 Likes
2

Hey! Thanks for taking the time to put this proposal together.

Overall, I’m very excited for it! It’s scary to ‘rip the bandaid’ and effectively remove one more bootstrapping mechanism, but it’s one that needed to happen at some point on the way to full decentralization.

I am a bit worried in that we already have few proposal authors outside VeChain, and this creates a much larger hurdle, but maybe it can open up an avenue for revenue for community developers that previously wouldn’t be interested in proposal discussions. Hopefully a wake-up call! I’m definitely excited for the opportunity to be more ‘hands-on’.

I have some questions that I’m hoping you could address/clarify for the final proposal:

What happens if a proposal is set with a 4 week timeline, but it fails to deliver within that time? Is it just a guide/expectation, or something stricter?

I think selecting a developer should already be done in Step 0 (discourse, discord, telegram discussions etc)., and included with the proposal itself in Step 1., as an additonal thing to vote on. A reputable developer can bring a lot of ‘weight’ or ‘trust’ in the proposal.

If no developer or team is planned for until step 2, we might see a lot of proposals go through voting but with no clear direction after that. Said developer should already be part of the discussions around the proposal to assist with feasibility, technical complexity, scalability, etc. You touch on this later in the thread already:

–

Will any formal channels for developers to contact VeChain be established? Every proposal author / community developer has a different level of direct connection with foundation developers, so a dedicated channel should be established for fairness.

A 'proposal developer hub' documentation would be great. Relevant repositories, foundation contacts, the ‘support channel’ explained above, pull request expectations/examples, testnet development for proposals (contract/frontend) work, the guidelines outlined here, and so on. A living document that can grow with time.

You touch on some topics here - but I would like to see a clear list of 'possibilities" and what isn’t possible. For example, given that there is no talk of roles here, I assume no developer will have access to call contract functions if decided by governance, to for example blacklist a dApp, withdraw from the treasury, or other role-based calls. Something that wouldn’t require any actual development but rather higher privilege, wouldn’t be possible.

A more exhaustive list of what’s possible and what requires VeChain would be great. Again, on the developer hub explained above.

Thanks for creating the guidelines and expectations! Best of luck with the proposal.

2 Likes
3

in terms of selecting a development team - how will that be done? Will there be a place where teams can register their interest in the proposal, perhaps with contact details, small background of skills etc

1 Like
4

Thanks a lot for the thoughtful feedback, really appreciate the detailed questions and it’s great to see community members already thinking about how they can participate more actively.

Let me address your points:

Timeline (e.g. 4 weeks)
The timeline should be considered primarily as a guideline and expectation, not a strict enforcement mechanism. Development timelines can sometimes shift once implementation begins. The intention is to create visibility and accountability around delivery expectations, rather than introduce rigid constraints that could block progress.

Developer selection (Step 0 vs Step 2)
You’re absolutely right that in many cases developers will already be involved during the discussion phase (Discourse, Discord, Telegram, etc.), and we strongly encourage that. Having builders participate early helps assess feasibility, complexity, and cost.

The framework keeps some flexibility so that proposals are not blocked if a developer is not finalized yet, but in practice we expect many proposals to already involve builders during the discussion stage, which can indeed add credibility and confidence to the proposal.

Developer communication with VeChain
We agree that clear communication channels are important. Developers working on proposals will have dedicated ways to reach the VeChain team for technical questions, ensuring everyone has fair access to support regardless of existing connections with the Foundation. A dedicated discord channel can be setup.

Documentation for developers
Rather than creating a separate “developer hub”, we plan to provide all relevant information in a dedicated section of the VeBetterDAO documentation. This will include resources such as:

  • Relevant repositories

  • Development guidelines

  • Testnet workflows

  • PR expectations

  • Technical support channels

This documentation can evolve over time as more community developers participate.

What developers can and cannot implement
In general, developers will be able to implement and modify all components such as:

  • Smart contracts

  • Frontend features

  • Integrations

However, developers will not receive privileged access to execute restricted contract functions or role-based actions. VeChain will need to review, approve and execute those actions.

We will make this distinction clearer in the documentation so developers have clear guidelines.

Thanks again for the thoughtful feedback, discussions like this help refine the framework and make it clearer for everyone interested in building within VeBetterDAO.

2 Likes
5

Good question.

Under this framework, the responsibility for selecting the development team sits with the proposal author, who acts as the execution lead for the proposal.

There will not be a centralized registry of developers managed by the Foundation. Instead, proposal authors are free to identify and engage developers in the way they consider most effective. This can happen through existing VeChain ecosystem channels (Discourse, Discord, Telegram, developer communities) or through external networks and collaborations. The intention is to keep this process flexible and decentralized.

Over time, as more builders become involved in VeBetterDAO development, we expect this to naturally grow into a broader network of community developers who can collaborate with proposal authors.

1 Like
6

Thanks for the clarification! I think that covers it. Looking forward to see the VBD documentation on it.

One final question about the wallet:
Would it be possible to instead of it be a ‘developer wallet’ be a list of wallets, with a predefined split?

My reasoning is that a proposal author deserve to be paid for their time just like the developer, especially now with the new requirements of managing developer(s), and an agreed-upon split is fairer than having one “developer wallet” entrusted with the full amount to then split. I can picture a scenario where the developer wallet does not fulfill any agreed amount once it’s paid out. Although unlikely, it can still happen.

Distribution, adding, changing wallet would follow the process you’ve outlined. Only change is that you can define 1 or more wallets to receive payment with the status changes, and that the % split between the wallets must be defined.

For example:

  • Proposal 1: Proposal author, 30% | Developer 70%
  • Proposal 2: Proposal author/developer, 100% (one individual with both roles, or other wallets not yet defined)
  • Proposal 3: Proposal author: 25% | Developer 1: 25% | Developer 2: 25% | Developer 3: 25%

In situations like this, it would be fairer if the distribution respected this split so there’s no risk of foul play between recipients. Is this possible, or has the one-wallet approach been selected for technical feasibility?

1 Like
7

Great point, and we agree with the concern around fairness and trust in fund distribution.

For the initial version, we prefer to keep the payment flow simple within VeBetter, meaning a single payout address is defined at the protocol level. This avoids adding additional complexity to the core system.

That said, we absolutely recognize the need for fair distribution between proposal authors and developers.

Our preferred approach is that authors and developers agree on the split off-platform, and manage it independently. For example, they can use a smart contract as the payout address. This way:

  • The agreed split is enforced trustlessly

  • There is no reliance on a single party to redistribute funds

  • We keep VeBetter’s core logic simple and secure

So in practice:

  • VeBetter pays to one address

  • That address can be a smart contract managing the split

This gives flexibility and fairness without introducing additional complexity into the platform itself.

1 Like