Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028
160 DReps voted · 70 with a rationale · 8 changed their vote
Open a row to read the rationale.
- No590.5K ₳No rationale
- Yes589.7K ₳Rationale
I support this proposal because it focuses on genuinely core protocol infrastructure that directly strengthens Cardano’s scalability, resilience, decentralisation, and developer ecosystem. While the treasury ask is large, the proposal targets foundational systems required for Cardano’s next growth phase and represents the kind of long-term infrastructure investment necessary for Cardano to compete as global financial infrastructure. Crypto will eat legacy!
- No587.6K ₳No rationale
- No533.9K ₳Rationale
IO is the team right now.
- No499K ₳Rationale
- Yes487.7K ₳No rationale
- No479.9K ₳No rationale
- Yes466.2K ₳No rationale
- YesChanged438.7K ₳History
Earlier votes
No1mo agoSuperseded
- No414.2K ₳No rationale
- Abstain385.2K ₳Rationale
Abstaining, as I’m part of the Cardano Constitution Committee Tingvard.
Reading proposals and staying updated, just like you.
Thanks to all fellow DReps who are also doing the hard work.
Follow and DM me on X: @kenerik if you have any questions. - No383K ₳No rationale
- No381.1K ₳No rationale
- NoRevoted365.7K ₳History
Earlier votes
No2mo agoSuperseded
No2mo agoSuperseded
No2mo agoSuperseded
- No360.3K ₳No rationale
- Yes332.3K ₳No rationale
- Yes328.9K ₳No rationale
- Abstain314.4K ₳Rationale
I support these vital infrastructure upgrades (Peras, Leios, History Expiry) but am abstaining to provide feedback for the anticipated revision. I encourage the team to return with a leaner, unbundled, one-year proposal so we can fund this work and get started ASAP.
A PDF version of this rationale is also made available.
Since this treasury withdrawal has already failed to pass, my "Abstain" vote serves to place my governance rationale on the record and provide constructive feedback for the team's anticipated revision.
I want to be clear: I fully support the necessity of these deliverables. Leios is only half of the picture; the rest is Peras, and we absolutely need both for our scalability and to realize our Cardano 2030 strategy. The accompanying work packages are also critical (for example, History Expiry, without which smaller SPOs would soon struggle to keep up with upcoming hardware requirements of Leios, posing a direct threat to our decentralization). I also greatly value the team's transparency and the highly detailed breakdown of salaries, development costs, and overhead.
I understand the community’s concerns regarding the bundled nature of the proposals and the massive two-year funding request. While I see valid logistical reasons for the team's approach, as these work packages are closely interconnected and guaranteed funding ensures zero development disruption, we must balance efficiency with responsible, step-by-step treasury management.
What I am looking for in a revised proposal:
I would like to see the team return with a revised, leaner approach that addresses the community's structural concerns:
Shorter Time Horizons: Split the funding request into a one-year timeframe (if feasible), rather than asking for two years upfront.
Strategic Unbundling: Separate the work packages into tighter, more modular proposals. Group together only the deliverables that are absolutely interconnected by technical dependencies or strict timelines.
Optimized Budget: Review the budget to cut any non-essential spending. We should strive for the leanest possible execution without compromising on the high standards of quality and security the Cardano network demands.
I look forward to seeing a modular revision of this vital infrastructure work and having the team start working on delivering those work packages ASAP.
- Yes313.4K ₳No rationale
- No300.6K ₳Rationale
First of all, I don’t understand why funding is being requested for two years, especially when the NCL operates on an annual basis. This would allocate a significant portion of the treasury to a single proposal what about the rest of the projects? That doesn’t seem balanced or fair.
Secondly, I’m unclear about the $176/hour rate. That figure appears excessively high for a developer. Can this be justified? It raises concerns about whether the budget assumptions are realistic.
It almost feels like these numbers are based on an assumption that Cardano’s price is at $3.65 which is clearly not the case. Budgeting should reflect current market conditions and responsible treasury management.
Overall, I believe this proposal needs more transparency and a more reasonable funding structure before it can be seriously considered.
I would recommend breaking this proposal into smaller phases instead of submitting it as one large two-year request. Especially in a bear market, where the community is already sensitive about treasury spending, asking for such a large amount upfront can create unnecessary resistance.
A phased approach would build more trust, allow for better accountability, and give the community the opportunity to evaluate progress before committing additional funds.
- Yes298.9K ₳Rationale
Voting YES on Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028
Summary
Asking ₳39,787,316 over the period of 2026–2028 to deliver 17 work packages for core infrastructure.
Conclusion
It seems a lot of people are voting against this budget because they don't like that it's a two-year timeline and they don't like that it's a bundled package. I used to think bundled packages were a bad idea but I now think that in some cases they make sense. We are, as a group, still in the process of figuring out what level of detail is best for the DRep democratic mechanism to operate. I'm starting to think that the democratic process should operate at a higher level than I once did.
The two-year timeline makes sense if Tweag believes it will take 2 years of continuous development to produce results.
The proposer is communicating that they believe these conditions are what they need to succeed. I think we should take that into account.
Signed,
William DoyleYour friendly neighbourhood DRep!
$computerman
drep1yfpgzfymq6tt9c684e7vzata8r5pl4w84fmrjqeztdqw0sgpzw3nt
@william00000010 on 𝕏
contact@williamdoyle.ca - No294.4K ₳No rationale
- No270.1K ₳Rationale
I am voting NO on “Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028.”
Tweag is one of the strongest technical teams in the Cardano ecosystem, with a long track record on consensus, ledger, Plutus, and formal‑methods work. Their contributions to Ouroboros Genesis, History Expiry design, Genesis Sync Accelerator, and the Hoarding Node, and their role in Peras, are real, important, and visible in open‑source code. The work proposed here—Peras v1/v2, History Expiry, Hoarding Node, conformance and adversarial testing, mutation frameworks, Genesis Sync maintenance, and developer tooling—is clearly core infrastructure, not peripheral activity.
My NO is not about the importance of this class of work; it is about how it is packaged and funded in this proposal. The request is for ₳39,787,316 (~USD 9.95M) over two full years (2026–2028), across 17 work packages, and it explicitly asks voters to treat the entire portfolio as a single, non‑modular delivery pipeline. In a governance system that is still maturing, with a constrained Net Change Limit and many other infrastructure teams also requesting funds, I do not think it is healthy to lock in such a large, multi‑year envelope in one decision. Most serious teams this cycle are requesting roughly one year of funding and returning to governance for renewal. I believe Tweag should do the same here: request a one‑year tranche, deliver against it, and then come back for follow‑up funding once progress and priorities can be reassessed.
The size and pricing of the ask reinforce that concern. The budget is based on an average rate of $176/hour for senior Cardano infrastructure engineers and an ADA price of 0.25. That rate is not unreasonable for highly specialized protocol work, and I appreciate Tweag’s transparency in stating it. However, at nearly ₳40M, this proposal is very large relative to other infrastructure withdrawals in the same NCL window, and accepting a two‑year contract at this level would, in practice, set a pricing and scale precedent for future core‑infra asks. Given ongoing advances in developer tooling (including AI‑assisted workflows) and the need to preserve Treasury flexibility, I think it is appropriate to ask for a smaller, time‑bounded commitment first rather than approve the full two‑year amount in one step.
Bundling is the third issue. I agree that many of the 17 work packages are technically interdependent and should not be micromanaged in isolation. At the same time, not all of them are equally urgent. Peras v1 mainnet readiness and core v2 work, History Expiry together with Genesis Sync, a baseline Hoarding Node deployment, and essential conformance/adversarial testing look like clear near‑term priorities. Other items in the portfolio, while valuable, could reasonably be funded later or as part of a follow‑up proposal once the critical path is secured. By insisting that the entire set be decided as a single yes/no, the proposal makes it difficult for DReps to prioritize under a constrained Net Change Limit.
For these reasons, I will vote NO on this proposal in its current form. I would be much more inclined to support a resubmission that (1) requests funding for approximately one year under the current NCL, (2) focuses that year on the clearly critical path—Peras mainnet readiness, History Expiry + Genesis Sync, baseline Hoarding Node, and necessary testing infrastructure—(3) provides more detailed, work‑package‑level budget and milestone breakdowns, and (4) leaves room for additional, lower‑urgency items to be considered in a subsequent, smaller proposal once the first tranche has been delivered. - Yes245.5K ₳Rationale
This would deliver Peras v1 and v2 mainnet readiness - the faster finality upgrade (~2 min vs ~12 min today) that has no other funded delivery vehicle anywhere in the 2026 governance cycle. Beyond Peras, the proposal covers History Expiry (critical for SPO storage sustainability under Leios throughput increases), the Hoarding Node (network observability and adversarial behaviour detection), the Hard Fork Mempool Bridger (transaction preservation during fork incidents), conformance testing for both Peras and Leios, and mutation testing infrastructure. Tweag has been embedded in Cardano's core infrastructure since 2018 - they implemented Ouroboros Genesis and led the consensus and ledger teams. Critically, Tweag's existing track record and disclosed rate card ($176/hour, ₳0.25/ADA conversion, two-year fixed-price packages) provide cost transparency. This is the model the ecosystem should reward and replicate.
- No238.8K ₳Rationale
This year we have spent too much from the treasury already and ADA's constant weakness against USD is not helping. 1 ADA = 0.22 USD at the time of writing. We must protect the treasury until situation is more favorable.
- No234.2K ₳No rationale
- No233.2K ₳No rationale
- NoRevoted232.7K ₳History
Earlier votes
No2mo agoSuperseded
No2mo agoSuperseded
- Abstain215.5K ₳No rationale
- No207.6K ₳No rationale
- Abstain200.5K ₳No rationale
- Abstain191.1K ₳No rationale
- Yes182.2K ₳No rationale
- No178.9K ₳No rationale
- No142.5K ₳Rationale
I would support the part of this proposal for 1 year, and in 1 year I would support the other part.
- Abstain138.4K ₳No rationale
- No137.4K ₳No rationale
- Abstain131.9K ₳No rationale
- Yes129.1K ₳No rationale
- Yes115.6K ₳No rationale
- Yes110.9K ₳No rationale
- Abstain108.3K ₳Rationale
Due to current limitations in our governance process, I will cast abstain votes on most upcoming proposals. The existing framework does not provide the adequate structure, clarity, or time required to make well-informed funding decisions. Moving forward, I will only vote "Yes" on initiatives that are absolutely critical to the network's immediate survival and success. I sincerely apologize to the teams who have dedicated time and effort to their proposals; you deserve a more robust evaluation system. Right now, my priority must shift from assessing standard funding requests to actively improving our governance infrastructure, ensuring we no longer have to make rushed decisions with insufficient information.
- No92.6K ₳No rationale
- Yes72.1K ₳No rationale
- No55.9K ₳Rationale
no. mismanagement of funds last year, countless proposals elsewhere in some form or another and way too many projects which are not needed, or not needed at the moment, or handled elsewhere.
- No52.4K ₳No rationale
- No50.5K ₳No rationale
- Yes49.7K ₳Rationale
I am voting YES on the Tweag Core Cardano Infrastructure proposal because the work is strategically important for Cardano’s long-term scalability, resilience, and 2030 vision. Peras mainnet readiness, History Expiry, conformance testing, adversarial testing, observability, Mithril-related canonical state work, and developer tooling are not isolated tasks; they are part of the infrastructure foundation Cardano needs if we want higher usage without sacrificing decentralization, security, or operational reliability.
This is not a blank check. For me, a proposal of this size must be held to a high standard of KPI accountability. The community should be able to verify delivery through public milestones, open-source outputs, reproducible releases, benchmarks, audit results, demos, third-party assurance, close-out reporting, and clear evidence that the work is being used by SPOs, developers, infrastructure teams, and downstream projects. Success should not only mean that code was written; it should mean that Cardano’s ecosystem capacity increased.
My core thesis remains: Cardano needs convenience without dependency. This proposal can support that thesis if the results reduce friction for builders, SPOs, and users while avoiding long-term dependence on one provider or one closed delivery path. Treasury funding should move Cardano from service dependency toward open ecosystem capacity. That means Tweag’s work should produce documentation, runbooks, reusable tools, contribution pathways, and knowledge transfer so smaller developers and teams can participate in the Cardano economic machine.
I also believe sizable proposals benefit from continued community warm-up, heads-up, and consultation. The best parts of Catalyst-style iteration should carry into governance: early feedback, refinement, milestone accountability, Proof of Achievement, close-out reporting, and continuity of learning. A YES vote here should be understood as support for vital infrastructure work, paired with the expectation that delivery remains transparent, measurable, and broadly useful to the whole ecosystem.
As a Cardano citizen and Product Committee voting member, I support this proposal because it appears aligned with Cardano’s infrastructure needs and long-term decentralization goals. But the mandate is accountability: public evidence, measurable impact, open outputs, and a clear path from specialist delivery to shared ecosystem capacity.
- No46.5K ₳Rationale
Sorry, but the team need to prove the previous proposal deliverables with explanation, before the continue withdrawal of the treasury
- No45.2K ₳Rationale
That's insanely huge budget and what's strange is that why do you need funding for years (till 20208)? I think such proposals can go via Project Catalyst in the future.