Voice of the People

Vote: YES on "Cardano Vision 2026: Human Centred, Scalable, Post Quantum Secure — IO Research"

Rationale:

Cardano's core competitive advantage is its research-driven approach. Without continued investment in consensus evolution (Leios/Peras), post-quantum cryptography, ZK infrastructure, and formal methods, Cardano loses the one differentiator that justifies its existence alongside faster, cheaper L1s. This is not optional spending — it is what makes Cardano Cardano.

CV25 delivered above targets (20% overperformance), produced 24 peer-reviewed papers, and advanced Leios, Peras, Cavefish, and ZK verification from theory to prototype. The track record supports continued funding.

I am voting Yes because rejecting this proposal would inflict more damage on the ecosystem than approving it with reservations.

However, this Yes vote comes with serious criticism on two fronts:

1. The proposal should have been split. The community asked for it. Multiple DReps asked for it. A $7.9M monolithic proposal covering 7 work packages forces an all-or-nothing decision that does not serve good governance. DReps who see clear value in post-quantum research but question the ROI of WP7 dissemination activities, for example, are forced to accept both or reject both. This is a structural failure of the proposal, not of the DReps voting No.

2. Charles Hoskinson's public response has been counterproductive. Threatening not to resubmit, warning of permanent ADA price damage, and criticizing DReps who vote No or Abstain is not how you build consensus in a decentralized governance system. A founder who responds to legitimate scrutiny with emotional pressure undermines the very governance model Cardano claims to champion. The community is not obligated to approve proposals out of fear. IO should listen to the feedback, split future proposals into independently votable components, and let each stand on its own merit.

For 2027, I expect IO Research proposals to be modular, independently votable, and responsive to DRep feedback. The research is essential. The governance approach around it needs to mature.

Vote: YES on "The first node in the browser; a Cardano USP" (Gerolamo) — HLabs

Rationale:

Gerolamo targets a capability that no other major L1 can replicate without redesigning its base layer. Cardano's eUTxO model, bounded block sizes, and deterministic Plutus execution make an in-browser fully-validating node technically viable here in a way it is not on Ethereum, Solana, or any account-based chain. If shipped, this becomes a concrete, demonstrable competitive advantage — not a whitepaper claim.

The engineering work required (succinct validation, compact checkpointing, embeddable verifiers) directly feeds into components Cardano needs anyway for trustless bridges and L2 infrastructure. Funding Gerolamo is funding that foundation.

I voted No on the previous bundled HLabs proposal (Pebble + Gerolamo). This proposal addresses that concern: the scope has been deliberately separated, and Gerolamo stands on its own merit with a focused 5-FTE, $1M budget that excludes block production and non-essential overhead.

The governance structure is among the strongest I have seen in any treasury proposal:

• Smart contract escrow (SundaeSwap treasury contracts, audited by TxPipe and MLabs)
• Independent oversight board (Carmuega, Rosa, Gianelloni) with pause authority
• Milestone-based disbursement with objective, publicly verifiable acceptance criteria
• Independent quarterly financial audit
• Automatic failsafe sweep of unused funds back to treasury

At ₳4,600,000 for 12 months and 5 FTEs, the cost is contained and the contingency buffer (15%, refundable) reflects lessons learned from prior proposals affected by ADA price volatility.

This is infrastructure that compounds: every wallet and dApp that integrates Gerolamo inherits trustless chain access. That is the kind of investment the treasury should be making.

Vote: YES on Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028

Rationale:

Peras is critical infrastructure for Cardano's consensus layer. Letting Tweag's delivery stall would directly harm the Leios roadmap and, by extension, Cardano's long-term scalability. The practical cost of voting No — losing a specialized engineering team mid-delivery — outweighs the principled objection to covering currency risk with treasury funds.

That said, this Yes vote comes with a clear expectation for future proposals:

1. No more ADA-denominated contracts without hedging mechanisms. All future treasury-funded engagements above a reasonable threshold should be denominated in stablecoins (USDCx, USDM) or include contractual volatility buffers. The treasury is not an insurance policy against ADA price fluctuations.

2. Milestone-based disbursement tied to deliverables, not lump sums released upfront. Tweag themselves acknowledged that receiving payment in milestones was part of the problem — this should become the standard, not the exception.

3. Transparent cost breakdowns per workstream. DReps need to see FTE counts, burn rates, and delivered-vs-paused scope before approving supplementary requests. A shortfall claim without auditable numbers is not sufficient.

This vote is not an endorsement of the funding structure. It is a pragmatic decision to protect ongoing critical work while demanding that the governance process prevents this situation from recurring.

Vote: NO on "Pebble & Ecosystem maintenance: TypeScript core of Cardano" — HLabs

Rationale:

This proposal bundles two components with very different value propositions, and my vote reflects that asymmetry.

The tooling maintenance component (1.5 FTEs, $300K) is genuinely necessary. Mesh, Lucid Evolution, and Midgard depend on these libraries, and hard-fork compatibility is not optional. I would vote Yes on this scope if it were submitted independently.

However, 70% of this proposal ($700K, 3.5 FTEs) funds Pebble, a second smart-contract language for Cardano. The strategic argument is sound in theory — an imperative alternative to Aiken could widen the developer funnel. But timing matters more than theory.

Cardano's current priority should be consolidating adoption around existing tools, not splitting developer attention across a second language. Aiken is still maturing, its ecosystem is still growing, and the community of Cardano smart-contract developers remains small. Adding a competing language now risks fragmenting educational resources, tooling support, and developer mindshare before either language reaches critical mass.

A second language is a valid long-term goal. It is not a treasury priority in a constrained budget environment where core infrastructure proposals (Leios, IO Research, Tweag/Peras) are struggling to reach the 67% threshold.

I would reconsider this position in a future cycle where Aiken adoption has matured and the treasury is less constrained.

Note: I am voting Yes on the separate Gerolamo proposal from the same team (HLabs), which I evaluate as delivering a unique competitive advantage that no other L1 can replicate. That vote should not be read as a blanket endorsement of all HLabs proposals.

Again another funding proposition related to Marketing. It is moment to fund new projects or developments, not marketing

As I mentioned in other proposals, the visibility of Cardano will grow as we invest in improving the protocol, making it easier for everyone and with more features.

The cost is too high keeping in mind the Regulatory complexity that it will have (different states different regulations that might change over time), and reliance on unproven waitlist conversion
Too risky

It's not the moment to focus on this kind of experiments, specially when relying on "donor engagement" and tax incentives for the donors (that might change eventually)

To drive adoption is critical, specially if it's thanks to development o maintenance of the projects that already are in Cardano. Looks quite transparent proposal.

Currently, Cardano should prioritize technical development that drives innovation and organically builds brand reputation over costly marketing. We can focus on "Brand Marketing" once we have a broader-functionality ecosystem.

Currently the UX in Ledger is clear enough. It's not the moment to spend in this.

I see positively everything that helps to simplify/ enhance the development in Cardano, specially if it is not expensive and comes from a trusted team.

It is important to maintain critical Rust tooling and enhance developer productivity

This kind of technical development is what we need. IOR has proven their skills and good faith already. It's critical for advancing Cardano’s scalability, sustainability, and interoperability, but also for continue writing papers that helps not only Cardano, but also Cryptos in general.

HW maintenance ensures user security. I there is no compatibility with them community would have a huge problem.

It's a good step in the good direction in order to decentralize API access via Icebreakers, boosting SPO revenue and developer usability

For now, I understand we should focus in one Governance tool, focusing funds in one.

It is necessary for maintaining critical Nix-based infrastructure, ensuring node compatibility and reliability with future developments

This ones drives critical scalability (Leios, Hydra), dApp security (Plutus tools), and node efficiency. It but need budget clarity and prioritization to mitigate execution risks, but it's important to fund reliable and trustful developers.

This proposal should proceed for its innovative EUTxO rollups. It might bring a great improvement in Cardano's On-chain transaction efficiency

GovTool is Cardano’s primary governance interface, critical for CIP-1694 and Voltaire. This would ensures accessible governance, supports DReps, users...

Since this is the first time the community is fully in charge of treasury use, it makes sense to start with a lower limit than proposed before (>=300) and increase it later if needed.
Control and understanding of our power (rights) is vital.

Hard no for now. We are still in a moment where a treasury is vital to incentivize improvement, development and other apps that will increase the use and the security of the protocol. To cut the incentive by half would increase the staking rewards a 12%, but decrease the incentive by half for development.

The live development incentivized by the self-sustainable funding (treasury) it's one of the key differences between Cardano and other cryptocurrencies, making this one non-dependant on centralised entities.

WP2 is the non-negotiable core of this proposal. Someone has to steward the Haskell node repositories, coordinate hard forks, and lead incident response when the chain partitions — as happened in November 2025. Intersect has done this. Voting No means those functions go unmanaged, which is not an acceptable outcome for a protocol in active development.

WP1 and WP3 are harder to evaluate at this level of detail, but the reduction from last year's ask ($7.875M to $6.35M) reflects at least some fiscal discipline, and the audit by Appold provides an external check.

However, I want to register a structural concern that this proposal does not resolve: Intersect simultaneously administers treasury withdrawals on behalf of the community and receives treasury funds as a vendor. That is a conflict of interest by design. It has been tolerated because no alternative coordination layer exists yet, but it should not be normalized. The ecosystem needs to work toward a governance structure where the entity administering treasury funds and the entities receiving them are structurally separated.

This Yes vote is for the functions, not an endorsement of the current structure.

Wirex is not a speculative build. It is an existing, regulated payments business with 7 million users, $20 billion in processed volume, and Visa Principal Member status. The infrastructure being funded — smart contract settlement, account abstraction, stablecoin-connected banking rails, and Visa card issuance linked to on-chain balances — is open-source and reusable by any wallet or fintech building on Cardano. That is the right model: a proven executor delivering shared infrastructure, not a proprietary product capturing ecosystem value.

Real-world payment rails are a legitimate gap in Cardano's stack, and this proposal fills it with a team that has already shipped at scale elsewhere.

However, this proposal is notably thin on milestone detail compared to the standard set by other proposals in this cycle. I am voting Yes on the strength of Wirex's track record and the open-source commitment. If a future proposal from this team — or any team — arrives through the Intersect budget process with this level of detail and no independently structured milestones and acceptance criteria, my vote will be No regardless of the executor's reputation.

This is not a proposal I fundamentally oppose. Strike Finance has demonstrated real traction, the liquidity flywheel thesis is sound, and Cardano-native stablecoins and derivatives infrastructure are necessary for long-term ecosystem competitiveness.

However, the timing is wrong. We are in a bear market cycle where USDM depeg risk is materially elevated. Deploying 9,000,000 ADA of treasury capital into a stablecoin position — at a moment when stablecoin liquidity on Cardano is still shallow and under stress — introduces a risk profile that is inappropriate for treasury funds at this stage of the cycle. A depeg event under current conditions is a plausible scenario, not a tail risk.

I would reconsider a productive treasury deployment of this kind in a future cycle, when Cardano-native stablecoins have demonstrated sustained peg stability at greater scale and market conditions are more favorable.

The current process of pitting individual proposals against each other across unrelated domains is structurally broken, as this governance cycle has demonstrated. A budget-first, category-based approach with expert evaluation is the right direction for Cardano treasury governance to mature.