Will Norris

I am voting NO on the Revised Cardano dOSPO and OMF Program Proposal.

I want to be clear that this is not a vote against open-source sustainability, maintainers, public goods, or the need to improve long-term support for Cardano’s open-source dependencies.

The problem this proposal is trying to solve is real. Cardano does rely on open-source software, libraries, tools and maintainers that need better continuity, succession planning, dependency awareness and long-term support.

I also recognise that this revised proposal is materially improved from the earlier version. It is smaller, shorter, more focused, and more pilot-like. The proposal requests 4,094,000 ADA over 12 months and is structured around a Maintenance Fund, Maintainer Development Program, CodeForUs Bounty Program, and Ecosystem Activation Reserve.

However, I do not believe this is the right treasury allocation at this time.

My main concern is that this remains a secondary allocation structure rather than direct funding of clearly identified critical infrastructure. The proposal creates a new programme layer that will later decide which open-source dependencies, maintainers, bounties and ecosystem activities receive funding.

That may become a useful model in future, but I believe Cardano should first agree the broader NCL and treasury framework within which this type of programme would sit.

I have recently advocated for shorter NCL windows, category-level budget buckets, market-aware spending, sovereign reserves in stronger markets, and clearer rules for any treasury investment or programme-allocation function. This proposal is exactly the type of action that should be considered inside a pre-agreed open-source maintenance or ecosystem sustainability bucket, not from one long, undifferentiated NCL pot.

Until that framework exists, I am more comfortable supporting direct, specific, measurable infrastructure and tooling proposals than approving new meta-funding structures.

I am also cautious about precedent. I have been reluctant to support broad secondary funding bodies where DReps delegate substantial allocation discretion to another programme or administrator. Even where the intention is good, DRep accountability over treasury spending should remain direct unless the mandate, category budget, governance controls and selection rules are exceptionally clear.

A future version of this proposal could be stronger if it were submitted after NCL reform, inside an agreed open-source sustainability budget, with clearer pre-identified dependency priorities, tighter disbursement criteria, and stronger evidence that this programme structure is the best way to fund those public goods.

As submitted, I do not believe this proposal should be prioritised ahead of preserving remaining NCL capacity and improving the treasury framework first.

For these reasons, I vote NO.

I am voting YES on the TxPipe Tx3 proposal.

I have considered this proposal carefully because, unlike the lower-level TxPipe maintenance proposals I have already supported, Tx3 sits higher in the developer stack. It is not simply core library maintenance. It is an open API/interface layer intended to make Cardano dApp protocols easier to describe, integrate with, and consume.

However, I believe this proposal still fits within my broader “fund the rails before the growth bets” approach.

Tx3 aims to help protocol authors define reusable interfaces for UTxO-based dApp interactions, allowing wallets, applications, SDKs, agents and other tools to generate typed clients and build transactions against those protocols more reliably. This can reduce integration friction, improve developer experience, and make Cardano applications easier to compose and connect.

Cardano’s UTxO model is powerful, but dApp interaction remains harder to standardise than in account-based ecosystems. A common interface layer for protocol interactions could become valuable infrastructure if adopted widely and kept open.

I also view this proposal differently from large commercial growth, liquidity, or treasury-capital deployment proposals. The ask is 1,684,050 ADA, which is material but comparatively modest relative to many live treasury requests. It is Cardano-native, developer-facing, open-source oriented, and linked to a credible technical team with a strong delivery history across the ecosystem.

In the current NCL environment, I remain cautious on broad growth asks, private commercial subsidies, and large DeFi or treasury-investment programmes. But I am willing to support focused proposals that strengthen the technical rails builders use to create applications on Cardano.

My support is not unconditional. I would expect clear reporting on protocol onboarding, SDK generation, adoption by external teams, documentation quality, open-source delivery, and evidence that Tx3 becomes an ecosystem tool rather than a narrow TxPipe-specific layer.

On balance, I believe this proposal is a proportionate investment in Cardano developer infrastructure and dApp composability.

For these reasons, I vote YES.

I am voting NO on AlphaGrowth’s Cardano PRIME proposal.

I want to be clear that this is not a vote against AlphaGrowth, DeFi growth, business development, liquidity, institutional outreach, or the idea that Cardano should become more ambitious in how it grows its ecosystem.

I do believe Cardano needs a stronger business development function. I do believe Cardano needs deeper liquidity, better DeFi distribution, stronger integrations, and a more deliberate strategy for attracting capital and users. I also recognise that this proposal is more detailed and more structurally serious than many treasury asks.

However, I do not believe a 120,000,000 ADA withdrawal should be approved in the current treasury framework.

The proposal requests 120M ADA for a 12-month community-overseen programme to improve DeFi protocol readiness, activate incentives, and grow durable liquidity across Cardano markets. It includes phased delivery, oversight, reporting, audit/assurance funding, and return-to-treasury mechanisms. Those are positive features.

But the scale of the ask is simply too large to approve without prior treasury reform, significantly deeper scrutiny, and a valid NCL framework that can accommodate it.

My first concern is the Net Change Limit. The NCL is a constitutional treasury safeguard that caps ADA withdrawals from the treasury over a defined period to ensure financial sustainability. If there is only around 58M ADA of current NCL headroom available, then a 120M ADA treasury withdrawal should not be considered constitutional unless and until a valid NCL top-up or revised NCL framework is approved and recognised.

My second concern is sequencing. A proposal of this size should not be used to force the NCL discussion after the fact. If AlphaGrowth and the community believe Cardano needs this scale of DeFi growth funding, then the correct sequence should be: first reform or reset the NCL framework, then define the relevant growth/DeFi/treasury-investment budget bucket, then resubmit a proposal of this type inside that agreed framework.

My third concern is that PRIME is not simply critical infrastructure maintenance. It is a large DeFi growth, incentives, liquidity, business development, and treasury-capital deployment programme. That may be valuable, but it belongs in a different category from wallet security, self-custody, protocol maintenance, open-source infrastructure, and core developer tooling. Cardano has not yet agreed how much of the NCL should be allocated to DeFi growth or treasury-investment style programmes.

This is why I have been advocating NCL reform.

Before approving a 120M ADA programme of this nature, I believe Cardano should agree:

• shorter NCL windows, ideally around 3–6 months;
• category-level budget buckets;
• a defined DeFi/growth allocation;
• a strategy for strong and weak ADA markets;
• a plan for building sovereign reserves in stronger markets;
• rules for stablecoin and non-ADA reserve assets;
• risk limits for treasury-capital deployment;
• concentration limits;
• conflict controls;
• independent due diligence standards;
• public reporting requirements;
• accountability for returns and losses.

I am not opposed to the Cardano Treasury eventually developing a more sophisticated business development, sovereign reserve, or VC-style ecosystem investment function. In fact, I think that may become necessary. But it must be built slowly, deliberately, and inside an agreed constitutional and treasury framework.

A 120M ADA programme should not be the starting point.

The correct path, in my view, is for AlphaGrowth to work with DReps and the wider community on NCL reform and treasury architecture first, then resubmit PRIME once a revised NCL framework and, if necessary, constitutional update have been enacted.

That would allow the community to assess PRIME inside a proper category budget, with clear risk rules, market-aware treasury strategy, and an agreed mandate for this type of growth capital.

Until then, I cannot support this proposal.

For these reasons, I vote NO.

I am voting NO on the DeFi Kernel / Global Order Book proposal.

I want to be clear that this is not a vote against Cardano DeFi, shared liquidity, composable financial applications, Dano Finance, or the broader idea of improving DeFi infrastructure on Cardano.

The proposal is interesting and has merit. Cardano DeFi would benefit from better contract discoverability, shared liquidity standards, reusable transaction tooling, and improved composability between protocols. I also recognise that the proposal is more Cardano-native and ecosystem-focused than some other commercial adoption proposals.

However, I do not believe this is the right treasury allocation at this time.

The proposal requests 3,333,000 ADA, made up of 3,300,000 ADA for delivery and a 33,000 ADA administration fee. It funds a DeFi Kernel registry and submission process, a Spot Leverage Order Book, an American Options Protocol, and a Composable DeFi Transaction Builder SDK.

My concern is that a significant portion of the ask is not simply maintenance of existing core infrastructure, but the development of new DeFi primitives and protocol-level financial products. Those may be valuable, but they sit in a different category from the infrastructure, wallet security, self-custody, developer tooling and open-source maintenance proposals I have supported.

This proposal is exactly the kind of action that, in my view, should be evaluated inside a pre-agreed DeFi / liquidity / treasury investment budget bucket. Cardano has not yet agreed that bucket, its size, its risk limits, or its priority relative to core infrastructure and public-good maintenance.

This ties directly to my broader view on NCL reform.

I believe Cardano should move toward shorter NCL windows, category-level budget buckets, market-aware spending, sovereign reserves built in stronger markets, and clear rules for any VC-style or treasury-investment function. Until that framework exists, I am reluctant to approve further higher-stack growth or DeFi expansion proposals from the same long, undifferentiated NCL window.

I am not opposed to DeFi funding in principle. I am not opposed to treasury-backed growth in principle. But I believe DReps should first agree how much of the NCL should be available for DeFi, liquidity, growth and investment-style proposals, and what standards those proposals must meet.

A future version of this proposal could be more compelling within a clearer DeFi or growth allocation framework, especially if the public-good deliverables, open-source scope, adoption targets, risk controls, and ecosystem-wide benefits are specified against an agreed category budget.

As submitted, I do not believe this proposal should be prioritised ahead of preserving remaining NCL capacity for the rest of the current window.

For these reasons, I vote NO.

I am voting NO on the Wirex Real-World Payments proposal.

I support the strategic goal of bringing real-world payments to Cardano. Payments, card infrastructure, fiat connectivity, stablecoin settlement and merchant acceptance are all important if Cardano is to reach broader adoption.

However, I do not believe this proposal is sufficiently clear or sufficiently justified for a treasury withdrawal of 3,961,538 ADA.

My main concern is that the proposal does not clearly define what Cardano receives in exchange for this funding. It uses broad language around payment infrastructure, banking rails, on-chain settlement, stablecoins, wallets, self-custody integration and card issuance, but I do not think the specific Cardano public-good deliverables are defined tightly enough.

For a withdrawal of this size, I would expect clearer detail on what will be open-sourced, what infrastructure will remain available to the wider Cardano ecosystem, what is exclusive or non-exclusive to Cardano, what adoption commitments exist, what success metrics will be reported, and how the Treasury benefits beyond helping fund a commercial payments rollout.

In the current NCL environment, I believe DReps need to be highly selective. My priority is to support critical infrastructure, wallet security, self-custody, developer tooling, open-source public goods and protocol readiness.

Real-world payments are important, but growth and adoption proposals should be assessed inside a clearer NCL framework. This proposal reinforces my view that Cardano should move toward shorter NCL windows and category-level budget buckets, so DReps can agree in advance how much treasury capacity should go toward infrastructure, security, developer tooling, governance, growth, marketing, DeFi or treasury investment, and reserves.

I am not opposed to funding payments infrastructure in principle. I am also not opposed to growth/adoption spending. But for a nearly 4M ADA withdrawal, I believe the public-good output, ecosystem return, open-source scope, adoption targets and long-term Cardano benefit need to be much more clearly specified.

A stronger revised proposal could separate commercial rollout from public-good infrastructure, define exactly what Cardano receives, specify what is open-source, provide measurable adoption targets, and explain the long-term value returned to the Cardano ecosystem and Treasury.

As submitted, I do not believe this proposal is sufficiently precise, accountable or proportionate.

For these reasons, I vote NO.

I am voting NO on the Alchemy by Sundial x Charms proposal.

This is not a vote against Bitcoin, BTCfi, Sundial, Charms, or the idea that Cardano should compete for Bitcoin liquidity. I understand the strategic argument that Cardano needs stronger Bitcoin-related infrastructure and that BTC liquidity is one of the largest opportunities in digital assets.

However, I do not believe this proposal is the right use of the Cardano Treasury at this time.

The proposal requests 10,000,000 ADA for a Cardano-native Bitcoin treasury and BTCfi infrastructure layer. The concept is ambitious and potentially interesting, but it is also novel, complex and materially higher risk than the infrastructure, wallet, security and developer-tooling proposals I have supported.

My main concern is that this proposal sits closer to a treasury-backed investment or structured financial product than to essential public-good maintenance. It involves protocol infrastructure, staged launch liquidity, FIRE and ICE assets, Bitcoin-backed exposure, reserve mechanics, integrations, dashboards, legal/compliance work and go-to-market execution.

That may become the type of activity the Cardano Treasury should support in future, but I believe the governance framework should come first.

I recently set out my broader view that Cardano should reform the NCL framework before raising the spending ceiling or using the Treasury in a more active investment-style role:
https://x.com/Cardano_Will/status/2074566189389336964

Before approving large BTCfi or treasury-investment style proposals, I believe Cardano should agree clearer rules around shorter NCL windows, category-level budget buckets, sovereign reserves, stablecoin and non-ADA asset policy, risk limits, concentration limits, conflict controls, independent due diligence, reporting standards and accountability for returns and losses.

I am not opposed to the Treasury eventually operating more like a sovereign reserve or VC-style ecosystem investment function. In fact, I think that may be an important future direction. But it should happen within an agreed framework, not through large ad hoc allocations while the NCL is already under pressure.

In the current environment, I am prioritising critical infrastructure, wallet security, self-custody, open-source public goods, developer tooling and protocol readiness. Alchemy is strategically interesting, but it does not clear my bar for a 10M ADA treasury withdrawal at this time.

For these reasons, I vote NO.

I am voting NO on the proposal to raise the Net Change Limit by 150M ADA.

This is not a vote against treasury spending, ecosystem growth, DeFi, marketing, infrastructure, or ambition. I have supported multiple treasury withdrawals where I believe the case is strong, particularly for wallet security, self-custody, developer tooling, open-source infrastructure and essential public goods.

However, I do not believe the NCL should be increased at this time.

The Net Change Limit is a constitutional treasury guardrail. It is intended to cap treasury withdrawals over a defined period and force prioritisation. If the limit is raised whenever live demand exceeds available capacity, the NCL risks becoming a formality rather than a meaningful discipline mechanism.

My concern is also structural. The current NCL window is too long, and we are already under significant pressure early in the cycle. I believe Cardano should move toward shorter NCL windows, perhaps 3–6 months, with appropriately sized limits. Shorter windows would allow DReps to reassess priorities, market conditions, treasury needs and proposal quality more frequently.

Before increasing the NCL, I believe DReps should first debate and agree a better treasury framework, including category-level budget buckets for areas such as core infrastructure, wallets and security, developer tooling, governance operations, growth and adoption, marketing, DeFi or treasury investment, contingency and reserves.

I also believe Cardano should develop a more market-aware treasury strategy. In stronger ADA markets, the community should consider converting a defined, governance-approved portion of treasury ADA into stable reserves and possibly other approved non-ADA assets. Those reserves could help fund essential operations, public goods and strategic opportunities during weak ADA markets, reducing the need to spend ADA when its long-term opportunity cost is higher.

I am not opposed to the Treasury eventually acting as a more sophisticated sovereign reserve or VC-style ecosystem investment function. But that should happen within agreed buckets, risk limits, stablecoin policies, concentration limits, conflict controls, due diligence standards, public reporting and clear accountability for returns and losses.

I have set out my broader thinking on NCL reform here:
https://x.com/Cardano_Will/status/2074566189389336964

For these reasons, I believe the framework should come before the expanded ceiling. I support serious NCL reform, but I do not support increasing the current limit by 150M ADA now.

I vote NO.

I am voting YES on the TxPipe Oura proposal.

Oura is useful open-source developer and infrastructure tooling for Cardano. It provides a Rust-native event pipeline that connects to Cardano nodes, monitors blockchain activity, filters relevant events, and routes those events to downstream systems such as databases, webhooks, queues, analytics services and application backends.

This matters because many wallets, dApps, explorers, governance tools, indexers, monitoring systems and analytics platforms need reliable ways to process Cardano events without each team having to build and maintain custom event-pipeline infrastructure from scratch.

In the current NCL environment, I believe DReps need to be selective. My priority is to support focused proposals that maintain essential public goods, open-source infrastructure, developer tooling, protocol compatibility and the technical rails that Cardano builders rely on.

Oura fits that framework.

This is not a speculative growth proposal. It is a modest, scoped maintenance request for an existing open-source tool. The work covers dependency updates, Cardano protocol compatibility, performance improvements, bug fixes, documentation, community support, issue triage, review of external contributions and continued improvements based on ecosystem feedback.

I also view it positively that Oura is built on Pallas, has an active open-source footprint, and supports a wide range of data sources and output sinks. That makes it useful for production infrastructure, low-resource setups, monitoring, indexing, analytics and real-time event processing.

The proposal is modest in size compared with many other live treasury requests and is structured through the 2026 treasury management framework, with Intersect administration, oversight controls, milestone-based disbursement and community auditability.

While I rank Oura slightly below the most foundational TxPipe proposals such as Pallas and Dolos, I still consider it a valuable part of the Cardano developer infrastructure stack. Under my “fund the rails before the growth bets” approach, this is the kind of practical maintenance work the treasury should support.

For these reasons, I consider this a responsible and proportionate use of treasury funds.

I vote YES.

I am voting NO on the Strike Finance Liquidity Deployment proposal.

This is not a vote against Strike Finance, Cardano DeFi, perpetual futures, or productive treasury thinking. Strike has built a real product with meaningful traction, and I recognise the argument that deeper stablecoin liquidity could support more Cardano-native trading activity.

However, I do not believe this is the right use of the Cardano Treasury at this time.

The proposal requests 9,000,000 ADA to be sold for USDM and deployed into Strike Finance V2 liquidity infrastructure for 12 months. Although the proposal is structured as a returnable deployment rather than a grant, it still exposes treasury assets to material risk, including ADA price appreciation risk, stablecoin risk, smart-contract risk, yield underperformance, custody risk and market-making risk.

My concern is also one of precedent. I am not comfortable with the Cardano Treasury becoming an active liquidity allocator into a derivatives venue. That is a materially different function from funding open-source public goods, security-critical infrastructure, developer tooling, wallet maintenance, protocol readiness or clearly scoped ecosystem infrastructure.

In the current NCL environment, I believe DReps need to be especially disciplined. The NCL is a ceiling, not a spending target. Treasury capacity should be prioritised for proposals with broad public-good value, direct ecosystem utility, limited downside risk and clear long-term benefit to Cardano.

Strike may be valuable to the ecosystem, but this proposal asks the Treasury to take on risk that I do not think is appropriate for a public treasury at this stage. The potential return does not outweigh the governance, precedent and capital-risk concerns for me.

For these reasons, I vote NO.

I am voting YES on the TxPipe UTxO RPC proposal.

UTxO RPC is important developer infrastructure for Cardano because it helps standardise how applications, tools, SDKs and services interact with UTxO-based blockchain data.

This is not the same as funding another hosted API provider like Blockfrost or Koios. UTxO RPC sits at a different layer. It is an open interface specification that can be implemented by different backends and used across multiple languages and developer environments.

That matters because Cardano needs more interoperability, less integration fragmentation, and better developer experience. A common interface for UTxO-based data access can make it easier for wallets, dApps, indexers, SDKs, infrastructure providers and future tooling to communicate in a consistent way.

In the current NCL environment, I believe DReps need to be selective. My priority is to support scoped proposals that maintain essential public goods, open-source infrastructure, developer tooling, protocol compatibility and the technical rails that Cardano builders rely on.

UTxO RPC fits that framework.

The proposal is modest in size compared with many other live treasury requests and is focused on maintenance, compatibility, SDK support, documentation, community support and continued improvement of a standard already used by several ecosystem workstreams.

I also view it positively that this proposal is structured through the 2026 treasury management framework, with Intersect administration, oversight controls, milestone-based disbursement and community auditability.

There is some overlap with other data access tools and providers in the ecosystem, but I do not see that as a reason to reject it. Cardano benefits from having open, interoperable, self-hostable and implementation-neutral standards that reduce reliance on any single provider or integration path.

For these reasons, I consider this a responsible and proportionate use of treasury funds.

I vote YES.

I am voting YES on the TxPipe Dolos proposal.

Dolos is important infrastructure for Cardano because it provides a lightweight Cardano data node designed to give developers efficient access to chain data without requiring the full overhead of traditional node infrastructure.

This matters because developer access to reliable chain data is one of the core rails of the ecosystem. Wallets, explorers, dApps, indexers, analytics platforms, governance tools and developer backends all depend on being able to query and consume Cardano data efficiently.

Dolos also improves infrastructure diversity. It supports multiple familiar interfaces, including Mini-Blockfrost, UTxO-RPC, Mini-Kupo and node-compatible tooling. This gives builders more optionality and reduces reliance on a small number of hosted or centralised API providers.

In the current NCL environment, I believe DReps need to be selective. My priority is to support scoped proposals that maintain essential public goods, open-source infrastructure, developer tooling, self-hosting capability and the technical rails Cardano builders rely on.

Dolos fits that framework.

I view this proposal as one of the stronger TxPipe maintenance proposals because it supports decentralised access to chain data and gives developers another practical infrastructure path. It is not a broad speculative growth proposal. It is a focused maintenance and enhancement request for a useful open-source data-node layer.

I also view it positively that the proposal is modest in size compared with many other live treasury requests and is structured through the 2026 treasury management framework, with Intersect administration, oversight controls, milestone-based disbursement and community auditability.

There is some overlap with existing API and data-access providers such as Blockfrost, Koios, Ogmios and Kupo-style tooling. However, I see that overlap as part of the value rather than a reason to reject it. Cardano should not depend on a narrow set of infrastructure access points. More self-hostable, open-source and interoperable options make the ecosystem stronger.

For these reasons, I consider this a responsible and proportionate use of treasury funds.

I vote YES.

I am voting YES on the TxPipe Pallas proposal.

Pallas is core developer infrastructure for Cardano. It provides Rust libraries for important Cardano primitives, including ledger data structures, serialization, cryptography, transaction building, chain synchronization, multi-era support, and node communication.

This is not a speculative growth proposal. It is a focused maintenance request for open-source tooling that sits low in the Cardano development stack and is used by multiple downstream projects and developer tools.

In the current NCL environment, I believe DReps need to be selective. My priority is to support proposals that maintain critical public goods, core developer infrastructure, protocol compatibility, open-source libraries, and the technical rails that Cardano builders rely on.

Pallas clearly fits that category.

I consider this one of the stronger TxPipe proposals because it is foundational. Higher-level tools and applications depend on reliable lower-level libraries. If those libraries fall behind ledger changes, hard forks, dependency updates or protocol evolution, the impact can propagate across the ecosystem.

I also view it positively that this proposal is modest in size compared with many other live treasury requests and is structured through the 2026 treasury management framework, with Intersect administration, oversight controls, milestone-based disbursement and community auditability.

Given the current budget pressure, I am prioritising infrastructure and maintenance over larger speculative or commercial proposals. Pallas is exactly the type of low-level open-source developer tooling that the treasury should be willing to maintain.

For these reasons, I consider this a responsible and proportionate use of treasury funds.

I vote YES.

I am voting YES on the revised Scalus 2026 proposal.

My previous concern with Scalus was not that the technology lacked value, but that the earlier proposal was too broad, too expensive, and tried to fund too much at once relative to demonstrated demand and current treasury capacity.

This revised proposal materially addresses those concerns.

The ask has been reduced significantly to 2,464,844 ADA over 9 months, with no contingency. The scope has also been narrowed meaningfully. The standalone L1 node, full L2 integration, and broad formal-verification work are now out of scope. Instead, the proposal focuses on maintaining the existing Scalus stack, preparing it for Dijkstra, improving interoperability across JVM and JavaScript/TypeScript ecosystems, and validating a bounded application-runtime step.

That is a much more proportionate and responsible request.

Scalus is already used directly or indirectly across parts of the Cardano developer ecosystem, including projects and tools such as Gummiworm L2, Bifrost, SugarRush, Vela, DID/DIDComm, MeshJS, Evolution SDK, Lucid Evolution, Cardano Client Lib, and YaciDevKit. I believe there is value in maintaining and improving a JVM-native development path for Cardano, especially where it supports serious protocol, DeFi, bridge, identity, and enterprise-style application development.

In the current NCL environment, I am prioritising infrastructure, developer tooling, compatibility work, self-custody, and open-source public goods over larger speculative or commercial treasury requests. This revised Scalus proposal fits that framework far better than the original version.

I also view positively the milestone-based delivery structure, independent oversight, third-party assurance, financial audit allocation, escrow-based treasury management, and automatic return of unused funds.

This is a good example of governance working as intended: DReps and the community raised concerns, the proposer listened, and the revised proposal came back smaller, narrower, and more accountable.

For these reasons, I consider this a responsible use of treasury funds.

I vote YES.

I am voting NO on the Cardano Builder DAO proposal.

I want to be clear that this is not a vote against builders, dApps, ecosystem growth, or the idea that Cardano needs better outcome-based funding. I recognise that the Cardano Builder DAO has already operated funding rounds, distributed capital to projects, built a community of builders, and returned unused ADA to the treasury.

However, I do not believe this proposal is the right allocation of treasury funds in the current environment.

The request is very large at 20,000,000 ADA, and it effectively asks DReps to allocate a significant amount of treasury capacity to a secondary funding body. In my view, that creates accountability, prioritisation and delegation concerns.

Cardano is now in an environment where the Net Change Limit is under significant pressure and many live proposals are competing for limited remaining capacity. Under those conditions, I believe DReps should prioritise direct, clearly scoped, critical infrastructure and public-good maintenance before large meta-funding mechanisms.

My concern is not that Builder DAO has done nothing. My concern is that allocating such a large amount to another funding layer weakens direct DRep accountability over treasury spending. DReps were elected and delegated to make difficult prioritisation decisions, not to pass a major portion of that responsibility to another committee or DAO unless the mandate, limits, governance protections, conflict controls and measurable return profile are exceptionally strong.

I also have concerns around potential conflicts of interest in builder-led funding structures. Even where processes are transparent and well-intentioned, a DAO composed of ecosystem participants allocating funds to ecosystem participants needs an extremely high governance bar. In this case, I do not believe the structure justifies the size of the ask while the treasury budget is so constrained.

I support targeted funding for builders when proposals are direct, specific, measurable and proportionate. I am not comfortable supporting a 20M ADA treasury withdrawal into a broad secondary allocation mechanism at this time.

For these reasons, I vote NO.

I am voting YES on the MLabs Core Tool Maintenance & Enhancement: Plutarch and Ply proposal.

Plutarch and Ply are important developer tools for Cardano smart contract development. They help teams write, compile, serialize, test and maintain production on-chain applications, with Plutarch supporting efficient smart contract development through compilation to UPLC, and Ply helping bridge scripts into blueprint-style artifacts.

In the current NCL environment, I believe DReps need to be selective. My priority is to support proposals that maintain essential public goods, developer infrastructure, security-critical tooling and the core rails that allow Cardano builders to keep building.

This proposal fits that framework.

It is not a broad speculative growth proposal. It is a focused maintenance and enhancement request for tooling already used by Cardano builders. The work prioritises critical breakages, serious vulnerabilities, protocol-era and hard-fork compatibility, bug fixes, correctness improvements, optimisations, documentation and developer-experience improvements.

I also view it positively that the proposal discloses prior treasury funding, sets out a clear budget, includes Intersect administration, provides for oversight and milestone-based disbursement controls, and is structured through the 2026 treasury management smart contract framework.

The requested amount is material, but proportionate when compared with larger and more speculative treasury asks currently competing for limited NCL capacity. Cardano needs to preserve and maintain the tooling that production teams rely on, especially as Plutus, UPLC and ledger-era changes continue to evolve.

For these reasons, I consider this a responsible use of treasury funds and a good example of the type of developer infrastructure maintenance the treasury should support.

I vote YES.

I am voting YES on the Daedalus Wallet Maintenance and Improvements 2026–2027 proposal.

Daedalus remains a unique and important part of the Cardano ecosystem. It is Cardano’s only full-node desktop wallet, allowing users to verify the chain directly rather than relying on third-party APIs or trusted backend services. That makes Daedalus materially different from light wallets and important for self-sovereignty, client diversity, decentralisation, and resilient access to Cardano.

This proposal is a focused maintenance and improvement request, not a speculative growth proposal. It funds ongoing protocol compatibility, hard fork readiness, node and wallet backend updates, dependency and security maintenance, platform support, release engineering, user support, Japanese localisation, hardware wallet support, and future-facing improvements such as CIP-30 dApp connector support.

In the current NCL environment, I believe DReps need to be selective and prioritise core infrastructure. My approach is to support proposals that maintain essential public goods, security-critical systems, developer/user access, self-custody, and decentralised infrastructure before larger or more speculative treasury requests.

Daedalus clearly fits that category.

I also note positively that the proposal includes a defined scope of work, measurable success criteria, independent financial audit funding, Intersect administration, milestone-based oversight, and return of unspent funds. These are important safeguards for a treasury withdrawal.

The ask is material, but I consider it proportionate given the importance of maintaining Cardano’s only full-node desktop wallet through upcoming protocol changes and ecosystem upgrades.

For these reasons, I believe this is a responsible use of treasury funds.

I vote YES.

I am voting YES on the Hardware Wallet Maintenance proposal.

Hardware wallets are critical security infrastructure for Cardano. They support safe custody, staking, governance participation, transaction signing, and DRep voting for many users who choose not to expose private keys to hot wallets.

This proposal is a focused maintenance request rather than a speculative growth proposal. It supports continued Ledger and Trezor compatibility, Cardano hardware-wallet tooling, integration support, vendor coordination, audits, protocol upgrade readiness, and ongoing maintenance required to keep this part of the ecosystem reliable.

In the current NCL environment, I believe DReps need to be highly selective. My priority is to support proposals that maintain essential public goods, security-critical infrastructure, self-custody, and developer/user access to Cardano.

Hardware wallet support clearly fits that category.

The requested amount is material, but proportionate given the importance of the work. If this infrastructure is not maintained properly, the downside risk is significant: degraded wallet compatibility, weaker self-custody UX, reduced governance participation, and increased friction for users who rely on cold-storage signing.

For those reasons, I consider this a responsible and necessary use of treasury funds.

I vote YES.

I recognise Blockfrost as important Cardano infrastructure and I appreciate the effort to move it toward a community-governed, not-for-profit public-good model. However, I am voting NO because I do not believe this proposal resolves the core sustainability problem.

Moving Blockfrost into a not-for-profit structure changes who bears the cost, but it does not remove the cost. Servers, operations, maintenance, development and support still need to be paid for. This proposal funds an 18-month runway, but the long-term model after that period remains too uncertain. In practice, this risks turning Blockfrost into a recurring treasury-funded operating expense.

Under the current NCL constraint and with many competing treasury requests, I believe limited funds should be prioritised for actions with clearer exit paths, stronger self-sustainability plans, and more defined post-funding accountability. I would be open to reconsidering a future proposal that provides a concrete long-term revenue/vendor model, decentralisation milestones, and a clearer plan to avoid ongoing treasury dependency.

This is not a rejection of Blockfrost’s value. It is a vote for treasury discipline and sustainable public-good funding.

I am voting NO on this proposal.

I recognise the value of the Technical Steering Committee and the importance of protocol governance, CIP editorial capacity, hard fork coordination, parameter review, and independent technical input for Cardano. The requested amount of 1.193M ADA is modest compared with many current treasury actions, and several parts of the proposal appear worthwhile in principle.

However, this action is explicitly dependent on the approval of the broader IntersectMBO Governance Coordination and Technical proposal, which is requesting 25.4M ADA and which I do not support in its current form. Taken together, these Intersect-related requests represent a significant draw on the remaining Net Change Limit.

Given that there is now approximately 58M ADA remaining in the NCL and live governance actions are requesting close to 100M ADA, DReps have a responsibility to apply strict prioritisation. In this environment, even proposals with merit need to be assessed against treasury scarcity, funding dependencies, and opportunity cost.

In my view, this proposal should be resubmitted as a cleaner, standalone TSC funding request, focused tightly on the highest-impact functions: protocol governance, CIP editing, hard fork coordination, parameter analysis, and independent technical review. I would be more open to supporting that narrower version if it were not tied to the larger 25.4M ADA Intersect budget structure.

This is not a rejection of the TSC’s importance. It is a vote for treasury discipline, clearer separation of funding requests, and stronger prioritisation under NCL scarcity.

I am voting YES on this Treasury Withdrawal for the Mithril Protocol.

While the remaining Net Change Limit is now tight, with only around 76.8M ada left, I believe Mithril remains one of the higher-priority uses of Treasury funding. This is not a discretionary marketing spend or a vague ecosystem programme. Mithril is core Cardano infrastructure that supports faster and more secure access to chain state, light-client verification, improved bootstrapping, cross-chain and Layer 2 use cases, and reduced reliance on centralised infrastructure.

The request for 3,810,423 ada is material in the current NCL environment, but proportionate given the importance of Mithril to Cardano’s long-term scalability, decentralisation, and developer infrastructure. I also recognise that this proposal has come through the Intersect budget process and includes an administration and oversight structure rather than a simple unmanaged withdrawal.

My support is not a signal that all remaining Treasury requests should be approved. Quite the opposite: with the NCL becoming increasingly constrained, I believe DReps need to become more selective. I will prioritise core infrastructure, security, open-source tooling, and proposals with clear delivery value over lower-priority or less measurable spending.

Mithril clears that bar for me. It is important, public-good infrastructure for Cardano, and I believe it deserves to be funded.

I am voting NO on this Treasury withdrawal.

I recognise that governance coordination, technical stewardship, release coordination and incident response are important functions for Cardano. However, I do not believe this 25.4m ada request represents sufficient value for money in the context of the remaining Net Change Limit.

Based on the practical remaining NCL position, this proposal would consume a very large share of the remaining available budget. That creates a serious opportunity cost for other governance, tooling, infrastructure and ecosystem proposals still seeking funding.

My concern is not that the work has no value. My concern is that the proposal is too large, too bundled, and concentrates too much coordination funding into a single organisation. Cardano governance should continue moving toward a more decentralised, competitive and transparent delivery model, where critical functions are funded with clear scope, measurable outputs, lean budgets and strong accountability.

I would be open to supporting a smaller, more focused proposal for genuinely critical technical stewardship, incident response, repository coordination and governance process support. But I do not believe this broad 25.4m ada withdrawal is the right use of scarce treasury capacity at this stage.

For those reasons, I am voting NO.

I vote No on this Treasury Withdrawal.

I support the ambition behind this proposal and recognise the value of bringing real-world agricultural identity, data, financing, and trust infrastructure onto Cardano. The proposal has credible intent, relevant partners, existing progress, and a serious attempt to align with Cardano’s constitutional requirements for Treasury withdrawals.

However, I do not believe this proposal is ready for a 10M ADA Treasury withdrawal in its current form.

The requested amount is significant, the programme is complex and multi-country, and the execution risk remains high. The proposal appears to rely on substantial scaling from current adoption levels to a much larger farmer and farm registration target within 18 months. I would need to see stronger demand-side validation from buyers, lenders, insurers, governments, or other institutional users before supporting a Treasury request of this size.

I am also concerned that the first tranche is too large and front-loaded relative to the current level of proven traction and operational maturity. For a proposal of this scale, I would prefer clearer country-level delivery plans, stronger signed commitments, more granular unit economics, a fully established legal structure, and tighter milestone-based release conditions.

This is not a rejection of the mission. I would be open to supporting a revised proposal with a smaller initial tranche, clearer measurable milestones, stronger evidence of demand, and more robust safeguards for Treasury funds.

For now, I believe the responsible vote is No.

I am voting YES on Eternl: Path to Sustainability v2.

Eternl is important user-facing infrastructure for Cardano. It supports ordinary ADA holders, delegators, DRep participation, staking, dApp usage, governance interaction, and the broader usability of the ecosystem. In my view, mature wallet infrastructure is not optional if Cardano is serious about adoption, decentralised governance, and real-world utility.

The previous proposal failed to receive a constitutional vote from the Constitutional Committee, and I believe the feedback was valid. Treasury withdrawals must meet a high standard around audit allocation, oversight metrics, administrator responsibility, refund conditions, and transparency. This revised version appears to have responded directly to that feedback by clarifying the audit and oversight provisions, naming the administrator, disclosing prior treasury receipts, and setting out refund / repayment mechanics.

I also support the sustainability direction of the proposal. Treasury funding should not become permanent dependency, but in this case the proposal includes a pathway toward paid-plan revenue, public reporting, and potential repayment or return of surplus value to the Cardano Treasury. That is the correct model: support critical infrastructure while expecting discipline, transparency, and a route away from ongoing treasury reliance.

My YES vote is therefore based on three points: Eternl’s proven value to the Cardano ecosystem, the improvements made in v2 following constitutional feedback, and the expectation that the team will provide transparent reporting, auditable use of funds, and clear accountability throughout the funded period.

I am voting YES on the Van Rossem Hard Fork.

This is exactly the kind of core protocol upgrade Cardano should be supporting: technically reviewed, constitutionally appropriate, infrastructure-focused, and designed to improve the long-term capability of the network. Moving to protocol version 11 strengthens Cardano’s smart contract and ledger foundations, introduces important new Plutus primitives, improves developer experience, and supports more advanced applications being built on Cardano.

This is not a speculative treasury request or vague ecosystem initiative. It is a serious protocol upgrade with clear scope, clear technical rationale, and strong alignment with Cardano’s long-term mission as a secure, decentralised, high-assurance blockchain.

Subject to the required hard fork readiness and SPO upgrade thresholds being met, I am a resounding YES.

I am voting YES on this proposal because I believe it represents a materially improved and more focused version of the previous Tweag treasury request. The scope has been narrowed significantly, the requested amount has been reduced, and the remaining work packages are directly relevant to Cardano’s core infrastructure, scalability, decentralisation, and long-term protocol resilience.

Peras, conformance testing, and History Expiry are not speculative ecosystem extras; they are important pieces of foundational infrastructure. Faster practical finality, stronger multi-implementation confidence, and reduced long-term node storage burden all support Cardano’s ability to scale while preserving decentralisation and operational robustness.

My support is based on the expectation that this proposal is delivered with strong milestone-based oversight, transparent reporting, independent assurance, and appropriate handling of any unused funds. Treasury funding should not be treated as a blank cheque, especially for large technical infrastructure work. However, when the scope is clear, constitutionally aligned, and strategically important to the network, I believe the treasury should support high-quality core development.

For those reasons, I am voting YES.

I am voting YES on this Treasury Withdrawal to reimburse the Ikigai governance action deposit.

My rationale is that this appears to be a narrow and exceptional restitution case arising from an early Voltaire-era governance/node issue, where a good-faith participant lost the ability to recover a ₳100,000 governance action deposit. I do not view this as normal treasury funding, nor as a precedent for reimbursing failed proposals, user error, rejected actions, or ordinary opportunity cost.

The requested amount is small, fixed, and clearly scoped. Supporting reimbursement here helps maintain trust in Cardano governance during the early implementation phase, especially for participants who engaged constructively and were affected by technical edge cases outside their control.

I support this action on the basis that it is a one-off correction for a specific governance implementation issue, not a general policy of compensating governance participants for unsuccessful or unrecovered deposits.

I am voting No on this governance action as submitted.

I recognise Rare Network’s long-standing contribution to the Cardano ecosystem, and I see genuine value in Rare Dev Gov Day as a coordination venue for builders, DReps, SPOs, governance participants, and the wider Cardano community. I also appreciate the attempt to include Treasury return mechanics through a share of VIP ticket revenue.

However, I do not believe this proposal is structured in a way that justifies a Treasury withdrawal of ₳2,750,000. My main concern is that it bundles a potentially valuable governance and developer coordination event with a broader title sponsorship and marketing package for Rare Evo 2026. Rare Evo will happen regardless of Treasury funding, so this request appears to be funding an incremental branding and sponsorship layer rather than a clearly necessary public good.

I believe the Cardano Treasury should prioritise proposals with direct, measurable outcomes for protocol development, critical infrastructure, developer tooling, governance capability, adoption, and long-term ecosystem resilience. Event sponsorship can have value, but at this scale it needs a stronger case for measurable impact, tighter scope, clearer success metrics, and a more direct connection to outcomes that justify Treasury funding.

I would be open to reconsidering a revised proposal focused specifically on Rare Dev Gov Day, with a leaner budget, clear deliverables, audited reporting, and defined refund terms. As submitted, I cannot support the bundled request.

I am voting No on this Info Action.

I agree with the underlying concern that Cardano needs better treasury governance, clearer prioritisation, stronger accountability, and more effective coordination between proposers, DReps, SPOs, the Constitutional Committee, and the wider community.

However, I do not believe this proposal is defined clearly enough to justify an on-chain endorsement. It appears to signal support for a broad reform direction that may later require changes to governance processes or even constitutional interpretation, but it does not yet provide enough detail on the proposed model, accountability structures, decentralisation safeguards, implementation pathway, or how competing coordination approaches would remain open and permissionless.

Cardano does need better treasury coordination, but that coordination should emerge transparently through open tooling, public analysis, milestone tracking, community review, and competitive governance infrastructure — not through a broad mandate that risks pre-shaping the process before the ecosystem has fully debated the design.

For these reasons, I support continued discussion and future refinement, but I cannot support this Info Action in its current form.

I am voting YES on IO: Hydra because I believe Hydra is strategically important public infrastructure for Cardano.

Hydra directly supports Cardano’s long-term scalability by enabling faster, lower-cost, higher-throughput application environments while remaining anchored to Cardano. This is important for real-world use cases such as DeFi, payments, gaming, AI agent transactions, enterprise workflows, and other applications that require speed and low fees beyond what the L1 alone can practically provide.

I also view this proposal differently from the previous bundled L2 request. This is a more focused, standalone Hydra proposal, which makes it easier to evaluate on its own merits. I believe the community feedback around bundling was valid, and this revised approach is a better governance pattern.

My support is not a blank cheque. Treasury funding must be treated seriously, especially in the current budget environment. However, where a proposal funds core scaling infrastructure, has clear strategic relevance, supports developers, strengthens Cardano’s competitiveness, and is structured around milestone-based delivery and accountability, I believe it is reasonable for the treasury to support it.

Hydra is not a speculative marketing exercise. It is a technical capability that can help unlock more practical usage of Cardano. For that reason, I believe this proposal is aligned with Cardano’s constitutional principles around usability, predictable costs, developer access, and long-term sustainability.

On balance, I believe funding this work is in the best interests of the Cardano ecosystem, and I am voting YES.

I am voting ABSTAIN on the Scalus: Cardano’s Application Platform proposal.

I believe this proposal is directionally valuable and addresses a real challenge for Cardano: improving developer experience, application-layer infrastructure, smart contract tooling, verification workflows, and the ability for builders to ship production-ready applications more easily.

I also recognise that the Lantr / Scalus team has already delivered meaningful work, and this proposal is materially stronger than many treasury requests in terms of structure, technical ambition, milestone design, oversight, and treasury-control mechanisms.

However, I am not fully comfortable voting Yes on this version of the proposal.

The ask of ₳8.503m is significant, and I do not believe there is currently enough demonstrated adoption, community consensus, or proven demand from the wider developer market to justify approving this level of funding at this stage. The proposal may be technically strong, but treasury funding also requires proportionality, timing, and confidence that the requested investment matches ecosystem readiness.

I also take the current community signal seriously. The live voting trend shows substantial resistance, and while I do not believe that should automatically determine every DRep’s vote, it does suggest that the proposal has not yet won sufficient trust or conviction from the ecosystem.

My abstain vote is therefore not a rejection of Scalus, Lantr, JVM tooling, developer infrastructure, or application-layer investment. It is a signal that I would like to see this proposal return in a more staged, smaller, adoption-measured format with clearer evidence of demand and a more incremental funding path.

I support the direction, but I cannot actively support the full treasury ask in its current form.

For those reasons, I am voting ABSTAIN.

I am voting YES on this parameter-change proposal to reduce 'committeeMinSize' from 7 to 5.

My support is based on governance resilience and protocol liveness. This change does not, in my view, mean Cardano should move away from maintaining a strong seven-member Constitutional Committee. Rather, it creates a practical safety margin so that governance actions are not blocked if one or two CC seats are temporarily vacant.

The proposed value of 5 remains comfortably within the constitutional guardrails and avoids moving to the lower minimum of 3, which would create greater centralisation concerns. It is also a no-cost proposal with no treasury withdrawal.

I recognise the concern that reducing the minimum could weaken constitutional oversight if misused. However, I believe the stronger risk here is governance paralysis caused by vacancies or delayed committee replacement. Cardano needs robust checks and balances, but those checks must not become a single point of failure.

For those reasons, I support this proposal as a sensible operational resilience measure while continuing to expect the ecosystem to maintain a full, diverse, and accountable Constitutional Committee wherever possible.

I am voting YES on this proposal to update the Plutus cost models.

This is a necessary technical parameter update to support the van Rossem / Protocol Version 11 upgrade and enable new Plutus primitives across Plutus V1, V2 and V3. These primitives expand the built-in functionality available to Cardano smart contract developers, while the cost model ensures that CPU and memory usage are priced appropriately and safely at the protocol level.

This proposal appears aligned with the Cardano Constitution, particularly the Plutus Cost Model guardrails requiring cost model values to be benchmarked, updated when new primitives are introduced, and supplied for each supported Plutus language version.

I recognise that changes to existing cost settings may create some operational impact for dApps that rely on hardcoded or pre-calculated execution budgets. However, the proposal has been reviewed through the relevant technical process, is based on benchmarked cost model updates, and is important for Cardano’s continued smart contract capability and developer experience.

As this is a constitutionally aligned, technically necessary, non-treasury parameter update that supports Cardano’s protocol evolution, I am voting YES.

I am voting YES on Cardano Critical Integrations V2.

My view is that Cardano has already made a significant strategic commitment to critical integrations through CCI V1, and it would be poor treasury discipline to fund major integrations but then fail to maintain, support, and operationalise them properly.

The integrations covered by this proposal — including USDCx, Pyth, Dune, LayerZero, and Fireblocks — are important infrastructure for liquidity, DeFi, institutional access, analytics, interoperability, and broader ecosystem adoption. These are not peripheral “nice to have” items; they are part of the connective tissue Cardano needs if it is to compete as a serious global financial and application platform.

That said, my support is not unconditional. The size of the ask, the confidentiality around some vendor-level costs, and the fact that some CCI V1 work remains incomplete mean that the proposers must be held to a high standard of transparency, reporting, auditability, and delivery discipline. I expect clear milestone reporting, responsible fund management, and the return of unused funds where appropriate.

I see this as a vote for continuity, operational maturity, and adoption infrastructure — not as automatic approval for indefinite future funding. On balance, I believe this proposal is aligned with Cardano’s long-term interests and is constitutionally acceptable, so I am voting YES.

I am voting NO on the Cardano dOSPO and OMF Program.

I strongly support the underlying problem this proposal is trying to address. Cardano depends on open-source infrastructure, tooling, maintainers, SDKs, libraries and ecosystem contributors, and I do believe long-term open-source maintenance needs a serious and sustainable funding model.

However, I do not believe this proposal is the right structure for a ₳12m, 36-month treasury commitment.

My concern is not with the intent, but with the governance and funding model. This proposal appears to create a broad ecosystem funding institution that would itself allocate treasury resources to other parties. That is a much higher-risk model than funding a clearly scoped technical delivery with direct milestones, direct accountability, and stronger treasury controls.

For an ask of this size and duration, I would expect a more mature structure before funds are committed: clearer escrow mechanics, stronger on-chain enforcement, fully established independent governance before funding begins, tighter milestone-based release controls, and better coordination with existing Cardano open-source funding mechanisms such as Intersect’s open-source maintenance work.

I am also concerned about overlap and fragmentation. Cardano should absolutely fund critical open-source maintenance, but we should avoid creating parallel funding structures that duplicate or compete with existing ecosystem processes unless the need, scope and governance model are extremely clear.

In my view, this proposal is trying to solve an important problem, but it asks the treasury to take too much structural and governance risk up front.

I would be open to supporting a revised version that starts smaller, operates as a pilot, has stronger escrow and refund protections, is better integrated with existing ecosystem maintenance frameworks, and provides clearer accountability for how funds are selected, released, measured and audited.

For those reasons, I am voting NO.

I am voting YES because Gerolamo has the potential to materially strengthen Cardano’s decentralisation, client diversity, and developer infrastructure by enabling a browser-capable Cardano node. This aligns with Cardano’s long-term strategy and with my DRep principles of supporting open-source public-good infrastructure that improves resilience and reduces reliance on centralised service providers.

I recognise the delivery risk: Gerolamo is not yet a production-ready validating browser node, and the project must demonstrate real progress through its milestones. I would also like continued clarity around independent audit and oversight costs, milestone acceptance, and adoption pathways for wallets and dApps.

However, I believe this is the type of ambitious infrastructure work the treasury should support when paired with transparent delivery controls, refundable contingency, and independent oversight. For that reason, I support this proposal.

I am voting YES on Cardano Vision 2026.

While I understand the concerns around the size and breadth of this proposal, I believe this is one of the clearest examples of the type of long-term public-good investment the Cardano Treasury exists to support.

Cardano’s competitive advantage has always been its research-first foundation, high-assurance engineering culture, formal methods, and willingness to solve hard problems properly rather than chase short-term narratives. The work proposed here — including scalability, Leios/Peras research, post-quantum security, ZK, developer experience, governance, incentives and research-to-engineering translation — is not optional if Cardano is to remain technically credible over the long term.

I recognise the concern that this proposal is broad and bundled. However, in this case I believe the workstreams are deeply interconnected. Breaking this into many smaller proposals may appear cleaner from a governance perspective, but it also risks fragmentation, delay, loss of coordination, and potentially the loss of specialised talent that is extremely difficult to rebuild once dispersed.

My support is not a blank cheque. I expect clear milestone reporting, transparent oversight, community visibility, and the return of any unused or undisbursed funds in line with the proposal’s refund commitments. But I believe the strategic risk of failing to fund this research programme is greater than the risk of approving it.

For these reasons, I believe this proposal is aligned with Cardano’s long-term interests, its research-driven identity, and the responsible use of treasury funds for foundational ecosystem infrastructure.

I am voting NO on this proposal.

I recognise the ambition behind OriLife × TonFarm and I support the broader goal of bringing real-world adoption, supply-chain traceability, identity, and agricultural use cases to Cardano. The proposal is interesting, and I appreciate the work already done by the team, including the existing proof of concept, field deployment, and the attempt to structure the funding through milestones and escrow.

However, I do not believe this proposal currently meets the burden of proof required for a 2.4m ADA treasury withdrawal.

My concern is not with the sector or the idea itself. My concern is whether Cardano’s treasury should fund a large-scale vertical commercial deployment where the ecosystem-wide return remains uncertain. The projected adoption numbers are substantial, but they still appear highly aspirational without enough hard evidence of binding customer commitments, guaranteed transaction volume, or a clear path for the Cardano treasury and wider ecosystem to benefit proportionately from the investment.

I would be more comfortable supporting a smaller, staged proposal that proves real mainnet usage, demonstrates repeatable demand, and establishes clearer treasury-aligned economics before requesting funding at this scale. For commercial deployments, I believe the treasury should increasingly expect stronger repayment, revenue-sharing, or ecosystem-value mechanisms, especially where the funded infrastructure may directly benefit a private or semi-commercial operator.

This may become a strong Cardano real-world adoption case in the future, but at this stage I do not believe the risk/reward profile justifies the requested treasury spend.

For these reasons, I am voting NO.

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

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

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

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

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

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

For these reasons, I am abstaining.

I am voting NO on the TOKEN2049 Title Sponsorship Top-Up.

I support Cardano having a strong presence at major global events, and I recognise the value of TOKEN2049 as one of the most important conferences in the crypto industry. I also appreciate that the proposal has been structured with clearer administration, oversight, and refund provisions.

However, my concern is with the proportionality of this additional spend.

The baseline TOKEN2049 proposal already gives Cardano a meaningful presence at the event. This top-up is specifically asking the Treasury to fund an upgrade from Platinum to Title sponsorship, with benefits such as a larger booth, mainstage keynote slot, branding visibility, media introductions, lanyards, networking access, and other premium exposure.

Those benefits may well have value, but I do not believe the case has been made that this additional premium package is necessary or represents the best use of Treasury funds at this time.

This is not a vote against marketing, events, EMURGO, or Cardano being visible on the global stage. It is a vote against this specific incremental top-up. In my view, Treasury spending should be disciplined and proportionate, especially when the additional ask is for premium brand positioning rather than core delivery, infrastructure, builder support, or activity that is clearly essential to the ecosystem.

For those reasons, I am voting NO.

I am voting ABSTAIN on the Pogun proposal because I believe it raises genuinely important strategic questions for the future of Cardano, particularly around Bitcoin integration, BTCfi, liquidity growth and ecosystem capital formation.

I recognise the potential long-term value of bringing Bitcoin liquidity and economic activity into the Cardano ecosystem. I also appreciate that the proposal attempts to move beyond a simple grant model by exploring treasury-alignment concepts such as revenue sharing and repayment mechanisms. I believe this is a positive direction for governance maturity and ecosystem funding design.

However, I also believe this proposal sits in a more commercially oriented category than many of the protocol, infrastructure and public-goods-focused treasury requests currently under consideration.

As a DRep, I am increasingly focused on treasury stewardship, Net Change Limit constraints and the long-term sustainability of treasury allocation decisions. With approximately 13 months remaining in the current NCL window and many competing infrastructure, governance and ecosystem proposals still seeking funding, I am cautious about making strong affirmative allocations toward commercially speculative ecosystem growth initiatives at this stage.

My abstain vote therefore reflects both:

1 respect for the strategic ambition of the proposal,
2 and uncertainty around whether this type of ecosystem venture-style funding should currently be prioritised over more foundational public infrastructure and governance-critical ecosystem layers.

I believe Cardano governance is still collectively evolving its framework for how treasury funding should interact with commercially monetisable ecosystem businesses, particularly around:

1 repayment structures,
2 revenue-sharing models,
3 treasury participation in upside,
4 and long-term ecosystem capital allocation strategy.

I would welcome continued discussion and refinement in this area as Cardano governance matures further.

I am voting NO on the Blockfrost: Maintenance and Next Generation Indexing proposal, not because I believe Blockfrost lacks value to the Cardano ecosystem, but because I believe Cardano governance now needs to evolve toward a more sustainable and sophisticated treasury funding model for commercially viable infrastructure providers.

Blockfrost is clearly important ecosystem infrastructure. Many developers, wallets, applications and services rely on its APIs and indexing capabilities, and I recognise the strategic value of the proposed next-generation indexing work.

However, Blockfrost is also an operational commercial business with monetisable products, existing customers and a credible path toward long-term commercial sustainability.

As DReps, we are now operating under meaningful Net Change Limit constraints, with approximately 13 months remaining in the current NCL window and many competing infrastructure, adoption and research proposals still seeking treasury funding.

Because of this, I believe Cardano governance should begin distinguishing more clearly between:

1 pure public goods,
2 ecosystem-critical open infrastructure,
3 and commercially monetisable ecosystem businesses.

In cases where treasury funding is used to accelerate commercial infrastructure providers, I believe future proposals should increasingly explore:

1 repayment mechanisms,
2 treasury revenue-sharing,
3 ecosystem pricing guarantees,
4 or other models that allow the Cardano treasury and community to participate in the upside created by treasury-funded ecosystem growth.

I do not believe perpetual operational subsidy through treasury withdrawals should become the default model for commercially viable infrastructure businesses.

This vote is therefore not a rejection of Blockfrost’s technical contributions or ecosystem importance. It is a reflection of my broader view that Cardano governance is maturing from simple grant distribution toward more disciplined treasury stewardship and long-term capital allocation thinking.

I would welcome a revised proposal structure in the future that incorporates stronger treasury-alignment mechanisms alongside the important infrastructure work being proposed.

I am voting YES on the Revised Cardano Summit 2026 Singapore proposal because I believe Cardano needs credible external visibility, ecosystem coordination and real-world adoption efforts alongside protocol and infrastructure development.

Importantly, this revised proposal responded constructively to community feedback. The budget was reduced materially, the Summit was decoupled from TOKEN2049, and the proposal now includes clearer scope, measurable KPIs and a more focused delivery approach.

While I remain mindful of treasury discipline and current NCL constraints, I also believe Cardano cannot rely solely on technical excellence to grow. Developer engagement, enterprise visibility, institutional networking and ecosystem showcase events all play a role in long-term adoption and ecosystem expansion when executed responsibly.

I recognise the concerns around event ROI and large ecosystem spending. Those concerns are valid, and future treasury-funded events should continue moving toward stronger accountability, measurable outcomes and efficient budgeting.

However, on balance, I believe the revised proposal represents a significantly improved and more reasonable approach compared with the original version, and I believe supporting a well-scoped flagship ecosystem event is aligned with Cardano’s broader growth and adoption goals.

This vote aligns with my broader DRep philosophy of supporting:

1 sustainable ecosystem growth,
2 external adoption and visibility,
3 developer and enterprise engagement,
4 responsible treasury stewardship,
5 and long-term Cardano ecosystem resilience.

I am voting YES on the Eternl treasury proposal because I believe independent wallet and access infrastructure is critical to Cardano’s long-term usability, decentralisation and governance participation.

Eternl is already widely used across the ecosystem for staking, DApp interaction, payments and on-chain governance. Supporting reliable wallet infrastructure helps ensure users can actually participate in the Cardano ecosystem, not just theoretically benefit from protocol-level improvements.

The proposal is also relatively modest in size compared with many current treasury requests and includes a path toward greater long-term sustainability through a Pro-plan revenue model and treasury repayment mechanics.

I recognise the concerns raised around closed-source components, self-administration and the lack of milestone-based disbursement. I believe those concerns are valid and should continue to be discussed as Cardano governance matures.

However, on balance, I believe the practical ecosystem value of maintaining stable, independent wallet infrastructure outweighs those concerns in this case.

This vote aligns with my broader DRep philosophy of supporting:

1 critical ecosystem infrastructure,
2 decentralisation in practice,
3 governance participation,
4 user accessibility,
5 and sustainable long-term ecosystem growth,

while still remaining mindful of treasury discipline and responsible capital allocation under current NCL constraints.

I voted YES on IO & VacuumLabs: Enhancing Plutus because Plutus is foundational to Cardano’s smart-contract ecosystem. The proposal improves execution efficiency, expands useful primitives, strengthens formal specification and conformance testing, and improves developer tooling through better compiler architecture, clearer errors, reduced boilerplate, and easier setup. These improvements support lower-cost DApps, better developer experience, stronger security, and future node diversity. The ask is proportionate to the importance of Plutus as core infrastructure and the collaboration with VacuumLabs helps broaden stewardship beyond IO.

I voted YES on IO: Cardano High Assurance Technical Collaboration because security and correctness are central to Cardano’s long-term value proposition. This proposal makes formal verification more accessible to everyday developers by extending Blaster to DApp-level verification, integrating with major Cardano smart contract languages, delivering a VS Code extension, building a Common Vulnerability Library, and providing a preconfigured developer environment. As Cardano grows DeFi, bridges, stablecoins, and institutional use cases, stronger verification tooling reduces exploit risk and increases trust. The ask is proportionate, collaborative across multiple ecosystem teams, and aligned with Cardano’s high-assurance identity.

I voted YES on the IO & Midgard Labs L2 Scalability Initiative because Cardano needs credible L2 infrastructure alongside L1 scaling to compete for high-performance applications such as DeFi, AI micropayments, gaming, and consumer payments. The proposal funds shared L2 infrastructure, Hydra production hardening, and Midgard’s path to mainnet, giving Cardano a broader scaling portfolio rather than relying on a single approach. I recognise the valid concern that these workstreams could have been separated because they carry different maturity and risk profiles. However, the ask is modest relative to the potential ecosystem benefit, remains within the Net Change Limit, and supports adoption, throughput, TVL, and protocol revenue.

I voted YES on the Cardano Maintenance Initiative because a stable, secure, and well-maintained Cardano platform is the foundation for every other ecosystem objective. The proposal funds essential work across node bugfixing, security reviews, CI/CD, monitoring, performance, QA, release management, incident response, DB-Sync, APIs, CLI tooling, Plutus Core maintenance, and the Cardano Blueprint. While the ask is large and must be scrutinised carefully, underfunding core maintenance would create unacceptable technical and operational risk for the network. My support is conditional on strong milestone-based disbursement, independent assurance, transparent reporting, and return of unspent funds.

I voted YES on the IO Consensus Initiative because Leios is a critical base-layer scaling upgrade for Cardano. The proposal funds the path from public testnet toward a mainnet-ready release candidate, including formal conformance testing, adversarial validation, parameter exploration, and hard-fork enabling work. Cardano’s 2030 adoption targets require a major throughput increase at L1, not only L2 scaling, and Leios directly addresses that requirement while preserving Cardano’s security and decentralisation principles. The ask is significant but proportionate to the strategic importance of the work and remains within the applicable Net Change Limit.

I voted YES on IO: Cardano Upgrades because the proposal funds strategically important platform-level improvements that directly support Cardano adoption, DeFi usability, treasury resilience, and ecosystem growth. CIP-159 account address enhancements can unlock micro-fees, cheaper DeFi batcher models, wallet revenue models, and L2 reserve patterns. Multi-Asset Treasury design is an important step toward reducing treasury exposure to ADA volatility and enabling more sustainable budgeting. Babel Fees removes a major onboarding barrier by allowing users to pay transaction fees in native assets rather than needing ADA first. The ask of ₳13.1M is meaningful but proportionate to the protocol-wide impact and remains well within the current Net Change Limit. I recognise concerns around bundling, budget granularity, and the wider IO package, but this specific proposal is strongly aligned with long-term utility, adoption, and Cardano’s competitiveness.

I support this proposal because improving Cardano’s developer experience is a high-leverage investment in adoption, utility, and ecosystem growth. The current builder journey remains fragmented, with tooling, documentation, onboarding, and reusable contract patterns spread across the ecosystem. This initiative addresses those issues through practical deliverables including cardano-init, an OpenZeppelin-style contracts library, Developer Portal improvements, bounties, outreach, and measurable DevX assessment. The ask of ₳3.6M is modest relative to the Net Change Limit, and the proposal includes milestone-based disbursement, Intersect administration, independent assurance, auditable treasury contracts, refund conditions, and prior treasury disclosure. While I recognise concerns about the wider IO funding package and potential overlap with other initiatives, this specific proposal is well aligned with long-term Cardano adoption and builder growth.

I am voting NO on the original Cardano Summit 2026 and TOKEN2049 Singapore treasury withdrawal. I support Cardano having a strong global presence, and I am not opposed to a Cardano Summit or a targeted TOKEN2049 strategy in principle. However, this proposal bundles two materially different spending decisions into one vote, requests a very large treasury allocation, and does not provide a sufficiently convincing ROI case for the scale of spend. The subsequent community pushback and the move toward revised standalone Summit and TOKEN2049 proposals confirms that the original structure was not the right approach. Treasury funds should be deployed with strong discipline, clear voter choice, measurable ecosystem impact, and the highest possible accountability. For those reasons, I believe the original bundled proposal should be rejected and considered only through leaner, separate, better-scoped proposals.

NO — I support the strategic value of HLabs’ work on Gerolamo, Pebble and TypeScript ecosystem maintenance, and I believe these workstreams could materially improve Cardano’s decentralization, developer experience and infrastructure resilience. However, this Treasury Withdrawal does not clearly satisfy Article II, Section 7(4) of the current Cardano Constitution, which requires an allocation of ADA for periodic independent audits and oversight metrics. The proposed escrow and oversight board are strong safeguards, but they do not clearly replace the need for an explicit audit/oversight allocation in the funding request itself. Given the size of the request and the importance of maintaining clean Treasury standards, I am voting NO on this version while encouraging HLabs to resubmit with the constitutional gap addressed and clearer budget separation.

I support this proposal as a necessary and pragmatic step to ensure the continuity of Project Catalyst operations. The transition of the managing entity from Input Output Global to the Cardano Foundation is required under the Catalyst Foundation Company’s statutes and helps prevent disruption to ongoing Fund 10–14 project delivery and payouts.

This action does not introduce new spending or alter governance structures but instead safeguards existing commitments and protects the integrity of the ecosystem. It aligns with the principles of accountability and responsible stewardship outlined in the Cardano Constitution.

While broader improvements to Catalyst’s effectiveness and impact may still be needed, maintaining operational continuity is the correct and responsible course of action at this stage. For these reasons, I am voting YES.

I support this proposal as a measured, well-structured first step toward addressing one of Cardano’s most critical gaps: DeFi liquidity. Rather than deploying large capital immediately, this withdrawal prudently focuses on establishing the legal, technical, and governance infrastructure required to manage funds responsibly. This staged approach aligns strongly with the Cardano Constitution (Article I, Sections 6 & 7), particularly around transparency, defined terms of withdrawal, auditability, and clear refund conditions.

The proposal demonstrates strong fiscal discipline and risk awareness: development is contributed at zero cost, funds are milestone-based, unused ADA is returned, and there are explicit failure/refund clauses covering legal, technical, and governance risks. The use of a 5-of-9 multisig (Amaru contract), monthly reporting, and independent audit further strengthens accountability and decentralised oversight.

Importantly, this initiative builds on prior community signalling (~67% support) and targets a high-impact area with potential ecosystem-wide ROI. Deep liquidity is foundational for stablecoins, DeFi growth, and broader adoption—without it, Cardano risks stagnation relative to other ecosystems.

While I will expect continued scrutiny in future withdrawals (particularly capital deployment and performance metrics), this initial tranche is proportionate, constitutionally compliant, and strategically sound.

Vote: YES — prudent groundwork for scalable, accountable DeFi growth on Cardano.

Vote: YES

This proposal represents a high-impact investment in core infrastructure resilience and decentralisation, which are foundational to Cardano’s long-term success. Today, block production relies on a single Haskell implementation, creating systemic risk. Dingo introduces a second independent node implementation in Go, materially improving network robustness—an approach proven effective in ecosystems like Ethereum.

Blink Labs has demonstrated credible delivery capability, with substantial prior output (1,000+ PRs, full Plutus conformance, working infrastructure components already in production). This is not a speculative idea, but an advanced, partially completed system requiring funding to reach mainnet readiness.

From a cost and ROI perspective, the proposal is reasonable and competitive. The requested 6.9M ADA (~$2.07M) covers a full year of engineering, audit, and delivery, and is priced conservatively relative to comparable efforts. The inclusion of a security audit, milestone-based escrow, independent oversight board, and on-chain accountability mechanisms significantly reduces execution risk and aligns with responsible treasury usage.

Importantly, the proposal is strongly aligned with the Cardano Constitution (v2.4):

Supports ecosystem growth and technical decentralisation
Includes transparent fund administration and auditability (Article IV)
Respects Net Change Limit constraints
Provides clear reporting, verifiability, and governance safeguards

Strategically, this also strengthens Cardano’s readiness for future upgrades such as Leios and Dijkstra, while expanding accessibility to a broader developer base via Go—supporting long-term ecosystem growth.

Overall, this is the kind of high-leverage, infrastructure-level investment the treasury should fund: it improves resilience, unlocks developer participation, and delivers lasting public goods under strong accountability frameworks.

This is the right thing to do for the network.

Vote: YES

This Info Action establishes a Net Change Limit of 300M ADA for Epochs 613–713, aligning closely with the treasury’s historical annual inflows and maintaining a sustainable fiscal guardrail as required by the Cardano Constitution. Setting the NCL near the replenishment rate helps ensure the ecosystem can continue to fund meaningful development without materially depleting the treasury. Strategic investment will be essential to drive adoption, particularly through infrastructure, liquidity growth, and the development of critical components such as stablecoins and financial rails that strengthen Cardano’s position in the broader digital economy. At the same time, the NCL represents a ceiling, not a spending target. Treasury withdrawals must continue to be evaluated carefully, prioritising initiatives that deliver real adoption, infrastructure, and measurable impact for the ecosystem. The treasury should support builders who execute and deliver value, not serve as an open-ended funding mechanism for projects that fail to produce results.

YES — This proposal delivers a measured, constitution-aligned increase to Plutus memory limits, improving developer flexibility and user experience without compromising network safety. The staged (Part 1 of 2) approach respects governance guardrails, allows real-world observation, and avoids reckless parameter jumps. Supporting this change helps Cardano scale practically today while preserving long-term decentralisation and robustness.

This Info Action is constitutionally appropriate, non-binding, and fully aligned with the intended purpose of informational governance actions. It introduces no technical, financial, or governance risk, and does not alter protocol parameters, ledger rules, or constitutional provisions. Naming a hard fork is a symbolic act that helps coordinate shared understanding across the ecosystem and has precedent within Cardano’s culture. Recognising Max van Rossem’s contributions to the community and the Hard Fork Working Group is not only harmless, but the right thing to do—it acknowledges meaningful service, reinforces positive norms around contribution and stewardship, and strengthens the social fabric of Cardano governance. As such, this proposal is sound, respectful, and worthy of support.

YES Vote Rationale – Cardano 2030 Vision & Strategy Framework and KPIs

I support this Info Action because Cardano governance requires a shared strategic framework and measurable reference point to guide treasury allocation, prioritisation, and long-term decision-making. A community-led Vision, Strategy and KPI framework provides DReps with a common measuring stick while remaining non-binding and fully compatible with the Cardano Constitution. My YES vote reflects support for strategic clarity and accountability, not automatic endorsement of any future funding or implementation details.

With respect to governance compensation, my support is contingent on clear, disciplined design. I support DRep compensation only when it is tied to measurable and active participation, assessed over a rolling six-month, epoch-based period, and paid proportionally based on completion of defined metrics (e.g. voting participation, rationale submission, and verifiable governance engagement). Compensation should be flat per qualifying DRep, not scaled by ADA delegated, and should require a minimum delegation threshold (e.g. 500k ADA) to ensure representational legitimacy and prevent governance farming. I support Constitutional Committee compensation due to the responsibility, accountability, and independence required by the role. I remain sceptical of additional SPO compensation, as SPOs already earn revenue through pool fees and governance participation is an expected responsibility; any additional costs should be reflected transparently in pool fee structures rather than paid separately from the treasury.

This YES vote supports strategic direction and governance maturity, while making clear that any future compensation mechanisms must prioritise accountability, fairness, anti-capture safeguards, and constitutional alignment.

I support Constitution v2.4 as it strengthens Cardano governance through improved clarity, integrity, and accountability without changing power dynamics or weakening safeguards. By removing non-binding expectations, the Constitution is reaffirmed as an enforceable framework rather than advisory guidance; by integrating Budget Info requirements directly into Treasury Withdrawals, oversight is simplified and applied where funds actually move; and by mandating proposal document immutability, voter trust and governance integrity are materially improved. The reversion of specific wording to address EMURGO’s concerns reflects a pragmatic, consensus-driven approach that supports constitutional legitimacy and governance stability at this stage of Cardano’s decentralisation.

I am voting YES on the proposal to add Christina as an additional Constitutional Committee member.

This action is fully compliant with CIP-1694 and the Cardano Constitution. Constitutional Committee size is not fixed, the proposal remains within existing guardrails, preserves the 67% voting threshold, and correctly references the prior Update Committee action that added Cardano Curia, ensuring proper ledger ordering and non-conflict.

The snap election to fill the vacant Constitutional Committee seat was implemented on-chain, and this proposal does not override, replace, or invalidate that outcome. Cardano Curia remains duly selected and ratified.

From a governance-resilience perspective, adding an additional member above the current minCommitteeSize of 7 reduces operational fragility and lowers the risk of governance stalling due to resignation, inactivity, or term expiry during the current mandate.

The exceptionally close snap-election result provides reasonable justification for broader representation without undermining the original on-chain decision.

Caveat: going forward, the community should clearly define whether snap-election processes are intended to be strictly single-seat outcomes, or whether close results may justify additional on-chain committee appointments. Expectations should be set in advance so that committee expansion remains principled rather than ad-hoc.

On balance, this proposal strengthens governance continuity while remaining aligned with both the letter and spirit of the Cardano Constitution.

Vote: YES — with a clear expectation of transparency, accountability, and measurable delivery

Cardano urgently needs tier-one integrations that unlock real-world utility: institutional custody, robust oracles, tier-one stablecoins, cross-chain connectivity, and analytics. These are not luxuries — they are foundational infrastructure for Cardano to compete globally as a serious settlement layer.

This proposal from the Cardano founding entities is, in my view, strategically necessary. It is aligned with the Constitution’s intent for ecosystem budgets, and it directly addresses several long-standing gaps that have limited adoption and liquidity on Cardano.
The network cannot scale institutional, DeFi, RWA, or enterprise activity without this infrastructure in place.

For these reasons, I am firmly voting YES on this Budget Info Action.

However — and this is important — a YES vote today must not be interpreted as a blank cheque.

The Constitutional framework requires:

Clear cost breakdowns

Dedicated audit and oversight provisions

Transparent administration of funds

Milestones, deliverables, and public reporting

My support is therefore paired with an expectation that the subsequent Treasury Withdrawal(s) will include:

Transparent allocation across the five integration pillars

Independent auditing and reporting in line with Article IV

Open standards and minimisation of vendor lock-in

Regular public progress updates and measurable KPIs

Clear governance oversight to prevent centralisation risks

This budget represents a major step forward — one that could meaningfully accelerate Cardano’s maturity and global competitiveness. If implemented with transparency and accountability, it will strengthen the ecosystem for builders, institutions, users, and delegators alike.

YES to the vision — with firm expectations for responsible execution.

If the later Treasury Withdrawal actions fail to meet these standards, I will reassess my support at that stage. For now, this proposal is the right direction at the right moment.

Vote: YES — with strong reservations regarding the exclusion of DJED

After reviewing the Stablecoin DeFi Liquidity Budget proposal, I will be voting YES, as it represents a major strategic step forward for Cardano DeFi and the responsible evolution of our Treasury. However, I want to state clearly my dismay that algorithmic stablecoins—particularly DJED, Cardano’s native stablecoin—have been excluded from consideration.

Summary

This proposal requests a ₳50,000,000 allocation from the Treasury to deepen stablecoin liquidity across Cardano’s DeFi ecosystem.
The funds will form a balanced pool of ADA and fiat-backed stablecoins, deployed into DEXs and lending protocols to:

Increase trading depth and efficiency

Provide a more reliable medium of exchange and unit of account for DeFi activity

Generate yield and diversify Treasury exposure

Strengthen Cardano’s competitiveness in on-chain liquidity and real-world adoption

A 9-member interim committee will manage deployment, subject to oversight by the Treasury DAO (tDAO), with on-chain checks such as:

Annual re-election or recall

Transparent reporting

Guardrails to remain within the Net Change Limit (NCL)

Why I Support It

Liquidity is the lifeblood of any DeFi ecosystem. Cardano’s weakness today is not technology—it’s depth and usability.
This proposal directly addresses that issue while introducing a repeatable, risk-managed framework for future Treasury deployments.

I believe this design is both constitutional and pragmatic, aligning with:

Fiscal responsibility: It diversifies Treasury exposure, aims to generate returns, and keeps risk within defined parameters.

Decentralized governance: The tDAO oversight and recall powers align with the Constitution’s principles of accountability and transparency.

Ecosystem growth: It materially improves liquidity, user experience, and protocol attractiveness—supporting builders, DEXs, and lending markets.

If implemented well, it can serve as Cardano’s first on-chain sovereign liquidity engine, showing the ecosystem’s ability to self-organize, self-fund, and grow sustainably.

Where I’m Disappointed

Despite supporting this initiative, I am deeply disappointed that DJED has been excluded.
DJED is Cardano’s native algorithmic stablecoin, built on academic principles, overcollateralized in ADA, and powered by COTI’s transparent smart contract model. Excluding DJED from participation sends a negative signal to innovation and decentralization, especially when it embodies the scientific and open-source ethos that Cardano stands for.

Yes, fiat-backed stablecoins offer near-term peg stability, but they rely on centralized custodians, off-chain collateral, and regulatory whims.
Cardano’s long-term vision is to build a self-sovereign financial system, not one dependent on fiat intermediaries. Algorithmic stablecoins are essential to that vision.
Treasury funds should not explicitly favor off-chain custodial assets over native, on-chain collateralized models that reflect the Constitution’s values of autonomy and decentralization.

It would have been more balanced to allocate a percentage (e.g., 10–20%) of the stablecoin liquidity fund toward DJED, subject to transparent risk assessments.
This would strengthen liquidity diversity, demonstrate technological confidence, and ensure Cardano’s DeFi infrastructure remains resilient even if fiat-backed tokens face restrictions or blacklisting.

Risks & Oversight

While the framework is well designed, success will depend on:

Professional liquidity management and transparent reporting.

Clear KPIs and yield/risk disclosures.

Continuous accountability of the committee to DReps and the wider community.

Prudent adherence to the Net Change Limit and Constitution’s fiscal prudence guardrails.

As a DRep, I will continue to monitor implementation closely to ensure:

Risk controls are enforced.

No single custodian or protocol gains undue advantage.

Reporting remains transparent and accessible to all ADA holders.

Conclusion

This proposal is a bold and necessary move for Cardano to strengthen its DeFi foundations and generate sustainable Treasury revenue. It is constitutional, fiscally sound, and growth-oriented.
However, I urge future revisions or follow-up proposals to integrate DJED and other algorithmic stablecoins, ensuring that Cardano’s DeFi ecosystem remains true to its decentralized DNA and not dependent solely on fiat bridges.

Therefore, my vote is YES — with the expectation that the next phase will restore balance by recognizing the importance of algorithmic stablecoins like DJED to Cardano’s long-term sovereignty and resilience.

Vote: NO — Cardano in Oceania: A community-led strategic plan for investing in growth

While I support the spirit of this initiative, I cannot back it in its current form.

My reasons:

The proposal leaves too many unanswered questions:
• Which countries/cities will actually be covered?
• Who is the BD Lead, and what’s the hiring/timeline?
• Where are the early partner LOIs/MOUs to prove traction?
• Who is delivering the hackathon (director, venue, mentors, post-event support)?
• What are the Pacific Island partnerships & multilingual education plans?
• Who is the independent auditor?
• How will the ₳100k Ikigai reimbursement be managed without crowding out program delivery?

These gaps make it hard to judge ROI and accountability, despite the proposal being constitutionally compliant.

Conclusion:
I respect the proposers and the intent, but until there is a clearer definition of scope, partners, and deliverables, I cannot vote to allocate ₳778k.

For 2026, I’d welcome a revised submission with stronger BD leadership, defined regional coverage, and proven early traction.

I am voting Yes on this governance action because it is both constitutionally compliant and strategically valuable for the long-term growth of the Cardano ecosystem.

1. Constitutionality

This proposal is consistent with the Cardano Constitution:

Article III.5 – Submitted in a legible, standardized format with rationale, budget, administration plan, and reporting.

Article IV.1 – Advances adoption, liquidity, and token infrastructure, directly serving Cardano’s sustainability and competitiveness.

Article IV.2 – Funds are administered by Intersect, with oversight from a Board of Advisors and provision for audits.

Article IV.3 – At ₳5M, it sits comfortably within the Net Change Limit (₳86M still available for 2025).

Article IV.4 – Provides for independent yearly audits, ensuring transparency and accountability.

There are no constitutional violations present.

1. Strategic Value

Loan, not grant – This is the first-ever Treasury loan, with repayment terms (5 years, 2.44% APR). It sets a precedent for sustainable Treasury use.

Ecosystem-wide benefit – While led by the Snek Foundation, the benefits extend far beyond SNEK:

ADA liquidity and trading pair depth will increase.

Exchange infrastructure and compliance frameworks will be reusable by future Cardano Native Tokens (CNTs).

Visibility and accessibility of Cardano assets on Tier 1 platforms will grow.

Proven track record – Snek has already self-funded $4.5M to deliver Cardano’s first three Tier 1 listings (Kraken, Crypto.com, Kucoin). This demonstrates competence, credibility, and “skin in the game.”

Momentum alignment – This loan complements other strategic listing pushes (e.g., Midnight Foundation / $NIGHT), enabling a positive chain reaction for CNT listings.

1. Treasury Context

With ₳86M ADA still available under the Net Change Limit, allocating ₳5M (just ~6%) to this initiative is proportionate and justified.

Given that much of the Net Change allowance will likely be consumed this year, supporting a high-impact, repayable initiative is a responsible use of funds.

1. Risk Assessment

Repayment risk exists, as repayment depends on Snek revenues and broader market conditions.

However, the safeguards (Intersect administration, Board oversight, yearly audits, enforceable loan agreement) reduce risk to an acceptable level.

Even in the unlikely event of repayment default, the Treasury benefits from the exchange infrastructure and ecosystem visibility established.

1. Conclusion

This proposal combines innovation, accountability, and ecosystem impact. It addresses a major bottleneck for Cardano adoption (CEX visibility and liquidity), introduces a sustainable funding model (repayable loans), and leverages a proven team with significant prior investment.

For these reasons, I believe the benefits to ADA, CNT adoption, and the broader Cardano ecosystem far outweigh the manageable risks. Supporting this initiative demonstrates confidence in new Treasury models and accelerates Cardano’s competitiveness globally.

I therefore cast my vote: YES.