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.

  • Abstain584.2M ₳Rationale

    Summary
    Yoroi DRep votes ABSTAIN on Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026-2028. While Yoroi has confidence in Tweag's technical expertise and track record, the scale and structure of this request warrant a more measured approach before full endorsement.
    Rationale
    Tweag's track record and the importance of this work are not in question. The focus on Peras mainnet delivery, conformance testing, and node observability addresses areas the ecosystem genuinely needs, and Tweag has the institutional knowledge to deliver them. Yoroi does not take lightly the risk of disrupting continuity on work of this criticality.

    A two-year, 39.79M ADA commitment requires stronger annual accountability gates.
    The proposal bundles 17 work packages across a broad scope into a single funding action, with the full two-year amount requested upfront. For a commitment of this magnitude, Yoroi believes the community deserves clearer year-by-year milestones and a structure that allows the second year's funding to be contingent on verified first-year delivery.

    A phased submission would be easier to support.
    Splitting the proposal into annual tranches would preserve the continuity of the work while providing the governance oversight that a request of this scale warrants. Yoroi would be in a significantly stronger position to vote YES on a first-year proposal with a clearly defined scope and a commitment to return for the second year upon delivery.

    Conclusion
    Yoroi respects the depth of Tweag's contribution to Cardano's infrastructure and the importance of the work outlined in this proposal. Our abstain is not a rejection of the team or the programme, but a considered view that a commitment of this scale deserves a more structured approach to community oversight. We would encourage a resubmission structured around annual tranches and look forward to supporting that work through the governance process.

  • NoChanged435.8M ₳Rationale

    I vote NO to "Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028".

    While I am confident in the necessity of Peras, I recommend resubmission for the following two reasons:

    • Several developers have pointed out that the proposal includes unnecessary items and overlaps with existing efforts and tools. I hope you will focus on the critical infrastructure aspects.

    • Also, given the current NCL usage, it will likely be difficult to charge for two years' worth of costs; it should be reduced to one year's worth, and the next cost should be charged once the next NCL is released.

    ーーー

    私は「Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028」にNOを投票します。

    私はPerasの必要性に自信を持っていますが、次の2点から、再提出を推奨します。
    ・複数の開発者から、不必要な項目、既存の取り組みやツールと重複する提案書に含まれているという指摘がありました。重要なインフラ部分に内容を絞り込むことを願います。
    ・また、現在のNCLの使用状況などから見て、2年分のコストを請求するのはおそらく難しいです、1年分に縮小して、次のNCLが解放されてから次のコストを請求する必要があります。

    Earlier votes

    Yes2mo agoSuperseded

    I vote YES to "Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028".

    I understand that this proposal is currently unpopular in terms of timeframe and scope, but Peras + Leios is a necessary piece in competing with other L1 solutions. Considering the current volume of Cardano transactions, Peras may offer a more noticeable improvement in scalability than the currently popular Leios. This speeds up finality from 12 minutes to 2 minutes under certain conditions, so it is effective regardless of transaction volume. You can verify the team's track record by checking Tweag's activities in cardano-ledger (346 commits = #2 contributor (following iohk.io with 985)), cardano-node, and the ouroboros-consensus GitHub repository.

    私は「Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028」にYESを投票します。

    この提案書が期間やスコープの観点から、現在不人気であることは理解していますが、Peras+Leiosは他のL1との競争において必要なピースです。現在のCardanoのTxの利用量を考慮すると、現味人気のあるLeiosよりも、Perasはそのスケーラビリティ向上の効果を実感しやすいかもしれません。これはファイナリティを12分から2分へ一定の条件下で早めるものですから、Tx量が高くても低くても、効果があります。cardano-ledger(346 commits = #2 contributor (985 iohk.io に次ぐ))、cardano-node、ouroboros-consensus githubレポジトリなどでのTweagの活動を確認することがチームの実績を確認できます。

  • Abstain293M ₳Rationale

    Summary
    EMURGO as a DRep votes ABSTAIN on the treasury withdrawal titled "Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026-2028", with rationale outlined below.
    Rationale
    Tweag has a long and well-documented track record on Cardano's core infrastructure, and the work packages in this proposal address areas of genuine importance to the ecosystem. The focus on Peras mainnet readiness, including production cryptography, conformance testing, and operational hardening, is directly aligned with one of the most consequential protocol milestones in the current cycle. EMURGO recognises the value of that continuity and does not question Tweag's capability to deliver.

    The primary concern is the scale and duration of the commitment being requested. At 39.79M ADA over two years, this is one of the larger single-team allocations in the current budget cycle, and the proposal covers 17 work packages spanning a wide range of scope and maturity. A multi-year, multi-package request of this size benefits from clearer year-by-year prioritisation and more granular milestone gates that allow the community to assess progress before the full amount is committed.

    EMURGO would be more comfortable supporting this proposal if it were structured in annual tranches, with the second year's funding contingent on verified delivery of the first. This would preserve the continuity of Tweag's work while giving the community appropriate oversight over a commitment of this magnitude. We would encourage the team to consider whether a phased submission would better serve both the project and the broader governance process.

  • No254.7M ₳No rationale
  • No222.9M ₳Rationale

    Overview of EDC vote on IO + Tweag proposals:

    ❌ IO: Developer Experience Initiative
    ✅ IO: Cardano Upgrades
    ✅ IO: Consensus Initiative
    ✅ IO & Ensurable Systems: Cardano Maintenance Initiative
    ❌ IO & Midgard Labs: L2 Scalability Initiative
    ➖ IO: Cardano High Assurance Technical Collaboration
    ✅ IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability
    ❌ Blockfrost: Maintenance and Next Generation Indexing
    ❌ Pogun: Capital Without Compromise
    ❌ Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028
    ✅ IO: Cardano Vision 2026: Human Centred, Scalable, Post Quantum Secure - IO Research

    Combined:

    ✅ YES: 147.7m ADA / 35.5m USD
    ❌ NO: 74.0m ADA / 17.7m USD
    ➖ ABSTAIN: 13.1m ADA / 3.1m USD

    All proposed initiatives sound like nice-to-haves for Cardano; some are essential for Cardano's momentum. The asks on almost all of the proposals are too high. That's why we had to triage and prioritize the essentials over the nice-to-haves, allow for a remainder on the NCL, and leave room for other vendors to enter the race for this year's budget.

    We want to make it clear that a NO does not mean we are against the proposed tech. Quite the opposite, for example we'd love to look into Midgard and Pogun for Eternl. We also appreciate the work Blockfrost is doing, trying to replace itself with decentralized tech.

    But we need to leave some part of the NCL for other vendors and initiatives.

  • Abstain165.7M ₳No rationale
  • No120.2M ₳Rationale

    The Cardano Foundation votes NO. We recognize Tweag's long-standing contribution to Cardano's core infrastructure and the strategic value of Peras, but the bundled two-year scope, unresolved 2025 delivery, and insufficient budget transparency prevent our approval. We encourage a leaner resubmission.

    A PDF version of this rationale is also made available.

    The Cardano Foundation recognizes Tweag by Modus Create as a deeply experienced contributor to Cardano's core infrastructure, engaged on the consensus and ledger layers since 2018 and central to the design of Peras. We see strategic value in this portfolio, and we regard faster finality through Peras, alongside conformance, mutation, and adversarial-fork testing, as public-good infrastructure that strengthens the network's security and resilience.

    Our NO vote is not a rejection of this work or of Peras, but of this specific governance action as submitted. Our concerns are based on the following points:

    • Improper Bundling: The proposal is, by the proposer's own description, "a single delivery pipeline, not a modular menu," requiring DReps to approve high-value mainnet delivery together with narrower tooling, extensions, and routine maintenance. This forces an all-or-nothing decision on workstreams of very different strategic priority and maturity, and prevents us from supporting the strongest components on their own merits.
    • Insufficient Financial Transparency: A treasury request of 39,787,316 ada (approximately $9,946,829) over two years is supported only by a headline blended rate and conversion assumption. Milestone-level budgets, FTE allocation, subcontractor and audit costs, overhead, and the basis for the contingency are not disclosed in a way that lets DReps independently assess whether the amount is appropriately scoped.
    • Unclear Relationship to Prior Funding: In 2025, Tweag has already received 11,070,322.68 ada from the Treasury for related workstreams. Public information indicates that several 2025 workstreams were paused or remain incomplete, attributed to ada conversion timing and price movement. The current action does not provide an independently auditable closeout of that prior funding, nor a clean separation between completing prior obligations, recovering a shortfall, and genuinely new work. We do not believe the Treasury should absorb a prior funding shortfall embedded into a larger new portfolio without granular accounting.
    • Timeline and Net Change Limit Discipline: A two-year package spanning 2026–2028 is difficult to reconcile with treasury discipline under the applicable Net Change Limit period. A shorter horizon would allow the community to reassess scope, delivery, and cost against demonstrated results.

    Recommendations for a Future Submission

    This NO vote is intended to be constructive. We would encourage the proposer to prepare a revised submission that:

    • Unbundles the portfolio, separating Peras v1 mainnet readiness and the minimum required safety scaffolding from Peras v2, developer tooling, Hoarding Node extensions, and ongoing maintenance, so each can be judged on its own justification.
    • Discloses milestone-level financials, including FTE, subcontractor, audit, overhead, and contingency breakdowns, with strict payment gates and clawback terms for non-delivery.
    • Publishes an independently auditable 2025 closeout report with milestone acceptance evidence, and clearly identifies which 2026 costs complete prior obligations versus new work.
    • Aligns with a shorter horizon, such as 12 months or the current NCL period, rather than a 2-year package.

    The Cardano Foundation votes NO. This vote is intended to be constructive: we encourage Tweag to return with leaner, modular proposals that prioritize Peras v1 mainnet readiness, align with a shorter funding horizon, publish an independently auditable 2025 closeout, and provide milestone-level budget and delivery detail. We value Tweag's work and look forward to reviewing a revised submission on these terms.


    NOTE on 'Internal Voting':
    The fields constitutional and unconstitutional below reflect the CF governance teams' individual opinions whether they are for or against the proposal. Reason for this inconsistency is, that CIP-136 is at the moment only applicable to CC rationales, but we want to record the internal opinions of our DRep assessment transparently as well.

  • Abstain92.2M ₳No rationale
  • No91.5M ₳Rationale

    As a DRep, I decided to vote NO for proposal: Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028

    My rationale:

    First, I want to acknowledge that Tweag is one of the strongest technical teams working in the Cardano ecosystem. They have consistently delivered high-quality infrastructure work, and many of the areas covered in this proposal are genuinely important for Cardano's long-term success.

    In particular, I believe Peras is extremely important. Faster finality is a meaningful upgrade for Cardano and directly improves user experience, exchange integrations, DeFi usability, and overall network competitiveness. Reducing finality from roughly 12 minutes to around 2 minutes is a major improvement, and I appreciate that Tweag is helping to move this forward.

    The proposal also includes several valuable infrastructure improvements around testing, resilience, observability, developer tooling, and node efficiency. This is clearly more serious and more aligned with core infrastructure than many other treasury proposals currently being discussed.

    However, despite appreciating the team and the technical value of the work, I decided to vote NO for three reasons.

    The first issue is the two-year budget request.

    Most teams in this budget cycle are requesting one year of funding and returning to governance for renewed approval. Tweag is asking the treasury to commit funding for two full years upfront.

    I do not believe this is healthy treasury governance.

    Cardano governance is still very new. Priorities can change quickly. New teams may emerge. Market conditions may shift. The ecosystem may discover that certain priorities are more urgent than others. Locking treasury capital for two years reduces flexibility and weakens future governance decision-making.

    Even if the team believes a longer timeline helps align with hard fork schedules, the better approach would be to request funding for year one, deliver results, and then return to governance for year two funding.

    That creates stronger accountability and gives DReps the ability to reassess progress before committing additional treasury resources.

    The second issue is cost.

    The proposal uses an average rate of $176 per hour for senior engineering work.

    Another concern is proportionality. Tweag is asking nearly ₳40M over two years, which is significantly larger than other infrastructure teams such as Blink Labs (Amaru) and Dingo that are also working on critical Cardano infrastructure. Client diversity, alternative node implementations, and infrastructure resilience are equally important priorities. In a constrained treasury environment, DReps must compare proposals relative to each other, not evaluate each proposal in isolation.

    I understand that highly specialized infrastructure engineers are expensive. Cardano requires elite engineering talent.

    However, we are entering an era where AI tools are rapidly improving developer productivity across software engineering. These tools should increasingly reduce development costs, improve efficiency, and allow teams to deliver more with smaller budgets.

    Treasury participants should expect some of these efficiency gains to be reflected in pricing.

    At nearly $10 million, this proposal feels expensive relative to current treasury constraints.

    The third issue is bundling.

    This proposal combines multiple infrastructure initiatives into a single treasury withdrawal, including Peras, testing frameworks, developer tooling, observability infrastructure, storage optimization, and ongoing maintenance work.

    Many of these initiatives may be valuable, and Peras is clearly the flagship priority. However, not all of them carry the same level of urgency.

    Some items feel mission-critical for Cardano in the near term, while others could potentially be funded later or submitted as separate proposals.

    By bundling everything into one request, DReps are forced into a binary decision where they may strongly support certain components while having reservations about others.

    That reduces treasury precision and makes proper prioritization much harder, especially in a budget cycle where many teams are competing for limited treasury resources.

    This matters even more because the Net Change Limit is relatively constrained and many other teams are competing for treasury funding. DReps need to make difficult decisions and focus on the highest-priority initiatives first.

    Cardano cannot approve every large proposal simply because the underlying work sounds useful.

    For me, the path to approval is straightforward:

    • Request funding for one year only
    • Unbundle the proposal into clearer priority categories
    • Reduce overall costs and reflect improved software development efficiency

    If Tweag returns with a more focused proposal built around these principles, I would be far more comfortable supporting it.

    The team is highly capable, and Cardano absolutely needs infrastructure work like Peras.

    But treasury governance must remain disciplined, flexible, and focused on prioritization.

    If you'd like to support my work, consider delegating to the MANDA pool and backing me as a DRep. Your support is the only way I can get time for governance.

    MANDA Pool ID:
    pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

    My DRep ID:
    drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

  • Abstain86M ₳Rationale

    SIPO DRep votes Abstain on this governance action.

    SIPO highly values Tweag by Modus Create's contribution to core infrastructure. Ouroboros Peras (faster finality, ~12 min to ~2 min) and History Expiry (full-node economics and the preservation of decentralization) are foundational to Cardano's path to 2030 scaling, and Tweag has been a core contributor to the Cardano node diffusion layer and the Ouroboros implementation for over eight years since 2018. This proposal is specialist engineering within the IO-led core-protocol development consortium and is, at the work level, largely complementary to IO Research's research layer. Funds are de-risked and released progressively through Intersect administration, milestone-based fixed-price contracting, third-party milestone assurance, and an audited treasury smart contract; governance and budget transparency are appropriate.

    Because SIPO recognizes the importance of this work, SIPO chooses Abstain rather than an active No. It is not SIPO's intent to contribute to the rejection of well-governed, essential core work.

    At the same time, SIPO refrains from actively supporting this proposal, for two reasons. First, with IO leading and funding core-protocol development in 2026, Tweag's parallel direct ₳39.8M treasury request leaves the funding-responsibility split within the decentralized model unresolved (IO coordination/sub-funding versus a direct treasury draw). Second, under NCL fiscal discipline, ₳39.8M is the single largest direct withdrawal at roughly 28% of the estimated remaining NCL, and SIPO prioritizes preserving slate room until the structural funding model settles.

    SIPO's position is not fixed. SIPO remains open to supporting a future coordinated or revised funding structure once the role split is clarified. This vote is SIPO DRep's recorded position.

    SIPO DRep は本ガバナンスアクションに Abstain(棄権)を投じます。

    SIPO は、Tweag by Modus Create のコアインフラへの貢献を高く評価します。Ouroboros Peras(finality の高速化、約12分→約2分)と History Expiry(フルノードの経済性=分散性の維持)は Cardano の 2030 スケーリングの基盤であり、Tweag は 2018 年以来 8 年にわたり Cardano node の diffusion 層と Ouroboros 実装を支えてきた中核貢献者です。本提案は IO 主導のコアプロトコル開発コンソーシアムにおける specialist engineering であり、IO Research の研究レイヤーとは作業レベルで概ね補完関係にあります。資金配分は Intersect 管理・マイルストーン固定価格契約・第三者検収・監査済みトレジャリースマートコントラクトを通じて段階的に de-risk されており、ガバナンスと予算の透明性は適切です。

    この作業の重要性を認識するため、SIPO は能動的な No(否定)ではなく Abstain を選びます。良く設計され、かつ essential なコア作業の否決に加担することは SIPO の意図ではありません。

    一方で、SIPO は本提案を能動的に支持することも控えます。理由は次の 2 点です。第一に、IO が 2026 年にコアプロトコル開発を leading and funding する中で、Tweag がトレジャリーから並行して ₳39.8M を直接要求する構造は、分散化された資金責任の役割分担(IO による調整・sub-fund か、トレジャリー直接引き出しか)が未解決です。第二に、NCL 財政規律の下で ₳39.8M は推定残り NCL の約 28% を占める単独最大の直接引き出しであり、構造的な資金モデルが定まるまで SIPO はスレートの余地を残すことを優先します。

    SIPO の立場は固定的ではありません。役割分担の明確化や、調整された/改訂された資金構造が示されれば、将来的な支持に開かれています。本投票は SIPO DRep の記録上の立場表明です。

  • No84.3M ₳Rationale

    The faster finality that would come with Ouroboros Peras is certainly desirable. But, this nearly $10 million USD price tag is too rich for my blood right now. It's also a two year project. They could have sought to fund only the first year. This is probably better timed for a future when we get more bang for the buck for our Treasury ADA.

  • No77.7M ₳No rationale
  • No76.8M ₳Rationale

    We suggest making changes to the omnibus/bundled proposal to focus only on the essential infrastructure and narrow the weaker mutation-testing or duplicated assurance items where Blaster or existing tooling is stronger.

    A PDF version of this rationale is also made available.

    We suggest making changes to the omnibus/bundled proposal to focus only on the essential infrastructure and narrow the weaker mutation-testing or duplicated assurance items where Blaster or existing tooling is stronger.

    We would like to support the critical infrastructure portions, especially Peras (finality), History Expiry which are essential for Cardano, but many of the other items.

  • Abstain75.2M ₳No rationale
  • No74.5M ₳Rationale

    I understand the importance of many of the areas covered by this proposal. In particular, improvements related to Peras finality, History Expiry for reducing SPO operational burden, and stronger conformance and adversarial testing are all meaningful topics for strengthening Cardano’s long-term L1 infrastructure. I also recognize Tweag’s long-standing contributions to Cardano’s core infrastructure development.

    At the same time, given the current treasury environment, I believe the proposal has become too broad in scope. The proposal combines 17 work packages across 9 infrastructure areas, simultaneously covering finality, testing, tooling, observability, storage economics, debugging, and several other priorities with different levels of urgency and ecosystem impact.

    While the proposal argues that these components form a “single delivery pipeline” with strong interdependencies, I believe a more focused and phased approach would be preferable under current treasury conditions. In particular, I believe a proposal more narrowly centered around Peras mainnet readiness and critical infrastructure components such as History Expiry would have been easier to evaluate positively and prioritize for funding.

    Cardano is currently in a phase where treasury management and prioritization require a higher degree of discipline and scope control, especially for large bundled proposals. From that perspective, while this proposal contains many valuable ideas, I believe the overall scope and budget size are too large at this stage.

    For these reasons, I vote against this proposal.

    本提案が扱っている領域の重要性自体は理解しています。特に、Perasによるfinality改善、History ExpiryによるSPO運用負荷軽減、conformance testingやadversarial testingによる安全性強化などは、Cardanoの長期的なL1基盤を支える上で重要なテーマだと考えています。Tweagが長年Cardanoのコアインフラへ貢献してきた実績についても評価しています。

    一方で、現在のトレジャリー状況を踏まえると、本提案はスコープが広すぎる印象を受けました。17 work packagesを9つのインフラ領域へ同時展開する構成となっており、finality、testing、tooling、observability、storage economics、debuggingなど、多数の異なる優先度のテーマが一括で含まれています。

    提案内では、これらを「single delivery pipeline」として相互依存的な構造であると説明していますが、現時点では、より優先順位を絞った段階的アプローチの方が望ましいと感じています。特に、Peras mainnet readinessやHistory Expiryなど、Cardano全体へ直接影響するコア部分に集中したproposalであれば、より前向きに評価しやすかったと感じています。

    現在のCardanoは、トレジャリー管理や予算優先順位について慎重な判断が求められるフェーズにあり、大規模包括提案については特に厳格なスコープ管理が必要だと考えています。その観点から、本提案は重要な内容を含んでいる一方で、現時点では範囲と予算規模が大きすぎると判断しました。

    そのため、今回は反対とします。

  • No73.1M ₳Rationale

    I love the Peras work (~2 min finality is a huge win), but bundling 17 packages makes it too hard to analyze. The 39.7M ADA ask is too high for an all-or-nothing vote. I value Tweag but cannot support this mega proposal. I urge a decoupled Peras proposal be submitted with extreme urgency.

    A PDF version of this rationale is also made available.

    I want to explicitly state that I absolutely love the Peras work highlighted in this proposal. Achieving faster finality is a massive win for Cardano, and the technical merit of that specific upgrade is undeniable. Achieving ~2 min finality from the current ~12 min finality is extremely ambitious and valuable to Cardano.

    However, bundling seventeen different work packages into a single, unchangeable delivery pipeline makes it incredibly difficult to properly analyze and support. The overall financial ask of nearly forty million ADA is exceptionally high, and bundling everything together forces DReps into an all-or-nothing decision on a massive volume of community capital.

    While I highly value Tweag's historical contributions and engineering expertise towards Cardano, I cannot support a mega proposal of this scale under these parameters. I would warmly welcome and look forward to a new, decoupled proposal covering the Peras infrastructure work specifically so I can further analyze in detail and possibly prioritize it as a DRep. From my current perspective, I strongly recommend that this standalone Peras proposal be submitted with extreme urgency.

  • Abstain62.7M ₳No rationale
  • No53.8M ₳Rationale

    I am voting No on the Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026-2028 proposal.

    I strongly agree with the direction of the work this proposal addresses, including faster finality through Peras, SPO economic sustainability through History Expiry, and node diversity support through Conformance Testing.

    I also deeply recognize Tweag's eight years of continuous contribution to Cardano's core infrastructure since 2018 (implementing Ouroboros Genesis, contributing to Peras design, and others), as well as their responsible approach in self-financing critical work despite the ADA price losses in 2025.

    That said, I cannot support the proposal in its current structure. Two reasons.

    1. Bundling 17 Work Packages into a single governance action.

    This proposal bundles 17 work packages of varying maturity and priority into a single governance action. DReps have no means to separately evaluate production-ready work, early-stage research work, and work where overlap with other ongoing efforts has been raised.

    1. ₳39.79M upfront commitment over two years with no annual verification gate.

    The structure commits the full amount upfront, over twice the duration of a standard governance cycle, without verification of first-year delivery. The second year's funding should be designed to be contingent on verified first-year delivery.

    This No is not a rejection of the Tweag team or the value of the work this proposal addresses. The continuity of the work of a team that has stewarded Cardano's core infrastructure for eight years deserves to be preserved.

    However, a structure that commits 17 WPs × 2 years × ₳39.79M in a single action fails to satisfy two governance principles simultaneously: separability of evaluation, and annual verification.

  • Abstain50.4M ₳Rationale

    I am abstaining on "Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028". Peras v1/v2 mainnet delivery is core Tier 2a infrastructure: reducing settlement finality from approximately 12 minutes to ~2 minutes is a meaningful and user-visible protocol improvement. Tweag has a credible track record in formal verification and core Cardano work, making them a qualified deliverer. The bundling of 17 work packages across 9 areas is a structural concern — the governance community cannot selectively approve individual workstreams — but the proposer's interdependency argument is plausible given the integrated nature of the deliverables. ₳39.8M over 2 years is a large ask, but the roadmap is clear and the timeline is structured. Abstaining reflects the bundling risk and current market conditions rather than a judgment against the technical content or Tweag's capability. Reference: https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem/ [Japanese version follows] 私は、「Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028」に棄権票を投じます。Peras v1/v2本番展開(ファイナリティ約12分→約2分)はTier 2aのコアインフラとして正当な資金需要があり、ユーザーが体感できる重要なプロトコル改善です。Tweagは形式検証・カルダノコア開発で実績のある組織であり、実施主体として適切です。9領域にまたがる17ワークパッケージを一括したバンドル構成はガバナンス評価を複雑にしており、個別のワークストリームを選択的に承認することができない点は構造的懸念です。一方、提案者が主張する相互依存性の論拠は成果物の統合的性質を踏まえると一定の合理性があります。₳39.8Mは2年間の提案として大規模ですが、ロードマップは明確で期間も構造化されています。棄権は技術内容やTweagの能力への否定ではなく、バンドルリスクと現在の市場状況を踏まえた判断です。参照: https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem-jp/

  • No50M ₳Rationale

    Overall, I support this proposal. However, in its current form, I have to vote No.

    Given the tightly constrained budget for the current year, there simply isn't enough funding available to satisfy requests covering multiple years in advance.

    If the proposal is revised to focus on a one-year scope and clearly prioritize the most important objectives for that period, I would be happy to support it.

  • No49.5M ₳No rationale
  • No47.6M ₳No rationale
  • Abstain42.9M ₳No rationale
  • No40.1M ₳Rationale

    As much as we need faster finality on chain, this proposal is too expensive, planning for a too long time horizon and simply not what Cardano currently needs.

  • Yes38.1M ₳Rationale

    Peras is already an ongoing core protocol effort, and continuity matters. Stopping and restarting projects like this could waste a lot of the money and engineering effort already invested over the years.

    Teams like Tweag also represent valuable long-term experience within the ecosystem. While Cardano often focuses on onboarding new developers, maintaining continuity among experienced protocol contributors is important as well.

    That said, I still think the budget is on the high side, and some cost reductions or scope adjustments would likely make the proposal stronger.

  • No37.8M ₳No rationale
  • No36.9M ₳No rationale
  • AbstainChanged34.6M ₳Rationale

    財政が厳しい中で、この17項目の中で『もし半年遅らせても致命傷にならないもの』は本当に一つもないのか? 100%か0%かの選択ではなく、優先順位をつけた段階的な予算承認は不可能なのか?17のパッケージがすべて「今」必要か? 財政が厳しいなら、Perasだけに絞るなど、モジュール化(切り分け)して予算を抑えるよう修正を求める余地はないか?1つの会社のこれだけの予算を全部とは現状では厳しくないか?

    Earlier votes

    No2mo agoSuperseded

    財政が厳しい中で、この17項目の中で『もし半年遅らせても致命傷にならないもの』は本当に一つもないのか? 100%か0%かの選択ではなく、優先順位をつけた段階的な予算承認は不可能なのか?17のパッケージがすべて「今」必要か? 財政が厳しいなら、Perasだけに絞るなど、モジュール化(切り分け)して予算を抑えるよう修正を求める余地はないか?1つの会社のこれだけの予算を全部とは現状では厳しくないか?

  • No33.5M ₳Rationale

    No. ₳39.8M (~$9.95M) committed across 2026-2028 in one withdrawal pre-allocates treasury capital across multiple annual budget cycles, escaping yearly re-authorization. The Peras finality engineering is strong; the multi-year structure is the problem. Re-scope to an annual tranche.

    A PDF version of this rationale is also made available.

    Voting No. ₳39,787,316 (~$9.95M) for Tweag by Modus Create to deliver core infrastructure work across a two-year 2026-2028 timeline, with Peras mainnet finality as the headline. The engineering is the kind of L1 work the treasury should fund. The objection is the funding structure: committing roughly $10M across three calendar years in a single withdrawal, rather than the merit of the work. Read against the Cardano First framework:

    • Economic Sustainability: Lead concern. A single withdrawal spanning 2026-2028 pre-allocates treasury capital across multiple annual budget cycles. The treasury is budgeted year by year, and a three-calendar-year lump ask removes the annual checkpoint where the community re-authorizes spend against current priorities and a current Net Change Limit. Milestone gating controls when funds disburse, but the full ₳39.8M is committed up front against budgets the community has not yet set. The parallel Amaru "Treasury Withdrawal 2026" shows the right shape: scoped to a single year.
    • Governance Transparency: The 2026-2028 horizon escapes annual re-authorization. Even with Intersect as administrator, milestone-based fixed-price contracts, and proportional return of unspent funds, locking three years of scope now reduces the DRep body's ability to course-correct as Peras, Leios, and the hard-fork roadmap evolve. Multi-year asks should return to the voting body each year, not commit the body once for the whole span.
    • Scalability: This is the strongest part of the proposal and the reason this is a reluctant No. Peras mainnet finality, History Expiry, and the conformance and adversarial testing work are real L1 improvements I want funded. The structure is the problem, not the engineering.
    • Decentralization: Neutral to positive, and not a factor driving the No. Tweag by Modus Create is a non-incumbent core vendor, and open-source, publicly tracked deliverables are the right default.

    Risks I'm accepting with this No:

    1. Peras and the HFC window. The proposal argues the two-year span aligns Peras v2 with a Hard Fork Combinator window. Forcing a re-scope to annual tranches risks delaying Peras v2 or missing that window. I accept that risk in exchange for preserving the annual budget checkpoint.
    2. Penalizing a well-structured ask. Tweag uses Intersect-administered fixed-price milestones with proportional refunds, which is among the better-governed budget proposals. Voting No on duration alone risks signaling that disciplined vendors gain little from good structure. The signal I intend is narrower: structure the duration annually.
    3. Strong technical work stalls for non-technical reasons. If this structural concern is widely shared, essential finality work fails to fund and has to find another path. I accept that in preference to normalizing three-year lump withdrawals.

    The engineering is exactly what the treasury should back. The three-year, roughly $10M single withdrawal is not the way to back it. Re-scope to an annual 2026 tranche that returns to the DRep body for 2027 and 2028 and this becomes a likely Yes. No.

  • Yes31.4M ₳Rationale

    I am voting Yes on this proposal.

    Tweag has consistently delivered high‑quality work on Plutus, Plutus Core, formal methods, and other core components that directly support the safety and long‑term reliability of Cardano. This proposal continues that essential infrastructure work over a multi‑year period, providing clear public‑goods value to the entire ecosystem.

    The requested budget is significant, but it is reasonable for a highly specialized research and engineering team operating at this level. Strengthening Cardano’s core infrastructure is foundational for future adoption, developer experience, and ecosystem resilience.

    For these reasons, I support this proposal.

  • Abstain27.9M ₳Rationale

    I generally support the direction of the work and think several deliverables are valuable, especially Peras and the hoarding node. Faster finality would be a meaningful improvement for Cardano, and the hoarding node seems useful for research and network observability around things like orphaned blocks/transactions, propagation issues, and invalid slot leader claims.

    That said, I am not fully ready to vote YES on this version. The ask is large, and I would like to see a clearer explanation of the practical use cases Peras unlocks, how this work should be prioritized relative to other core infrastructure, and how it fits alongside Leios. I do not want to signal opposition to the work itself, but given the current NCL environment and competing priorities, I am abstaining for now.

  • No27.9M ₳No rationale
  • No26.3M ₳Rationale

    This should be proposed with IO and Intersect as part of the 2030 roadmap.

  • Yes26.1M ₳Rationale

    Rationale — Tweag Core Infrastructure (Peras + Resilience Stack)
    Header

    You don’t scale safely by adding throughput alone—you scale by making the system provably correct under stress.

    1. Constitutional Gate (2.4(a)(d))

    Assessment: PASS (High Complexity, High Importance)

    Strong alignment with long-term sustainability, scalability, and resilience
    Clearly defined work packages (17 across 9 infrastructure areas)
    Includes milestone-based delivery, audits, and oversight via Intersect
    Treasury usage justified as core protocol and safety infrastructure

    1. Decision Declaration

    Vote: YES (Critical Infrastructure, High Execution Complexity)
    This is required to safely deliver Peras, Leios, and future scaling—but demands disciplined oversight.

    1. Context Framing

    This proposal funds core protocol and resilience infrastructure across:

    Peras (faster finality ~2 min vs ~12 min)
    Testing, validation, and adversarial simulation frameworks
    Node efficiency + storage sustainability (History Expiry)
    Network observability + debugging tools

    Core issue:

    Scaling upgrades (Leios, Peras) do not deliver value unless they are production-safe and operationally sustainable

    1. Core Evaluation
      4A. Strategic Alignment
      Direct alignment with:
      L1 scalability (Peras + Leios readiness)
      Network resilience
      Decentralization sustainability
      Enables:
      Safe scaling
      SPO viability
      Long-term protocol health

    This is deep infrastructure, not user-facing but absolutely required.

    4B. Economic / Market Impact

    Positive:

    Faster finality → better UX for:
    DeFi
    payments
    History Expiry:
    Reduces SPO cost burden
    Preserves decentralization
    Testing frameworks:
    Reduce catastrophic failure risk

    Critical Insight:

    This protects the economic layer from failure rather than directly generating growth

    4C. Execution & Accountability

    Strengths:

    17 interdependent work packages:
    Not fragmented, designed as a pipeline
    Clear ownership:
    Tweag (deep protocol experience since 2018)
    Strong delivery structure:
    Intersect-administered contracts
    Third-party assurance
    Public dashboards + updates

    Notable Strength:

    Explicit focus on:
    testing, validation, and failure scenarios
    → Rare in most ecosystems
    4D. Risk Assessment

    Primary Risks:

    High complexity across:
    consensus
    testing frameworks
    node architecture
    Interdependency risk:
    failure in one area impacts others
    Long timeline:
    2 years (2026–2028)

    Secondary Risks:

    Budget size (~₳39.8M)
    Coordination with:
    IOG
    ecosystem upgrades
    Delays tied to:
    hard fork windows

    Mitigation:

    Milestone-based contracts
    Independent assurance
    Phased delivery (Peras v1 → v2)
    4E. End-User Impact

    Builders:

    Better debugging tools
    More reliable infrastructure

    Users:

    Faster finality
    Fewer failed or lost transactions

    SPOs:

    Lower storage requirements
    More sustainable node operation

    Capital Providers:

    Reduced systemic risk
    5. Governance Quality Signal
    Strong governance alignment:
    Uses Intersect + oversight committees
    Transparent structure:
    Open-source deliverables
    Public reporting

    However:

    Complexity reduces visibility for average voters
    → Requires trust in technical execution

    1. Decision Justification

    This decision is based on:

    Critical role in making Peras + Leios viable in production
    Strong emphasis on testing, safety, and resilience
    Lack of viable alternative providers at this level of expertise
    7. Conditions to Change Vote
    Failure to deliver:
    Peras mainnet readiness
    measurable improvements in finality
    Lack of transparency in:
    milestone reporting
    Missed timelines tied to:
    hard fork coordination
    8. Forward Impact

    If successful:

    Cardano achieves:
    faster finality
    safer scaling
    sustainable node economics

    If unsuccessful:

    Scaling upgrades:
    delayed
    risky
    potentially destabilizing
    9. Stablecoin Utilization
    No explicit treasury hedging strategy
    Full exposure to ADA volatility across 2-year delivery window

    Assessment:

    Weak
    Significant given:
    size of budget
    duration

    Long-duration infrastructure funding should not rely on ADA price stability

    1. End-User Lens
      Transactions finalize faster
      Network is more reliable
      System is less likely to fail under load
      Assessment Summary
      Category: Core Protocol / Resilience Layer
      Strength: Essential for safe scaling
      Weakness: High complexity, large budget
      Risk Level: Medium–High
      Conviction: Positive (with strong oversight requirement)
      Key Distinction (Important)

    This proposal is:

    Safety + resilience for scaling

    Not:

    Growth
    Adoption
    Capital inflow
    Blunt Take
    Without this:
    Scaling upgrades become risky
    With this:
    Scaling becomes safe but expensive

  • Abstain25.3M ₳Rationale

    I am voting ABSTAIN on supporting the Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028 proposal. The amount requested is immense and the team has publicly to resubmit a new proposal which will cover a shorter term.

  • No23.5M ₳Rationale

    Cost is very high and for a long term. Peras needs to be taken to production, but some of the rest could be separate proposals.

  • No21.5M ₳No rationale
  • No21.5M ₳No rationale
  • Abstain21.4M ₳No rationale
  • Yes20.4M ₳No rationale
  • No20.3M ₳No rationale
  • YesChanged19.9M ₳Rationale

    After careful reconsideration and watching on X space of the team explaining themselves https://x.com/tweagio/status/2051657499070062684?s=20, I decided to change my vote to YES.

    TWEAG is a proven good player in our ecosystem and it does make sense to support another strong independent player next to IOG.
    Peras, fast finality is important for Cardano UX itself.
    As I am working in IT myself, I can appreciate the argument they need a longer runway as the covered topics such as Peras and History expiry are highly complex and security relevant and you need to keep the expert staff on, or they will be tasked on other projects, and onboarding new members is always very inefficient with lots of knowledge lost.
    All deliverables are open source and can be publicly tracked.
    Next to Peras, I am really excited about History Expiry which is a great add-on to Leios to cap the growth of required hard disk space for SPOs to help keep up decentralization.
    The other areas covered in this proposal do also make sense to me, and will help strengthen the ecosystem.
    So, overall I change my stance to YES as this proposal is essential overall on second closer look.

    Earlier votes

    No2mo agoSuperseded

    Yes, we need faster finality on Cardano for Midnight. But faster and not in such a bundled proposal over 3 years, this should be either paid for by the Midnight ecosystem which needs this or at least unbundled and reduced to a minimum. This proposal is way too expensive for Peras.

  • Yes17.4M ₳No rationale
  • Abstain17.3M ₳Rationale

    Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028

  • No16.7M ₳Rationale

    We recognize Tweag’s long-term contribution and the importance of the proposed work. However, this is a very large request: ₳39,787,316 / $9,946,829 for 17 work packages across 9 infrastructure areas. At this scale, the proposal needs much stronger budget transparency, modularity, and work-package-level accountability.

    The disclosed $176/hour rate is useful, but accepting it as a treasury baseline would set a risky precedent. A rate at this level requires extremely strong justification: named team, FTE allocation, milestone payment amounts, and concrete acceptance evidence.

    This would be a good case for an RFP/tender experiment before settling on such rates as a standard for core infrastructure work. We are open to a revised version with clearer modularization, stronger price discovery, and more detailed milestone gates, but we cannot support this withdrawal as submitted.

  • Yes14.2M ₳No rationale
  • Yes14.1M ₳No rationale
  • Abstain13.3M ₳Rationale

    RCADA abstains on the Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028 proposal.

    This is not an abstention against Tweag, Peras, History Expiry, conformance testing, network observability, Plutus tooling, or the broader infrastructure direction described in the proposal. On the contrary, RCADA recognises that much of this work is important, technically credible, and highly relevant to Cardano’s long-term resilience, scalability, developer experience, and decentralisation.

    The proposal requests ₳39,787,316 to fund 17 work packages across 9 core infrastructure areas over the 2026–2028 period. These include Peras v1 and v2, History Expiry, Hard Fork Mempool Bridger, conformance testing, adversarial fork testing, Canonical Ledger State and Mithril work, Plutus Script Re-Executor, mutation testing, Hoarding Node work, block cost investigation, and ongoing maintenance of Genesis Sync Accelerator and the Cardano Node Emulator.

    RCADA acknowledges that these work packages are not arbitrary or unrelated. The proposal makes a reasonable technical argument that they form a connected delivery pipeline around Peras, Leios-readiness, testing, observability, node sustainability, and developer tooling. The proposal explicitly states that it is structured as a single delivery pipeline rather than a modular menu, because several of the testing, observability, and audit components support the safe delivery of larger protocol improvements.

    That technical connection matters, and it is one of the reasons RCADA does not vote No.

    However, RCADA also has a responsibility to uphold strong governance standards, especially for treasury withdrawals of this size and duration. A request approaching ₳40 million over two years must meet a very high bar for granularity, reviewability, cost transparency, milestone clarity, and risk partitioning. Even where work packages are technically related, DReps are still being asked to approve a large, multi-year, all-or-nothing funding pipeline in a single governance action.

    RCADA’s concern is therefore not with the importance of the work, but with the structure of the proposal.

    The proposal contains several positive governance features. It identifies Intersect as administrator, refers to a legal contract with Cardano Development Holdings, includes milestone-based delivery and third-party assurance, uses treasury smart contract infrastructure, provides refund conditions for undisbursed or reduced-scope work, discloses prior treasury receipts, and states Net Change Limit compliance. These are meaningful safeguards, and RCADA welcomes them.

    Nevertheless, for a proposal of this scale, RCADA would have preferred clearer per-work-package costing, stronger modularity or phase separation, explicit annual review or renewal gates, sharper prioritisation of critical-path deliverables, and clearer handling of dependencies where final ecosystem value depends on later governance actions, hard fork activation, CIP progression, or adoption by other teams.

    RCADA is particularly mindful that poor proposal structure can cause important and much-needed work to fail on governance grounds, even where the underlying technical case is strong. This is a message not only to Tweag, but to all proposers seeking treasury support: high-quality work deserves high-quality proposals. The more important the work, the more important it is that the proposal gives DReps and the community enough clarity, granularity, and accountability to support it confidently.

    In this case, RCADA is genuinely pained not to vote Yes. The infrastructure direction is valuable, and Tweag’s long-standing involvement in Cardano core development gives the proposal substantial credibility. But RCADA cannot ignore the governance responsibility that comes with approving a large treasury commitment. Supporting important work must not come at the cost of lowering proposal-quality standards, especially when those standards protect the legitimacy and sustainability of Cardano governance itself.

    RCADA therefore abstains as a constructive signal.

    This abstention should not be read as rejection of Tweag, Peras, or the infrastructure roadmap. It is a request for a more granular, risk-partitioned, and reviewable funding structure. RCADA would be more comfortable supporting a revised proposal that preserves the critical infrastructure objectives while offering clearer cost breakdowns, stronger phase gates, and more opportunity for DReps to assess and approve the highest-priority work on its own merits.

    RCADA encourages Tweag and future infrastructure proposers to return with structures that make it easier for DReps to say Yes to important work without compromising governance discipline.

    RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/."

  • No12.1M ₳Rationale

    While long term planning and resource allocation is prudent for any organisation looking to progress immensely, we believe that given Cardano's current state, an annual budget request would be appropriate. Kindly resubmit an annual budget.

  • No10.4M ₳Rationale

    Peras itself is strategically important. The proposal's core promise is faster settlement, with Peras targeting roughly 2 minute finality instead of ~12 minutes today, which matters for exchanges, bridges, partner chains and dApps that need stronger settlement guarantees.

    I still land on NO because, as a Treasury proposal, this is too bundled, too long duration and too hard to evaluate cleanly. It asks for 39.8 million $ADA/$9.95 million USD over 2026-2028 across 17 work packages in 9 areas and explicitly says the portfolio should be treated as one delivery pipeline rather than a modular menu. That is exactly the problem - voters are being forced into one yes/no decision on a mix of very different items - some clearly critical, some much more debatable. If this were just Peras v1 mainnet readiness, I would be much more open to supporting it and voting YES.

    The second issue is budget clarity. The proposal justifies the total primarily through an average rate of $176 an hour for senior Cardano infrastructure engineers and a two year effort horizon. That rate is not outrageous on its own for specialized protocol work. But from the materials here, I still do not get a clean, easy to audit package by- ackage budget showing how much is actually going to:

    For a proposal this large and this broad, I want a much sharper line of sight between the money and the deliverables.

    The third issue is carry over risk from prior funding. Tweag publicly disclosed in April 2026 that its ongoing Cardano delivery suffered a roughly $3.5 million effective funding shortfall because the prior budget had assumed a much higher ADA/USD conversion rate and that a significant portion of the work had to be paused while the most critical roadmap items continued. Their own tracker currently shows some work streams as done but others as on pause or pending final demo. That makes this new proposal look, at least in part, like a catch-up and stabilization proposal for a budget stress problem from the previous cycle, not just a clean forward looking ask. It weakens the investment case for locking in a larger two year contract.

    The fourth issue is overlap with other 2026 asks. The separate Consensus proposal already includes maturing consensus changes through release candidate readiness and specifically mentions conformance testing against formal specifications and integration into the primary node. The Maintenance proposal already covers node bugfixing, infrastructure, monitoring, and testnet maintenance. The Plutus proposal already covers formal verification, conformance and security for smart contract infrastructure. That does not mean Tweag's work is useless - it means Treasury voters are being asked to fund multiple proposals that cluster around the same correctness, readiness and maintenance surface area. The boundaries are not clean enough for a proposal this large.

    Because that is not how it is presented, I vote NO.