Proposal: Grant Transparency & Fund Recovery

[litter3]

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

[litter3]

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.

[Plunk]

@litter3

first payment received 63728 B3TR for a value of $5000.
Current value : $1274

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.

[litter3]

@Plunk

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.

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.

[litter3]

@Plunk

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

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.

[Plunk]

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.

[litter3]

@Plunk

Honestly, I think this adds more complexity to the process than I’d like to have

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.

@Plunk

my expenditure report template I used USD spent, not B3TR.

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.

[litter3]

@Plunk

Yes. So ask for more and give it back if you don’t use it.

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

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

[Plunk]

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.

[litter3]

@Plunk

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.

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

[Plunk]

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.

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

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.

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

Unspent Funds Summary

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

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

[Dan]

Hello!
First of all sorry for this proposal execution to have taken so much time. We are almost ready to release it.

Here’s a quick update:
The proposal text says SGER is “required between tranches in order for the next tranche to be released.” When implementing this we considered enforcing it at the contract level (i.e. a hard on-chain block on approveMilestone when no SGER is recorded) and decided against it. Wanted to be transparent about why.
A smart contract can only observe that an event happened: e.g. “a report was uploaded for tranche N.” What the contract cannot do is read the report, understand its content, and judge whether it’s a legitimate accounting of how grant funds were spent. On-chain we just store an IPFS URI; a contract can’t fetch the IPFS document, parse it, evaluate the line-items, cross-check evidence links, or distinguish a real expenditure report from a single-word document that says “I rock!”. Even if the report were stored as raw text on-chain rather than IPFS, the same problem remains — verifying the legitimacy of a financial report is a human judgement, not a syntactic check.

So a contract-level rule like “a report was filed for this tranche” gives the appearance of enforcement without any actual safeguard. It would just incentivize uploading garbage to satisfy the gate.

What we’re shipping

The proposal’s actual safeguard is reviewer oversight: the Foundation grant team (and the wider community via public IPFS data) review the SGER before approving each tranche payout. We’ve leaned into that:

• UI-side gate for reviewers: a clear warning is shown above the Approve & Fund button on every milestone where no SGER has been submitted (including the first tranche). In the next iteration of this work the Approve & Fund button itself will be disabled until the proposer submits an SGER, so reviewers can’t accidentally release funds without one.
• Public, immutable SGER data: every report is pinned to IPFS as versioned JSON inside the milestone metadata URI. Anyone — voters, the grant team, future auditors — can read the full report.
• Mandatory budget at submission: cost breakdown and spending plan are required form fields; proposals missing them can’t be submitted, matching the proposal’s “not eligible for voting” language.
• Schema matches the proposal table 1:1: project name, recipient, tranche number, milestone goal, achievement status, evidence links, expenditure breakdown, totals, unspent funds, notes.
• Backward compatible: grants approved before this work display cleanly with no SGER section.

TL;DR

The proposal is a process change, and the meaningful enforcement is the human reviewer’s judgement on the SGER content. Our execution focuses 100% on giving reviewers the right surface area (clear UI warnings, soon a hard UI block, public report data) and on writing this up in the grant manager instructions, rather than on a contract-level pseudo-gate that wouldn’t actually protect the treasury.

For example here are the instructions we give to our grant manager team:

1. When reviewing new grant applications

Every grant submission now includes two new mandatory sections:

• Cost Breakdown — line-item budget with category, amount (USD), and justification per item.
• Spending Plan — narrative describing how funds will be allocated across categories with a delivery
  timeline.

The form blocks submission if either is missing, so you should never see a grant without these. What to
check:

• Do the line-items match the requested grant amount? (Sum of items ≈ total request.)
• Does each justification actually justify the cost, or is it boilerplate?
• Does the spending plan show a realistic timeline tied to the milestones?
• Are amounts proportionate to the work described? Flag anything that looks inflated.

Where to see it on the grant detail page: Budget tab.

---

2. When approving each milestone tranche payout

This is the new core responsibility. Before clicking “Approve & Fund” on any milestone, including the first
one:

1. Check whether the proposer has submitted an Expenditure Report for that tranche.
   • If yes → it appears above the milestone actions, and you can read the full report inline.
   • If no → a clear warning banner appears above the “Approve & Fund” button: “Expenditure report missing for
     this payout.”
2. If the warning is showing, don’t approve the tranche. Reach out to the proposer and ask them to submit the
   SGER first. (In an upcoming UI update the button itself will be disabled until an SGER is on file — for now
   treat the warning as a hard stop.)
3. If an SGER is present, review it before approving. Specifically:
   • Milestone Goal vs Achieved status — does the explanation match what was promised in the original
     milestone description?
   • Evidence links — open them. GitHub commits should be real and recent. Demos should be reachable. Audit
     reports should be from a recognised auditor. Dashboards should show actual usage.
   • Expenditure Breakdown — do the categories and amounts make sense for the work delivered? Cross-check
     against the original Cost Breakdown.
   • Total Spent vs Total Received — math should balance. Unspent amount should have an explanation in Notes
     if non-trivial.
   • Notes — read for blockers, scope changes, or red flags.
4. If everything checks out, click Approve & Fund. Otherwise reject and ask for clarification.

---

3. If you suspect fraud or misrepresentation

Per the proposal, evidence of fraudulent reporting is grounds for removing the dApp from the grant program
and blacklisting from the DAO. If you spot:

• Fake/empty GitHub repos passed off as work
• Invoices or receipts that don’t match claimed expenses
• Numbers that don’t add up
• Repeated vague reports with no real evidence

…don’t approve the tranche. Document what you found and escalate to the Foundation.

---

4. Practical notes

• Reports are public and permanent. They’re pinned to IPFS, anyone can fetch and read them. Treat that as a
  feature: voters can see what you saw.
• Only the original proposer wallet can submit a report. If a different team member needs to file, the
  proposer has to do it from their wallet (or the team should switch wallets first). The UI tells the receiver
  wallet this explicitly.
• Editing milestone dates preserves prior reports. If a proposer asks you to extend a milestone deadline, the
  SGERs they’ve already filed are not lost — the system re-reads chain state and merges.

---

TL;DR — your new checklist before clicking Approve & Fund

• SGER is on file for this tranche
• Evidence links open and look legitimate
• Numbers in the report add up
• Report content matches the original milestone goal
• No red flags in Notes / blockers section

If any of those fail, reject or ask for resubmission instead of approving.

If anyone wants to test here is the staging environment for this implementation: https://pr-3245-staging.staging.testnet.governance.vebetterdao.org/

[Plunk]

Dan, this is awesome.

Thank you so much for all of this work!

Excited to see it in play!

[Dan]

Almost there, I think this week is the one when we will release this.

If you go to this link there are some videos showing what is coming: feat/implement-grants-governance-proposal by rosavechain · Pull Request #3245 · vechain/vebetterdao · GitHub

It is showing how the creation of grant flow changed (not that much, we added the new “Budget” step asking for users to insert details about how they intend to spend the money), the approval & fund flow (nothing changed for first milestone, but from second one an expenditure report of how funds from the previous milestone were spent is needed), and for adding an expenditure report.