CardanoYoda (MANDA Pool)

As a DRep, I decided to vote YES on the proposal: Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime

My rationale:

I voted NO on the previous Scalus proposal because the ₳8.5M budget and broad scope were not sufficiently supported by demonstrated adoption. It attempted to fund the complete long-term vision at once, including a production-grade L1 node, L2 integration, formal verification, an advanced devnet, and a comprehensive application runtime.

The team responded constructively to this feedback. The new ask has been reduced by 71% to ₳2.46M. Staffing has been reduced from 8.25 to 2.25 FTE, and the 10% contingency has been removed.

The L1 node, full Gummiworm integration, broad formal-verification work, and advanced devnet expansion are no longer included. This proposal is therefore materially different from the one I previously rejected.

The remaining scope is more proportionate.

Maintenance and Dijkstra readiness are legitimate public-infrastructure expenses. Scalus components are reused by Cardano tools such as MeshJS, Lucid Evolution, Evolution SDK, YaciDevKit, and Cardano Client Lib. Developers can therefore benefit from Scalus without directly choosing Scala or integrating the complete platform.

Components embedded in widely used SDKs can benefit a much larger part of the ecosystem. Keeping them compatible with future protocol versions also protects Cardano’s previous investment.

The Dijkstra hard fork is expected to affect Plutus, ledger rules, transaction construction, cost models, and other parts of the development stack. Scalus and the tools depending on it will therefore need to be updated. Funding compatibility work before the hard fork is more responsible than waiting for problems to appear afterwards.

It also helps Cardano maintain multiple independent development environments rather than relying on a single toolchain.

The team has demonstrated its ability to deliver. Its three funded Catalyst projects, totaling ₳428k, and the previous ₳657k Treasury allocation were completed. All reported milestones were delivered.

The annualized rate of $210k per FTE is at the upper end of the market, but it is defensible given the specialized senior expertise required in compiler engineering, Plutus, and protocol-level development. Combined with the substantially reduced team size and overall budget, the current request appears proportionate to the proposed scope.

This is the type of constructive resubmission that governance should encourage. The team listened to DRep feedback, removed the most contested components, substantially reduced the budget, and focused on maintaining proven open-source infrastructure while testing the next step at a controlled scale.

For these reasons, I vote YES.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I vote NO on the proposal: Alchemy by Sundial x Charms: Cardano-Native Bitcoin Treasury Protocol

My rationale:

After discussing with the team, I found out that they are not able to deliver the project and that they will announce it publicly.

If my information is wrong, please feel free to contact me.

As a DRep, I vote ABSTAIN on the proposal: Withdraw 4,969,231 ada for Cardano Enterprise Adoption: Ticketing Platform.

My rationale:

I see both positives and serious concerns.

On the positive side, this proposal is connected to a real company with an existing ticketing business. Sellout appears to be a real service with real users, and Anvil is a credible Cardano development partner. I also appreciate that the proposal attempts to bring a real-world commercial use case to Cardano, which is something the ecosystem should generally welcome.

However, I remain skeptical about the actual added value of blockchain in this specific use case.

A tokenized ticket has clear value before the event, but after the event, its utility becomes much weaker. Unless there is a concrete loyalty, collectible, or future-access model, the NFT mostly becomes an expired ticket record. The proposal does not sufficiently explain why this long-term on-chain footprint creates meaningful value for users or for Cardano.

There is also a more fundamental issue: owning an NFT ticket does not by itself guarantee admission to the event. The buyer still depends on a trusted third party. In this model, the NFT is not the same as owning a fully on-chain asset like ADA. It represents an off-chain promise that must still be honored in the real world.

The proposal also appears to rely heavily on custodial wallets and hidden blockchain UX. That may be good for normal users, but it weakens the self-custody argument. If ticket buyers do not manage their wallets, do not interact with Cardano directly, and continue to rely on Sellout’s system for redemption, then Cardano risks becoming a backend ledger rather than essential infrastructure.

I am also concerned about the economics of minUTxO. If every purchased ticket becomes a CIP-68 NFT, then ADA must be attached to token-bearing UTxOs. At a small scale, this may be manageable. At a larger scale, it becomes a real operational capital requirement. If old tickets remain in wallets after events, the minUTxO requirement can keep growing over time. This is a significant barrier to scaling the product.

Related to this, the proposal does not clearly explain who owns or benefits from the ADA used for minUTxO. If the wallets are custodial, then Sellout appears to control the ADA reserve required to operate the system. If this ADA is delegated, staking rewards may also accrue to Sellout unless another arrangement is clearly defined. If a customer exports a ticket to self-custody, it is unclear whether the customer receives the required min ADA together with the NFT, whether they must provide ADA themselves, or how that ADA is later recovered.

This is not a minor implementation detail. It affects user experience, capital requirements, ownership, staking rewards, and the real meaning of self-custody.

In addition, ADA locked for minUTxO should not be treated as strong economic activity or productive TVL. It is mostly operational liquidity required to make the NFT design work. It may support staking, and it may sit under the control of the custodial operator, but it is not the same as active capital used in DeFi or organic user demand for ADA.

The repayment mechanism is positive in principle, but I am not convinced it is strong enough. Based on the expected ticket volume and fee-share structure, repayment of roughly $1.09M could take many years, possibly around 15 years under conservative assumptions. That makes the repayment more like long-term upside than strong Treasury protection.

I am also uncomfortable with the Treasury funding a private company’s product development, Web2 integration, salaries, marketing, and business expansion unless the Cardano-specific value is very clear. In this case, I do not think the proposal fully proves that Cardano is necessary for the core ticketing business.

Many parts of ticketing can be implemented in Web2. Users are also not strongly motivated to take advantage of self-custody if the event experience still depends on the ticketing provider and venue.

For these reasons, I cannot vote YES.

At the same time, I do not want to vote NO because this is still a real business trying to use Cardano in a real-world service. I want Cardano to be adopted by actual companies and not only by crypto-native projects.

If the team can prove the model, generate real usage, and show that Cardano brings measurable value to organizers, artists, venues, or buyers, then this could become useful learning for the ecosystem.

Therefore, I abstain.

I would like to see a future version with a clearer explanation of why Cardano’s role in the ticketing system is important, how self-custody works in practice, how minUTxO is handled at scale, who owns the ADA attached to ticket UTxOs, who receives staking rewards, what happens to tickets after events, how users benefit from NFT ownership, and a more realistic repayment model.

I would also like to see Sellout have more skin in the game and cover part of the cost of integrating its business with Cardano.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I vote YES on the proposal: Intersect Technical Steering Committee Support.

My rationale:

Cardano needs strong technical governance alongside its on-chain governance system. DReps can make decisions, but they cannot be expected to independently assess every protocol parameter, hard-fork dependency, infrastructure risk, or complex technical proposal without support from specialists.

The Technical Steering Committee and the groups covered by this proposal perform important functions for the ecosystem. The Parameter Committee provides analysis and recommendations related to protocol parameters. CIP editors maintain the process through which technical standards and protocol improvements are discussed and documented. The Hard Fork Working Group coordinates readiness across nodes, wallets, exchanges, dApps, and other infrastructure before network upgrades.

The activity of the Technical Steering Committee, CIP editors, and Hard Fork Working Group is publicly visible. Meeting minutes, technical discussions, CIP reviews, readiness assessments, and coordination around protocol upgrades are available for the community to inspect.

The Hard Fork Working Group has demonstrated practical value by monitoring ecosystem readiness, identifying critical dependencies, maintaining risk information, and recommending delays when important infrastructure was not ready. This type of coordination reduces the risk of unnecessary disruption during protocol upgrades.

I also support the proposed pilot for independent technical reviews of core infrastructure proposals. DReps regularly receive proposals involving highly specialized software, cryptography, networking, protocol design, and security. Independent technical assessments can improve the quality of due diligence and help DReps distinguish between credible technical claims and unsupported statements.

These reviews should remain advisory. Technical experts should provide evidence, identify risks, and evaluate feasibility, while final Treasury accountability must remain with DReps and the wider governance system.

The total request of 1,193,000 ADA for 12 months does not appear excessive for supporting technical coordination, protocol governance, CIP editing, hard-fork readiness, and a technical-review pilot.

The proposal is not without shortcomings. It does not provide a detailed allocation of the 832,000 ADA between the Parameter Committee, CIP editors, and Hard Fork Working Group. It also lacks named paid roles, workload allocation, rates, quantities of technical reports, and a clear number of reviews expected under the pilot.

The milestones and acceptance criteria are also not currently available to DReps. The proposal states that they will be included in the project's smart-contract metadata after the legal contract has been prepared. I would prefer milestones, payment schedules, and acceptance criteria to be available before the Treasury vote, not after the funds have already been committed.

There is also some uncertainty about the boundary between this proposal and the main Intersect proposal. The main proposal includes technical stewardship, release coordination, incident response, repository management, governance coordination, and operational support for committees and working groups. This proposal separately funds the substantive work of the Technical Steering Committee and several specialist groups.

Intersect should provide a clear responsibility and cost-allocation map showing which staff, activities, and deliverables are funded through each proposal. No person or activity should be compensated twice for the same work.

However, these shortcomings are not sufficient for me to reject this proposal. The activities funded here are more narrowly connected to technical governance, protocol evolution, and independent expert support. These are functions that Cardano needs regardless of my broader concerns about Intersect’s governance coordination.

My YES vote on this proposal is therefore also a clear signal about priorities. I support funding the specialist technical functions that help protect protocol continuity, improve hard-fork readiness, maintain the CIP process, and provide DReps with independent technical expertise.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0
In an ideal process, the main Intersect proposal would have been unbundled so that core technical staff and technical stewardship could be approved separately from governance coordination and general operations. The approaching Net Change Limit makes a resubmission uncertain, but this should not prevent me from supporting the narrower technical-governance work presented here.

For these reasons, I vote YES.

As a DRep, I vote YES on the proposal: UTxO RPC by TxPipe – Maintaining Cardano’s Integration Standard, Year 2.

My rationale:

UTxO RPC is useful open-source infrastructure that provides a standardized interface for interacting with UTxO-based blockchains.

It defines common methods and data structures through Protocol Buffers and provides SDKs for several programming languages, including Rust, Go, Node.js, .NET, Haskell, and Python. This can reduce integration complexity and allow developers to use the same interface across different Cardano node implementations and infrastructure providers.

The work is publicly visible across multiple GitHub repositories. The specification, SDKs, generated packages, documentation, and integrations are actively maintained.

There is also evidence that UTxO RPC is becoming a real ecosystem standard. Dingo includes a native UTxO RPC server, and the Haskell Cardano node contains UTxO RPC query, transaction submission, evaluation, and testing functionality.

This is important for Cardano. Alternative node implementations should not require developers to use completely different APIs. A common integration standard can reduce ecosystem fragmentation and make it easier for wallets, dApps, infrastructure providers, and developer tools to support multiple node implementations.

The previous maintenance period resulted in visible work, including governance support, transaction evaluation improvements, new query functionality, SDK updates, release automation, dependency maintenance, and fixes to broken generated packages.

The requested 540,750 ADA for 12 months does not appear excessive for maintaining the specification and multiple language SDKs.

The proposal could provide more detail about the exact part-time allocation, supported SDKs, measurable maintenance targets, and the roadmap toward a stable version of the standard. I would also prefer a clear Year 1 delivery report and more precise rules for the use and return of the contingency reserve.

The claim that Amaru has already adopted UTxO RPC may also be stronger than the currently visible implementation. However, adoption by Dingo and the Haskell node is sufficient to demonstrate that the project has practical ecosystem value.

These shortcomings are not sufficient for me to reject the proposal. UTxO RPC has a clear public-good role, the work is transparent, and TxPipe has demonstrated that it is capable of delivering.

For these reasons, I vote YES.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I ABSTAIN on the proposal: Tx3 by TxPipe – Open API Layer for Cardano’s dApp Protocols.

My rationale:

Tx3 addresses a real problem in the Cardano developer ecosystem. Integrating with Cardano protocols often requires developers to understand protocol-specific transaction structures, datums, redeemers, reference inputs, and off-chain logic. A standardized interface that can generate documentation, SDKs, and deterministic unsigned transactions could reduce duplicated integration work.

The project is not starting from zero. The core framework, protocol gateway, registry, and several protocol definitions are publicly visible on GitHub. TxPipe has also demonstrated that it can deliver technically complex open-source infrastructure.

I particularly value the developer-facing part of the proposal. A common interface for Cardano protocols could benefit wallets, aggregators, developers, and other applications even if the expected growth of AI-driven blockchain activity does not materialize as quickly as predicted.

However, I am not ready to vote YES on the proposal in its current form.

The proposal states that five protocols are already live, but this does not necessarily mean that the complete functionality of these protocols has been integrated. For example, the Strike implementation covers staking rather than the main derivatives protocol, while parts of the Bodega workflow remain outside the current Tx3 capabilities.

The proposal does not clearly define what will count as one of the twelve new protocol onboardings. A small or partial feature of a large dApp should not automatically be considered a complete protocol integration.

The twelve protocols are also not identified, and there is no clear selection process, evidence of demand from protocol teams, or requirement for those teams to validate the resulting interfaces.

I would also expect a clear verification standard. Each integration should be tested against real on-chain transactions, include reproducible test vectors, document unsupported functionality, and ideally receive confirmation from the relevant protocol team.

The AI-agent and MCP components are interesting, but they remain more speculative than the existing developer tooling. The proposal should be justified primarily by current developer demand and measurable adoption rather than assumptions about future autonomous-agent activity.

The proposal also lacks sufficient information about the team, FTE allocation, cost per protocol integration, development costs for the MCP server, security review, hosting, and maintenance of the existing integrations.

The total request of 1,684,050 ADA may be reasonable for the proposed scope, but the budget is presented as a single work package and does not provide enough detail for me to evaluate whether the cost is proportionate.

There is also no clear long-term maintenance model. Protocols change, contracts are upgraded, and addresses and transaction patterns may become outdated. The proposal should explain who will be responsible for keeping the protocol definitions accurate and how outdated or unsafe integrations will be identified and disabled.

I see clear potential in Tx3, and the visible work gives me confidence that TxPipe is capable of delivering. However, the proposal does not provide enough detail about the exact deliverables, integration completeness, verification standards, adoption, security, cost breakdown, and long-term maintenance.

For these reasons, I ABSTAIN.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I vote YES on the proposal: Pallas by TxPipe – Maintaining Cardano’s Core Rust Libraries, Year 2.

My rationale:

Pallas is an important open-source infrastructure for the Cardano developer ecosystem. It provides Rust implementations of core Cardano and Ouroboros functionality, including networking, CBOR encoding, cryptographic primitives, address handling, ledger traversal, transaction building, and transaction validation.

These libraries are used by multiple projects across the ecosystem, including Aiken, Dolos, Oura, Mithril, Amaru, and UTxO-RPC. Maintaining Pallas, therefore, benefits more than one application or vendor. It reduces the need for individual teams to repeatedly implement the same low-level protocol functionality.

The work is publicly visible on GitHub. The repository is active, releases are published, and the team continues to address protocol compatibility, correctness, testing, documentation, and developer experience.

Some of the recent work includes preparation for Cardano protocol upgrades, improvements to UTxO-RPC compatibility, transaction-validation fixes, networking development, and initial support for Leios mini-protocols. This demonstrates that the previous maintenance funding resulted in meaningful and relevant work.

The requested 540,750 ADA for 12 months does not appear excessive for maintaining specialized infrastructure used across the ecosystem.

The proposal could provide more detail about the exact part-time allocation, measurable maintenance targets, and the division of work between Pallas and other TxPipe proposals such as Dolos and Oura. I would also prefer clearer rules for the use and return of the contingency reserve.

However, these shortcomings are not sufficient for me to reject the proposal. Pallas has a clear public-good role, the work is transparent, and TxPipe has demonstrated that it is capable of delivering.

For these reasons, I vote YES.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I vote YES on the proposal: Oura by TxPipe – Maintaining Cardano’s Event Pipeline.

My rationale:

Oura is useful open-source infrastructure that allows developers and infrastructure operators to monitor Cardano blockchain events, filter relevant data, and route it to external systems such as databases, message queues, cloud services, webhooks, and analytics platforms.

This reduces the need for individual teams to build and maintain their own Cardano event-processing pipelines. Oura supports multiple data sources and a wide range of output integrations, making it a flexible tool for indexing, monitoring, analytics, and real-time applications.

The work is publicly visible on GitHub. The repository is active, the project has a long development history, and TxPipe continues to release updates, improve documentation, maintain compatibility with Cardano infrastructure, and address bugs and operational issues.

Oura v2 was a substantial overhaul of the original pipeline. It introduced new sources, sinks, filters, persistent cursors, rollback handling, WebAssembly support, and improvements to testing, packaging, and deployment. The project therefore requires continued maintenance and stabilization.

The requested 540,750 ADA for 12 months does not appear excessive for maintaining specialized open-source infrastructure written in Rust.

The proposal could provide more detail about the exact part-time allocation, measurable maintenance targets, adoption, and possible overlap with other TxPipe maintenance proposals. I would also prefer clearer rules for the use and return of the contingency reserve.

However, these shortcomings are not sufficient for me to reject the proposal. TxPipe has a strong delivery record, the work is transparent, and Oura provides practical value to the Cardano developer ecosystem.

For these reasons, I vote YES.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I vote YES on the proposal: Dolos by TxPipe – Maintaining Cardano’s Lightweight Data Node, Year 2.

My rationale:

Dolos is useful open-source infrastructure that gives developers efficient access to Cardano chain data without requiring the resources and complexity of running a traditional full node and separate indexing services.

It supports several interfaces used across the Cardano developer ecosystem, including UTxO-RPC, Mini-Blockfrost, Mini-Kupo and the Ouroboros Node-to-Client interface. This makes it easier for developers to integrate Dolos into existing applications and development workflows.

I have direct experience with the product and see practical value in its continued development and maintenance.

The work is also publicly visible on GitHub. The repository is active, releases are frequent, and the team continues to address protocol compatibility, bugs, performance, security, testing, and documentation. TxPipe has demonstrated that it is capable of delivering and maintaining this software.

The requested 540,750 ADA for 12 months does not appear excessive for maintaining a specialized Cardano data node written in Rust.

The proposal could provide more detail about the exact part-time allocation, measurable maintenance targets, and the conditions under which the contingency reserve may be used. However, these shortcomings are not sufficient for me to reject the proposal, given the visible delivery record, reasonable budget, and practical usefulness of Dolos.

For these reasons, I vote YES.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I abstain from the proposal: MLabs Core Tool Maintenance & Enhancement: Plutarch and Ply

My rationale:

Plutarch and Ply are useful pieces of Cardano smart-contract tooling. They support developers building and maintaining on-chain applications, and maintaining open-source developer infrastructure is generally a valid use of Treasury funding.

MLabs also has a relevant track record. The team has worked on these tools before, the work is visible, and previous delivery through Catalyst shows that they are capable of contributing to Cardano’s developer ecosystem.

However, I cannot vote YES on this proposal as submitted.

The issue is that the proposal does not describe the deliverables, cost structure, staffing, and accountability with enough detail for an on-chain Treasury withdrawal.

The proposal uses a broad quarterly maintenance model and lists reasonable priority areas such as critical breakages, protocol-era compatibility, bug fixes, optimizations, documentation, and developer-experience improvements. That is a sensible maintenance framework, but it is not enough for a YES vote at this budget level.

I would expect clearer information about specific quarterly deliverables, acceptance criteria, evidence of completion, the split between Plutarch and Ply work, expected FTE allocation, named maintainers or roles, hourly or monthly rates, and a more detailed cost breakdown.

This is especially important because MLabs has described similar work much better in Catalyst in the past. Their previous Catalyst proposal included concrete milestones, outputs, acceptance criteria, evidence requirements, delivery timing, and an hour-based budget breakdown.

In my view, teams asking for Treasury funding through on-chain governance and the Intersect budget process should maintain at least the same standard of transparency that they used in Catalyst.

I do not want to vote NO because the work itself is valuable and the team appears capable. But I also do not think the proposal is ready for a YES vote without better-defined deliverables, costs, staffing, and accountability.

For these reasons, I abstain.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I abstain from the proposal: Mithril Protocol.

My rationale:

Mithril is an important piece of Cardano infrastructure. It helps reduce the cost and complexity of accessing and verifying blockchain state, improves node synchronization, and supports a more decentralized infrastructure layer for wallets, tools, light clients, monitoring, and other ecosystem applications.

I also recognize that the work is publicly visible on GitHub. The team involved has the technical capability and track record to deliver.

However, I cannot vote YES on this proposal as submitted because the requested amount is too large to be justified without more detailed information.

The proposal does describe the general direction of the work and appears to include milestones, but for a Treasury withdrawal of this size, I would expect much clearer public details about the specific deliverables, acceptance criteria, delivery team, FTE allocation, rates, and overhead.

The proposal explains why Mithril matters, but it does not provide enough detail to assess whether the budget is reasonable. For critical infrastructure, continuity is important, but Treasury funding still requires strong cost justification, transparency, and accountability.

My abstention should therefore not be interpreted as opposition to Mithril. I support the continued development and maintenance of Mithril as critical infrastructure. My concern is with the level of transparency and cost justification in this specific withdrawal.

If this work is submitted again in the future, I would like to see a much clearer team and cost breakdown, along with more specific public deliverables and measurable acceptance criteria. With that information, I would be much more open to voting YES.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I vote YES on the proposal: Hardware Wallet Maintenance 2026.

My rationale:

Hardware-wallet support is part of Cardano’s basic security and access infrastructure. Many users rely on Ledger and Trezor devices to securely hold and use ADA and Cardano native assets. If hardware-wallet compatibility breaks, users may lose practical access to secure signing, wallets and dApps may face integration problems, and Cardano’s user experience would suffer.

This is a continuity proposal focused on maintenance, compatibility, supporting libraries, cardano-hw-cli, and developer support for integrations. In my view, this is a reasonable and necessary scope.

I also consider the budget acceptable. The total request is ₳1,310,960. For 12 months of specialized maintenance on a security-critical layer used by the ecosystem, this does not appear excessive.

The vendor has relevant prior experience and a proven track record in this area. Repeated funding is normally something I examine carefully, but maintenance of critical infrastructure is naturally recurring.

Cardano users should not discover hardware-wallet maintenance problems only after something breaks. Preventive maintenance is cheaper, safer, and less disruptive than emergency repair.

For these reasons, I vote YES.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I vote NO on the proposal: Withdraw 3,961,538 ada for Bringing Real-World Payments to Cardano with Wirex

My rationale:

I support the strategic goal of bringing real-world payments to Cardano. Wirex has relevant experience in card issuance and regulated payment infrastructure.

However, I cannot approve this withdrawal as submitted because the proposal does not clearly explain what Cardano is actually receiving in exchange for Treasury funding.

The proposal uses broad language such as “the lack of integrated infrastructure to support real-world payments at scale” and “a full-stack, open-source payments infrastructure that enables onchain settlement through smart contracts while connecting Cardano to banking rails.”

These statements are too vague for a Treasury withdrawal of this size.

The main problem is that Cardano payment-card infrastructure already appears to exist in some form. EMURGO announced a partnership with Wirex at Cardano Summit 2025 to issue the Cardano Card. EMURGO stated that the card is natively integrated into the Wirex app, with Wirex as the issuer, and that users can spend with hundreds of cryptocurrencies and stablecoins, including ADA, BTC, ETH, and USDC, anywhere Visa is accepted.

EMURGO also stated that a share of profits is intended for the Cardano Treasury. The proposal should mention the current profit or how much has already been put into the Treasury.

The Cardano Card was described as being distributed by EMURGO and issued by Wirex. The proposal should describe what exactly is missing and what this Treasury proposal would deliver that is not already part of Wirex’s or EMURGO’s commercial roadmap.

Moreover, Wirex announced in May 2026 that it had partnered with SecondFi.

I am not claiming that EMURGO or SecondFi are formal participants in this Treasury withdrawal. The proposal text names Wirex as the vendor. But because EMURGO, Wirex, the Cardano Card, and SecondFi are already publicly connected in the Cardano payments context, the proposal should explicitly clarify whether EMURGO or SecondFi is involved in this work in any way.

This is especially important after the recent SecondFi security incident. SecondFi has announced that it will not resume normal operations.

After such an incident, DReps should be careful about who builds critical payment infrastructure. If EMURGO or SecondFi has any direct or indirect relationship to this proposal, that relationship should be disclosed clearly.

The proposal should also explain whether the recent SecondFi incident affects the feasibility and user-safety model of the Wirex proposal.

It should be explained in detail whether the Treasury is funding a defined Cardano public good or subsidizing the next phase of an already existing commercial card.

Conditions for approval of the proposal:

1. Detailed description of the infrastructure that already exists and what specifically this proposal delivers.
2. What specifically will be open-sourced.
3. If and how EMURGO and SecondFi will participate in the project.

I would be open to a revised version of this proposal. I cannot justify approving this Treasury withdrawal in its current form.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I vote NO on the proposal: Net Change Limit: Cardano Treasury (Epochs 613–713).

My rationale:

Cardano governance must be able to define strategy, set priorities, and allocate Treasury resources responsibly. A necessary step is better coordination among DReps on how the available budget should be used.

Ideally, we should first define some form of budget bucket system that makes clear how much funding should be allocated to key categories such as core infrastructure, research, integrations, liquidity, ecosystem support, commercial adoption, community projects, and other priorities.

Without preparation, coordination, structure, and prioritization, increasing the NCL risks becoming another unstructured run on the Treasury. Teams will compete to submit additional withdrawals, and DReps will be expected to process them without a clear strategic framework.

DReps are already exhausted after the Intersect budget process. They have reviewed more than 100 proposals, with many still active. Most community DReps work for free, and it is also the summer vacation period in many countries. Burdening DReps with a large number of additional proposals at this point is not reasonable.

I understand the argument that Cardano should invest even beyond current Treasury income because we need growth and commercial adoption. I partially agree with that view. However, this makes strategy and prioritization even more important, not less. If we want to increase the NCL, we should first have a serious debate among DReps about how the additional budget should be allocated and what outcomes we expect from it.

Approving an increase in the NCL without a clear strategy, allocation framework, and prioritization process seems irresponsible to me. Before expanding the spending capacity of the Treasury, we need to address the governance and coordination issues that currently limit our ability to make wise funding decisions.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I decided to vote NO on the Strike Finance V2 Treasury Deployment proposal.

My rationale:

I want to be clear at the beginning. I want to support Strike. It is one of the most visible DeFi protocols on Cardano. I recognize the importance of liquidity and trading infrastructure for the ecosystem.

I also appreciate that the proposal is not framed as a grant, but as a productive treasury deployment intended to return principal and yield to the Treasury.

However, as a responsible DRep, I must apply a high standard when Treasury assets are exposed to significant risks. For a 9M ADA request, the proposal does not yet provide enough detail, safeguards, or evidence to justify a YES vote. I remain open to supporting a revised proposal if these issues are addressed.

One concern is trade transparency. Strike reports strong growth numbers. However, because Strike V2 trading happens on the Strike execution layer rather than fully on-chain, DReps and the community need more information to verify the quality of this activity.

Strike should publish anonymized V2 trade concentration data, including the top 5, top 10, and top 20 accounts by volume and trade count, the percentage of volume generated by market makers, the percentage generated by the official liquidity vault, self-trade prevention rules, wash-trading controls, and a clear definition of what “unique traders” means.

Another concern is the need for support from the public treasury. The proposal states that Strike has generated millions of dollars in profit for liquidity providers and over $1M in protocol revenue. These numbers make Strike look successful, but they also weaken the argument that Treasury support is necessary.

If the protocol has already generated substantial LP profit and revenue, Strike should explain why the required liquidity cannot come from reinvested protocol revenue, LP profits, or the STRIKE token treasury.

I am also concerned about market timing. The proposal requires Treasury ADA to be sold into USDM. ADA is currently trading at low levels, which makes this a high-conviction treasury decision. Selling ADA at low prices to support USDM liquidity and a private DeFi protocol is difficult to justify without stronger Treasury protection and upside alignment.

Custody is another important issue. A 3-person council is relatively small for a 9M ADA deployment. I would expect a larger and more independent structure, potentially something like a 5-of-7 multisig. Including respected top DReps or other independent ecosystem representatives would add legitimacy and reduce concentration risk. The proposal should also provide exact signers, thresholds, wallet addresses, responsibilities, and conflict-of-interest disclosures before approval.

Audit readiness is also not sufficient yet. Strike has public evidence of prior audit work for older smart-contract components, but the official Strike V2 audit relevant to this 9M ADA deployment has not been published yet. DReps should require the final V2 audit report, audited commit hashes, and deployed contract addresses before approving a treasury deployment of this size.

The proposal should also include a clear commitment that, during the 12-month Treasury liquidity deployment, Strike will not unilaterally change protocol settings or economic terms in a way that materially increases Treasury risk or reduces Treasury upside. Any necessary changes should be disclosed publicly, clearly justified, reviewed by the independent council, and included in regular transparency reporting.

Finally, the proposal does not sufficiently describe how the ADA-to-USDM conversion will be executed. Since the Treasury position depends on selling 9M ADA into USDM, execution fees, spreads, slippage, and counterparties are material risks. These details should be specified before approval, not only reported afterwards.

Overall, I see a potentially interesting idea, but the proposal form is not adequate for the size and risk of the request. It describes the intention, but not enough of the execution plan, audit status, custody mechanics, conflict management, and downside protection.

For these reasons, I vote NO on the current proposal, while remaining open to a revised version with stronger Treasury protection and a more complete risk framework.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

Buy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0

As a DRep, I decided to vote YES on the proposal: Cardano Builder DAO.

My rationale:

My vote should not be perceived as an unconditional endorsement of the DAO as a perfect funding vehicle. It is a pragmatic decision based on the current state of Cardano treasury funding, the need for alternative funding mechanisms, and the improvements CB DAO has made since its previous round.

After the Intersect budget process, only a limited number of non-Intersect proposals reached the on-chain stage. Excluding Intersect-related proposals, only nine proposals were approved, and five of those are connected to one entity. These proposals are now on-chain and still do not have funding guaranteed.

Catalyst is expected to return in the fall with a budget of around ₳2M, which is small in the current market environment and especially limited given the low ADA price.

At the same time, several important teams and platforms in the Cardano ecosystem have struggled or gone out of business. Some of this is natural and even healthy market discipline, but from a user and ecosystem perspective, losing key tools, infrastructure, and applications can also become a serious problem.

I believe Cardano needs alternative funding vehicles. It is inefficient when large proposals from founding entities asking for tens of millions of ADA and smaller builder proposals asking for hundreds of thousands of ADA must compete in the same on-chain governance process.

This is especially problematic when many proposals are submitted at the beginning of an NCL period and DReps are expected to evaluate everything at once.

CB DAO is one of the few mechanisms currently capable of directing funding to ecosystem builders in a more focused way. The DAO targets existing Cardano applications, not random ideas. Cardano needs wallets, aggregators, bridges, dashboards, oracles, risk tools, DeFi products, and user-facing applications. If these products disappear, users feel the consequences directly.

Another important reason for my YES vote is the effort to introduce independent oversight through members of the DRep DAO. In my view, DReps should not only approve funding. They should also be involved in controlling milestones, reviewing deliverables, and stopping or delaying disbursements when conditions are not met.

If DReps carry responsibility for approving treasury withdrawals, they should also have a role in ensuring that treasury funds are used according to the approved mandate.

Last year, I voted NO on CB DAO. I shared many of the concerns raised by other DReps about the structure, rules, accountability, and possible conflicts of interest. I still have concerns today.

However, I also see a serious effort to improve the model, and that matters.

To be clear, CB DAO is not a perfect mechanism. Several commercial or tokenized projects have received funding even though, in my view, such projects should increasingly survive through revenue, private investment, token economics, or targeted performance-based funding rather than broad treasury subsidies. Treasury funding should not become a permanent runway for businesses that are unable or unwilling to commercialize.

Projects that fail to meet KPIs should not automatically receive further funding. In some cases, KPIs should be stricter, more objective, and more clearly connected to Cardano's strategic goals.

Accountability also needs to improve. The KPI dashboard is a useful step, but it is not enough by itself. If KPI data is self-reported, partially self-reported, or not independently verified, then DReps and the community should treat it with caution. Future funding rounds should move toward more verifiable, on-chain, independently auditable metrics wherever possible.

There is also a funding-need problem. Some CB DAO participants are commercial projects, tokenized projects, or teams that already had other funding routes. These projects should be assessed more strictly. Treasury funding should be used as a temporary runway toward sustainability, not as a replacement for a business model.

CB DAO is asking for more funding than last year. Normally, I would treat this as a significant concern. However, given the lower ADA price, the larger nominal ADA request is partly understandable. Still, more ADA must come with stronger accountability, stricter eligibility, and clearer milestone control.

For future rounds, I recommend several improvements:

CB DAO should set stricter KPIs and make KPI achievement a stronger condition for future eligibility. It should put more emphasis on previous funding history, commercial viability, and whether a project has already received significant support from Catalyst, the treasury, or other ecosystem programs. It should also consider caps on how much one project can receive across multiple rounds.

I also recommend avoiding repeated funding for successful commercial projects unless there is a clear public-good justification, strong evidence of ecosystem impact, and a credible path to sustainability. For commercial projects, funding should ideally come with stronger treasury alignment, such as revenue-sharing, token allocation, service commitments, open-source commitments, or other mechanisms that ensure the ecosystem receives value in return.

Finally, I strongly recommend prioritizing open-source projects, especially when treasury funding is repeated. If a project receives public funding several times and later shuts down, the ecosystem should ideally be able to continue, fork, or maintain the service. Treasury-funded work should not disappear completely when a private business closes.

Despite these concerns, I am voting YES because I believe Cardano needs builder-focused funding mechanisms, and CB DAO has shown enough willingness to improve to justify another controlled round. My support depends on stronger oversight, stricter KPI discipline, and a clear expectation that funding can be delayed or stopped if milestones, deliverables, or accountability standards are not met.

Disclaimer: I am a member of the DRep DAO and have been named as a potential independent oversight participant for this proposal. If this role is formalized, I may be involved in milestone review and disbursement control. I am in contact with the Clarity / CB DAO team, but I am not a CB DAO requesting member and I am not applying for CB DAO project funding. Any compensation, role, or responsibility connected to oversight must be clearly disclosed. My YES vote should therefore be read together with this disclosure.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote NO on the proposal: Blockfrost's transformation to not-for-profit.

My rationale:

I recognize that Blockfrost is a valuable infrastructure for Cardano developers. However, the core question for me is not whether Blockfrost is useful, but whether the Treasury should reinforce dependence on one dominant access provider or reduce that dependence.

The proposal itself states that in most epochs, more than 50% of Cardano transactions are submitted through Blockfrost. I see this not only as evidence of importance, but also as evidence of an access-layer centralization problem.

For this reason, I believe Treasury funding should be used to increase provider diversity, not to concentrate almost ₳10M into one dominant provider.

Cardano does not depend only on Blockfrost. Developers can already use other access-layer solutions such as Koios, Ogmios/Kupo, Maestro, or self-hosted infrastructure.

This matters because the Treasury should not make one dominant provider even more central to the ecosystem. If Blockfrost already handles a large share of Cardano transaction submission, then funding it alone may preserve the same dependency problem instead of solving it.

In my view, Treasury funding should strengthen a diverse access layer: multiple providers, failover tooling, and easier ways for wallets and dApps to use multiple backends.

We need to build a competitive and resilient infrastructure market where no single provider is indispensable.

I also consider the history of prior community funding relevant. Blockfrost previously received Catalyst funding for “Open-sourcing Blockfrost API.” That Catalyst proposal is complete, with $119,000 distributed, and its stated goal was to open-source the Blockfrost backend under the Apache License 2.0.

Much of Blockfrost already appears to be public and reusable today: the backend is under the Apache License 2.0, the OpenAPI specification is under the MIT License, and the decentralized platform is also under the Apache License 2.0.

Because of this, the proposal should be much more precise about what the community is actually receiving that it does not already have.

The proposal says that all Blockfrost intellectual property, including source code, trademarks, domain names, and associated assets, will be transferred to the governing not-for-profit. But if major parts of the code are already open-source, then the most valuable parts of the transfer are likely the brand, domains, operational infrastructure, dashboard systems, production know-how, user base, and any remaining private assets.

I do not believe the community should pay a large premium mainly for trademarks and continuity if the better strategic goal is provider diversity.

I am also concerned that nearly 80% of the requested budget goes to staffing.

The proposal asks the Treasury to fund six people for 18 months: four developers, one project manager, and one community manager. I do not object to paying people for critical infrastructure work, but the proposal should better explain why this exact team size is needed for the full transition period, what each role will deliver, and how the work will be publicly verifiable.

Based on visible public GitHub activity, I see ongoing maintenance and development, but not enough obvious evidence to justify four full-time developers for 18 months without a clearer roadmap and milestone-linked deliverables. Otherwise, the ask risks looking more like an 18-month payroll subsidy than a tightly scoped public-good transition.

There is also ambiguity around DevOps costs. The proposal says the Ops & Infrastructure budget covers the infrastructure stack and also the DevOps personnel who monitor and operate it, while the staffing budget separately includes four developers.

It should be clear whether DevOps labor is included in staffing, infrastructure, or both. I would expect a role-by-role allocation, expected public/open-source deliverables, and clear evidence that the staffing budget produces concrete public value.

I could support a smaller, milestone-based transition proposal if the transition is shorter. But I do not think an 18-month, ₳9.83M operating subsidy for the dominant provider is the best way to build long-term resilience.

Before allocating large funding of this type, DReps should coordinate on a broader access-layer strategy. We should first decide what kind of infrastructure market Cardano wants: one dominant public API funded by the Treasury, or a diverse ecosystem of providers. Without that strategy, each proposal is assessed in isolation, and the Treasury may unintentionally reinforce centralization.

Treasury funding should buy decentralization, redundancy, and competition in the access layer. As written, this proposal risks preserving dependency instead of reducing it.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote YES on the proposal: Daedalus Wallet Maintenance and Improvements 2026–2027.

My rationale:

According to the proposal, Daedalus has approximately 4,000 monthly active users. That is not even 1% of stakers, which number around 1.3M. I assume Daedalus users are primarily OGs, or a small portion of users who want the most decentralized solution possible.

This is still a relatively small user base compared to the requested budget. From a pure adoption or user-growth perspective, this would be difficult to justify.

However, I see Daedalus as public-good infrastructure. An open-source full-node wallet is essentially the most secure and self-sovereign solution that every ecosystem should offer, even if its user base is relatively small.

Daedalus is Cardano’s only full-node desktop wallet for regular users. It allows users to verify the chain directly, run their own local node, submit transactions without relying on third-party APIs, and preserve a stronger self-sovereign trust model than lite wallets.

This is important for decentralization and resilience. Cardano should not depend only on backend-based wallets, even if they are more convenient for most users.

Daedalus maintenance is not the same as building the Cardano node itself. The core node work is prepared upstream, including Leios and Peras. Daedalus integrates and ships that node in a wallet product. Although it is necessary to integrate the wallet with new features carefully, I do not see this as deep protocol R&D.

The proposal mentions Japanese localization. I do not consider localization alone to be a strong cost driver. The Daedalus codebase already has a structured i18n workflow, and AI tools can significantly reduce the cost of generating translations. Adding draft translations for additional languages should be relatively inexpensive.

A key reason for my YES vote is that the proposal includes improvements that make Daedalus more useful, especially CIP-30 support. Today, Daedalus users are largely excluded from the dApp and DeFi ecosystem unless they switch to a browser wallet. That is a serious limitation. If Daedalus is supposed to remain relevant, full-node users need a path to interact with dApps without fully abandoning the benefits of the full-node wallet model.

At the same time, I have reservations.

The proposal does not provide enough FTE transparency. It gives a total labor budget, but it does not clearly break down the number of FTEs, hourly or monthly rates, named roles, or allocation between maintenance, new features, support, and architecture assessment.

This is tolerable only because the IO did not provide this information either. However, DReps should strictly require it from the next NCL period.

For future funding requests, I expect more details. DReps should be able to understand what team size is being funded and how the monthly burn is justified.

Eternl decided to implement a sustainability plan. Wallets should not rely on subsidies forever. Especially since if we only support some wallets from Treasury, we are picking winners and putting other vendors at a disadvantage. Treasury cannot fund all wallets in the ecosystem.

Some parts of Daedalus may remain a public good, but the team should also explore whether non-core services can be commercialized or externally supported without compromising the wallet’s trust model.

My position is as follows. Daedalus has relatively few users and will definitely not trigger adoption growth. Nevertheless, Daedalus should be funded because Cardano benefits from having at least one maintained, open-source, full-node wallet available to non-technical users.

I strongly recommend reducing costs. I also encourage the team to explore sustainability options for Daedalus.

Some parts of Daedalus may remain a public good, but non-core services could potentially be commercialized or externally supported without compromising the wallet’s trust model. For example, after CIP-30 support is implemented, the team could evaluate optional swap or DEX aggregator functionality, with transparent fees and without weakening Daedalus’s full-node, self-sovereign model.

I understand that commercializing Daedalus with 4,000 users is challenging. However, I believe the team should still explore realistic sustainability options.

For context: A new Catalyst round with a budget of ₳2M is expected to be launched. This round is intended to support several teams. The costs of maintaining wallets should not be comparable to the budget for several teams. Cardano needs to invest in growth and adoption. Daedalus is a must-have wallet, but it will not fundamentally support ecosystem growth.

If the budget is even tighter next time, it may be necessary to make difficult trade-offs between maintaining Daedalus and funding growth-oriented initiatives.

I vote YES, but I consider this a one-year public-good maintenance bridge. Future proposals should provide clearer FTE details, stronger cost justification, transparent reporting, and a credible plan for long-term sustainability.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote YES on the proposal: Eternl: Path to Sustainability - v2.

My rationale:

Eternl is one of the most used wallets in the Cardano ecosystem, next to Yoroi, now SecondFi. The recent SecondFi wallet-drain incident shows that wallet security is not an abstract concern. When a wallet fails, users can lose real funds, and trust in the whole ecosystem is damaged.

This is exactly why Cardano needs several mature, reliable, and actively maintained wallets. The ecosystem should not depend on one dominant wallet or assume that historically popular wallets will always remain safe and trusted. Wallet diversity is part of ecosystem resilience.

I consider Eternl important infrastructure. Wallets are the interface through which users hold funds, stake, vote, interact with dApps, and participate in governance. If users lose trust in wallets, they lose trust in the ecosystem. For this reason, I believe important wallets need sufficient resources to maintain security and reliability.

I expect wallet teams that receive Treasury support to take security extremely seriously. This should include strong internal review, responsible handling of dependencies, hardware wallet support, careful transaction-building logic, and ideally independent technical security audits of critical wallet components. In my view, technical security audits of wallet software should become a normal expectation for Treasury-funded wallet infrastructure.

Eternl has an acceptable price per FTE, namely $70,000. In the context of other teams in the ecosystem, which often ask for much higher rates, this is a fair offer. I would like to see other teams reduce their development costs, because the Treasury cannot afford to cover excessively high development costs in the long term.

I appreciate the effort to introduce the Pro plan for personal and company use. This is the correct path to long-term sustainability. Wallets should move in this direction. Treasury can support important infrastructure for a limited period, but mature products must eventually be commercialized and not rely on recurring Treasury funding. With dwindling Treasury resources, this is absolutely necessary.

It is also important that Eternl plans to open source some libraries. I would prefer stronger open-source commitments, especially for Treasury-funded software, but this is a positive step. Open source should become a much stronger standard for projects receiving public ecosystem funds. After TapTools went out of business despite generous funding and without a meaningful willingness to open source, I am much less willing to support closed-source projects unless they show a credible path to sustainability, transparency, and public benefit.

I also appreciate that the Eternl DRep abstained from voting on its own proposal. This is the right standard. Conflicts of interest undermine trust in governance. Projects, DReps, and Founding Entities should avoid voting on their own funding whenever possible.

For these reasons, I vote YES.

This vote should not be interpreted as support for permanent Treasury subsidies. I expect Eternl to use this period to launch its Pro model, strengthen sustainability, continue improving wallet security, and reduce dependence on Treasury funding in the future.

If you would like to support my work, consider delegating to the MANDA pool and backing me as a DRep. Your support helps me dedicate more time to governance.

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I voted YES for the proposal: Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)

I vote YES on the van Rossem hard fork, provided the 85% SPO readiness requirement is verified before ratification.

It improves Plutus performance and capability, expands built-in availability across Plutus versions, introduces useful new primitives, and strengthens ledger correctness and node diagnostics.

The proposal presents testing, audit, conformance, and performance evidence, and the upgrade keeps Cardano in the Conway era with unchanged transaction shape, minimizing ecosystem disruption.

I vote YES on the technical merit of the van Rossem hard fork, but I will continue to monitor SPO readiness before the end of the voting period. If the 85% active-stake readiness threshold is not confirmed, I am prepared to change my vote, because the action should not proceed unless HARDFORK-04 is satisfied.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I have decided to vote NO on the proposal: Reforming Treasury Governance

My rationale:

I support the discussion opened by this proposal. Cardano needs a more coherent treasury process, and I agree that the current model of isolated treasury withdrawals is not sufficient for long-term strategic governance.

However, I cannot support the proposal in its current form because I have concerns about shifting decision-making power away from DReps and the community towards a strategic entity or expert commission.

Expert review can be useful. It can help with due diligence, technical evaluation, milestone assessment, and contract review. However, final accountability for Treasury decisions must remain with DReps and the community.

Any future model involving expert commissions or execution bodies must include strong transparency requirements, conflict-of-interest rules, clear appointment and removal mechanisms, public reporting, and meaningful oversight by DReps.

Changes to the Cardano Constitution should also accompany changes to the budget process and governance model.

The Constitution should more clearly separate the roles of voters (DReps) and executors. A party that can directly benefit from the approval of a proposal should not also act as a voter on that proposal.

Today, the rules are not applied evenly in practice. Some DReps abstain from voting on their own proposals, which can negatively affect approval, while Pentad members may support each other's proposals or their own proposal.

The Constitution should establish clear and consistent rules for all actors.

It may also be necessary to define additional governance roles and their competencies.

If an expert commission or execution body is established, elected DRep representatives should be part of it with one vote. They should have the right to review contracts under NDA where necessary.

DReps should retain the final authority to approve or reject recommendations made by such bodies.

Another important issue is cost. Establishing expert commissions or execution bodies can become expensive. Therefore, maximum compensation levels, budget limits, and accountability rules must be defined in advance.

Any future compensation model should avoid creating new imbalances. It would not be healthy for the governance system if execution bodies were generously compensated while DReps and CC members remained largely uncompensated.

Compensation should be transparent, proportionate, and aligned with responsibility.

The current Constitution addresses compensation primarily for Constitutional Committee members.

However, Treasury governance involves more actors and different kinds of responsibilities. DReps decide who receives funding, face significant public pressure, are asked for consultations, and are expected to provide rationales and oversight. The Constitution should address compensation more comprehensively for all governance actors.

The greater the DRep's voting power, the greater the responsibility and social pressure. The biggest ones are even forced to change their vote. Some DReps have already retired and left Cardano forever. This is an unacceptable situation.

One possible option is to allocate a small percentage of the NCL or approved budget, for example, 1–5%, to compensate for governance-related work. Another possibility is to link staking with governance in a way that better aligns incentives.

The NCL concept also needs reform. It should either be removed or turned into a proper protocol parameter. The protocol, or temporarily DReps, should ensure gradual allocation across the full NCL period. Allocating the entire budget at the beginning of a cycle is not a sustainable model.

The budget process should ensure that resources are distributed fairly across the ecosystem. Categories such as infrastructure, research, integrations, operations, ecosystem growth, tooling, education, and community support should be clearly defined.

Proposals should then request funding within specific categories, rather than forcing DReps to compare unrelated proposals against each other. We need a synchronization mechanism and to select the best proposals from many in a given category.

I would also support a multi-year planning model. DReps should approve a three-year strategic budget plan so that the ecosystem can see in advance which budget categories are expected to receive less funding over time, which categories are expected to receive more funding, and where future funding needs are likely to emerge. This would improve predictability, planning, and strategic alignment.

It is also essential that proposals follow a uniform format. If smaller submitters are expected to provide FTE estimates, cost breakdowns, and detailed milestones, the same requirements must apply to all proposals, including those submitted by founding entities.

Governance deserves deeper reform. These are only some of my thoughts, but they explain why I cannot support the proposed direction in its current form.

At the same time, I see this governance action as a useful starting point for debate. Every DRep may have a different view of what Cardano governance should look like, and this discussion is necessary.

However, any reform must preserve DRep accountability, prevent conflicts of interest, and ensure that Treasury governance remains transparent, fair, and community-controlled.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote YES on the proposal: IO: Hydra

My rationale:

Hydra is one of Cardano’s most important scaling technologies and one of the few L2 solutions already connected to real production use cases. This proposal focuses on hardening Hydra v2, improving performance, strengthening operations, supporting the ecosystem, and improving the developer experience.

This can help make Cardano viable for high-performance use cases such as institutional DeFi, agent payments, micropayments, gaming, voting infrastructure, and point-of-sale systems.

I would like to see multiple types of L2 solutions on Cardano, including alternatives to channel-based infrastructure. Technical diversity is healthy because different L2 designs serve different use cases.

However, Treasury funding must be disciplined. Several L2 or scaling-related initiatives have already received funding or support in the past. Before asking for additional funding, these projects should demonstrate delivery, adoption, and a credible path to real usage.

In my view, the Treasury should not try to fully fund every possible L2 direction at the same time. Given the Net Change Limit and current market sentiment, we need to focus on quality, not quantity. Only a small number of L2 solutions should receive major Treasury support, and continued funding should depend on evidence of production use, ecosystem demand, and measurable impact.

Hydra currently has the strongest case because it is the most mature Cardano L2, is ready for adoption, and already has real users. I therefore see this proposal as a strategic investment in adoption, while still expecting other funded L2 initiatives to deliver results before requesting further Treasury resources.

At the same time, it is important to recognize the broader context. In the Ethereum ecosystem, there is an ongoing debate about how much user activity and liquidity should remain on L2s versus returning to L1.

Cardano should have a clear L2 strategy before making repeated long-term investments into multiple scaling solutions.

The ask of ₳5.1M is significant, but reasonable for core infrastructure work.

However, IO should also work on commercializing Hydra and at least partially covering the costs of future development. I understand that this is difficult for an L2 designed to offer near-zero fees. Still, there are realistic options. IO could offer Hydra-as-a-service for teams that do not want to run infrastructure themselves. Another option could be enterprise support, integration services, or managed operational tooling.

My main concern is that detailed milestones, acceptance criteria, payment amounts, and delivery dates will be finalized later in the legal contract. Ideally, DReps should be able to review this level of detail before approving a treasury withdrawal. Even better, DReps should have representatives involved in milestone approval or oversight. Future proposals should improve this.

Despite a few concerns, I believe Hydra is strategically important for Cardano, has real users, and can support adoption that would otherwise move to competing ecosystems. Therefore, I support the proposal.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote YES on the treasury withdrawal to reimburse the lost deposit from the Ikigai Info governance action.

My rationale:

This is a narrow and justified reimbursement. The original Ikigai action was symbolic and submitted very early in Cardano’s on-chain governance era. The loss of the 100,000 ADA deposit was caused by a Cardano node bug that allowed an unregistered stake key to be used, making the deposit unrecoverable.

In my view, the submitter should not be financially punished for acting as an early participant in governance and helping test the system in practice. Reimbursing the deposit is therefore a matter of fairness and accountability.

The requested amount of 103,000 ADA is reasonable. It covers the original lost deposit plus a modest compensation for missed staking rewards. The funds go directly to the affected submitter, there are no operational costs, and the distribution can be verified on-chain.

For these reasons, I support this action.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote YES on the proposal to reduce the committeeMinSize parameter from 7 to 5.

My rationale:

My main reason is operational resilience. The current Constitutional Committee (CC) has 7 members, which is equal to the current minimum size. This makes governance fragile because a single resignation, expired term, or failure to maintain active membership can prevent the CC from satisfying the minimum-size requirement. As a result, governance actions that require CC approval may be blocked from progressing.

The purpose of this change is to create a safety buffer, not to concentrate governance power.

I recognize that this change comes with a trade-off. The parameter itself defines the minimum required number of CC members, not the desired operating size. However, if the CC were to operate with only 5 members, individual members would have more influence. With the current 2/3 approval threshold, 4 constitutional votes would be required, while 2 unconstitutional votes could prevent approval. This is a real governance risk.

However, the current situation is that the minimum is equal to the actual number of CC members. In my view, this creates unnecessary fragility. The risk of governance inoperability under the current setting is greater than the risk created by this limited reduction.

The proposal does not directly reduce the current number of CC members, and it does not imply that a 5-member CC should become the normal target. Ideally, Cardano should continue to maintain a 7-member committee. In the future, I would even support discussing a larger committee, for example, 9 members with a minimum of 7. That would provide both resilience and broader decentralization.

However, a larger committee only makes sense if the Constitution and governance process evolve to address the real problems that governance faces. For example, conflicts of interest should be handled explicitly. Today, CC approval of many governance actions may appear almost formal because most actions are not controversial from a constitutional perspective. If we expect a larger CC to add real value, the constitutional review process must be meaningful, independent, and relevant to the actual risks in governance.

An important aspect of my decision is incentives. Serving in governance is demanding work, especially during periods when treasury withdrawals are being reviewed. In my observation, there is not enough interest in the CC role relative to how important and demanding the work is.

Governance needs people with the right competence, independence, and willingness to devote sufficient time to the role. If this work remains difficult to fill, setting the minimum equal to the target number of members creates avoidable systemic risk.

We should also be honest about the recent context. Cardano has already experienced a situation where the retirement of a single CC member brought the committee below the required minimum. This exposed a mismatch between governance needs and the current incentive structure. I believe that once incentives are introduced for governance bodies, the number of qualified applicants will increase. We can reconsider a higher minimum later.

It is also important to note that the CC does not approve governance actions alone. Other governance bodies, especially DReps and, depending on the action type, SPOs, are also part of the ratification process. A smaller CC cannot approve governance actions by itself.

However, a smaller CC can make blocking easier. This is why the change should be treated as an operational safeguard, not as a governance-design ideal.

The proposed value of 5 complies with the relevant constitutional guardrails, has gone through the Parameter Committee process, and is reversible if needed. For these reasons, I support the change while expecting future CC elections to continue targeting 7 active members.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote YES for the proposal: Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026-2027.

My rationale:

My previous vote on the earlier version of this proposal was NO. The major reason was that Tweag was asking for a two-year budget, which I considered unfair to other submitters asking for funding. This issue has now been resolved.

I consider all three work packages important.

Peras is important for faster finality and a better user experience. History Expiry is important for long-term node sustainability and SPO costs, especially if Cardano throughput increases in the future. Conformance Testing is important because protocol upgrades such as Peras and Leios must be delivered safely, with strong testing and validation infrastructure.

My main concern remains the milestone structure. The proposal says that milestones, acceptance criteria, payment amounts, and delivery dates will be defined later in the legal contract between Tweag and Intersect. This means DReps are being asked to approve the treasury withdrawal before reviewing the full milestone-level detail.

In my view, this should be fixed in future proposals. DReps should be able to review milestones before voting, especially for large infrastructure budgets.

I accept this structure in this case mainly because Tweag has a strong track record in Cardano core infrastructure. However, this requires trust that Intersect will ensure the contract is well defined, with clear deliverables, acceptance criteria, reporting requirements, and refund conditions.

One broader concern is that core Cardano infrastructure funding is now distributed across multiple entities. Some work packages that were historically delivered within, or closely connected to, IO are now being funded through separate proposals from other specialist teams such as Tweag.

This may be a reasonable delivery model, especially when the teams have the right expertise, but it also makes it harder for DReps to understand the total annual cost of Cardano core infrastructure.

For that reason, I believe future infrastructure planning should provide a clearer combined view of expected funding needs across IO, Tweag, and other core contributors. This should ideally be available before DReps approve the 2027 Net Change Limit (NCL), so the community can assess treasury capacity with a full picture rather than evaluating each proposal in isolation.

For the next funding cycle, it would be helpful if both IO and Tweag communicated their expected future budget needs early.

I would appreciate it if Intersect could coordinate this process and help provide DReps with a clearer overview of the expected infrastructure funding pipeline before the NCL is approved.

I support this resubmitted proposal and vote YES.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I have decided to vote NO on the proposal Rare Evo and Dev Gov Day 2026: Cardano Title Sponsorship.

My rationale:

The team is trustworthy and has shown in the past that it can organize high-quality ecosystem events. Rare Evo is undoubtedly useful for networking, community building, and Cardano visibility. My concern is that this proposal is too broad, too expensive, and not strong enough in terms of measurable ROI.

In the context of previous Catalyst funding, this proposal raises a clear concern. Rare Evo has already received Catalyst-related support before, including event-related funding. A new direct-treasury proposal should clearly explain why this funding is incremental and not simply another subsidy for the same event infrastructure.

Rare Evo previously received ₳200K from Catalyst for event-related support. Now the same event ecosystem is asking for ₳2.75M from the Treasury, representing a nearly 14x budget increase. This request packages sponsorship, access, hospitality, travel support, admin costs, tax costs, and future-year costs into one proposal.

Even if the scope is larger, DReps should ask whether this increase is justified by measurable new outcomes, not only by more benefits and higher visibility. This is especially true since the proposal explicitly states that Rare Evo 2026 will occur regardless of treasury funding, meaning this massive request is strictly for premium branding upgrades and perks rather than the survival of the event infrastructure itself.

I also don't think the "free access" argument is sufficient on its own. Making a commercial event free for part of the Cardano community may be popular, but Treasury money should not mainly be used to subsidize attendance, food, drinks, hotels, or VIP perks. Looking at the breakdown, allocating over ₳312,000 for a single Happy Hour/Kickoff party and over ₳208,000 for event catering sets an unsustainable precedent for how Treasury funds should be deployed, favoring luxury hospitality over core development.

The community has pushed the Cardano Foundation to make the Cardano Summit more self-sustainable. I believe the same standard should apply here. For a commercial event, I would rather see a standard ticket model than a large Treasury request.

I am also uncomfortable with including a ₳208,333 venue deposit for 2027 inside a 2026 event proposal, especially when the proposal suggests that another Treasury request may follow. This feels like a weak fiscal precedent that attempts to lock the Treasury into future commitments before next year's proposal is even formally voted on.

The proposal says that 20% of VIP ticket sales will return to the Treasury, but without a projected VIP ticket volume, historical sales data, or a minimum guaranteed return, this is more symbolic than financial. A $900 VIP ticket sounds meaningful, but 20% of unknown sales is not a strong recovery mechanism.

Rare Evo 2026 appears to have multiple revenue streams, including tickets, sponsors, exhibitors, partners, and possibly premium/VIP/whale-pass revenue. Before the Cardano Treasury pays ₳2.75M, DReps should see a transparent financial breakdown for the whole event and the percentage of the total event budget Cardano is being asked to cover.

Cardano is being asked to buy a very large sponsorship package inside a commercial multi-chain event, but the proposal does not disclose enough information for DReps to know whether the price is fair or whether Cardano is disproportionately subsidizing an event that already has other sponsors, revenue streams, and private profit margins.

The wider governance context also matters.

DReps have already shown that they are not simply "anti-event," since TOKEN2049 was approved. At the same time, DReps rejected the Cardano Summit. If a Cardano-native flagship event was rejected because of cost, unclear ROI, or concerns about large event spending, then approving Rare Evo at ₳2.75M requires a strong justification.

In addition, there are other marketing-related proposals in the Intersect Budget process that have a chance to be approved, which makes a standalone request of this magnitude even harder to support without deep financial clarity.

Treasury-funded sponsorships must be judged as marketing investments, not as general community support. Before approving ₳2.75M, DReps should understand whether Cardano is buying fair marketing value or subsidizing private event revenue.

For these reasons, I cannot support this proposal in its current form. I would strongly welcome a revised, leaner proposal that focuses strictly on technical and governance infrastructure without anchoring it to high-cost commercial sponsorships and hospitality subsidies.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

This is the last-minute vote. I'm changing my vote to YES.

For reference, please check my previous rationale.

My conditions for accepting the proposal have been largely met.

• Catalyst proposal is done. The Catalyst platform displayed data incorrectly.
• The difference between Pebble and Catalyst-funded projects has been clarified.
• I have evidence that there is demand for Pebble from devs.
• I have decided not to insist on unbundling.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote NO on proposal: 5am.earth Trust Layer Targeting Vision 2030 KPIs

My rationale:

I see clear potential value in decentralized identity, traceability, stablecoin rails, credit access, and real-world data anchored to Cardano. These are exactly the types of use cases that could help Cardano become useful outside the crypto-native ecosystem.

However, I cannot support this proposal in its current form because I believe it creates too much risk for the Treasury and leaves too many important economic questions unanswered.

My main concern is that the proposal appears to use public Treasury funds to scale infrastructure that may later become a monetized commercial platform. The proposal does not clearly explain what the Cardano Treasury receives in return if that model succeeds.

There is no clear repayment mechanism. There is no concrete explanation of how future commercial value would flow back to the Cardano ecosystem beyond indirect benefits such as transactions, TVL, stablecoin usage, or reputation.

To be clear, those benefits matter, but they are not the same as repayment or value capture for the Treasury.

This creates an asymmetric risk/reward structure. The Treasury is being asked to fund the expensive early phase, while the Foundation, partners, or application providers may capture the future commercial upside.

If this is intended to be public infrastructure, then the proposal should clearly define which parts are open, whether other Cardano builders can access it on fair and transparent terms, and whether the Treasury receives any direct benefit if the platform becomes commercially successful.

I am also concerned about the budget transparency.

The proposal gives a strategic budget structure, but not a sufficiently detailed operational budget. It names categories such as farmer growth, satellite data, oracle infrastructure, Cardano integration, foundation support, administration, and audit, but it does not provide enough line-item allocation for DReps to judge whether the 10M ADA request is reasonable.

The proposal mixes very different cost profiles. For example, low-cost field work in countries such as India, Cambodia, and Kenya. This contrasts with international coordination and Swiss-based project coordination.

Without a detailed budget, it is difficult to know whether Treasury funds are mainly paying for farmer onboarding, third-party data providers, software vendors, or expensive managers.

The proposal says the Foundation should become self-sustaining through commercial partnerships and institutional backing by 2028 and should not return to the Treasury for operating costs.

A sustainability claim is not the same as signed contracts. DReps should understand who is expected to pay after Month 18 and what happens if those revenues do not materialize.

A 10M ADA Treasury withdrawal should have a much clearer budget, stronger public-good guarantees, better risk controls, and a more explicit explanation of Cardano’s value capture.

For these reasons, I consider this a high-risk proposal for the Treasury. In its current form, I cannot support approval.

I might support the proposal if the team provides a detailed operational budget, clear ownership and access terms, evidence of committed commercial revenue, and a stronger mechanism ensuring that Cardano and the Treasury benefit if the platform succeeds.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I have decided to vote NO on the proposal: Cardano Critical Integrations V2

My rationale:

The first Critical Integrations proposal, CCI V1, requested ₳70,000,000 and explicitly stated:

"Funds will be administered by Intersect under a performance and milestone-based structure over a period of up to 24 months."

It also stated that the budget covered integration work and related expenses, including deployment development, licensing fees, maintenance costs, and additional infrastructure required to support the integrations.

The current CCI V2 proposal now asks for an additional ₳23,000,000 to cover a focused “Year 2” contracted cost and a 12-month enhancement and maintenance program.

This includes platform and licensing fees, maintenance, operational costs, Cardano-side infrastructure, developer support, and related services for integrations that were already part of CCI V1.

In my view, these categories appear to substantially overlap with what the original ₳70,000,000 budget was already expected to cover over a period of up to 24 months.

Before asking the Cardano Treasury for additional funds, the proposers should provide a clear reconciliation of CCI V1: how much of the ₳70,000,000 has been committed, how much has been spent, how much remains, which partner contracts are already covered, and which Year-2 obligations were not included in the original budget.

The V2 proposal also does not clearly define when “Year 2” begins.

The V2 proposal says the new funds will be administered over a 12-month delivery window. Still, it does not clearly specify whether that period begins upon enactment, receipt of funds, contract signature, first drawdown, or the renewal dates of existing partner agreements.

This is especially important because CCI V1 was approved near the end of 2025 and was described as a budget administered over a period of up to 24 months.

Public announcements also suggest that some integrations are still relatively recent: USDCx was announced in February 2026, and Pyth live integration was announced in May 2026.

In that context, asking for an additional “Year 2” budget already in May 2026 appears premature unless the proposers clearly explain why V1 does not cover these costs and when the Year-2 period actually starts and ends.

Without that clarity, DReps cannot properly assess whether this proposal is timely, necessary, or an early renewal of costs that should already have been anticipated.

I understand that some vendor-level costs may be protected by confidentiality obligations and NDAs. I do not expect the proposers to disclose sensitive commercial terms for specific partners if that would violate agreements or harm negotiations.

Confidentiality around vendor pricing does not prevent the proposal from providing a clearer non-vendor-level breakdown.

The proposal allocates ₳20,700,000, approximately 90% of the total request, to “Integration and maintenance costs,” but this category combines many different items: licensing, platform fees, attestor operations, relayers, oracle infrastructure, custody, Fireblocks costs, infrastructure fees, and maintenance.

DReps are not told how much of this amount is expected to go to external NDA-covered vendors, how much is for Cardano-side engineering, how much is for work performed by Pentad-related teams or contractors, and how much is pass-through infrastructure or operational overhead.

That distinction matters. Confidential vendor pricing can remain private, but DReps should still be able to evaluate whether non-confidential engineering, support, and FTE-like costs are reasonable and not already covered elsewhere.

The current structure requires DReps to approve a large treasury withdrawal before they have access to the underlying contracts, commercial terms, vendor-level pricing, or detailed allocation logic.

The proposal says that Statements of Work will be submitted and verified, and that some information will be disclosed through progress reports, but it does not make clear whether DReps will be able to review the relevant SoWs before approval or before drawdowns. This creates a governance gap: DReps are accountable for approving treasury withdrawals, but they cannot independently verify the full basis for the spending decision at the time of voting.

For future proposals of this kind, I would support a stronger DRep-facing oversight mechanism.

A reasonable solution could be a small group of DRep-elected representatives, bound by NDAs and strict conflict-of-interest rules, who can inspect the relevant contracts and drawdown requests confidentially.

They would not disclose sensitive vendor terms, but they could provide public attestations that the spending matches the approved scope and that the split between vendor costs, internal engineering, infrastructure, administration, and overhead is reasonable.

I must mention that I have read Intersect’s Critical Integrations status reports, and I acknowledge that they provide useful progress updates on the integrations.

However, they do not provide the clarity I need as a DRep: they do not clearly explain why the original CCI V1 budget does not cover the relevant costs over its stated period of up to 24 months, when the CCI V2 “Year 2” period precisely begins, or how the non-NDA portion of the budget is broken down.

I want to be very clear: I support Critical Integrations for Cardano. I also understand that a NO vote may be unpopular and may bring public criticism. I accept that.

As a DRep, my responsibility is to protect the Treasury and approve funding only when the scope, timing, and budget are clear enough to evaluate.

Supporting Critical Integrations and requiring clarity are not contradictory. I want to support this proposal, but clarity is not optional. Until the key questions are answered, I cannot responsibly vote YES.

My conditions for approval are:

1. Explain why the original CCI V1 proposal does not already cover the relevant costs over its stated period of up to 24 months.

2. Define the exact period for the CCI V2 “Year 2” budget, including when the 12-month window starts and ends.

3. Provide a clearer anonymized breakdown of non-NDA costs, especially separating external vendor/license costs from Cardano-side engineering, infrastructure operations, support, tooling, administration, and any Pentad-related or contractor work.

Until these points are clarified, I cannot support the proposal in its current form.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote YES for proposal: Update Plutus Cost Models

My rationale:

This is a technical parameter update that enables the new Plutus primitives that will become available after the van Rossem hard fork to Protocol Version 11. It extends relevant primitives consistently across Plutus V1, V2, and V3, and updates some existing primitive costs based on benchmarking.

For this kind of highly technical parameter change, DReps cannot reasonably be expected to independently verify every cost-model coefficient. The important question is whether the process was credible, reviewed, tested, and consistent with the constitutional guardrails.

In this case, the proposal states that the changes were recommended by Intersect's Parameter Committee, confirmed by the Technical Steering Committee, benchmarked against the reference implementation, and already enacted on SanchoNet, Preview, and Preprod testnets.

I trust Intersect's Parameter Committee and the process followed here. Cost model updates are exactly the kind of work where the ecosystem needs a competent technical body to review benchmarks, assess consistency with guardrails, and recommend safe parameter changes.

Approving this action is basically essential. Without the appropriate cost model settings, the new Plutus functionality introduced with Protocol Version 11 cannot be properly enabled and used. This would unnecessarily limit developer capabilities and reduce the value of the upcoming hard fork.

My support should be understood as support for the technical process, the committee recommendation, and the need to keep Plutus cost models aligned with protocol upgrades.

Unless credible technical objections are raised by qualified Plutus or ledger engineers, I believe this action should be approved.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote YES for the proposal: The first node in the browser; a Cardano USP.

This proposal concerns Gerolamo, a TypeScript implementation of a Cardano node, scoped specifically to the browser-extension light-node use case. The goal is to deliver a production-ready Cardano light node that can run in the browser and expose a messaging API to dApps and wallets. This would allow applications to obtain locally verified chain data instead of relying entirely on trusted external servers.

The main reason I support this proposal is that Gerolamo could help move Cardano wallets and dApps toward a more trust-minimized model. Today, many applications depend heavily on backend providers, indexers, APIs, or other server-side infrastructure. This is convenient, but it also creates dependency on external services. A browser-based validating node could allow users and developers to interact with Cardano with stronger local verification guarantees.

This does not only matter for users who explicitly demand maximum sovereignty. Most users probably do not think in terms of “full validation” or “trust minimization.” However, they can still benefit from applications that are more reliable, more responsive, and less dependent on centralized infrastructure. If delivered successfully, Gerolamo could make stronger security assumptions available through ordinary browser-based applications.

I also see value in Gerolamo from the perspective of client diversity. Cardano should not rely forever on a single dominant node implementation or one main codebase at the networking and validation layer. Gerolamo is not funded here as a block-producing node, and server-side relay roles are explicitly out of scope under this proposal. However, a successful TypeScript implementation of ledger validation, networking, and browser-based node architecture could become an important foundation for future alternative node work.

That said, my YES vote is not without concerns.

I also note that Gerolamo has received previous funding, and based on the public project status, the final milestone from that earlier funding appears to remain paused or unfinished. I do not consider this, by itself, a reason to reject the current proposal, especially because the new proposal has a clearer scope and a stronger milestone-based structure. However, I would still like HLabs to provide a clear retrospective on the previous funding.

Second, the proposal still carries high execution risk. A browser-based Cardano node is technically plausible, but difficult. The hardest part is not simply making something sync in a browser. The hard part is the correct and robust implementation of ledger rules, chain selection, rollback handling, Plutus validation, protocol parameter changes, storage behavior, and conformance with the reference implementation.

The author's clarification was useful, especially regarding the proxy architecture, Mithril, browser runtime assumptions, and the distinction between technical feasibility and production readiness. However, it also confirms that conformance is not currently a milestone-gated requirement, even though a significant part of the Haskell node conformance tests has reportedly been ported, and more work is ongoing.

Third, I recognize that demand for this kind of infrastructure is not always easy to prove in advance. Users do not usually ask directly for client diversity, local validation, or reduced RPC dependency, but they can benefit from these properties indirectly through more resilient and trust-minimized applications.

For this reason, I do not consider the absence of a fully proven demand to be a reason to reject the proposal. However, adoption remains an important factor to watch. I would welcome clear communication from HLabs during delivery about potential wallet or dApp integrations, proxy operator interest, and usage indicators that show whether Gerolamo is moving from technical capability toward practical ecosystem adoption.

In conclusion, I am voting YES because I believe Gerolamo addresses an important long-term infrastructure need for Cardano: more trust-minimized dApps and wallets, reduced dependency on centralized backend services, stronger client diversity, and a potentially distinctive browser-based validation model.

At the same time, I recognize that this is an ambitious infrastructure proposal with meaningful technical and adoption risks. My YES vote reflects support for the direction, the potential ecosystem benefits, and the team’s continued work, while also recognizing that delivery should be followed closely by the community. In particular, I will be looking for transparent reporting on progress, conformance work, benchmarks, adoption signals, and how the team builds on lessons from the previous Gerolamo funding.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I have decided to vote NO on the proposal: Eternl: Path to Sustainability (2026–2027)

My rationale:

I want to begin by saying that I respect the Eternl team and the work they have done for Cardano. Eternl is one of the top wallets in the ecosystem and should be preserved. Wallets are a critical infrastructure that users cannot do without. The quality of wallets significantly influences how users perceive the quality, reliability, and capabilities of the entire ecosystem.

Wallets must be maintained. They must prepare for hard forks, implement new CIPs, support new ledger and governance features, maintain compatibility with hardware wallets and DApps, and provide users with a reliable interface to the Cardano network.

For this reason, I believe it can make sense for wallet teams to seek Treasury support for maintenance and protocol-related work. However, I am less convinced that the Treasury should fund product expansion, proprietary roadmap items, or commercial growth features.

Some parts of this proposal may be appropriate for Treasury funding, mainly maintenance, hard-fork readiness, security-critical upgrades, CIP implementation, governance compatibility, and the infrastructure required to keep the wallet operational.

Other parts of the roadmap may be better suited for the Draper Orion Fund or other funding vehicles rather than a direct Treasury withdrawal. In general, growth-oriented products with potential revenue models should be funded through mechanisms that include external due diligence, clear expectations, and measurable return to the ecosystem.

Eternl has already received significant public support. From Catalyst, the ADA-denominated grants are ₳69.2k, ₳554k, and ₳20.8k, for a total of ₳644k. Together with last year’s on-chain Treasury withdrawal of ₳583k, this equals approximately ₳1.227M. In addition, Eternl received USD-denominated Catalyst grants of $90k, $90k, and $46k, for a total of $226k USD.

This is substantial ecosystem support. I do not say this to diminish Eternl’s contribution, but to point out that future requests should be more narrowly focused on public-good maintenance rather than expansion. We should also give other wallets room to grow and compete fairly.

For the Treasury, picking winners is always complicated. There is currently no clear consensus or rule among DReps on how to fund public goods, especially when the beneficiary is a private product competing in a market with several other wallets. This makes the decision harder.

In the current market conditions, it is challenging for wallets and DeFi protocols to build a functional business model. I recognize that reality, and I am willing to consider Treasury funding for maintenance and protocol-critical work. But I believe we should be cautious when Treasury funding supports the expansion of one already-dominant wallet over others.

For wallets, the long-term path must be to find a sustainable business model. Eternl appears to have found one and is now expanding it through paid services. I appreciate this direction. However, if a wallet is moving toward a commercial model, then Treasury funding should be limited to clearly defined public-good work, not general operations or growth. Paid services, premium features, and enterprise-style tools should ideally be funded by customers, investors, or ecosystem investment vehicles rather than direct grants.

A YES decision would also be easier if Eternl were open source. I understand that not every team is ready to open source its entire product, and I respect the need to protect business interests and security-sensitive parts of the codebase.

However, when a project seeks repeated Treasury funding, the public-good argument becomes stronger when important components are open, reusable, and verifiable by the community.

Eternl mentions that some libraries will be published, which is a positive step. In my view, this should happen before asking for another broad Treasury withdrawal, not after. Open-sourcing important components would make it easier to distinguish between public-good funding and private product funding.

I am also concerned that Eternl plans to vote YES on its own proposal. This is not ideal in our young governance system. We should cultivate a healthy governance culture from the beginning. Proposers should not vote for proposals from which they directly benefit. In an ideal governance culture, even founding entities may need to be very careful when voting on proposals connected to their own interests. It would be more appropriate and more credible for Eternl to abstain and leave the decision to other DReps, especially because Eternl is one of the largest DReps in the ecosystem.

For these reasons, I am voting NO. I remain open to supporting a revised proposal under these conditions:

• Open source important components of Eternl that are funded as public goods.
• Reduce the requested scope and ask specifically for maintenance, hard-fork readiness, CIP implementation, and governance-critical work.
• Abstain as a DRep on proposals from which Eternl or Tastenkunst directly benefits.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote NO for proposal: Scalus: Cardano’s Application Platform for Building, Launching, and Scaling

My rationale:

I want to be clear that this is not a vote against Scalus as a technical project or against the capabilities of Alexander Nemish and the Lantr team. The team has delivered tangible outputs and has clearly contributed meaningful work to the Cardano ecosystem.

However, treasury decisions must evaluate not only technical ambition, but also adoption, ecosystem demand, proportionality of funding, and whether prior treasury allocations have demonstrated enough traction to justify significantly larger follow-on funding. After reviewing those factors, I do not believe this proposal meets that threshold.

My primary concern is that this proposal asks the Treasury to make a very large leap before the original thesis has been sufficiently validated.

In 2025, Scalus already received an approved treasury withdrawal of ₳657,692 for “Scalus – DApps Development Platform.” That proposal was approved to validate the idea that Cardano developers could benefit from a Scala-based unified development experience where smart contracts, transaction building, and application logic could all be written in one language.

That treasury allocation was already a significant step up from earlier Catalyst grants, where the team requested much smaller and more narrowly scoped funding.

For example, one Catalyst proposal requested only ₳100,000 for a three-month engagement involving roughly 2.5 months of development by two engineers to build a cross-platform transaction builder API. Earlier Catalyst proposals were similarly focused and relatively modest in scope. In total, Scalus has previously received roughly ₳1.08M across Catalyst and treasury funding.

Now, less than a year later, the team is requesting ₳8.5M, which represents nearly eight times all prior funding combined. While ADA volatility makes USD comparisons imperfect, this is still a very substantial increase.

Last year, the treasury funded a development platform. This year, the Treasury is being asked to fund a full application platform, runtime infrastructure, formal verification tooling, L2 integrations, observability tooling, enterprise onboarding capabilities, and significant node-level infrastructure.

This moves far beyond validating product-market fit and instead expands horizontally into multiple adjacent areas before proving that the original thesis has achieved broad adoption.

That leads directly to my second concern: ecosystem demand.

The proposal repeatedly argues that Scalus unlocks access to millions of JVM developers and creates a bridge for enterprise adoption. However, the actual data we have about Cardano developers tells a different story.

The Cardano Foundation 2025 Developer Ecosystem Survey shows that Cardano developers primarily rely on JavaScript, TypeScript, Python, Rust, and Haskell for broader application development.

On the smart contract side, Aiken has clearly become the dominant non-Haskell language because it directly addresses many of the developer experience concerns highlighted in the survey. When developers were asked what they would use to write Plutus scripts, 83 respondents selected Aiken, while only 10 selected Scalus, the same number as Plu-ts.

The survey highlights demand for better onboarding, documentation, examples, and simpler workflows, but it does not indicate strong demand for a large Scala-centric platform. The “26 million JVM developers” argument reflects theoretical market potential rather than evidence of actual developer adoption within Cardano today.

The proposal also fails to provide meaningful adoption metrics that would justify funding at this level. For an ₳8.5M request, I would expect clear evidence of active developer usage, recurring external contributors, meaningful production deployments, or measurable ecosystem dependence.

The proposal itself reflects how early adoption still is by setting targets of only five external teams, two production deployments, and two ecosystem integrations during the funding period.

I am also concerned about the proposal’s node-related scope. It introduces significant node-level infrastructure ambitions while remaining unclear about how far this effort goes and why this additional infrastructure is necessary at this stage.

Cardano has already allocated substantial treasury resources toward infrastructure, including initiatives such as Amaru and Dingo. Perhaps the Gerolamo proposal will also be approved.

While infrastructure remains important, I believe future treasury allocations should increasingly prioritize growth, user adoption, and helping existing builders scale successfully.

Cardano’s biggest challenge today is not a lack of infrastructure proposals. It is a lack of users, applications with meaningful traction, and broader ecosystem growth. This proposal continues expanding deeper into infrastructure before proving strong demand for what has already been built.

Ultimately, my concern is not the quality of the team or the legitimacy of the project. My concern is proportionality.

Treasury should fund demonstrated ecosystem demand rather than speculative platform expansion. I would have been far more supportive of a smaller proposal in the range of ₳1M–2M focused on validating adoption, proving real usage, and expanding incrementally based on demonstrated demand.

Scalus may still become a valuable part of Cardano’s tooling ecosystem, but I do not believe this level of funding is justified today.

For these reasons, I voted NO.

If you find my governance work valuable, consider supporting me:

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote NO on proposal: Cardano dOSPO and OMF Program

My rationale:

First, I want to be clear that I strongly support the emergence of specialized DAOs and new governance structures in Cardano. I believe governance should evolve beyond direct Treasury Withdrawal requests for every type of work.

This proposal highlights a legitimate category where direct funding requests may not always be practical. In particular, upstream open-source dependencies that Cardano relies on may not be aware that Cardano depends on them.

However, I do not believe this proposal is sufficiently well-defined to justify approval in its current form.

My first concern is the three-year budget commitment.

Most teams in this funding cycle are requesting one year of funding and returning to governance for renewed approval. This proposal asks the treasury to commit 12 million ADA over 36 months upfront, which I do not believe reflects healthy treasury governance.

Cardano governance is still young. Locking treasury budget authority for such a long period reduces flexibility and weakens future governance oversight.

While the proposal does include early termination clauses and a mechanism to return uncommitted funds, an upfront 36-month approval shifts the burden of proof. Instead of the program operator returning to show results for a standard yearly renewal, the burden is placed on DReps to actively coordinate an extraordinary termination vote if the program’s strategic direction underperforms after year one.

A better approach would be to request funding for one year, demonstrate results, and return to governance for renewal based on measurable outcomes.

My second concern is the governance structure itself.

The proposal introduces two advisory councils, but the Technical Community Advisory Council may include active maintainers, contributors, and infrastructure participants whose own projects could later become eligible for funding. That creates a clear conflict-of-interest risk.

While technical expertise is absolutely necessary, experts should not be placed in a position where they can effectively act as both applicants and gatekeepers. The proposal mentions signed conflict-of-interest policies, but it does not provide sufficient safeguards such as public disclosure requirements, transparent voting records, or clear restrictions on participating in decisions that directly benefit affiliated projects.

More importantly, I believe DReps should have a stronger role in this structure. While the proposal allows DReps to authorize the total budget block, they are effectively removed from the actual project allocation decisions once the program begins.

I would prefer a hybrid model where technical experts conduct dependency analysis, assess risk, and provide funding recommendations, while DReps, either directly or through specialized DRep-created governance DAOs, review major allocations, co-approve funding decisions, oversee reallocations, and retain authority to replace operators or intervene when governance failures occur.

My third concern is the scope of what may be funded, particularly external open-source dependencies. I understand the argument that Cardano relies on upstream infrastructure.

In some cases, supporting those dependencies may be entirely reasonable. However, the current scope is too broad and the boundaries are not clearly defined.

The proposal references external dependencies such as OpenSSL and NGINX to justify broader upstream funding, but it does not clearly explain under what circumstances Cardano treasury funding should be used for globally shared infrastructure.

While supporting critical upstream dependencies may sometimes be justified, the proposal should provide clearer criteria to ensure Cardano is funding infrastructure where ecosystem reliance is substantial, maintainer risk is real, and alternative funding sources are limited.

This concern becomes even more significant when looking at existing proposals already operating in adjacent areas.

Cardano Tooling DAO is focused on Cardano-native tooling such as APIs, SDKs, explorers, analytics platforms, and developer infrastructure.

At the same time, Intersect Open Source Committee is already requesting treasury funding through its Paid Open Source Model for maintainer retainers, tooling sustainability, contributor pipelines, and ecosystem reporting.

dOSPO explicitly states that it is intended to replace the Intersect Open Source Committee’s Paid Open Source Model in a more decentralized form. That may be a legitimate direction, but both proposals are currently active within the same funding cycle and the transition between them is not clearly defined.

Without clearer coordination and transition planning, there is a risk that Treasury could fund overlapping programs simultaneously rather than managing a deliberate and efficient handover of responsibilities.

This concern is amplified by the fact that Christian Taylor previously worked within Intersect's open-source structures before proposing this alternative model, and that for the first six months, the treasury funds will be managed by his private consultancy before an independent legal entity is even formed.

Before creating another large funding body, I believe there needs to be much clearer justification for why this structure must exist separately from existing initiatives and what exact problem it solves that existing structures cannot address.

Conditions under which I could support a future version of this proposal:

• Limit the budget request to one year, with renewal based on demonstrated results

• Clearly define the boundaries between dOSPO, Cardano Tooling DAO, and Intersect Open Source Committee to avoid duplication

• Create stronger conflict-of-interest protections and explicit recusal rules for council members

• Give DReps a formal oversight role in major allocation decisions

• More clearly define when funding external open-source dependencies is appropriate

I support experimentation, I support DAOs, and I support solving real open-source sustainability challenges. However, in its current form, this proposal is too broad, overlaps with existing initiatives, and does not provide sufficient governance clarity for a commitment of this size.

Therefore, I am voting NO.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote NO for proposal: [OriLife × TonFarm] Identifying 180 Million Durians Without Physical Labels

My rationale:

While I appreciate your effort to address a real-world problem, I do not believe this is an appropriate use of Cardano Treasury funds.

My primary concern is the proposal's own economic logic. The team repeatedly argues that demand for this solution is effectively guaranteed because traceability compliance will be required by the Vietnamese government and export markets.

If that is true, then there should already be clear commercial demand from the actual beneficiaries of the system: farmers, exporters, traders, processors, or supply chain operators. If compliance becomes mandatory, these stakeholders should be willing to pay for the service themselves.

Treasury funds should not subsidize customer acquisition or commercial deployment for a private business operating in a market that it claims is already guaranteed.

This concern becomes even stronger because the proposal does not offer meaningful direct value back to the Cardano Treasury.

The proposal references locked ADA, transaction fees, and ecosystem growth as forms of return, but these are indirect benefits. There is no meaningful revenue-sharing mechanism, repayment model, profit-sharing structure, or direct treasury return.

In practice, Cardano Treasury absorbs early-stage deployment risk while the private operators appear positioned to capture most of the long-term commercial upside.

The proposal explicitly confirms that the team previously deployed this model on TON before bringing it to Cardano. While migration between ecosystems is normal, it raises legitimate questions about why Cardano Treasury should fund the scaling of a business model that was initially validated elsewhere.

I am also concerned about duplication of existing efforts. The Cardano Foundation has already supported traceability initiatives, including Originate and earlier partnerships focused on supply-chain verification.

More broadly, this is already a highly competitive sector with existing players such as VeChain, IBM, and TE-FOOD. The proposal's core traceability stack does not appear sufficiently differentiated to justify treasury funding at this scale.

The only potentially unique element is the biometric identification of individual durians through image recognition. However, this is also one of the biggest risks in the proposal.

It remains unclear how verification works in practice after the initial registration. If another image must be taken later for verification, the proposal does not sufficiently explain how the system handles real-world conditions. Agricultural environments are highly unpredictable, and the proposal does not provide enough independent validation data to demonstrate that this approach works reliably at the claimed scale of 180 million fruits.

Regarding the technical architecture, the proposal utilizes 12,000 CIP-68 farm NFTs to track harvest data. While this is a technically valid use of Cardano primitives, I am not convinced that such a complex on-chain structure is essential to solve the underlying business problem.

Layering NFTs with DIDs, Merkle batching, Hydra, Midnight, and multiple off-chain systems creates an overengineered stack that introduces significant operational and technical risk. For a project focused on agricultural compliance, a leaner architecture using DIDs and simpler data availability layers would likely be more robust without introducing unnecessary NFT-based state management complexity and associated minADA requirements.

The proposal is also extremely ambitious in its operational scaling assumptions, moving from smaller pilots to 180 million fruits across 12,000 hectares within a relatively short timeframe.

I fully support entrepreneurs choosing Cardano as their infrastructure layer, and the team is free to build on Cardano. A successful deployment could certainly create positive visibility for Cardano and may encourage broader enterprise adoption in similar industries.

However, requesting Treasury funds is a different matter and requires a much stronger public-good justification.

In this case, the proposal operates in an existing commercial market with established competitors and a customer base that the proposal itself describes as mandatory due to regulatory pressure. While broader ecosystem visibility is a potential upside, I do not believe that possibility alone justifies Treasury spending to subsidize the commercial execution risk or market expansion of a private business operating in a commercially viable sector.

For these reasons, I am voting NO.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

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

My rationale:

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

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

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

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

The first issue is the two-year budget request.

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

I do not believe this is healthy treasury governance.

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

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

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

The second issue is cost.

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

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

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

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

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

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

The third issue is bundling.

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

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

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

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

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

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

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

For me, the path to approval is straightforward:

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

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

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

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

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I have decided to vote on the three crypto event proposals as follows:

• Revised Cardano Summit 2026 Singapore: ABSTAIN
• TOKEN2049 Singapore 2026 Baseline “Platinum” Sponsorship proposed by EMURGO: YES
• TOKEN2049 Singapore 2026 Top-Up “Title” Sponsorship Upgrade: NO

Given that DReps have to process a large number of proposals in the coming weeks, I will provide one short rationale for all three proposals.

My rationale:

First of all, thank you to both the Cardano Foundation and EMURGO for accepting feedback and resubmitting proposals.

I do not oppose the idea of a Cardano Summit. My concern is primarily about treasury allocation and long-term sustainability. Cardano Foundation owns and manages the Cardano brand and remains one of the strongest-capitalized entities in the ecosystem. According to its 2025 financial report, the Foundation held approximately $361M in assets at the end of 2025, including roughly $280M in crypto assets and approximately $80M in fiat and traditional financial assets.

If the Foundation believes the Summit is strategically critical for Cardano, I believe it should be willing to finance a larger portion of the event from its own resources.

My second concern is that the Foundation previously communicated that the Summit should become increasingly sustainable over time.

The current proposal does not provide enough clarity on what that actually means. I still do not know whether future Summits will require treasury funding, how much funding may be requested in future years, or when the Summit is expected to become financially self-sustaining.

The proposal mentions that revenue from the 2026 Summit will help fund future events, but it does not clearly state that future treasury requests will stop. Given the large funding requirements from IO, Intersect, infrastructure teams, and builders across the ecosystem, I am not comfortable approving both major event proposals.

At the same time, I recognize that other DReps support the Summit and consider it strategically important. My current position is somewhere between NO and ABSTAIN.

That is why I decided to abstain rather than vote NO.

I decided to support the baseline TOKEN2049 Singapore 2026 proposal because it gives Cardano exposure beyond its own ecosystem. Unlike the Summit, which is naturally more focused on existing Cardano community members, TOKEN2049 puts Cardano in front of a much broader audience that includes investors, exchanges, market makers, media, founders, developers, enterprises, and builders from other ecosystems.

I believe Cardano still needs stronger external visibility, and this proposal addresses that more directly.

For approximately $792,900, the baseline proposal gives Cardano a large booth at the event, a dedicated builder stage, live product demonstrations, lead generation tools, networking access, ecosystem tickets, and post-event reporting requirements.

More importantly, it gives Cardano builders direct access to people who are not already part of the ecosystem. That is a much stronger value proposition than spending significantly more money to create a separate event in the same city just two days earlier.

I understand that EMURGO has faced criticism from parts of the community in the past. However, DReps should evaluate proposals based on current execution plans and expected outcomes. I appreciate that EMURGO recently addressed concerns related to DRep selection in Yoroi Wallet, and I am willing to give them a second chance.

I want to make a pragmatic decision.

In this case, EMURGO is leveraging an existing global event, which significantly reduces operational complexity. The proposal also includes concrete deliverables such as builder showcases, live demos, partnership targets, media exposure, and measurable post-event reporting. While some KPIs should always be viewed critically, I believe the overall direction is pragmatic and focused on external ecosystem growth.

I do not support the Top-Up proposal because I do not believe the additional $424,360 is justified. The extra spending mainly buys a larger booth, a keynote slot, lanyard branding, protein shake branding, and additional media exposure.

In my view, the baseline proposal already captures most of the meaningful value, and the upgrade feels like diminishing returns and unnecessary prestige spending.

This is ultimately a pragmatic treasury allocation decision. Cardano should not disappear from major crypto conversations, media, and broader crypto audiences. I believe supporting one meaningful external-facing marketing initiative is reasonable.

At the same time, treasury resources remain limited, and I do not believe it is responsible to fund multiple overlapping event proposals.

If one of these events is approved, I will likely be significantly more conservative when evaluating other marketing-related proposals.

I may still change my mind before voting closes. If it becomes clear that the EMURGO proposals have no realistic path to approval while the Foundation proposal does, I may reconsider my position and adjust my votes accordingly.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I have decided to vote on the three crypto event proposals as follows:

• Revised Cardano Summit 2026 Singapore: ABSTAIN
• TOKEN2049 Singapore 2026 Baseline “Platinum” Sponsorship proposed by EMURGO: YES
• TOKEN2049 Singapore 2026 Top-Up “Title” Sponsorship Upgrade: NO

Given that DReps have to process a large number of proposals in the coming weeks, I will provide one short rationale for all three proposals.

My rationale:

First of all, thank you to both the Cardano Foundation and EMURGO for accepting feedback and resubmitting proposals.

I do not oppose the idea of a Cardano Summit. My concern is primarily about treasury allocation and long-term sustainability. Cardano Foundation owns and manages the Cardano brand and remains one of the strongest-capitalized entities in the ecosystem. According to its 2025 financial report, the Foundation held approximately $361M in assets at the end of 2025, including roughly $280M in crypto assets and approximately $80M in fiat and traditional financial assets.

If the Foundation believes the Summit is strategically critical for Cardano, I believe it should be willing to finance a larger portion of the event from its own resources.

My second concern is that the Foundation previously communicated that the Summit should become increasingly sustainable over time.

The current proposal does not provide enough clarity on what that actually means. I still do not know whether future Summits will require treasury funding, how much funding may be requested in future years, or when the Summit is expected to become financially self-sustaining.

The proposal mentions that revenue from the 2026 Summit will help fund future events, but it does not clearly state that future treasury requests will stop. Given the large funding requirements from IO, Intersect, infrastructure teams, and builders across the ecosystem, I am not comfortable approving both major event proposals.

At the same time, I recognize that other DReps support the Summit and consider it strategically important. My current position is somewhere between NO and ABSTAIN.

That is why I decided to abstain rather than vote NO.

I decided to support the baseline TOKEN2049 Singapore 2026 proposal because it gives Cardano exposure beyond its own ecosystem. Unlike the Summit, which is naturally more focused on existing Cardano community members, TOKEN2049 puts Cardano in front of a much broader audience that includes investors, exchanges, market makers, media, founders, developers, enterprises, and builders from other ecosystems.

I believe Cardano still needs stronger external visibility, and this proposal addresses that more directly.

For approximately $792,900, the baseline proposal gives Cardano a large booth at the event, a dedicated builder stage, live product demonstrations, lead generation tools, networking access, ecosystem tickets, and post-event reporting requirements.

More importantly, it gives Cardano builders direct access to people who are not already part of the ecosystem. That is a much stronger value proposition than spending significantly more money to create a separate event in the same city just two days earlier.

I understand that EMURGO has faced criticism from parts of the community in the past. However, DReps should evaluate proposals based on current execution plans and expected outcomes. I appreciate that EMURGO recently addressed concerns related to DRep selection in Yoroi Wallet, and I am willing to give them a second chance.

I want to make a pragmatic decision.

In this case, EMURGO is leveraging an existing global event, which significantly reduces operational complexity. The proposal also includes concrete deliverables such as builder showcases, live demos, partnership targets, media exposure, and measurable post-event reporting. While some KPIs should always be viewed critically, I believe the overall direction is pragmatic and focused on external ecosystem growth.

I do not support the Top-Up proposal because I do not believe the additional $424,360 is justified. The extra spending mainly buys a larger booth, a keynote slot, lanyard branding, protein shake branding, and additional media exposure.

In my view, the baseline proposal already captures most of the meaningful value, and the upgrade feels like diminishing returns and unnecessary prestige spending.

This is ultimately a pragmatic treasury allocation decision. Cardano should not disappear from major crypto conversations, media, and broader crypto audiences. I believe supporting one meaningful external-facing marketing initiative is reasonable.

At the same time, treasury resources remain limited, and I do not believe it is responsible to fund multiple overlapping event proposals.

If one of these events is approved, I will likely be significantly more conservative when evaluating other marketing-related proposals.

I may still change my mind before voting closes. If it becomes clear that the EMURGO proposals have no realistic path to approval while the Foundation proposal does, I may reconsider my position and adjust my votes accordingly.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I have decided to vote on the three crypto event proposals as follows:

• Revised Cardano Summit 2026 Singapore: ABSTAIN
• TOKEN2049 Singapore 2026 Baseline “Platinum” Sponsorship proposed by EMURGO: YES
• TOKEN2049 Singapore 2026 Top-Up “Title” Sponsorship Upgrade: NO

Given that DReps have to process a large number of proposals in the coming weeks, I will provide one short rationale for all three proposals.

My rationale:

First of all, thank you to both the Cardano Foundation and EMURGO for accepting feedback and resubmitting proposals.

I do not oppose the idea of a Cardano Summit. My concern is primarily about treasury allocation and long-term sustainability. Cardano Foundation owns and manages the Cardano brand and remains one of the strongest-capitalized entities in the ecosystem. According to its 2025 financial report, the Foundation held approximately $361M in assets at the end of 2025, including roughly $280M in crypto assets and approximately $80M in fiat and traditional financial assets.

If the Foundation believes the Summit is strategically critical for Cardano, I believe it should be willing to finance a larger portion of the event from its own resources.

My second concern is that the Foundation previously communicated that the Summit should become increasingly sustainable over time.

The current proposal does not provide enough clarity on what that actually means. I still do not know whether future Summits will require treasury funding, how much funding may be requested in future years, or when the Summit is expected to become financially self-sustaining.

The proposal mentions that revenue from the 2026 Summit will help fund future events, but it does not clearly state that future treasury requests will stop. Given the large funding requirements from IO, Intersect, infrastructure teams, and builders across the ecosystem, I am not comfortable approving both major event proposals.

At the same time, I recognize that other DReps support the Summit and consider it strategically important. My current position is somewhere between NO and ABSTAIN.

That is why I decided to abstain rather than vote NO.

I decided to support the baseline TOKEN2049 Singapore 2026 proposal because it gives Cardano exposure beyond its own ecosystem. Unlike the Summit, which is naturally more focused on existing Cardano community members, TOKEN2049 puts Cardano in front of a much broader audience that includes investors, exchanges, market makers, media, founders, developers, enterprises, and builders from other ecosystems.

I believe Cardano still needs stronger external visibility, and this proposal addresses that more directly.

For approximately $792,900, the baseline proposal gives Cardano a large booth at the event, a dedicated builder stage, live product demonstrations, lead generation tools, networking access, ecosystem tickets, and post-event reporting requirements.

More importantly, it gives Cardano builders direct access to people who are not already part of the ecosystem. That is a much stronger value proposition than spending significantly more money to create a separate event in the same city just two days earlier.

I understand that EMURGO has faced criticism from parts of the community in the past. However, DReps should evaluate proposals based on current execution plans and expected outcomes. I appreciate that EMURGO recently addressed concerns related to DRep selection in Yoroi Wallet, and I am willing to give them a second chance.

I want to make a pragmatic decision.

In this case, EMURGO is leveraging an existing global event, which significantly reduces operational complexity. The proposal also includes concrete deliverables such as builder showcases, live demos, partnership targets, media exposure, and measurable post-event reporting. While some KPIs should always be viewed critically, I believe the overall direction is pragmatic and focused on external ecosystem growth.

I do not support the Top-Up proposal because I do not believe the additional $424,360 is justified. The extra spending mainly buys a larger booth, a keynote slot, lanyard branding, protein shake branding, and additional media exposure.

In my view, the baseline proposal already captures most of the meaningful value, and the upgrade feels like diminishing returns and unnecessary prestige spending.

This is ultimately a pragmatic treasury allocation decision. Cardano should not disappear from major crypto conversations, media, and broader crypto audiences. I believe supporting one meaningful external-facing marketing initiative is reasonable.

At the same time, treasury resources remain limited, and I do not believe it is responsible to fund multiple overlapping event proposals.

If one of these events is approved, I will likely be significantly more conservative when evaluating other marketing-related proposals.

I may still change my mind before voting closes. If it becomes clear that the EMURGO proposals have no realistic path to approval while the Foundation proposal does, I may reconsider my position and adjust my votes accordingly.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote NO for the proposal: Cardano Vision 2026: Human Centred, Scalable, Post Quantum Secure – IO Research

My rationale:

Cardano was built on scientific rigor, formal methods, and long-term research. That remains one of its greatest strengths and one of the reasons Cardano has survived while many other ecosystems prioritized speed over quality.

I strongly believe this research culture must be preserved. IO remains one of the most important technology organizations in the blockchain industry, and Cardano benefits from having world-class researchers working on difficult problems such as scalability, cryptography, and protocol design.

However, survival alone is not enough. Cardano is no longer in the top 10 by market capitalization, and the ecosystem continues to face challenges in adoption, liquidity, and user growth. That should force us to think more carefully about capital allocation. We must continue funding critical research, but we also need to recognize that part of the treasury must be directed toward adoption, growth, and ecosystem expansion if Cardano wants to become competitive again.

Respecting Cardano’s research culture does not mean approving every research budget request without strong prioritization, especially in the context of the current Intersect budget cycle, where 69 proposals are competing for limited treasury resources.

The biggest issue with this proposal is that it bundles too many independent research agendas into a single treasury withdrawal.

This proposal includes research across post-quantum cryptography, Leios optimization, sharding, zero-knowledge infrastructure, bridge security, atomic swaps, governance incentives, proof-of-personhood, decentralized identity, light clients, Babel fee markets, Proof-of-Useful-Work, and many other areas.

Some of these research areas are highly valuable and should likely be prioritized this year. I believe post-quantum research, Leios-related research, and potentially sharding research are strategically important for Cardano’s long-term competitiveness.

However, other areas feel less urgent and could be postponed to future budget cycles, including bridge research, atomic swaps, light client architecture, next-generation fee market design, and several others.

Bundling all of these topics together creates a governance problem. DReps may strongly support some research areas while disagreeing with others, yet they are forced into a single yes-or-no decision. This reduces treasury precision and makes proper prioritization far more difficult.

Some research areas also appear weakly connected to Cardano’s immediate needs.

For example, Proof-of-Useful-Work feels highly experimental and currently has unclear implementation pathways for Cardano. It may eventually become useful, but it does not feel urgent relative to more immediate scaling, adoption, and ecosystem priorities.

Similarly, Zero-Knowledge research is clearly valuable for Cardano, but it may also directly benefit Midnight. I would prefer clearer cost allocation where Midnight contributes to research that may materially support its own long-term business model. I would be far more comfortable if ZK-related research costs were shared rather than fully funded by the Cardano treasury.

The governance section is another concern.

IO previously received funding through the Beyond Minimum Viable Governance initiative. Before approving another round of governance research, I would like clearer visibility into what was achieved, what was implemented, and what measurable improvements resulted from that funding.

The concentration of voting power is already a real issue today. We need practical solutions in the near term, not only additional long-term governance research. If more research is required, there should also be a clear roadmap for temporary improvements while longer-term solutions are being developed.

There are already several independent governance improvement initiatives emerging across the community. Many DReps are actively discussing concentration risks, participation incentives, delegation models, budget reforms, and operational improvements. IO should actively collaborate with these community members and incorporate their real-world governance experience rather than conducting research in isolation. Governance cannot be improved through academic modelling alone. A single annual questionnaire or limited consultation is not sufficient input for designing governance systems that affect the entire ecosystem. More direct collaboration with active DReps and governance participants is necessary.

Treasury prioritization is also a major factor in my decision.

Teams are currently requesting approximately ₳700M in total funding. This proposal alone asks for nearly 10% of the Net Change Limit.

I already supported IO’s maintenance proposal for ₳62,134,630 because maintaining the core network is essential.

At this point, I am no longer comfortable approving another large bundled proposal that combines multiple research agendas under a single budget request.

The ecosystem urgently needs funding for adoption, growth, and independent teams building on Cardano. Treasury resources should not become overly concentrated within a single organization.

The Net Change Limit is set at ₳350M. I struggle to approve nearly ₳200M to IO across multiple proposals without significantly stronger prioritization. That may help ensure IO’s stability, but the broader ecosystem could suffer from underinvestment.

DReps need to make difficult choices and focus on what Cardano absolutely needs over the next year.

For these reasons, I voted NO. I would prefer to see this proposal unbundled and resubmitted as separate research proposals. If Midnight materially benefits from some of this research, the Midnight Treasury should also participate in funding it.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote NO on the proposal: Pogun: Capital Without Compromise

A PDF version of this rationale is also made available.

My rationale:

The idea itself is strategically attractive. Bitcoin liquidity is enormous, and Cardano would clearly benefit if BTC holders could bridge assets into the ecosystem, borrow against them, earn yield, and increase DeFi activity on Cardano. The non-margin lending model is also genuinely interesting because it avoids oracle-driven liquidations, which remain a major weakness in many traditional DeFi lending protocols.

However, my primary concern is structural.

This proposal is not core infrastructure in the same category as protocol scaling, node maintenance, or Plutus improvements. It is primarily a commercial DeFi venture. If successful, it may benefit Cardano, but it would also create a private business with its own revenue streams, market share, and strategic upside. That distinction matters when treasury funds are involved.

The proposal combines:

1. Bitcoin bridge infrastructure — potentially public infrastructure that could benefit the broader ecosystem
2. A credit market — a revenue-generating DeFi application
3. A yield/private credit/RWA layer — an even more commercial and potentially regulated business model

These components have very different risk profiles and should not be bundled into a single treasury proposal.

The bridge layer could reasonably be considered ecosystem infrastructure because other Cardano applications may benefit from it. The lending and yield layers are clearly monetized products that generate fees through origination fees, servicing fees, bridge fees, and performance fees. This is funding the development of a future revenue-generating business.

The proposed treasury return model also raises concerns. The proposal offers 20% of EBITDA until the treasury is repaid and 5% of EBITDA in perpetuity afterward. At first glance, this sounds attractive. However, EBITDA is highly flexible and can be materially affected by operational expenses, expansion costs, infrastructure spending, legal costs, and other business decisions. This does not imply bad intent, but it does mean treasury returns are far less predictable than they may initially appear.

If IO wants treasury funding for commercial ventures, the structure should look much closer to an actual investment. That could mean a loan structure, revenue-share agreements with stronger protections, equity-like rights, or significantly more favorable repayment terms for the treasury. Public funds should not absorb early-stage business risk without receiving adequate protections or upside participation.

The proposal also does not clearly disclose several important issues that should be addressed when public treasury funds are used to support a commercial venture. It remains unclear whether there are future token issuance plans, whether private investors may enter later, what the ownership structure looks like, whether founders or advisors receive equity upside, and whether the treasury would have any stronger protections in the event of restructuring, acquisition, or future fundraising rounds.

There is also a broader ecosystem concern. Pogun is not entering an empty market. Other Cardano teams are already building adjacent infrastructure. Sundial is developing Bitcoin-related infrastructure and recently received recognition at Paris Blockchain Week, while FluidTokens has already demonstrated native Bitcoin–Cardano atomic swaps on mainnet. Treasury funding should be careful not to unintentionally pick winners in competitive markets where multiple ecosystem teams are already innovating.

Execution risk is also very high. The proposal attempts to simultaneously deliver a new lending model, a yield platform, a Bitcoin bridge, BitVM infrastructure, operator architecture, institutional onboarding, and products that may face meaningful regulatory scrutiny due to private credit and RWA exposure. The bridge architecture involving BitVM, BABE witness encryption, Mithril state attestation, Groth16 proofs, and 1-of-N operator assumptions is technically ambitious and promising, but it is also highly complex. A Q4 2026 mainnet target feels aggressive.

I believe Pogun is an interesting idea with potential long-term value for Cardano. However, I do not believe the Treasury should fund the full commercial stack in its current form.

A stronger proposal would separate:

1. Open-source Bitcoin interoperability infrastructure
2. Public credit primitives
3. The commercial frontend/business model

I would be far more open to supporting the public infrastructure components separately.

For now, I believe this proposal is better suited for private capital, strategic partnerships, or a much smaller pilot before requesting treasury funding at this scale.

For these reasons, I voted NO.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote YES for the proposal: IO: Cardano High Assurance Technical Collaboration

My rationale:

I support this proposal because it strengthens one of Cardano's most important long-term differentiators: security and formal correctness.

Many blockchain ecosystems prioritize speed of development but often pay the price later through exploits, protocol failures, and loss of user trust. The industry has repeatedly seen hacks worth hundreds of millions of dollars across bridges, lending protocols, exchanges, and DeFi applications. Audits alone are often insufficient because they review code but do not mathematically prove correctness.

This proposal pushes Cardano further towards a model where security becomes a real competitive advantage rather than just a marketing narrative.

The first workstream expands Blaster, IO's automated formal verification tool. Blaster has already been used to verify individual smart contracts used in production applications such as Djed and USDCx, but full DApp-level verification currently requires significant manual effort.

This proposal aims to automate verification across multi-contract systems and multi-transaction flows, which is significantly more valuable because many major exploits occur at the protocol level through flawed interactions between contracts, state transitions, and external assumptions rather than within a single script alone.

The proposal also introduces a Common Vulnerability Library, which could make formal verification more accessible by giving developers reusable templates for common attack vectors and security checks. This could significantly improve baseline security standards for smaller teams that cannot afford repeated audits or large internal security teams. It should not be viewed as a replacement for audits, but it can help teams identify vulnerabilities earlier and reduce reliance on costly manual reviews.

Another valuable component is the equivalence checking tool, which allows developers to optimize UPLC code while mathematically proving that functionality remains unchanged. This can improve efficiency without introducing unnecessary security risks.

The proposal also expands support across multiple smart contract languages, including Aiken, Scalus, Pebble, and Futura, which is important for ecosystem decentralization. Cardano should not become dependent on a single development stack.

The second workstream focuses on a Container-Based Developer Environment (CBDE) that simplifies onboarding by packaging the full high-assurance tooling stack into a much easier setup process. This addresses a real pain point for developers.

This proposal is also complementary to IO & VacuumLabs: Enhancing Plutus – Performance, Correctness, and Usability, which focuses more on protocol-layer improvements such as Plutus capabilities, formal specifications, and core tooling.

I also appreciate that this proposal includes collaboration with multiple ecosystem teams rather than concentrating all work inside IO. The involvement of TxPipe, Midgard Labs, Harmonic Labs, Lantr, SAIB, and No.Witness Labs is a positive signal and helps distribute technical expertise across the ecosystem.

That said, the proposal still lacks sufficient financial transparency. It explains technical deliverables well, but it does not show how much funding goes to each participating team. If ecosystem collaboration is presented as a major strength, DReps should be able to see how funds are distributed across organizations, how many engineers are involved, and what each team is being compensated for. This is particularly important when some ecosystem teams may also pursue separate funding through other channels.

Finally, some of the proposal's adoption projections appear overly optimistic. Better tooling can improve developer experience, but developer growth also depends on broader ecosystem demand, liquidity, users, and real business opportunities.

Despite these concerns, this proposal strengthens Cardano's long-term security model and reinforces an area where Cardano can genuinely differentiate itself from competing ecosystems. For these reasons, I support it.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I decided to vote YES on the proposal: IO & VacuumLabs: Enhancing Plutus – Performance, Correctness, and Usability

My rationale:

I support this proposal because it addresses real technical bottlenecks in Cardano's smart contract stack: execution costs, tooling friction, and formal correctness. These are fundamental issues that directly impact developer adoption, DeFi competitiveness, and long-term support for alternative node implementations.

The most tangible part of this proposal is reducing Plutus execution costs.

CIP-0156 (multiIndexArray) and CIP-0168 (BuiltinValue functions) introduce new built-ins that can reduce script complexity and lower execution costs for many common use cases.

This matters because Cardano smart contracts are frequently criticized for high execution costs, transaction constraints, inefficient handling of multi-assets, and unnecessary complexity for common DeFi operations.

These inefficiencies directly affect DEXs, lending protocols, stablecoins, and other on-chain applications that need to operate efficiently at scale.

Formal correctness and alternative node support may be even more important over the long term.

Without implementation-independent specifications, conformance testing, and stronger formal guarantees, alternative clients become significantly riskier to develop and maintain. Cardano cannot realistically pursue node diversity while lacking the tooling and specifications required to support multiple implementations safely.

At the same time, Cardano has marketed formal methods as a major differentiator for years. This proposal suggests that some important parts of Plutus formalization still require further maturation. The IO should clearly explain what formal specifications already exist, what gaps remain, and why those gaps were not addressed earlier.

This proposal must be considered in a broader context.

The blockchain industry has repeatedly demonstrated how expensive weak smart contract tooling and insufficient verification can become. Major exploits across EVM ecosystems have resulted in billions of dollars in losses due to contract vulnerabilities, implementation mistakes, and weak security assumptions.

While no system can eliminate risk, Cardano has consistently positioned itself as a platform built on higher assurance standards. Strengthening formal specifications, conformance testing, and smart contract correctness helps preserve that competitive advantage as the ecosystem grows and more value moves on-chain.

However, this proposal is not perfect.

I continue to see unnecessary fragmentation across IO proposals. Related work is often split across multiple proposals, while vague budget categories such as "Engagement & Ecosystem Support" continue to appear without sufficient breakdown. Future proposals should provide clearer boundaries between maintenance, developer tooling, and protocol upgrades.

Despite these concerns, this proposal addresses important infrastructure gaps, improves Cardano's long-term competitiveness, and the requested budget is relatively reasonable compared with other IO requests.

For these reasons, I support it.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I have decided to vote NO on the proposal: IO: Developer Experience Initiative.

My rationale:

I have already approved the significantly larger proposal IO & Ensureable Systems: Cardano Maintenance Initiative, which includes a broad scope and substantial budget. In my view, that proposal should already cover a meaningful portion of the activities described here.

As a result, I am concerned about potential overlap between initiatives.

One example is the “Engagement & Ecosystem support” category, which appears in multiple IO proposals without a clear definition or breakdown. It is not sufficiently explained what specific activities are funded under this category, who is responsible for them, and how they differ across proposals.

This lack of clarity raises concerns about duplication of effort and inefficient allocation of Treasury funds.

While I agree that improving developer experience is important, I do not fully agree with the premise that fragmented tooling and scattered documentation are currently the primary bottlenecks to building on Cardano.

Modern development workflows increasingly rely on AI-assisted tools and aggregated knowledge sources, significantly reducing friction when navigating documentation.

However, this does not diminish the importance of having accurate, complete, and up-to-date documentation.

Cardano already has an official developer portal maintained by the Cardano Foundation: https://developers.cardano.org/

It is important to maintain a single, well-maintained source of truth rather than introducing additional parallel documentation efforts that risk fragmentation and eventual obsolescence.

Documentation should be treated as a standard responsibility of product delivery, not as a separate, recurring funding request. When new tools or protocols are released, high-quality documentation should be included as part of that work.

Additionally, many of the proposed activities, such as improving tooling, maintaining libraries, running hackathons, and supporting developers, can and should increasingly be handled by the community and independent teams, rather than being centralized within IO.

As Cardano matures, it is important to gradually reduce dependency on founding entities and enable a more decentralized ecosystem of contributors. Foundational entities should support and collaborate with the community, not dominate all areas of ecosystem development.

There are also concerns regarding coordination across proposals. For example, Intersect has requested a significant budget (₳25.4M) that includes elements related to Pentad integrations. When multiple entities request funding for related or overlapping initiatives, it becomes difficult for DReps to assess scope, ownership, and efficiency. A more coordinated approach, potentially through joint proposals, would improve clarity and accountability.

Overall, while this proposal addresses a relevant area, it introduces additional spending in areas that are already partially covered elsewhere or could be more effectively handled by the broader ecosystem.

Given the limited Treasury budget, it is important to prioritize carefully. Over-allocating funds to centralized initiatives risks ensuring the sustainability of a single entity, rather than fostering the long-term growth and diversity of the ecosystem.

In my view, a better approach would be to:

• strengthen coordination between existing initiatives
• ensure documentation is delivered as part of core development work
• empower community-led efforts through targeted funding mechanisms
• and maintain a balanced allocation of resources across infrastructure, ecosystem growth, and decentralization

For these reasons, I am voting NO on this proposal.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I have decided to vote YES on the proposal: IO & Ensureable Systems: Cardano Maintenance Initiative.

My rationale:

This is one of the most important proposals in the current cycle, but also one of the most difficult to evaluate, as it sits in a gray zone. Maintenance is unquestionably necessary for the network to function, yet it is inherently harder to measure, benchmark, and justify with precision compared to feature-driven work.

I want to clearly state that the proposal, in its current form, lacks sufficient transparency relative to its size. The overall budget is high, and while the scope is broad, the level of detail provided does not allow DReps to assess cost efficiency properly. A more granular breakdown is needed, including clearer information on team size, FTE allocation, salary assumptions, and cost distribution across specific components and activities.

Ethereum provides a useful benchmark for funding core protocol maintenance. More than $100M has been distributed over multiple years, roughly three to four, to support base-layer development across multiple independent client teams, including execution clients such as Geth, Reth, Nethermind, Besu, and Erigon, and consensus clients such as Prysm, Lighthouse, Lodestar, Nimbus, and Teku, along with supporting research, testing, and infrastructure work.

This implies an approximate annualized funding level of $25M to $35M for the entire multi-client ecosystem, not for a single team.

Through initiatives like Protocol Guild, funding is distributed across roughly 190 contributors and around 30 teams. Total compensation for experienced Ethereum engineers typically falls in the range of $100k to $180k annually.

By contrast, IO is requesting approximately ₳62.1M, or about $15M, for nine months of maintenance for a single primary implementation, which annualizes to nearly $20M.

This does not include additional IO proposals for consensus upgrades, protocol improvements, and other initiatives.

For additional context, alternative node teams are operating at significantly lower budgets. The Amaru team requested approximately $3.04M, and the Dingo team approximately $2.07M.

While IO's scope is broader, the difference in scale highlights the need to continuously push towards cost efficiency, especially in a future where multiple node implementations will require ongoing funding.

Maintenance is clearly essential, but this proposal concentrates a very large budget within a single entity. Compared to Ethereum's multi-client ecosystem, which is supported through distributed funding across many independent teams, this level of funding for one dominant implementation requires significantly greater transparency and justification.

The proposal does not provide a breakdown that would allow DReps to determine how much of the requested budget is allocated specifically to maintaining the Haskell node versus other components. Costs are aggregated across broad categories, making it difficult to assess efficiency at the component, team, or deliverable level.

Similarly, while the funding distribution table provides a high-level overview, categories such as "Governance" and "Engagement & Ecosystem support" are not sufficiently defined. Without a clearer scope, deliverables, and resource allocation, it is difficult to evaluate whether these costs are justified or optimally structured.

Despite these concerns, I am voting in favor of this proposal because maintenance is not optional. It is a fundamental requirement for the stability, security, and continuity of the network. Without it, all other investments in the ecosystem would be at risk.

I am fully aware of the reputational risk if the IO does not receive key funding.

However, this approval should not be interpreted as acceptance of the current level of transparency or cost structure. Going forward, I strongly encourage IO to move towards a more detailed and modular budgeting approach. This could include separating core areas such as node maintenance, infrastructure, and ecosystem support into distinct proposals, each with clearly defined scope, FTEs, and cost assumptions.

If Cardano is moving towards a multi-node environment, as is clearly the case with Amaru, Dingo, and other implementations, then the cost structure across nodes must become more comparable and transparent. It is difficult to justify a situation where one implementation is maintained at a significantly higher cost without a clear, data-driven justification.

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

MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

As a DRep, I have decided to vote YES on the proposal: IO: Consensus Initiative.

My rationale:

This is a must-have proposal for Cardano.

It directly addresses a fundamental limitation of the network, namely throughput at the consensus layer. Without a meaningful increase in L1 capacity, Cardano cannot realistically meet its 2030 ambitions or compete in high-throughput use cases.

Ouroboros Leos represents a critical step in this direction. By extending Praos with Endorser Blocks and committee-based validation, it aims to deliver an order-of-magnitude increase in throughput while preserving decentralization and security.

I want to be clear about prioritization.

In previous votes, I rejected proposals related to L2 scaling. These solutions may become important over time, but they are not substitutes for a strong and scalable base layer.

Cardano must first ensure that its L1 is capable of supporting meaningful economic activity at scale. For this reason, I consider L1 scaling through Leios to be a higher priority than current L2 initiatives.

At the same time, I do recognize the value of L2 solutions for specific use cases. They are a natural extension of the base layer. However, given the current budget constraints, the scale of funding requested by IO, and broader industry trends such as Ethereum's evolving stance on rollup-centric scaling, I believe L2 initiatives can be deferred in favor of strengthening L1 first.

This proposal focuses on progressing Leios from testnet to a mainnet-ready release candidate. It includes substantial engineering work on consensus integration, conformance testing against formal specifications, large-scale validation and adversarial testing, and preparation for hard-fork enabling.

While the proposal does not guarantee mainnet activation, it delivers the necessary conditions to make it possible. Given the complexity and risk of consensus-layer upgrades, this is a reasonable and expected approach.

I would also welcome clearer communication from IO regarding the longer-term scalability roadmap beyond the current Leios implementation. In particular, it would be important to clarify whether a more advanced version, often referred to as Full Parallel Leios, is realistically achievable and on what timeline.

Competing blockchain platforms are already targeting even higher levels of throughput and performance. Cardano may ultimately require additional scalability improvements beyond this iteration to remain competitive. Greater transparency in this direction would help DReps better assess the long-term value of this investment.

It is also important to acknowledge that protocol-level upgrades, such as Leios, create ecosystem-wide obligations. Alternative node implementations, such as Amaru, Dingo, and others, will need to adopt and maintain compatibility with these changes. This introduces additional downstream costs that should be considered as part of the broader funding strategy.

Leios is essential infrastructure for Cardano's future. It enables the network to scale, supports long-term sustainability through increased transaction capacity, and strengthens its competitiveness across key use cases. While the proposal would benefit from improved transparency and clearer cost justification, it addresses a critical need that cannot be deferred. For this reason, I support it.

As a DRep, I have decided to vote YES on the proposal: IO: Cardano Upgrades.

My rationale:

This is a strategically important proposal. Although it is a bundled proposal, the work streams are naturally connected around economic UX and treasury mechanics. In this case, I consider bundling acceptable.

The three core components are meaningful:

1. CIP-159 / Account Address Enhancement: This represents fundamental protocol infrastructure. Enabling micro-fees, reducing batching costs, improving L2 reserve management, and supporting future multi-asset account logic would bring tangible benefits to the ecosystem.

2. Multi-Asset Treasury Design: This is strategically valuable from a governance and financial perspective. A treasury held solely in ADA is exposed to volatility, and enabling support for stablecoins or other native assets could strengthen long-term resilience. The proposal focuses on delivering a CIP, which is an appropriate first step. At the same time, given the sensitivity of this topic, broader alignment with the community and DReps would be beneficial.

3. Babel Fees: This is likely the most adoption-focused component. Requiring users to acquire ADA before interacting with the network introduces real friction. Fee abstraction is a meaningful UX improvement. However, the current deliverable is limited to a single provider. While this may be acceptable as an initial step, it should be clearly understood as a centralized prototype rather than a fully decentralized infrastructure. The proposal states that the architecture will be designed for future extensibility towards a permissionless model.

I find the budget section of this proposal insufficiently detailed for a treasury withdrawal of this size.

While high-level categories are provided, there is no clear information on the number of engineers involved, salary assumptions, or time allocation across work streams. This level of detail is commonly expected even from smaller treasury proposals, where teams often provide transparent breakdowns to justify their funding.

For example, the proposal by Blink Labs for the Dingo clearly outlines team size, cost per FTE, duration, and contingency assumptions. This allows DReps to properly assess cost efficiency and realism.

Governance standards should be applied consistently across all entities, regardless of size or submitter. It is therefore reasonable to expect the same level of transparency and rigor from IO as from smaller teams. Without this level of granularity, it is difficult to fully assess whether the requested funds are justified and responsibly allocated.

At the same time, I recognize the broader context in which these proposals are submitted.

I am prepared to support selected proposals from IO, even where certain aspects are not fully specified or could be improved. While I strongly encourage higher standards of transparency and more granular budget breakdowns in future submissions, I also acknowledge the importance of ensuring that core contributors to the ecosystem remain operational and capable of delivering critical infrastructure.

It is also important to recognize the evolving cost structure of the ecosystem. Cardano is moving towards supporting multiple independent node implementations, which will require recurring funding similar to what has been provided to IO.

If we want to preserve the ability to fund other critical areas, such as community builders, DeFi development, governance, liquidity, and marketing, we must remain disciplined and responsible in how Treasury funds are allocated.

My view is that a significant portion of the Net Change Limit (around 50% or potentially less over time) should be sufficient to support the development and maintenance of all node implementations in the ecosystem, not just those led by IO.

To summarize, all three components of this proposal address real limitations in the current Cardano ecosystem and have the potential to deliver meaningful improvements. CIP-159 strengthens the protocol by enabling more flexible and efficient account mechanics, which can lower costs and improve infrastructure for developers and L2 solutions. Multi-asset treasury design enhances financial resilience and governance by reducing dependence on ADA volatility and enabling more sophisticated funding models. Babel Fees directly improves user experience by removing a key onboarding barrier, allowing users to interact with the network without first acquiring ADA.

Together, these features contribute to a more accessible and economically robust ecosystem. While the proposal could benefit from greater transparency in its budget and delivery structure, the overall direction is aligned with Cardano’s long-term growth and competitiveness.

As a DRep, I have decided to vote NO on the proposal: IO & Midgard Labs: L2 Scalability Initiative

This was not an easy decision. However, DReps recently rejected a bundled proposal for Cardano Summit and TOKEN2049 submitted by Cardano Foundation and EMURGO. If governance decisions are to remain consistent and credible, the same standards must apply to proposals submitted by Input Output (IO).

This proposal combines several distinct components into a single funding request:

1. L2-agnostic data availability (DA) research and prototyping, intended as shared infrastructure for future L2s.

2. Hydra production hardening, including performance optimization, tooling, reference DeFi implementations, and ecosystem support.

3. Midgard rollup development, including its path toward mainnet and multi-operator coordination.

These components differ significantly in scope, maturity, and risk profile. They range from early-stage research (DA), to ongoing infrastructure development (Hydra), to previously funded but not fully delivered work (Midgard).

Bundling of components reduces transparency and weakens accountability, particularly where prior milestones remain incomplete.

Midgard previously received ₳2,162,096 in 2025 through a treasury withdrawal, as well as funding of ₳500,000 through Catalyst. At this stage, key milestones have not yet been delivered.

While complex infrastructure development can take time, further funding should be contingent on clear evidence of progress and fulfillment of prior commitments.

The proposal also includes developer relations, ecosystem coordination, and engagement activities, with ₳625,552 allocated to “Engagement & Ecosystem support.” While these functions are important, they are not clearly defined in terms of deliverables or measurable outcomes.

I believe such activities are better suited to independent, community-led initiatives, which are already emerging within the ecosystem and can often deliver these functions more efficiently and in a more decentralized manner.

Additionally, the proposal references “contributions from Input Output and Midgard Labs” without providing a clear breakdown of responsibilities, resource allocation, or accountability between the entities. This lack of clarity further complicates evaluation and raises concerns about governance oversight.

Finally, the proposal presents ambitious performance and adoption outcomes, such as high throughput, low fees, and mainnet readiness, while the defined deliverables are primarily focused on research, prototyping, and incremental improvements. This creates a gap between stated outcomes and funded activities, making it difficult to assess whether the requested funding will result in measurable, production-ready infrastructure within the proposed timeframe.

To be clear, all three components addressed in this proposal are important for Cardano’s future. Hydra, Midgard, and a DA layer are all critical parts of the ecosystem’s scalability roadmap.

I would be willing to consider a bundled proposal provided the scope, delivery expectations, and accountability are balanced and clearly defined across all parts. However, in this case, the proposal is too asymmetrical in its composition, combining early-stage research, ongoing infrastructure development, and previously funded but incomplete work, without sufficient clarity on prior delivery.

I remain open to reviewing future proposals that address these components separately and with stronger guarantees of delivery.

As a DRep, I decided to vote NO on the proposal: Blockfrost: Maintenance and Next Generation Indexing

Blockfrost has received multiple funding rounds from Catalyst in the past. Last year, $1,300,000 from the Treasury. That is enough support for a private company under the IO umbrella to become a sustainable business.

While Blockfrost provides a free tier, it operates a freemium model where production usage is monetized. Without disclosure of revenue, cost recovery, and sustainability metrics, it is not possible to determine whether this subsidy is necessary or whether it risks funding a commercially viable business.

While Blockfrost is clearly an important provider, no independent data has been provided to justify subsidizing its operational costs over other competing services.

Blockfrost is one of several capable API providers in the ecosystem, alongside Maestro and Cardanoscan, while decentralized alternatives such as Koios further reduce reliance on any single service. This suggests that the ecosystem does not depend on Blockfrost in a way that would justify exclusive treasury support.

If we pick winners by subsidizing their business, others must also seek funding from the Treasury, or we support centralization by ensuring Blockfrost dominance. The winner should emerge from healthy competition, not through governance decisions.

To be clear, access to blockchain data is essential, but this does not require subsidizing a specific private API provider.

The ecosystem would benefit more from investment in open, decentralized, or protocol-level data access solutions that reduce reliance on any single service.

Allocating treasury funds to an IOG-aligned service risks reinforcing centralization at the infrastructure layer, especially in a market where multiple alternative providers exist.

Additionally, this proposal bundles two distinct components: the development of new infrastructure (Project Cayley) and an operational subsidy for Blockfrost's existing services. Combining them into a single vote prevents proper evaluation of each on its own merits and forces an all-or-nothing decision.

As a DRep, I decided to vote NO for the proposal: Cardano Summit 2026 and TOKEN2049 Singapore

A PDF version of this rationale is also made available.

My rationale:

Cardano needs better marketing. Flagship events are important. The community should not condemn this idea for petty reasons. Seen pragmatically, Cardano must not disappear from the radar of the media, business, and governments.

Given the current low price of ADA, I am afraid that we cannot fund two large events from the Treasury this year. Organizing two back-to-back events is a good idea. However, I am leaning towards the possibility of funding only one event.

I propose to skip the Cardano Summit and focus only on TOKEN2049. Please split this proposal into two separate ones. I would probably support funding for participation in TOKEN2049 if the main organizer were the Cardano Foundation (CF).

According to the Cardano Foundation's "path to sustainability" plan, the expected budget for the Summit in 2026 should be only $1.2M. Asking for $2.5 requires an explanation for the deviation from the plan.

Community members complained that tickets were noticeably more expensive than in previous years for Summit 2025. Many fans were unable to attend the event because the total cost, including airfare and accommodation, was too high.

The proposal should be more detailed. It should mention what the ticket price will be, how many sponsors are expected, and what the expected revenue is.

Focusing on governance at Cardano Summit 2026 is not a good idea given the current problems with the centralization of voting power. It makes sense to discuss this among DReps, but maybe Google Meet is enough for that. Let's present governance to the world only when we ourselves are proud of it.

If CF submits a new proposal for Summit, I recommend considering a change of topic.

I would rather use 10M ADA to address governance issues than to fund the Summit at this time.

I also recommend reducing costs or looking for other sources. The Cardano Summit will not be the only marketing-related proposal this year. I have heard of at least 3 other proposals that may require a similar amount.

I appreciate the Cardano Foundation for everything it does for the community and the protocol. They have proven many times in the past that they are capable of organizing the Summit.

With regard to the Treasury, it is necessary that this flagship event is sustainable. Alternatively, the costs respect the current price of ADA. We all have skin in the game. If we want to do spectacular events, we must first think about how to get Cardano back into the top 10.

As a DRep I decided to vote YES for the proposal: Pebble + Gerolamo - HLabs 2026 Budget

The proposal concerns the tooling, Gerolamo node and programming language for smart contracts named Pebble.

Gerolamo is a lightweight node that is designed with the goal of running in the browser and one day potentially also on mobile devices. This would allow developers to build light wallets that move towards more trust-minimized, on-chain security models.

Applications using a Gerolamo node could benefit from higher responsiveness and improved reliability, as they may become more independent of data from external servers.

If full ledger validation is implemented, such applications could theoretically reach a security level comparable to running a full node like Daedalus, allowing users to move closer to full sovereignty over their funds.

Although most users are probably not explicitly looking for maximum sovereignty, they can still benefit from improved responsiveness and reduced reliance on centralized infrastructure.

Gerolamo is primarily positioned as an alternative relay and data node implementation, contributing to client diversity and reducing reliance on a single codebase at the networking layer. It is not currently intended for block production, although future extensions could expand its capabilities.

The alternative programming language Pebble is a strong argument in support of the proposal.

Haskell (Plutus) and Aiken are primarily functional programming languages, while Pebble is designed to be more imperative and low-level in style, closer to paradigms commonly used in Web2 development.

Pebble code is compiled into Untyped Plutus Core, ensuring compatibility with the existing execution model.

Aiken is currently one of the most widely used programming languages in the ecosystem. However, it can still be relatively complex for developers who only have experience with imperative languages.

Building alternative programming languages is desirable for the ecosystem, as it can broaden developer participation and diversify the tooling landscape.

The tooling maintained by HLabs is another strong reason to support the proposal.

TypeScript libraries such as cardano-ledger-ts, ouroboros-miniprotocols-ts, and uplc form part of the foundational infrastructure used by a range of Cardano developer tools and applications, often as transitive dependencies.

While not always visible at the application layer, these libraries underpin SDKs, off-chain code, and experimentation in the TypeScript ecosystem.

Continued support for this tooling helps maintain continuity for developers and reduces the operational burden of adapting to protocol changes.

The proposal is also aligned with the Cardano Vision 2030, particularly in terms of its focus on measurable outcomes and ecosystem KPIs.

By supporting core infrastructure, developer tooling, and alternative implementations, it contributes to key metrics such as developer growth, network resilience, and client diversity. These are critical indicators of long-term ecosystem health and decentralization.

I would appreciate it if the proposal were split into three separate proposals, corresponding to the main work streams (Pebble, Gerolamo, and tooling). This would allow for more granular evaluation and clearer accountability for each component.

That said, I do not consider this a reason to reject the proposal. I understand that the team intends to continue working across all three areas in parallel, and bundling them may reflect practical considerations around coordination and delivery.

As a DRep, I decided to vote NO on the proposal: Cardano x Draper Dragon: Orion Fund

Cardano needs experts for efficient treasury spending, increased on-chain activity, and to become more attractive to VC investors. This proposal has the potential to achieve all that. It is not an absolute NO, but feedback for improving the proposal.

My rationale:

What to improve in the proposal:

The Cardano Vision document makes a fundamental pivot. From “we build technology” to “we must deliver measurable results”.

A proposal of this scale should explicitly commit to the KPIs defined in the Vision 2030. In its current form, the proposal defines its KPIs in a vague and qualitative manner, without clear numerical targets, baselines, or success thresholds, which makes objective evaluation and accountability difficult. Furthermore, if we expect smaller projects requesting significantly lower funding to adhere to clearly defined KPIs and measurable outcomes, it is essential that proposals of this scale set the standard by doing so themselves.

Future tranches should be explicitly conditioned on clearly defined and measurable milestones, aligned with both financial performance and ecosystem impact. These milestones should include specific targets, transparent reporting requirements, and independently verifiable data, allowing the community to objectively assess progress. The conditions under which additional capital is released should be defined up front.

The role of the Cardano Foundation (CF) within this structure should be more clearly defined, as its current description as an "administrator" lacks sufficient detail regarding its responsibilities, authority, and limitations. In particular, the relationship between the CF and Arouet Holdings should be explicitly clarified to avoid ambiguity around control, decision-making, and accountability.

To strengthen governance and transparency, it would be beneficial to introduce a clearer separation of roles and to consider incorporating a DRep committee as an additional oversight layer. Such a committee could provide community-aligned review and accountability, potentially in a role analogous to CF. This would improve checks and balances while maintaining proper legal and governance boundaries.

The proposal presents ambitious return targets, such as a 3x gross multiple and 25%+ IRR, which are meaningful on a strategic level. However, for an allocation of this magnitude, it would be appropriate to support these targets with clear evidence of past performance. In particular, the proposal would benefit from including historical fund results, track record data, and relevant benchmarks demonstrating the manager's ability to achieve comparable outcomes. Without such context, it remains difficult to assess the credibility of the stated targets.

It would be reasonable to expect a clear and consolidated presentation of the fund's economic structure, including management fees, performance fees, and the overall distribution waterfall. While some elements may be mentioned, they are not presented in a sufficiently transparent and structured way to allow for proper evaluation. This makes it difficult to assess how much capital will be deployed into the ecosystem versus consumed by operational costs, and what portion of returns would ultimately accrue to the treasury.

The proposal lacks clearly defined downside protection mechanisms for the treasury in the event of underperformance. In particular, it is not specified whether management fees are adjusted in case of poor performance, whether any form of clawback or capital preservation mechanism exists, or whether there are conditions under which the fund can be paused or discontinued.

The proposal would benefit from independent oversight or audit mechanisms to ensure transparency and accountability. In addition to third-party or professional oversight, it may be valuable to consider the inclusion of a DRep committee as part of the governance structure. This would help strengthen the connection between on-chain governance and the off-chain investment structure.

While the use of a venture capital partner can bring potential benefits such as access to deal flow, investment expertise, and external networks, the proposal does not sufficiently demonstrate why this approach is superior to alternative capital allocation mechanisms.

It remains unclear what unique value Draper Dragon provides that could not be developed within the Cardano ecosystem itself, whether through improved grant systems, internal investment structures, or community-led allocation processes.

I recognize that a VC partner may be able to execute certain activities faster and more efficiently than DReps operating through on-chain governance. However, this raises a broader strategic question of whether the goal should be to outsource these functions, or rather to improve and mature our own governance capabilities over time.

Before committing to this approach, it would be prudent to more clearly define how much capital should be allocated through external managers such as Draper Dragon versus how much should remain under direct on-chain governance. Without clearly explaining why this approach is better and what concrete value Draper Dragon brings, the proposal asks the community to trust external parties without providing sufficient evidence that this is the most effective way to allocate treasury funds.

In conclusion, I view this proposal as directionally promising and aligned with Cardano’s long-term ambition to grow its ecosystem and improve capital efficiency. However, given the scale of the requested allocation, the current level of detail, clarity, and accountability is not yet sufficient to justify approval.

My vote should be understood as a request for refinement rather than rejection. I would be open to supporting a revised version of this proposal that addresses the points outlined above, particularly in the areas of KPI definition, governance structure, transparency of fund economics, and evidence of track record and added value. With these improvements, this initiative could become a strong and valuable component of Cardano’s treasury strategy.

As a DRep, I decided to vote NO on the proposal: Cardano Defi Liquidity Budget - Withdrawal 1

My rationale:

I appreciate the intention behind this proposal. However, in its current form, I am not able to support it. The reasons are similar to those for rejecting the previous proposal:

gov_action1fvgw27fjpr9c7g582mszzyez0jgkqgjgatzdnyngrg8wwc9kcn3qqxtz8r7

In my opinion, the Cardano Treasury should serve as a source of liquidity for the ecosystem. The direction is right.

I still believe that establishing a legal entity in the Cayman Islands is unnecessarily costly. In my opinion, there are cheaper alternatives. The team wants to push this option. They are actively trying to explain it. Even if I accepted it, the costs of directors and supervisors seem high to me.

My primary concern relates to the proportionality between the proposed costs and the expected scope of responsibilities.

The proposal does not clearly define the exact role, responsibilities, or time commitment of the directors. In my understanding, the DAO is responsible for making decisions related to stablecoins and allocation, while the legal entity and its directors would act primarily as the formal structure executing those decisions, especially regarding off-chain interactions.

If this interpretation is correct, the directors would not be independently managing a complex investment strategy, but rather acting as a governance and legal execution layer on top of decisions made elsewhere. In that case, their role appears primarily supervisory and operational from a legal standpoint, rather than involving active portfolio management or continuous strategic decision-making.

The financial operations associated with minting stablecoins and allocation to DeFi are relatively straightforward.

In such a setup, a director's compensation of around $50,000 per year seems difficult to justify. This level of compensation is more typical for hedge fund structures, where directors oversee complex investment strategies, active trading, and significant regulatory exposure. Here, the structure appears simpler and more delegated. Based on comparable roles, a more appropriate compensation range would likely be in the range of $10,000 to $25,000 per director. If the intention is for directors to take on a more active or strategic role, this should be clearly specified and justified, including the expected scope of decision-making, liability, and time commitment.

Another important issue is the lack of transparency regarding the directors themselves. The proposal does not disclose their names, which makes it impossible to properly assess their competence, experience, or suitability for the role. This is particularly relevant given that there are no strict legal requirements in the Cayman Islands regarding formal education, licensing, or specific qualifications for directors. As a result, the quality of governance depends heavily on the individuals appointed. Without knowing who they are, it is difficult to evaluate whether the proposed compensation is appropriate.

I also attempted to identify the candidates based on the descriptions provided. While I was able to form a reasonable assumption about the first candidate, this remains unconfirmed, and I do not consider it appropriate to rely on inference alone. If my assumption is correct, there are aspects of this individual's past business history that would merit clarification. For this reason, I believe the proposal should explicitly disclose the individual's identity and address any relevant history openly, so that voters can make an informed decision.

In the case of the second candidate, I was not able to identify the person with confidence. However, the description suggests involvement in a DeFi market-making entity. Given that this proposal involves deploying stablecoin liquidity to the Cardano ecosystem, this creates a potential conflict of interest. A director in such a position could influence decisions regarding which platforms receive liquidity or how stablecoins are allocated, potentially favoring entities they are already connected with. This does not imply wrongdoing, but it is a material governance risk that should be transparently disclosed and properly managed, for example, through clear conflict-of-interest policies.

If the candidates have active financial or operational ties to Cardano projects that could benefit from the DAO’s decisions, this creates a potential conflict of interest that must be clearly disclosed and properly managed.

For these reasons, I am not comfortable approving the proposal as it stands. This is not a rejection of the idea itself, but rather a request for stronger governance standards, clearer definition of roles (including the relationship between the DAO and the directors), greater transparency, and a more proportionate cost structure.

I am willing to support a revised version of this proposal if the directors are clearly identified, their responsibilities and compensation are justified in relation to the actual scope of work, the interaction between the DAO and the legal entity is clearly defined, and potential conflicts of interest are transparently disclosed and appropriately managed.

I would like to emphasize that if this proposal is approved, I will decide on the 50M ADA withdrawal independently of this one. I will assess it on its own merits, structure, safeguards, and overall value to the ecosystem.

As a DRep, I voted YES for the proposal: Approve Cardano Foundation as New Managing Entity of Project Catalyst

In general, Cardano needs funding for builders. On-chain governance is cumbersome and not suitable for smaller fundings.

The Catalyst Foundation's (CF) takeover of Catalyst was received positively by the community, despite the cancellation of Fund15. I also see this transition positively, as a change of control over the project has the potential to result in necessary changes.

Catalyst has been criticized for what projects were funded and how the voting system worked. It is necessary to make radical changes to the system and set new rules.

I believe CF can implement these changes and make Catalyst a well-functioning funding vehicle.

An important aspect is the builders. They are waiting for payments for the work that has already been done within Funds 10-14. Funding was promised, so it is fair to continue distributing funds for completed milestones.

Although the transition could have happened without this governance action, I appreciate CF for submitting and getting feedback from DReps.

As a DRep, I have decided to vote NO for the proposal: Cardano Budget Process Framework (facilitated by Intersect).

My rationale:

With this vote, I signal a request for changes to the framework.

The framework contains several positive elements. I appreciate the effort to coordinate the decision-making process and to align proposals with the Cardano Vision document. It is necessary to push proposers to define KPIs. A unified template will make it easier to compare proposals in the same category.

I also appreciate that DReps can provide feedback and that teams can adjust their proposals before the final vote.

However, in its current form, the framework has several weaknesses.

The framework sets unrealistic expectations regarding the workload of DReps. Last year, around 200 proposals were submitted. It is naive to expect that DReps are ready to process such a large number in a limited time and for free.

If a typical DRep spends about two hours a day on governance and needs roughly four hours per proposal for review, analysis, research, comparison with others, and voting, they can process only about ten proposals per month.

For the context: In on-chain governance, about five proposals are submitted per month, and DReps often vote at the last minute.

The Intersect process must respect the time capabilities of DReps. Otherwise, it forces them to perform shallow reviews, make hasty decisions, and ultimately produce poor-quality governance outcomes.

The document states that a timeline will be published, but it does not define minimum review durations or workload limits. The review process should scale with the number of submitted proposals.

Another weakness of the framework is the use of "participating stake" in Ekklesia instead of live voting stake.

Given the current concentration of voting power in Cardano governance, using participating stake may allow large DReps to have disproportionate influence if participation is low. Some DReps have already declared that they will not actively participate in Ekklesia voting.

Low participation could therefore significantly affect which proposals advance to the Treasury Withdrawal stage.

The process must be resilient to the dominance of big DReps. Otherwise, it quietly accepts centralization of power and allows for uncontrolled treasury spending.

The framework also proposes bundling proposals into Treasury Withdrawals. Many DReps expressed strong opposition to bundling proposals during last year's budget discussions and preferred the submission of individual proposals.

Bundling forces DReps to approve Treasury Withdrawals containing proposals they do not want to support, simply because those withdrawals also include proposals they do support.

For example, a Treasury Withdrawal could contain proposals A, B, C and D. A DRep might want to support B, C, and D but not A. With bundled voting the DRep must either reject the entire package or approve a proposal they do not support.

This reduces the precision of governance decisions.

In addition to the minimum required amount, a maximum should also be defined. For example, 15M ADA. If a team requests more than the maximum, it would be forced to divide a large proposal into several smaller ones.

This would avoid situations where a single entity requests 100M ADA for many different activities in one proposal. DReps could then decide which activities they support and which they do not. It would also force teams to be more fiscally responsible.

A submission fee of 1000 ADA to serve as a spam filter is a good idea. On the other hand, at the current price of ADA it is only about $250. This seems low considering that the minimum request can be 100,000 ADA.

The submission fee could scale with the request size. For example:

• 1000 ADA for a request up to 500K ADA (small)
• 5000 ADA for a request over 500K ADA (medium)
• 10K ADA for a request over 10M ADA (big)

Putting submission fees into the Treasury is a good idea, but it might also be fair to consider using them to reward DReps who actively review and vote on proposals. Incentives could motivate DReps to participate more actively in the process.

I propose considering a process where, once a proposal crosses the threshold in Ekklesia, a Treasury Withdrawal is submitted individually. Limiting the number of Treasury Withdrawals per month (for example, to five) would give DReps enough time to review proposals properly.

Submitting dozens of Treasury Withdrawals at once forces DReps to make rushed decisions.

The framework in its current form risks creating a situation where:

1. Large DReps may have disproportionate influence on proposal prioritization if participation in Ekklesia is low
2. Treasury Withdrawals may contain bundled proposals, forcing DReps to approve proposals they would otherwise reject

For these reasons, I believe the framework should be revised before it is adopted.

ORIGINAL

As a DRep, I have decided to vote NO for the proposal: Cardano Budget Process Framework (facilitated by Intersect)

With this vote, I signal a request for changes to the framework.

The framework has unrealistic expectations from DReps. Framewok proposes bundling proposals, which DReps clearly rejected last year.

In the proposed framework, I appreciate the effort to coordinate the decision-making process and alignment with the Cardano Vision document. It is necessary to push proposers to define KPIs. A unified template will make it easier to compare proposals in the same category.

I appreciate that DReps can provide feedback and the team can adjust the proposal before the final vote.

In addition to the minimum required amount, a maximum should also be defined. Let's say 15M ADA. If the team requests more than the maximum, it will be forced to granularize a huge proposal into several sub-proposals. This will avoid a situation where one entity requests 100M ADA for different activities. DReps can decide which team activities they will support and which they will not. Moreover, it will force teams to be more responsible in terms of budget.

A submission fee of 1000 ADA to serve as a spam filter is a good idea. On the other hand, at the current price of ADA it is only $250. This seems low to me considering that the minimum request can be 100,000 ADA ($500,000). Let's scale the submission fee with the request size. For example:

• 1000 ADA for a request up to 500K ADA (small)
• 5000 ADA for a request over 500K ADA (medium)
• 10K ADA for a request over 10M ADA (big)

Putting submission fees to the Treasury is a good idea, but it might be fairer to use it to reward DReps who will actively vote on proposals. This can motivate DReps to participate in the process.

Incentives are necessary. Last year, 200 proposals were submitted. It is naive to expect that DReps are ready to process such a large number in a limited time and for free.

If a typical DRep spends 2 hours a day and needs 4 hours per proposal for review, analysis, research, comparison with others and voting, they can process only about 10 proposals per month.

In on-chain governance, about 5 proposals are submitted per month and DReps vote at the last minute.

The Intersect process must respect the time capabilities of DReps, otherwise it forces them to shallow review, hasty voting and basically make poor quality decisions.

The biggest weakness of the framework is the use of "participating stake" in Ekklesia instead of live voting stake, in combination with bundling of proposals.

Given the centralization of voting power in Cardano governance, it is unacceptable to use participating stake, as it allows Whale DRep to push proposals through Ekklesia. Moreover, if the participation of DReps is low. Some have already declared that they will ignore Ekklesia voting.

If I understand the framework correctly, Treasury Withdrawals will contain bundled proposals based on the results in Ekklesia.

Bundling of proposals last year DReps clearly rejected and demanded submission of individual proposals.

Bundling of proposals forces DReps to approve Treasury Withdrawal containing proposal A, which they do not want to support, just because in the same bundle there are also proposals B, C and D, which they want to support.

I propose this process. As soon as a proposal crosses the threshold in Ekklesia, Treasury Withdrawal will be submitted. Maximum 5 proposals per month, so that DRepo has enough time to review.

Submitting 40 Treasury Withdrawals at once forces DReps to make poor decisions.

The framework essentially proposes the following:

1. Big DReps can easily push proposals through Ekklesia
2. Treasury Withdrawal will contain bundled proposals, so DReps will be forced to accept unwanted proposals

Last year, 200 proposals were submitted. The document must specify how much time DReps will be given to review. The process time must scale with the number of proposals.

The document only says that a timeline will be published, but it does not define minimum review durations or workload limits.

As a DRep, I have decided to vote NO on the proposal: Dingo: a Production-Grade Block Producer in Go by Blink Labs

My rationale:

I mentioned the reasons for supporting node diversity in the proposal regarding Amaru. The same applies to other implementations.

ID: gov_action19uhuy5uame2s60yrh6n8cyds8ps5q7tkh05dqlzmpcfy429p9w4qq5ll3g0

From a network perspective, it is ideal to have at least 3 node implementations with an even representation in the network based on stake (33.3%).

Why am I not supporting Dingo at this moment?

Intersect launched a budget process last week. I recommend that all projects seeking funding do so as part of this process. All DReps need to make decisions in the context of other proposals.

I will not approve any withdrawals during the Intersect process that will circumvent it. This is a fair approach with respect to other proposals. If a project does not want to participate in this process, it has to wait until it is finished and hope that the spending does not reach the NCL.

It is very likely that other projects like the Gerolamo node will seek funding. At this point, I do not know how many proposals regarding node diversity will be submitted. A first-come, first-served approach is not a suitable approach for such a large and important investment. It is necessary to select the best proposals and support them.

The community must first agree on how many alternative implementations we want to support. Are 3 enough for us, or do we want to support 4 (Haskell, Amaru, Dingo, Gerolamo, possibly others)? We do not know if SPOs will be willing to install alternative nodes and what their preferences are. This debate has not even started.

So, there is no reason to rush to fund alternative nodes. I will follow the debates on this topic and read the rationales.

There is still an active proposal regarding lowering the NCL to 300M ADA. Another one will likely be submitted. The debate on NCL is not closed yet, which is another source of uncertainty.

The budget is limited due to the low price of ADA. I have to think about the other needs of the ecosystem. Builders are making it clear that they don’t have the resources they need, following the cancellation of Catalyst Fund15 (and Fund16). This is another reason not to rush to support infrastructure investments.

Let’s ensure sufficient funding is secured for projects with a direct impact on acquiring new users. Cardano needs user growth. Node diversity has an indirect effect on this (network stability). This line of thinking is also supported by a significant part of the community, which makes it clear that we should prioritize investments in ecosystem growth over excessive investments in infrastructure.

It is necessary to realize that investing in an alternative node means ongoing support for the coming years. As the Ouroboros consensus and other layers develop, it will be necessary to fund maintenance and changes in all nodes once we start. This is another reason to find a consensus in advance among DReps about which versions we want to support and why. It is a permanent investment in a new team.

Another reason concerns the broader perception of decentralization.

I see node diversity as an investment in decentralization. I see block production and governance as one system. If there are flaws in the system, they must be addressed.

We cannot invest tens of millions of ADA in block production infrastructure and, at the same time, tolerate unfunded and centralized governance.

Imagine a basket with a limited budget for decentralization. Resources must be allocated where they are most needed. There is no point in investing in 2, 3, or even 4 node implementations in the same year, when in governance, the top 5 DReps with voting power of 33.1% can prevent the approval of Treasury Withdrawals, a hard fork, or a constitutional amendment.

We have 1000 registered DReps, but only 20-25% vote. Almost all proposals are approved just before expiration.

One CC member retired because they were not willing to continue working for free for governance. This halted governance. DReps had two options to prevent this situation from happening again, but they did not use either of them.

If we invested the funds that Dingo requires in governance, we could address many problems. We launched on-chain governance, so it is necessary to take care of it. The investment in Cardano decentralization will be unbalanced if we invest everything (from the basket) only in block production.

To be clear, I plan to support the development of more alternative nodes if there is a budget for it. However, only after the NCL debate is concluded, the community agrees on how many nodes we need, the SPOs express their preferences, and the budget for additional builders is secured. We need to know when Catalyst will be relaunched, with what budget, and what other alternatives we have for builders.

I encourage the Dingo team and everyone else to participate in the Intersect budget process.

As a DRep, I decided to vote YES for the proposal: Amaru Treasury Withdrawal 2026

My rationale:

The team is well-established and respected within the Cardano community, with a strong track record.

I appreciate the detailed budget breakdown per activity and the comparison of the budget with similar proposals. Further, how the team plans to deal with volatility. I would like every proposal to include this.

In general, node diversity is critical for decentralization and network resilience. When multiple independent teams build node implementations, it reduces reliance on a single entity, such as IOG in the case of Cardano. It minimizes the systemic risks associated with monoculture software development.

IOG may require an extremely high budget for Haskell node development each year. In such a case, there must be an alternative.

One of the core promises of blockchain networks is high availability, including strong resistance to attacks and censorship. While no system can guarantee 100% uptime, having multiple node implementations increases the network's robustness. If a bug or vulnerability is present in one version, others may remain unaffected, limiting potential damage.

Unfortunately, we have experience with such an event. The November 2025 chain split on Cardano demonstrated the systemic risk of relying on a single node implementation. A malformed transaction triggered a validation inconsistency across node versions, resulting in a temporary fork that disrupted exchanges, explorers, and dApps until emergency patches were deployed and operators upgraded.

The incident exposed how monoculture amplifies software risk. When one codebase contains a critical bug, the entire ecosystem is vulnerable. Funding an alternative implementation, such as Amaru, would introduce client diversity, reducing the probability that a single defect could partition the network.

In a multi-implementation environment, an independent codebase can act as a fail-safe reference, improving resilience, accelerating fault detection, and strengthening Cardano's long-term success.

Encouraging additional node implementations also deepens understanding of the protocol. As more developers build and maintain nodes, they contribute to refining the protocol specification, surfacing ambiguities, and improving long-term maintainability. This also supports future clients by setting a clearer and more battle-tested standard.

Node diversity, however, comes with challenges. Divergent implementations can lead to consensus bugs or temporary chain splits if not carefully tested. Coordinated testnets and protocol-level specification clarity are essential to mitigate these risks.

Protocol upgrades may also take longer, as all implementations must integrate and validate changes, such as the upcoming Ouroboros Leios, which both IOG and Amaru nodes will need to support. The Amaru team needs to be well-funded to keep pace with the IOG development.

I appreciate that the team is thinking about integration with StarStream and Midgard.

Maintaining multiple full node implementations is resource-intensive and will likely require long-term support from the Cardano Treasury. However, the cost is justified by the increased decentralization, security, and community participation that such diversity brings.

The Amaru team's funding request is reasonable. The team includes respected developers from within the Cardano ecosystem and is supported by several reputable entities. Their Rust-based node implementation is a serious alternative to IOG's Haskell-based Cardano node.

The Amaru node strengthens decentralization, improves protocol robustness, and represents a healthy evolution of the Cardano network.

As a DRep, I decided to vote YES for the proposal: Reduce minimum Constitutional Committee size (committeeMinSize) from 7 to 5

We currently have 7 elected CC members, and the required minimum number of CC members is also set to 7.

Having the same number of CC members as the required minimum is a risk, as the governance process can halt after the resignation of a single CC member.

This situation would be especially burdensome in the combination of another crisis, such as the need to quickly upgrade the node version.

The DReps recently refused to add a new CC member, Christina, which would increase the number of CC members to 8. This setting would provide the necessary buffer. One of the arguments was that the election of a new CC member should be preceded by a costly election process.

It makes no sense to have the following process in the event of a crisis:

• Invite candidates to register.
• Elect a new CC member(s).
• Submit an on-chain proposal.
• Wait for the proposal to be approved by the DReps and SPOs.

Let me add that many DReps and SPOs often vote just before the expiration of proposals. It is not certain that they would vote faster in the event of a crisis. Nevertheless, it can be assumed that the election of a new CC member would take at least about a month.

It seems that the only way to mitigate the risk of halt governance is to reduce the required minimum.

From my point of view, it boils down to this question: Is the reduction acceptable?

I believe so. Here are my arguments:

• CC members supervise the constitutionality of proposals. The DReps decide on the merits of proposals. CC members cannot decide anything on their own, so the risk of a higher concentration of power is acceptable in this particular case.

• Ideally, all CC members should interpret the Constitution in the same way, i.e., come to similar conclusions. Practice shows that this happens in most cases. Only occasionally does a CC member have a different opinion from the majority.

• If we carefully select quality CC members and support their education and engagement, there is no need to stick to quantity.

• 5 out of 7 CC members are groups of people. They internally debate and vote on proposals. In the background, a larger group of individuals debates proposals. It is a higher number than the number of CC members.

• Governance is flexible. In case of suspicion of abuse of power, it is possible to elect new CC members or submit a No-Confidence proposal at any time.

• DReps did not approve compensation even for 5 CC members, which was the reason for the resignation of one member. Many DReps and community members considered the requested compensation to be high. It makes sense to reduce the number of CC members, as it reduces the overall budget for this gov body if we were to reconsider compensation.

I admit that reducing committeeMinSize is not ideal, but maintaining the current setting is a worse option. If it is not possible to easily increase the number of CC members for various reasons, reducing it is the only way to mitigate the risk of governance stalling.

As a DRep, I have decided to vote YES on the proposal: Net Change Limit of 300 Million ADA for Epochs 613–713

My rationale:

For context: The previous proposal set the NCL at 350M ADA. This proposal lowers the NCL by 50M ADA to 300M ADA for the period between epochs 613 - 713.

Spending needs to be balanced between protecting against selling pressure that lowers the price of ADA (and also security incentives) and smart investments that can support ADA price growth in the long term.

The price of ADA has dropped significantly to $0.25, which is the level of 2020/2021. At this time, it is wise to limit spending and increase the NCL as needed.

The NCL can be changed at any time. Setting a lower NCL at the beginning signals an effort to spend responsibly. Let's only increase the NCL if there is a compelling reason to do so.

At the current price of ADA, we have about $78M for investments, which is $13M less than with the NCL of 350M ADA. This is an acceptable budget. However, markets are volatile, and these numbers can change at any time.

It would be wise to evaluate the impact of projects that received funding last year. This would tell us in which cases the investments from the Treasury paid off and when they did not. This is one of the aspects that should determine the setting of the NCL.

Last year, we approved the NCL. Subsequently, there were several unsuccessful attempts to reduce it. It seems that the same scenario will be repeated this year. Instead of debating the ideal NCL before the on-chain vote, coordination is taking place through proposals, which I find inefficient.

As a DRep, I decided to vote NO on the proposal: Cardano DeFi Liquidity Budget - Withdrawal 1

Rationale for Rejection

I want to state clearly at the outset that I support the objective of this proposal. Cardano needs deeper and more reliable stablecoin liquidity, and I appreciate the work the team has put into advancing this discussion.

My decision to reject this withdrawal is not opposition to the goal, but a concern about the chosen architecture, sequencing, and cost structure.

The core issue for me is that this proposal asks DReps to approve a substantial amount of ADA for establishing an off-chain legal entity to deploy liquidity in DeFi.

Paying approximately 400k ADA to establish and operate a legal entity, including professional directors and ongoing compliance, represents a clear shift away from decentralized, trust-minimized design towards CeFi-style execution. If we are building DeFi, I believe we should first exhaust on-chain solutions and invest Treasury funds into code, protocols, and governance mechanisms rather than importing legacy legal layers as a starting point.

I fully understand that legal entities are required when interacting with OTC desks, fiat rails, or direct stablecoin issuer minting. However, it has not been convincingly demonstrated that this institutional path is cheaper or more efficient than a trust-minimized, on-chain approach once all costs are considered.

When the fixed legal overhead of roughly 400k ADA is added to OTC spreads, operational friction, and ongoing compliance, the institutional route may in fact be more expensive than a well-designed on-chain strategy at the scale currently being discussed. At approximately $32M of deployment, phased DEX and bridge-based execution can plausibly achieve comparable or lower total cost without introducing permanent administrative overhead.

I am also concerned that we are creating a new legal entity despite already having founding entities that are legal persons. The Cardano Foundation, for example, has publicly indicated plans to use Genesis ADA to mint stablecoins. This raises the question of whether all existing options have been explored and whether these entities have explicitly declined participation. My impression is that they do not wish to bear the legal and operational risk for this program, which is understandable, but that alone does not automatically justify establishing a new, Treasury-funded legal structure without further exploration or explanation.

I also believe that all major entities within the Cardano ecosystem share a vested economic interest in preserving ADA in the Treasury and using those funds as efficiently as possible. For that reason, I would expect openness to cooperation and reuse of existing structures wherever feasible. If the ecosystem ultimately decides that a new legal entity must be established, it should be designed as a reusable, shared resource for future initiatives rather than a single-purpose structure created solely for this proposal.

Another important point is that the proposal does not specify whether the legal entity is intended to exist only for a single year or to operate on an ongoing basis. While only year-1 costs are budgeted, there is no stated sunset clause, dissolution condition, or estimate of operating expenses for years 2 and beyond. In practice, this means approving not only a one-time expense, but the creation of a recurring cost center with no defined end. This lack of clarity makes it difficult to assess the true long-term commitment being made on behalf of the Treasury.

I am also uncomfortable with the way this withdrawal is positioned as the first in a sequence of withdrawals. When I approved the Info Action, I highlighted several shortcomings, as did many other DReps. I expect the team to address them. Before approving this withdrawal, I would like to see a second withdrawal with attachments that would be considered final and binding.

I have read the attachments to the first withdrawal, but I am not sure of their status. I give the team credit for addressing some of my concerns.

Under the current governance process, meaningful changes or clarifications can realistically only be acted upon in subsequent proposals/withdrawals. Approving this first withdrawal without visibility into the full set of planned withdrawals effectively pressures voters to approve later ones to avoid stranding sunk costs. Rejecting a later withdrawal after approving the legal entity would likely result in a loss of Treasury funds.

This is a systemic governance issue rather than a fault of the team, but it makes it impossible for me to responsibly approve this withdrawal in isolation. I would strongly prefer to see all planned withdrawals submitted with sufficient detail so the entire project can be evaluated coherently.

Finally, I want to emphasize that I remain supportive of this project and of the broader goal of improving Cardano's liquidity. However, I am not comfortable approving a large upfront expenditure for legal structuring before attempting a trust-minimized, on-chain-first approach.

My understanding is that the legal entity primarily exists to shield the committee from liability and to enable off-chain execution. If decisions were made directly by DReps and execution were limited strictly to on-chain transactions, neither a legal entity nor a committee would be strictly necessary. There are viable paths to bootstrap USDM or USDA liquidity using DeFi-native mechanisms such as DEXs, bridges, and phased deployment without exposing individuals to off-chain liability.

For these reasons, I am rejecting this proposal at this time. I encourage the team to explore an on-chain-first design, clarify the lifetime and cost of any legal entity, and present the full set of withdrawals together.

I remain open to supporting a revised approach that better aligns with decentralized principles while still addressing Cardano's liquidity needs.

I will continue to carefully review the rationales and arguments presented by other dReps and follow the ongoing discussion across community channels and social media.

Governance decisions of this magnitude benefit from broad scrutiny and diverse perspectives, and I remain open to refining my position should new information, clarifications, or materially different approaches emerge through that process.

As a DRep, I decided to vote YES for the proposal: Increase Transaction and Block Memory Units (Part 1 of 2)

Increasing the Plutus script memory unit limits for both transactions and blocks can, in some cases, facilitate dApp development and have a positive impact on the user experience.

The proposed changes do not have a dramatic impact on performance, which has been tested.

The change is recommended by the Parameter Committee and ratified by Intersect's Technical Steering Committee. I trust that they can devote enough time and have the expertise to best assess all the technical aspects of the change.

The parameters were set conservatively at the beginning. It is reasonable to push the limits. Especially if the builders request it.

In case of problems, the changes can be reverted. As stated in the proposal, it will probably not be necessary. I agree.

As a DRep, I decided to vote YES for the proposal: Name Protocol Version 11 hard fork - van Rossem

I fully support continuing the tradition of naming hard forks after individuals who have made a meaningful contribution to the growth of the Cardano ecosystem. It's a fitting way to honor their impact and preserve their legacy.

Honor and glory to Max van Ross.

As a DRep, I decided to vote YES for the proposal: Net Change Limit (Epoch 613 to Epoch 713)

Up to ₳350M can be withdrawn during the February 2026 –July 2027 NCL period. That cap was set higher specifically because there is an expected / previously approved ₳50M withdrawal originating from the 2025 decision.

The ₳50M budget is expected to be used to mint stablecoins. The Cardano ecosystem desperately needs this investment. If withdrawal is not approved, the ₳50M will remain available for something else.

The new NCL period is 500 days, or roughly 1 year and 4 months. On average, about ₳19M can be spent per month. The NCL for 2026 would be about 225M ADA.

According to my calculations, about ₳275M will be moved from the reserve to the treasury in 2026. In 2027, about ₳240M. Even if the maximum amount of ADA according to the NCL was withdrawn, ₳50M would remain in the treasury for the next years. That is reasonable.

The Cardano protocol earns about ₳50K per epoch, so in the calculation it is unfortunately a negligible amount for now.

I dare say that this NCL will push for cost reduction. Given that the teams will probably consider a lower price of ADA in 2026 than in 2025, most of the budget can be consumed by IOG, Catalyst and Intersect if they would request a similar budget.

As a reminder, in 2025 they requested:

• IOG core development: ₳96M
• IOG research: ₳27M
• Catalyst: ₳70M
• Intersect: ₳15M

That's a total of ₳208M. That would leave ₳17M for other proposals. Within this NCL, there is no room for another larger proposal of the scale of the Pentad proposal (₳70M) or the originally planned ₳100M for DeFi liquidity. I don't see much room for marketing proposals.

However, this is only a theoretical consideration at this point. No one can predict the market.

The NCL can be changed at any time. I believe that if there is a good reason, DReps would be willing to increase the NCL as needed.

At this point, it is wise to set the NCL to a low value. The proposed NCL of ₳300M + ₳50M is acceptable.

DReps should demand higher granularity of large proposals and carefully select only those items that Cardano really needs in 2026/2027.

With this NCL, it is not realistic to approve almost ₳100M budget for IOG without DReps having the opportunity to postpone less needed items to later. I want to believe that Intersect will play its role well in this.

It is obvious that proposals that will be submitted at the beginning of the NCL period will have a higher chance of approval. It can be assumed that most of the budget will be spent at the beginning and less will be left for later expenses.

DReps should be careful about the extended NCL period.

As a DRep, I have decided to vote YES for the proposal: CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION v2.4

I support the proposed changes to the Cardano Constitution because they improve clarity, coherence, and practical enforceability without undermining decentralization.

The revisions reduce ambiguity, better align the Constitution with Cardano’s on-chain governance mechanisms, and clarify roles and responsibilities in a way that strengthens accountability and decision-making. I also agree with the clarification around governance action sequencing, in particular that Info actions should not be used to pre-empt or condition treasury withdrawals. This simplification makes the process clearer and helps preserve voter sovereignty.

Overall, these changes represent a sensible evolution toward a more robust, transparent, and effective governance framework for the Cardano ecosystem.

As a DRep, I decided to vote NO on the proposal: DeltaDeFi: Hydra Trading Infrastructure Budget (₳1,500,000).

I appreciate the effort and technical competence demonstrated by the DeltaDeFi team. The proposal is well written, and the team has a proven ability to deliver.

My negative decision is based on the following considerations.

Allocating nearly 20% of the total budget to a "KPI Measurement Program" is, in my view, unjustified. Cardano has recently partnered with Dune, which enables low-cost, public, and reusable dashboards for most of the proposed metrics (TVL, volume, MAU, transactions, trends).

If the community believes that another extra DeFi Dashboard is needed, this should be addressed through a neutral, ecosystem-wide analytics initiative, not bundled into a single project’s budget.

The proposal does not explain how liquidity and users will actually be attracted. Delivering software alone does not bring liquidity or users, especially in the current market environment. The proposal relies on the assumption that market makers and users will arrive once APIs and infrastructure exist, which is not a reliable strategy.

The proposal's technical goals are realistic, but the TVL, volume, and MAU targets are aspirational and largely outside the team's direct control.

Without explicit liquidity strategies, incentives, or commitments, these targets should not be treated as expected outcomes.

If the team decides to submit another proposal, I would like to know who will provide initial liquidity, who will pay or incentivize market makers, what will attract new users, etc. It makes no sense to define ambitious goals without a strategy.

The team has already received approximately 650,000 ADA through Project Catalyst and has demonstrated the ability to deliver an MVP. This is positive.

However, giving a single DEX team more than 2M ADA to develop without demonstrable results is too much in my opinion. At this stage, I would prefer the team to focus on attracting users and liquidity with what already exists (MVP), rather than requesting a large new budget to continue building.

Cardano Treasury resources are limited, and concentrating such a large amount in a single team without demonstrated adoption carries a significant risk. I believe the team should only request additional funding after providing data on new users, transaction numbers, volume, etc.

A six-month period is sufficient to evaluate software delivery, but not to evaluate ecosystem impact. Most of the period will be spent building and hardening infrastructure. Any assessment will therefore focus on technical completion, not real adoption.

Given current market conditions, user growth and liquidity formation are especially uncertain. I am uncomfortable approving funding where success cannot realistically be evaluated on the outcomes that matter most: usage, liquidity, and market relevance.

The administration committee does not mitigate the core risks of this proposal, which are unclear liquidity sourcing, uncertain user adoption, and real ecosystem impact within six months.

The incentive model and business model are insufficiently specified. I need to know the intended fee structure, incentive model for liquidity providers or market makers, expected revenue, etc.

The proposal does not specify whether the project aims to be profitable and on what timeline.

I cannot objectively judge whether this is infrastructure spending or a subsidized private business with uncertain alignment.

This project appears to have profit potential if successful. At least I believe it should be a for-profit project. That is why I expect data on the project's sustainability and profitability in the proposal.

It is reasonable to ask whether the funding could be structured as a loan or some form of revenue sharing.

Cardano governance has previously required the SNEK project to convert its proposal into a loan. Applying a similar standard here would support fairness.

As a DRep, I vote YES for the proposal: Cardano 2030: Vision, Mission, Strategy Framework and KPIs.

The proposal focuses on all the important topics that I perceive as important for Cardano, especially scalability, privacy, and adoption. I appreciate the focus on topics such as post-quantum readiness, client diversity, and DID.

I could perhaps imagine some KPIs to be more ambitious; on the other hand, I appreciate that the estimates are realistic.

Some KPIs seem a bit ambitious to me, for example, the one regarding the voting activity of DReps: "> 70% of active DReps (by stake) vote on 90% or more of governance actions.".

At the end of the day, what is important is what we actually achieve, not what will be written in the document. I see the document primarily as a decision-making framework for DReps, so for me, the defined direction is more important than the KPIs.

The document mentions the need to fund DReps, SPOs, and the CC members. Approval of the document may oblige governance bodies to approve some form of compensation. I am not sure if the current wording cannot be abused in this way, but it is definitely an issue that should be resolved once and for all.

SPOs are currently the only governance actors that receive compensation from the protocol, although this is not related to governance. In my view, the incentive model should be changed, perhaps including ADA holders who could receive larger rewards if they delegate to active DReps, and smaller ones if they abstain or their DRep does not actively vote.

Regarding SPOs, the document mentions incentive improvements that will concern, among other things, the K parameter and the fixed reward parameter. This is a long-neglected topic, and I am glad that it is becoming one of the priorities.

In the context of governance, I would like to see a focus on standardization or the introduction of processes that would increase the quality of proposals. One of the goals should be to prevent excessive spending of ADA from the Treasury.

I see an asymmetry between the various funding mechanisms.

In Catalyst, it is possible to get relatively small funding, while the bureaucracy around submitting proposals and approving milestones is high. The winners are often decided by whales, founding entities, and DAOs, not DReps.

In on-chain governance, it is possible to apply for millions of ADA, and there are no standards regarding submission or meeting KPIs.

The document mentions that L2S must contribute value back to L1. I see this as a very important topic, and I hope that a viable framework will be set up.

I dare say that Cardano's success will be significantly influenced primarily by the Pentad initiative. If critical infrastructure can be built, the KPIs are achievable.

The Cardano 2030 vision and strategy is a direction that I, as a DRep, identify with and enthusiastically support.

As a DRep, I voted YES for the proposal: Add Constitutional Committee Member - Christina.

In the Snap election, Cardano Curia won with a slight lead over Christina. Christina received a large support from the community. Both of these candidates had by far the most votes over the others.

It is wise to increase the number of CC members above minCommitteeSize, as this will strengthen governance. In case a CC member suddenly retires, governance will remain operational.

Christina would become the third among the eight CC members who handle this role individually. This balances the ratio between councils and individual CC members.

As a DRep, I decided to vote YES on the Withdraw ₳70,000,000 for Cardano Critical Integrations Budget proposal.

I provided the reasons in the Info proposal, which are still valid. In this rationale, I will provide context for my decision.

Without specific integrations, Cardano will not reach banking use-cases, RWA tokenization, serious fintech integrations, large stablecoin programs, etc.

All projects pursuing these use cases have had to pay for critical integrations, often under NDA. Pentad benefits from not disclosing details about vendors and allocations of funds to specific integrations.

I will give two examples of integrations:

CCIP (Cross-Chain Interoperability Protocol) is Chainlink’s secure messaging and token-transfer standard, enabling reliable communication between blockchains and between blockchains and traditional financial systems. Chainlink provides the decentralized oracle network that verifies and secures every cross-chain interaction, making CCIP far safer than conventional bridges.

It gives blockchains a trusted, institution-grade way to share liquidity, move assets, and connect applications across networks—unlocking DeFi scaling, RWA use cases, and enterprise adoption that require secure interoperability.

What smaller projects did they pay for under NDA? Near, Solana, Avalanche, Algorand, and others.

Fireblocks is an institutional-grade digital asset custody and transfer platform that secures crypto assets without ever creating a single private-key point of failure. It provides banks, exchanges, fintechs, and asset managers with a secure infrastructure for storing assets, executing transactions, and integrating blockchain features into their products. It enables regulated institutions to safely hold and move crypto, which is a prerequisite for large-scale on-chain liquidity, enterprise adoption, and the deployment of stablecoins and tokenized assets on any blockchain.

What smaller projects did they pay for under NDA? Near, Sui, Avalanche, Algorand, and others.

Ethereum is by far the most integrated blockchain in the entire industry. It is the default chain that nearly every service, company, or protocol integrates first, and often exclusively, before considering other chains.

Many chains are actively catching up to Ethereum's infrastructure and institutional integrations — and Cardano hasn't truly begun that phase yet.

Even emerging chains like Sui and Aptos are ahead of Cardano in integrations.

Major integrations across top blockchains have largely been driven by banks, asset managers, fintechs, and enterprise platforms that require secure custody, compliance, and interoperability to deploy real on-chain use cases.

Banks such as JPMorgan, Citi, HSBC, and BNP Paribas adopted blockchain through tokenization pilots, collateral settlement systems, and cross-border payment networks, mostly built on or connected to Ethereum via Chainlink CCIP and institutional custody providers.

Asset managers like Franklin Templeton, BlackRock partners, Ondo, and Fidelity brought real-world assets on-chain, including money-market funds and tokenized treasuries, demanding reliable pricing oracles, stablecoins, and enterprise custody such as Fireblocks or Anchorage.

Fintech companies like Revolut, PayPal, and Robinhood integrated custody and transfer infrastructure to offer crypto to their users, while enterprises such as Nike, Starbucks, and Reddit adopted blockchain for loyalty, digital collectibles, and supply-chain use cases via platforms like Polygon.

These institutional and enterprise demands are what pushed other blockchains to prioritize integrations—bridges, custody, oracles, analytics, and cloud infrastructure—long before Cardano began this effort.

I know how the Cardano ecosystem can benefit from building critical infrastructure, and that we are behind. That is why I cannot oppose this proposal because of the Genesis ADA debate or vaguely defined KPIs.

Charles closed the Genesis ADA debate and promised that Pentad can use its resources to cover the additional costs associated with this proposal. I am not sure if it is a good strategy for DReps to reject this proposal with the intention of pressuring founding entities to use Genesis ADA.

Honestly, if DReps ever want to achieve this, they must coordinate their decisions together first.

The KPIs could be better defined. The proposal could have stated that integration with a Tier-1 oracle service, a custody service, and a stablecoin would be achieved.

Pentad has the best reputation in the ecosystem, and I can't imagine anyone else taking on this task. I agree that it is a "trust me, bro" proposal, but considering who we trust, it is acceptable

Cardano has superior technology, but without building critical infrastructure, the world will never know about it. Let's use Treasury to boost the ecosystem.

As a DRep, I have decided to vote YES on the Add Constitutional Committee Member proposal.

A new CC member, Cardano Curia, was elected in the Snap election. No one disputed the election results. I have no reason to disrespect this result.

The Cardano Curia members are well-known faces. I trust them and their ability to perform the CC role flawlessly.

Cardano governance needs to be able to approve proposals that require CC approval as soon as possible. This governance proposal is urgent, as there are other proposals waiting in the queue that require approval from CC members.

I am pleased that Cardano governance is able to quickly and effectively replace the retired CC member. I hope that other DReps will vote soon.

Congratulations to Cardano Curia on winning the Snap election, and I hope that they will soon become an active CC member.

As a DRep, I voted YES for the 2025 Net Change Limit Extension proposal.

In the context of recent events, namely, the retired CC member Cardano Atlantic Council, the ongoing SNAP election, and the submitted Cardano Critical Integrations Budget proposal, it makes sense to extend the Net Change Limit (NCL) by 8 epochs (40 days).

This will allow all withdrawals that started in this NCL period to be completed (both the info action and the withdrawal).

Approving the 70M ADA proposal within the current NCL is smarter than mentally transferring info action and/or balance to the next NCL period.

Furthermore, the NCL for next year has not been approved. It would be wise to have the NCL approved before the start of the new period. For this, we need a functioning CC, i.e., electing and approving a new CC member.

This is another reason to extend the current NCL period. I hope that at least an off-chain debate about the new NCL will begin.

Thank you for submitting this proposal. It was smart.

As a DRep, I decided to vote YES for the Cardano Critical Integrations Budget proposal.

Although Cardano has superior technology, it turns out that bottom-up adoption is not the fastest path to success. We need to onboard not only crypto natives, but also new users from the top down. This is only realistic if we can establish new strategic partnerships. These will not be possible without the critical infrastructure that can be delivered through this proposal.

Our most pressing issues are the absence of a Tier-1 stablecoin (including liquidity) and integration with Chainlink. Many community members want a natively minted Tier-1 stablecoin, specifically USDC and/or USDT.

I am surprised by the need to invest in on-chain analytics platforms and cross-chain bridges. There were several such tools funded in Catalyst. In Fund14, the building of another Bridge was approved. There is Wanchain and others. I would like to see a more detailed explanation and justification for this investment in the withdrawal proposal.

There is no time to wait for a miracle. This proposal should have been submitted a year ago, right after the introduction of on-chain governance. I am excited that it is finally here.

The Steering Committee, consisting of the founding entities, Intersect, and the Midnight Foundation, is solid and trustworthy, although a significant part of the community is critical of individual entities. It is positive to see that they reflect the state of the ecosystem and have taken steps together to address it.

Milestone-based funding with oversight is an excellent choice and an example of what a proposal requesting such a large sum should look like. An external audit adds credibility.

The Committee is committed to returning unused funds to the Treasury. That is positive. 5% for administration seems quite a high amount to me. A detailed breakdown of planned expenses would help.

70M ADA is a huge amount. It would be desirable to see a more specific budget. The proposal only shows what is to be achieved, but we do not know if the budget is adequate. It may be low or unnecessarily high.

I would like to see EMURGO and the Cardano Foundation (CF) provide additional funding if necessary to achieve the goal. CF has promised to provide an 8-figure sum for the minting of stablecoins. I expect at least some of it to be used for liquidity for a Tier-1 stablecoin.

I am excited about this proposal because it can finally deliver what Cardano has been needing for years.

As a DRep, I decided to vote YES for Loan ₳5,000,000 to Expand Cardano's Global Listings.

A PDF version of this rationale is also made available.

I had a productive call with SNEK in which some of my concerns were clarified. We said "Hi" in Berlin at the Cardano Summit. However, this is not the main reason why I am changing my decision.

I still think that paying off the loan can be a challenge for the team, especially if a bear market hits. On the other hand, 5 years gives room to take advantage of the next bull market that may be favorable for SNEK.

From my point of view, meme coins are not the most important direction for Cardano. My preferences remain the same, i.e., DeFi based on stablecoins and RWA, ideally with privacy support.

The recent unfortunate swap in which a user lost millions of USD due to low liquidity in the pool convinced me that we cannot make quick decisions and take the necessary steps to make our ecosystem succeed. In this context, it makes sense to support a project that will bring new activity to the chain.

Theoretically, 5M ADA could be used to pump stablecoins into the ecosystem. However, I do not expect that such a withdrawal will be approved by the end of the year. Hopefully, at least a withdrawal requesting 50M ADA will be approved. So approving a long-term loan is not an obstacle to other important goals.

It is necessary to add that this is a loan that has been supported by big names such as:

• Phillip Pon (CEO of Emurgo)
• Fahmi Syed (President of Midnight Foundation)
• Frederik Gregaard (CEO of Cardano Foundation)

If they are willing to associate their name with this proposal and possibly risk their careers, I will not be the one to hold back the proposal.

I probably would not support a similar proposal from a smaller meme project. SNEK has huge support, including my delegators. About half wanted me to support SNEK (but they understood my NO vote), and about half were glad that I did not support the Info proposal.

Tens of millions of ADA have been spent from the Treasury on various projects. We can afford to support the meme sector, especially if it is a loan, not a grant.

I wish the SNEK team and community all the best.

As a DRep, I decided to vote YES for the Ikigai Info Governance Action Deposit Reimbursement.

A PDF version of this rationale is also made available.

The deposit loss was caused by a bug in the Cardano node. The submitter could not have predicted the deposit loss. Moreover, it was the first governance action after the Chang hard fork. No one had experience submitting governance actions.

I considered how I would vote in a case where funds were lost due to a hack in DeFi. In such a case, I would probably vote NO, because the blame would be on the third-party team and security auditors. Treasury should not be used to cover damages in DeFi.

In the case of the Ikigai Info Governance Action, there was a bug on the Cardano protocol side, so the responsibility lies with the IOG team and the community. It is legitimate for the submitter to ask DReps to consider reimbursement.

I understand that the submitter lost staking rewards and other opportunities, but in my opinion the submitter should have only requested 100,000 ADA. Asking for an additional 3000 ADA seems a bit unreasonable to me, considering that the reimbursement could have been requested a long time ago.

Nevertheless, the proposal is acceptable as submitted.

From the governance action, I cannot verify whether the same entity that submitted the Ikigai Info Governance Action is requesting reimbursement. If anyone has any doubts, please contact me before submitting a withdrawal.

As a DRep, I decided to vote YES for the Securing Generic Top-Level Domains for the Cardano Ecosystem proposal.

A PDF version of this rationale is also made available.

Securing “.ada” and “.cardano” prevents other parties from registering those top-level domains, thereby reducing phishing risks, brand dilution, and confusion.

A verified .cardano TLD could help users visually identify trusted services at a glance. If the Cardano Foundation (CF) strictly controls who can register under ".cardano" or ".ada", then users can reasonably assume that "myapp.cardano" or "wallet.ada" is officially connected to the Cardano ecosystem.

This is similar to ".gov", ".edu", or ".bank" — restricted domains that communicate legitimacy because registration is verified and centrally governed.

Having ecosystem-specific domains enables use cases such as human-readable wallet addresses (e.g., “yourname.ada”) and domain tokenisation, as well as decentralized identity integrations.

These domains should be owned by the Cardano community. Only legally established entities can claim ownership of these domains, so it is necessary that one of the founding entities, such as CF, technically owns the domains.

I assume that the costs of securing the domains will be covered by Genesis coins. This is a desirable use of resources. I appreciate that CF is seeking DReps' approval for this operation. I also appreciate that CF is not seeking ADA from the Treasury and is committed to covering the annual operating costs associated with maintaining the domains in the estimated amount of $350,000.

CF owns the Cardano brand, so it is a suitable entity to manage the domains.

CF becomes the registry operator, meaning it controls all second-level domains. CF has not yet given a detailed plan for subdomain access or policy.

In the proposal, CF promises to establish a Community Advisory Group (CAG) to define policies and oversee responsible operation. Unfortunately, it is not defined how many members the committee will have, what their composition will be, whether DReps will participate in the decision-making, and who will have the final say (whether CF or CAG).

It should also be clarified whether it will be necessary to pay for obtaining a subdomain and what the potential revenue streams will be. Furthermore, how the profit will be used.

I believe in the good intentions of the Cardano Foundation regarding the management of top-level domains. They were the first to take the initiative, and they want to manage the domains and will even cover the costs associated with the acquisition and operation of the domains. I support this initiative.

As a DRep, I have decided to vote NO on the Constitutional Committee Compensation.

A PDF version of this rationale is also made available.

To the best of my knowledge, the proposal was not preceded by any debate with DReps and the community. CC members only debated among themselves. Only 5 out of 7 CC members are requesting compensation. The details of this debate are not public.

The proposal seems to me inconceptual and does not address any specific problem that we can currently observe. If we are to make changes, we should stick to a vision and strategy. It makes no sense to introduce compensation for one group of governance bodies without knowing how we will compensate DReps. We also do not know what the community and DReps think about compensation.

I will not approve compensation for CC members without simultaneously introducing the same benefits for DReps.

I dare say that the work of DReps is much more demanding than the work of CC members.

• While CC members are elected from a relatively small number of interested parties and then have their position secured, DReps have to try harder to get delegations from ADA holders. This is time-consuming.

• CC members only deal with the constitutionality of proposals, which is just a binary decision based on a clear text of the Constitution. If the proposal is in accordance with the Constitution, CC members just vote YES (regardless of their opinion). DReps have to deal with the merit of proposals, which is more time-consuming. It is necessary to analyze all aspects of proposals from different perspectives. They have to communicate with teams and delegators. In some cases, they are even asked for their opinion before submitting proposals. They have to give detailed feedback to teams (if they want and have the time).

• DReps have to explain their decisions to the community much more often, communicate with their delegates, and even face criticism. One prominent DRep even retired after such criticism. Also in this respect, the work of DReps is more demanding.

• It is DReps who approve proposals. While CC members can all vote YES for a proposal that is in accordance with the Constitution, it is up to DReps to reject a proposal that has low impact, or is even submitted by fraudsters. The role of DReps is more responsible.

• CC members have performed their role flawlessly without compensation so far. Many DReps are not willing to write rationales. Many DReps do not even explicitly vote NO if they do not want to vote YES. Perhaps their fatigue can be observed. In this case, compensation could address specific governance issues (there are plenty of issues).

If the position of CC members were to become more lucrative than the position of DReps due to compensation, it could introduce an imbalance into the system.

If there is agreement that CC members deserve compensation, I dare say that DReps deserve it too.

While in the case of CC members, introducing compensation is relatively easy, since there is a fixed number of them and their voting power is the same. In the case of DReps, it would be more complicated. They have different voting power and a different number of delegators.

This complexity is not a reason to introduce compensation for CC members before we introduce it for DReps.

Intersect requires a relatively large sum for Cardano governance. Governance tools also require funding. Let’s define the vision, determine how much we want to spend on governance from the Treasury, and then make decisions regarding other costs.

Volunteer work can have its limits and shortcomings. If DReps, but also CC members, put more time and effort into their work, maybe it would be beneficial for Cardano. Compensation would be attractive to experts, which we definitely need.

My opinion is that we should not pay governance bodies through Treasury withdrawals. Instead, we should integrate governance with staking. But that would be a different debate.

If we were to use 1M ADA for compensation, let’s divide this amount between CC members and active DReps. Governance bodies decide on hundreds of millions of ADA per year. This is a responsible role that should probably be compensated. However, doing it voluntarily is still a valid option.

Maybe it would be fair to do an analysis first and discuss the pros and cons. This proposal is unprepared and completely ignores the complexity of Cardano governance.

As a DRep, I decided to vote YES for changes to the content of the constitution, i.e., for version v2.3.

A PDF version of this rationale is also made available.

Slight adjustments to the texts and definitions make sense and simplify the understanding of the Constitution.

Changes regarding Info governance actions, strengthening accountability, and ensuring document mutability also make sense and streamline governance.

As a DRep, I decided to vote YES for the withdrawal of ₳1,150,000 for GovTool.

A PDF version of this rationale is also made available.

I explained my reasons for supporting this project in the Info Governance Action. They are still valid.

In short, GovTool is a mission-critical infrastructure for Cardano governance.

The Cardano community needs to support open-source tools for governance. Decentralization is not only about block production, but also about tools that facilitate governance processes, namely DReps registration, overview of DReps and governance actions, voting, communication, etc.

The breakdown is fairly transparent with specific FTE allocations.

It includes ecosystem-wide incentives, not just one vendor.

Cardano governance will evolve, so we need to not only maintain the tools but also continue to improve them. Tools with a modern user experience can attract new people to governance, which is what we need.

As a DRep, I am voting NO on the Defining the Cardano 2030 Vision & Strategy governance action.

A PDF version of this rationale is also made available.

I want to be very clear that my decision is not based on disagreement with the broad direction presented in Cardano 2030: Our Future, Defined. On the contrary, I generally like the document: it is well written, ambitious, and captures many of the values that should guide Cardano’s development. It succeeds in presenting a compelling aspirational vision, and it proposes KPIs that could, in principle, help us measure progress.

However, I cannot approve it in its current form. My rejection is partly procedural and partly substantive: the way the action has been structured makes it difficult to approve responsibly, and the content of the vision itself leaves important gaps that need to be addressed before it can credibly serve as our community’s north star.

Procedurally, I believe it is a mistake to separate the approval of the vision from the approval of the strategy. It is common practice to have two documents: the vision as a long-term destination, and the strategy as the path to reach it. The vision should remain stable and inspirational, while the strategy can evolve as circumstances change.

But when it comes to endorsement by the community, both should be reviewed together. Approving only the vision means DReps are asked to support ambitious declarations — such as the $200M annual revenue target — without being shown whether the actual strategy is realistic. The vision document itself acknowledges that the “aspiration is translated into tangible action through a comprehensive strategic plan.” If that is true, then it makes little sense to treat the vision in isolation. The two should be mapped together so that for every declaration in the vision, there is a corresponding set of steps in the strategy. Without that mapping, approval becomes a leap of faith rather than an informed decision.

The governance action provides only a single link to the document “Cardano 2030: Our Future, Defined.” This text is clearly a vision paper: it sets out aspirations, principles, and KPIs, but it does not contain a concrete strategy. The strategy is mentioned within the document, for example, in the section “From Vision to Strategy,” but no link or details are provided. In effect, DReps are asked to approve only the vision, even though the proposal is titled “Cardano 2030 Vision & Strategy.”

Substantively, the vision is too vague in several areas that matter for Cardano’s long-term identity. While it speaks eloquently about sustainability, decentralization, and adoption, it avoids specifics. For example, it does not name the technological pillars that will enable the future it describes.

Cardano’s path to scalability is not an abstract idea; it depends on tangible innovations such as Ouroboros Leios, Hydra, Mithril, and L2 frameworks. I would not expect detailed protocol specifications in a vision document, but I would expect these innovations to be at least acknowledged as the foundations of the ecosystem’s technological identity.

Similarly, privacy is entirely absent, even though privacy is a cornerstone of blockchain legitimacy and a natural extension of Cardano’s focus on formal methods, high assurance, and responsible innovation. Without privacy, Cardano risks being unable to serve sensitive domains such as identity, enterprise applications, and financial systems. A vision for 2030 that omits privacy feels incomplete.

Another major gap lies in governance. The document highlights transparency and accountability, and it frames governance as DReps expressing the will of the community. But this treatment is abstract and does not answer the most important questions: how will authority evolve between DReps, SPOs, and the founding entities — the Cardano Foundation, IOG, EMURGO, and Intersect?

These entities still hold enormous influence. They control Genesis coins, manage protocol research, steward adoption, and coordinate governance infrastructure. A credible vision should at least outline how their roles will change by 2030, how checks and balances will be established, and how collaboration between DReps and these entities will work in practice.

I feel the document pays too little attention to governance, even though on-chain governance is deeply tied to the protocol and directly influenced by how DReps decide to allocate Treasury funds. Governance on Cardano still has many shortcomings, and it would make sense to define a clearer vision for its future.

Some founding entities also serve as DReps, which makes questions of transparency and accountability even more important. The vision could therefore set expectations around transparency, establish principles for handling Genesis coins, and outline a framework for participation in governance.

Just as decentralization at the SPO level is essential, so too is decentralization at the DRep level, and this deserves to be part of the vision. While a vision approved by DReps is not legally binding, it nevertheless creates lasting community pressure that can shape the behavior of founding entities in practice.

The KPIs, while important, are not fully credible in their current form. The $200M annual revenue goal would require about 20–30 transactions per second. While this may be achievable with Leios and related scaling solutions, the document does not explain how the demand will be generated.

Phrases like “fostering meaningful transactions” and “stimulating on-chain demand” are left undefined, which leaves too much ambiguity. Similarly, the Treasury section is too vague. It invokes stewardship and efficiency but gives no indication of allocation models, oversight mechanisms, or measurable targets for impact. If the Treasury is central to Cardano’s sustainability, then the vision should at least include guiding models for distribution and accountability.

More generally, the KPIs omit governance entirely: nothing measures DRep participation, voter turnout, or treasury efficiency. These are central to Cardano’s distinctiveness and should be tracked alongside adoption and economic activity.

For me, this combination of procedural and substantive weaknesses means that the document, while well written, cannot be endorsed as it stands. If it is to serve as the community’s north star, it needs to be stronger: it should be approved together with the strategy or at least in explicit mapping to it; it should acknowledge flagship technologies and privacy as part of Cardano’s long-term identity; it should define expectations for founding entities and their collaboration with DReps; and it should include governance and treasury KPIs to measure the health of Cardano’s democratic system.

In its current form, the Cardano 2030: Our Future, Defined document is more a collection of aspirations than a guide I can use as a DRep to make informed decisions. For this reason, while I respect and appreciate the effort that went into drafting it, I must vote NO on this governance action.

As a DRep, I have decided to vote YES for the Stablecoin DeFi Liquidity Budget proposal.

A PDF version of this rationale is also made available.

GLOBAL PERSPECTIVE

In the global crypto landscape, expanding Cardano’s stablecoin supply is essential to remain competitive. Stablecoins now represent a $282 billion market, with Ethereum alone hosting $164 billion. Solana and BNB Chain each hold around $10 billion.

Cardano’s native USD-backed stablecoins—USDM and USDA—currently total just $25 million in market cap. At today’s ADA price, allocating 50 million ADA could roughly double that amount. But even then, Cardano’s stablecoin footprint would remain tiny compared to other ecosystems.

While 50M ADA may seem significant in the context of this year’s Net Change Limit, it’s actually the bare minimum needed to support Cardano’s growth. Personally, I’d support an even larger withdrawal if it helps build real utility.

TIMING

Timing is critical. The coming months may offer the best opportunity to mint stablecoins, as ADA could be nearing its bull market peak. If ADA rises further, minting becomes cheaper. But if ADA drops, we’ll get fewer stablecoins for the same amount—making this window especially valuable.

I believe it would be irresponsible to reject this proposal, especially from the perspective of monetary responsibility. A thriving DeFi ecosystem is not optional—it’s a core pillar of Cardano’s mission and critical to the protocol’s long-term sustainability.

Superior technology alone isn’t enough. We need users, liquidity, and real-world adoption. If we build brilliant services that no one uses, we fail. That’s the risk—and this proposal helps mitigate it.

Cardano’s DeFi ecosystem faces multiple challenges—not just low liquidity and the high slippage that comes with it. These issues are interconnected: solving one can help alleviate others.

MY CONCERNS

While I support this proposal, I believe it’s important to highlight a few concerns.

By injecting liquidity into selected protocols, we are inevitably picking winners and losers. The supported protocols will likely thrive, while others may struggle to survive. In extreme cases, we risk losing builders—or creating a situation where they remain dependent on Catalyst and Builder DAO subsidies, rather than building sustainable businesses.

This kind of market distortion could have unintended consequences, and the committee members carry significant responsibility for the outcomes of their decisions.

I understand the need for efficiency, which is why concentrating funds in two protocols makes sense. However, I believe the current rule—limiting allocations to only two protocols per category—is too rigid.

Supporting multiple protocols may be more advantageous from a risk diversification perspective.

My suggestion: remove the hard limit. The committee can still choose to fund only two protocols if that’s optimal, but they shouldn’t be bound by the rule. Flexibility will allow for better judgment and adaptability as the ecosystem evolves.

RESTRICTIONS ON THE USE OF ADA IN GOVERNANCE

The committee will control a significant amount of ADA—up to 35% of the 50 million ADA. While they’ve committed not to use this ADA for staking, they haven’t made any commitment regarding other activities, such as governance voting or delegation to DReps. To avoid any ambiguity or misuse, I believe this should be explicitly addressed in the rules.

UNELECTED COMMITTEE

I’ve spent a long time weighing whether to support the creation of yet another unelected committee—especially one tasked with making high-impact decisions that could significantly affect individual protocols.

Ultimately, I chose to support it, primarily due to the urgency of the issues this proposal aims to address. In this case, DReps may lack the time or specialized expertise needed to make fully informed decisions. Under these circumstances, a commission is an acceptable solution.

That said, I believe the ideal model would be a collaborative structure—where DReps work alongside a group of experts, combining democratic legitimacy with deep domain knowledge.

COMMITTEE MEMBERS

There is this rule in the document:

“Committee members should have broad knowledge across many domains including finance, Cardano DeFi, smart contracts, communication, business, and regulations.”

This reads like a superhuman job description. Realistically, no single person can be an expert in smart contracts, finance, and regulation all at once. Current committee members should disclose whether they meet these conditions.

This relates to remuneration. While the expectations for committee members are extremely high, the proposed compensation of 1,000 ADA per month seems inadequate.

First, it’s not attractive to new candidates. If we want qualified experts in key positions, we can’t rely on volunteers. We need to offer compensation that reflects the importance and complexity of the role.

It’s possible the committee will only make a few major decisions, with the heaviest workload concentrated in the first month. After that, their role may shift to oversight and occasional adjustments. In practice, one member might carry a full-time workload, while others only attend periodic online meetings.
Unfortunately, the proposal provides no estimates or breakdowns of expected workload, which makes it difficult to assess whether the remuneration is fair or sufficient.

CONFLICT OF INTERESTS

Another big issue is conflict of interest. The rules are too lenient in this regard.

For example, see this rule:

“All committee members should disclose any conflicts of interest when deliberating on any proposal sent to the committee. ”

This wording leaves too much wiggle room. Disclosure is expected, but not enforced. The phrase “should disclose” should be replaced with “must disclose” to ensure accountability.

It’s also possible that there are already unacknowledged ties between committee members and certain protocols.

WEAK POINTS

There are many such weak points in the “Stablecoin DeFi Liquidity Budget” document.

My understanding is that the approval proposal makes this document binding, and any changes would require an on-chain proposal. Therefore, it’s essential to amend the document before it becomes binding, ideally before the withdrawal proposal is submitted.

If we’re going to choose winners and losers, we must ensure that decisions are made professionally and transparently.

Even if committee members act in good faith, the optics matter. People may still say: “Of course, Protocol X got funding — their employee sits on the committee.” This kind of perception can erode trust in governance and lead to accusations of capture.

A similar example of weak phrasing is:

“The committee should also consider the following factors when selecting DeFi protocols:”

This wording leaves too much discretion in the hands of the committee and opens the door to potential favoritism. Because it’s not binding, there’s no guarantee that these factors will be applied consistently or transparently.

To ensure fairness and accountability, I would expect the proposal to include a formal scoring system with weighted criteria. This would make the selection process objective, repeatable, and easier to audit.

CONCLUSION

The intention to inject liquidity into Cardano’s DeFi ecosystem is undeniably important. But for it to succeed, the execution must be flawless—and the community must have full confidence in the process.

That’s why it’s essential for DReps to carefully review the “Stablecoin DeFi Liquidity Budget” document and propose necessary changes. Strengthening this foundation will help ensure transparency, fairness, and long-term impact.
Thank you to everyone who contributed to this proposal. Your work is deeply appreciated.

As a DRep, I’ve decided to vote NO on the ₳5M loan proposal for Cardano’s Global Listing Expansion powered by SNEK.

A PDF version of this rationale is also made available.

This decision was not made lightly, it followed a detailed analysis of the proposal and extensive engagement with the SNEK community. It was one of the most difficult governance choices I’ve faced so far.

The SNEK Foundation has already invested $4.5M into listings on several major centralized exchanges (CEXs). However, the current trading volumes are underwhelming. In the last 24 hours, Kraken saw $88,000 in volume, KuCoin $30,000, and Crypto.com just $2,000.

I examined the impact of these listings on Cardano’s on-chain activity and volume. While there was a short-term spike following the listings, the numbers quickly returned to previous levels. In fact, Cardano’s on-chain volume has been trending downward. The peak was in 2023, and by 2025, we’re seeing the lowest levels yet. Transaction counts are also gradually declining, aside from occasional spikes.

This leads to a clear conclusion: listing on major CEXs has not significantly boosted Cardano’s on-chain activity or volume. At least so far.

Meanwhile, HTX shows a much higher volume—$7M in the last 24 hours. This is substantially more than what we see on Cardano’s decentralized exchanges (DEXs), where Minswap V2 recorded $480,000, Wingriders V2 $74,000, and Minswap $41,000.

To better understand the broader implications, I analyzed the case of Shiba Inu, arguably the most successful meme token. Across the top five CEXs, Shiba Inu saw $125M in volume in a single day, while the top five DEXs combined for only $275,000. That’s a 450x difference. Despite having 1.5 million holders, Shiba Inu averages only about 6,000 on-chain transactions per day.

This shows that even successful meme coins generate most of their activity on CEXs, not on-chain. If SNEK were to gain popularity following a major listing, it’s likely that the impact on Cardano’s DeFi ecosystem would be minimal—or even negative, as attention shifts away from on-chain protocols.

After the FTX collapse, interest in self-custody grew, but this trend is mostly limited to BTC and ETH. For altcoins and meme coins, users still prefer CEXs due to ease of trading. While it’s possible that some users might discover SNEK on a CEX and then install a Cardano wallet, the number of such users will likely be small, though still welcome.

The proposal should have included a clear forecast of how CEX listings would drive growth in on-chain activity, volume, and user adoption. That data is missing.

Listing the first Cardano asset on a top-tier exchange could pave the way for future projects. However, it's important to note that IOG plans to list NIGHT on major CEXs without requesting Treasury support. Given this, the current proposal is not urgent.

This proposal is also notable for being the first to request a loan from the Cardano Treasury. I appreciate the initiative. However, the community has not yet reached consensus on whether Treasury loans should be collateralized.

In a recent poll I conducted, 59% of voters supported collateralized loans, 13% opposed, and 17% preferred a case-by-case approach. The SNEK proposal requests a loan without offering any collateral.

Personally, I don’t believe the absence of collateral should automatically disqualify a proposal. The Treasury should act like a strategic investor—willing to take calculated risks to support ecosystem growth. Many teams seeking support likely don’t have collateral, and a strict requirement could stifle innovation and early-stage development.

If the team had sufficient collateral or strong confidence in their project's success, they could secure funding by taking out a loan through DeFi platforms.

That said, proposals must include data-driven forecasts, measurable KPIs, and realistic revenue expectations. DReps need this information to assess risk and relevance. Funding should also be milestone-based, with future disbursements contingent on progress.

Although off-chain discussions and private communications shouldn’t normally influence governance decisions, they are acceptable at this early stage. I publicly asked Goofycrisp, a core SNEK contributor, the following:

"At present, the proposal doesn’t specify any form of on-chain or off-chain collateral. Can you clarify whether the loan will be collateralized, and if not, what safeguards will protect Treasury funds in the event of non-repayment?"

He replied:

"It's also the ONLY proposal that WILL pay back plus interest and is a direct net positive for the treasury.
At this point, Cardano gotta trust us. And I believe we've earned it."

This response is concerning. Treasury loans cannot be based solely on “trust me, bro.” That would set a dangerous precedent. This proposal will shape future governance standards, and we must demand transparency and accountability—not vague assurances.

The SNEK team claims the loan will be repaid over five years using revenue from their products, including Snek.fun, SNEKbot, Snekx, and SecurityBot. They state:

"Just as an example, over the last 30 days, Snek.fun has generated 100,000+ ADA. If we assume no growth at all, this alone would equal ~6.3M ADA over five years, already covering the loan principal."

While this sounds promising, the team only provided concrete numbers for Snek.fun. The rest of the revenue streams are mentioned without supporting data. The assumption that Snek.fun will maintain its current revenue for five years is overly optimistic—if not naive.

History shows that meme hype is short-lived. Solana’s recent meme boom collapsed, with volume and activity dropping by 90%. Every bear market has had similar effects.

If Snek.fun’s revenue drops, the team may not be able to repay the loan. Without detailed financials from other products, it’s impossible to assess the risk.

We also need to consider the broader ecosystem. Cardano currently has high fees and slippage, making it less competitive than Solana or CEXs for swaps. Under current conditions, it’s unlikely that Cardano will experience a meme coin mania similar to Solana’s.

Beyond the short-term benefits of volume and attention, we must also weigh the long-term risks. Solana’s meme surge damaged its reputation. Some users left and may never return. The meme space has both bright and dark sides, and we must acknowledge that.

The proposal does include a Board of Advisors intended to provide guidance and validation. However, I haven’t seen any public statements from these advisors clarifying their roles. Notably, representatives from EMURGO and the Cardano Foundation are listed as advisors, and they also serve as DReps voting on Treasury proposals. This dual role raises concerns. Even if their votes are based on merit, the optics of advising and voting on the same proposal could undermine community trust.

In summary, while the proposal is ambitious and well-intentioned, it lacks the necessary data, transparency, and safeguards to justify a ₳5M loan from the Treasury. For these reasons, I am voting NO.

I’m rejecting the proposal at this time to send a clear signal: Treasury loans must meet standards that will apply to all future projects. Ideally, these standards should have been defined earlier—perhaps even before the vote on the 39 withdrawals—but we can’t rewrite history. What we can do is keep improving our governance processes.

In that sense, this proposal is valuable. It highlights gaps in our current framework and pushes the community to refine how we evaluate and manage Treasury loans going forward.

As a DRep, I decided to vote NO for the proposal: Cardano in Oceania: A community-led strategic plan for investing in growth.

A PDF version of this rationale is also made available.

Recently, 37 out of 39 proposals were approved, which means a significant portion of the budget has already been allocated. Many of these proposals focused on booths, marketing, and support for local communities. Meanwhile, Fund14, where hackathon-related proposals could be submitted, has just closed.

While I appreciate the intent behind this new proposal and believe it could have a positive impact, I think projects within the same category should be submitted and reviewed together. That way, they can compete on equal footing, making it easier to select the strongest ideas and manage total spending for the year.

In my view, this proposal should have been submitted earlier, alongside the others that were recently approved. As it stands, it feels like it overlaps with initiatives that have already received Treasury funding.

As a DRep, I’ve committed to prioritizing support for builders over marketing initiatives. Rejecting this proposal aligns with that commitment, especially during the first year of on-chain governance.

Soon, a major proposal will request 50M ADA to inject liquidity into Cardano DeFi—and possibly another to support Bitcoin DeFi. These initiatives are far more critical to ecosystem growth. With this year’s NCL set at 350M ADA, we need to be selective and strategic. I’d strongly prefer not to see us approach that limit too quickly.

I’d prefer to see this proposal submitted next year, once the new NCL is approved and we begin planning the 2026 budget. That timing would allow it to be properly evaluated alongside other initiatives and ensure more strategic allocation of funds.

Until then, the team can think about using Catalyst Fund15.

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 2
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 2

Total score: 9

I did not vote for this proposal in Ekklesia. However, after careful reconsideration and communication with team members, I have decided to support this proposal.

As a DRep, I voted YES to adopt version 2.0 of the Cardano Blockchain Ecosystem Constitution, replacing version 1.0.

A PDF version of this rationale is also made available.

While many changes have been made, most are structural—streamlined wording, improved clarity, fixed typos, and the removal of redundancies.

The most significant update is the elimination of the requirement for a Budget Information Governance Action before a Withdrawal Governance Action. Removing this prerequisite will cut unnecessary bureaucracy and improve the efficiency of funding.

A few additional updates have also been introduced. Notably, for treasury withdrawals totaling under 1 million ADA within a two-year period, several previously burdensome requirements have been lifted. This adjustment streamlines the process for small-scale funding and reduces unnecessary constraints.

I want to express my sincere gratitude to everyone who contributed to the amendment of the Constitution.

As a DRep, I’ve voted NO on the proposal to pay listing fees for Snek. I don’t believe this expense is justified.

A PDF version of this rationale is also made available.

I’m happy to see meme coins emerging on Cardano. I appreciate the Snek project and its vibrant community—they represent grassroots creativity and a unique social experiment.

That said, I don’t believe meme coin projects should seek ADA from the Treasury. Here’s why.

Meme coins should drive on-chain activity. Listing them on centralized exchanges (CEXs) works against that goal—users can buy and sell there without interacting with the Cardano network, meaning no fees or engagement on-chain.

While CEXs are a key entry point into crypto, only a small percentage of users actually create on-chain wallets. Despite hundreds of millions registered on CEXs, only about 1–5% become on-chain users.

If meme coin teams believe CEX listings benefit their project, they’re free to pursue that path—but it shouldn’t be funded by the Cardano Treasury.

Snek has around 40,000 users, while Cardano has over 1.3 million ADA stakers. ADA remains the primary onboarding asset, and we shouldn’t downplay its central role. Snek might help onboard some users, but its impact on Cardano’s overall success is limited.

As for marketing, spending 5 million ADA on listing fees isn’t the best use of funds. There are already marketing-focused proposals among the 39 withdrawals that offer better value.

On liquidity, our goal should be to strengthen ADA/stablecoin pairs (like USDM, USDA), not ADA/SNEK. That’s a more strategic path for Cardano’s growth.

Snek’s current market cap is $244 million. The team has reportedly reserved 10% (currently, around $24 million) for marketing, partnerships, and CEX listings. That’s a substantial budget for a meme coin. Given these resources, additional funding from the Cardano Treasury isn’t necessary.

One current withdrawal proposal requests ₳3,126,000 to support listings on top-tier CEXs: “Ecosystem Exchange Listing and Market Making service.”

I suggest the Snek team collaborate with this group to support CEX listings across the entire Cardano ecosystem, rather than pursuing separate funding.

Paying listing fees from the Cardano Treasury sets a problematic precedent. CEXs typically charge each project individually—it’s not a technical hurdle, it’s a business model. If we fund Snek’s listing, other projects will expect the same, leading to unsustainable demands on Treasury funds.

We must be clear: the Treasury is not meant to cover listing fees. Projects should plan and fund these efforts independently.

I understand that my perspective may disappoint members of the Snek community, and I genuinely regret that. However, DReps have a responsibility to think long-term when it comes to Treasury spending. Decisions must be strategic—not driven by popularity or short-term excitement.

Cardano is being built as a decentralized global financial and social operating system. Meme coins like Snek absolutely have a place in that vision, but they are not the core priority.

I also hope the community gives the same level of attention and scrutiny to the other 39 current withdrawal proposals as they have to those submitted by the Snek team. Every proposal deserves thoughtful consideration.

As a DRep, I’ve voted NO on the proposal to pay listing fees for Snek. I don’t believe this expense is justified.

A PDF version of this rationale is also made available.

I’m happy to see meme coins emerging on Cardano. I appreciate the Snek project and its vibrant community—they represent grassroots creativity and a unique social experiment.

That said, I don’t believe meme coin projects should seek ADA from the Treasury. Here’s why.

Meme coins should drive on-chain activity. Listing them on centralized exchanges (CEXs) works against that goal—users can buy and sell there without interacting with the Cardano network, meaning no fees or engagement on-chain.

While CEXs are a key entry point into crypto, only a small percentage of users actually create on-chain wallets. Despite hundreds of millions registered on CEXs, only about 1–5% become on-chain users.

If meme coin teams believe CEX listings benefit their project, they’re free to pursue that path—but it shouldn’t be funded by the Cardano Treasury.

Snek has around 40,000 users, while Cardano has over 1.3 million ADA stakers. ADA remains the primary onboarding asset, and we shouldn’t downplay its central role. Snek might help onboard some users, but its impact on Cardano’s overall success is limited.

As for marketing, spending 5 million ADA on listing fees isn’t the best use of funds. There are already marketing-focused proposals among the 39 withdrawals that offer better value.

On liquidity, our goal should be to strengthen ADA/stablecoin pairs (like USDM, USDA), not ADA/SNEK. That’s a more strategic path for Cardano’s growth.

Snek’s current market cap is $244 million. The team has reportedly reserved 10% (currently, around $24 million) for marketing, partnerships, and CEX listings. That’s a substantial budget for a meme coin. Given these resources, additional funding from the Cardano Treasury isn’t necessary.

One current withdrawal proposal requests ₳3,126,000 to support listings on top-tier CEXs: “Ecosystem Exchange Listing and Market Making service.”

I suggest the Snek team collaborate with this group to support CEX listings across the entire Cardano ecosystem, rather than pursuing separate funding.

Paying listing fees from the Cardano Treasury sets a problematic precedent. CEXs typically charge each project individually—it’s not a technical hurdle, it’s a business model. If we fund Snek’s listing, other projects will expect the same, leading to unsustainable demands on Treasury funds.

We must be clear: the Treasury is not meant to cover listing fees. Projects should plan and fund these efforts independently.

I understand that my perspective may disappoint members of the Snek community, and I genuinely regret that. However, DReps have a responsibility to think long-term when it comes to Treasury spending. Decisions must be strategic—not driven by popularity or short-term excitement.

Cardano is being built as a decentralized global financial and social operating system. Meme coins like Snek absolutely have a place in that vision, but they are not the core priority.

I also hope the community gives the same level of attention and scrutiny to the other 39 current withdrawal proposals as they have to those submitted by the Snek team. Every proposal deserves thoughtful consideration.

As a DRep, I confidently vote YES to replace the Interim Constitution Committee.

A PDF version of this rationale is also made available.

This rotation is not only a healthy step for governance—it’s a principle enshrined in the Cardano Constitution. The election process was smooth, with no complaints noted, and the newly elected members are fully equipped to fulfill their roles.

I’m pleased that the incoming CC members are those I personally voted for. But even if that weren’t the case, I would still support the transition.

Importantly, this marks a historic shift: for the first time, CC members are not affiliated with founding entities. That alone makes this change worth supporting.

I have full confidence in the new members’ ability to handle their responsibilities—and I wish them great success in their work ahead.

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 8

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 1
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 6

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 0
• Team strength, feasibility, and track record: 1
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 4

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 0
• Team strength, feasibility, and track record: 1
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 4

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 0
• Team strength, feasibility, and track record: 1
• Impact on the Cardano ecosystem: 1
• Value for money:
• Cost compared to similar proposals:
• Personal or community usage and benefit:

Total score:

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 1
• Impact on the Cardano ecosystem: 1
• Value for money: 0
• Cost compared to similar proposals: 0
• Personal or community usage and benefit: 1

Total score: 4

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 1
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 7

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 0
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 2
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 6

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 0
• Impact on the Cardano ecosystem: 1
• Value for money: 0
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 5

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 0
• Team strength, feasibility, and track record: 1
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 5

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 2

Total score: 8

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 0
• Team strength, feasibility, and track record: 1
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 4

The vote for this withdrawal is NO. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 0
• Team strength, feasibility, and track record: 1
• Impact on the Cardano ecosystem: 1
• Value for money: 0
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 4

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 2
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 2
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 2
• Cost compared to similar proposals: 2
• Personal or community usage and benefit: 0

Total score: 8

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 2
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 8

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 2
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 2

Total score: 10

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 2
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 9

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 2
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 9

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 1
• Impact on the Cardano ecosystem: 2
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 2

Total score: 8

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 2
• Value for money: 1
• Cost compared to similar proposals: 2
• Personal or community usage and benefit: 1

Total score: 10

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 1
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 2
• Personal or community usage and benefit: 0

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 2
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 2

Total score: 9

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 2
• Cost compared to similar proposals: 2
• Personal or community usage and benefit: 1

Total score: 10

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 2
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 2

Total score: 10

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 0

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 1
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 7

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 1
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 2
• Value for money: 1
• Cost compared to similar proposals: 1
• Personal or community usage and benefit: 1

Total score: 8

The vote for this withdrawal is YES. Details can be found in the rationale.

A PDF version of this rationale is also made available.

I plan to vote YES on most projects I’ve supported in Ekklesia. To stay transparent, I’ll rate each project across six categories, scoring 0 to 2 per category (max 12 points). Projects scoring below 6 won’t get my support. I’ll consider supporting those with 7–8 points, and will fully support any scoring 9 or more.

The categories are:

• Key infrastructure, research, or essential funding: 2
• Team strength, feasibility, and track record: 2
• Impact on the Cardano ecosystem: 2
• Value for money: 2
• Cost compared to similar proposals: 2
• Personal or community usage and benefit: 2

Total score: 12

I’ve decided to vote NO on the Info Governance Action submitted by Tempo.Vote.

A PDF version of this rationale is also made available.

I do have a profile on Tempo.Vote and genuinely appreciate the service. I believe in supporting platforms I actively use. I also like the idea of offering a short-term loan of 100K ADA to help users submit governance actions and earn a modest return. Still, there are alternative ways to make this mechanism work.

However, the requested 200K ADA to cover six months of infrastructure costs—roughly 33,333 ADA per month, or around $25,000 USD—feels excessive. Additionally, the proposal allocates 180K ADA to implement three new features, which also seems overvalued. I believe another team could deliver similar results more cost-effectively.

In my view, a comparable proposal could be executed with a budget up to ten times lower.

I’ve decided to vote YES on the Info GA proposal for GovTool.

A PDF version of this rationale is also made available.

Initially, I was leaning toward voting NO or Abstain, as the request for 1.15 million ADA (approx. $920,000) to fund 5.75 FTEs seemed quite steep for a community-driven open-source project. This concern appears to be shared by many, based on discussions I’ve followed across X.
It’s worth asking whether maintaining and evolving a single governance tool should really cost $1 million per year—especially when multiple governance tools are now in development. Each of these projects will likely request funding from the Treasury. In that context, I believe $1M should be enough to support several tools, not just one.
I believe that as these tools mature and stabilize, their maintenance costs will naturally decrease.
More broadly, I think the development of governance infrastructure needs better coordination. Without it, we risk fragmentation and inefficient use of resources.
In the end, I chose to support the proposal.
Governance is still a relatively new component of our ecosystem, and early-stage support is essential. Many tools are still in development—some are incomplete, others don’t function as expected, and improvements are clearly needed.
Effective on-chain governance depends on robust infrastructure. Cardano has committed to building governance on-chain, and to succeed, we must bring its infrastructure to a mature, reliable state.
I recall that navigating budget proposals in GovTool was noticeably less intuitive compared to Ekklesia. We saw governance actions submitted incorrectly. Many DReps don’t provide rationales for their votes, and technical hurdles may be a contributing factor.
All that is evidence that the tooling isn’t yet where it needs to be.
Better-designed tools can encourage stronger engagement from DReps and delegators.
Another reason I support this project is its commitment to being fully open-source. In a decentralized ecosystem, open access is key to building trust.
One final reason I’m supporting the proposal is simple: GovTool is my go-to platform for governance. It’s the tool I rely on most, so it feels natural to stand behind something I actively use.
That said, I’d really like to see the team optimize GovTool over time so that it becomes less costly to maintain. As the platform matures, I hope its upkeep will become more efficient.

I voted YES on the Treasury Withdrawal proposal submitted by the Amaru project.

A PDF version of this rationale is also made available.

I voted YES on the Treasury Withdrawal proposal submitted by the Amaru project.

My rationale

The team is well-established and respected within the Cardano community, with a strong track record.

I value their decision to manage the budget directly through a smart contract and a well-defined framework. This adds transparency, and I trust the team to handle it responsibly.

While the team will retain full control of the funds, I consider this acceptable given their reputation.

Most importantly, a financial audit is planned, so the community will be able to verify that funds are used as intended.

My rationale for voting YES, which I attached to the info governance action

Node diversity is critical for decentralization and network resilience. When multiple independent teams build node software, it reduces reliance on a single entity, such as IOG in the case of Cardano. It minimizes the systemic risks associated with monoculture software development.

One of the core promises of blockchain networks is high availability, including strong resistance to attacks and censorship. While no system can guarantee 100% uptime, having multiple node implementations increases the network’s robustness. If a bug or vulnerability is present in one version, others may remain unaffected, limiting potential damage.

Encouraging additional node implementations also deepens understanding of the protocol. As more developers build and maintain nodes, they contribute to refining the protocol specification, surfacing ambiguities, and improving long-term maintainability. This also supports future clients by setting a clearer and more battle-tested standard.

For comparison, Bitcoin is largely dependent on a single implementation: Bitcoin Core. While there are alternatives (e.g., btcd, Bitcoin Knots), they are rarely used, making the network heavily reliant on a single development team. This centralization becomes especially visible during governance disputes, such as those surrounding the use of the OP_RETURN opcode and Ordinals.

In contrast, Ethereum has multiple actively maintained implementations for both its consensus and execution layers. These include clients like Geth, Nethermind, Besu, Erigon (execution), and Prysm, Lighthouse, Teku, Nimbus (consensus). This diversity has strengthened Ethereum's decentralization and made the network more resilient to bugs and performance issues in any single client.

Node diversity, however, comes with challenges. Divergent implementations can lead to consensus bugs or temporary chain splits if not carefully tested. Coordinated testnets and protocol-level specification clarity are essential to mitigate these risks. Protocol upgrades may also take longer, as all implementations must integrate and validate changes, such as the upcoming Ouroboros Leios, which both IOG and Amaru nodes will need to support.

Sustained funding is another consideration. Maintaining multiple full node implementations is resource-intensive and will likely require long-term support from the Cardano Treasury. However, the cost is justified by the increased decentralization, security, and community participation that such diversity brings.

The Amaru team's funding request is reasonable, especially compared to the budgets that IOG requires. The team includes respected developers from within the Cardano ecosystem and is supported by several reputable entities. Their proposed Rust-based node implementation would be a serious alternative to IOG’s Haskell-based Cardano node, marking a crucial step forward for ecosystem resilience.

This initiative strengthens decentralization, improves protocol robustness, and represents a healthy evolution of the Cardano network.

I am voting NO on the Cardano Blockchain Ecosystem Budget of 275M ADA, administered by Intersect.

Rationale:

I strongly oppose bundling all proposals into a single package for DReps to approve.

Critical proposals are grouped with less important or unnecessary ones, many of which belong to Catalyst.

Budget responsibility requires making decisions on individual proposals or smaller bundles, not one large one.

Proposal Breakdown:

• In Ekklesia, I voted YES for 35 proposals totaling 213.3M ADA—which is 62M ADA lower than the collective DRep-approved budget in Ekklesia.

• A separate GA exists for six of the proposals I supported—these are top-tier projects that most DReps agree will positively impact the ecosystem.

• Intersect’s GA includes 19 projects, totaling 204.2M ADA, including four IOG projects with a combined budget of 194M ADA.

• At the same time, 14 projects totaling 65.5M ADA were proposals I did not support in Ekklesia.

Assuming that IOG is able to submit its own GA for their proposals, I am talking about supporting 15 projects with a total budget of 10M ADA that I want to support.

Against this are 14 projects with a budget of 65.5M that I do not want to support.

As a DRep, I cannot accept it.

In my case, this imbalance makes the bundled approach unacceptable. I believe that many DReps will struggle with this as well.

Preferred Alternative:

I urge teams to submit their own GAs or ask Intersect to structure proposals by category or threshold.

• On-chain voting for individual proposals would be ideal, though the 100K ADA deposit for GA submissions is a challenge for many projects.

• Smaller, more focused GA bundles would allow better decision-making.

Net Change Limit (NCL) Concerns:

The current NCL is unclear, making a 275M ADA budget approval premature. There are two active GAs regarding NCL:

1. 200M ADA NCL that expires May 29, 2025.
2. 300M ADA NCL that expires June 8, 2025.

The existing NCL received strong support, but many DReps may have backed it simply to keep the budget process moving—not because they favored a high limit.

Until DReps align on the NCL, approving such a large budget makes little sense.

This GA expires June 13, 2025. If both active NCL GAs fail, confirming the current NCL, I will still have one epoch to reconsider my vote.

Next Steps & My Position:

I urge DReps to vote on the NCL GAs as soon as possible.

I continue to believe that budgetary responsibility is best maintained by voting on individual proposals rather than relying on an NCL. Let’s handle this on-chain.

My NO vote is a signal to Intersect that I support a process change. I do not want to approve one large bundle worth 275M ADA—I prefer individual votes or smaller proposal bundles.

However, my support for the projects I voted YES for in Ekklesia remains firm. I will vote YES if they submit their own GA.

I am also open to reconsidering all proposals, as long as they come through proper GA submissions.

Ultimately, I believe the ideal NCL should be around 250M ADA, with 10M ADA kept as a reserve for emergencies.

Balancing monetary policy protection and ecosystem investment is a challenge—we must minimize selling pressure while funding growth.

The solution is ensuring that only projects with a positive long-term impact receive ADA from the Treasury.

In my view, some proposals in the current bundle are unnecessary.

I am voting NO because the governance action is invalid and will reportedly be resubmitted.

I voted YES for the Ecosystem Budget for Community Builders.

Rationale:

A total of 7,568,810 ADA is needed to fund seven community builder projects that have surpassed the 2.69B ADA threshold, which represents 50% + 1 Lovelace of the active registered voting stake.

In GovTool and Ekklesia, I supported six out of the seven projects—but all seven are expected to have a positive impact on the ecosystem.

From Ekklesia’s voting results, it’s clear that DReps overwhelmingly support these projects, and that should be acknowledged.

Three of the seven projects—Midgard, Starstream, and ZK Rollup—specifically address scalability, which is the most pressing need for the Cardano ecosystem.

Given this context, voting YES was the only logical choice.

Founding Entity Proposals:

Proposals from founding entities that also met the threshold were intentionally excluded from this governance action. Instead, they are invited to submit their own governance actions for budget requests.

I fully support this decision, as it aligns with the ongoing community debate about the Net Change Limit (NCL).

The current NCL is set at 350M ADA, but a reduction is expected. Two governance actions have been submitted to adjust the NCL to 200M or 300M ADA.

To minimize spending, it’s best to decide on-chain for each proposal individually, rather than bundling multiple proposals into a single governance action.

This approach prevents situations where DReps who support IOG’s budget feel obligated to also back community proposals they disagree with.

Given the circumstances, Intersect has made the right decision, and I appreciate their approach.

I vote YES for the governance action setting a 300M ADA Net Change Limit (NCL) for epochs 563–635.

As I’ve emphasized in previous discussions on NCL, it’s essential to balance monetary policy protection with ecosystem investment while also accounting for delays in the budget process.

DReps approved a budget of approximately 281M ADA, but the governance action for it has yet to be submitted. Setting the NCL at 300M ADA ensures an additional ~20M ADA remains available for spending if needed.

A one-year NCL period makes sense, beginning in Q3 2025 and ending in Q2 2026—one year after this governance action’s potential ratification.

While I personally favor a lower NCL of around 250M ADA, the majority of the voting stake supports higher spending, and that decision must be respected.

I voted YES for the Amaru project.

Node diversity is critical for decentralization and network resilience. When multiple independent teams build node software, it reduces reliance on a single entity, such as IOG in the case of Cardano. It minimizes the systemic risks associated with monoculture software development.

One of the core promises of blockchain networks is high availability, including strong resistance to attacks and censorship. While no system can guarantee 100% uptime, having multiple node implementations increases the network’s robustness. If a bug or vulnerability is present in one version, others may remain unaffected, limiting potential damage.

Encouraging additional node implementations also deepens understanding of the protocol. As more developers build and maintain nodes, they contribute to refining the protocol specification, surfacing ambiguities, and improving long-term maintainability. This also supports future clients by setting a clearer and more battle-tested standard.

For comparison, Bitcoin is largely dependent on a single implementation: Bitcoin Core. While there are alternatives (e.g., btcd, Bitcoin Knots), they are rarely used, making the network heavily reliant on a single development team. This centralization becomes especially visible during governance disputes, such as those surrounding the use of the OP_RETURN opcode and Ordinals.

In contrast, Ethereum has multiple actively maintained implementations for both its consensus and execution layers. These include clients like Geth, Nethermind, Besu, Erigon (execution), and Prysm, Lighthouse, Teku, Nimbus (consensus). This diversity has strengthened Ethereum's decentralization and made the network more resilient to bugs and performance issues in any single client.

Node diversity, however, comes with challenges. Divergent implementations can lead to consensus bugs or temporary chain splits if not carefully tested. Coordinated testnets and protocol-level specification clarity are essential to mitigate these risks. Protocol upgrades may also take longer, as all implementations must integrate and validate changes, such as the upcoming Ouroboros Leios, which both IOG and Amaru nodes will need to support.

Sustained funding is another consideration. Maintaining multiple full node implementations is resource-intensive and will likely require long-term support from the Cardano Treasury. However, the cost is justified by the increased decentralization, security, and community participation that such diversity brings.

The Amaru team's funding request is reasonable, especially compared to the budgets that IOG requires. The team includes respected developers from within the Cardano ecosystem and is supported by several reputable entities. Their proposed Rust-based node implementation would be a serious alternative to IOG’s Haskell-based Cardano node, marking a crucial step forward for ecosystem resilience.

This initiative strengthens decentralization, improves protocol robustness, and represents a healthy evolution of the Cardano network.

I voted NO to reduce the Net Change Limit (NCL) to 200M ADA, which has been one of the toughest governance decisions so far. It feels like there’s no entirely good option here.
Moreover, I myself called for a lower NCL.

The current NCL of 350M ADA has some notable drawbacks.

If high selling pressure causes ADA’s price to drop significantly—say to 0.2 USD—it could result in serious challenges. Funding the ecosystem in dollar terms would require selling a large amount of ADA from the treasury, leading to a spiral of selling pressure that could worsen the situation.

Cardano Whale pointed out that some projects like Tezos and Polkadot have invested heavily in their ecosystems, possess innovative technologies, yet struggle to gain substantial attention.

For blockchains, maintaining a presence in the top 10 market capitalization rankings is vital.

Retail investors, institutions, and crypto enthusiasts evaluate projects not only based on technology but also on market performance. If Cardano drops out of the top 10 for an extended period, it may never regain its position, regardless of decentralization or technological progress like Ouroboros Leios. This is an important factor to consider, even if it feels unfair or subjective.

On the other hand, reducing the NCL to 200M ADA comes with its own set of concerns.

Cardano needs investments to advance its technology, support builders, and develop the ecosystem. Without increased user activity, Treasury revenue won't grow. Spending on maintenance and development in the next years risks exhausting the reserve, ultimately making Cardano economically unsustainable.

Protocol security also hinges on attractive staking rewards and incentives. Moreover, Ouroboros Leios’s potential will remain untapped without active developers, tools, and a growing DeFi ecosystem. Investments in all these areas are crucial.

IOG has made their funding requirements clear: Core Dev needs 96M ADA, Catalyst 69M ADA, and Research 27M ADA. Combined, this totals 192M ADA. The offer from IOG is simple: either approve this funding or let it be.

Debates around fairness, IOG and Charles’s past contributions, and the definition of “completion” for Cardano have their place, but the reality is that IOG holds unmatched expertise in the protocol. No other entity can effectively take over maintenance, development, and research at the same pace or quality.

If DReps allocate 192M ADA to IOG, only 8M ADA remains for other projects.

After reviewing budget proposals, I supported only the essentials I believe the ecosystem absolutely needs: projects like Midgard, Starstream, Hydra, ZK Rollups, Blockfrost, Lucid, Chainlink integration, and others. For the CORE category alone, this amounts to around 12M ADA. Across all categories, my total approved budget comes to 213M ADA.

Given my own estimate of required expenditures is 213M ADA, I cannot support an NCL of 200M ADA. It would contradict my stance on necessary project funding versus the cap I approve. This inconsistency guided my decision to vote NO on reducing the NCL.

Cardano requires effective marketing and improved governance support, as the current situation is far from ideal.

Investing in the ecosystem and advancing new technologies must go hand in hand to ensure sustainable growth.

Approving the NCL of 200M ADA, in my view, would mean preserving the status quo, leaving all key responsibilities to IOG while neglecting investment in the broader ecosystem. Essentially, it would restrict funding for entities that are vital to the ecosystem, just as IOG is.

An important consideration is the expected scenarios surrounding the NCL.

Both NCLs, an NCL of 350M ADA and 200M ADA, are extremes in my view.

The current NCL, set at 350M ADA, has strong support with 76% of the voting stake participating. Nearly the entire voting stake approved it. Drastically reducing the NCL from 350M to 200M ADA would be either irresponsible or overly ambitious.

What would happen next? Builders, Intersect, IOG, or others would likely submit a new governance action proposing an intermediate NCL, perhaps 250M or 300M ADA. Alternatively, multiple proposals could be submitted simultaneously.

This scenario would create an unstable environment that is counterproductive and difficult to support. Such instability undermines progress.

Moreover, the crypto community has little interest in prolonged debates about how much the Cardano ecosystem can afford to invest.

In an unstable environment, even proposing a coherent budget becomes nearly impossible.

Currently, we have an NCL of 350M ADA. Consider this likely scenario:

Intersect is expected to submit a governance action for the budget expiring in June. Meanwhile, if a new NCL of 200M ADA is approved by the end of May, the proposed budget would effectively become unconstitutional unless it is approved before the new NCL takes effect. This complicates the process and further highlights the issues with sudden, extreme changes.

Debating the NCL through governance actions is both inefficient and overly time-consuming.
It seems likely that the community's consensus would fall somewhere between 250M–300M ADA. However, no off-chain temperature check was conducted (to which the majority of the community would respond) before the on-chain vote, which led to the current NCL being approved simply to allow the budgeting process to continue.

The concept of the NCL itself is starting to feel unnecessary, as it constantly shifts based on the majority vote. If the voting stake agrees to increase or decrease the NCL, it will inevitably happen.

It’s important to emphasize that the NCL doesn’t dictate the amount that must be spent from the treasury. Every withdrawal proposal still requires approval from the community.

I would likely vote YES if the current proposal fell within the 250M–300M ADA range. If a proposal like this is submitted, I would support it, as it aligns with the budget I consider reasonable based on the proposals I have endorsed.

However, my decision isn’t final and may change depending on future developments in governance. For instance, if governance actions combine multiple proposals that result in an excessively high total cost, or if the IOG proposal is grouped with several proposals I don’t support, or one I strongly oppose, such as the Daedalus 2025 Service Enhancement, I might reconsider my stance.

If the only way to prevent a poor budget outcome is to vote for a lower NCL, I am prepared to do so. This decision is nuanced and cannot be seen in black-and-white terms.

I want to avoid a scenario where approving a lower NCL inevitably results in another GA submission. Addressing the NCL repeatedly is time-consuming and unproductive. DReps need to prioritize budget proposals instead.

A higher NCL serves no purpose if it ends up funding low-quality projects within the budget.

As a DRep, I have decided to vote YES on the second governance action regarding the setting of the Net Change Limit (NCL).
Currently there are 2 governance actions submitted regarding NCL. The first one is submitted by the community and the second one by Intersect. This creates chaos.

First GA from the community:
gov_action10ueqgzwenxr39le68n0se9peu92r7gm2846xwehh3u0ahc0qd0uqqyljxu5

Second GA from the Intersect:
gov_action1nd3t833j7v5sz65k3tp9yyvztw60sjcjgcgjr37682s3m7frwrusqmd2k80

It is logical to compare both actions and choose only one.

GA from Intersect defines the term NCL and specifies the validity period of NCL.

"The 2025 Net Change Limit will begin at the start of Epoch 532 and continue for 72 epochs, finishing at the conclusion of Epoch 604 in December 2025."

This is just a cosmetic improvement. I assume that all DReps understand the term NCL. I don't mind that the period is vaguely defined for 2025 and 2026 in the first GA.

Intersect GA is better structured, more accurate, and contains relevant links. I appreciate that.

The most important thing regarding NCL is the amount of ADA that should be set as the limit for treasury withdrawals.

The first GA wants to cap the NCL at 300M ADA while the second GA wants to cap it at 350M ADA.

In my rationale for the first GA, I mentioned that I would like to see the NCL lower, somewhere around 280M ADA. 300M ADA was acceptable to me.

350M ADA is the maximum amount I am willing to accept from my perspective. I am aware that this is a relatively high NCL. My poll shows that the NCL of 350M ADA is considered high by most respondents.

Although it is not necessary to withdraw ADA up to the NCL, there will always be a risk that the maximum possible amount will be withdrawn. My concern is that this may happen.

The cryptocurrency ecosystem is unique in that Treasury investments in the ecosystem have a direct negative impact on the market price of ADA. Entities that receive ADA will mostly sell them because they are forced to pay costs in USD. Selling pressure can grow.

If the ADA price is low in a bear market, in 2026 it may be necessary to sell a relatively large amount of ADA to obtain the necessary amount in USD. Treasury can quickly run out. Of course, it will be possible to approve the NCL for 2026, which can prevent this. It is likely that a new NCL will be proposed.

ADA is perceived as money. Their market price, or rather the capitalization of Cardano, is an important factor from a demand perspective. If Cardano does not stay in the top 10, it could prevent the adoption of the ecosystem.

Another negative impact could be the US government's disinterest in including ADA in the state stockpile. Let us keep these risks in mind.

On the other hand, without continuous protocol improvements and ecosystem development, adoption is largely limited. Cardano's attractiveness would depend only on decentralization and monetary policy.

Cardano is being built as an SC platform. As such, it depends on the growing network effect. This in turn depends on scalability.

As a DRep, I have to carefully balance the short-term negative impact on the ADA price that will harm SPOs, stakers and possibly adoption and the long-term potentially positive impact on the ecosystem.

So I would like to see the NCL set to a maximum of 280M ADA. 350M ADA is too much. Nevertheless, I decided to vote YES for this GA. Why?

A GA can be submitted at any time that will lower or increase the NCL for a given period.

Individual withdrawals are more important than NCL. DReps should carefully consider each withdrawal and assess the long-term impact. This is where savings must be made. Let's invest primarily in technology, not in meetings and discussion groups.

With a higher NCL, we have more maneuvering options. It is not necessary to invest all ADA up to NCL. Theoretically, we can lock ADA in DeFi. These are relevant reasons to have a higher NCL. I can justify to myself why I approve of a high NCL.

In addition, we need to ratify some NCL so that we can start withdrawing ADA from the Treasury. We are at the end of Q1 and NCL is still not defined.

The dilemma I have is whether to vote YES for only one GA or for both. In the previous rationale, I stated in the disclaimer that if a better GA for NCL appears, I can change my vote.

From my point of view, the community GA is more treasury-friendly, so I support it a little more. So I will not change my vote for the community GA. Let both GAs have my support. Let the better one win.

I am aware that I am contributing to the chaos. It would be better to vote for only one GA. I will monitor the feedback and read other rationales. I will respond if necessary.

At this point, I want to vote as quickly as possible and provide my thoughts.

As a DRep, I have decided to vote YES on the governance action regarding the setting of the Net Change Limit (NCL).

The Governance Action (GA) proposes an NCL of 300M ADA for 2025 and 250M ADA for 2026.

It is crucial that the NCL does not exceed the expected revenues of the Treasury. A prudent economist aims to ensure expenses remain below revenues while also building reserves for the future.

Personally, I would prefer an NCL of 280M ADA for 2025 and 230M ADA for 2026. That said, I recognize that during a bull market, we can afford to allocate more funds—potentially even using Treasury resources to buy stablecoins.

For Cardano to thrive, it must remain in the top 10 blockchain platforms in the coming years and stay competitive. Achieving this requires consistent investment, particularly in scalability.

From a long-term perspective, Cardano must also prepare for resistance against quantum computers. This will demand significant investment over the next decade, which needs to be factored into current planning.

The Intersect budget is estimated at 260M ADA—lower than the proposed NCL. I believe this budget can be reduced; however, even if it isn't, it will remain within the limits set by this GA. Therefore, the NCL will not hinder ecosystem funding.

I propose utilizing the Treasury to mint stablecoins within the Cardano ecosystem, which could generate yield and serve as an additional revenue stream. At present, ADA fee revenue does not meet expectations, and diversifying income sources is critical.

Yield generation could also be redistributed as staking rewards. If ADA could capture the success of the Cardano ecosystem, it could have a positive impact on the market capitalization.

These are the reasons I advocate for setting the NCL above the Intersect budget.

However, I do acknowledge the risks. If a new NCL is not approved for 2027, the last approved NCL—250M ADA—will remain in effect. This could result in spending exceeding Treasury income that year. Nevertheless, I am confident the community will successfully ratify a new NCL when the time comes.

In my opinion, the NCL should be calculated as a percentage of Treasury income from the previous year. For instance, if Treasury income totaled 300M ADA during the last 73 epochs and the NCL was set at 90%, the spending limit would be 270M ADA.

Important monetary parameters are currently defined as percentages, and it would be wise to maintain this convention. Additionally, such a mechanism could provide stability and predictability over multiple years without requiring frequent adjustments.

As the GA indicates, the method of setting the NCL can always be revised. I do not intend to promote my own perspective by rejecting other Governance Actions.

I appreciate that this GA originates from the community rather than from founding entities. It is encouraging to see the community assuming greater responsibility.

The proposed NCLs for the next two years are reasonable and align with long-term sustainability. It is crucial not to delay investments in ecosystem development. The sooner we approve the NCL, the better.

Disclaimer: If an alternative GA proposing a different NCL emerges and aligns more closely with my views, I may reconsider my vote. It makes sense to support only one proposal.

I voted YES for the 2025 Vision & Roadmap. I'm glad this document was created to allow the community to agree on Cardano's future direction.

The biggest emphasis is on both L1 and L2 scalability, which we all agree should be prioritized. Completing the Basho era is crucial in the context of the previous roadmap from 2017.

I am not entirely sure about building the PartnerChain Framework in addition to Ouroboros Leios, Peras, Hydra, and Midgard simultaneously.

Scalability is addressed from three sides, which might be unnecessary. I understand the importance of the PartnerChain Framework and appreciate that it's being considered.

Maybe we should focus on only 2 things now and not chase too many hares at once.

On the other hand, it's good to be prepared for all eventualities. Successful applications are starting to consider building their own blockchains, so having a framework that seamlessly connects all chains could be advantageous.

Ultimately, I don't mind that the PartnerChain Framework will be built. I see it as support for the Midnight project. I would like to see more focus on privacy directly in the Cardano protocol. If Midnight is delivered, Cardano can adopt some of the technologies once we deliver scalability.

I was pleased to see the emphasis on modular design. The Ethereum ecosystem has adopted this approach, offering high flexibility and adaptability.

Programmable Assets will bring new possibilities to the ecosystem, including minting USDC and USDT and building soul-bound tokens.

Cardano should be as flexible as possible to accommodate various use cases, even those not entirely aligned with Satoshi's ideals. Ideals and real business don't always align, and from the user's perspective, having the ability to choose is important.

The document mentions using ZK Proofs for building Bitcoin DeFi on Cardano, which is a direction worth supporting. In the Cardano ecosystem, we already have wallets that allow holding ADA and BTC, and further integration is desirable.

Supporting multiple client implementations is essential for a decentralized ecosystem. Combined with the focus on modularity, this is a good approach for future development.

Currently, staking rewards are not optimal. This issue will be addressed by introducing the min-margin parameter and modifying the pledge-benefit curve for a0.

I largely agree with the Vision & Roadmap described in the document.

However, in my opinion, the document could have included an approximate delivery time horizon and a rough estimate of costs.

I assume this will be a topic for further debate.

I decided to vote NO on decreasing Treasury Tax from 20% to 10%.

My rationale:

Cardano’s Basho era, i.e., scalability, is not complete. To complete it, ADA from the treasury will be required. Additionally, Cardano needs to attract more users, which may mean additional spending on technology and marketing.

I can imagine using ADA from the treasury to mint stablecoins or liquidity. If we could agree to reduce the T parameter, then I would rather use the 10% gained in DeFi than increase staking rewards.

Increasing staking rewards by 6 ADA for every 100,000 staked ADA makes no sense if the ADA price drops by 50-80%.

If we increase staking rewards, stakers would receive an additional 150M ADA. This would represent potential selling pressure at the end of a bull market, which is a risk to the protocol's security. We need to balance incentives and security.

We cannot predict the future price of ADA and the behavior of stakers. Cardano, including the treasury, should be prepared for the worst-case scenario. Technology development is expensive. We can't tell developers to cut their living costs in half just because the price of ADA is lower than we hoped.

One of the key pillars of Cardano is long-term sustainability. I see this as the need to have enough ADA in the treasury at least until Cardano collects millions of ADA in fees.

Treasury is not large in the context of competing projects. A few Ethereum L2s and even dapps have larger treasury than Cardano. Ethereum Foundation holds $657M in stablecoins. Ethereum is the #2 project.

The current amount of ADA in the treasury seems adequate to me considering future needs.

If we want to increase staking rewards, we need to address the problem of unclaimed rewards, which make up 55% of the virtual pot. We are talking about about 10M ADA per epoch, which is returned to the reserve. This leads to the so-called double taxation.

Instead of reducing the T parameter, I suggest thinking about changing the algorithm for calculating rewards. This will require careful analysis and proposing of CIP. This is the right Cardano way.

We should not change one parameter just because we can, but carefully consider each change to other parameters, incentives, decentralization, and security.

Reduction of the T parameter will bring a relatively negligible increase in staking rewards from my point of view. Cardano has capped supply, so it cannot compete with other PoS projects that have infinite inflation. Such projects can have higher staking rewards but at the cost of lower scarcity.

I see no reason for higher rewards for SPOs and stakers in the total amount of 2.2M per epoch when many community members claim that we do not have enough ADA in the treasury to reward DReps. I see the function of DReps as similar to the function of SPOs. This aspect should be carefully considered when talking about rewards for various actors in the ecosystem.

At this point, Intersect's proposed budget calls for 263M ADA. If we were to simultaneously reduce the T parameter, we should consider halving the budget as well. We should make sure that the income in the treasury is higher than the expenses.

We should not change monetary policy as needed. Ethereum is notorious for frequent changes, which is criticized by many. Bitcoin’s monetary policy has never changed. Let’s be more like Bitcoin than Ethereum.

Unlike Bitcoin, Cardano has a treasury. Let’s take advantage of that. Instead of changing monetary policy, let’s manage income and expenses effectively.

Treasury belongs to all ADA holders. They should be interested in Cardano's long-term success, not their short-term profit. Stakers are a mix of both groups, short-term speculators and long-term supporters. The Cardano mission is long-term in nature. Let's adapt our decisions accordingly.

Read the full rationale:

https://raw.githubusercontent.com/Satuchac/DRep/refs/heads/main/001_My%20Rationale%20for%20Approving%20the%20Cardano%20Constitution.txt