> For the complete documentation index, see [llms.txt](https://committees.docs.intersectmbo.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://committees.docs.intersectmbo.org/intersect-budget-committee/committee-meeting-notes/2026-meeting-notes/drep-responses.md).

# DRep Responses

Responses from the Committee for DReps who have requested feedback:

## Budget Committee Response to Yuta

Re: Vote change on "Budget Process Improvement and Treasury Transparency 2026–2027" (600K ADA / NCL 0.17%)

Yuta, thank you for taking the time to revisit your assessment and for sharing your reasoning so openly. Engagement at this level is exactly what makes the governance process work, and we want to respond to your concern in the same constructive spirit in which you raised it.

We understand that you changed your previous "Yes" to a "No" on the following rationale: judging from the recent submission status of on-chain governance actions, submitting treasury withdrawal actions is no longer difficult for builders. The implication is that everything can now be consolidated into on-chain governance actions, effectively removing the need for an off-chain budget process.

Given the large number of treasury withdrawal actions submitted recently, this is a very reasonable interpretation, and we appreciate why you reached it. We'd like to offer some context that we think reframes how difficult it actually is to set up these actions in practice, and, just as importantly, what the budget process delivers beyond mere submission.

Before we do, we want to return to the case you yourself made when you originally voted Yes, because we think it still holds, and it anticipates the very point at issue here.

### Your original reasoning still stands

When you supported this proposal, you wrote that "the Budget Committee is the body that operationalises Treasury withdrawals through DRep governance," and that without it the budget cycle "either reverts to pre-Conway-era handling or moves under another sub-body." You noted that Cardano's Conway-era treasury governance is only \~12 months old, and that this is the first end-to-end cycle.

You also made the meta-governance argument directly: that the Budget Committee's existence is what enables DRep oversight of all other Treasury withdrawals, and that "refusing to fund the Budget Committee while continuing to ratify other Treasury withdrawals through it would be operationally inconsistent."

That observation is exactly why the recent volume of on-chain actions argues for the process, not against it. The fact that \~20 treasury withdrawals can sit on-chain at once is precisely the condition under which DReps most need a consistent framework to evaluate them, which is the role this body plays. The activity you're pointing to is the workload the Budget Committee exists to make tractable, not evidence that the workload has gone away.

And your sixth point, that WP2's treasury transparency and analytics "directly serves DReps who must vote on Treasury withdrawals," speaks to the same need. More on-chain submissions means more for DReps to analyze, which makes that analytics capability more valuable now, not less.

### The realities of on-chain treasury withdrawals

While anyone can technically submit a proposal, the barrier to entry remains high for the average builder and company, for two main reasons:

* The financial hurdle. Sourcing the 100,000 ADA deposit required for a treasury withdrawal action is a genuine challenge for small teams. Teams usually find a way to fund it eventually, but it remains a real and recurring barrier, and it disproportionately affects exactly the smaller, newer entrants we most want to bring into the ecosystem.
* Technical complexity. The process is difficult for teams that are not native to Cardano or not deeply technical, those who don't build developer tooling for a living. To date we have almost exclusively seen self-submitted smart-contract treasury setups come from highly specialized developers, or from teams with direct access to them. The recent volume of on-chain actions reflects the capability of a specialized subset of builders, not a lowered barrier for the broader community.

So while the headline activity looks like submission has become easy, the population doing the submitting tells a different story.

### Why the budget process is crucial

Today we have a constitutional, permissionless governance model where anyone can submit treasury withdrawals at any time. That is genuinely valuable: there is no gatekeeper, and anyone with the necessary ADA can participate.

But that same openness leaves DReps in the position of analyzing complex, individually-submitted treasury withdrawals on the basis of scattered, inconsistent information. It is possible, but it is a massive and uneven burden, and it scales poorly as volume grows.

The value add: An established budget process, with analytics tooling built in, creates a transparent framework where proposers, DReps, and the broader community can compare and evaluate proposals side by side, on a consistent basis.

Beyond comparison and evaluation, the process provides essential services to builders that on-chain submission alone does not:

* Administrative support that streamlines the logistical overhead of governance for teams that don't have it in-house.
* Stablecoin conversion, allowing projects to convert ADA immediately and hedge against exchange-rate volatility between approval and execution.

These are not duplicative of on-chain governance. They are the connective infrastructure that makes on-chain governance usable for non-specialists.

### Looking ahead: the 2027 iteration

We want to be clear that we don't think the process is finished. It has improved dramatically since 2025, and we share your instinct that it should keep getting leaner and more on-chain-aligned. Our primary goal for 2027 is to start sooner and remove the current bottleneck, where \~20 live treasury withdrawals sit on-chain while a separate budget process runs off-chain in parallel. Concretely:

1. Transparency & analytics workstream. We need far more visibility into how funds are spent and whether deliverables are met, surfaced directly in the budget tool so anyone reviewing has it immediately. Today, administrators of treasury withdrawals are not strictly responsible for auditing deliverables, and we rely largely on proposer self-reporting. We want to trust builders, but we also fundamentally need transparent, independent, third-party verification of KPIs.
2. Reducing the burden on DReps. We plan to bring in independent subject-matter experts to provide deep-dive technical analyses alongside proposals, so DReps can vote informed without carrying the full analytical load themselves.
3. Dynamic application fees. The flat application fee worked relatively well this cycle. Going forward we want to make it dynamic, scaling with the total funding requested, so the governance workload stays sustainable and proportionate.

### In closing

Your concern points at something real, and it's directionally where we want to take the process too. Where we differ is on timing: the conditions that would make full on-chain consolidation viable for the whole builder community aren't here yet, and dismantling the process now would remove the support layer that smaller and less-technical teams currently depend on, while increasing, not decreasing, the load on DReps.

We'd genuinely welcome the chance to talk this through with you further, and to fold your perspective into the 2027 design. Thank you again for the seriousness you've brought to this vote.

The Budget Committee

<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://committees.docs.intersectmbo.org/intersect-budget-committee/committee-meeting-notes/2026-meeting-notes/drep-responses.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.