Proposal: Grant Transparency & Fund Recovery

VeBetterDAO
21

let use an example

say total grant is 600k B3TR (since grant is paid out in B3TR, this is to me the unit of reference). 10% is kept for the balance evaluation = 60k
if total spent at the project (all milestones delivered) is 550k - there is a saving of 50k.

from there few options :
deduct 50% of the saving as a bonus to the grantee - so last payment will be 35k only
or
double allocation earned for say 3 months once the dApp is released for vote.
that will push DApp to work to get votes and to minimize their cost pf development under the grant

22

another point :
how do you value hours spent internally? if the grantee team is based in the US that hourly rate will be different to a team based in India.
So I suggest that a theoretical reference hourly rate is set. so applicant to grant can value their time based on reference rate. Reporting will also use that reference hourly rate.

23

In this scenario, you were given a $5000 grant and you decided to keep in the form of B3TR, which is inherently a highly volatile asset. You took the risk, perhaps hoping that the price would rise and you would get more USD out of it, but that was your decision to make. An option would have been for you to play it safe and convert it to a stable coin to lock-in the $5000.

from there few options :
deduct 50% of the saving as a bonus to the grantee - so last payment will be 35k only
or
double allocation earned for say 3 months once the dApp is released for vote.
that will push DApp to work to get votes and to minimize their cost pf development under the grant

Honestly, I think this adds more complexity to the process than Iā€™d like to have. This proposal is intended to be simple enough and straight-forward. If you receive 100k B3TR and only end up spending 50k, you return 50k in order to receive the next tranche. I have included a ā€˜bonusā€™ in the form of the final tranche. With my proposal, the final tranche is 100% yours to keep, whether you spend 100% or 0% (this is why, for the final tranche, there is a cap of 40% of the entire asking price). In my opinion, that is fair enough.

how do you value hours spent internally? if the grantee team is based in the US that hourly rate will be different to a team based in India.

I donā€™t. This is up for the dApps to decide. If your operations are based in India, ask for an amount that is suitable that country. If you are in the US, ask for an amount thatā€™s suitable for that country. The asking price for an Indian-based team should be lower than the asking price of a US based team. You spend your money how you need to spend your money, and you ask for the amount that you need to ask for. This is the entire premise of the proposal - to stop dApps from asking for money that they do not need.

If your expenditure report shows obvious overspending in a sector, that would raise flags for fraud and this would be investigated by the community & Foundation.

The goal of this proposal isnā€™t to tell people what to do with their grant money, itā€™s to have an overview as to what theyā€™re spending it on. If a dApp is spending their money foolishly, the community has a right to know and can make their voting decisions based off of it.

25

This does not necessarily mean fraud. I donā€™t know if you have experience in project costing, but the main principle is to break the project down into as many subtasks as possible and estimate the cost of each one based on several assumptions. Some tasks will inevitably be underestimated (due to unforeseen events), some will be accurate, and some will be overestimated (thanks to better efficiency). Overall, these variations balance each other out, and the project usually lands within the expected budget.

However, if you deduct the savings from certain tasks while refusing to acknowledge the overruns on others, the project will inevitably end up at a loss.

26

and then the community would have complained that a grantee is immediately cashing out the grantā€¦
note that between the B3TR amount is define at the time of the grant application while the first payout is made 3-4weeks after - the B3TR took already a dip during that time.

payment of all milestones after will suffer from the volatility of the B3TR. so my point is very relevant with regards the reporting of expenses.
So since the grant is in B3TR, grantee should report their expenses related to the program at the B3TR of the time of the expense. And that is lot of tracking work in temrs of accounting.

27

This does not necessarily mean fraud.

Of course not, hence why an investigation could be done if someone wanted to. Again, the goal is to allow for visibility. This visibility currently does not exist.

Some tasks will inevitably be underestimated (due to unforeseen events), some will be accurate, and some will be overestimated (thanks to better efficiency). Overall, these variations balance each other out, and the project usually lands within the expected budget.

Yes. So ask for more and give it back if you donā€™t use it. This allows grantees to ask for more without the community getting mad about over-asking. There is a safety net for the community in the form of the fund retrieval between each tranche.

and then the community would have complained that a grantee is immediately cashing out the grantā€¦

The community would maybe have been worried if it was fully withdrawn, because there is no obligation for dApps to declare what theyā€™re spending their money on.
With this new proposal, the community would have an expenditure report to review, so there would be no room for speculation.

In your case, a simple announcement regarding your reasons for converting to a stable coin would be perfect - but this is besides the point.

note that between the B3TR amount is define at the time of the grant application while the first payout is made 3-4weeks after - the B3TR took already a dip during that time.

Price fluctuation risk already exists in the current system. This proposal doesnā€™t introduce it, it simply makes the use of funds more visible. The goal is clarity, reasonability, and accountability, not perfect price precision.

grantee should report their expenses related to the program at the B3TR of the time of the expense. And that is lot of tracking work in temrs of accounting.

Thatā€™s a fair concern, and I agree that requiring expense-by-expense conversion at the exact B3TR price would create unnecessary overhead.

A much more practical approach would be to report spending in USD-equivalent terms, using a reasonable reference or average B3TR price for the tranche period. Hence why in my expenditure report template I used USD spent, not B3TR.

The intent here is transparency, not forensic accounting. This keeps the reporting lightweight while still giving the community clear visibility into how grant funds are being used.

28

fair enough but without incentive and without proper internal hour valuation upfront,
all projects will end up claiming they have spent all the grant money properly since they can just play with the amount and the rate of the internal hours.

the proposal being to check whether the money received is truly spent, since Grantees receive B3TR they should report expenditure in B3TR equivalent. Otherwise you can not determine if tranche is overspent/underspent.

29

  1. this is contradiction with what you wrote here ā€œā€œThis is the entire premise of the proposal - to stop dApps from asking for money that they do not need.ā€

    1. this is not how a project works. balance between budget and actual is done at the end of the project, no during the project

    So clawback should only happen at the end of the project not between tranches

30

I think weā€™re just going to have to agree to disagree on the whole faking documents side of things. I understand that they can be faked, that doesnā€™t change my mind on it being a good addition because they can be analysed and it also takes significantly more effort to fake documents than to not give any documents at all. Itā€™s a deterrent and extra barrier for fraudulent grantees to jump through, not a fix-all. For legitimate grantees, this should be nothing more than a bit of extra accountability.

since Grantees receive B3TR they should report expenditure in B3TR equivalent. Otherwise you can not determine if tranche is overspent/underspent.

You purchase things in USD so realistically it needs to be reported in USD. The B3TR/USD amount is locked at the time of submitting the grant, so that same ratio would be used. The volatility of the token is at the risk of the grantee. They can choose to exchange it for a stable coin and risk losing out if the price rises, or they can hold on to the coin if they think that it will increase in value, which would be a huge bonus. Regardless of their choice, any difference in B3TR relative to the locked USD value must be either returned to the treasury or deducted from the next tranche. Itā€™s about risk/reward.

this is contradiction with what you wrote here ā€œā€œThis is the entire premise of the proposal - to stop dApps from asking for money that they do not need.ā€

Thatā€™s my bad, what I meant to say was ā€˜to stop dApps from receiving money that they do not needā€™.

this is not how a project works. balance between budget and actual is done at the end of the project, no during the project.

So clawback should only happen at the end of the project not between tranches

Iā€™m in two minds about this. This would run the risk of the dApp holding onto the entire grant money at the end of their grant journey, as there is no way to remove it from them. The app could be blacklisted, sure, but thatā€™s after all the damage would have been done.

I agree that the clawback feature can be a huge spanner in the works, so over the next while Iā€™ll stew over the idea of removing the clawback, or at least modifying it in a way that I still find reasonable. Iā€™m still keen on the idea of paying some of the grant back, but Iā€™m not 100% against the idea of taking it out of the proposal.

My main qualm is with not having any transparency in what grantees are doing with their grant money and I would like there to be some form of consequence for grantees who ask for what they donā€™t need. The only current consequence is the risk that their proposal will be rejected, but there are no consequences if their proposal is accepted.

31

It is one way to see it. Another is that the grant is meant to help developers join the ecosystem by covering the cost of their project. A grantee cannot hedge or do any forward coverage to mitigate fluctuations in the value of B3TR. So if B3TR loses value, the grant will no longer cover the project cost.

With a valuation in USD and a clawback mechanism, the grantee could face a double blow.
Here is an example:

  • Project (or tranche) cost estimate: 20k USD

  • Converted as 400,000 B3TR (1 B3TR = 0.05 USD for the sake of this example)

At the end of the project:

  • Actual spending: 18k USD

  • Average B3TR value during the project: 0.02 USD

  • USD effectively received (in B3TR): 8k USD

So would you ask for a clawback of 2k USD, making the situation even worse for the grantee ā€” a total loss of 12k USD?

pushing the math even further :

Actual spending: 16k USD

  • Average B3TR value during the project: 0.01 USD

  • USD effectively received (in B3TR): 4k USD

total loss : 16-4+4 (clawback) = 16k so basically Grantee has fully sponsored the development and the grant was useless/meaningless

32

:receipt: Grant Transparency & Reporting Standards for Funding

Summary:

This proposal introduces new requirements for all grant applicants to improve transparency, ensure responsible use of treasury funds, and strengthen trust in the VeBetterDAO grant process.

Motivation:

As grant funding within VeBetterDAO grows, so does the need for clearer visibility into how funds are requested and used. While internal review processes exist, the lack of public transparency has led to increasing skepticism and disengagement among voters.

This proposal aims to introduce lightweight, consistent transparency requirements that help build trust, improve voter confidence, and set clearer expectations for grant applicants without overcomplicating the process or adding significant overhead.

Detailed Specification:

1. Cost Breakdown Requirement:
All dApp proposals must include a clear and detailed explanation of how the requested grant amount was calculated. This should include estimates, justifications, and any relevant assumptions or references.

2. Spending Plan Disclosure:
Each proposal must outline how the grant funds will be allocated across budget categories (e.g. development, marketing, audits) and provide an estimated timeline for delivery.

3. Inter-tranche Expenditure Report:
As targets for each tranche are hit, dApps are to provide an expenditure report in order to receive funds from the following tranche. This report, alongside milestone reports, will be posted publicly (e.g. on Discourse), and reviewed by the internal grant team before any funds from the following tranche are released.

These requirements will be integrated into the grant submission interface and grant review workflow:

Grant proposals missing a spending plan or cost breakdown will not be eligible for voting.

A standardized reporting template (below) will be required between tranches in order for the next tranche to be released.

If the dAppā€™s expense report, invoices, or other information is found to be fraudulent, proof of fraud would be provided to the grant team (if they didnā€™t already catch it), subsequently removing the dApp from the grant program and blacklisted from DAO.

:clipboard: Standardized Grant Expenditure Report Template:

Project Name:
Name of the dApp/project

Grant Recipient(s):
Team name and wallet address(es)

Tranche Number:
e.g., Tranche 1 of 3

Date of Report Submission:
DD/MM/YYYY

:white_check_mark: Milestone Completion Summary

Milestone Goal:
Brief description of the objective for this tranche

Was this milestone achieved?

Yes / Partially / No

Evidence of Completion:
Links to GitHub commits, product demos, dashboards, audit reports, etc.

:money_bag: Expenditure Breakdown

Development ā€“ Smart contract work ā€“ $2,000
Marketing ā€“ Twitter campaign ā€“ $500
Audit ā€“ Security review ā€“ $1,000
Services/Tools ā€“ Hosting, APIs ā€“ $200
Other ā€“ Legal/ops ā€“ $300
Total Spent: $4,000

:coin: Unspent Funds Summary

Total received for this tranche: $5,000
Total spent: $4,000
Unspent amount: $1,000

:speaking_head: Notes or Challenges Faced

Use this section to share blockers, learnings, or changes.

Risk Analysis

  • Increased overhead for applicants:
    Requiring cost breakdowns and reporting may add minor administrative work for dApp teams, particularly smaller ones. This risk is mitigated by keeping requirements lightweight and standardized.

  • False sense of security:
    Transparency requirements may be interpreted as full protection against misuse of funds. In reality, reports and receipts can still be misrepresented. This proposal reduces risk but does not eliminate it.

  • Discouraging some applicants:
    Higher transparency expectations may deter low-effort or opportunistic proposals, which is an intended outcome, but could also discourage some legitimate teams unfamiliar with grant reporting.

  • Reliance on social enforcement:
    Enforcement largely depends on reviewer oversight and public scrutiny rather than hard technical controls. While imperfect, this approach balances accountability with operational practicality.

Success Metrics

The effectiveness of this proposal can be measured by:

  • Higher-quality grant proposals:
    More consistent cost breakdowns, clearer spending plans, and better-defined milestones across submitted proposals.

  • Greater transparency:
    Public availability of spending reports and milestone updates for funded dApps.

  • Improved voter confidence:
    Increased participation in grant discussions and reduced instances of blanket ā€œnoā€ votes driven by uncertainty or distrust.

  • Reduced overfunding concerns:
    Fewer community complaints regarding excessive grant amounts or unclear use of funds.

  • Process adoption:
    Consistent use of the standardized reporting framework by grant recipients across multiple funding cycles.

Community Engagement:

This proposal was initially created on 11/06/2025 (DD/MM/YYYY). Since then, this proposal has had many discussions involving many community members, including input from the VeBetterDAO Grant Team. Further discussions have also been held on the VeBetterDAO Community HUB Discord channel. This proposal has seen various iterations, thanks to input from multiple community members.

Conclusion:

As the VeBetterDAO grant program scales, relying on implicit trust and unseen internal processes is no longer sufficient. While no framework can fully prevent abuse, the absence of clear, enforceable transparency standards actively undermines voter confidence and long-term participation.

This proposal establishes a reasonable baseline for transparency that formalizes expectations, reduces ambiguity, and makes grant funding more accountable to the community it serves. It is a necessary step to restore confidence, discourage low-effort proposals, and protect the integrity of the DAOā€™s treasury without introducing excessive complexity or overhead.

Proposal Changes

Added Features:

  1. Cost Justification Requirement: A mandatory field in the initial application requiring a detailed, line-item breakdown, justifying how the total grant amount was calculated.

  2. Standardized Grant Expenditure Report (SGER): A new, required reporting document that must be submitted and verified between funding tranches.

  3. Proof-of-Progress Evidence: Requirement for verifiable links (GitHub, demos, etc.) to be attached to expenditure reports before the release of subsequent funds.

Modified Features:

  1. Tranche Disbursement Workflow: The current milestone-based release of funds is modified to require a review of the Expenditure Report first.

  2. dApp Submission Interface: The user interface for applicants is updated to include specific fields for spending plans and budget categories.

Removed Features:

N/A