Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028

System2mo ago1 post

160 DReps voted · 70 with a rationale · 8 changed their vote

Open a row to read the rationale.

  • NoChanged9.2M ₳History

    Earlier votes

    Abstain2mo agoSuperseded

  • Abstain8.8M ₳Rationale

    私はこの提案を棄権します。Perasによるファイナリティ短縮、履歴データ管理の効率化、適合性テスト、ネットワーク監視・分析基盤であるHoarding Nodeをはじめとする各取り組みは、Cardanoのコアインフラ強化に貢献するものであり、その技術的価値やTweagのこれまでの実績については高く評価しています。また、Cardanoの長期的な競争力を維持するためには、こうした基盤技術への継続的な投資が重要であると考えています。一方で、本提案は17のワークパッケージと複数の異なる取り組みを単一の財務引き出し提案にまとめており、それぞれを個別に評価して判断することが困難だと感じています。提案に含まれる内容の中には支持できるものが多くありますが、優先順位や必要性について個別に判断したい項目も含まれています。また、₳39,787,316という大規模な予算と2年間にわたる実施期間を考慮すると、より分割された形で提案されていれば、コミュニティやDRepが各取り組みについて、より明確に意思表示を行えた可能性があると考えています。そのため、本提案の技術的価値や目的には一定の理解を示しつつ、今回は棄権します。\n\nI abstain from this proposal. I highly value the initiatives included in this proposal, such as Peras for faster finality, improvements to historical data management, conformance testing, and Hoarding Node as a network monitoring and analysis platform. These efforts contribute to strengthening Cardano’s core infrastructure, and I highly appreciate both their technical value and Tweag’s track record to date. I also believe that continued investment in foundational technologies is important for maintaining Cardano’s long-term competitiveness. At the same time, this proposal combines 17 work packages and multiple distinct initiatives into a single treasury withdrawal proposal, making it difficult to evaluate and form a judgment on each component individually. While many aspects of the proposal are worthy of support, it also contains areas whose priority and necessity I would prefer to assess separately. Furthermore, considering the substantial budget of ₳39,787,316 and the two-year implementation period, I believe that a more modular proposal structure could have allowed the community and DReps to express clearer views on each initiative. Therefore, while I recognize the technical value and objectives of this proposal, I will abstain from voting on it.

  • No7.6M ₳Rationale

    I'm sorry this kind of scope of a proposal 2026-2028 needs some kind of independent expert verification and support. It is supposed to drive Cardano into a certain direction and at a substantial cost.

    Do you have any support for this scope of work either from the Cardano Foundation, IOG, Emurgo, Intersect technical experts, a very representative group of SPOs, a very representative group of Cardano builders, etc.?

    I'm sorry, but just submitting this package as a whole is not enough without multiple third-party independent confirmation that this exact scope of work is needed and worthwhile. Not only desirable, but really worth the amount requested and that it meets Cardano's needs today.

    Until such independent verification and confirmation is provided, I would be happy with the full delivery of the proposal approved last year: Withdraw ₳11,070,323 for TWEAG's Proposals for multiple core budget project

  • No7.2M ₳No rationale
  • No5.9M ₳Rationale

    I am voting No.

    This proposal bundles large, multi-year funding for important protocol work into a single ask, and that structure is the issue—not the work itself. It creates unnecessary pressures for a budget that must account for multiple asks.

    A PDF version of this rationale is also made available.

    I am voting No.

    This proposal bundles large, multi-year funding for important protocol work into a single ask, and that structure is the issue—not the work itself. It creates unnecessary pressures for a budget that must account for multiple asks.

    Peras and Leios both have merit, but committing this level of capital upfront reduces treasury flexibility and crowds out the ability to fund other priorities as the ecosystem evolves. We should not be locking in large portions of the treasury across multiple years, especially for work that carries execution risk and has already seen timeline shifts.

    I also question the timing. Fast finality is directionally valuable, particularly for enterprise and higher-assurance use cases, but it’s not clear this is a current constraint on adoption. Most active ecosystems operate without it today, and user growth has not been limited by its absence. If and when this becomes a real requirement, I would expect to see stronger demand signals—and ideally some level of co-investment from those stakeholders—before prioritizing it at this scale.

    Additionally, prior treasury management decisions by proposers are not something the Cardano treasury should be expected to compensate for.

    Finally, this vote is also a fiscal one. There are multiple large asks in this cycle, and we simply cannot fund everything at once without severely limiting flexibility for the rest of the year. Saying No here is not a rejection of the work, but a necessary constraint on capital allocation.

    I would potentially support a restructured approach—breaking this into smaller, clearly scoped proposals (e.g., Peras and Leios separately), with single-year funding and milestone-based accountability. There is room to continue progressing this work so it is ready when needed, but not at the scale of a multi-million, multi-year commitment upfront.

  • Yes5.8M ₳No rationale
  • Yes5.4M ₳No rationale
  • Abstain5.3M ₳No rationale
  • No5.3M ₳Rationale

    STORM Partners votes NO on the Tweag Core Cardano Infrastructure proposal.
    We recognize Tweag’s long-standing contributions to Cardano and the relevance of Peras for faster finality. The proposal includes important work across Peras, resilience, testing, observability, and developer tooling.
    However, the ask is too large at this stage. At nearly ₳39.8M over two years, this would consume a major share of the current Net Change Limit, while also funding continuation of work that appears partly connected to prior infrastructure commitments. Under current budget pressure, we believe Cardano should prioritize the most essential protocol and adoption-enabling proposals first.
    This is not a rejection of Tweag’s technical credibility. It is a prioritization decision. We vote NO due to cost, timing, and NCL constraints.

  • Yes4.8M ₳No rationale
  • Yes4.7M ₳Rationale

    This is expensive, but contains man work packages. Would have like to see this broken up into several smaller proposals.

  • No4.6M ₳No rationale
  • No4.4M ₳Rationale

    This proposal for Peras is very expensive and features a long term delivery timeline. It is also unclear whether there is any overlap with IOG’s core developments that have already been submitted. At a minimum, the team should disclose any collaboration with Cardano’s founding entities or confirm whether they have their support.

  • Yes4.1M ₳Rationale

    [Portuguese]
    Optamos por votar "SIM" nesta ação de governança "Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028" (gov_action14u26vcn3wmcnhc5pqrt6494ypugr7c7f3e2ns60r32cntl6zjtxsqqgeu8p), pois entendemos que ela financia entregas relevantes para a infraestrutura central da Cardano, especialmente o Ouroboros Peras, incluindo melhorias de resiliência, escalabilidade, testes de conformidade, observabilidade da rede e ferramentas para desenvolvedores. Embora o valor solicitado seja expressivo, de ₳39.787.316, o escopo é amplo, distribuído em 17 pacotes de trabalho ao longo de dois anos, e possui potencial de gerar benefícios estruturais para a rede. Também consideramos positivo que a proposta preveja mecanismos claros para mensurar e acompanhar as entregas, como marcos, critérios de aceitação, valores e prazos por etapa, validação por terceiro assegurador, administração pela Intersect, demonstrações públicas, atualizações regulares e controle dos desembolsos por smart contracts de tesouraria. Esses elementos fortalecem a transparência, permitem acompanhar o progresso e tornam o custo-benefício mais defensável, desde que os marcos contratuais sejam publicados e acompanhados de forma clara pela comunidade.
    [English]
    We chose to vote "YES" on this governance action "Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028" (gov_action14u26vcn3wmcnhc5pqrt6494ypugr7c7f3e2ns60r32cntl6zjtxsqqgeu8p), because we understand that it funds relevant deliverables for Cardano’s core infrastructure, especially Ouroboros Peras, including improvements in resilience, scalability, conformance testing, network observability, and developer tooling. Although the requested amount is significant, totaling ₳39,787,316, the scope is broad, distributed across 17 work packages over two years, and has the potential to generate structural benefits for the network. We also view positively the fact that the proposal includes clear mechanisms to measure and track deliverables, such as milestones, acceptance criteria, amounts and timelines per stage, validation by a third-party assurer, administration by Intersect, public demos, regular updates, and disbursement control through treasury smart contracts. These elements strengthen transparency, enable progress monitoring, and make the cost-benefit case more defensible, provided that the contractual milestones are published and clearly tracked by the community.

  • Yes3.4M ₳No rationale
  • No2.8M ₳Rationale

    I have a lot of respect for this team and the goals of this proposal but I simply do not think the treasury is in a place to cover 2 years of operations especially of this size.

  • YesRevoted2.6M ₳Rationale

    私はこの提案を支持します。Cardanoの中核インフラは、「トカゲの尻尾をどこから切るか」を議論するのとは違うと思います。Peras、History Expiry、Conformance Testing、Hoarding Node、開発者向けツールは、Leios時代に向けた同じ体を構成する仕組みです。車検にたとえれば、普通の運転者はタイヤ、オイル、ブレーキなどを一つひとつ個別に発注するわけではありません。本当に求めているのは、安全で、信頼でき、安心して乗れるように整備された車です。同じように、SPO、Builder、ユーザーが求めているのは、全体として安全に動くCardanoの中核基盤です。
    ただし、統合提案を支持することは白紙委任ではありません。大規模かつ一括型であるからこそ、Reeveのようなオンチェーン監査・財務報告の仕組みを、Cardanoエコシステム内で積極的に発信・活用していく必要があります。
    そのため、私は、厳格なマイルストーン管理、独立した技術的Assurance、透明な進捗報告、公開デモ、Reeve等を含むオンチェーン・オフチェーン双方の監査証跡、納品後のコミュニティレビューを前提として、本提案に賛成します。


    I support this proposal because Cardano’s core infrastructure should not be treated like deciding where to cut off a lizard’s tail. Peras, History Expiry, Conformance Testing, Hoarding Node, and developer tools are connected parts of the same body for the Leios era.

    A car inspection is a useful analogy. Most drivers do not separately order checks for tires, oil, brakes, and every small component. What they really want is a safe, reliable, well-maintained car they can drive with confidence. In the same way, SPOs, builders, and users need Cardano’s core infrastructure to work safely as a whole.

    However, supporting an integrated proposal is not a blank check. Because this proposal is large and bundled, Cardano should actively communicate and use its own auditability tools, such as Reeve for on-chain financial reporting.

    For that reason, I vote Yes, with the expectation of strict milestone management, independent technical assurance, transparent progress reports, public demos, on-chain and off-chain audit trails including tools such as Reeve, and community review after delivery.

    Earlier votes

    Yes2mo agoSuperseded

    この提案は、PerasのMainnet展開に加え、Leios時代に向けた中核インフラを整備する重要な提案です。History Expiryは、将来のデータ肥大によるSPOストレージ負担を抑え、分散性を維持するために重要です。一方で、履歴剪定は安全性・監査性・復旧性に関わるため、Mithril等による検証可能なcheckpoint、archive nodeの履歴可用性、conformance testing、明確なfallback手順を条件として支持します。
    Conformance TestingはPerasやLeiosのような複雑なプロトコル変更の安全性を高め、Hoarding Nodeはネットワーク異常やmempool挙動の観測性を改善します。Plutus Script Re-ExecutorはDApp開発者のデバッグ環境を改善し、スマートコントラクトの信頼性向上に寄与します。
    要求額は大きく、17ワークパッケージを一括で扱う点には慎重な監視が必要ですが、Cardanoの分散性・安全性・スケーラビリティを支える公共財性は高いと判断します。厳格なマイルストーン管理、第三者Assurance、公開デモ、未使用資金返還を前提として、賛成します。

    ---


    
I support this proposal because it funds important core infrastructure for Cardano’s next phase, including the mainnet deployment of Peras and preparation for the Leios era.

    History Expiry is especially important because it can reduce future SPO storage burdens caused by data growth and help preserve decentralization. However, pruning historical data also affects safety, auditability, and recovery. For that reason, my support depends on verifiable checkpoints using Mithril or similar mechanisms, archive node availability, conformance testing, and clear fallback procedures.

    Conformance Testing will help improve the safety of complex protocol upgrades such as Peras and Leios. Hoarding Node will improve observability of network anomalies and mempool behavior. Plutus Script Re-Executor will improve the debugging environment for DApp developers and contribute to greater smart contract reliability.

    The requested amount is large, and the bundled structure of 17 work packages requires careful oversight. Still, I believe this proposal has high public-good value for Cardano’s decentralization, security, and scalability. I vote Yes, with the expectation of strict milestone management, third-party assurance, public demos, and the return of unused funds.

  • Abstain2.5M ₳No rationale
  • Yes2.5M ₳No rationale
  • No2.3M ₳No rationale
  • Yes2.3M ₳No rationale
  • Yes2.1M ₳No rationale
  • No2.1M ₳No rationale
  • Abstain2.1M ₳Rationale

    I am choosing to ABSTAIN on the Tweag Core Infrastructure proposal.

    I recognise the importance of the work being proposed. The scope includes serious Cardano infrastructure priorities, including Peras, history expiry, conformance testing, ledger/node improvements, adversarial testing, Mithril-related work and broader protocol resilience. I also recognise Tweag as a credible technical contributor with relevant experience in the Cardano ecosystem.

    However, I cannot actively support the proposal in its current form because the requested amount — approximately ₳39.8 million over 24 months — is extremely large relative to the remaining Net Change Limit. At this stage of Cardano treasury governance, I believe DReps have a responsibility to be especially disciplined with large multi-year withdrawals, even where the underlying work appears valuable.

    My concern is not that the work lacks merit. My concern is the structure, scale and precedent. A proposal of this size should ideally be broken into clearer staged tranches, with more granular work-package-level budgets, stronger visibility into milestone acceptance, clearer FX/conversion risk controls, and tighter mechanisms for pausing or reassessing funding if delivery, market conditions or ecosystem priorities change.

    I do not view this as a clear constitutional rejection. The proposal appears to address many of the required areas for a Treasury Withdrawal. My abstention instead reflects a governance judgement: the work may be important, but I am not sufficiently comfortable approving this level of Treasury commitment as currently structured.

    I would be open to supporting a revised version that preserves the most important infrastructure work while reducing the initial Treasury exposure, improving budget transparency, and staging funding in a way that better protects the Cardano Treasury and the remaining NCL.

    For these reasons, I am abstaining.

  • Abstain2M ₳No rationale
  • Abstain1.9M ₳No rationale
  • No1.8M ₳Rationale

    While acknowledging Tweag's excellent technical capabilities and the strategic importance of the Peras upgrade (shortening verification times from 12 minutes to 2 minutes for Midnight and DeFi), the proposal's financial structure is unhealthy for the ecosystem treasury. The requirement for a budget commitment of nearly 40 million ADA over a continuous two-year period (2026–2028) is excessively long, reducing flexibility and the community's ability to control milestones.

    The proposal bundles too many less urgent ancillary items into the core Peras funding package, forcing voters into an "all or nothing" situation. Furthermore, the $176/hour unit price is too high, and there's a lack of detailed budget breakdown for each specific work package.

    Therefore, we decided to vote NO and request that Tweag break the project down into one-year phases, reduce non-essential items, and clarify the cost structure before re-funding. This helps protect fiscal discipline and allows other infrastructure projects to develop alongside it.

  • No1.8M ₳Rationale

    I appreciate the goals of this proposal but the funding requested is quite significant. The work should be split into smaller proposals, with funding requested to cover one year of work rather than two.

  • Yes1.7M ₳Rationale

    Core L1 infrastructure, all open-source, delivered by a proven Cardano consensus/ledger contributor.

  • No1.7M ₳No rationale
  • Yes1.7M ₳No rationale
  • Yes1.6M ₳No rationale
  • No1.6M ₳Rationale

    While I understand the importance of delivering Peras, I cannot support this proposal for the following two reasons:

    • Requesting a two-year budget upfront seems either out of touch with reality or even somewhat inappropriate. Given the NCL, projects are already competing for one-year funding, let alone two years.
    • It is difficult to justify that IOG has submitted multiple proposals totaling 162M ada, already collaborating with various other companies, while a subcontractor involved in the same work submits a separate proposal.
  • Yes1.5M ₳Rationale

    Vote: YES on Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028

    Rationale:

    Peras is critical infrastructure for Cardano's consensus layer. Letting Tweag's delivery stall would directly harm the Leios roadmap and, by extension, Cardano's long-term scalability. The practical cost of voting No — losing a specialized engineering team mid-delivery — outweighs the principled objection to covering currency risk with treasury funds.

    That said, this Yes vote comes with a clear expectation for future proposals:

    1. No more ADA-denominated contracts without hedging mechanisms. All future treasury-funded engagements above a reasonable threshold should be denominated in stablecoins (USDCx, USDM) or include contractual volatility buffers. The treasury is not an insurance policy against ADA price fluctuations.

    2. Milestone-based disbursement tied to deliverables, not lump sums released upfront. Tweag themselves acknowledged that receiving payment in milestones was part of the problem — this should become the standard, not the exception.

    3. Transparent cost breakdowns per workstream. DReps need to see FTE counts, burn rates, and delivered-vs-paused scope before approving supplementary requests. A shortfall claim without auditable numbers is not sufficient.

    This vote is not an endorsement of the funding structure. It is a pragmatic decision to protect ongoing critical work while demanding that the governance process prevents this situation from recurring.

  • No1.4M ₳No rationale
  • Yes1.4M ₳No rationale
  • Yes1.4M ₳No rationale
  • No1.3M ₳No rationale
  • No1.2M ₳No rationale
  • No1.1M ₳No rationale
  • No1.1M ₳Rationale

    Is every proposal following the Cardano bad habit of bundling “important” with “therefore fund everything” now? We're not running a treasury cosplay here.

    Peras matters, faster finality is strategically relevant. Tweag has lineage in consensus, ledger, Genesis, and Peras-related work, and several of the streams listed in this proposal are integrated into the Cardano core stack. But the tendency to say “Peras is vital, therefore also fund a wide basket of adjacent infrastructure” has to stop! I for one do not buy basket logic at this ticket size without much harder proof of marginal necessity. Yes, a few items might be mission-critical, but others are more or less beneficial and leave me with this “while we are here, let’s also renovate the basement” impression.

    I also can't shake the feeling that the document reads partly like a rescue-financing wrapper around previously underfunded or price-impaired work. We all get the market reality, we really do, but I do not think the treasury should become a retroactive absorber of execution-financing risk just because the work is important. Cardano needs protocol-critical delivery, but more than anything else it needs a procurement spine.

    My verdict is therefore "No." I will not vote to approve a ₳40M omnibus infrastructure ask just because the words “Peras” and “resilience” are doing the heavy lifting.

  • No955.7K ₳Rationale

    The multi-year structure (2026–2028) locks up a significant portion of treasury capital in advance, during volatile economic environments, it is safer to fund infrastructure via shorter, annualized cycles rather than multi-year mandates.

  • No931.8K ₳No rationale
  • Abstain861.5K ₳No rationale
  • No825.2K ₳Rationale

    Core infrastructure development is vital, but the governance vehicle used in this proposal undermines the principles of continuous accountability and decentralized oversight. A request of this magnitude (₳39.8M) spanning a three-year horizon isolates the proposer from iterative community evaluation. By voting No, we invite the proposers to restructure this action. The proposal should be unbundled into discrete, annualized, or milestone-gated sub-proposals and resubmitted, allowing the community to fund critical elements like Peras and History Expiry progressively without relinquishing multi-year governance control.

    Historical Coherence Report
    Our voting record demonstrates consistent support for core infrastructure upgrades, as evidenced by our previous Yes votes on the Amaru Treasury Withdrawal 2026 and the Cardano Critical Integrations Budget. Voting No on this action marks a deliberate strategic shift. This shift does not reflect a change in our stance toward supporting core protocol engineering, but rather an evolving requirement for stricter structural frameworks. Moving forward, large-scale infrastructure funding must include granular milestone escrow mechanisms and shorter approval intervals to protect treasury health.

    Latin American Ecosystem Impact Statement:
    While rejecting this action temporarily delays the rollout of performance optimizations like History Expiry, a No vote ultimately protects Latin American developers and SPOs by enforcing strict treasury discipline. Demanding that the proposal be resubmitted with shorter milestones ensures that communal funds—which regional projects heavily rely on for ecosystem growth—are not locked up prematurely, thereby preserving long-term financial liquidity and accountability for the global and regional community.

  • Yes798.4K ₳Rationale

    Voting YES. Expensive proposal, but this is core infrastructure work tied directly to Peras, scalability, resilience, SPO sustainability, and developer tooling — not marketing. Cardano’s long-term competitiveness depends on shipping protocol improvements safely and reliably.

  • No717.5K ₳No rationale
  • No705.1K ₳Rationale

    No

  • No625.9K ₳Rationale

    Ask: ₳39,787,316 Duration: 2 years (2026–2028) Peras by reducing finality from twelve minutes to two is Cardano's most strategically important pending protocol upgrade and I want to see it on mainnet. This no vote is about the structure of the ask, not the team or the work.

    A PDF version of this rationale is also made available.

    I'm voting no on Tweag Core Cardano Infrastructure 2026–2028, and this vote requires the same care I'd give any proposal involving work I genuinely want funded. Tweag has earned a place in Cardano's infrastructure story that cannot be manufactured quickly, eight years building Ouroboros Genesis, driving Peras design, and maintaining consensus-layer components that few teams in this ecosystem have the depth to touch. I voted yes on their prior ₳11M request. Peras by reducing finality from twelve minutes to two is Cardano's most strategically important pending protocol upgrade and I want to see it on mainnet. This no vote is about the structure of the ask, not the team or the work.
    The primary problem is bundling. The proposal explicitly states it is "a single delivery pipeline, not a modular menu" the proposer's own framing for why 17 work packages cannot be separately evaluated. Peras v1 mainnet readiness, Peras v2 pre-agreement, History Expiry, Hard Fork Mempool Bridger, Conformance Testing, Adversarial Fork Testing, Canonical Ledger State, Plutus Script Re-Executor, Mutation Testing, Hoarding Node extended deployment, Block Cost Investigation, and ongoing maintenance are not the same strategic tier. Peras v1 is urgent, critical, and irreplaceable. Block Cost Investigation and Mutation Testing are valuable but not equivalently urgent. Bundling them as inseparable forces DReps into a binary decision on nearly ₳40M without the ability to prioritize. That's not a delivery efficiency, it's a governance problem transferred from the proposer to the community.
    The two-year timeline compounds the issue. Most proposals in this cycle request one year of funding and return to governance for renewal, that structure preserves DRep discretion as priorities evolve, market conditions shift, and delivery evidence accumulates. Committing ₳39.8M across 2026–2028 in a single action removes that annual verification gate. The current NCL runs through mid-2027; a 2028 delivery horizon extends beyond it. Tweag's own rationale states that two years is needed to align Peras v2 with an HFC window and is an engineering reason, not a governance reason. The better structure is one year funded, delivered, then a return to governance for year two with Peras v1 results in hand.
    The financial transparency is also insufficient for an ask at this scale. ₳39.8M supported by a blended hourly rate and a five-year ADA conversion average is not a budget, it's a price. There is no milestone-level cost allocation, no FTE count by workstream, no disclosed CBU/ARK subcontract amounts, no overhead breakdown. At $176/hour, the implied annual FTE cost runs approximately $365,000 per engineer, and well above the threshold I apply before expecting explicit cost justification. That rate may be appropriate for Tweag's consulting model, but without a labor category breakdown the community cannot independently verify whether the amount is appropriately scoped for the work. The prior ₳11M 2025 funding also needs a clean, independently auditable closeout before a new portfolio of this scale can be evaluated on its own merits, several 2025 workstreams are publicly noted as paused, and the current proposal does not distinguish between completing prior obligations, recovering a shortfall, and genuinely new scope.
    Tweag knows what a resubmission should look like and the DRep community has stated it clearly and consistently across every substantive no vote on this action. Peras v1 mainnet readiness, minimum required safety scaffolding, and the hard-fork tooling that enables it, should be unbundled, one year, with milestone-level budget disclosure and a published 2025 closeout. That proposal gets evaluated on its own merits against a team with proven execution. I want to fund Peras. I need a structure that lets me do it responsibly. Vote no, with strong encouragement to resubmit on those terms.

  • No605.7K ₳Rationale

    🗳️ VOTING: Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028

    Tweag is requesting ₳39,787,316 ADA from the Cardano treasury — nearly $10 million — for infrastructure work planned for 2026–2028.

    The proposal includes Peras, testing frameworks, developer tooling, network monitoring, storage optimization, and node infrastructure maintenance.

    My vote: NO.

    I am not voting against Peras.
    I am not saying Tweag is a weak team.
    I am voting against the funding model itself.

    Requesting treasury funds for 2 full years upfront is not healthy governance for Cardano.
    First there should be clear delivery and measurable results after 1 year, then a new review, new evaluation, and a new vote.

    Almost 40 million ADA in a single package is too large.
    Especially when critical infrastructure, optional tooling, maintenance, and secondary initiatives are all bundled together.

    The Cardano treasury is not an unlimited wallet.
    If every strong infrastructure contractor starts requesting tens of millions of ADA years in advance, governance turns into a constant treasury drain.

    The approach should stay simple:

    • deliver results first
    • return for additional funding later
    • smaller focused proposals
    • better transparency
    • stronger treasury discipline

    That is why my vote on this proposal is: NO.

    I registered as a DRep and I am ready to help shape the future of the ecosystem.
    Optimistic about building the largest digital community in the world. 🖤

    My DRep ID:
    ➡️ drep1y269ehxj30k4vfzfc2z84v0xykd3amuy2xn0kv9zf8rhcec2fg2jr

    More info: https://t.me/PROCENT666/338

    #Cardano #ADA #DRep #CardanoGovernance #Peras #Treasury #Blockchain #Crypto #Web3