$Khale

I am voting NO on “Cardano Critical Integrations V2.” This proposal requests an additional ₳23M only months after the community approved ₳70M for CCI V1, which was described as a performance- and milestone-based budget administered over “up to 24 months.” The proposers have not provided a clear, DRep-facing reconciliation of that original ₳70M: how much is committed, how much has been spent, how much remains, and which Year-2 obligations were explicitly excluded from the original scope. Without that reconciliation, it is not possible to judge whether this second withdrawal is genuinely necessary, or whether we are being asked to pre-fund renewals and integration work that should already have been anticipated within V1.
The additional explanations and governance details provided in this proposal are welcome, but they still do not answer the core questions I must be able to resolve as a DRep. They do not clearly explain why the original CCI V1 budget of ₳70M, defined over “up to 24 months,” does not already cover the relevant maintenance and renewal costs, when the CCI V2 “Year 2” period precisely begins and ends, or how the non-NDA portion of this new budget is allocated between external vendor/licence costs and Cardano-side engineering, infrastructure operations, support, tooling, administration, and Pentad-related work. At the same time, ~90% of the requested amount is bundled into a single “integration and maintenance” line, combining licensing, platform fees, attestor/DVN/oracle operations, Fireblocks integration, and Cardano-side work without a non-vendor-specific breakdown. Confidentiality around individual contracts may be commercially understandable, but using that confidentiality to justify such a large opaque bucket is not acceptable at Treasury scale.
I support Critical Integrations for Cardano, and I recognise that a NO vote here may be unpopular and I accept that. My responsibility as a DRep is to protect the Treasury and approve funding only when the scope, timing, and budget are sufficiently clear to evaluate. Supporting Critical Integrations and requiring clarity are not contradictory positions. I would like to support this proposal, but budget and scope clarity are not optional. In its current form, this governance action leans heavily on the discretion of the Steering Committee and on bi-annual reporting, while asking DReps to approve a very large, bundled request without access to the underlying Statements of Work, pricing logic, or a clear separation between one-off integration work and steady-state Year-2 maintenance.
My conditions for a future YES are straightforward. First, explain why the original CCI V1 proposal does not already cover the relevant costs over its stated 24-month period, with a concrete reconciliation of committed, spent, and remaining funds by category. Second, define the exact 12-month period covered by the CCI V2 “Year 2” budget, including when it starts and ends, and how that aligns with the V1 approval date and partner contract timelines. Third, provide a clearer anonymised breakdown of non-NDA costs, especially separating external vendor/licence costs from Cardano-side engineering, infrastructure operations, support, tooling, administration, and any Pentad-related or contractor work. Until these points are addressed in a way that DReps and the wider community can independently assess, I cannot responsibly vote YES on this treasury withdrawal.

I am voting YES on “Update Plutus Cost Models.” This is a narrowly scoped technical parameter update that enables the new Plutus primitives introduced with the van Rossem hard fork (Protocol Version 11), extends relevant primitives consistently across Plutus V1, V2, and V3, and adjusts some existing primitive cost models based on fresh benchmarking data. Without this action, those new CIPs and capabilities could not be safely and properly used on mainnet, which would unnecessarily limit developer functionality after the hard fork.
For this kind of highly technical change, DReps cannot reasonably verify every individual cost-model coefficient. The key question is whether the process is credible, transparent, and aligned with the guardrails. In this case, the changes have been benchmarked on the reference architecture, recommended by Intersect’s Parameter Committee, confirmed by the Technical Steering Committee, deployed and tested on SanchoNet, Preview, and Preprod testnets, and documented with public benchmarking data and methodology. The update is explicitly framed as consistent with PCM‑01, PCM‑02, and PCM‑03 (benchmark-derived values, updates for new primitives, no negative costs).
There is some risk that a small number of existing Plutus V3 scripts close to their CPU limits may be affected by the increased costs for certain integer operations and equalsByteString, and there is an ongoing discussion about Plutus versioning hygiene under CIP‑35 when adding new built-ins. However, these risks have been openly acknowledged, developers have been given testnet environments and advance notice to adapt, and the change is tightly coupled to enabling core functionality for Protocol Version 11 rather than introducing discretionary behaviour.
My YES should therefore be understood as support for the established benchmarking and governance process for cost-model updates, and for keeping Plutus cost models aligned with protocol upgrades, rather than as a blanket endorsement of every future change of this type. I encourage the technical committees to continue improving versioning discipline and communication around backwards-compatibility, but in this specific case, I believe approving the update is in the best interest of the network and its developers.

I am voting NO on “Eternl: Path to Sustainability (2026–2027)”. I recognise Eternl as one of Cardano’s most important wallets: it has delivered multi‑platform access, deep feature coverage, and the most complete governance UI in the ecosystem, and it already plays a meaningful role in transaction flow, staking, and DRep voting. The team has a strong track record under Catalyst and the 2025 Treasury withdrawal, and the technical scope of this proposal – hard‑fork readiness, CIP implementation, hardware wallet support, multi‑region infra, and governance tooling – is clearly real and non‑trivial.
However, Eternl is a closed‑source, for‑profit product that has already received substantial public funding (roughly ₳1.3M plus 226k USD). This proposal seeks another full year of general operations funding at a time when Eternl is explicitly moving toward a commercial Pro‑plan model. While the FX discipline, reporting commitments, and conditional repayment/donation mechanism are positive, the Treasury is effectively being asked to absorb downside business risk while future upside is partly retained by the company. In my view, repeated broad Treasury support for private products should be contingent on opening key components as true public goods and narrowing the scope to protocol‑critical maintenance work, not general roadmap and commercial expansion.
I would be open to supporting a revised proposal that (1) open‑sources important components funded as public goods, (2) limits the ask to clearly defined maintenance, hard‑fork readiness, CIP and governance‑critical work, with other product features funded via commercial revenue or investment vehicles such as Orion/Draper, and (3) is accompanied by an abstention from Eternl’s own DRep on this item to strengthen governance culture. For this iteration, however, I do not believe it is appropriate for the Treasury to act as a general business backstop for a closed, commercial wallet when other wallets also need space to grow and compete.

I am voting NO on “Scalus: Cardano’s Application Platform for Building, Launching, and Scaling.”
This decision is not a reflection on the quality of the team or the technical merit of Scalus. Lantr has a strong delivery record, prior Catalyst and 2025 Treasury funding have produced tangible outputs, and the proposal is well structured from a constitutional, escrow, and oversight perspective. Scalus also addresses real pain points around application delivery, L2 integration, and sovereign chain access, and I agree that the application layer is a critical next focus for Cardano.
My concerns are primarily about proportionality, adoption, and scope at this point in time.
First, the scale of the ask. Scalus has already received approximately ₳1.08M in community funding across three Catalyst rounds and the 2025 Treasury budget proposal. The current request of ₳8.503M represents roughly eight times all prior funding combined, less than a year after the first Treasury withdrawal was enacted. While the unit cost assumptions for senior engineering and audits are reasonable, I do not believe ecosystem demand and usage have yet reached a level that justifies such a large follow‑on allocation.
Second, the adoption signal remains relatively early. The proposal cites integrations and use by projects such as Hydrozoa, Bifrost, SugarRush, and Vela, and Scalus clearly has technical traction. However, Cardano-wide data still shows that most smart‑contract developers are choosing other languages and toolchains (notably Aiken) as their primary option, and Scalus remains a minority choice today. The proposal’s own targets—five external teams, two production(-like) deployments, and two deeper integrations over the funding period—are modest relative to the size of the request. In my view, Treasury should see stronger evidence of broad, pull‑driven demand before committing to a platform expansion of this magnitude.
Third, the scope is very broad for a single 12‑month proposal. This is effectively four major initiatives bundled together: a smart contract platform, an application runtime, an application‑focused L1 node, and native L2 integrations. While there are synergies in pursuing an integrated stack, this breadth concentrates risk and makes it difficult to assess value per component. It also overlaps with multiple other infrastructure efforts (Amaru, Dingo, Dolos, Yaci, Balius, and potentially Gerolamo), at a time when many in the ecosystem are calling for more emphasis on user growth and application traction rather than additional platform-infrastructure bets.
Fourth, there is non‑trivial dependency and maintenance risk. Some of the most impactful roadmap items—L2 scaling and formal verification—depend on external projects such as Hydrozoa/Gummiworm and Blaster, which are not funded through this proposal. In addition, the proposal already anticipates an increased maintenance footprint in 2027 (2–2.5 FTE) before any diversified funding model is in place. Once Treasury funds a platform of this scope, ongoing maintenance and hard‑fork support become difficult to decline, even if adoption does not grow as expected.
In summary, I view Scalus as a serious, credible project with meaningful technical contributions and a well-governed proposal, but I do not believe this ₳8.5M bundled platform ask is proportionate to its current ecosystem adoption or to the broader Treasury context. I would be more inclined to support a smaller, more focused follow‑on proposal in the ₳1–2M range, aimed at deepening adoption, hardening specific layers, and demonstrating clear usage and impact, with larger expansions considered only after those results are evident.
For these reasons, I am casting a NO vote on this proposal at this time.

I am voting YES on “Cardano Vision 2026: Human Centred, Scalable, Post Quantum Secure – IO Research,” while explicitly recognising the concerns raised about bundling, conversion, and milestone structure.
I acknowledge that this proposal aggregates multiple research agendas—post‑quantum cryptography, Leios/Peras analysis, sharding exploration, ZK/L2 infrastructure, bridge and atomic‑swap security, light‑client and decentralized API design, Babel/intent markets, PoUW, governance incentives, and identity—into a single, large envelope. This bundling reduces the precision with which DReps can prioritise: it is not possible to approve, for example, PQ security and consensus analysis while rejecting lower‑priority or more experimental topics such as PoUW in this funding cycle. I also recognise the research‑to‑deployment conversion concern. IO Research reports more than 250 peer‑reviewed papers historically, of which around 20% have been implemented in Cardano, and CV26 itself is still primarily framed around 38 papers/reports, 8 CPSs, 12 prototypes, and 5 CIPs, rather than direct production delivery. Finally, the tranche design—four equal 25% releases keyed to contract execution, an interim report, a Q3 R&D session, and a final report—are process checkpoints rather than tightly output‑bound payment gates per work package, which several DReps have reasonably highlighted as weak for a programme of this size.
Even with those caveats, I judge the proposal’s content and track record to justify a YES this cycle. CV26 squarely targets long‑term differentiators that are difficult to source elsewhere at comparable depth: adversarial analysis and optimisation of Leios/Peras, MEV and mempool safety in an eUTxO setting, post‑quantum primitives and PQ‑secure Ouroboros, node key security via HSMs and MPC, eUTxO‑native data‑availability and fee‑market design, ZK verification infrastructure and zk‑rollups, a formal foundation for Plutus (state machines and verifying compiler), trust‑minimised light‑client and intent architectures (Cavefish and decentralised indexers), Babel/intent market design and minUTxO redesign, bridge and atomic‑swap protocols, multi‑resource consensus/PoUW, and governance/identity primitives including proof‑of‑personhood and ZK credentials. These are structured with explicit TRL targets and clear “out of scope” boundaries for implementation, and they build directly on a CV25 year that exceeded its research and validation targets and handed several concrete artefacts (e.g. Leios CIP, Phalanx, RSnarks, Cavefish) to engineering. The consortium—IO Research plus leading universities such as Edinburgh, Oxford, IST Tokyo, Buenos Aires, Sydney, and Berkeley, along with applied partners like Eryx—is, in my view, uniquely positioned to deliver this category of work for Cardano.
I also consider the governance and custody structure to be appropriate for a Tier‑2c research programme at this scale. Funds are held in Intersect‑administered treasury reserve and project‑specific smart contracts developed by Sundae Labs and audited by TxPipe and MLabs, with multi‑party controls over fund movements, delegation to auto‑abstain, third‑party assurance of milestones, and an obligation to return undisbursed funds at the end of the delivery period. The proposal includes a clear reporting cadence—public R&D sessions, a mid‑year interim report, and a year‑end final report with financial breakdown—which, together with CV25’s published reports, gives the community a reasonable basis to track progress and judge research‑to‑deployment conversion over time.
That said, my support comes with expectations for future cycles. For any follow‑on “Cardano Vision 20xx” programmes, I will look for: (1) tighter bundling or modularisation so that high‑priority research lines (e.g. PQ security, consensus robustness) can be evaluated and funded independently of lower‑priority or more speculative work; (2) stronger evidence that prior cycles’ outputs—CV25 and CV26—are translating into deployed capabilities, CIPs, and measurable network outcomes, not just additional publications; and (3) more granular, output‑based milestone and disbursement structures for large research envelopes, rather than only broad reporting checkpoints. I am voting YES on CV26 because I believe maintaining Cardano’s research foundation and this particular research network is strategically important at this stage, but future renewals should expect a higher bar on prioritisation, conversion, and milestone discipline.

I am voting NO on the “Cardano dOSPO and OMF Program.” I agree that Cardano needs a more robust and sustainable approach to open-source maintenance, and I support the goal of a decentralised OSPO and Open Maintenance Fund. However, this proposal requests a large, multi‑year budget (on the order of 12M ADA over several years) for a still-early organisational structure, at a time when the 350M ADA Net Change Limit is already under pressure from multiple other high‑priority proposals. In the context of this year’s portfolio, I do not consider it prudent to allocate such a significant share of Treasury capacity to a long‑horizon programme that has not yet demonstrated outcomes at this scale under its proposed framework.
Compared with other 2026 proposals I have reviewed, this programme is less mature in terms of demonstrated delivery and phasing. The plan relies heavily on establishing new governance bodies, processes, and funding mechanisms, but offers relatively few concrete, near‑term milestones with measurable impact in the first 12–18 months, and limited evidence of prior results under the same structure. By contrast, I have already voted NO on other large proposals that had live mainnet usage and clearer KPIs, on the grounds of budget clarity, phasing, and Treasury risk. Maintaining a YES for a multi‑year dOSPO/OMF programme with a similar or larger cost profile, but less proven delivery, would be inconsistent with the standards I have applied elsewhere.
For a future proposal, I would look for a more phased approach: a smaller, tightly scoped initial Treasury allocation focused on a limited set of high‑impact maintenance targets, with clear 12–18 month milestones, public reporting, and an explicit review point before any multi‑year expansion. I would also expect clearer articulation of how this programme interacts with existing IO, Intersect, and community maintenance efforts to avoid overlap and double funding. Until those conditions are met, I cannot responsibly support this multi‑year Treasury withdrawal.

I am voting YES on “The first node in the browser; a Cardano USP.”
This proposal funds Gerolamo, a TypeScript implementation of a Cardano node scoped to a production‑ready browser‑extension light node that dApps and wallets can use for local, trust‑minimized validation instead of relying entirely on centralized RPC/indexer infrastructure. It directly advances the Cardano 2030 KPI for alternative full node clients and the “Security & Resilience → Client Diversity” objective by adding an independently developed client in a different runtime and footprint (browser/TypeScript) than the existing Haskell and Rust implementations.
The scope and budget are focused and reasonable for core infrastructure. The ask is 4,600,000 ADA (~USD 1.15M at 0.25), representing 5 FTE at USD 200k/year plus a 15% contingency. The rate is clearly defined as a company‑level rate that includes taxes, non‑developer staff, compliance, legal, and an independent financial audit, not just salaries. The work is strictly limited to the browser light‑node use case: full block production, SPO infrastructure, and server‑side relay roles are explicitly out of scope for this funding period, which keeps the mandate narrow and avoids overlapping with Amaru and other server‑side clients.
Deliverables and milestones are objective and user‑relevant. Over 12 months (Q2 2026–Q1 2027), the plan is to:
Implement full ledger rules and Praos chain selection in a browser‑compatible way, with state stored in IndexedDB and correct rollback handling.
Release a public browser extension (e.g., via Chrome Web Store) exposing a messaging API for basic and indexed queries (tip, UTxO by output reference, UTxOs by address/asset, plus transaction submission), along with a demo dApp that demonstrates these flows against a public testnet without any backend.
Achieve stability criteria: syncing from genesis to tip, maintaining ≥15 peers for extended periods, correct behaviour across rollbacks, and working in at least one non‑Chromium browser (e.g., Firefox or Safari).
Acceptance criteria are tied to tagged releases, sync logs, store listings, tests, screencasts, and public documentation, not self‑reported status, and production‑readiness is defined in terms of sync reliability, performance, peer connectivity, and rollback safety.
Governance, custody, and oversight are strong. Funds are held in SundaeLabs’ treasury.ak/vendor.ak contracts, audited and in production, with milestone‑based disbursement gated by an independent oversight board (TxPipe, Aiken/Midnight, BlinkLabs/Dingo) that can co‑sign releases, pause milestones, and help sweep unused funds back to the Treasury. The proposal includes an independent financial audit of fund flows (quarterly plus final), monthly public updates, quarterly detailed reports (technical and financial), and a transaction journal logging every on‑chain action tied to this GA. All escrowed ADA is delegated to the always‑abstain DRep and cannot be staked with SPOs; any remaining funds after expiry are automatically swept back to the Treasury at the contract level. The proposers also reference a 2025 retrospective on prior funding and delivery, which is important for continuity and accountability.
I acknowledge the concerns raised by some DReps about execution risk, demand visibility, and the number of concurrent node efforts. A fully validating browser node is technically challenging, and adoption by wallets and dApps will need to be earned over time. However, this proposal is one‑year, tightly scoped, and heavily milestone‑gated, with independent technical and financial oversight. It does not seek to fund another general‑purpose full node; it targets a unique niche that Cardano’s eUTxO design makes realistic: on‑device, browser‑based validation for dApps and light wallets. In my view, that is the kind of foundational, decentralization‑oriented infrastructure the treasury should support, especially when the ask is moderate and the accountability structure is strong.
For these reasons, I am comfortable voting YES on this proposal.

I am voting NO on “Cardano at TOKEN2049 Singapore 2026 – Top‑Up ‘Title’ Sponsorship Upgrade” at 1,768,167 ADA.

This proposal is procedurally sound and transparently structured: it is explicitly contingent on the Platinum baseline passing, uses Intersect’s audited TRSC/PSSC framework with auto‑abstain delegation and multi‑sig oversight, and clearly itemises what the extra spend buys—larger booth footprint (144 sqm vs 108 sqm), a 15‑minute mainstage keynote, lanyard and “protein shake station” branding, press‑release inclusion, facilitated media introductions, and slightly higher KPI targets for leads, collaborations, media coverage, and wallet sign‑ups. Those elements would increase Cardano’s visibility at TOKEN2049 and are aligned with Pillars 2 and 4 of the 2030 strategy.

However, I do not see a proportionate incremental return that justifies an additional ~424,000 USD of treasury spend on top of an already large Platinum sponsorship. The upgrade leaves the fundamental nature of the spend unchanged: this remains a short, marketing‑heavy activation at a two‑day crypto conference, aimed primarily at an audience already deep in the industry. The incremental KPI uplift—an extra 30% booth contacts, six more collaborations, 60 additional wallet sign‑ups, modest increases in media coverage—does not convincingly support the cost, especially given the lack of strong evidence that previous TOKEN2049 or EMURGO‑run events have led to durable on‑chain adoption or enterprise deployments commensurate with their price. In the same Net Change Limit window the treasury is already funding large, foundational initiatives (Leios, protocol upgrades, Orion Fund), and multiple DReps have raised credible concerns about turning high‑end sponsorships into recurring, high‑ticket expenditures when measured ROI remains weak. Given these opportunity costs, and my existing NO position on the Platinum baseline, I cannot support allocating an additional 1.77M ADA simply to further upgrade Cardano’s prominence and branding at TOKEN2049.

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.

I am voting YES on “Pebble & Ecosystem maintenance: TypeScript core of Cardano.” This proposal combines clearly justified TypeScript tooling maintenance with a strategic, but in my view acceptable, investment into Pebble as a TS‑shaped smart‑contract language. The total ask is mid‑sized relative to other 2026 infrastructure packages and uses the now‑standard SundaeLabs treasury contracts with independent oversight, milestone‑based disbursement, and refunds of undisbursed funds, which meets my governance and accountability expectations.
On the maintenance side, the value is straightforward. Many widely used ecosystem tools—including Mesh, Lucid Evolution, Midgard, and other SDKs—depend directly or indirectly on HLabs’ TypeScript stack (cardano‑ledger‑ts, ouroboros‑miniprotocols‑ts, plutus‑machine, uplc). If these libraries lag protocol changes such as Plutus V4 and new parameter sets, a large part of the developer ecosystem is at risk of breakage. Funding a dedicated team to keep this stack aligned with upcoming hard forks is a clear public good and, in my view, an appropriate use of treasury funds.
Pebble is the higher‑risk component, and I acknowledge the concerns raised by some DReps: Aiken is already working well, Pebble’s near‑term adoption targets are modest, and the main barriers to Cardano adoption are not solely about language syntax. However, I believe there is a strong strategic case for having a production‑grade, TS‑shaped language that compiles to optimized UPLC, with a full type system, Plutus V4 support, and modern tooling (LSP, CLI, sourcemaps). TypeScript is one of the most widely used languages globally, and giving those developers a familiar path to write on‑chain logic on Cardano is, in my view, a reasonable bet to broaden the long‑term developer funnel, especially when paired with the existing Aiken and Plutus options.
I agree that HLabs should, over time, provide a clearer retrospective on prior Catalyst funding related to plu‑ts and Pebble, and I expect them to report not just code delivery but real usage metrics for Pebble and the maintained TS stack. Nonetheless, given the strong public‑goods case for the TS maintenance track, the credible technical scope for Pebble, the modest size of the combined ask relative to other infra proposals, and the robust treasury‑governance structure, I judge that the likely long‑term benefits to Cardano’s TypeScript ecosystem justify a YES vote.

I am voting NO on “Cardano at TOKEN2049 Singapore 2026 – Baseline ‘Platinum’ Sponsorship” at 3,303,750 ADA.

This revised proposal is an improvement over the earlier Summit+Title package: the scope has been narrowed to TOKEN2049 only, the budget is smaller, and the structure is more clearly builder‑centric. Cardano would receive a high‑visibility booth, a dedicated builder sub‑stage, 30 builder tickets, branded Wi‑Fi, welcome‑bag inserts, lead‑scanning, and broad exposure across TOKEN2049’s app, website, and signage, with solid constitutional compliance via Intersect’s Sundae Labs treasury contracts, multi‑sig oversight, milestones, and clear refund conditions. EMURGO’s local presence and multi‑year relationship with TOKEN2049 also reduce execution risk, and the KPIs (1,950 contacts, 20 collaborations, 13 expert slots, 200 wallet sign‑ups, 200 academy subscribers, 20 media pieces, plus explicit post‑event on‑chain tracking) are more concrete than in past event proposals.

However, even with these positives, I do not find the funding proportionality or expected ROI compelling enough to justify nearly 800,000 USD of treasury spend for a two‑day, marketing‑heavy activation. The budget allocates 399,900 USD to the sponsorship fee, 250,000 USD to “Booth Build and Logistics”, and 97,485 USD (15%) to “Management, Logistics & Community Support”. Several DReps have convincingly argued that these levels are out of line with reasonable event costs and represent weak value for money when compared with the projected KPIs, especially in a bear‑market context where other ecosystems have spent large amounts on sponsorships without seeing durable gains in usage or market position. At the same time, the treasury in this Net Change Limit window is already supporting foundational work on consensus (Leios), protocol upgrades, and the Orion Fund—initiatives that are far closer to non‑substitutable infrastructure or clearly levered growth capital than another conference booth. Given the opportunity cost and the lack of strong evidence that prior EMURGO‑led activations have produced lasting on‑chain outcomes commensurate with their cost, I believe these funds are better reserved for core protocol work, product‑driven ecosystem growth, and more cost‑effective builder support rather than this Platinum sponsorship.

I am voting YES on “[OriLife × TonFarm] Identifying 180 Million Durians Without Physical Labels.”
This proposal is a rare combination of real‑world urgency, technical maturity, modest treasury exposure, and strong governance safeguards.

Real regulatory demand in a large market
Vietnam’s durian exports to China exceed USD 3.3B/year, with China accounting for over 90% of export value. The 2025 scandal (17 people prosecuted, plantation codes revoked, thousands of containers delayed) showed how easily peelable QR labels can be reused to disguise unregistered or contaminated fruit.
Circular 11/2026/TT‑BCT now legally requires food production establishments to connect to a national Traceability System and provide records from 1 December 2026, with sanctions for non‑compliance.
Existing traceability deployments (e.g., TE‑FOOD) have operated at scale in Vietnam but remain label‑based and therefore vulnerable to exactly the fraud that triggered the scandal.
OriLife responds to this with a label‑free, legally driven model:
Adoption is driven by farm‑level legal obligation, not voluntary enterprise subscriptions.
Bio‑ID uses the fruit’s skin texture as the identifier, so there is no label to peel and reattach; the fraud vector is closed at its source.
This is precisely the kind of high‑stakes, non‑discretionary real‑world use case I want Cardano to be involved in.

Proven team and technical maturity
The Alliance has already done the hard learning:
In 2024, TonFarm deployed QR‑based traceability on TON across multiple farms in Đắk Lắk, manually attaching labels and hashing each fruit individually on‑chain, only to see that model fail on detachable labels, centralized mutable databases, and linear per‑fruit costs.
From that, they built durable assets: two harvest seasons of UX with older farmers, institutional trust across 46 communes, standardized onboarding, offline queue logic, and a formally registered copyright for the ongoing work.
The current stack is already live or prototyped:
Bio‑ID demo at orilife.io shows the fruit‑fingerprinting working on real images.
VeData batching has been tested on Cardano preprod, committing batched fruit state changes in a single eUTxO transaction.
LampNet and PhoenixKey prototypes are online, with open‑source code available.
The three companies cover field operations, R&D/IP, and product/UX, and have already self‑invested roughly USD 500k before this governance action. That’s a credible base to build from.

Scope, cost, and Cardano fit
The ask is 2,400,000 ADA, anchored at USD 0.25/ADA (~USD 600k).
Targets at full scale (M7):
12,000 ha, ~12,000 farm households, 24,000 PhoenixKey DIDs, ~1.2M trees, and ~180M fruits per season.
Around 1.0–1.2M on‑chain events per year, primarily VeData anchors and setup; commercial escrow and labor‑contract modules are optional, used where their dispute‑resolution value justifies the fee.
Approximately 75,000 ADA permanently locked at M4 in farm NFTs, wallets, and escrow contracts.
Technically, the design makes good use of Cardano:
VeData uses eUTxO + sparse Merkle trees to batch up to ~15,000 fruit updates into a single transaction, bringing per‑fruit cost down to ~USD 0.000009 at ADA 0.25—roughly 19,000× cheaper than the previous one‑tx‑per‑fruit model on TON (~USD 0.17/fruit).
LampNet applies a five‑layer validation pipeline (device, image authenticity, GPS bounds, timestamp, biological plausibility) before any data hits Cardano, and Hydra heads further optimize decommit throughput.
PhoenixKey builds on Cardano’s W3C DID stack, and Midnight is planned for ZK proofs and view keys; if Midnight is delayed, trade‑secret fields remain off‑chain while consumer‑facing data stays on L1.
This is a textbook example of Cardano’s primitives being used for what they were designed to do: high‑integrity, cost‑predictable state commitments and standards‑aligned identity.

Governance, ADA‑price handling, and treasury protection
The governance and risk controls are unusually strong:
Funds are held in Intersect‑managed escrow contracts, with per‑milestone releases only on 2‑of‑3 IOB signatures.
The initial M0 advance (360k ADA) can be clawed back if M1 is not submitted within 90 days; a missing 30‑day spending report freezes subsequent milestones.
Overdue milestones automatically return ADA to the Treasury; project termination triggers a sweep of all remaining ADA back within 14 days.
ADA‑price risk is explicitly handled:
At or above 0.25: full planned scope executes.
Below 0.25: the Alliance commits to self‑funding the shortfall rather than shrinking scope.
Above 0.30: surplus first reimburses prior self‑funding, then goes to contingency or ecosystem reinvestment.
This gives the treasury protection against both downside and unearned windfalls and ensures scope is not quietly cut if the price moves against the proposers.

Responding to ROI and “fit” objections
I’ve read the NO rationales carefully (YUTA, EMURGO, Socious, TriangleForces, Army of Spies). I agree this is not a “pure financial ROI” proposal:
The direct fee stream to L1 (~28–29k ADA/year at scale) is modest relative to the ask, and the MAGIC economy is a relatively closed loop.
Farmers and exporters, under legal pressure, may be able to fund similar infra commercially without treasury involvement.
Where I differ is in how I interpret the treasury’s role and the returns here:
For a ~2.4M ADA risk, Cardano gets a credible chance at being the backbone for a legally mandated traceability system in a USD 3B+ export sector, plus locked ADA, tens of thousands of DID‑backed users, and a high‑quality reference deployment.
The ongoing costs are not treasury‑subsidized; users pay on‑chain fees in MAGIC credits denominated in VND, and the system is designed to be economically competitive with existing label and RFID solutions.
The proposal is one of the most thoughtful I’ve seen in terms of price hedging, clawbacks, and milestone‑based disbursement, which substantially limits treasury risk.
Given the scale of the problem, the regulatory pull, and the modest size and structure of this ask, I judge this to be a reasonable, bounded risk to take in order to showcase Cardano in exactly the kind of real‑world, legally enforced supply‑chain context the ecosystem needs.
For these reasons, I am comfortable voting YES on this proposal.

I am voting NO on “Revised Cardano Summit 2026 Singapore.”
This revised proposal is substantively better than the original. The Foundation listened to community feedback, cut the budget by 22%, decoupled the Summit from EMURGO’s TOKEN2049 sponsorship, increased its own internal contribution from USD 250k to USD 380k, and shifted to a leaner two‑stage format with clearer KPIs and revenue targets. The custody model through audited Sundae Labs treasury contracts, the milestone structure, the public dashboard, and the annual Grant Thornton audit—all of which also cover this withdrawal—provide strong accountability and transparency. I also accept the argument that, at this scale and in this context, only a well‑structured founding entity currently has the operational capacity to run a credible global flagship event without risking reputational damage to Cardano.
On proposal quality, governance, and responsiveness, this Summit request is above average and the YES votes make valid points about its potential long‑term value and the importance of having a controlled Cardano platform adjacent to TOKEN2049 in Singapore. However, my decision is driven by treasury fit and priority. The ask remains large at ₳7,800,000, and the benefits—enterprise MQLs, meetings, media coverage, and developer engagement—are inherently indirect and hard to tie cleanly to durable on‑chain adoption. The Cardano Foundation is still well capitalized and successfully self‑funded Summits from 2022–2024; Summit 2025 was the first treasury‑funded flagship, and moving immediately to a second edition paid from the treasury risks normalizing this as a recurring line item rather than a last‑resort or transitional mechanism. In the same NCL window I am already supporting multiple multi‑million‑ADA proposals for protocol upgrades, high‑assurance tooling, developer experience, and L2 scalability—work that produces direct, durable improvements to Cardano’s technical capacity and security for all builders. Given finite treasury resources, I judge those investments to be a higher‑leverage use of public funds this epoch than a flagship event, even a well‑designed one in a strategically attractive location.
For these reasons, I will vote NO on this proposal in its current form. This is not a rejection of the idea of a 2026 Summit in Singapore, nor a criticism of the Foundation’s ability to execute; it is a statement about what I believe the treasury should prioritize now. I would be more inclined to support future Summit proposals if they (1) come through the main budget process with sufficient lead time, (2) present a clear, quantified path toward Summit self‑sustainability and reduced treasury reliance, (3) include explicit conflict‑of‑interest mitigations (such as founding‑entity DReps abstaining on their own large withdrawals), and (4) report in detail on how previous Summits converted KPIs like MQLs and meetings into concrete, on‑chain adoption.

I am voting YES on “IO & VacuumLabs – Enhancing Plutus: Performance, Correctness, and Usability.”
This proposal is a focused, technically strong package that tackles three long‑standing bottlenecks in Cardano’s smart contract stack: execution cost and expressiveness, formal correctness for a world with multiple node implementations, and practical developer experience. It delivers concrete artifacts on a clear roadmap: new built‑ins like CIP‑0156 multiIndexArray and CIP‑0168 BuiltinValue functions plus casing on Data to reduce script size and execution units; a scoped investigation of removing the scope check and a CIP on laziness/memoization in UPLC; a property‑based conformance framework and expanded Agda metatheory for Plutus primitives; systematic audits of evaluator and costing code; and a new Plinth compiler backend that works with multiple GHC versions, ships binaries for major platforms, drops Nix/native‑library friction, and surfaces clearer source‑level errors.
These deliverables map directly to Cardano’s 2030 KPIs and pillars. Cheaper, more expressive scripts and better tooling enable richer DeFi and on‑chain applications and higher transaction volumes; stronger formal specifications and conformance testing reduce the risk of subtle consensus bugs as alternative node implementations emerge; and a simpler Plutus toolchain lowers the drop‑off rate for new developers, which is critical for MAU and ecosystem growth. The budget is mid‑sized relative to other 2026 asks, heavily weighted toward engineering and formal‑methods work across IO and VacuumLabs, with specific milestones, code, CIPs, tests, and documentation attached to each line item.
I share some of the concerns voiced by other DReps about IO’s large cumulative treasury allocation and the need for more fine‑grained cost modeling and prior‑results reporting in future core‑protocol proposals. However, in this case the internal structure, technical scope, and expected impact are strong enough that, on balance, I consider this a justified investment in Cardano’s smart contract foundations, and I will support it with a YES vote.

I am voting YES on “IO: Cardano High Assurance Technical Collaboration.”
This proposal extends already‑proven formal verification work on Cardano (Blaster on real production contracts such as stablecoin and DeFi protocols) into a full DApp‑level toolkit, with clear, testable deliverables across UPLC equivalence checking, DApp‑wide proofs, a Common Vulnerability Library, multi‑language integrations, and a container‑based development environment (CBDE). It is one of the few proposals that directly strengthens Cardano’s long‑term differentiator—high assurance smart contracts—at a time when AI‑assisted attacks and complex DeFi systems increase the cost of getting security wrong.
The budget is mid‑sized relative to other 2026 technical proposals and is heavily weighted toward engineering work by multiple ecosystem teams, not overhead. I share other DReps’ concerns about IO’s large cumulative treasury allocation and the lack of FTE‑level cost breakdowns per partner, and I expect any future high‑assurance or Blaster‑related funding requests to provide more granular financial transparency and clearer ex‑post reporting before I would support another tranche at this scale. However, on balance, I consider this a justified, one‑time investment in shared high‑assurance infrastructure: even a single major exploit prevented over the coming years would likely exceed the value of this ask, and the resulting tooling will be available to all Cardano developers, not just its authors.

I am voting NO on “IO & Ensurable Systems: Cardano Maintenance Initiative” at the requested 62,134,630 ADA. I fully agree that core maintenance is non‑discretionary and that IO’s expertise has been central to Cardano’s stability and upgradeability to date. The governance and custody setup via Intersect’s treasury contracts, Oversight Committee controls, auto‑abstain delegation, and refund conditions is also robust and aligned with constitutional best practice. My objection is not to funding essential maintenance itself, but to the way this proposal bundles many different activities into a single, very large “maintenance” envelope without sufficient cost transparency or scope discipline.

In its current form, the proposal conflates true, safety‑critical maintenance (uptime, DR, incident response) with a broad set of improvements and support functions: Cardano Blueprint documentation, open‑source community support, code modernization and technical‑debt work, performance analysis, and QA/release work that should be scoped and costed as part of specific feature or node deliverables. Many of these are valuable, but they are not all non‑optional “keep the lights on” tasks, and the proposal does not provide the granular FTE rates, team sizing, or per‑component cost breakdown needed to judge whether 62M ADA is reasonable. For a single vendor, in a treasury that has already committed to other large initiatives, this size and level of bundling is not something I can support.

For a future maintenance proposal, I would be prepared to reconsider a smaller, better‑structured request that:
(1) clearly modularizes the scope into separate governance actions—for example, a narrowly defined core maintenance contract for node uptime/DR/incident response, and distinct, smaller proposals for documentation (Blueprint), performance improvements, open‑source support, and ecosystem engagement;
(2) adopts a tighter definition of “maintenance”, reserving that label and budget for truly non‑discretionary operational work, while treating modernization, technical debt, and documentation as explicit upgrades or improvements with their own scope and evaluation criteria; and
(3) provides a transparent, benchmarkable cost model (FTE bands, roles, and per‑workstream allocations), so DReps can compare core Haskell node maintenance costs against alternative node teams and industry norms, and see exactly how much is being requested for Blueprint, tooling, and other “extras”.

I am voting YES on “IO Consensus Initiative (Leios)” at 27,714,342 ADA, with explicit reservations about cost transparency and IO’s aggregate draw on the treasury.

Leios is a must‑have consensus upgrade if Cardano is serious about its own 2030 plan (27M monthly transactions, materially higher fee revenue, and credible performance versus rival L1s). The current cycle already funds an early public testnet and feature‑complete prototype; this proposal pays for the hard part: taking Leios from prototype (SRL 4) to a mainnet‑ready release candidate (SRL 5–8), validating it under load and adversarial conditions, and doing everything within IO’s control to enable a Dijkstra‑era hard fork. Without that base‑layer scaling, most other adoption and revenue targets become aspirational marketing rather than realistic outcomes.

From a governance and constitutional perspective, the proposal is well structured. Funds are denominated purely in ADA, sit within the 350M Net Change Limit window, and are administered through Intersect’s Treasury Reserve Smart Contract plus project‑specific contracts, using audited Sundae Labs infrastructure, auto‑abstain delegation, multi‑sig controls with an independent Oversight Committee, milestone‑based disbursement, and a commitment to return undisbursed funds at the end of the period. Scope is clear: Q4 2026 release candidate, Q1 2027 high‑confidence validation, and Q4 2026–Q1 2027 hard‑fork enabling activities, with explicit acknowledgement that mainnet activation depends on external governance and ecosystem readiness and therefore cannot be guaranteed in this governance action.

I share several of the concerns raised by other DReps. First, cost transparency is weaker than it should be at this scale: 27.7M ADA (~6.65M USD) is heavily weighted to development (86%), which is appropriate for consensus work, but the proposal does not provide FTE rates, team sizes, or per‑workstream allocation that would let DReps benchmark IO’s efficiency against industry norms or alternative implementations. This is part of a broader pattern of IO submitting large technical asks outside the main Intersect budget cycle, after already having been allocated ~130.7M ADA across prior treasury‑funded workstreams, with ~78.46M ADA withdrawn so far. Second, Leios introduces non‑trivial downstream obligations and risks for SPOs and alternative clients: higher operational complexity, traffic prioritization requirements, and the need for Amaru, Dingo, and others to implement and maintain compatibility. The proposal acknowledges parameter and integration risk and the possibility that smaller pools could be squeezed, but the trade‑offs on SPO economics are not quantified.

Despite these negatives, this proposal is far closer to core, non‑substitutable infrastructure than most other large asks in this cycle. As DReps like YUTA, CardanoYoda and Dr. Navjit have argued, Cardano can delay or down‑scale many marketing, L2, or ancillary initiatives, but it cannot credibly pursue its 2030 adoption and revenue targets without a base layer that can actually carry that load. The downside of not funding this stage of Leios—remaining a structurally low‑throughput L1 in a market that increasingly assumes “high TPS by default”—is, in my view, greater than the discomfort of funding a relatively expensive, high‑risk engineering program.

For these reasons, my position is:

Vote: YES, treating this as a one‑off, foundational consensus upgrade that should go ahead, even given IO’s imperfect cost transparency and treasury footprint.

Conditions going forward: I expect IO to (1) provide more granular, benchmarkable budgeting (FTE bands, team sizes, per‑workstream splits) in any future Leios‑related asks or follow‑ons, (2) articulate a clear plan for how Leios costs and responsibilities are shared with alternative clients over time, and (3) keep DReps informed on parameter choices and SPO impact, so the ecosystem can make informed decisions when the actual hard‑fork governance action arrives.

If those expectations are not met, my tolerance for additional large, out‑of‑cycle IO treasury withdrawals will be significantly lower, even for technically important work.

I am voting YES on “IO: Cardano Upgrades” at 13,103,039 ADA, because it funds three tightly scoped protocol‑level improvements that directly target long‑standing economic and UX limitations on Cardano. CIP‑159 account address enhancements unlock true micro‑fees, cheaper batchers, and better L2 reserve patterns; CPS‑23 multi‑asset Treasury design is a necessary first step toward holding stablecoins and other native assets in the Treasury, improving long‑term financial resilience; and Babel Fees builds on CIP‑118 to let users pay transaction fees in native assets like USDC or bridged BTC, removing the “buy ADA first” barrier that has hurt onboarding. These workstreams are well‑timed with the Dijkstra/Euler eras and the arrival of BTC bridges and USDC, and they align closely with 2030 KPIs for TVL, transactions, MAU, protocol revenue, and Pillar 5’s focus on financial stewardship.

At the same time, I share several concerns raised by other DReps. IO and affiliates have already been allocated around 130.7M ADA via prior treasury actions, with ~78.46M ADA withdrawn, and this proposal sits alongside larger IO asks for Leios and maintenance in the same Net Change Limit window. While this ask is smaller and its scope is much cleaner than the maintenance bundle, the budget detail is still weaker than I would like: we see per‑workstream amounts (≈7.07M ADA for CIP‑159, 2.36M for CPS‑23, 3.68M for Babel Fees) but no FTE rates, team sizes, or cost per role, despite smaller teams routinely providing that level of breakdown. I therefore treat this as a conditional YES: I support these specific upgrades because they address critical gaps and are well‑structured and time‑bound, but I expect any follow‑on funding in these areas to come with (1) clear delivery on the milestones promised here, (2) demonstrable adoption and impact, and (3) more granular, benchmarkable budgets so that IO can be evaluated to the same standard as other ecosystem teams.

I am voting YES on “IO: Developer Experience Initiative” at 3,601,926 ADA. This is a focused, six‑month program aimed squarely at one of Cardano’s clearest bottlenecks: developer onboarding and retention. The proposal funds concrete deliverables—a stack‑agnostic “cardano‑init” starter CLI, an OpenZeppelin‑style contracts library with at least five ready‑to‑audit smart contracts, a unified Developer Portal “hub” optimized for key personas, a targeted bounty program for existing tooling, and a measurement‑oriented hackathon—all driven by prior survey data from 109 Cardano builders and the Cardano Foundation’s developer ecosystem findings. These outputs directly support a 20–30% uplift in developer onboarding and a ≥30% improvement in relative developer growth rate, which should translate into more DApps, higher MAU, and more transactions over time, aligning closely with Pillar 2 (Adoption & Utility) and Pillar 4 (Community & Ecosystem Growth) in the Cardano 2030 strategy.
The scope is well bounded and the budget is proportionate for the work: roughly 81% of the 3.6M ADA request goes to development and engineering, with the remainder covering ecosystem support, bounties, the measurement hackathon, and standard audit/oversight costs. Governance and constitutional compliance are strong—the withdrawal is denominated in ADA, sits within the 350M NCL, and is administered via Intersect’s audited TRSC/PSSC framework with auto‑abstain delegation, multi‑sig oversight, third‑party assurance, and a commitment to return unspent funds. Compared to many larger, less targeted proposals this epoch, this initiative offers a clear link between cost and ecosystem utility. My support comes with the expectation that IO keeps the work collaborative and upstream‑oriented (so it strengthens, rather than replaces, existing community tools) and that it publishes concrete DevX metrics—such as time‑to‑MVP, NPS, and adoption of the CLI, contracts library, and Developer Portal flows—so that any future DevX‑related asks can be evaluated against demonstrable impact.

I am voting NO on “Pogun – Capital Without Compromise” at 12,290,000 ADA.
Even acknowledging the technical sophistication, phased milestones, and the attempt to treat the treasury as an investor, this is still a single, vertically integrated commercial venture—bridge, credit protocol, and yield/RWA product—asking for 12.29M ADA with equity‑like risk but without equity‑like rights or protections. The treasury would be exposed to complex execution, legal, and market risk across multiple layers while relying mainly on a soft EBITDA‑based revenue share and quarterly reports, with no clear governance stake, no treatment of related‑party costs, and no hard safeguards around restructuring, spin‑outs, or M&A. That is not, in my view, an appropriate structure for public capital, especially when more neutral ways to support Bitcoin DeFi are available.
In addition to concerns raised by other DReps, I see four further issues. First, the overall positioning feels more like an extraction layer on top of Cardano than a neutral, ecosystem‑first platform, with a private venture capturing bridge/credit/yield fees while public funds underwrite early risk. Second, the yield layer introduces opaque governance and fiduciary risk: there is no clear description of who controls strategy selection and risk, what qualifications they have, or what guardrails protect depositors and underwriters if RWA/private‑credit exposures go wrong. Third, the proposal does not spell out concrete legal fallbacks and client protections across jurisdictions, defaults, and potential changes in corporate structure, which is material for cross‑chain, institutional products. Finally, the design overlaps heavily with work already being pursued by existing ecosystem teams on BTC‑backed lending and bridging; funding a large, IO‑aligned, vertically integrated competitor from the treasury risks crowding out established developers and fragmenting limited demand. Taken together, I do not believe allocating 12.29M ADA to this structure is prudent in this cycle, so my vote is NO.

I am voting NO on “Blockfrost – Maintenance and Next Generation Indexing” in its current, bundled form.
This is not a rejection of the problem space or of Project Cayley. I see decentralized, scalable data infrastructure as strategically important for Cardano, especially as Leios increases throughput and full‑chain indexing becomes uneconomic for smaller operators. Cayley’s sliced indexing and multi‑chain data layer are directionally strong and align with Cardano’s 2030 infrastructure and scalability goals.
My objections are to how this proposal is structured and financed, not to the underlying architecture.

1. Bundling infra build and operational subsidy
   The proposal combines two very different asks into a single vote:
   a one‑off infrastructure build (Project Cayley), and
   an ongoing operational subsidy for Blockfrost’s existing free‑tier service.
   This “all‑or‑nothing” structure prevents governance from approving Cayley on its own merits while independently deciding whether subsidizing Blockfrost’s operations is appropriate. At this scale, I consider that a process defect.
2. Exclusive subsidy for a commercial freemium service
   Blockfrost operates a commercial freemium model; the free tier is a path into paid plans. The proposal asks the treasury to underwrite a substantial portion of those free‑tier costs without:

• a monetization/repayment or revenue‑sharing mechanism back to the treasury,
• a clear taper or sunset for subsidy, or
• commitments that upside from cross‑ecosystem expansion (e.g., Bitcoin) will flow back to Cardano.

IO and affiliates already hold ₳130.7M in allocations, including prior Blockfrost funding (₳1.1375M, 88% drawn). Other private teams have been pushed toward loan‑like or revenue‑sharing models. Extending a large, pure OPEX subsidy here, with no reciprocal mechanism, sets a precedent I do not support.
3. Competition, centralization, and evidentiary standards
While I agree that data‑access services tend to centralize and that Cayley’s design is decentralization‑oriented, the immediate effect of subsidizing Blockfrost’s free tier is to further strengthen a single provider in a competitive market with multiple alternatives (Maestro, Cardanoscan, Koios, Dandelion, Ogmios, Yaci Store, etc.).
Key dependency claims—such as “~90% of free‑tier traffic,” “100+ Icebreakers,” and “hundreds of thousands of dollars” in projected savings—are not backed by independently verifiable data and at least one claim was removed after scrutiny. I am not comfortable using treasury funds to subsidize one incumbent’s operating costs and strategic expansion on the basis of unverified metrics, especially when this risks distorting competition and encouraging similar requests from other providers.
4. Prior funding and accountability
Given IO & affiliates’ existing ₳130.7M allocation and prior Blockfrost support, I expect a higher standard of backward‑looking accountability before approving a further multi‑million‑ADA ask.
The proposal acknowledges these prior receipts but does not provide a clear, quantified retrospective on:

• how previous Blockfrost funds were used, and
• what measurable improvements (uptime, capacity, geographical redundancy, developer adoption) were delivered.

For repeat funding at this magnitude, assertions of importance are not enough; the community should see concrete, auditable results.
5. What I would support instead
My NO is specific to this combined packaging. I would be positively inclined toward a restructured approach, for example:
A Cayley‑only infrastructure proposal, with clear technical KPIs, decentralization metrics, audits, and reporting.
A separate, smaller, time‑bounded operations proposal (if still desired) that is competitively neutral, supported by transparent revenue/cost data, includes a taper or exit schedule, and offers some form of public return to the treasury (e.g., revenue share or capped loan).
In summary, I support solving the data‑infrastructure problem and view Cayley as promising, but I cannot support this specific mix of bundled infra and exclusive OPEX subsidy. For that reason, I am voting NO.

I am voting YES on “IO & Midgard Labs: L2 Scalability Initiative” at 10,425,871 ADA, but it is a conditional YES that comes with clear expectations and consequences for future proposals in this area.
This initiative sits at a critical point in Cardano’s throughput expansion strategy. Today’s L1 profile—multi‑minute to ~2‑hour finality, ~7–10 TPS, and fees around 0.17 USD—excludes Cardano from serious consideration for high‑frequency DeFi, AI‑agent micropayments, gaming, and consumer payments, even before technical merits like security or eUTxO are evaluated. Leios and Peras will materially improve base‑layer capacity and finality, but they will not deliver sub‑second UX and sub‑cent fees across the board; in this budget cycle, only L2s can credibly close that gap. This proposal funds three linked workstreams that together address that problem in a way that builds on, rather than discards, prior investments: (1) a shared, L2‑agnostic data availability strategy and prototype for all Cardano L2s; (2) production hardening and turnkey solutions for Hydra, now in its adoption phase with real users like Delta DeFi and Masumi; and (3) the path from testnet to mainnet‑readiness for Midgard, Cardano’s first permissionless optimistic rollup. Strategically, this is not a nice‑to‑have; it is the L2 side of the Basho story, and without it Cardano’s scaling roadmap remains incomplete.
At the same time, the concerns raised by NO‑voting DReps are serious and justified, and my YES explicitly incorporates them. First, several DReps argue that Hydra has already received substantial investment and still has an unclear path to ecosystem‑wide impact, and that 80% of this budget going to Hydra‑related work risks good money chasing uncertain adoption. Second, Midgard has previous funding via Catalyst and a 2025 treasury withdrawal, with missed or delayed milestone communication and a shifted mainnet target; this undermines trust even if technical work has progressed. Third, this proposal bundles three conceptually distinct categories—shared public‑good infra (DA layer), IO’s own L2 research/maintenance (Hydra hardening), and acceleration of a specific rollup product (Midgard)—into one treasury narrative, making it harder to judge each on its own merits. I agree with these critiques. However, I also see a substantial body of prior Hydra and Midgard work, live or near‑live adopters (Delta DeFi, Masumi), and a clear, ecosystem‑level need for L2 capacity. On that basis, I judge a controlled continuation to be more prudent than halting the initiative mid‑stream, provided we tighten expectations around how this work is executed and reported.
My YES vote is therefore conditional on three expectations, which will heavily influence how I evaluate any future L2‑related asks:

1. Clear separation and reporting per workstream. I expect IO and Midgard Labs to report progress and milestones separately for: (a) the L2‑agnostic DA strategy/prototype (Q3–Q4 2026 → Q1 2027 spec and prototype), (b) Hydra production hardening and turnkey solutions (performance SLOs, operator tooling, and reference DeFi/state‑machine deployments for projects like Delta and Masumi), and (c) Midgard’s multi‑operator coordination and pen‑testing towards mainnet readiness. Any future proposals must show what was actually delivered here against these three tracks, not re‑bundle them into another large, undifferentiated narrative.
2. L2‑agnostic infra and ecosystem‑first design. The data‑availability workstream must remain genuinely L2‑agnostic, with transparent evaluation of candidate architectures and visible community input before locking in choices that could impose ecosystem‑wide technical debt. Likewise, Hydra hardening and Midgard mainnet work should be positioned as platform‑level infrastructure with open standards and clear documentation, not as bespoke support for a small set of projects. Treasury is not a bailout mechanism for individual business models; if Delta, Masumi, or Midgard succeed, it should be because they provide competitive products on top of shared infrastructure, not because that infrastructure is effectively subsidised only for them.
3. Significantly improved communication and milestone discipline. For Midgard in particular, previous Catalyst and treasury funding cycles have suffered from weak outward communication and slow milestone reporting, even where technical progress has been real. Going forward, I expect timely, transparent milestone submissions under this proposal, with public artefacts that non‑specialist DReps can verify: specs, testnet releases, pen‑test reports, and clear criteria for mainnet readiness. If those expectations are ignored or minimised—if, in another year, we are again asked to fund “the final push” for Midgard or further Hydra platformisation without clear, verifiable delivery against this program—my default stance on subsequent L2 scalability withdrawals will shift toward NO, regardless of how strategically important the category is in the abstract.
   In summary, I see this proposal as a necessary next step in Cardano’s throughput expansion path, tying together shared L2 infrastructure, Hydra’s adoption‑phase hardening, and Midgard’s move toward production in a way that can materially improve competitiveness and tie L2 activity back to L1 fees and treasury revenue. I support it because I believe the downside of not funding it—stalled Hydra adoption, a Midgard testnet that never crosses the finish line, and a lack of credible L2 options for builders—is greater than the controlled risk of funding it under tightened expectations. But that support is not open‑ended: future votes in this area will be decided based on how well IO and Midgard Labs meet these expectations on delivery, separation of concerns, and communication over the life of this initiative.

I am voting NO on “Cardano Summit 2026 and TOKEN2049 Singapore” at the requested 14,076,539 ADA (~3.66M USD), and would only consider supporting a substantially revised version under tighter conditions. In my view, a multi‑day event that requires funding in the multi‑million‑dollar range is, by design, oriented toward large, well‑capitalized players rather than the retail users or smaller institutions we claim to be targeting. The current configuration does not convincingly justify this level of spend versus other treasury priorities.

For a revised proposal, I would need to see three things: (1) a materially reduced and modular budget (for example, a leaner physical Summit in Singapore with more internal content online, and a Platinum + Top‑Up approach at TOKEN2049 justified against the current full‑Title package), (2) clearly outcome‑focused KPIs that go beyond contacts and impressions to measure developer retention, enterprise pilots/PoCs, mainnet deployments, and DeFi/liquidity impacts attributable to the events, and (3) an explicit commitment that any 2027+ event or sponsorship funding will be contingent on meeting those 2026 adoption KPIs, not merely on delivering the event itself.

Rationale for the direction of this vote:

The operational urgency argument presented in this proposal is legitimate and not in dispute. Over 500 active projects — with an estimated $33 million USD in undistributed milestone payments across Funds 10–14 — require a managing entity to continue functioning. If no Administrator is confirmed before the end of May 2026, Catalyst operations face an indeterminate pause that would directly harm grantees who have fulfilled or are fulfilling their obligations in good faith. That is a material harm this vote intends to avoid.

However, approval of this proposal does not signal satisfaction with the Cardano Foundation as a stewardship body, nor does it constitute endorsement of how CF has conducted itself in previous community interactions. Several concerns remain unresolved and will be actively monitored:

1. Governance accountability deficit. The CF operates under a Swiss Stiftung structure that does not permit ADA holders to elect or remove board members. The board is self-perpetuating and structurally unaccountable to the community whose treasury funds it is being asked to steward. This is a foundational governance misalignment with the principles embedded in the Cardano Constitution. This vote does not ratify this structure as acceptable — it accepts a constrained operational necessity.

2. Contested prior conduct. CF's deployment of 180 million ADA in voting stake during Catalyst Fund 13, in a manner perceived by a significant portion of the community as contrary to community direction, and its governance lead's characterization of community critics as "useful idiots," represent a culture of entitlement incompatible with the concept of community stewardship. These incidents are on record and will inform all future evaluations of CF's conduct in this role.

3. No operational readiness documentation. The proposal provides no staffing plan, no milestone management framework, no transition timeline, and no description of the internal controls that will govern CF's administration of Funds 10–14. This level of opacity is inadequate for a stewardship role of this scale and will not be accepted as a standard going forward.

4. Structural failings of Catalyst unaddressed. Known deficiencies in Catalyst — including process documentation gaps, technical access limitations, procedural inconsistencies, and inadequate community representation in program design — are not acknowledged in this proposal. These failings did not originate with CF, but they must be addressed under CF's stewardship. Silence on these issues is not acceptable.

5. No accountability framework. The proposal includes no commitments to regular public reporting, community escalation pathways, independent oversight for the transition period, or measurable performance standards. These are minimum expectations for a body being granted stewardship of public funds.

Conditions and expectations attached to this vote:

This vote is cast with the explicit expectation that the following will be delivered within a reasonable timeframe:

Regular, structured public reporting on Fund 10–14 milestone reviews and disbursement status, on no less than a monthly cadence

A published transition and operational plan for CF's assumption of Catalyst administration

A documented assessment of Catalyst's existing structural deficiencies and a proposed remediation roadmap

Demonstrably transparent and consistent milestone review and disbursement decisions, with rationales available to the community

No repetition of the conduct observed in Fund 13 or the dismissive posture toward community accountability concerns

Failure to deliver substantive progress on these expectations will result in a motion to remove the Cardano Foundation from its stewardship position, with a defined reinstatement bar and cooling-off period. This is not an idle condition — it is a governance commitment.

The community has been offered a binary choice: approve CF or pause Catalyst operations. Under those circumstances, this vote approves continuity. It does not approve complacency.

As larger and more complex systems are developed and integrated into the Cardano ecosystem, the need for iterative parameter updates like this will become more frequent.
​
I view this as a beneficial, appropriately risk-managed upgrade that follows the guardrails, is being executed in a staged manner, and includes an appropriate reversion plan if unexpected performance issues arise. My only recommendation is to provide more formal, first-hand supporting documentation in a single curated package (rather than scattered third-party links) to make review and long-term traceability easier for DReps and the broader community.

Withdrawal 1 (500k ADA) smartly operationalizes the approved DeFi Liquidity Budget Info Action by funding only foundational infrastructure—legal FC via Walkers, Amaru multisig via Sundae, and Invariant0 audit—before any liquidity deploy.
​
This addresses prior concerns: modular scale (0.15% treasury vs. 15%), detailed breakdowns/timelines (Phase 1–2, $166k legal), on‑chain enforcement (5/9 multisig, auto‑abstain), and constitutional compliance (Articles III–V, Guardrails). Providers are credible; milestones gate disbursements.
​
Approve to unlock safe testing of the full 50M framework—future tranches can be rejected if admin underperforms.

I support the need for a Net Change Limit for Epochs 613–713, but I do not support setting it at 350M ADA on the basis of the analysis provided. The proposed cap is chosen top‑down from past inflows and the previous NCL (≈306.9M ADA net income uplifted to 350M ≈115%), largely to accommodate an undrawn 50M DeFi Liquidity Budget, without a bottom‑up view of category‑level forecasts, a treasury sustainability trajectory, or ROI‑style reporting on how the last NCL’s spending actually performed. This falls short of responsible, program‑driven budgeting.

In practice, the prior 350M NCL has already been treated as a soft spending target, with an extension passed once the cap was approached, rather than as a rigorously justified ceiling. Re‑adopting the same headline number, again without clear forward planning or outcome analysis, risks normalizing that behavior. I am therefore voting NO on this 350M ADA NCL and would prefer a future NCL that is set at a more conservative level and explicitly grounded in transparent forecasts and retrospective impact reporting.

Constitution v2.4 retains and strengthens the governance architecture introduced in earlier versions, particularly the clear definition of roles and thresholds, the standardized and immutable governance‑action document model, and the comprehensive guardrails around protocol changes and treasury withdrawals.
​
By formally removing non‑binding “expectation” and “encouragement” clauses and the mandated CC code of conduct from the constitutional text, this version focuses the Constitution on enforceable rules and on‑chain guardrails, while leaving codes of conduct and tooling expectations to be defined and evolved through community practice and separate processes. This is more consistent with a durable, technology‑aligned constitutional document.
​
The removal of the Budget Info Action mechanism, combined with the re‑assignment of its audit, administrator, and reporting safeguards directly to all Treasury Withdrawal actions, simplifies governance while materially improving accountability. Every withdrawal must now meet the same high standard for transparency, auditability, and administrator responsibility, which aligns with best practices for treasury risk management.
​
The targeted reversions from v2.3 to restore the original v1.0 wording on ada “owners”, custodians, and independent audits address EMURGO’s specific concerns without weakening the underlying constitutional requirements for custody and oversight. This adjustment supports broad stakeholder acceptance and practical ratifiability while preserving the substantive protections introduced in later versions.
​
Taken as a whole, v2.4 is a carefully scoped refinement rather than a structural redesign. It maintains the improvements I previously supported in v2.3, clarifies and simplifies where experience has shown friction, and strengthens the link between on‑chain governance actions and immutable, auditable documentation. For these reasons, it merits a YES vote as the most coherent and operationally sound version of the Cardano Constitution to date.

Cardano 2030 assembles a professional framework from broad input (700+ participants), with a $200M L1 revenue target, starter KPIs (TVL $3B, 27M txns/mo, 1M MAU, 99.98% uptime), and 7 imperatives (abstraction, culture‑first targeting, talent, enterprise, SPOs, scalability, treasury) offering tactical ideas like turnout‑aware voting and multi‑asset yields.
​
​Yet, as a 2030 strategy, it underdelivers: pillars/imperatives restate themes without prioritization, timelines, owners, or trade‑offs; execution is "distributed" sans coordination; KPIs are explicitly preliminary, deferring fuller sets to 2026. The non‑binding Info Action provides direction but no discipline for treasury/rubric use.
​
​For the effort and funding, this remains an aspirational narrative over operational plan—strong start, immature finish. NO vote, urging iteration for sequencing, commitments, and enforcement to make it DRep‑actionable.

Voting decision: NO

Rationale

This proposal seeks to add an additional Constitutional Committee member by promoting the runner‑up from a recently completed snap election that was explicitly framed as filling a single vacant CC seat up to the constitutional minimum of seven members. While the election was close, the process produced a clear on‑chain outcome and Cardano Curia has already been duly seated through an Update Committee action.
​

The stated motivation—improving governance resilience above the current minCommitteeSize=7 and avoiding potential future deadlocks—is understandable, but changing CC composition in response to one close result, by directly installing the losing candidate, cuts against the basic democratic expectation that an election with defined rules and a single available seat produces a single winner. This approach risks being perceived as retroactively revising the outcome of that process rather than respecting the original mandate.
​

If the community wishes to increase CC size, introduce alternates, or add buffer capacity, this should be addressed via a separate, neutral governance track that revisits CC design as a whole: number of seats, use of ranked or multi‑seat elections, fallback and replacement mechanisms, and clear guardrails for how “near‑tie” candidates may or may not be considered in future. Those changes should then apply generally, not solely to this specific snap election or individual candidate.
​

The proposal is formally constitutional as an Update Committee action: it references the prior Curia Update Committee action as previousGovActionId, does not remove or replace existing members, keeps the 67% threshold unchanged, and respects the current term end at epoch 653. However, constitutional validity alone is not sufficient to justify setting a precedent of using Update Committee actions to immediately add election runners‑up on a case‑by‑case basis.
​

For these reasons, this proposal is premature and procedurally mis‑targeted. The underlying problem—how to design a more resilient and flexible Constitutional Committee composition and election system—should be addressed through a broader governance design effort rather than by installing a specific individual outside the original one‑seat mandate. Until such a framework exists and is approved, adding an extra member in this way would blur the line between respecting election outcomes and retroactively adjusting them.
​

On this basis, a NO vote best preserves the integrity of the recent snap election and signals that CC composition changes should be handled via a comprehensive, community‑wide governance design process rather than ad‑hoc additions driven by a single close result.

I understand that this rationale is longer that usual and ask for the reader's forgiveness, however I wanted to be sure that I was very clear on why I have chosen to vote NO to this proposal.

Inadequate transparency on costs and structure

This proposal intentionally withholds any cost breakdown and any concrete repayment schedule, citing negotiation leverage and market‑sensitivity, which prevents DReps from assessing whether a 5M ADA facility is proportionate to actual listing, market‑making, legal, and marketing costs. Cardano’s constitutional and governance expectations for treasury withdrawals require that relevant costs, repayment conditions, and refund circumstances be specified in enough detail for voters to understand what they are authorizing; here, those core economic parameters are effectively “trust us, audited later.” Compared to other large, system‑level initiatives I have evaluated (e.g., the 275M ADA ecosystem budget, stablecoin and liquidity frameworks), this falls below the transparency baseline I have already treated as mandatory for nine‑figure‑equivalent commitments.​​

Weak lender protections and asymmetric risk

Although the Snek Foundation cites historic revenues (e.g., Snek.fun at ~100k ADA/month, a ~10M ADA treasury, ~1.2M ADA in fees, and potential equity raises), none of these are bound to hard covenants such as minimum annual repayments, coverage ratios, or ring‑fenced cash flows dedicated to servicing the loan. Principal repayment can be deferred until the end of year 3, the total repayment window stretches to five years, and there is no explicit default ladder beyond a generic statement that enforcement would follow a separate loan contract under Intersect. In practice, this structure shifts timing, liquidity, and performance risk onto the treasury while leaving the borrower with broad discretion over when and how to prioritize repayments, which is inconsistent with the kind of disciplined, lender‑protective design I have required for other large instruments.​

Governance, oversight, and unresolved conflicts of interest

The use of Intersect’s TRSC/PSSC framework, an Oversight Committee of external entities, a 3rd‑party assuror, and annual audits does ensure secure custody, on‑chain traceability, and basic administrative checks. However, the Board of Advisors—including senior figures from Cardano Foundation, Emurgo, Midnight Foundation, and Snek Foundation—has an advisory only role with no binding authority, no key control, and no formal conflict‑of‑interest and recusal provisions described in the text. This means the same ecosystem leaders who should be neutrally stewarding treasury and governance narratives are positioned as proponents and brand backers of a high‑risk, lightly specified loan, without any structural safeguards to separate their ecosystem duties from SNEK‑specific commercial outcomes, which I have consistently treated as governance‑quality red flags.​​

Misleading framing of the “approved budget” and process integrity

The proposal states that this treasury withdrawal “follows the approved Budget: ₳5M Loan for Cardano's Global Listing Expansion – Powered by Snek,” and links to an outcome page that many readers could interpret as a final authorization. On‑chain and explorer data show that the original SNEK loan proposal was an info action that passed its vote but then expired as an info action, meaning it did not itself trigger a binding treasury withdrawal or create a legally enforceable budget line in the smart contracts. Presenting that earlier decision as an already “approved budget” for this loan blurs a critical distinction between advisory sentiment (info actions) and actual legal/financial apportionment (treasury withdrawals), and risks misleading DReps into believing they are just operationalizing a pre‑ratified commitment rather than making the first binding decision on deploying 5M ADA. Under my rubric, this is a serious process‑integrity concern and alone would justify withholding support until proposers correct the record and clearly separate “community support signals” from true budget approvals.​

Strategic priority and speculative ecosystem benefit

Even if the loan were perfectly structured, the underlying bet remains that subsidizing SNEK’s centralized listings will materially improve ADA liquidity, CNT adoption, and global awareness enough to justify tying up 5M ADA for up to five years. Evidence from other ecosystems shows that meme‑coin exchange pushes often generate short‑lived trading volume and attention, with unclear, hard‑to‑measure long‑term benefit for base‑layer utility, developer adoption, or serious DeFi depth, especially when compared against alternatives like protocol‑level tooling, L2/Rollup infrastructure, or core dApp support. My established methodology prioritizes proposals with demonstrable, durable infrastructure or governance impact over speculative marketing and listing campaigns, particularly when they introduce new precedents for treasury‑backed loans and concentrated ecosystem bets on a single community token.​​

Conclusion

For these reasons—persistent opacity on costs and repayment structure, weak lender protections and asymmetric risk, governance and conflict‑of‑interest concerns, a misleading “approved budget” framing that blurs the role of prior info actions, and the speculative, non‑essential nature of the proposed benefits relative to other funding priorities—this proposal does not meet the standard of transparency, proportionality, and integrity I have applied to other high‑value treasury withdrawals. Accordingly, I believe a NO vote is warranted.

After a comprehensive review of the proposal 'Securing Generic Top-Level Domains for the Cardano Ecosystem', It is my determination that, at this time and under current conditions, it would be an inefficient use of resources to follow this course of action and have submitted a vote of NO.

This initiative requires a substantial, multi‑year financial and operational commitment (roughly 1.2–1.6M ADA equivalent in one‑off setup and ~200k–600k ADA per year in ongoing costs at 0.50 USD/ADA), yet the expected near‑term ecosystem demand for .ada and .cardano domains appears low and largely confined to existing participants already well‑served by current domains.​

Operating ICANN gTLDs introduces a new governance and DNS abuse‑mitigation surface, requiring continuous policy work, dispute‑resolution, identity and name‑allocation rules, and proactive anti‑phishing and impersonation controls under evolving ICANN obligations, at the same time that Cardano still lacks sufficient funding and focus for core infrastructure, user growth, and L2/application adoption.​

The stated goals—stronger digital presence and Web2/Web3 bridging—can be advanced more efficiently through defensive registration and brand‑protection on existing TLDs, targeted DNS‑abuse monitoring, and investment in Cardano‑native or partner Web3 naming systems (including integrations with providers that already support ADA) rather than by owning and operating two high‑cost, high‑risk ICANN gTLDs.​

For these reasons, and given more urgent ecosystem priorities and clearer ROI opportunities, this proposal does not justify community endorsement at this time.

I am supporting the "Reimburse Ikigai Info Governance Action Deposit" Info Action proposal based on the principle that Cardano governance must be accountable, trustworthy, and capable of correcting institutional mistakes affecting good-faith participants. Addressing this historic deposit loss is critical for sustaining trust in Cardano’s evolving governance processes, especially when significant collateral is required to participate in early and untested phases of on-chain proposal submission.

However, my ongoing YES vote for a subsequent formal treasury withdrawal is strictly contingent upon several conditions being met:

Verification of Recipient Authenticity: There must be clear, on-chain or otherwise cryptographically verifiable evidence that the reimbursement is being made either directly to the original Ikigai Info Action proposer or to an officially authorized representative. No unrelated or opportunistic third-party should ever receive these funds. Proper identity confirmation and documentation should be part of the process to prevent misuse or fraudulent claims.

Accurate, Conservative Compensation Calculation: The final reimbursement should be limited to the original 100,000 ADA deposit plus a precisely calculated figure representing only actual lost staking rewards over the relevant period. Any “potential” or hypothetical opportunity costs (such as speculative airdrops or alternate network opportunities) must be excluded from the reimbursement to avoid turning a corrective action into an inappropriate windfall.

Preclusion of Exploitative Precedent: This action should be strictly treated as a one-time remedy for a specific, documented infrastructure failure. It must not become a template for turning process errors into personal profit. The intent here is to make the affected individual whole—and nothing more.

Appropriateness of Process: While some community members have discussed handling this via a future “insurance” or “bug bounty” process, I concur that this unique and isolated event can be satisfactorily addressed via the current Info Action and subsequent Treasury Withdraw mechanism—provided the above criteria are fully satisfied—without unnecessary delay or added procedural burden for the original submitter.

A YES vote is therefore justified as a principled act of rectification and trust restoration, but will only be maintained into the reimbursement stage if there is demonstrable compliance with these transparency and accountability standards. This proposal must not be allowed to devolve into a financial opportunism or process loophole; its legitimacy derives solely from its fidelity to the goal of correcting a protocol-level governance error for the original, directly affected participant.

While I respect the Constitutional Committee’s contributions and agree that professionalizing key governance roles may eventually support Cardano’s growth and integrity, I fundamentally cannot support this proposal for the following reasons:

1. Absence of a Community-Endorsed Compensation Framework: Compensation for governance actors should emerge from a broad, transparent, and peer-reviewed process covering all relevant bodies (CC, DReps, SPOs), not be defined by unilateral proposals by beneficiaries.

2. Excessive and Unjustified Amounts: The ask—200,000 ADA per member for non-executive, part-time oversight work, absent clear costing or workload—is excessive by sector standards and unaccompanied by supporting documentation, deliverables, or operational logs.

3. Governance Equity and Precedent Risks: Selective funding of the CC would unbalance the governance ecosystem, introducing perceptions of privilege and setting a problematic precedent for future administrative funding.

4. Transparency and Accountability: The lack of public discussion, clear workload transparency, and consensus-building demonstrates a failure of process.

Until Cardano establishes a unifying compensation policy through a full community-led framework, I cannot support isolated and unjustified treasury outlays of this magnitude for any governance role, including the Constitutional Committee.

I vote YES on the proposal to adopt the Cardano Blockchain Ecosystem Constitution v2.3 based on the following key reasons.

Clearer and Stronger Governance Framework

Version 2.3 builds upon the foundation established in 2.0 with important clarifications and enhancements. It removes non-binding aspirational clauses and the Budget Info Action mechanism, streamlining governance into enforceable, operational rules focused on Treasury Withdrawals and oversight. This rationalization strengthens constitutional coherence and legal certainty, improving accountability for treasury fund administration.

Enhanced Transparency and Oversight

The update mandates immutability of hosted proposal documents, expanded definitions for key governance terms, and universal application of audit and administrator designation requirements on all treasury withdrawals. This elevates transparency and consistency in how funds are governed and overseen, directly responding to community feedback and governance experience since version 2.0.

Alignment with Cardano’s Strategic Direction

By simplifying processes and codifying rigorous oversight mechanisms, version 2.3 better supports Cardano’s decentralized ethos while facilitating scalability and operational efficiency. It strengthens key guardrails such as the Net Change Limit and clarifies stakeholder roles, which are essential foundations for sustainable ecosystem growth and community trust.

Incorporation of Community Feedback

The refined provisions reflect recommendations aimed at removing ambiguity, improving enforceability, and ensuring strong oversight—addressing gaps noted in earlier versions. This collective community input has been prudently integrated to balance transparency, inclusivity, and practical governance.

Summary

The Constitution v2.3 delivers a streamlined, principled, and robust governance framework that clarifies accountability, enforces rigorous treasury fund oversight, and removes outdated provisions. It upholds Cardano’s commitment to decentralized, transparent, and resilient governance. Given these substantial improvements and thoughtful incorporation of feedback, endorsing v2.3 is a prudent step forward for the Cardano community’s collective governance maturity.

I therefore strongly support a YES vote on the Cardano Blockchain Ecosystem Constitution v2.3 proposal.

After thorough review of the proposal titled Cardano GovTool Budget – 12-month Maintenance and Active Development, I recommend a NO vote on this proposal primarily due to significant governance and financial risks related to its internal incentive fund and governance structure.

While GovTool is foundational to Cardano’s decentralized governance process, this proposal introduces a discretionary incentive fund (~₳250,000) lacking transparent allocation criteria, decision-making processes, contributor definitions, or conflict-of-interest safeguards. This discretionary budget resembles a slush fund with increased risk of misuse and inadequate accountability to the community.

Additionally, the governance consortium lacks clear authority, defined membership criteria, and formal conflict resolution mechanisms, which weakens oversight and increases risks of centralization within this core governance infrastructure.

Further, the roadmap omits specific, measurable deliverables and success metrics, limiting meaningful community oversight of progress and outcomes. DRep voting on this proposal appears to be a formality rather than a fully informed, transparent decision-making process.

Given Cardano’s constitutional mandates for transparency, prudent treasury management, and decentralization of authority over funds, the unresolved ambiguity and risk posed by this proposal prevent endorsement at this time. Strengthening governance clarity, incentive distribution transparency, and establishing explicit accountability are essential before reconsideration.

Based on a comprehensive evaluation of the proposal, established governance procedures, and aggregate community sentiment, I have submitted a NO vote for the "Stablecoin DeFi Liquidity Budget" proposal (50M ADA) in its current form.

Key Rationale

Lack of Prerequisite Structures and Planning

Absence of tDAO and Legal Foundation: The proposal relies on a tDAO for oversight, yet this body is not conceptualized, staffed, or operational. There is no existing legal entity or governance framework to safely manage or administer such a large fund, which is a fundamental red flag by any business, investment, or risk management standard.

Undefined Oversight and Reporting: Promises of developing accountability, reporting, and legal standards after budget approval are contrary to every recognized principle of prudent fund allocation. Best practices universally require such systems to be fully in place before any capital committal, not after.

Failure in Proposal Structuring

Premature and Over-broad Proposal: Rather than presenting a clearly actionable business plan, this initiative is more akin to a vague planning exercise masquerading as a fund request. It offers neither a tested operational framework nor a breakdown of risk models or performance expectations, and is structured as a "figure it out as we go" experiment using community assets.

Lack of Segmenting and Sequencing: The absence of a phased or modular approach—where design, governance, and legal structures are built and audited before funding is sought—represents a critical governance failure. Sound practice dictates that only after core frameworks and administrative competence are proven should capital deployment even be considered.

Business, Risk, and Investment Management Failures

No Professional Investment Policy or Guardrails: There are no portfolio allocation models, drawdown policies, counterparty limits, crisis response plans, or milestones tied to performance-based tranches—minimum standards for any professional asset manager or public treasury.

Irresponsible Risk Posture: The proposal concentrates risk on an unelected, only partially accountable committee, with unclear recusal rules or conflict of interest enforcement—violating both fiduciary duty principles and modern governance guardrails.

Lack of Strategic Depth and Focus

Liquidity Myopia: While liquidity is conclusively a core DeFi success factor, it is meaningless absent underlying real utility, enterprise traction, and a sustainable business model. Over-prioritization distorts resource allocation, increases exposure to mercenary capital, and can fail to deliver stickiness or real user adoption.

Redundancy and Inefficiency Risk: The broad, loosely-defined goals overlap with several other ecosystem initiatives, risking inefficient capital allocation, duplicated efforts, and wasted opportunity costs.

Diversification and Treasury Stewardship Principles

Concentration Risk: The wisdom of spreading risk—"never put all your eggs in one basket"—is wholly disregarded in the current plan. The lack of diversification, both functionally and by scope, endangers the treasury and is inconsistent with both modern portfolio management and responsible treasury practice.

Permanent Bureaucratic Overhead: Guaranteeing perpetual committee remuneration and legal overhead without clearly defined public-goods milestones or exit criteria is not only a governance anti-pattern but an economic liability to the community.

Best Practice and Comparative Analysis

Standard Practice: Leading public funds and private investment managers—whether in DeFi or traditional finance—always build legal, operational, and audit structures first. Investment committees are elected or appointed by competitive, transparent, and public call. Only after key-person risk, accountability, and business processes are in place does real capital begin deploying.

DAO Treasury Precedents: Successful ecosystem DAOs (e.g., Uniswap, Aave) introduce liquidity mining, grants, and reserve management slowly, with checks, tranching, and extensive upfront community debate. Large untried fund deployments without shadow governance, defined metrics, or staged releases have repeatedly (see various DeFi hacks, governance blowups) led to lasting loss of funds and community trust.

NO Vote Rationale

This proposal cannot be responsibly approved or recommended in its current form. It requests Cardano treasury assets while lacking even the minimum baseline of operational, legal, and strategic readiness demanded of any large grant, investment, or public-capital initiative. The only responsible recommendation is a NO vote, with the advisory that future proposals be modularized such that design, setup, governance, and legal structure occur sequentially, with capital made available only to proven, elected, and auditable administrative entities working from a foundation of clear, community-endorsed standards and diversified, milestone-based budget tranches.

After a thorough review of the full SNEK proposal rationale, evaluation of community input, comparative market standards, and cross-referencing all established Cardano governance records, I submit a NO vote for this proposal. The crux of my decision is the absence of robust, constitutionally aligned processes and an ecosystem-proven legal/organizational framework suitable for issuing and administering commercial loans from the Cardano Treasury.

Detailed Evaluation

1. Lack of Precedent—No Established Loan Process
   The Cardano Treasury operates under a structure designed for milestone-based grants with rigorously defined milestones, multi-party escrow, third-party oversight, and constitutional controls.

Nowhere in the current treasury system is there an on-chain framework, admin process, or legal toolset for the issuance, management, recourse, interest collection, or default remedy of loans—even “pilot” commercial loans of this scale.

All successful treasury withdrawals to date have run through a tightly defined and auditable risk and governance process, never as discretionary or borrower-defined long-horizon loans.

1. Inadequate Safeguards and Unusual Terms
   The SNEK proposal, while innovative, requests terms highly irregular by any professional standard: a multi-million ADA loan, 2.4% APY, with no payments due for 3 years and full repayment not due for 5 years—without meaningful security or collateral.

No comparable public or institutional lending entity—especially one managing public funds—would extend a loan of this quantum, to this class of asset (meme coin), on such open-ended terms, at this interest rate, and with such minimal repayment obligation visibility.

The proposal places the onus on Cardano’s Treasury and governance to adopt a risk role more akin to venture banking than public fund administration—without the protections or institutional capacity to do so safely.

1. Organizational and Legal Framework Gaps
   The Cardano ecosystem’s administrative structure (Intersect as default administrator, external multi-sig oversight, constitutional requirements for dispute and milestone handling) is not designed for ongoing loan management, enforcement, or interest rate monitoring.

No statutory body or operational entity currently exists to negotiate, collect on, or restructure defaulted loans for the treasury—or to handle complex dispute resolutions implied by commercial lending.

1. Critical Process and Guardrail Deficiencies
   The absence of essential financial guardrails exposes the treasury to both moral hazard and significant loss risk.

Unlike successful infrastructure and tooling proposals, which are disbursed incrementally with third-party assurance tied to verifiable completion criteria, this proposal would see public risk concentrated on one entity with large, deferred, and ambiguous returns.

There is inadequate process for ongoing community oversight, repayment transparency, or the implementation of independent professional review for such a high-risk, high-exposure transaction.

1. Stewardship and Fiduciary Responsibility
   As a DRep, my duty is to place the Cardano Treasury and ecosystem’s long-term sustainability and resilience above short-term gain or popularity, even when personally holding some exposure to SNEK tokens.

Regardless of individual or community enthusiasm, it is essential to uphold rigorous, neutral, and prudent stewardship—particularly given the precedent this proposal would set for future requests.

Approving such a proposal without having first established a dedicated loan administration body, a comprehensive lending framework, and auditable risk management and reporting structures would represent a fundamental breach of responsible treasury oversight.

Evaluation Table

Review Category	Score (out of 5)	Rationale
Constitutional Compliance	2	Unclear alignment—lacks defined approval, admin, and enforcement policies for loan instruments.
Governance Oversight	2	No internal process or precedent for loan management, default recourse, or sustained oversight.
Value Alignment	3	Supports an existing Cardano project, but terms, risk, and uniqueness make value questionable.
Risk & Redundancy	1	High exposure, no diversification, concentrated and illiquid counterparty risk.
Transparency/Reporting	2	Repayment and interest reporting undefined, off-chain, with little recourse for missed targets.
Funding Proportionality	2	Large ADA amount, not justified for unsecured, borrower-dictated lending terms.
Vendor Track Record	3	SNEK’s community impact recognized, but not adequate for multimillion loan risk.
TOTAL	15/35
FINAL SCORE (scale 0–100)	42.9

Recommendation
This proposal cannot be supported without the prior establishment of a clearly defined, constitutional loan framework, specialized administrative structure, thorough risk assessment and milestone enforcement model, and transparent, community-auditable reporting regime. It does not meet the established governance or fiduciary standards required for the safe stewardship of the Cardano Treasury.

NO VOTE — Until such time as the necessary treasury processes, guardrails, and organizational capabilities for responsible lending are established, approval of this loan would undermine Cardano’s governance principles, risk community assets, and set a precarious precedent for public fund management.

This proposal represents a critical milestone for Cardano as it marks the first full year of community-led governance following the establishment of the Cardano Constitution and initial on-chain voting mechanisms. While the governance process remains a "work in progress," this proposal is a constructive step that lays the groundwork for a more inclusive, transparent, and accountable decentralized system.

The incoming seven Constitutional Committee (CC) members bring fresh perspectives and diverse expertise to the governance framework, complementing the experience of outgoing participants. Their active participation is expected to enhance the oversight of governance decisions, promote fairness in evaluating proposals, and improve responsiveness to community feedback. This generational transition signifies maturity and resilience in Cardano's governance model, fostering broader community confidence.

Importantly, this proposal embraces the iterative nature of decentralized governance. It recognizes the ongoing need to engage the entire Cardano ecosystem, including DReps, SPOs, developers, and everyday ADA holders, in shaping future votes and budget allocations. The emphasis on increasing transparency, expanding participation beyond select groups, and refining compliance checks reflects a commitment to evolving governance practices in alignment with Cardano’s constitutional principles.

In summary, the proposal not only supports critical infrastructure and ecosystem development but also symbolizes a pivotal phase in the community’s journey toward robust, scalable, and inclusive self-governance. Voting YES reinforces confidence in this evolving process and encourages continued collaboration and refinement to strengthen Cardano’s governance for the long term.

After a thorough and detailed review of the proposed Constitution Version 2.00, I find this iteration to be a sound and acceptable foundation for the ongoing governance of the Cardano Blockchain ecosystem. This Constitution reflects significant evolution in establishing a robust, decentralized governance framework that balances community participation, technical security, transparency, and long-term sustainability. While I have identified various questions and considerations regarding specific language, definitions, and procedural clarifications, these points do not constitute objections substantial enough to warrant a NO vote. Instead, they represent constructive feedback intended to promote iterative refinement and clarity in future amendments.

The Constitution 2.00 presents a comprehensive governance architecture encompassing the roles and responsibilities of Ada Holders, Delegated Representatives (DReps), Stake Pool Operators (SPOs), and the Constitutional Committee (CC). It establishes guiding tenets, defines essential guardrails for protocol parameter changes and treasury withdrawals, and introduces meaningful processes for community participation and oversight. Its design to promote self-governance, impartiality, and financial stability aligns well with Cardano’s vision to empower individuals and communities globally.

I support the adoption of Constitution 2.00 because it satisfactorily captures these core principles and practical mechanisms necessary for the Cardano ecosystem to mature its decentralized governance in a secure and transparent manner. It does so while acknowledging governance as a living process, open to future amendments driven by community consensus.

Summary of Questions, Considerations, and Recommendations for Future Committee Review

These points reflect areas where additional specificity, clearer definitions, and procedural detail may enhance the constitutional framework in subsequent iterations or guidance documents. They will be formally submitted to the Constitutional Committee for consideration:

1. Preamble Language and Clarity
   The phrase “we hereby establish this Cardano Constitution to govern the Cardano Blockchain ecosystem” could be refined to clarify that the Constitution establishes governing rules rather than governing directly.
   Suggest adding “and vision” to “share our values” to emphasize the shared aspirations behind the Constitution.

2. Definition of “Persons” and Inclusion Language
   In the definition of Ada Holders as “Persons,” clarification is needed whether this refers exclusively to individual natural persons or includes corporate entities. Using language consistent with the Cardano Community definition (“individuals and organizations”) might reduce ambiguity.
   Question the use of “including the CC” in the Cardano Community member definition, as including a specific entity can imply exclusion of others, which was likely unintended.

3. Terms and Role Clarifications
   Clarify that DReps vote not only on on-chain governance actions but also on “Info” actions that indicate community sentiment, to avoid confusion from casual use of “on-chain” and “off-chain” terminology.
   Recommend expanding Ada Holders’ participation rights to explicitly include direct voting without registering as DReps or delegating, reflecting functionality described in existing governance tools.

4. Net Change Limit and Treasury Mechanics
   Suggest defining the Net Change Limit formula more explicitly, including how the Treasury value baseline is established and its relationship to withdrawal limits over time-frames for greater clarity.

5. Privileges and Protections of Community Members
   Request more explicit detailing of the rights, privileges, and protections referenced in Article II Section 1 to reduce reliance on literary generalities and improve definitional precision.

6. Compensation Disclosure and Governance Communication Channels
   Inquire about the practical mechanisms and designated governance communication channels for DReps and CC members to disclose compensation transparently, along with responsibilities for managing these channels.

7. Proposal Content and Supporting Materials
   The immutability requirement for proposal documents is understood to safeguard integrity, but suggest exploration of mechanisms that allow updating, adding, or withdrawing supporting information related to proposals during their active period to facilitate innovation and responsiveness.

8. Oversight and Administration of Treasury Withdrawals
   Recommend explicitly stating in the Constitution that treasury withdrawal proposals must specify the designated process and responsible agent(s) for oversight.
   Questions why the requirement to designate administrators for monitoring treasury withdrawal funds is reiterated only in large requests, recommending it be universal.

9. Constitutional Committee Process Enhancements
   Propose that the constitutionality determination of governance actions by the Constitutional Committee be completed prior to DRep voting to avoid wasted efforts on unconstitutional proposals.
   Calls for more precise language on the CC’s composition, term-setting authority, and election timelines to avoid ambiguity and governance paralysis.
   Request safeguards and timelines around no-confidence motions and related governance to mitigate risks of stalemate or misuse.

10. Transparency and Conduct of Constitutional Committee
    Suggest clearer and more concise language for CC members voting against constitutionality requiring written rationale linked to specific constitutional provisions.
    Question the differential approach to compensation disclosure between CC members and other contributing participants, advocating for equitable treatment.

11. Guardrails and Amendment Procedures
    Recommend replacing vague phrases like “from time to time” with fixed timelines or defined processes, especially for guardrail amendments and CC elections, to enhance predictability and accountability.

12. Terminology Refinement
    Propose abandoning or minimizing ambiguous terms like “on-chain” and “off-chain” in favor of more precise designations linked to the specific governance or technical processes they describe.

13. Definition of “Info” Actions
    Request clearer definition of “Info” actions in the Constitution as tools primarily for gauging community sentiment rather than only an on-chain record, avoiding circular definitions.

In conclusion, while these questions and recommendations highlight important areas for future refinement, they do not detract from the overall quality and readiness of Constitution Version 2.00 to serve as the foundational governance framework for the Cardano Blockchain ecosystem. Accordingly, I cast my YES vote in support of Constitution 2.00 and respectfully submit the above points to the Constitutional Committee for ongoing consideration and improvement.

This proposal is substantially the same as 'Withdraw ₳5M for Cardano's Global Listing Expansion - Powered by Snek' aside from the title and what appears to be an error or placeholder in the amount metadata (₳5 vs ₳5M). These 2 proposals appear to be duplicates or near-duplicates submitted twice—potentially one draft and one finalized, or a re-submission due to a metadata error.

Despite the slight differences, the underlying issues remain the same and as such I'll use the same rationale as I did in the other proposal.

After careful review, I am unable to support this proposal in its current form due to multiple critical constitutional and operational shortcomings relating to Cardano’s governance standards for treasury disbursement.

Key issues necessitating a NO vote:

Constitutional Noncompliance

No Named Administrator: The proposal does not specify an Administrator (such as Intersect or Cardano Development Holdings) responsible for the contractual, fiduciary, and oversight duties associated with Cardano Treasury withdrawals, as required by Article IV of the Cardano Constitution.

No Legal Contract Commitment: There is no explicit commitment to a legal, off-chain contract with defined milestones, deliverables, dispute resolution, and reporting. This is mandatory for all treasury withdrawals to ensure enforceability and accountability.

Lack of Milestone-Based Escrow: The proposal does not establish milestone-based, smart contract–gated disbursement. Funds appear poised for full or discretionary release, with no clear controls to ensure payment only upon delivery of new exchange listings or defined KPIs.

Lack of Third-Party Assurance and Oversight: The proposal leaves out provisions for an independent oversight agent—such as Cardano Foundation, DQuadrant, or NMKR—to serve as milestone verifier and ensure funds are released only when contractual obligations are met.

Operational Risks

No Smart Contract Controls or Delegation Policy: There is no commitment to use the Sundae Labs Treasury Reserve Smart Contracts (TRSC/PSSC) or multi-signature custodial controls; nor is there any assurance that funds will be delegated only to an auto-abstain DRep (not to a Stake Pool Operator), violating best practices in treasury security.

No Process for Vendor KYB/KYC: The proposal does not affirm that the Snek Foundation (or principals) will provide pre-funding verification, Know-Your-Business (KYB) or Know-Your-Customer (KYC) documentation.

No Refund/Clawback or Unused Funds Handling: While there is mention of returning unused budget, there is no contractual guarantee, escrow mechanism, or refund process described for unsupported, failed, or incomplete listings.

Transparency and Overlap

Risk of Duplication: The proposal does not clarify coordination or non-overlap with existing, already-funded Cardano exchange listing and market-making pools (e.g., Flowdesk). There is risk of duplicated listing efforts or double fee payments.

Inadequate Public and On-Chain Reporting Commitments: While intent for transparency is stated, there is no binding provision for on-chain metadata, announcement of exchange targets, or progress tracking following the established Cardano treasury reporting practice.

In summary:
While the proposal is high-impact and the vendor has strong credentials, Cardano’s constitutional governance exists to prevent treasury capture and enforce stewardship. Treasury funds must be administered only under named, contractually bound, multi-party and externally assured processes. In the absence of these basic protections, a YES vote would undermine decentralization, transparency, and accountability for the entire ecosystem.

I am therefore compelled to vote NO until these core operational and constitutional deficiencies are remedied.

After careful review, I am unable to support this proposal in its current form due to multiple critical constitutional and operational shortcomings relating to Cardano’s governance standards for treasury disbursement.

Key issues necessitating a NO vote:

Constitutional Noncompliance

No Named Administrator:
The proposal does not specify an Administrator (such as Intersect or Cardano Development Holdings) responsible for the contractual, fiduciary, and oversight duties associated with Cardano Treasury withdrawals, as required by Article IV of the Cardano Constitution.

No Legal Contract Commitment:
There is no explicit commitment to a legal, off-chain contract with defined milestones, deliverables, dispute resolution, and reporting. This is mandatory for all treasury withdrawals to ensure enforceability and accountability.

Lack of Milestone-Based Escrow:
The proposal does not establish milestone-based, smart contract–gated disbursement. Funds appear poised for full or discretionary release, with no clear controls to ensure payment only upon delivery of new exchange listings or defined KPIs.

Lack of Third-Party Assurance and Oversight:
The proposal leaves out provisions for an independent oversight agent—such as Cardano Foundation or NMKR—to serve as milestone verifier and ensure funds are released only when contractual obligations are met.

Operational Risks

No Smart Contract Controls or Delegation Policy:
There is no commitment to use the Sundae Labs Treasury Reserve Smart Contracts (TRSC/PSSC) or multi-signature custodial controls; nor is there any assurance that funds will be delegated only to an auto-abstain DRep (not to a Stake Pool Operator), violating best practices in treasury security.

No Process for Vendor KYB/KYC:
The proposal does not affirm that the Snek Foundation (or principals) will provide pre-funding verification, Know-Your-Business (KYB) or Know-Your-Customer (KYC) documentation.

No Refund/Clawback or Unused Funds Handling:
While there is mention of returning unused budget, there is no contractual guarantee, escrow mechanism, or refund process described for unsupported, failed, or incomplete listings.

Transparency and Overlap

Risk of Duplication:
The proposal does not clarify coordination or non-overlap with existing, already-funded Cardano exchange listing and market-making pools (e.g., Flowdesk). There is risk of duplicated listing efforts or double fee payments.

Inadequate Public and On-Chain Reporting Commitments:
While intent for transparency is stated, there is no binding provision for on-chain metadata, announcement of exchange targets, or progress tracking following the established Cardano treasury reporting practice.

In summary:
While the proposal is high-impact and the vendor has strong credentials, Cardano’s constitutional governance exists to prevent treasury capture and enforce stewardship. Treasury funds must be administered only under named, contractually bound, multi-party and externally assured processes. In the absence of these basic protections, a YES vote would undermine decentralization, transparency, and accountability for the entire ecosystem.

I am therefore compelled to vote NO until these core operational and constitutional deficiencies are remedied.

After a careful and comprehensive evaluation of the “Cardano Product Committee Community-driven 2030 Cardano Vision and 2026 roadmap insights collection via workshops and structured product research” proposal, I have voted YES for the following reasons:

The proposal directly supports Cardano’s governance and product roadmap objectives, fostering transparent, inclusive, and broad-based community participation in long-term visioning and yearly roadmap development.

It provides a structured, scalable process to gather diverse insights addressing challenges in adoption, developer experience, and governance that are critical for Cardano’s future evolution.

The funding amount requested is proportionate and well-justified given the scope, complexity, and deliverables involved in conducting extensive workshops and research initiatives across global and regional communities.

The Product Committee demonstrates a strong track record, expertise, and commitment to accountability, with planned public documentation, open repositories, and reporting which ensures transparency and continuous community feedback.

This initiative is essential to prevent fragmentation and to maintain Cardano’s competitive edge through well-aligned, community-informed product decision making, extending beyond purely technical development into strategic ecosystem growth and participation.

Overall, the project supports the decentralized principles of Cardano by empowering the community’s voice and fostering sustained roadmap excellence, which aligns with the ecosystem’s constitutional and governance rules.

I am voting YES on this proposal to fund Cardano Ecosystem Pavilions at Exhibitions with ₳889,500.

This initiative addresses a critical need to make Cardano projects more visible and accessible at influential exhibitions globally. By subsidizing (not fully covering) project participation, the proposal enables diverse Cardano teams to showcase their work, attract investors and developers, and educate new audiences about the ecosystem’s depth and innovation. Importantly, the approach includes education and follow-up support to maximize each project's event return, and employs a milestone model to ensure accountability and efficiency with treasury funds.

Vendor experience, transparent milestone-based process, and scaled-back budget further enhance cost-effectiveness and trust. This is a practical, high-ROI initiative that strengthens Cardano's global presence and supports sustainable ecosystem growth.

For these reasons, I support this funding request.

While addressing a real issue in the Cardano ecosystem—market making and listing for Cardano Native Tokens—the proposal falls short in demonstrating broad ecosystem impact, scalability, and cost effectiveness. The scope is narrow, focusing mostly on select projects, with limited quantified KPIs or measurable returns to the wider community.

The substantial ₳3.126 million budget is not sufficiently justified given the indirect nature of ecosystem benefits and lack of clear, transparent milestone-based performance metrics. Community involvement and governance mechanisms appear limited in this funding approach, raising concerns about inclusivity and longer-term sustainability.

Despite vendor experience and a solid governance framework for treasury management, the strategic value of the service at this scale is questionable, prompting caution before treasury funds are allocated.

Accordingly, I have submitted a NO vote pending a more detailed, community-aligned strategic justification and clear measurable outcomes.

I recommend a YES vote for the ₳592,780 treasury withdrawal for "Beyond Minimum Viable Governance: Iteratively Improving." This proposal addresses a fundamental gap in the Cardano ecosystem by enabling continuous, transparent, and community-validated governance measurement and improvement.

The delivery team, led by IOG’s Voltaire specialists with backing from constitutional committee members, WADA, Intersect, and community partners, brings unparalleled experience in Cardano’s governance mechanics and stakeholder engagement. The project will create the first systematic, data-driven “State of Governance” report, track and publish governance KPIs, synthesize community feedback through multiple engagement pathways, author actionable CIPs/CPSs, and publish a replicable playbook for future improvement cycles.

The budget is reasonable for the scope, the delivery controls are strong, and the outputs will benefit DReps, committees, protocol maintainers, and ordinary users. The framework and open process will raise the standard of Cardano governance by providing a clear baseline, methodology, and improvement pathway, promoting greater transparency and resilience in decentralized decision-making.

I am now voting YES on this proposal after further direct engagement with the proposer and gaining additional context that meaningfully changes my assessment.

1. Direct communication to address concerns — The proposer reached out to me personally to clarify the intent, constraints, and future vision for NFTCDN. This responsiveness, determination, and willingness to address questions directly has increased my confidence in their commitment to delivering genuine value to the Cardano ecosystem.

2. Context of the first-ever voting round — Given that this is our first treasury voting cycle and the submission process was flawed (no definitive guidelines, inconsistent formatting, no pre-vote vetting, and incomplete info capture), I believe significant leeway is warranted when evaluating initial proposals. Early votes are as much about establishing process and gathering operational data as they are about perfecting proposals.

3. Existing gap in operational data and reporting — The Cardano ecosystem currently lacks consolidated operational usage metrics, cost baselines, and infrastructure demand data that would allow for accurate long-term planning. This proposal can help fill that gap by capturing concrete adoption and performance data from real-world usage.

4. Lowering barriers for developer experimentation — One of the largest constraints to grassroots and professional developer growth is the cost/time required to produce a working Proof of Concept or prototype. NFTCDN’s free-tier access for 18 months could meaningfully reduce these barriers, enabling more developers to bring long-imagined projects to life and test market viability without the upfront infrastructure burden.

5. Reframing as R&D and ecosystem requirements gathering — Initially, I saw this as a private SaaS expansion play. After discussion with the proposer, I now see it as a development research and requirement validation initiative, where the output includes usage metrics, demand analysis, and integration feedback that can inform future infrastructure planning. This shift in perspective addresses my original concerns about vendor lock-in and sustainability.

6. Appropriateness of scope and cost — The budget request aligns with the scope of work and anticipated outputs. If the initiative delivers the expected adoption data, operational performance reports, and developer integration insights at this price point, it will represent good value for the treasury as an R&D investment.

For these reasons, I now support this proposal as a strategically relevant initiative to gather critical ecosystem data, lower developer onboarding costs, and inform future infrastructure funding decisions. While I still expect that future proposals evolve toward open-source, distributed governance models, the unique context of this first cycle and the concrete commitments from the proposer make this a worthwhile and timely investment.

For additional context and future reference I am leaving my original No vote rationale below as I am not entirely sure how the voting data and rationale relationships are maintained and would hate for any potentially relevant information to get lost.

Original No vote:

I am voting NO on this proposal, as it does not meet the standards for open, sustainable, and community-owned infrastructure that Cardano’s treasury should prioritize.

While content delivery for native asset metadata and media is a legitimate need, this solution is centralized, proprietary, and insufficiently transparent regarding both budget and long-term sustainability. Funding a single vendor to provide a non-critical CDN on a closed-source, commercial basis risks lock-in, undermines decentralization, and sets a precedent for treasury-funded private SaaS subsidies.

The proposal’s claimed cost savings and ROI are not supported by detailed technical or financial disclosures, and the reliance on a free period followed by uncertain pricing leaves projects exposed if future funding is denied or terms change. Additionally, current ecosystem adoption is limited, and similar functionality can be achieved with more open and competitively priced alternatives.

I encourage resubmission of a leaner, open-source, and community-governed proposal, developed transparently and collaboratively, before treasury support is reconsidered.

I am voting NO on this proposal to fund "High-yield RWA Asset for Cardano Tokenized Real Estate" with ₳3,000,000.

The proposal presents an exciting vision: onboarding a tested, tokenized US home equity protocol and a real estate-backed token (HausCoin) onto Cardano. However, this experiment comes at a high cost with many unresolved questions. The approach faces significant US/EU regulatory headwinds, must prove legal clarity for tokenized home equity, and lacks immediate, demonstrable ecosystem benefit. The business case is compelling but primarily future-focused, and Cardano’s treasury would assume extensive technical, regulatory, and adoption risk that should be managed and validated incrementally instead.

While I support real-world asset innovation, more risk-managed, modular, and transparent approaches are warranted before deploying treasury-scale funding for high-risk, long-horizon ventures. For these reasons, I cannot support the proposal as written.

This proposal is an important evolutionary complement to Project Catalyst, introducing a forward-thinking funding mechanism centered on extended quadratic funding, reputation-weighted voting, and transparent milestone accountability. It not only addresses existing Catalyst challenges such as concentrated voting power, protracted or uncertain milestone execution, and lack of visibility into project impact, but also pioneers new methods for community-driven, scalable innovation funding.

Crucially, the proposal recognizes that responsible ecosystem growth depends on robust research and iterative prototyping. Only by actively exploring alternative models and questioning established assumptions can Cardano continue to refine its governance and funding processes. This initiative supports exactly that by creating space to evaluate new options, better understand the types of problems we face, and uncover which questions we ought to be asking as the treasury evolves.

The team behind this proposal brings extensive experience from leading innovation platforms and blockchain development, reinforcing confidence in successful delivery. Financial oversight is strengthened through audited Sundae Labs smart contracts and multi-party governance, ensuring treasury security and accountability. All allocated funds flow directly to projects, maximizing real-world impact and eliminating operational overhead.

Mandatory standardized impact reporting sets a clear benchmark for transparency, enabling systematic learning from outcomes and making it possible to continuously fine-tune funding mechanisms based on real data.

Most importantly, the proposal encourages broader participation—from individual donors to major stakeholders—and invites the ecosystem to take shared ownership of its own evolution. By prototyping new models and gathering actionable insights, it ensures Cardano’s innovation funding toolkit can adapt and improve over time.

For these reasons, I recommend supporting this proposal as a critical step toward a more flexible, research-led, and collaborative approach to decentralized treasury management on Cardano—one that remains accountable, transparent, and open to continuous improvement.

I recommend voting YES on this proposal to fund the Cardano Builder DAO administered by Intersect with ₳12,000,000. This funding addresses a crucial gap in the Cardano ecosystem by providing dedicated, sustainable financial backing and strategic support specifically for live, user-facing dApps driving meaningful on-chain activity, TVL, and ecosystem engagement.

The project leverages proven governance infrastructure built on Clarity and Agora smart contracts, enabling transparent, member-driven decision-making and treasury management. The DAO structure complements Project Catalyst by focusing on the scale-up phase of projects rather than early-stage startup innovation, thereby ensuring both innovation and growth receive targeted support.

Robust treasury administration, including multi-party authorization and independent oversight, provides confidence in governance and fund security. Planned KPIs and milestone monitoring will permit clear tracking of projects’ impact and ROI.

Supporting application-layer projects is vital to growing Cardano’s user base, increasing real usage metrics, and driving the ecosystem towards mass adoption. This DAO proposes a scalable, community-aligned funding model essential for long-term ecosystem health and resilience.

I recommend voting NO on this ₳6,000,000 treasury withdrawal for the unified global events marketing strategy. While a coordinated global marketing approach to Cardano events is conceptually valuable, this proposal does not provide sufficient detail or justification to warrant funding at this scale.

The proposal lacks a granular marketing strategy with well-defined, measurable outcomes directly tied to ecosystem growth metrics. The budget is significant and not adequately broken down or clearly linked to demonstrable return on investment. The complexity of unifying multiple event marketing efforts requires strong coordination mechanisms and community buy-in, which the proposal does not sufficiently demonstrate.

Furthermore, transparency around community involvement and feedback in crafting and executing the strategy is limited. Without clear public involvement or structured co-creation, there is risk that the strategy may not align well with the diverse needs of Cardano’s decentralized ecosystem.

While the governance framework and treasury management are robust, these do not compensate for the strategic and operational uncertainties present.

A more detailed, community-driven, and outcome-focused marketing proposal with clear KPIs and modest budget ask would be needed before treasury funding can be recommended.

I vote YES on the Ledger App Rewrite Treasury Withdrawal.

This proposal tackles a longstanding usability and testing challenge in the Cardano Ledger App by redesigning the UI to conform with embedded app standards, improving user experience and maintainability. Vacuumlabs brings proven expertise within the Cardano ecosystem, demonstrated through their prior work on wallets and DEX platforms. The proposal outlines clear off-chain contract management with milestone-based deliverables, supported by third-party auditing and transparent on-chain budget tracking via treasury smart contracts. At ₳300,000, the funding is prudent and aligned with the scope, ensuring a vital infrastructure upgrade benefiting many Cardano users. Supporting this proposal advances ecosystem sustainability and developer tooling excellence.

I vote YES on the Dolos Treasury Withdrawal proposal.

Dolos fulfills a critical need by providing efficient, lightweight ledger data access essential for Cardano dApps’ scalability and ecosystem usability. TxPipe has a robust track record with open governance, transparent milestone reporting, and community contributions. The proposal complies with all constitutional guardrails regarding budget size, administration, and transparency, with multi-sig oversight and public audits. The requested funding aligns with deliverables and supports Cardano’s long-term developer infrastructure. This investment is both prudent and strategically aligned with Cardano’s growth objectives.

I voted YES on the Treasury Withdrawal proposal titled zkFold – ZK Rollup for Cardano (₳1,161,000), as it directly advances critical scalability goals for the Cardano protocol using state-of-the-art ZK cryptography.

zkFold proposes a fully general-purpose rollup that helps move dozens to hundreds of dApp interactions off-chain per transaction. This can unlock performance benefits that rival Layer 1 alternatives, while preserving the security guarantees of Cardano.

zkFold’s prototype validates that such execution fits within Cardano’s current Execution Unit limits—showing feasibility today, not years from now.

The vendor has provided well-defined roles, cryptographic infrastructure knowledge, and a realistic path to testnet. All disbursements are protected via audited smart contracts, milestone validation and delegated to the auto-abstain DRep. Governance is clear, secure, and reversible if milestones aren’t met.

I fully support this as a strategic, constitutionally compliant Infrastructure proposal, aligned explicitly with Cardano’s Basho-era scalability and ecosystem expansion goals.

I voted YES on the Treasury Withdrawal titled Lucid Evolution Maintenance (₳130,903) based on its vital role supporting frontend developers across the Cardano dApp ecosystem.

Lucid is the most widely adopted JavaScript/TypeScript SDK for building with Cardano smart contracts — providing capabilities like transaction assembly, metadata serialization, script formatting, and wallet communication.

Continued evolution of Lucid ensures smooth dApp operations and adoption of new features like Plutus V3 and Babel fees. This keeps developer experience competitive with other chains.

Anastasia Labs, the vendor, has a strong delivery track record, deep ecosystem contributions, and an open governance stance. They maintain the Lucid repo and over 50 other Cardano infrastructure packages.

Funds are disbursed constitutionally: held in smart contract escrow, guarded by an oversight committee (Sundae Labs, CF, NMKR, etc.), validated via milestones, and publicly transparent via IPFS metadata and on-chain multisig workflows.

Given Lucid’s prominence and the modest budget request, this proposal is a high-leverage investment in the tooling required to expand Cardano’s user and developer base.

I voted YES on the Treasury Withdrawal titled UTxO RPC: Sustaining Cardano Blockchain Integration requesting ₳220,914 based on its strategic importance, developer adoption, constitutional compliance, and cost effectiveness.

UTxO RPC provides crucial infrastructure for standardizing access to Cardano’s UTxO model using modern RPC endpoints, SDKs, and a shared schema language. This removes major onboarding and integration hurdles for both developers already building on Cardano (e.g. Lace, Mesh, Amaru) and those new to the ecosystem.

The proposal is well-scoped (0.625 FTEs) and continues TxPipe’s stewardship of one of the most pivotal light-client/public-access gateways in the Rust tooling landscape.

I also confirm administrative compliance and financial oversight using constitutional smart contract infrastructure (TRSC/PSSC), audited by trusted third parties (MLabs, Sundae Labs, TxPipe). All milestones are contract-governed, metadata-linked, and transparently enforced. This is especially fitting given that TxPipe itself contributed to auditing the underlying multi-signature framework.

UTxO RPC is a powerful ecosystem enabler and demonstrates the “invisible infrastructure” layer that modern blockchain platforms must deliver. I support this proposal as a constitutional Treasury action and recommend approval.

I voted YES on the Treasury Withdrawal titled Pallas – Sustaining Critical Rust Tooling for Cardano requesting ₳220,914.

Pallas is a critical piece of Rust-based infrastructure, used daily by protocol developers, explorers, wallet libraries, and tools like Aiken, Lucid, Mithril, and Amaru. This proposal sustains the library through dedicated engineering time and smart-contract-governed payments.

TxPipe is the original Pallas maintainer and has proven delivery capacity through Catalyst and open-source history. Their GitHub activity and engagement with the broader Cardano contributor community earn high marks on transparency and reliability.

Funding mechanisms use the TRSC smart contract framework with full moderated delivery assurance, milestone tracking, and public dashboards. All data is verified on-chain using metadata hashes and IPFS anchors.

Given Pallas’s widespread usage, developer importance, and vulnerability to protocol drift without support, I fully support this constitutional treasury withdrawal for a modest, proportionate amount. Sustaining this public good is aligned with Cardano’s roadmap and ecosystem health.

After a detailed review of the MLabs Research proposal titled “Tooling for Elliptical Curves – GrumpleStiltSkin”, I have voted YES based on the following considerations aligned with Cardano’s governance objectives and ecosystem priorities:

Critical Infrastructure for ZK and Cryptography:
This proposal addresses a significant gap in Cardano’s cryptographic tooling by enabling flexible, on-chain zero-knowledge proof verification over customizable elliptic curves. This capability is essential for expanding Cardano’s privacy, scalability, and advanced application potential.

Developer Usability and Security:
By delivering a flexible and developer-friendly YTxP-based interface in Plutarch, the project reduces the complexity and specialized knowledge required for application developers to leverage zero-knowledge proofs safely and effectively. This promotes broader adoption and reduces duplicated effort and security risks.

Alignment with Cardano Roadmap and Ecosystem Needs:
The tooling directly supports Cardano’s ambitions in zkApps and cryptographic sophistication, complementing ongoing research and protocol development efforts. It strengthens the foundation for future decentralized applications requiring advanced cryptography.

Reasonable and Transparent Scope:
The proposed budget of ₳104,347 for 600 hours of focused development, including project management and quality assurance, is modest and appropriate for the scope of work and specialized expertise required.

Strong Track Record of Vendor:
MLabs has demonstrated substantial commitment and expertise within the Cardano ecosystem, especially in Plutus, Plutarch, and advanced cryptographic research, providing confidence in timely and quality delivery.

Milestone-Based Disbursement & Oversight:
Funding will be managed through milestone-based payments enforced by smart contracts and overseen by Intersect with third-party assurance, ensuring accountability and transparency.

This proposal delivers clear technical value that directly benefits developers, applications, and the broader Cardano platform, sustaining Cardano’s leadership in blockchain innovation and cryptographic capabilities.

For these reasons, I endorse this proposal and encourage community support to enable its successful execution.

After a detailed review of the proposal titled "Withdraw ₳314,800 for PyCardano", I have decided to vote YES. This proposal directly supports the ongoing development and enhancement of PyCardano, a vital Python library that underpins many ecosystem tools, wallets, and applications. By funding this initiative, the community ensures:

Sustained Developer Support:
PyCardano offers an accessible, well-documented, and reliable interface for developers building on Cardano, improving overall productivity and lowering barriers to entry.

Ecosystem Stability and Growth:
Maintaining this key library helps secure developer workflows that rely on it for integration with Cardano’s ledger and transaction model, benefiting a broad scope of projects.

Alignment with Strategic Goals:
The proposal clearly aligns with the broader ecosystem objectives to support developer experience, tooling excellence, and mature software infrastructure critical to Cardano’s long-term health and innovation capacity.

Reasonable Funding Request:
The budget is proportional to the scope of work planned, supporting a focused effort by a qualified and proven team. The procedural framework includes milestone tracking and accountability, assuring that deliverables align with community expectations.

Supporting the PyCardano project through this proposal will help maintain a key piece of the Cardano development stack, fostering both innovation and reliability across many integrated solutions. Therefore, I fully support this proposal and vote YES.

After careful assessment of the "Withdraw ₳199,911 for OpShin - Python Smart Contracts for Cardano" proposal, I am voting YES based on the following considerations:

1. Strategic Alignment:
   The proposal promotes expanding the Cardano smart contract ecosystem by supporting OpShin’s development of Python-based smart contracts. Offering additional smart contract language support, specifically in a widely-used language like Python, directly aligns with Cardano’s goals to increase developer accessibility, adoption, and ecosystem growth. It enhances developer experience and lowers the entry barrier for smart contract development on Cardano.

2. Ecosystem Diversification and Inclusion:
   Supporting smart contracts beyond Plutus/VHDL/Haskell strengthens the network’s inclusivity and innovation capacity. Python’s large developer community and familiar programming paradigms offer a compelling opportunity for onboarding new developers into the Cardano ecosystem, potentially accelerating real-world dApp creation.

3. Technical Merit and Track Record:
   OpShin has demonstrated steady progress and a clear roadmap for continued Python smart contract development with sound technical foundations. The funding requested is aligned with achieving tangible milestones and delivering a production-ready toolset. This will enable broader developer engagement and ecosystem tooling expansion.

4. Reasonable Funding and Oversight:
   The requested withdrawal amount of ₳199,911 is appropriate for the scope and stage of the project. It reflects a responsible and proportional investment in the further development of essential programming infrastructure without undue risk or overlap with other funded efforts.

5. Transparency and Deliverables:
   The proposal sets forth clear deliverables, including secure smart contract execution, integration with existing Cardano toolchains, and comprehensive documentation. The progress will be verifiable within the governance framework and subject to the community oversight and milestone assurance protocols.

In summary, supporting OpShin's Python smart contracts development is a strategic step toward fostering a more diverse and accessible developer ecosystem on Cardano. It complements existing initiatives by enabling smart contract development in a broadly used programming language, ultimately accelerating Cardano’s mission for widespread blockchain adoption.

Therefore, I endorse funding this withdrawal and will vote YES.

After a thorough review of the Input Output Research (IOR) Cardano Vision - Work Program 2025 proposal and all supporting documentation, I am voting YES for the following key reasons:

Alignment with Cardano’s Strategic Roadmap and Vision
The proposal directly supports multiple priority areas in the 2025 Cardano Product Roadmap, including Developer/User Experience, Scaling the Layer 1 Engine, Architectural Excellence, Leios, Layer 2 Expansion, SPO Incentive Improvements, Multiple Node Implementations, Incoming Liquidity, and Programmable Assets.
The multi-year Cardano Vision research agenda underpins foundational scientific breakthroughs essential to Cardano’s sustained leadership in blockchain innovation, ensuring the ecosystem’s competitiveness and resilience for years to come.

Comprehensive, Evidence-Based Research Program
IOR proposes a rigorous, systematic research funnel delivering over 20 peer-reviewed academic papers annually, along with prioritized, technology-validated development streams. This methodical approach balances fundamental blockchain science with real-world technical validation, advancing both theory and practice, a critical capability unique and indispensable for Cardano’s ecosystem.

Experienced and Credible Team
Input Output Research has demonstrated extensive prior success with a track record of over 200 published academic papers and pivotal contributions to Cardano’s architecture and protocol innovations (e.g., Ouroboros consensus, Hydra, Mithril). The team includes multidisciplinary experts in distributed systems, cryptography, game theory, and formal methods, instilling confidence in delivery and quality.

Transparent Budget and Resource Allocation
The requested funding of approximately ₳26.8 million (USD $13.42M equivalent) covers 56 full-time equivalents spanning research, technology validation, administration, dissemination, and stakeholder engagement. This seems reasonable and proportional for the scope and impact of work outlined, especially given the high cost and complexity of blockchain R&D.

Community Engagement and Dissemination
IOR commits to robust communication and knowledge sharing with the broader Cardano ecosystem, including SPOs, developers, DReps, and committees. They aim to operationalize open frameworks for academic visibility, collaborative cross-team research, and public availability of insights and artifacts, thus maximizing ecosystem benefit.

Governance and Oversight
The proposal is under the appropriate oversight mechanisms, with designated administration and contractual safeguards aligned with Cardano treasury governance expectations, ensuring a structured, accountable execution process.

Risks Well-Considered and Mitigated
Dependencies between research streams and technology validation projects are acknowledged and managed within the proposal, reducing risk of bottlenecks. The focus on multi-year sustained funding further mitigates resource continuity risk which is essential in complex academic research cycles.

Summary:
Input Output Research’s Cardano Vision program for 2025 is a vital, strategic investment in Cardano’s long-term technical foundation and market leadership. By advancing cutting-edge scalable consensus protocols, novel cryptographic constructs, governance innovations, and interoperability research, it ensures that Cardano stays at the forefront of blockchain technology evolution. The proposal is well-aligned with community priorities, fiscally sensible, and backed by a proven team committed to rigorous academic standards and ecosystem transparency. I support its funding to maintain Cardano’s path of unparalleled research-driven progress.

After careful review of the proposal requesting ₳4,000,000 ADA for expanding stablecoin and Cardano native asset support, I have decided to vote NO due to multiple fundamental concerns around clarity, accountability, and overall value for the Cardano ecosystem.

Key Concerns:

Lack of Clear Scope and Deliverables
The proposal’s problem statement accurately identifies real challenges in stablecoin infrastructure, wallet and custodian support, exchange liquidity, and fiat ramps, which are critical for Cardano’s broader adoption and DeFi growth. However, the proposal itself is vague about what exactly will be built or improved. There is no clear, detailed roadmap or description of the technical solutions, no specific milestones, and no defined metrics for success. It reads more like high-level aspirations than a concrete development plan.

Unclear Accountability and Governance
It is not clearly stated who the primary developers are or the structure of the team executing this work. The contractual relationship with the treasury is nebulous, leaving open questions about intellectual property rights, ownership of outputs, maintenance responsibilities, and ongoing support. There is no clear indication if this is a grant, a service contract, or another form of funding. Without defined governance or stewardship, it is difficult to evaluate how the community’s investment will be managed or safeguarded over time.

Ambiguous ROI and Value to the Ecosystem
Given the significant treasury allocation requested (₳4 million), the proposal lacks convincing justification on return on investment (ROI) for the Cardano ecosystem. There is no roadmap on sustaining or scaling the work post-initial spend or how it enhances decentralization, public good infrastructure, or developer/community engagement. The benefits appear uncertain and unspecific, undermining confidence in the effective use of treasury funds.

Potential Conflict of Interest and Limited Ecosystem Benefits
The proposal seems aimed primarily at supporting a single company’s stablecoin project (USDA and its infrastructure). Treasury funds should preferentially support open, public-good infrastructure benefitting the entire Cardano ecosystem, rather than subsidizing individual commercial interests. The proposal does not clarify how it ensures open access, interoperability, or contributions back to the ecosystem beyond the funded entity.

Community and Governance Alignment
The proposal lacks a defined framework for community involvement, decentralization of control, or mechanisms for transparent reporting and accountability. This is misaligned with Cardano’s governance principles emphasizing inclusive, open, and community-driven development.

Alternative Funding Sources and Risk Mitigation
Stablecoin infrastructure projects, especially those of a commercial nature, should ideally attract private sector investment or revenue-driven funding. The high-risk profile and commercial orientation of this proposal make it more appropriate for venture capital or token sale funding rather than community treasury support. Without mechanisms for value recycling or return to the treasury, it risks weakening long-term ecosystem financial sustainability.

Summary:
While the overarching problems this proposal seeks to address are legitimate and important for Cardano’s growth, the proposal’s lack of specificity, unclear accountability, possible commercial conflicts of interest, and poor governance alignment compel me to vote NO. I recommend resubmission with detailed technical scope, clear governance and IP frameworks, transparent budgets with defined milestones, and stronger demonstration of public-good benefits and ecosystem ROI. This will enable informed, confident community support aligned with Cardano’s decentralized vision and responsible treasury stewardship.

I voted YES on the Treasury Withdrawal titled Hardware Wallets Maintenance (₳424,800), which ensures the continued upkeep of Ledger, Trezor, and Keystone hardware wallet integrations within the Cardano ecosystem.

This proposal is critical to Cardano’s security infrastructure and user confidence in self-custody: without it, wallet users may not be able to sign transactions or interact with core protocol features in upcoming Cardano releases.

Vacuumlabs, the vendor, has maintained these integrations since 2018 and remains the lead engineering team behind the cardano-hw-cli and firmware adaptations across both Ledger and Trezor.

The proposal is administered under a formal legal contract through the CDH, using Treasury Reserve Smart Contracts (TRSC) developed by Sundae Labs. Fund disbursement is milestone- and metadata-gated and coordinated via an external 3rd party assurer and community-visible dashboards.

This funding ensures hardware wallet users remain compatible with new roadmap features (e.g. Babel Fees, Nested Transactions, CIP-68), and that certified audits (required by Ledger) are performed.

I affirm this proposal’s alignment with the 2025 Ecosystem Budget Info Action, its Ekklesia vote threshold of 3.43B ADA, and strongly support this critical infrastructure work.

I vote YES on this proposal to fund the Cardano Summit 2025 and associated regional tech events.

The Cardano Summit series has long been a cornerstone in the ecosystem, serving as a critical platform where developers, community members, enterprises, regulators, and other stakeholders converge to share knowledge, foster collaboration, and accelerate Cardano’s adoption globally. The 2025 proposal builds on this legacy with a hybrid model: one flagship global summit in Europe alongside four regionally focused events—in the US, Africa, LATAM, and Asia—to expand reach and enhance local engagement.

This initiative directly supports several of Cardano’s 2025 roadmap priorities: driving developer onboarding through targeted Dev Days and hackathons; showcasing real-world applications; strengthening community and governance dialogue; and attracting capital, talent, and media attention.

I appreciate the strong consortium of co-host partners bringing deep regional expertise and proven event management capabilities. The plan’s clear KPIs for attendance, speakers, and sessions provide measurable milestones for success. I also welcome the ongoing efforts to establish a dedicated Summit Steering Committee and evolving financial models aimed at growing sustainability over time.

However, I have some questions and concerns that must be addressed as the initiative progresses:

Clarification is needed on the ownership and governance relationship between the Cardano Foundation and the broader ecosystem with respect to these events, including intellectual property, trademarks, and contractual responsibilities.

The average attendance figures, while meaningful, may not fully capture the Summit’s ecosystem impact; more granular KPIs reflecting post-event developer engagement, ecosystem contribution, and project growth would strengthen accountability.

I further seek transparency on detailed cost breakdowns for each event and how treasury funds translate directly into ecosystem expansion beyond event execution.

Community participation and inclusivity should be prioritized to ensure these remain accessible public goods, allowing broad ecosystem representation without pay-to-play barriers.

Additionally, I acknowledge some DReps voice concerns about the combined funding of flagship and regional events as a single proposal, the scale relative to alternative outreach approaches, and the shift of funding responsibility from founding entities to the treasury.

In summary, I support this funding request as a necessary strategic investment in Cardano’s global growth and ecosystem development, recognizing the Summit’s unique role as an onboarding and collaboration hub. Simultaneously, I emphasize the need for ongoing transparency, community involvement, and clear demonstration of the value these events deliver to maximize treasury efficiency and long-term ecosystem benefit.

I am voting NO on this proposal. The decision is based on budget scale, detail, operational transparency, and the type of oversight presented in the proposal and relevant supporting links.

1. Size of Funding Request and Budget Specificity
   The proposal requests ₳15,750,000 for a 12-month period to fund Intersect’s role as an Administrator and ecosystem MBO.

The written proposal refers readers to external supporting CSV and PDF files for operational budget detail, rather than providing this information in the main governance action text.

According to information in those supporting files, major expenses are attributed to personnel (approx. 45 roles at an average of $100,000 each), with some line items for board compensation and “Board Services,” but job roles, responsibility mapping, and cost justifications are not detailed in the proposal itself.

1. Transparency and Oversight
   The proposal describes oversight via an off-chain legal contract, the Cardano Development Holdings entity, and milestone tracking with third-party assurer review.

It is not clear from the proposal documentation how compensation, operational decisions, or board activities are communicated to or approved by the broader Cardano community, or how board members are selected, compensated, or held accountable.

1. Scope of Organizational Role and Treasury Funding
   Intersect’s remit as described includes core node repo stewardship, upgrade coordination, committee facilitation, and Administrator role execution.

The budget requested is significantly larger than for most other Cardano proposals reviewed, including those funding technical or development initiatives.

The proposal does not specify contingency plans if Intersect is not funded.

Conclusion:

Based on the information provided, I do not find the current proposal demonstrates the necessary transparency or detailed justification for a ₳15,750,000 treasury withdrawal. The operational scope, budget, and oversight mechanisms as documented do not provide sufficient clarity for this scale of community funding. Additional clarity on organizational structure, budgeting process, and community accountability is needed before considering future support.

I vote YES for the ₳212,000 treasury withdrawal to fund AdaStat.net, a proven, independently maintained, and open-access Cardano blockchain explorer.

AdaStat offers vital real-time access to chain data, governance activities, stake pool performance, REST API integration, and a mobile-ready, fast UX/UI—all provided continuously for over five years.

Maintaining a diverse set of independently operated explorers is crucial to preserving Cardano’s decentralization, transparency, and network resilience. AdaStat’s focus on open standards, governance data, and broad community utility (SPOs, DReps, CC, developers, and end users) aligns directly with Cardano’s core values.

The budget is reasonable for 24 months of technical development, performance upgrades, and operational support, representing high value for sustaining ecosystem-critical infrastructure. Project delivery and risk are well managed via a milestone-based legal contract, treasury multisig, Oversight Committee, and 3rd-party assurance.

AdaStat’s independent operation helps mitigate single-point-of-failure risk, broadens community tooling, and increases accessibility of Cardano’s data to the global community, underpinning growth and adoption.

I voted YES on the Treasury Withdrawal titled Blockfrost Platform Community Budget Proposal (₳1,300,000) based on its strong support during the Ekklesia budget phase (3.18B ADA voting in favor) and full compliance with Article IV of the Cardano Constitution.

This proposal supports the Icebreakers Era, an evolution of the Blockfrost API from centralized backend to an open-source, SPO-powered infrastructure layer. By allowing trusted community node operators to run profitable Blockfrost endpoints and route traffic via the Gateway system, the platform decentralizes API access and empowers SPOs directly.

The technical controls around funding meet or exceed expectations:

Funds administers via audited smart contracts (Sundae Labs)

Fund flows executed only after legal contracts + milestone approval

Protected by a multisig oversight committee, and non-staking "auto-abstain" modeling

Strategic benefits of this funding include enhanced access for dApp and mobile developers, enterprise-level private deployment (Solitary mode), and ADA-based micro-payment APIs using Hydra settlement channels.

The ₳1.3M budget is proportionate and compares favorably with infrastructure proposals of similar scope. All code will be open-sourced, ensuring zero vendor lock-in. I recommend approval of this proposal to ensure robust, sovereign API access for Cardano while supporting SPO viability and decentralization goals.

I vote YES on the treasury withdrawal for ₳266,667 to support Cexplorer.io, a critical and high-usage blockchain explorer providing Cardano developers, stake pool operators, and the broader community with real-time, detailed blockchain insights. The proposal's continuous maintenance and planned enhancements ensure that Cexplorer remains reliable, scalable, and equipped with advanced features tailored to ecosystem needs.

The vendor team brings solid, proven experience in backend and frontend blockchain infrastructure with specific Cardano knowledge and architectural expertise. The contract management embeds clear milestones and acceptance criteria, with third-party milestone assurors and community transparency supported on-chain via Sundae Labs treasury smart contracts.

The budget request is reasonable for operational continuity and planned expansions, with a strong value proposition in maintaining critical infrastructure that underpins ecosystem transparency and developer productivity. Cexplorer.io’s position as a trusted platform with significant monthly user engagement highlights its importance.

The governance framework around contract delivery, treasury management, and oversight committee controls adequately mitigate risks related to execution and fund management.

Approval of this proposal will sustain and grow a foundational tool that directly benefits Cardano’s developer experience, staking community, and research efforts — integral to Cardano’s ecosystem health and growth.

I vote YES to the treasury withdrawal proposal for ₳657,692 in support of the Scalus DApps Development Platform.

This platform aims to streamline and unify the Cardano smart contract and DApp development experience through Scala 3, offering a consistent tooling ecosystem that covers the full development lifecycle—from setup to deployment.

Given the steep learning curve and fragmented toolsets currently discouraging developer onboarding, Scalus addresses a significant bottleneck by bridging traditional Scala/Java/Kotlin developer expertise with the Cardano ecosystem’s needs. Such unification has the potential to reduce time-to-market, improve code safety, and tap into a wider talent pool — all critical factors for Cardano's scaling and enterprise adoption goals.

The vendor brings relevant domain expertise as a former IOG engineer familiar with Cardano’s FP and blockchain ecosystem, enhancing confidence in delivery. The proposal includes a well-defined contractual plan with milestones, third-party milestone acceptance, and robust governance and treasury oversight, ensuring risk is managed and accountability ensured.

The budget aligns reasonably with the scope of work for betting on a scalable development platform aimed at improving ecosystem inclusivity and productivity. Transparency measures and governance compliance are fully in place.

Approval will support expanding Cardano’s developer base through a production-ready, unified development platform designed for professional and business teams, thus fostering innovation and adoption.

I vote YES on the treasury withdrawal proposal for ₳583,000 to maintain and sustain Eternl, a core user wallet infrastructure for Cardano.

Eternl has demonstrated consistent operational and technical capability since 2021, supporting a wide range of users across platforms.

The proposal seeks operational funding necessary to cover mature, steady-state maintenance costs, critical for ensuring ongoing security, reliability, and compatibility within the Cardano ecosystem. Maintaining a high-quality wallet infrastructure facilitates user retention, network participation, and developer integration, which are vital for long-term ecosystem health.

The governance framework ensures accountability and transparency via a legally binding contract with clear milestones, third-party milestone assurance, and audited on-chain treasury tooling managed under a multisig and Oversight Committee to reduce risks of fund mismanagement.

The requested budget is consistent with industry norms for sustained maintenance of essential software services. Approval will preserve a key gateway for Cardano's users and developers, supporting continued platform growth and adoption.

This treasury withdrawal proposal aims to develop a zero-knowledge (ZK) bridge for Cardano to enable modular, trustless interoperability with other blockchains via a zk-proof-based communication protocol. While interoperability is a critical area for Cardano, this proposal currently focuses on a testnet proof-of-concept limited to the Cardano side, without specifying targeted partner chains or a clear path to mainnet deployment.

Key concerns influencing this no vote include:

Lack of Concrete Scope and Deliverables: The proposal provides high-level architectural goals but lacks detailed implementation plans, timelines, and defined milestones that concretely demonstrate progress towards production-ready, mainnet-capable infrastructure.

Unclear Integration and Differentiation: There is insufficient engagement with or clear distinction from other ongoing Cardano initiatives, such as Hydra, zkRollup efforts by zkFold, Tweag's Layer 2 tooling, Midgard, and other ZK proof research. This raises risks of redundancy or fragmented ecosystem efforts.

Budget Concerns: The ₳700,000 request is substantial for a preliminary, testnet-only PoC lacking demonstrated immediate ecosystem impact or user-facing integration. The proposal indicates reliance on further grant funding beyond this phase, creating uncertainty about scope control and deliverable accountability.

Open-Ended Development and Audit Risks: Essential activities such as smart contract audits, mainnet readiness verification, and security assessments are explicitly out of scope, implying significant additional future costs with no clarity on funding or delivery guarantees.

Vendor Experience Relative to Proposal Needs: Although the vendor demonstrates strong cryptographic and zero-knowledge expertise, their recent Cardano-specific deployment experience on cross-chain ZK bridges is limited.

Governance and Oversight Good Practices: The proposal meets governance requirements with clear contract management, milestone tracking, on-chain metadata, and multi-party treasury oversight, which reduces administrative risks but does not fully compensate for the substantial strategic and technical uncertainties.

Given these factors, this proposal’s risks and ambiguities outweigh the potential benefits at this stage.

A vote of no is warranted pending a future, more detailed, and tightly scoped proposal with clearer production plans, integration strategies, phased funding, and audit milestones.

I vote YES on this treasury withdrawal request for ₳11,070,323 supporting TWEAG’s multiple core budget projects for Cardano in 2025.

This suite of initiatives represents a comprehensive and strategically critical investment in Cardano’s foundational infrastructure—ranging from ledger state management, conformance testing, synchronization improvements, to tooling and node emulator development.

TWEAG by Modus Create brings deep domain expertise and a proven track record with Cardano’s core protocol and ecosystem. The proposal outlines robust administrative oversight via milestone-driven legal contracts, third-party assurance, and on-chain metadata transparency executed under a treasury management system. The requested budget aligns realistically with the broad and impactful scope of work. The anticipated benefits include enhanced protocol reliability, improved developer and operator workflows, faster network upgrades, and better overall ecosystem resilience.

Approval of this proposal supports critical foundational improvements essential for Cardano’s scalability, security, and long-term sustainability.

I vote YES on the ₳243,478 treasury withdrawal for MLabs’ ongoing maintenance and enhancement of the Plutarch smart contract eDSL.

Plutarch serves a foundational role in the Cardano ecosystem as a trusted, production-ready Haskell-based tool for writing secure, efficient smart contracts. This maintenance-focused proposal responds directly to the need for sustained investment in Cardano core tooling — including patching, updates for hard forks, feature improvements, and user-requested enhancements.

The vendor has a strong stewardship record for Plutarch and related infrastructures. The proposal is structured around milestone and metadata-based delivery, subject to third-party assurance, with funding routed through open, on-chain governance tooling. This proposal offers a high return in developer productivity, tooling quality, and protocol readiness relative to the cost and fits within the 2025 budget plan.

Maintaining Plutarch improves long-term resilience and helps retain developers within the ecosystem.

I vote YES on the Gerolamo treasury withdrawal proposal for ₳578,571 to support the development of a fully functional Cardano node in Typescript, capable of running in-browser.

This capability fills a vital infrastructure gap in the Cardano ecosystem, greatly enhancing developer accessibility and enabling scalable, decentralized applications to function independently of centralized backends. Gerolamo allows dApps and wallets to trustlessly access ledger data from within the browser, reducing reliance on hosted nodes and making light clients more runtime- and user-friendly.

The proposal is built around milestone-linked disbursements handled under a legally binding contract with external milestone assurance. Funds will be distributed through audited treasury smart contracts subject to community verification, with metadata and governance artifacts made public.

Given the initiative’s unique value to ecosystem scalability and its alignment with long-term decentralization goals, this proposal warrants approval.

I vote YES on the OSC Budget Proposal – Paid Open Source Model treasury withdrawal.

Cardano’s open-source ecosystem is fundamental to the security, reliability, and continued innovation of the network. This proposal implements a structured funding model that directly targets longstanding needs for maintainability, bug bounty funding, onboarding new contributors, incident response, and sustained development of foundational code, tools, and documentation across the ecosystem. The outlined programs – including a Maintainer Retainer, developer onboarding tracks, and security initiatives – are broad in scope and essential for ecosystem health. The funding mechanism is staged, uses milestone-based contracts, and is subject to community monitoring and external third-party oversight. All treasury operations tied to this proposal are transparently managed on-chain with public compliance to Cardano governance requirements. The total requested amount is commensurate with the scope and the historical scale of under-resourcing for critical open source in Cardano.

Approval of this treasury withdrawal supports a predictable and transparent approach to building a sustainable open-source foundation for Cardano.

I vote YES on the Maestro Treasury Withdrawal proposal to fund the development of a comprehensive Web3 developer stack dedicated to positioning Cardano as the smart contract and DeFi layer for Bitcoin.

This strategic project addresses a critical ecosystem need by enabling Cardano to tap into Bitcoin’s considerable liquidity and user base through robust infrastructure including blockchain indexing, mempool monitoring, event notifications, and wallet management. Maestro demonstrates strong capability with an established track record delivering infrastructure for key Cardano projects and integrations. The proposal includes clear legal contract frameworks with milestone-based deliverables, backed by 3rd party assurance, governed transparently via treasury management smart contracts.

The requested ₳600,000 budget is well justified relative to the project's scope and impact, employing rigorous audit and oversight processes.

Supporting Maestro will substantially enhance Cardano’s smart contract ecosystem, developer experience, and overall ecosystem growth.

I voted YES on the Treasury Withdrawal titled "MLabs Core Tool Maintenance & Enhancement: Cardano.nix" (₳45,217) after reviewing all submitted materials.

The Administrator is clearly named and this proposal is governed by a milestone-based off-chain contract with Cardano Development Holdings, including independent milestone review, 3rd-party assurance, and transparent delivery schedules. Disbursements are executed through a thoroughly audited smart contract system that prevents unilateral control and ensures community oversight.

The proposal itself delivers critical maintenance for the Cardano.nix deployment framework, a widely-used open-source tool for reproducible infrastructure builds across the Cardano ecosystem. Cardano.nix underpins deployment pipelines used by both community and IOG/Daedalus node operators, and this funding ensures consistent upgrades, bug fixes, and developer experience improvements.

MLabs is an experienced and trusted vendor with a proven track record. The requested amount is proportional to the scope and essential to maintaining infrastructure readiness in Cardano’s growth and governance phase.

For these reasons, I support this Treasury Withdrawal and recommend affirmative votes from all DReps committed to Cardano’s stability, open tooling, and infrastructure maturity.

After a thorough review of the “Withdraw ₳99,600 for BloxBean Java Tools Maintenance and Enhancement” proposal, I am confident this is a strategically important initiative that directly supports the stability, usability, and growth of the Cardano ecosystem.

BloxBean’s Java tooling is a critical part of the developer infrastructure, widely used by Cardano developers, explorers, and enterprise integrations. Maintaining and enhancing these tools ensures Cardano has a robust, production-ready set of Java libraries and developer kits that improve integration, adoption, and interoperability.

Key reasons to support this proposal include:

Alignment with Cardano Roadmap:
This maintenance work supports ongoing ecosystem development goals by improving tool reliability and compatibility with the evolving Cardano protocol and node upgrades.

Ecosystem Impact:
Reliable Java tooling reduces barriers for developers and enterprises building on Cardano, facilitating faster development cycles and enabling more sophisticated applications.

Demonstrated Track Record:
BloxBean has a proven history of commitment and contributions to Cardano’s development stack, indicating competence and reliability.

Reasonable Funding:
The requested amount (~₳99,600) is proportionate for the scope of ongoing maintenance and targeted enhancements, representing good value for sustaining essential infrastructure.

Transparent Oversight:
The proposal includes milestone-based funding releases with delivery assurance and public reporting, ensuring accountability and effective use of funds.

Overall, this proposal is a sound investment in Cardano’s developer ecosystem, promoting a robust and accessible toolchain that benefits developers, projects, and the wider adoption of the platform. I vote YES to approve the disbursement.

I have supported the Amaru proposal at every stage of the process and see no reason to change my stance at this point. Accordingly, I have voted YES on this proposal.

As a side note, I find this to be one of the most well thought out, comprehensive, and detailed proposals I have reviewed to date. It sets a high standard for future submissions, and I hope other proposers will follow this format and level of detail.

DRep Vote Rationale: NO on the 2025 Cardano Ecosystem Budget Proposal

After a thorough review of the proposal and supporting documentation—including previous submissions and public statements from IntersectMBO—I have decided to vote NO on this Budget Info Action. My decision is based on both practical and fundamental concerns.

1. Budget Size Exceeds Responsible Limits

The total budget request of 275,269,340 ADA exceeds the maximum amount I am willing to allocate for the 2025 budget by over 75 million ADA. In my view, this level of spending is not justified by the current needs or the demonstrated capacity for effective, transparent delivery. Fiscal responsibility is paramount, especially when drawing from the Cardano Treasury, and this proposal does not meet that standard.

1. Governance and Process Concerns
   A. Lack of Pre-Vote Compliance Checks

• No administrative or compliance vetting was performed by IntersectMBO or its committees before DRep voting. All 194 proposals were left for DReps to review, with no assurance that proposals were KYC/KYB compliant or met other eligibility criteria.

• This means DReps could approve proposals that are later blocked by Intersect at the administrative stage, wasting community effort and undermining the legitimacy of the DRep vote.

B. Centralization and Administrative Discretion

• Only proposals that named Intersect as their Administrator were included in this budget action. Proposals that chose to operate independently or through other means were excluded, regardless of merit or community support.

• Intersect reserves the right to decline or withdraw as Administrator after DRep approval based on post-vote compliance checks, with no clear appeals process. This creates a risk of centralized, discretionary veto power over community-approved proposals.

1. Inclusivity vs. Member-Centric Practice

• IntersectMBO’s stated mission is to bring together the entire Cardano community, including non-members. However, in practice, their approach privileges entities and individuals who are aligned with or pay for Intersect membership and services.

• The proposal requests 15.75M ADA for Intersect’s own operations as a “member-based organization,” funded from the public treasury rather than membership dues.

• This model grants Intersect the benefits of a private administrator—control, funding, and authority—without the risks, competition, or accountability expected of a private business, especially when using public funds.

1. Transparency and Accountability Gaps

• No clear, published criteria for compliance or due diligence are provided before DRep voting, nor is there a transparent process for proposers to appeal declined administration decisions.

• While smart contract escrow and multi-signature oversight are positive steps, the ultimate administrative authority remains centralized with Intersect.

Conclusion

While I appreciate the effort to coordinate a community-driven budget process, this proposal falls short in several critical areas:

• It exceeds a fiscally responsible budget limit,
• Lacks adequate pre-vote compliance screening,
• Concentrates administrative power and funding within a single, member-centric organization,
• And fails to provide the transparency and accountability necessary for true decentralized governance.

For these reasons, I cannot support this Budget Info Action and have cast my vote as NO. I encourage the community and IntersectMBO to address these concerns in future funding cycles to ensure Cardano’s governance remains open, inclusive, and accountable to all stakeholders.

I voted for each of these submissions individually while processing the 190+ proposal 'survey' presented through the Ekklesia website. I see no reason not to support them directly through this info action to ensure they receive appropriate support, just in case they don't pass while being included in a separate bundled proposal.

I have therefore voted YES to this proposal.

I believe that node availability, accessibility and diversity is not only critical for ecosystem growth but also a key component to mass adoption.

I picture a time, in the not too distant future, where nodes will have the ability to run on any and all connected devices. Imagine, a smart fridge having the ability to run a node and generate income, used to pay for its own groceries, that are automatically reordered as needed, through both a blockchain enabled farmer-direct ordering app and delivery service. That would be something to see.

It is on this basis that I have voted YES to this proposal.

I have already voted for what I believe is the most appropriate NCL given the available information. Additionally, there is also now an issue of missing or altered Data, post submission, associated with this proposal.

For these reasons, I have voted NO to this proposal.

Data integrity is critical to maintaining every aspect of an integrated system, especially with regards to it's governance. An ecosystem as diverse and interconnected as Cardano's, cannot be managed, maintained and expanded without a concrete and reliable foundation for data.

While the proposal itself may be sound, due to the fact that data associated with this info action is missing or altered, post submission, I am not able to support this proposal and have voted NO.

Given the current state of the Cardano ecosystem, I believe the proposed NCL amount is a far more practical option compared to previous iterations presented thus far.

While a 200M NCL leaves little room for anything beyond core research, development, and operations in 2025, I am convinced this focus is precisely where our attention should be in the short to medium term.

As a community now fully responsible for the direction, scale, and pace of the ecosystem’s expansion and evolution, we must ensure a robust and comprehensive framework of policies, procedures, infrastructure, and auditing is in place before allocating significant resources to areas we are currently unprepared or unable to support.

This approach should be a priority across all areas of the ecosystem but is particularly critical for administration, governance, and funding, which currently lack substance, quality, and transparency.

While I understand that setting a Net Change Limit does not mean it is necessary to spend the maximum amount specified by that limit, I have, however, seen this exact scenario play out repeatedly over the years. A higher potential for covering expenses, inevitably leads to higher expenses. Also, I feel it would be irresponsible to to set the 2025 NCL to the entire projected yearly treasury income.

It is for these reasons that I am voting NO to this proposal. I feel that a 350M NCL is excessive and is not beholden to a fiscally responsible approach and would incentivize unnecessary and unneeded spending.

While I am willing to reluctantly agree to the Net Change Limit proposed for 2025, it is at the upper boundary of what I'd currently accept as a yearly spending cap.

Beyond the 2025 amount, I am opposed to the remainder of the proposal. In my view, it is short sighted and irresponsible to attempt to set an amount for 2026. None of us have any idea what is going to happen from one week to the next, so trying to anticipate the state of affairs in the blockchain ecosystem in general and Cardano's state of development and adoption specifically, 9 months from now and setting a 2026 NCL, is an exercise in futility.

I am willing to agree to this proposal for three specific reasons.

1. The knowledge that I will oppose any budget that allocates more than 75% of the NCL to the 2025 budget with the final 25% remaining for unforeseen opportunities and emergency reserves.
2. The ability to change the NCL once its minimum timeframe has elapsed, which will occur before a 2026 NCL is required.
3. Lack of any other valid option.

With that being said, I am voting YES to this proposal based solely off of the amount proposed for 2025; however, if a more appropriate proposal is submitted before this proposal's end date, I will happily reevaluate my position and assign my support to the most feasible and fiscally responsible proposal.

In my opinion, research and development are paramount as we move forward. The product committee's 2025 roadmap proposal clearly articulates the necessary foundational upgrades and expansions required to remain at the forefront of blockchain innovation. I believe this is a well-thought-out and comprehensive proposal for the upcoming year, and have initially voted yes. I will continue to monitor changes to the roadmap until voting closes on March 30 but baring any substantial contradictory additions, my initial vote will stand.

At present, I see no justification to adjust any network parameters.

Until such time that Cardano realizes it initial vision with all network and support structures being completed or there are unforseen, extenuating circumstances introduced that threaten Cardano's existance, I will vote no to any and all parameter changes.

My development approach remains the same - First make it work, then make it pretty, then make it popular, then make changes.

I am voting YES on “Hard Fork to Protocol Version 11 (‘van Rossem’ Hard Fork)” because it is a focused intra‑era protocol upgrade that improves Plutus performance and capabilities, strengthens ledger correctness, and enhances node diagnostics, while keeping the ledger in the Conway era and preserving transaction shape. The action adds useful new Plutus built‑ins, unifies built‑in availability across Plutus versions, and introduces case expressions in UPLC, which together reduce execution cost and extend what builders can do on‑chain.

It also enforces VRF key hash uniqueness, clarifies reference input rules, promotes the Constitutional Committee voting restriction into a formal ledger predicate, and improves PPView mismatch reporting, all of which contribute to more robust and transparent consensus and governance behavior. The hard fork is contingent on at least 85% of active stake pools upgrading to a compatible node and has been recommended by Intersect’s Hard Fork Working Group and Technical Steering Committee, which satisfies my requirements around readiness and technical review for protocol changes.

I am voting NO on “Eternl – Path to Sustainability – v2”. Eternl is an important Cardano wallet and governance interface, and I recognise the value of its infrastructure and long‑term contribution. However, this proposal again seeks a full year of broad operations funding for a closed‑source, commercial product that has already received substantial public support through Catalyst, Intersect, and the 2025 Treasury withdrawal.
The added audit and oversight clarifications in v2 improve transparency but do not change the fundamental structure of the ask: the Treasury is being asked to bridge general business risk while Eternl transitions to a paid Pro model, with conditional repayments and donations priced in fiat. In my view, repeated Treasury support for private products should be limited to clearly scoped public‑good maintenance work—such as hard‑fork readiness, CIP implementation, and governance‑critical compatibility—and should be accompanied by stronger open‑source commitments, not full commercial operations. For these reasons, I am maintaining my previous NO stance on this family of proposals.

I am voting YES on “Reimburse Ikigai Info Governance Action Deposit” because it is a narrowly scoped, corrective withdrawal that reimburses 100,000 ADA lost due to a documented node bug affecting an early Info governance action, with a modest 3,000 ADA top‑up to approximate missed staking rewards. The proposal is transparent, constitutionally compliant, and sends funds directly to the original submitter without administrator custody or additional overhead, which makes it a simple and proportionate way to resolve a long‑standing issue and reinforce trust in Cardano’s governance system.

I am voting NO on “Strike Finance Liquidity Deployment.” Strike is one of the stronger live DeFi products on Cardano, with meaningful trading activity, user traction, and a credible case that deeper liquidity could improve execution and keep more derivatives activity inside the ecosystem. The proposal is also more thoughtfully structured than many treasury investment-style requests, with independent multisig custody, monthly reporting, 6-month yield distribution, 12-month return of principal and realized yield, and defined review and wind-down triggers.

However, this proposal still asks the treasury to sell 9,000,000 ADA into USDM and take protocol, custody, stablecoin, execution, and opportunity-cost risk for a protocol-specific liquidity deployment. In my view, positions of this type should sit inside a clearly defined active-management treasury sleeve with formal portfolio rules, exposure limits, benchmarks, and public monitoring tools, rather than being approved one by one as isolated withdrawals. Strike may be a strong candidate for such a framework in the future, but I do not think the current treasury structure is mature enough to support this kind of deployment responsibly, so I am voting NO.

I am voting NO on “Reforming Treasury Governance” because, while I agree with many of the concerns it raises and with the proposed multi‑domain budget structure, I do not support the introduction of a single strategic entity and an appointed expert commission as the core mechanism for treasury governance reform. My view is that Cardano should move toward wider, more direct participation, where community members self‑organize into domain‑specific expert groups and vote on proposals they are uniquely qualified to assess, rather than centralizing strategic direction and project selection in a small set of appointed bodies.

I see DReps as an important intermediary in the current phase of governance, but not as the endpoint of Cardano’s decision‑making model. Although I share the proposal’s concerns about NCL‑centric thinking and domain competition, I cannot endorse this particular implementation path and will instead focus on approaches that keep strategic and evaluative power distributed across the community.