Dori

I'm voting Yes on the MLabs Core Tool Maintenance & Enhancement: Plutarch and Ply proposal.

I've consistently held that treasury funds should go first to infrastructure that is specific to Cardano and that the market won't replace on its own. Plutarch and Ply are exactly that kind of tooling. They are open-source smart contract tools built specifically for Cardano's eUTXO and UPLC, and they're already used in production by a number of teams.

If these tools aren't continuously maintained as the protocol evolves, the teams building on top of them get exposed to migration and rewrite risk. In other words, this isn't a proposal that creates new spending. It's maintenance that keeps an existing ecosystem asset from breaking.

I am voting Yes on the Withdraw 1,310,960 ada for Hardware Wallet Maintenance 2026 proposal.

This proposal is a small budget to maintain that compatibility layer for twelve months, and I support it because it secures the continuity of an already-proven access layer rather than building a new product.

The timing is also appropriate, given that protocol changes such as the recent Van Rossem hard fork are exactly what tends to break this compatibility.

Since this maintenance is not a company's commercial product but public signing infrastructure that everyone relies on, I consider Treasury support justified at this stage.

That said, this Yes does not assume open-ended subsidy.

As this item has already received Treasury funding several times, I believe the level of support should be reviewed if future requests grow excessively, and that over the long term it should transition toward the vendor and the wallet ecosystem sharing these costs.

I'm voting No on the Bringing Real-World Payments to Cardano with Wirex proposal.

I recognize Wirex as an established, regulated payments company with 7 million users and Visa Principal Member status. Still, I don't think this proposal justifies treasury funding.

First, this is an overly familiar business model. Crypto-linked cards from Crypto.com, Binance, Coinbase and others are already everywhere, yet none has turned them into a transformative success or driven meaningful volume and users to a network.

A crypto card is unlikely to bring the kind of durable on-chain activity or user growth that would justify this spend for Cardano.

Second, this isn't even a new venture. The Cardano Card was already launched commercially in 2025 through an EMURGO and Wirex partnership, with Wirex as the issuer.

Asking the treasury to now fund infrastructure for a product these same parties have already brought to market makes little sense. This is a commercial business, driven by commercial motives, that the parties are already pursuing on their own.

Integrating a new chain is the kind of expansion a company normally funds from its own R&D budget.

If Cardano integration were genuinely meaningful to Wirex's users and volume, there would be ample incentive to do it without a subsidy. If Wirex believes in that value, it should pursue it with its own investment, not the treasury.

For these reasons, I'm voting No.

I'm voting Yes on the Withdraw 3,810,423 ada for Mithril Protocol proposal.

Mithril is protocol-layer infrastructure that solves a problem specific to Cardano. Right now, a new node has to sync from genesis, which takes over a day.

Mithril uses stake-based multi-signatures to certify chain state in a trustless way, so a full node can be bootstrapped in under 20 minutes and light clients can verify state without relying on centralized trust.

The main reason I support this is that Mithril solves a problem at a layer no other project is addressing, and it's effectively the only Cardano-native solution at that layer.

The more we move into an era of multiple node implementations like Amaru and Dingo, the bigger Mithril's role becomes, since it's what proves that those different implementations have agreed on the same state.

For these reasons, I'm voting Yes.

I'm voting No on the Eternl: Path to Sustainability - v2 proposal.

First off, I clearly recognize Eternl's role in the ecosystem. A big share of mainnet transactions go through it, it has run reliably for over five years, and it offers the most complete in-app governance UI of any wallet, so as a DRep I feel its value firsthand.

Even so, I can't get behind the fundamental structure, for three reasons.

1. Eternl is a closed-source commercial product. Treasury funding makes sense when the result comes back to the ecosystem as a public good. If Eternl were open-source, so anyone could build on and verify it, there'd be a solid case.

   But the main UI stays closed and only some libraries are published. Something sustained by public funds while its core output stays private is hard to accept.

2. Not building a sufficient revenue model until now was the team's own business decision, and the consequences are theirs to bear. Delaying monetization was a bet on the market, and now that it didn't pan out, the funding gap is being handed to the community treasury.

   Bankrolling a private company's runway to launch a paid product isn't what the treasury is for.

3. The repayment terms are hard to accept too. It only commits to repaying when paid-plan income and remaining funds exceed costs. That means if the business does well, the support wasn't needed, and if it does poorly, repayment never happens. For lending out treasury funds to make sense, there should at least be an unconditional commitment to repay.

To sum up, this proposal asks the community to bankroll a paid-subscription business while promising self-sustainability, and ties repayment to that same business succeeding.

This isn't a denial of Eternl's value. It's that I can't agree with this structure, so I'm voting No.

I'm voting Yes on the Reimburse Ikigai Info Governance Action Deposit proposal.

The submitter losing their 100,000 ADA deposit wasn't their fault. It was caused by a bug in the Cardano node code. I believe a clear loss stemming from a protocol flaw is something the community should make right. The amount is small, it's paid out immediately, and there are no additional costs involved.

For these reasons, I'm voting Yes.

I'm voting No on the Strike Finance Liquidity Deployment proposal.

First off, I do recognize what Strike Finance has contributed to Cardano. I've used Strike Finance myself and written promotional posts about it more than a few times, so I genuinely think they've done a lot for the Cardano network.

But, as much as it pains me to say it, Strike Finance in its current form is hard to even call a Cardano-native product. I'm voting No for two reasons.

1. The proposal says it will "increase on-chain trading activity," but Strike V2's trade execution happens off-chain on the Strike Node, and L1 only handles deposits, withdrawals, and settlement. What the treasury funds create isn't on-chain transactions or fees, but market-making liquidity for an off-chain CLOB. On top of that, this off-chain processing doesn't even run on Hydra, the scaling solution built on Cardano's eUTXO model. It runs on Strike's own execution layer.

   In other words, it isn't even going in the direction of using Cardano's own infrastructure to become a reference point for the ecosystem. So Strike Finance's growth in trading volume doesn't translate into a direct contribution to the Cardano network.

2. The proposal doesn't prove the link between "more Strike traders" and "more users and liquidity for the Cardano ecosystem." Even with a target of 5,000 traders, there's no basis to assume they'll hold ADA, use other Cardano dApps, and stay in the ecosystem.

   If anything, the fact that around 50% of the trading volume comes from Ethereum users shows that these people are just using Strike, which is a different thing from actually coming into the Cardano ecosystem.

To sum up, this proposal reads more like the treasury investing liquidity for yield into a protocol that's hard to even call Cardano-native. I believe treasury funds should be used in a direction that genuinely brings users and liquidity to the ecosystem as a whole, and since I don't think this proposal meets that bar, I'm voting No.

I'm voting No on the Reforming Treasury Governance proposal.

First off, I actually agree with a good part of the problem this proposal is pointing at. Even so, the reason I'm voting No is that I think the fix it proposes goes in the opposite direction of solving that problem.

The core issue is that [h] a term-based strategic entity and [i] an appointed expert commission would concentrate the power to prepare, propose, and select projects for the budget, while [f] and [g] would cut off the path for individual proposals to reach DReps directly.

That means gathering the strategic direction and the funding-allocation decisions into a small set of appointed bodies, and it shrinks the DReps' role down to basically rubber-stamping a budget the commission has already put together.

On top of that, I can't really agree with the way this bundles nine propositions of quite different natures into a single Info action and asks for one up-or-down vote, when this is the kind of broad, constitution-level reform that deserves better.

I recognize the value of raising the issue, but I can't get behind a centralized budgeting body as the solution, so I'm voting No.

I'm voting Yes on the Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2027 proposal.

This proposal genuinely took on board the feedback raised against the previous version. It was cut from two years to one, from 17 work packages to 3, and the amount was reduced by more than half, from ₳39.8M to ₳18.26M. The fact that a multi-year single approval has been narrowed to a one-year scope, allowing performance-based reassessment, is also a positive.

The work itself is clearly core protocol-layer infrastructure. Peras is L1 infrastructure that cuts finality from roughly 12 minutes to 2, and Tweag is a proven team that has led the consensus and ledger teams since 2018. The post-delivery controls are also sufficient: mandatory code review by IOG, independent validation by No Witness Labs, milestone-based fixed-price contracts, and the return of any undisbursed funds.

That said, I want to clearly flag the lack of transparency in the cost calculation. The proposal only presents an hourly rate ($176/h) and a conversion rate ($0.25); it does not disclose the number of engineers involved or the allocation of hours across each work package. If the total is rate multiplied by hours, then without any basis for those hours, it's difficult for DReps to independently verify whether ₳18.26M is appropriate.

This matters especially now, at a point where AI has significantly changed engineering productivity. Precisely because the same work may no longer require as much manpower and time as it did in the past, the cost basis should be disclosed more transparently, and there should be a case made to convince the community that the scale is justified.

I am therefore voting Yes on the strength of the work's importance and its reduced scope, but I would like to see the personnel composition and the breakdown of estimated hours disclosed at the milestone stage going forward, with the reasonableness of the cost properly demonstrated.

I'm voting Abstain on the Rare Evo and Dev Gov Day 2026: Cardano Title Sponsorship proposal.

First, I'm not denying the value of this proposal itself. With our own Summit now cancelled, I believe Cardano's ecosystem visibility and marketing matter more than ever. In particular, Rare Dev Gov Day isn't just a marketing event but a venue where actual governance coordination takes place, covering things like Constitution 2.0 and treasury panels, and I see the structure of returning 20% of VIP ticket sales to the treasury as a positive.

Even so, the reason I can't vote Yes comes down to budget allocation priorities. The current 2026 NCL (a 350M ADA ceiling) is filling up quickly with this cycle's large proposals, and the remaining treasury headroom is limited.

In other words, this proposal isn't wrong in itself. It's that, under the current constrained NCL conditions, it is competing for the same funds as other core infrastructure and product proposals. I recognize the importance of marketing, but if we are to allocate a limited budget efficiently, I find it hard to actively support committing headroom to an event sponsorship at this point.

I therefore support the intent and value of this proposal, but in light of the current NCL conditions and budget priorities, I choose to Abstain rather than vote in favor.

I'm voting Abstain on the proposal to change committeeMinSize from 7 to 5.

I acknowledge the problem this proposal is trying to solve. The current committeeMinSize (7) equals the actual size of the Constitutional Committee, leaving no buffer, and creating a single point of failure where the departure of even one member could halt governance. I don't oppose the attempt to address this.

That said, this solution lowers the floor of the oversight layer. The Constitutional Committee is the check that verifies the constitutionality of all governance actions, including those passed by DReps, and lowering its minimum threshold weakens the robustness of that oversight. In particular, at a committee size of 5, the votes needed to block fall to 2, or effectively 1 if one member is inactive, so the blocking power that should be distributed instead becomes concentrated in a small minority.

The same problem could be solved by increasing the actual committee size so that 7 becomes a buffer rather than the floor, or by strengthening rapid replacement procedures when a seat falls vacant, instead of lowering the minimum. Since less oversight-weakening alternatives haven't been sufficiently explored, I choose to Abstain: I won't block the resolution of a legitimate operational problem, but I won't vote in favor of lowering the oversight threshold either.

I'm voting No on the Eternl: Path to Sustainability (2026-2027) proposal.

First, let me clearly acknowledge Eternl's standing and track record in the Cardano ecosystem. A significant share of mainnet transactions go through Eternl, it has run reliably for over five years, and it currently offers the most complete in-app governance UI of any wallet, which makes it infrastructure that has genuinely contributed to the ecosystem.

Even so, I'm voting No on this proposal for the following three reasons.

1. There are no milestones. This proposal isn't performance-based, staged disbursement. It secures 12 months of operating funds upfront. I believe treasury funds should be tied to clear deliverables and step-by-step verification, and a flat operating subsidy with no gating doesn't meet that standard.

2. Repayment only happens when there's a surplus. The proposal commits to repaying the treasury only if Pro plan income and remaining funds exceed costs. That isn't a guaranteed recovery structure. It's closer to a best-effort promise to pay back if the business does well. As long as the repayment obligation carries no real binding force, this should effectively be treated as an unconditional grant.

3. It draws on treasury funding while the core code isn't open-source. The main UI stays closed, with only some libraries published. If infrastructure is sustained by community funds, I believe its output should be returned to the ecosystem as a public good. The combination of public funding and a closed source is hard to accept.

This isn't a denial of Eternl's value. But on the question of the conditions under which treasury funds should be deployed, I can't agree with the way this proposal is structured.

I'm voting Yes on the IO: Hydra proposal.

I've consistently emphasized how important L2 infrastructure is for Cardano's scalability, and I see scaling solutions like Hydra as a differentiated value of Cardano — one that taps into the structural strengths only the eUTXO model can offer.

Honestly, a lot of the project leads I've talked to care less about the value of "decentralization" and more about whether a blockchain can actually deliver the best possible UX to their users. At a moment like this, where adoption by institutions and enterprises is what really matters, delivering an optimized UX to users through a scaling solution is decisive. And that's exactly where Hydra can play the most critical role.

There's going to come a point where we don't even realize that the services we use are running on a blockchain network underneath. When that day comes, Hydra is what can serve as that foundation within the Cardano ecosystem.

I'm voting No on the Scalus: Cardano's Application Platform for Building, Launching, and Scaling proposal.

I recognize Lantr Engineering's strong delivery track (Catalyst F11/F13 at 100%, 2025 Treasury Budget on track), the existing Scalus adoption by Hydrozoa, Bifrost, Mesh, Lucid Evolution, and CCL, and the solid governance hygiene (SundaeSwap escrow, credible oversight board, candid 2025 retrospective). That said, I'm voting No on the scope and priorities for two reasons.

1. The demand the proposal is trying to address isn't demonstrated as a Cardano-specific problem.

The core value proposition here is "bringing 26M developers from the JVM ecosystem to Cardano." But Cardano already has JVM-side tooling in operation, such as Bloxbean's Cardano Client Library (CCL) and Yaci DevKit, and there's no evidence presented that JVM developers aren't coming to Cardano because of the absence of an integrated application platform.

1. Both client diversity and dev tooling are already being addressed by multiple projects in progress.

On the L1 node side, alongside the Haskell node, Amaru (Rust) and Dingo (Go) are already underway with treasury funding, and the Gerolamo (TypeScript browser) proposal is on the table in this same cycle. The differentiated value of adding a JVM-native L1 node on top of that isn't clear. On the application platform side, Mesh SDK, Lucid Evolution, CCL and others have already become the standard stack for the builder ecosystem, so the case for a separate integrated platform being "essential" is weak.

I'm voting No on the "The first node in the browser; a Cardano USP" proposal.

To use a constrained treasury efficiently, the budget should be allocated by priority against actual ecosystem development needs. If this proposal passes and a new TypeScript-based browser node gets added as another client implementation, that's a positive in itself, but I don't see it as solving a fundamental problem that's blocking ecosystem development.

In other words, it would be nice to have, but it's not essential at the priority level of this cycle.

1. The proposal doesn't demonstrate a problem the Cardano ecosystem actually needs to solve.

The Cardano dApp and wallet ecosystem currently runs stably on infrastructure like Mesh, Lucid Evolution, Blockfrost, Maestro, and Koios. The absence of a fully-validating in-browser node isn't creating real problems for dApp builders or users. On top of that, IOG already provides a light verification option through Mithril. The 12-month adoption target of "≥3 wallet/dApp integrations" also reads as the proposal itself acknowledging that market demand isn't large.

1. The case for treasury priority is weak.

In the current NCL-constrained environment, ₳4.6M is not a small amount. The goal of client diversity is already being addressed through multiple projects, and the differentiated value of a "browser-based TypeScript node" on top of that is not clearly articulated.

HLabs is also requesting a separate ₳4.6M for Pebble and TypeScript tooling in the same cycle, which means a single team would receive roughly ₳9.2M from this cycle if both proposals pass. I think the more responsible treasury allocation for this cycle is to direct those funds toward protocol-layer infrastructure, maintenance of core tools with proven track records, and builder work where actual demand has been demonstrated.

I'm voting Abstain on the Cardano dOSPO and OMF Program proposal.

This proposal directly tackles the sustainability problem of Cardano's OSS infrastructure. I agree with the direction, but I can't come down clearly on either yes or no with the current structure, so I'm choosing Abstain.

What I see positively:

The problem of Cardano OSS infrastructure depending on a handful of maintainers is real, and it's an area that's hard to address through one-off grants or voluntary contributions alone. The proposal puts meaningful effort into governance hygiene, including dependency centrality based selection, two independent advisory councils, quarterly reporting, and refundable reserves. The proposer's Intersect OSPO track record is also real domain expertise.

What concerns me:

The motivation leans on generic OSS narratives (Harvard D3, Heartbleed, Kubernetes) without offering a Cardano-specific diagnosis of which libraries are actually at near-term risk. On top of that, the members of the two advisory councils that will hold the key decision-making power, their selection process, the dependency centrality formula used for retainer selection, and the boundary with POSM (which the proposer ran at Intersect) are all left to be decided after the proposal passes. The preconditions are not clear enough to commit ₳12M over 36 months.

Considering both sides, I'm voting Abstain.

I'm voting Yes on the Cardano Critical Integrations V2 proposal.

This proposal covers 12 months of operations and maintenance for Circle USDCx, LayerZero, Pyth, and Dune that are already live on mainnet, along with the native Fireblocks integration.

It feels less like a new build and more like an operations package that keeps live infrastructure live while extending it one step further.

This proposal sets up an optimized development environment for builders, enables better UX for users, and lays the foundation for a more diverse and richer product landscape to emerge on top.

In particular, while not many people are paying attention to it, Fireblocks is going to be a real opportunity for builders who need institutional-grade custody. Fireblocks is a company providing digital asset custody and operations infrastructure for institutional investors, exchanges, banks, and fintechs, and they offer one of the most well-known MPC (Multi-Party Computation) based institutional custody solutions in the industry. Over 1,800 financial institutions and fintechs, including BNY Mellon, BNP Paribas, ANZ, and Revolut, already run their digital asset operations on Fireblocks infrastructure.

The Fireblocks integration is a real opportunity to bring institutional investors, global exchanges, and RWA/tokenization projects to Cardano. Institutional-grade projects are one of the strongest channels in this market for pulling in major narratives, large liquidity, and new users, and this is exactly the kind of foundation that makes that possible.

Honestly, this comes a bit late. But for the growth of the Cardano ecosystem and broader adoption, having this foundational infrastructure in place is essential, which is why I'm voting Yes.

I'm voting No on the 5am.earth Trust Layer Targeting Vision 2030 KPIs proposal.

I recognize Syngenta Foundation India's track record in Indian agriculture and Project Swaminathan's mainnet registration progress. That said, I'm voting No for three reasons.

1. The preparation falls short of the promised scale, and even with full preparation this work is fundamentally difficult.

The Foundation is not yet registered, and the pre-Foundation co-promoters that would control the 5M ADA (Elk GmbH and HashPoint Consulting Sàrl) cannot be publicly verified. There are no disclosed country-level operational plans or buyer commitments for the three-country rollout. India, Cambodia, and Kenya are markets with entirely different regulatory, language, and payment infrastructures, and standing up a multi-sided marketplace that requires both supply (verified farmers) and demand (buyers) to mature in parallel within 18 months is fundamentally hard.

1. The actual demand for the problem being solved is not demonstrated.

The "verify once, use many times" vision is attractive, but there is no clear evidence of the demand side actually paying to use that verified information. EUDR compliance, credit scoring, insurance, and carbon markets are all mentioned as potential markets, but no specific buyer commitments are presented. The proposal references "anchor-brand pilots" in WP4, but no specific brands or LOIs are named. The solution's vision is running ahead of demonstrated demand.

1. The funding case is weak from a Cardano ecosystem priority standpoint.

Rather than allocating ₳10M (about 2.86% of NCL) to a single vertical project whose feasibility and demand are not demonstrated, the limited treasury budget should flow to more urgent work that strengthens Cardano's fundamentals, such as protocol-layer infrastructure, core tooling maintenance, and work by builder teams with verified track records. That would be a more responsible treasury allocation for this cycle.

I'm voting Yes on the Update Plutus Cost Models proposal.

This parameter update is what actually enables the new Plutus primitives that come with the van Rossem hard fork. The key items being activated are BLS12-381 multi-scalar multiplication (CIP-0133), the Array type (CIP-0138), Mary-era Value operations (CIP-0153), and modular exponentiation (CIP-0109).

If this passes, I think Cardano builders will be able to ship things on mainnet that have been off the table due to cost limits. ZK-based privacy dApps become viable at practical cost, and DeFi contracts will use less budget for more complex logic thanks to native Value operations, raising the performance ceiling for DEX, AMM, and lending products.

and I think Index-based contracts like oracles, Merkle proofs, and lookup tables become practical with the Array type, and legacy crypto verification opens up real integration with Web2 systems and external chains as well.

This is the activation step that turns the ZK, Array, and Value work Cardano has been researching and building into actual products. That's why I'm voting Yes.

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

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

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

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

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

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

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

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

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

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

I am voting Yes on the Cardano Vision 2026: Human Centred, Scalable, Post Quantum Secure - IO Research proposal.

When I previously voted in favor of Enhancing Plutus and High Assurance, I framed Cardano's core differentiator as the structural security advantage of the eUTxO model and declarative validation. This proposal extends that strength to defend against future threats such as quantum computing proactively, while preserving Cardano's research-driven identity.

In an era where AI-driven automated exploits are accelerating, the migration toward quantum-resistant cryptographic primitives is a protocol-layer effort to secure long-term resilience. It is also the research foundation that directly connects to the scaling directions I previously supported, including Leios, Peras, and ZK-based L2.

I also pay attention to the consortium structure of this proposal. IOR is not carrying this out alone. Nine partners are participating together, including leading universities such as Edinburgh, Oxford, and the Institute of Science Tokyo, alongside specialised contributors. This aligns with the direction of reducing single-org dependency on IOG that I emphasized in previous votes, and with the decentralization direction of IO's 2030 Vision. It also expands Cardano's original academic identity into a broader global research network.

The overall direction of this proposal, securing protocol-layer long-term resilience and reducing IOG dependency through a global partner structure, is in my view essential work for Cardano to prove its differentiated value at the next stage. For these reasons, I am voting Yes.

I am voting No on the Pebble & Ecosystem maintenance: TypeScript core of Cardano proposal.

This proposal bundles two tracks of work: maintenance of the TypeScript tooling stack, and accelerated development of a new smart contract language, Pebble. My positions on these two are clearly different. Because the proposal does not allow them to be evaluated separately, and because the Pebble portion does not meet the bar in my view, I am voting No on the bundled package.

I strongly agree with funding the TypeScript tooling maintenance. Many widely-used libraries in the Cardano TypeScript ecosystem, including Mesh, Lucid Evolution, and Midgard L2, depend on this tooling stack directly or transitively. If this maintenance lags during a hard fork, the entire downstream ecosystem stalls along with it. This is public-goods infrastructure, and I believe the Treasury should fund it.

However, I am skeptical about the case for funding Pebble.

1. There is no empirical evidence of demand. The proposal argues that since TS/JS is the largest developer pool in the world, an imperative-syntax language will draw them to Cardano. But there is no concrete signal showing that TypeScript developers who chose not to come to Cardano point to "Aiken's functional paradigm" as the blocker. If anything, in an era where AI has sharply lowered the cost of learning a new language, I think the real barrier is not the language itself but the structural difference between the market-standard EVM and the eUTxO model. Pebble does not address this fundamental barrier.

2. HLabs' own adoption target is very modest. Despite a potential target pool of millions of TS/Solidity developers, the 12-month goal is only 20 developers. Spending around ₳3.2M to onboard developers at that scale is difficult to justify.

3. Aiken is already working well. Aiken became the default quickly after mainnet release, and Cardano developer activity has remained steady. There is no observable signal supporting the hypothesis that "the functional paradigm is the bottleneck blocking developer inflow."

I think Cardano's real bottleneck for developer onboarding lies elsewhere. TVL and commercial opportunity, network effects, the learning curve of the eUTxO model itself, and gaps in documentation and tutorials are the larger problems, and Pebble does not solve any of them.

I recognize the value of the tooling maintenance while remaining skeptical about the funding case for Pebble. Because the bundled structure forces a single decision on both, I am voting No.

I am voting Yes on IO's Cardano High Assurance proposal.

In a market with repeated hacks, I believe Cardano's core differentiator lies in declarative validation built on the eUTXO model: the structural security advantage of being able to fully verify a transaction's result before it executes. This proposal extends that strength to the DApp level.

Formal Verification is "the work of mathematically proving that code behaves exactly as intended." It is one of Cardano's core differentiators, but until now it has been accessible only to a small group of developers trained in specialized verification tools.

The Blaster track brings this capability into a form ordinary developers can use naturally inside the code editor (VS Code) they already work in. Verification scope expands from a single contract to an entire DApp, common vulnerabilities come as pre-built property templates so developers don't need to write verification from scratch, and the equivalence checker preserves prior verification results when code is optimized.

In short, this converts Cardano's "safety in theory" into "safety used in everyday development." Especially as AI-driven automated exploits proliferate, this is not a developer-convenience improvement but an infrastructure investment that raises the security baseline of the entire ecosystem, and a natural next step in the line of work I supported when voting for the Enhancing Plutus proposal.

I also note the consortium structure. WS1 distributes work across multiple smart contract language integrations and additional components among external partner organizations. Rather than IOG vertically integrating every language and toolchain, this is a distributed execution structure where specialized organizations own their respective domains, aligned with reducing single-org dependency on IOG and with the decentralization direction of IO's 2030 Vision.

Over the long run, I think such a structure distributes expertise across organizations, accelerates technical progress, and creates a meaningful opportunity to grow specialized engineers within the Cardano ecosystem.

That said, partner-level budget allocation, FTE composition, and milestone schedules should be disclosed. Despite the ₳13M scale, the share of responsibility and resource allocation for each partner organization is not specified in the proposal. I do not believe IO's influence should serve as grounds for exempting it from the transparency and accountability standards that apply to every other proposer. Even if this proposal passes, partner-level deliverables and resource allocation should be disclosed in a trackable form during execution.

The overall direction of this proposal, extending eUTXO's structural security advantages to the level of practicing developers and reducing IOG dependency through a multi-partner distributed execution structure, is essential work for Cardano to prove its differentiated value to the market at the next stage.

For these reasons, I am voting Yes.

I vote YES on the Revised Cardano Summit 2026 Singapore proposal.

What stands out in this revised proposal is that CF's internal resource contribution has increased from $250,000 to $380,000, that the CF Summit has been decoupled from EMURGO's TOKEN2049 sponsorship into a separate proposal.

I laid out my supporting rationale when voting on the original proposal as well, but the effect of networking and direct engagement that comes out of in-person events like this is enormous. Real business, collaborations, and unexpected ideas and opportunities happen through face-to-face meetings.

The content that gets reproduced and shared through international events of this scale also delivers Cardano's presence to the market.

Some have suggested the community could organize this themselves, but that is nearly impossible. Every part of running an event of this scale, from the preparation work, to inviting speakers, to external promotion, can only be done by a credible and well-structured organization.

An inexperienced and unprepared organization hosting a low-quality event would actually damage the ecosystem's credibility and brand value externally. The fact that only the founding entities are currently capable of preparing an international event that represents Cardano is undeniable.

Since this Summit is being held in conjunction with TOKEN2049, I expect CF to maximize the synergy that the timing and location bring.

I am voting No on the IO & Midgard Labs: L2 Scalability Initiative proposal.

I have consistently emphasized the importance of L2 infrastructure for scaling the Cardano network. Scaling solutions like Hydra are essential for Cardano to remain competitive, and I believe that scaling approaches built on the structural strengths unique to the eUTXO model represent a differentiating value for Cardano.

For these reasons, this decision was not an easy one for me.

However, my opposition is not about what this proposal aims to build, but rather about how it is structured and what it asks DReps to overlook.

1. Midgard's prior funding commitments remain unfulfilled.
   Midgard has already received ₳500,000 through Catalyst Fund 12 and ₳2,162,096 through the 2025 Intersect treasury withdrawal, totaling approximately ₳2.66M in prior funding.

Yet Catalyst F12 currently sits at only 3 of 6 milestones completed, with the core deliverables in milestones 5 and 6 still not remaining undelivered past their scheduled dates.

This new funding request is essentially a third round of funding being asked for while Catalyst F12 is not even closed out yet. Even though Midgard's share within this proposal is relatively small, granting additional funding before prior commitments have been verified raises legitimate concerns about treasury fund accountability.

1. The bundled structure makes separate evaluation impossible.
   This proposal combines three components with different maturity levels and risk profiles into a single funding request. When heterogeneous components are bundled into one package, DReps lose the ability to evaluate the proven Hydra track separately from the unverified Midgard track.

As a result, we are forced into a binary choice where passing the legitimate parts requires also passing the parts we don't agree with.

I do not believe IO's influence should serve as grounds for exempting it from the transparency and accountability standards that apply to every other proposer. Trustworthy governance is only possible when the same standards are applied consistently.

1. Responsibility allocation and deliverable definitions are unclear.
   The proposal only states that the work will be "jointly delivered by IO and Midgard Labs," without providing a clear breakdown of how responsibilities, resources, and governance oversight are divided between the two organizations.

Additionally, ₳625,552 is allocated to "Engagement & Ecosystem support," but no measurable deliverables are defined for this line item.

---

This is not an evaluation of the value of any particular project. It is purely about flagging concerns regarding the structure of the proposal and consistency in governance.

I believe all three components covered in this proposal are important to the Cardano ecosystem. However, overlooking a bundled structure and accepting additional funding requests for unfinished projects would set a precedent that allows the same problems to repeat. To prevent that pattern from recurring, I had no choice but to vote No.

I would ask that the projects be submitted separately and independently, and that responsibility allocation and deliverable definitions be made more concrete. With those changes, I would be happy to consider future proposals more favorably.

I'm voting NO on IOG's Developer Experience Initiative proposal.

I agree that the activities covered in this proposal address an important area, reducing the onboarding friction faced by new developers. Setting up environments through cardano-init, providing reusable contracts via the ContractsLibrary, organizing onboarding content through the Developer HUB, supporting developers on Discord and GitHub, and funding bounties for external tooling maintainers are all activities that can contribute to ecosystem growth.

That said, I have reservations about whether these activities warrant being elevated into a separate Treasury funding request. IOG is a specialized organization responsible for Cardano's core research and development, and it has already been allocated significant Treasury resources through multiple large-scale infrastructure, protocol, and tooling proposals. In my view, the documentation, community support, onboarding content, and tooling integration covered in this proposal fall into the category of work that should naturally be handled as a complementary part of those ongoing core R&D projects, rather than as a standalone funded initiative.

Furthermore, a meaningful portion of this scope can be reasonably carried out by community contributors, OSS maintainers, and the existing efforts of the Cardano Foundation.

For these reasons, I am voting NO on this proposal. I fully agree with the broader direction of improving developer experience, and I would be supportive of approaches where documentation and onboarding are naturally included as part of the standard deliverables of core development work, or where community contributions are activated through more targeted mechanisms.

I am voting Yes on the Enhancing Plutus proposal.

If improvements to the consensus algorithm and network are about the protocol's performance and security, then Plutus is about improving the foundational infrastructure layer that allows various products to be born on the Cardano network.

In that sense, this proposal is just as important as protocol-level upgrades themselves, especially for enabling diverse products in the ecosystem to emerge and evolve.

To me, Plutus is a truly special contract language in the smart contract space.

We've been seeing a lot of hacks lately stemming from contract vulnerabilities, and a big part of why this happens is that most smart contracts dynamically change state at execution time. In that kind of structure, it's hard to fully predict what a transaction will actually do once it runs, so vulnerabilities end up being structurally baked in.

Cardano, on the other hand, is built around declarative validation on the eUTXO model, which means you can verify all outcomes before execution. That gives it a fundamental edge in terms of security. Especially now, when AI is accelerating automated vulnerability discovery and exploitation, I believe that continuing to strengthen Cardano's structural security advantage is exactly what will drive broader product adoption.

This proposal will lower transaction fees, open the door for a wider range of DApps, lower the barrier to entry for developers, and make it possible to build more efficient and sophisticated contracts. In particular, it lays the groundwork for new node implementations like Amaru to safely enter mainnet, and the transition of stewardship to VacuumLabs is, in my view, a real step toward reducing single-organization dependency on IOG and moving toward a structure where multiple specialist partners contribute to the core infrastructure.

That said, the proposal lacks line-item budget breakdowns and FTE figures, and the transparency around VacuumLabs's share also needs improvement.

I recognize that IO is a key organization driving this ecosystem forward, but I don't think its influence should serve as grounds for exempting it from the transparency and accountability standards that apply to every other proposer. If the opportunity arises, I'd appreciate it if more details on these points could be provided.

I'm voting Yes on IOG's Consensus and Maintenance proposals.

Network scalability and core infrastructure maintenance are not optional priorities, they are the foundation everything else in the Cardano ecosystem depends on.

1. Leios: Sustainable L1 Throughput

Cardano's current 10 to 15 TPS makes it structurally difficult to host products that require high transaction frequency — perpetual DEXs, on-chain games, AI agent micro-payments, enterprise-grade RWA infrastructure. Leios changes this at the protocol level, targeting a 10x to 65x throughput increase.

The 2030 Vision of scaling from 800,000 monthly transactions to over 27 million is not achievable through L2 alone. L1 must scale, and Leios is the mechanism designed to get there. The multi-vendor consortium and the fail-safe fallback to Praos make this an ambitious but disciplined upgrade.

1. Maintenance: The Layer Everything Depends On

Every stake pool, every dApp, every transaction runs on what this work delivers. By the end of 2026, stewardship of Cardano's Haskell engineering capability is set to move to a dedicated entity exactly the kind of structural decentralization the ecosystem has been asking for, and it has to be funded through to completion.

Consensus and Maintenance are also inseparable. Leios specifications come from the Consensus workstream, but integration into the node and long-term stability depend on Maintenance.

---

Strong tech at the protocol layer only really pays off when it's tested properly and kept up over time. Leios is a pretty ambitious upgrade, and that means it needs to be delivered carefully, not rushed. I'm voting Yes because both proposals have milestone-based funding, a multi-vendor delivery setup, and a clear handoff plan in place.

I'm voting Yes on IOG's Consensus and Maintenance proposals.

Network scalability and core infrastructure maintenance are not optional priorities, they are the foundation everything else in the Cardano ecosystem depends on.

1. Leios: Sustainable L1 Throughput

Cardano's current 10 to 15 TPS makes it structurally difficult to host products that require high transaction frequency — perpetual DEXs, on-chain games, AI agent micro-payments, enterprise-grade RWA infrastructure. Leios changes this at the protocol level, targeting a 10x to 65x throughput increase.

The 2030 Vision of scaling from 800,000 monthly transactions to over 27 million is not achievable through L2 alone. L1 must scale, and Leios is the mechanism designed to get there. The multi-vendor consortium and the fail-safe fallback to Praos make this an ambitious but disciplined upgrade.

1. Maintenance: The Layer Everything Depends On

Every stake pool, every dApp, every transaction runs on what this work delivers. By the end of 2026, stewardship of Cardano's Haskell engineering capability is set to move to a dedicated entity exactly the kind of structural decentralization the ecosystem has been asking for, and it has to be funded through to completion.

Consensus and Maintenance are also inseparable. Leios specifications come from the Consensus workstream, but integration into the node and long-term stability depend on Maintenance.

---

Strong tech at the protocol layer only really pays off when it's tested properly and kept up over time. Leios is a pretty ambitious upgrade, and that means it needs to be delivered carefully, not rushed. I'm voting Yes because both proposals have milestone-based funding, a multi-vendor delivery setup, and a clear handoff plan in place.

I'm voting Yes on IOG's Cardano Upgrade proposal.

Sharing the value of the Cardano ecosystem is one of my top priorities, but I see Cardano's network R&D as a necessity, not just a priority.

This Cardano Upgrade proposal contains several core elements needed for mass adoption. Among them, I want to focus on CIP-159 and Babel Fee.

1. CIP-159: Account Address Enhancement
   Reward accounts have so far been limited to receiving staking rewards only, but this upgrade expands them into general-purpose balance accounts that anyone can deposit into. Previously, every UTxO required a minimum ADA amount, which made micro-fees like 0.1 ADA essentially impossible. CIP-159 solves this constraint at the root.

This matters especially from the perspective of the AI agent economy. In an era where agents settle 0.01 USD per API call, a 1 ADA minimum was effectively a barrier to entry. CIP-159 lays the groundwork for Cardano to function as the payment infrastructure for the agent economy. There's a deeper meaning too.

The existing Reward account was a limited account-model area within Cardano. With CIP-159, Cardano keeps the strengths of eUTXO while gaining the flexibility of Ethereum's account model on top, becoming a hybrid structure. A new accounting dimension is being added on top of Cardano's unique eUTXO model.

1. Babel Fee
   One of the biggest entry barriers in the blockchain market is poor UX, and gas fees are the single largest cause of that friction. That's why many networks are investing in account abstraction, letting users pay gas in stablecoins or other tokens, building environments where users don't even feel like they're using a blockchain. This is the broader trend.

Babel Fee will play a central role for Cardano in this trend. Users will be able to pay gas with stablecoins like USDM without holding any ADA. This will drive the biggest changes in financial use cases like remittance, payments, and lending.

To put it simply, Babel Fee will play the biggest role in creating an environment where users don't even realize they're using the Cardano network.

I think strong technology introduced at the protocol layer manifests in diverse ways as it moves up to the product layer, delivering maximum utility to users through a range of products.

I believe this Cardano Upgrade is an important proposal that will bring real, practical value to Cardano.

I'm voting NO on the Pogun and Blockfrost governance proposals.

Both proposals are clearly important and meaningful for the ecosystem, but with limited treasury assets, we have to vote based on priorities to make sure those funds get used efficiently.

First, on the broader question of commercial proposals: we already have Catalyst and Orion Fund in place as channels for projects to raise funding. I don't think it makes sense for the treasury to additionally invest in commercial companies and commercially-oriented projects on top of that.

Blockfrost is genuinely the dominant RPC service in the Cardano ecosystem, but they run a business model with a paid premium tier. The argument that they need a subsidy because they hold 90% market share actually cuts the other way for me. It risks blocking other competitive indexer services from entering the market, undermining fair competition, and further entrenching their monopoly position. I think the healthier path for Blockfrost is to raise outside investment, or apply through Orion Fund or Catalyst, and let their business model prove its sustainability in fair competition with other players, rather than relying on treasury support.

Pogun is an attractive proposal given how important Bitcoin DeFi is in this market. The revenue-return structure is a step up from a standard grant, but at the end of the day it's still a commercial project. If IO truly believes this is a strong business, the right move is for them to seed it with their own capital. Same as with Blockfrost, they should apply to Orion Fund, go through Catalyst, or pursue external seed investment. There's also a fairness issue here, since other BTCfi and bridge projects are already building in this space. If treasury money goes as a grant to some projects and not others, you end up distorting the market.

My view is that the treasury is public-good capital, and it should be concentrated on the areas the market can't fund on its own, the shared infrastructure that benefits the entire Cardano ecosystem. Commercial projects should be funded through the channels built for that purpose, Orion Fund and Catalyst, plus the external capital markets.

I'm voting NO on the Pogun and Blockfrost governance proposals.

Both proposals are clearly important and meaningful for the ecosystem, but with limited treasury assets, we have to vote based on priorities to make sure those funds get used efficiently.

First, on the broader question of commercial proposals: we already have Catalyst and Orion Fund in place as channels for projects to raise funding. I don't think it makes sense for the treasury to additionally invest in commercial companies and commercially-oriented projects on top of that.

Blockfrost is genuinely the dominant RPC service in the Cardano ecosystem, but they run a business model with a paid premium tier. The argument that they need a subsidy because they hold 90% market share actually cuts the other way for me. It risks blocking other competitive indexer services from entering the market, undermining fair competition, and further entrenching their monopoly position. I think the healthier path for Blockfrost is to raise outside investment, or apply through Orion Fund or Catalyst, and let their business model prove its sustainability in fair competition with other players, rather than relying on treasury support.

Pogun is an attractive proposal given how important Bitcoin DeFi is in this market. The revenue-return structure is a step up from a standard grant, but at the end of the day it's still a commercial project. If IO truly believes this is a strong business, the right move is for them to seed it with their own capital. Same as with Blockfrost, they should apply to Orion Fund, go through Catalyst, or pursue external seed investment. There's also a fairness issue here, since other BTCfi and bridge projects are already building in this space. If treasury money goes as a grant to some projects and not others, you end up distorting the market.

My view is that the treasury is public-good capital, and it should be concentrated on the areas the market can't fund on its own, the shared infrastructure that benefits the entire Cardano ecosystem. Commercial projects should be funded through the channels built for that purpose, Orion Fund and Catalyst, plus the external capital markets.

I think this is a proposal with clear strategic value. Cardano has now reached a point where 'visibility' matters just as much as technology.

Hosting the Cardano Summit in Singapore right before TOKEN2049 is a highly effective strategy.

TOKEN2049 is one of the largest blockchain events in the world, drawing over 25,000 attendees, and it takes place in Singapore, a major Asian financial hub. With global events like this, participants typically arrive in the host city ahead of time to travel or take care of personal schedules. During this window, various side events are held in advance, creating natural opportunities for exposure and relationship-building with these attendees.

From my own experience attending global conferences, my team and I would often arrive early in the host city and join any connected events happening nearby. The offline touchpoints formed during these moments carried far greater impact than online promotion, and the likelihood of them leading to real business opportunities was significantly higher.

By hosting the Cardano Summit in Singapore before TOKEN2049, we can organically introduce TOKEN2049 attendees to the Cardano ecosystem and draw them into our network. At the same time, Cardano builders and projects participating in the Summit can continue into TOKEN2049, where they gain opportunities to connect with other chains, investors, and partners for collaboration and expansion.

The KPIs for this kind of event are admittedly difficult to measure in simple numbers. However, considering the potential for strengthening Cardano's presence, raising global awareness, and expanding the ecosystem, I believe this is one of the most effective strategic moves available to us.

We cannot afford to miss this opportunity.

Rationale:

1. Gerolamo: No Clear Demand for a Browser Light Node Today
   A trust-minimized browser light node is conceptually appealing, but there is no evidence of meaningful demand for backend-free dApp architectures in the current Cardano ecosystem. Most dApps today rely on centralized APIs such as Blockfrost and Koios, and this setup is functioning without significant friction. Cardano's primary bottleneck is not infrastructure decentralization, it is the lack of users and dApps themselves.

2. Gerolamo and Amaru: Redundant Scope
   Node diversity is important for long-term resilience, and having multiple implementations is a valid goal. However, the Treasury is already funding Amaru, a Rust-based alternative node. While Gerolamo and Amaru differ in runtime and target use cases, the functional overlap around chain sync, ledger validation, and peer connectivity is substantial. Given the current state of the ecosystem, investing heavily in parallel node implementations is not the highest priority. Limited Treasury resources should be directed toward areas with more immediate impact.

3. Pebble: Unvalidated Demand for a Second Smart Contract Language
   Aiken already serves as Cardano's primary smart contract language and is still in its early stages of adoption. The argument that Pebble will attract 17M+ JS/TS developers is a supply-side narrative with no demand-side validation. The claim that developers cannot onboard to Cardano because Aiken's learning curve is too steep does not hold up. Today, developers can rapidly learn new languages and frameworks through AI-assisted tools, making language familiarity a much smaller barrier than it used to be. The real barrier to developer adoption is not the language itself, it is whether building on Cardano leads to users and traction. The priority should be growing the ecosystem and demonstrating that Cardano is worth building on, not introducing a second smart contract language before the first has achieved meaningful penetration.

The ecosystem's highest priority today is creating an environment that attracts more liquidity and users. Node diversity matters, but Treasury resources are finite and must be allocated according to what the ecosystem needs most urgently. For these reasons, I vote against this proposal.

Since this issue stems from an early Cardano governance submission bug, I do think reimbursing the deposit is the right thing to do. However, it’s important to verify that the refund is actually going to the original proposer. I also have doubts about adding an extra 3,000 ADA as compensation. If additional reasons such as the Midnight airdrop are included for further reimbursement, I’ll be voting against this proposal.