Cardanians

We support this proposal because Plutarch and Ply are open-source developer tools with clear public-good value for Cardano.

They are used by builders across the ecosystem and help maintain reliable smart-contract development, serialization, compatibility, and developer experience as Cardano evolves.

We also recognize MLabs’ long-standing technical contribution to the ecosystem.

For future renewals, we would like to see clearer maintenance KPIs, adoption reporting, issue-resolution metrics, and a more detailed split between maintenance and new enhancement work.

We recognize Daedalus as an important open-source public-good wallet and Cardano’s full-node desktop wallet option. It supports self-sovereign access without relying on third-party APIs or hosted backends, which has value for ecosystem resilience.

However, we do not believe the case for continued treasury funding is strong enough in the current form. Daedalus serves a relatively small user base compared with light wallets, and the proposal would benefit from clearer evidence of current demand, usage trends, support load, release cadence, and long-term sustainability.

We also want clearer justification of which improvements are essential maintenance versus new feature development, and how future funding needs should be handled if Daedalus remains a niche wallet.

This is not a rejection of Daedalus. It is a decision that the public-good value is real, but not sufficiently justified against current usage and competing treasury priorities.

We recognize Blockfrost as important developer infrastructure that has helped many Cardano builders.

However, we do not support this proposal in its current form. The proposal itself shows how dependent the ecosystem already is on Blockfrost. Funding that dependency directly from the treasury may preserve a useful service, but it also risks reinforcing centralization around one access layer.

We would prefer a broader infrastructure strategy that supports multiple providers, open standards, self-hostable tooling, and reduced dependency on any single service.

We are also not fully convinced by the long-term sustainability model after the 18-month transition. For this size of request, the future cost structure and recurring funding risk should be clearer.

We support this proposal because not every smaller Cardano project or dApp should have to go through the full scrutiny of all DReps individually.

Many teams building on Cardano need a more practical funding path, where their needs can be assessed by people with relevant domain expertise, ecosystem context, and direct understanding of what it takes to build and maintain products on Cardano.

A dedicated council that includes both expert peers and DRep representation is better suited to evaluate smaller validated builders than a broad, proposal-by-proposal vote from the entire DRep set. This can reduce governance overhead, improve funding efficiency, and allow DReps to focus on larger strategic treasury decisions.

The key requirement is that such a body remains transparent, accountable, and subject to clear rules, reporting, conflict-of-interest protections, and measurable outcomes.

We support this proposal because it connects Cardano to a real existing ticketing business with users, events, revenue, and a clear enterprise adoption path.

Phase 1 is already live on mainnet and was funded by Sellout. Phase 2 adds a secondary marketplace, royalty enforcement, anti-scalping controls, wallet onboarding, organizer tools, audit, and public launch. The proposal also includes concrete Cardano-specific targets such as NFT tickets, on-chain interactions, new wallets, and ticket revenue settled on Cardano.

We also appreciate the treasury repayment mechanism. A 25% fee share until the treasury is repaid, followed by a smaller permanent fee, is a stronger value-capture model than most commercial adoption proposals provide.

We would still like clearer public-good guarantees around reusable infrastructure, licensing, and how other ticketing operators could use the system independently. However, the combination of existing traction, milestone-based delivery, enterprise use case, and treasury repayment makes this proposal worth supporting.

We support the strategic direction of bringing BTC liquidity and BTCfi primitives to Cardano. Alchemy is an interesting concept with useful elements such as launch liquidity, public dashboards, reporting, and profit/yield return to the treasury.

However, we are not comfortable voting YES in the current form. Our main concerns are treasury exit rights, custody and administrator certainty, regulatory risk, ADA price protection, market validation, and public-good guarantees.

The launch liquidity principal is not automatically returnable and may require a later governance action. The FIRE/ICE structure is financially complex and should have stronger legal and risk review before a larger treasury commitment.

This is not a rejection of BTCfi or Alchemy, but a ₳10M withdrawal into a novel structured-product protocol needs stronger safeguards and clearer treasury-return mechanics.

Fast, trustless verification of Cardano state is important for reducing reliance on centralized APIs and improving the experience for nodes, wallets, light clients, bridges, and ecosystem tooling. Mithril strengthens Cardano’s infrastructure layer without being tied to a proprietary commercial product.

We also see value in ensuring continuity as Mithril transitions from IOG-funded development to community-governed funding through Intersect.

That said, future funding should include clearer milestones, adoption metrics, roadmap reporting, and evidence of real usage across wallets, nodes, light clients, and infrastructure providers.

The main concern is that this is a very large withdrawal for Intersect’s core coordination and technical stewardship functions, but the proposal does not make the marginal value clear enough. A significant part of the scope appears to overlap with Intersect’s normal role as the ecosystem coordination body.

If these functions are essential to Intersect’s mandate, they should be presented with much clearer operational detail, measurable deliverables, spending breakdowns, and boundaries against other Intersect-related withdrawals.

We are also concerned about continued fragmentation of Intersect funding across multiple proposals. Intersect and its committees have already received significant treasury funding, and the ecosystem needs a clearer picture of total Intersect cost, recurring obligations, and what each additional withdrawal specifically adds.

This is not a vote against governance coordination or technical stewardship. It is a vote against approving another large operational withdrawal without stronger budget transparency, clearer accountability, and better separation from Intersect’s core budget.

The main concern is overlap with Intersect’s core role and budget. The TSC is an Intersect standing committee, and much of the proposed work appears to fall under Intersect’s normal technical governance and coordination function. If this work is essential, it should be clearly included and justified within Intersect’s main operating budget.

The proposal also lacks enough clarity on concrete deliverables, measurable outputs, and marginal impact. It is not clear enough what new value the treasury is buying or how this avoids duplicating already funded Intersect activities.

The independent technical review component may have value, but it would be better submitted as a narrower standalone proposal with clear scope, reviewer selection, conflict-of-interest rules, and reporting.

We support this proposal because hardware wallet compatibility is security-critical infrastructure for Cardano users and builders.

Ledger and Trezor support must be maintained continuously as Cardano, wallet software, firmware, and vendor requirements evolve. If this layer breaks, users can lose secure access to staking, governance, payments, DeFi, and dApp interactions.

This is not a new commercial product. It is maintenance of an already-proven access layer: compatibility updates, supporting libraries, tooling, developer support, release support, and vendor-required assurance work.

The request is reasonable for the scope, and the work fits the type of ecosystem infrastructure the treasury should support.

We recognize the strategic value of real-world payments, card access, and stablecoin rails for Cardano.

However, the proposal is too high-level for a multi-million ADA withdrawal. It lacks enough detail on budget allocation, milestones, compliance dependencies, maintenance, and Cardano-specific adoption targets.

The public-good component is also not clear enough: what will be open-source, under what license, and whether other Cardano builders can reuse it independently of Wirex.

Because this mainly supports commercial payment infrastructure without strong enough public-good guarantees or ecosystem value capture, we vote NO.

We originally voted YES on Tx3 during the Intersect Budget process, and we maintain that position.

Tx3 addresses a real developer-experience problem on Cardano: each dApp protocol often requires custom integration work, which increases friction for wallets, builders, tooling providers, and eventually AI agents. A shared open API layer for Cardano dApp protocols can make integrations more reusable, composable, and easier to maintain.

We also recognize TxPipe’s strong delivery record and the fact that this proposal builds on their broader open-source infrastructure stack. While Tx3 is more forward-looking than pure maintenance proposals, it has clear public-good potential if adopted by multiple protocols and developer tools.

We would still like to see strong reporting on protocol onboarding, real developer usage, SDK adoption, MCP usage, and long-term maintenance needs. However, we believe the strategic value and open infrastructure nature of the work justify support.

We originally voted YES on Pallas during the Intersect Budget process, and we maintain that position.

Pallas is core open-source infrastructure for the Cardano developer ecosystem. Rust libraries for Cardano primitives are used across multiple projects and help reduce duplicated implementation work for builders, tooling providers, and node-related initiatives.

We also recognize TxPipe’s strong delivery record and the importance of maintaining shared infrastructure that many other ecosystem components can build on.

We would still like future renewals to include clearer maintenance KPIs, adoption reporting, issue-resolution targets, contingency rules, and long-term sustainability logic. However, Pallas has clear public-good value and fits the type of work the Cardano Treasury should support.

Oura is open-source, reusable infrastructure that helps developers and infrastructure operators process Cardano blockchain events without building custom data pipelines. We recognize its value, ecosystem usage, and TxPipe’s strong delivery record.

However, we are still not fully comfortable voting YES. The proposal would benefit from clearer maintenance KPIs, usage and adoption reporting, issue-resolution targets, contingency rules, and long-term sustainability logic.

This is not a rejection of Oura or TxPipe. It is a signal that even valuable open-source maintenance proposals should come with clearer success metrics and reporting.

We are changing our position from the initial NO during the Intersect Budget process to ABSTAIN.

UTxO RPC is open-source, reusable, ecosystem-wide infrastructure, and we recognize both its value and TxPipe’s delivery record. This is much closer to the type of work the Cardano Treasury should support.

However, we are still not fully comfortable voting YES. The proposal would benefit from clearer maintenance KPIs, usage/adoption reporting, issue-resolution targets, contingency rules, and long-term sustainability logic.

This is not a rejection of UTxO RPC or TxPipe. It is a signal that even valuable open-source maintenance proposals should come with clearer success metrics and reporting.

We originally voted YES on Dolos during the Intersect Budget process, and we maintain that position.

Dolos is open-source, reusable infrastructure that provides a lightweight alternative for accessing Cardano chain data. It can reduce infrastructure costs, improve developer experience, and give builders more flexible options than running heavier data stacks.

We also recognize TxPipe’s strong delivery record and the public-good nature of the work. This is the kind of open-source ecosystem infrastructure that can reasonably fit treasury support.

We would still like future reporting to include clearer maintenance KPIs, usage metrics, issue-resolution targets, contingency rules, and long-term sustainability logic. However, these concerns do not outweigh the value of maintaining Dolos.

We recognize Strike Finance as a strong Cardano DeFi protocol with real usage.

However, this proposal asks the treasury to convert ADA into USDM and deploy it as liquidity into one commercial protocol. That creates market, stablecoin, smart-contract, custody, and ADA opportunity-cost risk.

The value capture is not strong enough. The treasury takes the downside risk, while much of the upside benefits Strike and its ecosystem. The proposal lacks sufficient first-loss protection, guaranteed return, revenue sharing, or broader treasury investment standards.

This is not a vote against Strike. It is a vote against using public funds as concentrated liquidity for a single protocol without stronger safeguards.

We have a lot of respect for Eternl and the team behind it. Eternl is one of the strongest user-facing products in the Cardano ecosystem and, in many practical areas, has outcompeted wallets backed by founding entities or larger institutional support.

Overall, the proposal is well presented, the requested amount is reasonable compared with many other treasury withdrawals, and the team has clearly delivered value to Cardano users over several years.

However, we are abstaining because we do not believe the Cardano Treasury should generally serve as a funding source for commercial proprietary infrastructure. Eternl is a privately operated product, the main UI will not be open-source, and the proposal is mainly operational funding to maintain and develop the product while it transitions toward paid plans.

What would make us reconsider is a stronger public-good component. For example, if Eternl open-sourced core parts of the wallet, delivered reusable infrastructure for the wider ecosystem, or created clearly accessible public-good tooling beyond its own commercial product, the case for treasury funding would be much stronger.

In our view, Eternl may be an excellent fit for a vehicle such as the Orion Fund. It is a proven Cardano product with strong usage, a capable team, and clear commercial potential. A venture-style funding model could help Eternl survive difficult market conditions while also acting as a growth engine, without creating the same expectation that the public treasury should fund proprietary commercial infrastructure.

For these reasons, we abstain. We respect the team and see the value of Eternl, but we are not convinced that this proposal belongs directly in the Cardano Treasury in its current form.

We support reimbursing the Ikigai Info Action deposit because the 100,000 ADA loss appears to have resulted from a protocol/tooling issue during early governance, not from normal governance risk.

The request is limited: 100,000 ADA for the lost deposit plus 3,000 ADA for missed staking rewards and opportunity cost.

This should not set a general precedent for reimbursing failed or expired governance actions. We support it only as a specific reimbursement for a technical issue.

We support the need to reform Cardano treasury governance. The current process is too fragmented, reactive, and difficult for DReps to evaluate consistently. Large and unrelated proposals are often assessed in isolation, without clear categories, shared priorities, or uniform standards for transparency, accountability, and milestones.

However, we are not ready to fully support this direction as presented. Treasury reform must not shift too much decision-making power away from DReps and the community toward expert commissions or execution bodies. Expert review can be useful, but final accountability should remain with elected governance actors.

Any improved model must include clear conflict-of-interest rules, transparent appointment and removal processes, public reporting, budget limits, and consistent requirements for all proposers, including founding entities.

We also believe this discussion should continue in a more structured way. The emerging DRep DAO aims to address some of these issues by bringing DReps together to discuss treasury standards, proposal evaluation, budget categories, and governance improvements. We encourage DReps to join the discussion and help design a better model: https://x.com/DRepDAO

For these reasons, we abstain. We agree that reform is needed, but the future model must preserve DRep accountability, improve transparency, and keep treasury governance community-controlled.

We are in the YES camp on Hydra. We consider Hydra strategically important, and we believe this is among the proposals that Cardano should seriously support and ultimately pass. We are not abstaining because we question the value of Hydra or the need to continue developing Layer 2 infrastructure.

The only reason we are not voting YES is the continued black-box level of transparency repeatedly presented by Input Output when requesting public treasury funds.

For a multi-million ADA withdrawal, the proposal should provide a much clearer breakdown of personnel, contractors, infrastructure, audits, testing, DevRel, project management, and contingency. Strategic importance should not lower the standard of public-fund accountability. If anything, major ecosystem actors should be held to a higher transparency standard.

We are also missing a clearer long-term funding picture. It is not fully clear whether this is a one-time production-hardening effort or the beginning of recurring treasury-funded Hydra maintenance. If Hydra is critical infrastructure, Cardano needs to understand the expected annual maintenance cost and what should be funded as a public good.

Future reporting should also focus on measurable production outcomes: public benchmarks, active integrations, volume processed through Hydra, operational reliability, developer usage, and measurable impact on L1 activity or fees.

For these reasons, we abstain. Hydra should move forward, but repeated black-box budget transparency from IO should not become the normal standard for Cardano Treasury funding.

The current minimum equals the current number of CC members, which makes governance fragile. A single resignation, expired term, or inactive seat can bring the CC below the required minimum and block actions that require CC approval.

This change should not be seen as making 5 members the ideal committee size. Cardano should still aim to maintain 7 active CC members, and a larger committee can be discussed in the future once incentives and candidate availability improve.

We recognize that a smaller minimum increases the influence of individual CC members and can make blocking easier. However, the risk of governance inoperability under the current setting is greater than the risk of this limited reduction.

The parameter is within guardrails, has gone through the Parameter Committee process, and can be changed again later if needed.

We recognize Tweag’s long-standing contribution to Cardano and appreciate that the revised proposal has significantly narrowed the scope compared with the original version. The workstreams around Peras, conformance testing, and History Expiry are strategically relevant and could become important for Cardano’s long-term protocol roadmap.

However, we are not convinced that this withdrawal is critical right now at the requested scale.

Our main concern is that some of the key measurable outcomes are still not concrete enough. For History Expiry, the expected storage reduction for standard relay and block-producing nodes is still part of the investigation. For Peras, the expected improvement in settlement time is still based mainly on research and simulations, with stronger real-world benchmarks expected only after the 2025 work is further completed.

We also understand the argument that Peras may be important for Midnight and future partner chains. If formally confirmed, that would be a strong reason to increase the urgency of this work. However, we have not seen any written confirmation clearly stating that Peras is a hard requirement for the Midnight bidirectional bridge, nor a clear timeline showing why this specific withdrawal must be approved now.

This is not a vote against Tweag or against Peras. It is a signal that we need stronger evidence on timing, urgency, expected outcomes, and dependency validation before confidently supporting an 18M–20M ADA withdrawal under current market conditions and competing treasury priorities.

We are abstaining because the work is relevant, but the case for funding it now at this scale is not yet fully persuasive to us. We would be open to reconsidering once the 2025 work provides clearer benchmarks, History Expiry impact is quantified, and the Midnight / partner-chain dependency is formally validated.

Rare Evo has been meaningful for the Cardano community, and we do see value in giving builders, DReps, and community members a place to meet. We would also enjoy seeing many familiar people there again.

However, we do not think a ₳2,750,000 treasury sponsorship is the right use of funds in the current environment. Crypto attention is low, and events like this mostly speak to people who are already inside the ecosystem. Cardano’s bigger challenge is reaching new users, businesses, developers, and institutions outside the existing crypto bubble.

We still support community gatherings, but they need to be much leaner and more targeted: smaller meetups, builder sessions, side events, online showcases, or low-cost regional formats. At this budget level, we would need stronger evidence of concrete outcomes beyond visibility and community presence.

This is a highly technical protocol-parameter proposal, so we rely heavily on the review process and technical validation behind it. The change was proposed by experts through Intersect’s Parameter Committee, reviewed and confirmed by the Technical Steering Committee, benchmarked against the reference implementation, and already enacted on SanchoNet, Preview, and Preprod testnets. Unless we hear negative technical feedback from qualified reviewers, we consider this parameter change to be as well validated as reasonably possible.

We see a potential value in decentralized identity, traceability, stablecoin rails, credit access, and real-world data anchored to Cardano. These are the kinds of use cases that could make Cardano useful outside the crypto-native ecosystem.

However, the proposal is not persuasive enough to justify a 10,000,000 ADA treasury request. After reading the proposal twice, we still can't tell who is accountable for execution. For a proposal of this size, DReps need a much clearer operational budget, ownership structure, line-item allocation, and responsibility map.

We are also concerned about the economic logic behind the projected Cardano impact. The proposal appears to rely on large L1 transaction numbers to justify its contribution to Vision 2030 KPIs, but for the business model to be sustainable, the high-volume parts of the system would likely need to be batched or moved to L2. The infrastructure layer, such as repeated satellite or verification updates, is exactly the part where batching is most rational. If those events are batched, the expected L1 transaction volume drops dramatically, which weakens the case that this proposal can generate enough on-chain activity to justify the spend.

This creates an unresolved tension: either the system produces high L1 transaction volume, which may become economically expensive for the operator, or it optimizes costs through batching/L2, which reduces the L1 transaction impact used to justify the treasury request. The proposal does not clearly reconcile this trade-off.

Finally, treasury funds may be used to scale infrastructure that later becomes a monetized commercial platform, without a clear repayment or value-capture mechanism for the Cardano Treasury. Indirect benefits such as transactions, TVL, stablecoin usage, and reputation matter, but they are not the same as a clearly defined return.

This may become a valuable real-world adoption case, but as submitted, it carries too much execution, coordination, and economic-risk uncertainty for the treasury.

The core issue is that CCI V1 was presented as a milestone-based structure over a period of up to 24 months and included integration work plus related costs such as deployment, licensing, maintenance, and infrastructure. CCI V2 now asks for a “Year 2” contracted cost and a new 12-month maintenance/enhancement program covering categories that appear to substantially overlap with what V1 was expected to cover.

Before any second withdrawal can be considered, DReps need a full reconciliation of V1: how much has been spent, how much is committed, how much remains, which deliverables are actually complete, which maintenance obligations were already covered, and why the original 24-month budget is no longer sufficient.

We understand that vendor-level pricing may be confidential. But that does not prevent a clearer anonymized breakdown separating vendor/licensing costs from Cardano-side engineering, infrastructure operations, support, tooling, administration, and contractor work. Asking DReps to approve another ₳23M without resolving these questions is not acceptable treasury governance.

We strongly value Eternl’s contribution to Cardano and agree that wallets are critical infrastructure that need ongoing maintenance, hard-fork readiness, CIP implementation, governance compatibility, and security updates.

However, we are not fully comfortable funding a broad commercial wallet roadmap from the treasury. We have doubts that a Pro subscription will yield enough to make Eternl self-sustainable at this scope, and similar user-support models have already been partially tested before. If the Pro plan can work, it should be tested immediately; if not, Eternl should a) find another revenue stream, b) reduce costs, or c) open-source important components and then request broad treasury support.

We would support a smaller scope focused on maintenance and protocol-critical work. But as submitted, we are not ready to support full team funding for a commercial roadmap, so we abstain. It is not a hard NO, but due to the above-mentioned arguments, we can't vote YES either.

Scalus is technically serious and the proposal is relatively transparent, but the market-demand signal is not strong enough for an ₳8.5M ask. Aiken is currently the dominant go-to smart contract platform in Cardano, while Plutus is now preferred by a smaller group; Scalus appears to face a similar adoption challenge. The proposal’s own targets are still modest: 5 external teams and 2 Scalus-owned chain-access deployments. We would prefer a smaller adoption-validation proposal first.

We agree that open-source maintenance is a real issue for Cardano. Critical libraries, tooling, SDKs, indexers, CI infrastructure, and other shared dependencies need sustainable support. The proposal is also more structured than many treasury asks: it defines work packages, advisory councils, dependency audits, bus-factor analysis, maintainer retainers, mentorship programs, dashboards, and return clauses for unused funds.

However, we are not comfortable approving 12,000,000 ADA over 36 months to establish a new funding and operational layer as a direct treasury withdrawal. This is a large multi-year commitment, initially led by one proposer and transitioning to a new legal entity that does not yet exist. Before Cardano commits to this scale, the model should be proven through a smaller pilot or evaluated through the Intersect budget process alongside other open-source maintenance and tooling proposals.

A better approach would be a one-year pilot coordinated with existing or emerging structures such as Cardano Tooling DAO or the Intersect Open Source Committee. Our understanding is that this initiative aims to take over part of the open-source tooling sustainability role from the Intersect committee. If that is the case, we would rather see it integrated into one of those structures instead of creating a separate independent organization from day one.

We would be open to supporting a revised version with a smaller initial scope, a clearer proof-of-concept phase, and stronger alignment with the wider Cardano funding architecture. As submitted, the idea is promising, but the scale and institutional commitment are too large for a first direct treasury withdrawal.

We recognize the value of Cardano’s research culture and the importance of topics such as post-quantum security, scalability, ZK, incentives, governance, identity, and human-centred design. However, this proposal, with its accountability structure, is not strong enough for a withdrawal of this size.

The main issue is not whether the research topics are useful. The issue is whether this should be funded as one large treasury withdrawal. The proposal bundles many strategic domains together and overlaps with core roadmap areas and other IO-led workstreams, including scaling, Leios/Peras, L2/ZK, Babel fees, governance, and protocol evolution. These are areas where founding entities were expected to use their long-standing resources to advance the core roadmap, rather than treating the treasury as the default continuation fund.

We would be open to a revised version that separates the highest-priority research streams, reduces bundling, adds stronger price discovery, and ties funding to clearer acceptance evidence and downstream Cardano value. As submitted, we cannot support this withdrawal.

Our previous position on the broader Pebble + Gerolamo – HLabs 2026 Budget was ABSTAIN, mainly because it bundled several important streams together and we preferred a broader RFP/tender-style approach for alternative nodes and core tooling. The core concern remains: node and client diversity should eventually be funded through a more strategic ecosystem-wide process, because every new implementation can create long-term maintenance obligations.

However, this new proposal is materially cleaner and easier to evaluate. It is focused specifically on Gerolamo, asks for 4,600,000 ADA, discloses 5 FTE over 12 months, and narrows the scope to a browser-based validating node and dApp/wallet API surface. This is a clearer and more accountable structure than the previous bundled proposal.

We also see a strong public-good argument. Reducing wallet and dApp dependence on centralized API providers is directly aligned with Cardano’s decentralization goals, and a browser-based validating node could become a unique Cardano advantage if adopted. The proposal still carries adoption risk, but given the improved scope clarity, explicit FTE model, milestone structure, and strategic value for trust-minimized dApps and wallets, we are willing to support it.

We like the idea as a commercial real-world adoption project, but this looks more like a sector-specific business rollout than a broad Cardano public infrastructure. For a 2,400,000 ADA treasury ask, we would need stronger budget transparency, team/FTE detail, milestone acceptance evidence, confirmed customer commitments, and a clearer public return to Cardano.

We would suggest exploring more suitable routes like membership as a company in CB DAO, funding via the Orion Fund, or checking whether Intersect grants could help co-fund the project. As submitted, we do not think this should be funded directly from the treasury.

We recognize Tweag’s long-term contribution and the importance of the proposed work. However, this is a very large request: ₳39,787,316 / $9,946,829 for 17 work packages across 9 infrastructure areas. At this scale, the proposal needs much stronger budget transparency, modularity, and work-package-level accountability.

The disclosed $176/hour rate is useful, but accepting it as a treasury baseline would set a risky precedent. A rate at this level requires extremely strong justification: named team, FTE allocation, milestone payment amounts, and concrete acceptance evidence.

This would be a good case for an RFP/tender experiment before settling on such rates as a standard for core infrastructure work. We are open to a revised version with clearer modularization, stronger price discovery, and more detailed milestone gates, but we cannot support this withdrawal as submitted.

NO on the upgrade. We support the baseline Platinum proposal, but we are not convinced that the additional 1,768,167 ADA / $424,360 for the Title upgrade is justified. The baseline already provides the core value: builder access, booth/stage presence, lead scanning, content support, and TOKEN2049 exposure.

The top-up mainly adds premium visibility: a 15-minute mainstage keynote, larger booth, press/media benefits, branded lanyards, a protein shake station, and a few extra invites/tickets. These may help, but the marginal ROI over Platinum is too uncertain for additional treasury spend. Therefore, we vote NO.

This is not an automatic YES. We were leaning between ABSTAIN and YES, because this is still a sizeable marketing/BD spend and it is difficult to prove in advance that conference presence will translate into concrete adoption, partnerships, users, or on-chain activity.

That said, this revised proposal is much more focused and proportionate than the earlier bundled version. The ask is 3,303,750 ADA / $792,900, the sponsorship was reduced from Title to Platinum, and the proposal is now directly centered on giving Cardano builders access to TOKEN2049 through up to 30 builder tickets, booth/stage presence, lead scanning, media/content support, and exposure to a 25,000+ attendee audience.

We also appreciate the defined KPIs, Intersect-administered smart-contract funding, third-party assurance, oversight, dashboard reporting, and refund conditions. While some KPIs are still proxy metrics, the structure is materially improved.

Cardano needs to be visible where serious builders, investors, exchanges, institutions, and partners already gather. Given the reduced scope, clear builder focus, and EMURGO’s Singapore presence and prior TOKEN2049 experience, we are willing to give this proposal the benefit of the doubt and vote YES.

We are voting ABSTAIN on the Revised Cardano Summit 2026 Singapore proposal.

The revised version is clearly stronger: it is decoupled from TOKEN2049, reduced by 22% to 7,800,000 ADA / $1.95M, includes clearer KPIs, a detailed budget, oversight, refund conditions, and CF increased its internal contribution to $380,000.

However, we are still not ready to vote YES. Even after the reduction, this remains a large treasury-funded event subsidy. The Summit is still far from self-sustaining, with a $450,000 revenue target against a $2.263M gross budget, and 6,240,000 ADA is available at kickoff before the event is delivered.

I understand the timing constraints and why the proposal was submitted outside the regular budget process. Still, I’m not convinced that renting expensive event space is the only, or necessarily the most efficient, path to institutional adoption. Cardano needs institutional outreach, but we should compare this against cheaper and more targeted formats: smaller invite-only meetings, side events, direct BD trips, private roundtables, or co-hosted partner events.

My abstain recognizes the improvements, but I would like to see a stronger sustainability path and clearer evidence that this format produces concrete ecosystem outcomes.

I’m voting NO because ₳ 12 million is a major treasury allocation, and the proposal still does not provide an auditable cost model and acceptance-evidence structure commensurate with that size. The work may be valuable, but public funding at this scale should include explicit staffing/FTE counts and rate assumptions per workstream, clear deliverable ownership, and artifact-driven milestone acceptance evidence (what will be published, how it will be tested, and what constitutes completion) so governance can judge cost efficiency and delivery quality. As a governance principle, core roadmap-class work from founding entities was expected to be funded primarily from their long-standing resources (including genesis allocation), and the treasury should not become the default completion fund unless proposals meet an exceptionally high standard of transparency and price discovery. Finally, we are giving a process penalty for bypassing the Intersect Budget Process, which was specifically designed to address the gap in the process between proposers and Dreps. Bypassing the Intersect budget mechanism undermines comparability and price discovery for a major protocol spend, and founding entities should set the example by using the improved process rather than routing around it.

I’m voting NO because this request combines two fundamentally different things into one treasury withdrawal: “new infrastructure build-out” and an ongoing operational subsidy model. Even if both are individually arguable, bundling forces an all-or-nothing decision and prevents governance from approving the forward-looking component while rejecting the subsidy component, which is not acceptable at multi-million-ADA scale. Treasury subsidization of an existing service also requires exceptional transparency: independently verifiable justification for dependency claims, a clear transition plan away from recurring subsidy, and a cost model that can be audited and benchmarked. Process penalty: bypassing the Intersect budget mechanism undermines price discovery and comparability and should not become normal for large infrastructure and operations spends.

This proposal is more structured than many commercial asks: four gated phases, explicit validation/audit steps, milestone-based disbursement via Intersect’s contract framework, and refund/termination conditions. It still asks the treasury to underwrite a commercial expansion initiative where downside risk is primarily socialized while upside relies on future execution and EBITDA-based repayments. The repayment structure (20% of EBITDA after an initial period, followed by a 5% perpetual return) is directionally better than a pure grant, but it depends on assumptions that cannot be verified at approval time and therefore needs particularly strong price discovery, competitive comparison, and enforcement detail to justify a multi-million-ADA allocation. In addition, the proposal does not disclose the actual staffed delivery team size/FTE allocation; the “seven people” listed are governance/advisory participants (4-person Product Committee, 3-person Advisory Board), with the Product Committee explicitly pro-bono, which is not a substitute for an auditable execution resourcing plan. Process penalty: bypassing the Intersect budget mechanism weakens comparability and eliminates a much-needed feedback loop; for a request of this size, this should be evaluated through a structured budget/RFP route or an investment-oriented vehicle designed for commercial risk. Happy to revisit this decision and vote yes if the above-mentioned points are implemented.

I’m voting Abstain because I accept the premise that higher assurance and verification tooling strengthens long-term security and trust, but the proposal does not provide sufficient budget transparency and measurable success criteria to justify treasury spending at a multi-million-ADA scale. The document makes the case for value, but for public funding this size I expect a clear mapping of “who delivers what” (named teams/roles), explicit FTE counts and rate assumptions, and concrete milestone acceptance evidence that can be independently verified rather than broad work packages and high-level claims about impact. I also want quantified KPIs/baselines tied to milestone gates (e.g., measurable adoption/usage of the delivered tooling, integration targets, and outcomes that can be observed over time). Finally, we are giving a process penalty for bypassing the Intersect Budget Process, which was specifically designed to address the gap in the process between proposers and Dreps. Bypassing the Intersect budget mechanism undermines comparability and price discovery for a major protocol spend, and founding entities should set the example by using the improved process rather than routing around it.

I’m voting NO because a request of this size for core, roadmap-adjacent protocol/economic-layer work is not presented with an auditable cost model or strong enough delivery evidence standards to justify treasury deployment. The proposal is directionally meaningful, but it relies largely on category budgeting rather than the level of transparency expected for multi-million-ADA public funding: explicit named delivery team composition, FTE counts and rates by workstream, and artifact-driven milestone acceptance criteria (what will be published at each gate, how it will be tested/verified, and what constitutes completion). This matters because the workstreams sit at the economic core of the platform. Mistakes or partial delivery create ecosystem-wide costs and without clear cost traceability and acceptance evidence, governance can’t benchmark value-for-money, which is an important factor with treasury-funded initiatives. More importantly, as a governance principle, core roadmap deliverables from founding entities were expected to be covered primarily by their own long-standing resources (including genesis allocation), and the treasury should not become the default completion fund for these categories unless the proposal is structured with exceptional clarity and procurement discipline. Finally, we are giving a process penalty for bypassing the Intersect Budget Process, which was specifically designed to address the gap in the process between proposers and Dreps. Bypassing the Intersect budget mechanism undermines comparability and price discovery for a major protocol spend, and founding entities should set the example by using the improved process rather than routing around it.

I’m voting NO because this is a large, consensus-layer scaling program and the proposal does not provide the level of auditable cost transparency and governance-grade deliverable gating that should accompany a multi-million-ADA treasury withdrawal for protocol-critical work. While it outlines phased intent and acknowledges that activation is separate from delivery, that structure still needs to be paired with explicit staffing/FTE counts, rate assumptions, and concrete artifact-based acceptance evidence per milestone so the community can verify progress and benchmark cost efficiency. This is especially important because consensus changes impose ecosystem-wide downstream obligations (testing, coordination, alternative client alignment, SPO operational impacts) and those externalities should be explicitly quantified and managed, not left implicit. As a governance principle, consensus/scaling “roadmap completion” from a founding entity should not default to treasury funding when those entities were expected to use their long-standing resources (including genesis allocation) to deliver core evolution of the protocol. Finally, we are giving a process penalty for bypassing the Intersect Budget Process, which was specifically designed to address the gap in the process between proposers and Dreps. Bypassing the Intersect budget mechanism undermines comparability and price discovery for a major protocol spend, and founding entities should set the example by using the improved process rather than routing around it.

I’m voting ABSTAIN because maintenance is clearly important, but approving ₳62,134,630 on the current level of transparency risks normalizing a treasury “operating backstop” without sufficient cost traceability, benchmarking, or measurable performance gates. The proposal provides a broad scope and high-level budget distribution, but for an ask of this magnitude, I expect component-level costing (what portion is node maintenance vs other functions), explicit team size/FTE allocations, and rate assumptions, and acceptance evidence that makes a continuous spend model governable. Without that, it becomes difficult to compare costs over time, especially as Cardano moves into a multi-client world where maintenance responsibility and funding will need to be distributed and benchmarked across teams. As a governance principle, I don’t want treasury-funded maintenance to become an open-ended model that reduces incentive to optimize; the ask must be structured to allow cost and performance scrutiny. Finally, we are giving a process penalty for bypassing the Intersect Budget Process, which was specifically designed to address the gap in the process between proposers and Dreps. Bypassing the Intersect budget mechanism undermines comparability and price discovery for a major protocol spend, and founding entities should set the example by using the improved process rather than routing around it.

I’m voting NO because this proposal asks for ₳ 10 million while bundling multiple workstreams with different maturity and risk profiles, without providing the level of cost traceability and milestone evidence that a multi-million-ADA treasury withdrawal requires. At this scale, each major stream should stand on its own with explicit staffing/FTE counts and rates, a clear “definition of done,” and artifact-based acceptance evidence. Otherwise, governance cannot do proper price discovery or evaluate whether we are paying for research, prototyping, production hardening, or GTM assumptions under one umbrella. Bundling also reduces decision precision: a voter may agree with one component but not another, yet must accept or reject the entire package, which is not an appropriate governance structure for spending at this size. Beyond structure, L2 work creates long-term obligations (maintenance, operator economics, ecosystem integration) and therefore demands particularly strong accountability gates to avoid funding “potential” without clear delivery. Finally, we are giving a process penalty for bypassing the Intersect Budget Process, which was specifically designed to address the gap in the process between proposers and Dreps. Bypassing the Intersect budget mechanism undermines comparability and price discovery for a major protocol spend, and founding entities should set the example by using the improved process rather than routing around it.

I agree with the proposed outcomes, but the proposal doesn’t justify ₳3.6 million ADA for a 6-month program with a cost model that is still too coarse for a multi-million-ADA withdrawal. The accountability and cost traceability are not at the level we should demand: the proposal provides a top-level funding distribution (e.g., 81% “Development & Engineering,” 12% “Engagement & Ecosystem support”) yet it does not explicitly map those costs to named roles, FTE counts, rates, and milestone acceptance artifacts, which makes it hard to evaluate whether the same outcomes could be delivered for materially less. It also contains deliverables whose “definition of done” can be subjective (“contracts ready-to-audit,” “unified onboarding,” “improve NPS/DevX”) unless paired with concrete evidence requirements and measurement methodology at milestone boundaries. Finally, we are giving a process penalty for bypassing the Intersect Budget Process, which was specifically designed to address the gap in the process between proposers and Dreps. Proposals of this category are exactly where a disciplined budget mechanism and/or RFP-style selection should be used to compare competing approaches; bypassing that weakens price discovery, and founding entities should model the standard we expect others to follow.

I support the intent. Cardano needs to stay visible to institutions, media, and builders, and co-locating around TOKEN2049 is strategically sensible. However, I can’t approve this withdrawal in its current form.

Why NO ....

Bundled package, no granularity: This request combines two large initiatives (Summit + TOKEN2049) under one vote. For a 14,076,539 ADA withdrawal, DReps need the ability to evaluate and approve these independently.
Sustainability is not demonstrated: The Summit still requires $2.5M in treasury funds, with only $313k carried over from 2025 and a stated $450k revenue target for 2026. That is not yet a credible glidepath to reduced treasury dependence year-over-year.
KPIs are too soft for the spend: The proposal lists many KPI categories, but it does not translate them into hard, measurable commitments (with baselines, targets, tracking method, and post-event reporting) that justify an ask of this size.
Process concern: The proposal is submitted outside the Intersect budget process due to timing, which reduces comparability versus other marketing requests and weakens “price discovery” for a large spend.

What would make me support a resubmission:

1. Split into two proposals (Summit vs TOKEN2049) so each can be judged on its own ROI.
2. Add hard KPI targets and a clear reporting plan (qualified leads, strategic meetings, partnerships initiated, media outcomes, and follow-up conversions).
3. Stick to the sustainability plan for Summit you published last year.

This NO is a request to restructure and tighten accountability, not a rejection of marketing or global presence.

I like the direction and I see real value here. Gerolamo targets trust-minimized dApps/light wallets and relay diversity, Pebble can broaden the developer funnel with a more familiar imperative/TypeScript-like experience, and ongoing TypeScript tooling maintenance reduces hard-fork fragmentation risk.

My hesitation is not about HLabs’ capability, but about process and procurement. This is a large, core-infrastructure request that will influence long-term maintenance commitments and how Cardano funds non-Haskell node/tooling work.

Before approving additional major node/tooling initiatives, I want to see an RFP/tender-style process for alternative nodes (and also for Haskell node maintenance): side-by-side comparison of scope, security/audit requirements, delivery milestones, adoption plan (including SPO/wallet/dApp uptake), and cost/maintenance expectations. Without that, it’s difficult to claim we’re achieving fair price discovery or choosing the best option among competing approaches.

For these reasons, I’m abstaining — I’m open to supporting HLabs in a revised process where proposals are evaluated competitively and granularly for this critical infrastructure category.

This is not a judgment on Blink Labs’ talent or the value of node diversity. The issue is prioritization and strategy.

1. Fiscal prioritization: Funding a third node implementation is a luxury we likely can’t afford right now. We should focus resources on getting one alternative node to production and then budget realistically for its ongoing maintenance before adding more permanent obligations.

2. Strategic coordination gap: Node diversity is important, but we lack an ecosystem-level plan for how many node implementations we intend to fund, in what sequence, and how we ensure SPO adoption. Treasury withdrawals shouldn’t be decided on a first-come basis for core infrastructure.

3. Cost sensitivity: The request is 6.9M ADA for 12 months, including premium FTE assumptions, a large audit line, and contingency. In the current treasury environment, this needs stronger comparative justification against alternatives and against other urgent ecosystem needs.

I’d be open to revisiting Dingo once we have a clearer multi-node strategy, a defined sequencing plan, and a budget view that includes long-term maintenance commitments.

I want to be clear: I strongly support the idea of a professional, ROI-driven ecosystem fund. Cardano has a real gap between grants and investor-ready companies, and a venture-style vehicle could materially improve proposal selection, negotiation, mentorship, and ultimately the number of scalable businesses built on Cardano.

My abstention is about the starting point. Approving Tranche One in its current shape risks setting a precedent for the entire multi-year initiative (3+ years), locking in misaligned incentives and weak accountability mechanisms that will be hard to correct later.

What I want to see strengthened before I can support a tranche-based VC program of this size:

1. Stronger alignment (“skin in the game”): clearer, meaningful co-investment commitments and full transparency around any co-invest activity, not just optionality. If co-investment is truly not possible under the proposed legal structure, then the structure should be adjusted so that meaningful alignment becomes possible. At a bare minimum, if the GP is to benefit economically (e.g., 20% of upside after Treasury repayment), the GP should cover the overhead/operational costs so that the full 50M ADA is effectively deployed into ecosystem projects rather than consumed by fund administration.

2. Hard KPI + milestone gates for future tranches: numeric baselines, targets, and clearly defined conditions under which Tranche Two/Three can be justified or rejected.

3. Governance and oversight clarity: clearer controls and checks (beyond reporting), and clearer boundaries around the CF administrator role and the SPV governance model.

We hope this initiative proceeds, but with a tighter structure that sets the right precedent from day one. If revised to address the points above, we won't be delaying the initiative and vote YES.

To be clear, I voted YES on the overall 50M ADA DeFi liquidity direction. This NO is about Withdrawal 1 as submitted (800,000 ADA for legal + setup).

I support building proper rails, but I can’t approve this version because the biggest cost item is the legal structure (up to 664k ADA) while key governance details are still not concrete: directors/supervisors are not named, director fees are “estimated”, and conflicts of interest aren’t transparently addressed.

I will vote YES on a revised version if it includes:

1. Named directors + supervisor (before disbursement)
2. Explicit COI disclosures + recusal policy
3. Hard fee caps and clear scope/time commitment for directors
4. Stronger cost justification for the chosen legal provider(s)

One of the easiest votes this year.

I hope CF won’t just finish what IOG started - i.e., milestone processing and payments for projects funded in previous rounds. I wish CF would also bring fresh ideas into the next Catalyst rounds.

Catalyst should be more than a funding mechanism: make it more VC-like in practice by actively connecting funded builders with the network and partners CF has access to.

We are setting the bar high - best of luck, CF team.

We decided to vote NO on the Cardano Budget Process Framework - not to reject the progress it brings, but to request targeted changes before adoption.

The framework is a meaningful step forward versus the current state: clearer structure, stronger alignment with the Cardano Vision, KPI discipline, and a better feedback loop for proposers. Big thumbs up for putting forward much-needed improvements.

However, there is a critical trade-off in the current design: proposals are shortlisted in Ekklesia using participating stake, and the process then moves toward bundling proposals into Treasury Withdrawals. In combination, these two choices can amplify the influence of a small set of large voters under low participation and reduce voting precision.

For Cardanians, either of the following compromises would make the framework acceptable:

If bundling remains: Ekklesia shortlisting should use total (live) voting stake, not participating stake, so results reflect actual governance power and are not skewed by low participation.
OR
If the participating stake remains: proposals should not be bundled into Treasury Withdrawals. Each shortlisted proposal should proceed as an individual Treasury Withdrawal to avoid “package deal” voting and preserve decision granularity.

Additional changes we strongly recommend implementing within this proposal:

Maximum request size: the framework already sets a minimum request of 100,000 ADA. Add a maximum as well (e.g., 20M ADA or 10% of the yearly NCL) to prevent oversized “mega-proposals” and force work to be split into reviewable, votable components.
Scaled submission fee: The current 1,000 ADA non-refundable submission donation is a good start, but it should scale with request size. Example brackets (1% of each lower bound):
100k–1M ADA: 1,000 ADA
1,000,001–5M ADA: 10,000 ADA
5M–20M ADA: 50,000 ADA
DRep review incentives: submission fees should explicitly fund a DRep review participation budget to reward active review and voting. The exact mechanism can be finalized later, but earmarking the budget should be part of the framework from day one.

Until these changes are incorporated, we cannot support the framework as written. The goal is not to block progress, but to ensure the process is resilient to low participation, avoids forced bundle voting, and scales to real-world reviewer capacity while protecting treasury decision quality.

At this stage, we believe it is important that some NCL is approved, even if it is more defensive. A conservative starting point is better than delay or uncertainty, and the NCL can always be increased later if there is a strong reason to do so.

Before raising the ceiling, the ecosystem should first evaluate how effective the previous year’s funded projects and initiatives actually were. Cardanians is reviewing that in parallel and would be open to supporting a higher NCL later if the data justifies it, especially if weaker ADA/USD conditions materially reduce real purchasing power.

For now, 300M ADA is a prudent initial ceiling that keeps the process moving while reserving any future increase for an evidence-based case.

This change increases the Plutus memory budget at both the transaction and block level, which directly addresses a real bottleneck for builders: some useful scripts and app flows hit the current ceiling and are forced into awkward workarounds (splitting logic, extra transactions, less efficient designs). Raising the ceiling is a straightforward way to unlock more practical on-chain functionality and improve developer experience.

Importantly, this is a measured, incremental step (“Part 1 of 2”), not a jump into unknown territory. The proposal increases:

a) maxTxExecutionUnits (memory) from 14,000,000 → 16,500,000 (+2.5M, ~+17.9%)

b) maxBlockExecutionUnits (memory) from 62,000,000 → 72,000,000 (+10M, ~+16.1%)

These values are intentionally coordinated so the network retains the same basic shape of capacity (e.g., still fitting four maximum-sized transactions per block), rather than creating a mismatch that could concentrate resources into fewer, heavier transactions.

From a governance and safety perspective, the proposal is framed explicitly to stay within the constitutional guardrails (including the per-epoch limit on how much these parameters should move). It also follows the expected process: it has been deployed on Preview and PreProd testnets first, and the supporting performance work (IOE benchmarking) indicates adequate headroom in critical timing metrics. In other words, it’s not just “we think it’s fine” — it’s “we tested it and the network can handle it within the intended budgets.”

Risks still exist and should be acknowledged. Increasing execution limits can be hard to “roll back” in practice if contracts begin relying on the higher limits. That’s exactly why we prefer this conservative, phased approach with prior testnet validation and clearly bounded increments. On balance, this is the kind of pragmatic, data-informed parameter tuning that helps Cardano scale utility for real applications while staying disciplined on operational safety.

Cardano has a tradition of naming hard forks after people who truly shaped the ecosystem. Naming PV11 the “van Rossem Hard Fork” is a heartfelt way to honor Max van Rossem’s governance work. Especially his contributions to the constitution and the early Constitutional Committee election process.

Rest in peace Max.

I support approving this NCL because it provides a clear, predictable spending ceiling while still allowing the ecosystem to keep funding builders and infrastructure that can grow real on-chain usage and, over time, increase the share of Cardano’s sustainability coming from transaction fees and economic activity.

The proposed cap is 350M ADA over ~100 epochs (~500 days / ~1 year 4 months). Under a conservative inflow path where treasury replenishment was ~3.9M ADA/epoch at end-2025 and continues declining at roughly the same rate observed through 2026 (~0.7M ADA/epoch per year), the expected treasury inflow across this window is roughly ~336M ADA. That implies the cap is near net neutral but slightly net negative in a worst-case scenario where the full cap is utilized (on the order of ~14M ADA), which is still within a tight band relative to the overall limit.

Importantly, this proposal does not inflate treasury outflows versus prior policy: the previous NCL was also 350M ADA, but set over roughly ~1 year. Spreading the same cap over ~1 year 4 months materially reduces the annualized spend rate, aligning with the reality that treasury inflows are trending downward.

My support is conditional on execution discipline: I expect greater granularity and accountability in future treasury withdrawals (clear scope, itemized budgets, milestones, and measurable KPIs). We should avoid approving tens of millions of ADA as a single “bundle” without concrete deliverables and performance measurement. NCL is the guardrail; sustainability still depends on funding high-quality, KPI-driven work that demonstrably expands adoption and usage.

For a ₳1.5M / 6-month “core trading infrastructure” ask, the proposal explains the direction, but it lacks the level of specificity and verifiable delivery standards expected at this budget.

What’s missing for a proposal of this size:

1. Milestone acceptance criteria: Each phase should have objective “done” checks (benchmarks, uptime/SLOs, latency targets, load profiles, rollout gates, go/no-go criteria), not just general outputs.

2. Operational and trust model clarity: Clearly state who operates Hydra heads and production services, what users must trust, failure scenarios (downtime, dispute handling, fund safety), incident response, and runbooks.

3. Security plan proportional to risk: “Security reviews/targeted audits” needs scope, auditor selection plan, timelines, threat model, and explicit in-scope components (on-chain + Hydra integration + infra).

4. Liquidity/adoption mechanics: A credible plan for market quality (market makers, initial pairs, incentive/distribution design if any) rather than KPI targets alone.

5. Budget benchmarking and itemized cost model: Not just a high-level split. Provide an itemized budget with roles + headcount, expected hours/man-days per workstream, rate per man-day, and major non-labor costs (audit quotes/estimates, infra, legal, tooling). Include brief benchmarking against comparable deliverables and typical engineering rates to justify proportionality.

6. Public-goods commitments: If positioned as “core infrastructure,” specify durable ecosystem value (licensing/IP, open interfaces, integration commitments, and a post-funding maintenance plan).

Resubmission request: Keep the governance safeguards (multisig, milestone-based releases, return of unused funds), but resubmit with (1) measurable acceptance criteria per phase, (2) explicit trust/risk + ops model, (3) audit scope/vendor plan, (4) credible liquidity/adoption plan, (5) itemized budget with hours/headcount/man-day rates, and (6) concrete public-goods + maintenance commitments.

For a ₳1.5M / 6-month “core trading infrastructure” ask, the proposal explains the direction, but it lacks the level of specificity and verifiable delivery standards expected at this budget.

What’s missing for a proposal of this size:

1. Milestone acceptance criteria: Each phase should have objective “done” checks (benchmarks, uptime/SLOs, latency targets, load profiles, rollout gates, go/no-go criteria), not just general outputs.

2. Operational and trust model clarity: Clearly state who operates Hydra heads and production services, what users must trust, failure scenarios (downtime, dispute handling, fund safety), incident response, and runbooks.

3. Security plan proportional to risk: “Security reviews/targeted audits” needs scope, auditor selection plan, timelines, threat model, and explicit in-scope components (on-chain + Hydra integration + infra).

4. Liquidity/adoption mechanics: A credible plan for market quality (market makers, initial pairs, incentive/distribution design if any) rather than KPI targets alone.

5. Budget benchmarking and itemized cost model: Not just a high-level split. Provide an itemized budget with roles + headcount, expected hours/man-days per workstream, rate per man-day, and major non-labor costs (audit quotes/estimates, infra, legal, tooling). Include brief benchmarking against comparable deliverables and typical engineering rates to justify proportionality.

6. Public-goods commitments: If positioned as “core infrastructure,” specify durable ecosystem value (licensing/IP, open interfaces, integration commitments, and a post-funding maintenance plan).

Resubmission request: Keep the governance safeguards (multisig, milestone-based releases, return of unused funds), but resubmit with (1) measurable acceptance criteria per phase, (2) explicit trust/risk + ops model, (3) audit scope/vendor plan, (4) credible liquidity/adoption plan, (5) itemized budget with hours/headcount/man-day rates, and (6) concrete public-goods + maintenance commitments.

We support these constitutional updates because they strengthen governance clarity, treasury accountability, and proposal integrity without expanding central authority. Removing redundant mechanisms, enforcing immutability of proposal documents, and applying audit safeguards uniformly across all treasury withdrawals improves long-term sustainability and reduces governance risk. Overall, this is a pragmatic hardening of Cardano’s governance framework that benefits DReps, builders, and the ecosystem.

We support the Vision 2030 Info Action as a non-binding strategic framework that provides a shared long-term direction and measurable outcomes for Cardano. It does not mandate implementation, authorize spending, or constrain future governance decisions, but offers useful reference KPIs and priorities to evaluate proposals more consistently. We view this as a guiding compass for DReps and the ecosystem, not an execution plan, and future actions must still be assessed on their own merits.

We support this proposal because adding an additional Constitutional Committee member strengthens governance resilience and reduces the risk of future ratification deadlocks. With the 66.7% approval threshold now in place, a larger CC also raises the absolute bar for approval, improving checks and balances. This action has no treasury impact, does not change CC powers or rules, and helps ensure stable, continuous governance operations.

We support this action because adding the elected Constitutional Committee member restores the committee to its required minimum size, enabling full on-chain governance to function again. The snap election was transparent, audited, and compliant with constitutional guardrails, and Cardano Curia received the highest DRep stake in the vote. This proposal does not change any rules or powers - it simply implements the community’s decision and ensures governance continuity.

We support the goal of bringing critical integrations such as stablecoins, custody, bridges, and analytics to Cardano, but the current proposal lacks the transparency needed for a ₳70M treasury withdrawal. There is no itemized cost breakdown, no clear prioritization of integrations, and limited visibility into partner selection or execution strategy. This level of opacity is not acceptable for the largest budget request in Cardano’s history. We encourage a revised version with clear costs, justification, and accountability so the community can responsibly support this important initiative.

We voted Yes because this proposal simply extends the existing Net Change Limit by eight epochs to prevent a governance and treasury deadlock. Without this extension, any Treasury Withdrawal ratified in Epoch 604 could not be enacted due to the NCL expiring before funds could be released. This action does not increase spending, change the cap, or alter any treasury rules - it only ensures continuity, constitutional compliance, and uninterrupted functioning of the treasury. Supporting this extension is necessary for stable governance operations.

We support the goal of bringing critical integrations such as stablecoins, custody, bridges, and analytics to Cardano, but the current proposal lacks the transparency needed for a ₳70M treasury withdrawal. There is no itemized cost breakdown, no clear prioritization of integrations, and limited visibility into partner selection or execution strategy. This level of opacity is not acceptable for the largest budget request in Cardano’s history. We encourage a revised version with clear costs, justification, and accountability so the community can responsibly support this important initiative.

We voted Yes because the expanded Treasury Withdrawal provides a complete, auditable, and enforceable loan framework that aligns with the strategic goal of improving Cardano’s global exchange presence. The structure includes milestone-based disbursements, independent audits, TRSC/PSSC oversight, and full repayment terms, reducing risk to the treasury. Although the proposal introduces a novel loan model, the detailed safeguards, transparency commitments, and ecosystem-wide benefits justify supporting this initiative.

This proposal corrects an early governance bug that caused the Ikigai Info Action submitter to lose their 100,000 ADA deposit through no fault of their own, as documented in the abstract and motivation sections. Reimbursing the deposit, plus a modest adjustment for lost rewards (total 103,000 ADA), upholds fairness for early participants and reinforces trust in Cardano’s governance process. The amount is small, constitutionally compliant, and directly resolves a long-standing issue acknowledged by the community.

We voted No because the requested 1,000,000 ADA compensation for the Constitutional Committee is not proportionate to the committee’s limited mandate and lacks sufficient justification or workload transparency. The proposal sets an unsustainable precedent for administrative spending, prioritizing institutional salaries over broader ecosystem needs. While smart-contract oversight and reporting are positive, the overall scale and structure do not meet our standards for efficient, accountable treasury use.

Cardano Constitution v2.3 simplifies governance and strengthens accountability. It removes non-binding expectations and redundant mechanisms, such as the Budget Info Action, making the framework more efficient and enforceable. The update introduces immutable proposal documents and applies audit safeguards to all treasury withdrawals, improving transparency and fiscal responsibility. By refining definitions and standardizing terminology, it enhances clarity for all participants while integrating broad community feedback to ensure a more stable and legitimate governance foundation.

Securing the .ada and .cardano generic top-level domains (gTLDs) strengthens Cardano’s global identity and digital infrastructure. It protects critical naming assets from third-party control, ensures long-term brand integrity, and opens new possibilities for ecosystem-wide innovation — including verifiable Web3 integrations, decentralized identity, and trusted domain-based services.

As this initiative is funded entirely by the Cardano Foundation and does not draw from the treasury, it poses no financial risk to the community. The proposed Community Advisory Group and public reporting commitment further align with decentralization and transparency principles.

While GovTool remains a valuable public good for Cardano governance, the ₳1.15M budget request appears disproportionate to the project’s current maturity and deliverables. The proposed team size and cost per FTE exceed open-source standards and lack clear justification relative to outcomes. Treasury spending must remain efficient and proportionate to ensure sustainability and equitable funding across the ecosystem. We encourage the proposers to return with a leaner, milestone-based plan that preserves GovTool’s progress while improving cost efficiency.

As Cardanians DRep, we believe this proposal tackles a systemic weakness in Cardano DeFi and introduces important long-term infrastructure for treasury capital deployment. That said, ₳50M is a serious ask, and at this level of funding, execution must be bulletproof.

We urge the team to:

1. Provide detailed milestone-based plans before each withdrawal
2. Finalize and publish the legal framework and jurisdictional implications
3. Use transparent, public RFPs for DeFi protocol selection with clear scoring criteria
4. Ensure the committee’s actions are logged and monitored in a verifiable on-chain way
5. Establish community review and feedback mechanisms beyond just dReps

Treasury capital must be treated with the same seriousness as VC or institutional funds — with governance, transparency, and measurable ROI.

With these measures, we believe this experiment can set a new benchmark for responsible DeFi funding from the treasury.

YES with eyes wide open and accountability baked in.

As Cardanians DRep, we support this proposal — but with clear reservations — based on our three pillars:

Long-Term Sustainability
We recognize this is a loan, not a grant. That’s a crucial shift in treasury funding logic — introducing interest repayment, external audit, and budget oversight via Intersect. These are important steps toward scalable, capital-efficient governance. If this succeeds, it could set a precedent for future proposals seeking to recycle treasury funds rather than consume them outright. However, we note that the proposal still lacks a granular budget breakdown, clear financial risk mitigation, and contingency if projected revenues fail.

Supporting Builders & Ecosystem Growth
Snek has already secured Tier 1 listings using $4.5M of self-funded capital. This track record cannot be ignored. The team proposes to open exchange infrastructure, legal frameworks, and onboarding playbooks for other Cardano-native tokens. If delivered, this creates real long-term value beyond Snek. Still, some concerns remain: we would prefer clearer timelines, KPIs for what success looks like (e.g. # of listings, trading volume, liquidity depth), and specific examples of how this proposal will tangibly benefit other builders.

Decentralization & Community Engagement
The proposal introduces decentralized funding innovation and promises transparency: governance by Intersect, oversight from a board of well-known advisors, and biannual reporting. However, more concrete measures of decentralization would strengthen it — such as community inclusion in impact assessment or commitments to open-source key tools/processes.

Conclusion
We vote YES, but this is not a blank cheque. It’s a vote for a structured, repayable experiment. If it succeeds, it could unlock visibility and access for Cardano in global markets — and pave the way for scalable CNT adoption. But if governance oversight is weak or execution opaque, trust will erode. We’ll monitor delivery closely and expect regular updates, repayments, and documentation of ecosystem benefits.

Long-Term Sustainability
A unified global marketing strategy could help improve awareness, clarify Cardano’s positioning, and attract new users. However, marketing alone does not directly enhance the protocol, infrastructure, or developer experience—its impact is indirect and difficult to measure.

Builder and Ecosystem Growth
While better marketing may benefit builders through increased visibility, the proposal does not describe how builders will be represented or supported in campaigns. It offers no assurance that dApps, tools, or community projects will be meaningfully included.

Decentralization and Community Engagement
Creating a narrative on behalf of the ecosystem requires community input and decentralized participation, which the proposal currently lacks. Messaging should reflect diverse voices—not a top-down vision shaped by a centralized team or agency.

Responsible Treasury Spending
₳6,000,000 is a significant amount for broad marketing with limited deliverables and no public KPIs. Moreover, we believe core marketing efforts should be funded by the founding entities (IOG, CF, Emurgo)—each of which received large allocations of genesis ADA and earns ongoing revenue through delegation and other sources.
While we support the goal of coherent messaging, we Abstain on this version due to lack of transparency, insufficient builder inclusion, and the belief that marketing should be led and resourced by the already well-funded founding entities. Treasury funds should prioritize public goods, not foundational responsibilities.

Long-Term Sustainability
Intersect was established to manage key aspects of decentralized governance under Voltaire. While the function is important, the proposal provides minimal evidence that its operations to date have significantly contributed to long-term sustainability or improved governance outcomes in measurable terms.

Builder and Ecosystem Growth
The proposal does not clearly explain how Intersect’s work benefits developers or builders. Its focus is administrative and process-oriented, with few deliverables tied to tooling, infrastructure, or direct ecosystem growth.

Decentralization and Community Engagement
Despite its intended role as a community-led entity, Intersect remains non-elected, membership-gated, and operationally opaque. Community members have little insight into internal decision-making, committee compensation, or how resources are allocated. This weakens its claim to serve as a model of decentralized governance.

Responsible Treasury Spending
₳15,750,000 is a massive budget request—enough to fund a 150-person company for a year—yet the proposal lacks a detailed cost structure, staffing plan, or milestones. There is no clear justification for how funds will be deployed or assessed.
Additionally, Cardano’s three founding entities (IOG, Cardano Foundation, and Emurgo) have ample resources—via genesis ADA allocations and staking revenue—to fund and support an organization like Intersect if they believe in its strategic necessity. It is not evident why such a large burden must be shifted to the treasury at this stage.
We vote NO, and call for a future funding request that includes a transparent budget, independently audited results, and community-elected oversight mechanisms. Treasury funds must be reserved for clear, accountable public goods, not opaque operations.

Long-Term Sustainability
Tweag’s work directly contributes to core Cardano infrastructure, including improvements to Plutus, node behavior, and formal verification. These investments are critical to the protocol’s long-term functionality, performance, and roadmap execution.

Builder and Ecosystem Growth
By enhancing low-level systems and dev tooling, Tweag’s contributions improve the experience for dApp developers, smart contract engineers, and infrastructure maintainers. These benefits are indirect but foundational.

Decentralization and Community Engagement
Tweag operates independently of IOG and CF, which increases development plurality and reduces systemic reliance on a single engineering source. Their formal, research-driven approach adds trust and transparency to protocol development.

Responsible Treasury Spending
₳11M is a large ask, but the scope covers multiple deliverables across protocol design, implementation, and long-term maintenance. The proposal would benefit from more granular cost transparency and a clear milestone framework.
We vote YES, conditional on milestone-based disbursement, clear delivery reporting, and community visibility into progress. Treasury should fund this work, but with oversight proportionate to the scale of investment.

Long-Term Sustainability
This proposal funds essential protocol development and maintenance tasks, including node upgrades, Plutus improvements, and network performance enhancements. These are non-negotiable components of Cardano’s continued functionality and roadmap delivery.

Builder and Ecosystem Growth
Core engineering enables builders to safely rely on stable infrastructure, unlocking new capabilities across smart contracts, governance, and scalability. Without it, tooling and dApp development would stall, weakening Cardano’s competitive edge.

Decentralization and Community Engagement
While the work is executed by IOG, the proposal is tied to Intersect governance structures and roadmap alignment. Its success depends on transparent delivery and ongoing communication between the engineering team, the community, and oversight committees.

Responsible Treasury Spending
At nearly ₳97 million, this is the single largest ask in the budget, equivalent to nearly one-third of the entire annual allocation. Yet the proposal does not provide a public breakdown of how the funds will be allocated: no clarity on staffing levels, workstream budgets, or even basic cost per deliverable. This level of opacity is unacceptable for such a large draw on public funds.

Furthermore, the proposal comes from an organization (IOG) that has historically operated with minimal financial transparency, despite having already received extensive support through initial ADA allocations and prior project funding. Treasury funding at this scale should be a last resort, not a default continuation of legacy arrangements.

We support funding core protocol development in principle, but this request must be completely restructured to include:

• A transparent itemized budget
• Public milestone schedules with deliverables
• Third-party audit of scope, staffing, and progress

Without these, approving this proposal risks normalizing vague, unaccountable treasury draws at enterprise scale. We are deeply concerned about the precedent this sets for future governance.

Long-Term Sustainability
Improving exchange listings and liquidity may offer reputational and market access benefits to Cardano-native projects. However, these are off-chain, externally controlled outcomes that don’t materially contribute to the protocol’s sustainability or infrastructure.

Builder and Ecosystem Growth
This proposal aims to assist a limited number of token projects—not the broader developer community. There’s no clear path for open participation, nor assurances that the supported listings will result in measurable ecosystem growth.

Decentralization and Community Engagement
The proposal does not offer community governance, public token selection, or decentralized oversight in how the services are allocated. While the administration is technically neutral (through Intersect), the process lacks transparency and public input.

Responsible Treasury Spending
₳3.1M is a high-cost proposal with minimal on-chain deliverables or reusable infrastructure. While we recognize the goal of improving liquidity, the execution lacks accountability, detailed budgeting, or broad benefit.
We choose to Abstain, as the intent may align with ecosystem goals, but the design falls short of the standards required for treasury funding. A clearer, transparent, and community-guided alternative would be more appropriate.

Long-Term Sustainability
While real-world asset (RWA) tokenization is a promising narrative, this proposal lacks sufficient detail to prove it will deliver sustainable value to the Cardano ecosystem. The use of treasury funds to subsidize an unproven business model carries high strategic and reputational risk.

Builder and Ecosystem Growth
The proposal does not offer infrastructure, tooling, or reusable components that benefit Cardano developers or projects. It primarily supports a single vertical use case with unclear technical, legal, or economic frameworks.

Decentralization and Community Engagement
There is no transparency on how assets will be selected, who controls the platform, or how the community participates. The proposal is structurally centralized and offers no assurances of open access or governance input.

Responsible Treasury Spending
₳3,000,000 is a massive ask for a speculative, profit-driven venture with limited ecosystem integration and unclear delivery terms. The risk-to-return ratio is far too high, and public funds should not serve as seed capital for opaque real estate projects. We strongly recommend voting NO.

Long-Term Sustainability
While creating a Builder DAO could support long-term innovation, the proposal lacks a clearly defined structure, governance model, and mechanisms for sustainable funding allocation. Without those, it risks becoming another siloed funding body with unclear alignment to Cardano’s roadmap.

Builder and Ecosystem Growth
The proposal does not outline how builders will apply, be evaluated, or supported. It’s unclear how it avoids overlapping with Catalyst or existing treasury pathways, raising questions about efficiency and redundancy.

Decentralization and Community Engagement
Despite claiming to empower community builders, the DAO structure is undeveloped, with no clarity on member selection, transparency, or accountability. The decision-making process is top-down at this stage, not community-led.

Responsible Treasury Spending
₳12,000,000 is an extraordinarily high request for an initiative that lacks foundational governance, technical planning, and operational details. Funding a DAO in name only, without concrete architecture or track record, is a high-risk use of treasury funds. We recommend voting NO until a smaller, transparent pilot with clear controls and milestones is proposed.

Long-Term Sustainability
Expanding infrastructure for stablecoins and native assets is strategically aligned with Cardano’s vision for financial use cases. However, this proposal lacks detail on what will actually be built, how it will be maintained, and who is delivering it.

Builder and Ecosystem Growth
Stablecoin tooling and asset infrastructure can support dApps and DeFi protocols, helping builders launch and scale. Yet without clear technical scope, timelines, or team accountability, it’s difficult to assess the benefit to developers in practice.

Decentralization and Community Engagement
The proposal references broader ecosystem impact, but doesn’t specify how it supports decentralization or community involvement. There is no framework for collaboration, governance, or public contribution to the deliverables.

Responsible Treasury Spending
₳4,000,000 is a significant request for an abstract, multi-domain effort with no transparent budget, roadmap, or defined outputs. While we support the general objective, the lack of clarity makes it difficult to justify a Yes vote.
We choose to Abstain, signaling support for the direction but not the current form of the proposal. A more focused, transparent version may earn our backing in the future.

Long-Term Sustainability
The Cardano Summit has consistently served as a high-visibility event that brings the global community together, supporting ecosystem awareness and narrative alignment. Continued investment in such events can reinforce Cardano’s reputation and long-term relevance.

Builder and Ecosystem Growth
In principle, the Summit offers a valuable opportunity for builders and teams to network, pitch ideas, and gain exposure. However, past editions have required projects to pay to showcase their work—including for keynotes, booths, or even to display their logos—which limits access and disproportionately favors well-funded teams.

Decentralization and Community Engagement
If funded by the treasury, the Summit should function as a true public good, accessible to the entire Cardano ecosystem. We would expect free attendance, equal opportunity for projects to present, and fair representation across regions and project types, not a pay-to-play structure.

Responsible Treasury Spending
₳6,000,000 is a significant ask and must come with clear value for the community. Without guarantees of open access and free presentation platforms for Cardano projects, the funding risks reinforcing exclusivity rather than enabling broad ecosystem engagement.
We Abstain, as we support the intent but cannot endorse the current model without commitments to inclusivity, transparency, and fair access for all builders.

Long-Term Sustainability
Funding open-source contributors is a noble goal, but this proposal lacks a focused strategy for sustainable outcomes. It does not define how funding decisions will be made, how work will be prioritized, or how deliverables will align with Cardano’s long-term needs.

Builder and Ecosystem Growth
While intended to support builders, the vague structure risks dispersing funds without measurable impact. There is no clear mechanism for ensuring funded work contributes meaningfully to the ecosystem or avoids duplication.

Decentralization and Community Engagement
The model concentrates power in a small committee to allocate large sums with limited community input. It lacks transparency, community governance, and verifiable accountability, which weakens its claim to decentralization.

Responsible Treasury Spending
₳5.88 million is one of the largest single requests in the budget, yet it offers the least clarity on outcomes, management, and oversight. Funding open-source work is important—but not at this scale without rigorous structure. We recommend voting NO due to poor transparency, high cost, and insufficient accountability.

Long-Term Sustainability
Strategic alignment toward a 2030 roadmap is important, but not urgent. This work does not require its own treasury-funded committee given the existing involvement of IOG, Emurgo, and the Cardano Foundation—each of whom received large allocations of genesis ADA for ecosystem development and planning.

Builder and Ecosystem Growth
While long-term visioning may indirectly benefit builders, this proposal offers no tangible tooling, infrastructure, or funding access for them. It risks funding bureaucracy over execution, with limited direct outcomes for developers or projects.

Decentralization and Community Engagement
The committee is intended to support community-driven product planning, but its structure is unclear, and there are no details about how representatives are selected or how public input will meaningfully influence roadmap decisions. It risks centralizing strategic direction under a small, appointed group.

Responsible Treasury Spending
₳750,000 is excessive for producing strategy documents, workshops, and coordination overhead. The founding entities—already well-funded—are responsible for ecosystem leadership and could contribute to this initiative without drawing from the treasury. Given the cost, duplication of mandate, and unclear governance structure, we recommend voting NO on this proposal.

Long-Term Sustainability
While global visibility matters, temporary physical booths at exhibitions do not provide lasting infrastructure or technical advancement. This initiative does little to enhance the core sustainability of the Cardano protocol or ecosystem.

Builder and Ecosystem Growth
The proposal claims to support growth by increasing awareness, but its indirect benefits to actual builders are limited and speculative. There is no guarantee that pavilion exposure translates to dApp adoption, developer onboarding, or long-term engagement.

Decentralization and Community Engagement
Pavilion presence at events is inherently top-down and PR-driven. It does not empower the community, improve transparency, or advance decentralization in any measurable way.

Responsible Treasury Spending
₳889,500 is an extremely high price for short-lived, hard-to-measure promotional impact. The budget lacks justification, is not tied to KPIs, and diverts funding from higher-impact proposals. We recommend voting NO based on cost inefficiency and low ecosystem return. Treasury funds should prioritize reusable infrastructure and verifiable outcomes..

Long-Term Sustainability
The idea of a native asset CDN—serving token icons, metadata, and branding—is helpful for improving UX and consistency across wallets and dApps. However, it is not a critical protocol service and does not directly impact network resilience or security.

Builder and Ecosystem Growth
A well-executed CDN could make asset integration smoother for developers and improve token discoverability for users. Yet, the technical complexity and impact are limited, and much of the value can be delivered using existing web infrastructure at a fraction of the proposed cost.

Decentralization and Community Engagement
The service would be public-facing and improve uniformity in asset presentation across interfaces. Still, it does not meaningfully increase decentralization or empower new participants, and the proposal lacks a clear open governance or stewardship model for long-term sustainability.

Treasury Spending Concerns
₳605,000 for a relatively lightweight web service is excessive. Comparable services—static asset hosting, cache/CDN distribution, metadata indexing—could be delivered reliably for ₳100,000–₳150,000 with ongoing maintenance. The proposal does not justify the inflated cost with itemized budgeting or technical constraints. Given the overestimation, lack of critical urgency, and weak accountability mechanisms, we recommend voting NO on this proposal. If resubmitted with a leaner scope and clearer delivery plan, it may be reconsidered.

Long-Term Sustainability
Exploring complementary funding models like Quadratic Funding can add value to Cardano’s governance system. It supports experimentation in decentralized grant distribution, which is aligned with long-term ecosystem evolution.

Builder and Ecosystem Growth
If executed well, this could channel funds to underrepresented community builders and broaden funding access. However, it remains experimental and does not directly support tooling, infrastructure, or builders in its current form.

Decentralization and Community Engagement
Quadratic Funding promotes more democratic participation in treasury allocation. That said, the proposal lacks clarity on how outcomes will be measured, how feedback will be incorporated, and how this pilot integrates with existing Catalyst structures.

Responsible Treasury Spending
₳1.5 million is excessive for an experimental pilot with unclear deliverables and no phased rollout plan. While we support the idea, the scope should be reduced and focused. We recommend voting NO on this version and encourage a leaner resubmission with tighter milestones, community co-design, and measurable outcomes.

Long-Term Sustainability
Scalus proposes a modular platform to streamline dApp development on Cardano, aiming to improve developer productivity and long-term maintainability of smart contract projects. If successful, it would reduce technical complexity and increase project durability.

Builder and Ecosystem Growth
By packaging essential dev tools—testing environments, contract templates, deployment flows—Scalus targets friction points that commonly delay or block dApp teams. The platform has the potential to meaningfully improve time-to-market and quality for builders.

Decentralization and Community Engagement
As open infrastructure, Scalus could decentralize dApp tooling by reducing reliance on closed or ad hoc solutions. That said, the proposal lacks specifics on community contribution, governance, or long-term maintenance strategy for the platform itself.

Responsible Treasury Spending
₳657,692 is a sizable request for a new development framework. The proposal does not provide enough clarity on deliverable milestones, FTE cost structure, or how it avoids overlap with existing dev tools. We support the concept, but funding should be milestone-gated and contingent on proof of technical progress and real-world adoption. Without those safeguards, this carries moderate execution and redundancy risk.

Long-Term Sustainability
The ZK Bridge aims to enable secure cross-chain communication using zero-knowledge proofs, a capability that would expand Cardano’s interoperability and future-proof it against ecosystem isolation. Such infrastructure is critical for long-term adaptability.

Builder and Ecosystem Growth
A functioning ZK bridge could allow developers to build cross-chain dApps and unlock access to liquidity and users from other networks. This would increase Cardano’s relevance in the broader Web3 space and enable new builder use cases.

Decentralization and Community Engagement
The proposal emphasizes non-custodial design and cryptographic trust, which aligns with Cardano’s decentralization principles. However, it offers limited detail on how operator sets, governance, or open standards will be handled post-launch.

Responsible Treasury Spending
₳700,000 is a reasonable ask for early-stage ZK infrastructure, but the proposal lacks clarity on deliverables, interoperability targets, or technical readiness. We support the strategic intent, but recommend milestone-based disbursement, public progress reporting, and an external audit of technical architecture. Without that, treasury risk remains non-trivial.

Long-Term Sustainability
This proposal aims to enhance the usability and accessibility of Cardano’s on-chain governance tooling, a necessary step for ensuring that Voltaire succeeds beyond its technical minimum. It supports long-term sustainability by addressing human factors that influence system adoption and effectiveness.

Builder and Ecosystem Growth
The proposal targets onboarding flows, UX audits, documentation, and interface components—resources that benefit wallet teams, DReps, and future governance tools. If well executed, these deliverables can lower the barrier to contribution and drive better user participation in governance processes.

Decentralization and Community Engagement
Improved UX and educational content are directly aligned with decentralization goals, as they help more ADA holders participate in governance with confidence. That said, the proposal’s focus on design and education rather than protocol-level infrastructure limits its decentralization impact to soft layers of engagement.

Responsible Treasury Spending
₳592,780 is a substantial amount for a proposal centered on UX improvements, documentation, and non-technical deliverables. The proposal lacks a detailed cost breakdown for specific outputs or FTE allocations, which makes it difficult to evaluate value-for-money. We support the intent—but funding should be milestone-based, publicly trackable, and outcomes-driven. Without clear accountability, this risks overspending on deliverables that are subjective and hard to measure.

Long-Term Sustainability
PyCardano is a foundational Python library for Cardano interaction, offering a reliable alternative to Haskell-based tooling. Maintaining it supports the ecosystem’s technical diversity and long-term compatibility across language environments.

Builder and Ecosystem Growth
It enables Python developers to build wallets, scripts, and applications without needing to learn lower-level tooling. This lowers the barrier to entry and expands the pool of potential Cardano builders worldwide.

Decentralization and Community Engagement
As an open-source library with wide adoption, PyCardano supports a more pluralistic and decentralized developer ecosystem. Intersect’s involvement adds transparency and community alignment.

Responsible Treasury Spending
₳314,800 is a justified amount to maintain and improve a core SDK that underpins many production services. The scope and impact are clear, making this responsible and ecosystem-enabling treasury spending.

Long-Term Sustainability
This proposal ensures continued support for Ledger, Trezor, and other hardware wallet integrations—vital for secure ADA storage, transaction signing, and governance participation. Ongoing maintenance helps future-proof against protocol upgrades.

Builder and Ecosystem Growth
Reliable hardware wallet libraries are essential for wallet developers and dApp teams who integrate signing functionality. This maintenance effort directly supports those builders by safeguarding the usability of secure endpoints.

Decentralization and Community Engagement
Hardware wallets are a key tool for self-custody and decentralized participation. Maintaining open, permissionless access aligns with Cardano’s core principles of sovereignty and non-custodial control.

Responsible Treasury Spending
At ₳424,800, this is a reasonable investment in high-impact, security-critical infrastructure. Administered by Intersect, with clear public benefit, we consider this responsible and foundational treasury spending.

Long-Term Sustainability
Eternl is a widely used light wallet in the Cardano ecosystem, and its continued maintenance ensures compatibility with network upgrades and governance features. Sustaining this infrastructure preserves reliable, long-term access to the blockchain.

Builder and Ecosystem Growth
Eternl serves users, dApps, and token projects by supporting transaction signing, voting, and delegation. Its accessibility and feature set support a diverse range of use cases, contributing to ecosystem utility and adoption.

Decentralization and Community Engagement
As a non-custodial wallet developed independently of founding entities, Eternl contributes to wallet diversity and user sovereignty. Its open development model and community feedback loop reinforce Cardano’s decentralization.

Responsible Treasury Spending
While the ₳583,000 request is sizable for maintenance, the wallet’s impact and user base justify continued support. Oversight through Intersect adds needed accountability. We view this as responsible but high-visibility spending that requires regular public progress reporting. We also expect open sourcing for better auditability.

Long-Term Sustainability
Gerolamo (also known as the Amaru project) aims to deliver a fully functional Cardano node in TypeScript, increasing protocol resilience through client diversity. This aligns with long-term goals of reducing systemic reliance on a single Haskell-based implementation.

Builder and Ecosystem Growth
A TypeScript node will unlock new use cases—light clients, browser integrations, and faster prototyping—for developers building wallets, tooling, or educational apps. It significantly broadens the technical entry points into Cardano development.

Decentralization and Community Engagement
Client diversity is a key pillar of decentralized blockchain infrastructure. Gerolamo’s open-source, alternative implementation offers more flexibility for the ecosystem and aligns with decentralization goals.

Responsible Treasury Spending
₳578,571 is well-targeted for advancing a high-leverage, technically ambitious project with broad utility. We consider this responsible treasury spending that directly enhances Cardano’s decentralization and developer accessibility.

Long-Term Sustainability
This proposal seeks to unify essential Web3 tooling—wallet connectors, SDKs, indexers, and starter kits—to make Cardano more competitive and developer-friendly. It supports sustainability by lowering entry barriers and standardizing common development patterns.

Builder and Ecosystem Growth
By consolidating and improving core components used across dApp development, the proposal directly empowers builders and accelerates project launches. A well-supported stack reduces fragmentation and increases onboarding success for new teams.

Decentralization and Community Engagement
The proposed stack would be open-source and publicly maintained, helping shift infrastructure ownership from centralized providers to the wider ecosystem. However, greater clarity is needed on how long-term stewardship and community adoption will be ensured.

Responsible Treasury Spending
₳600,000 is a mid-sized request that promises broad utility, but the proposal is light on specifics: it lacks a clear breakdown of tools to be built, project phases, or delivery schedule. We support the goal, but funding should be conditional on transparent milestones, public deliverables, and an audit of what will be reused versus built from scratch. Without that clarity, the risk of duplication or scope creep is significant.

Long-Term Sustainability
This proposal ensures the continued functionality and evolution of Cardano’s Ledger hardware wallet app, which is critical for secure transaction signing and governance participation. A full rewrite supports future compatibility with protocol upgrades and new features.

Builder and Ecosystem Growth
Improved Ledger support benefits developers building wallets, dApps, and governance tools by ensuring consistent hardware wallet integration. It directly supports ecosystem usability and end-user trust in Cardano applications.

Decentralization and Community Engagement
Hardware wallets are a cornerstone of secure, self-sovereign participation. Supporting open, non-custodial access through maintained Ledger software reinforces Cardano’s decentralization and security guarantees.

Responsible Treasury Spending
₳300,000 is reasonable for a comprehensive rewrite and future-proofing of such critical infrastructure. With Intersect’s oversight and clear community benefit, we consider this responsible and security-focused treasury funding.

Long-Term Sustainability
Dolos offers a lightweight alternative to full nodes, making Cardano data more accessible for constrained environments and infrastructure providers. Sustaining this tool strengthens the ecosystem’s adaptability and data availability.

Builder and Ecosystem Growth
By providing simplified access to blockchain data, Dolos supports developers building analytics tools, dashboards, and dApps without needing a full node setup. This lowers infrastructure costs and improves accessibility for smaller teams.

Decentralization and Community Engagement
As an independently maintained, open-source project, Dolos enhances client diversity and technical flexibility. It empowers more participants to operate and interact with Cardano on their own terms.

Responsible Treasury Spending
The requested funding is modest for maintaining an already valuable tool. Its ecosystem utility is clear, and continued development benefits many downstream use cases. We consider this responsible and high-leverage treasury spending.

Long-Term Sustainability
This proposal supports a reliable RPC interface for interacting with Cardano’s UTxO-based ledger, making it easier to build integrations and infrastructure. Sustaining such middleware is vital for interoperability and network accessibility.

Builder and Ecosystem Growth
UTxO RPC simplifies development for exchanges, explorers, and backend systems that need to query on-chain data efficiently. It enables faster project launches and lowers integration complexity for both new and existing developers.

Decentralization and Community Engagement
As a public integration layer, this tool allows more developers to build services without relying on centralized APIs. Its open availability aligns with Cardano’s goal of empowering a wide, permissionless developer base.

Responsible Treasury Spending
The requested amount is reasonable for maintaining critical integration infrastructure. The scope is clear and the deliverables are meaningful. We view this as responsible and utility-focused treasury funding.

Long-Term Sustainability
Pallas provides Rust-based libraries for parsing and interacting with the Cardano protocol, enabling alternative clients and tooling. Maintaining this codebase supports protocol diversity and reduces systemic reliance on Haskell-only infrastructure.

Builder and Ecosystem Growth
Rust is widely adopted in systems programming, and Pallas makes Cardano accessible to Rust developers. This supports new tooling, lighter clients, and broader integration potential across exchanges, wallets, and custom infrastructure.

Decentralization and Community Engagement
By enabling non-Haskell node tooling, Pallas strengthens client diversity—a core pillar of decentralization. The project is openly developed and maintained by long-standing contributors within the Cardano open-source ecosystem.

Responsible Treasury Spending
This proposal is well-scoped and targets essential maintenance of foundational infrastructure. At ₳220,914, we view this as responsible treasury spending that reinforces both decentralization and developer inclusion.

Long-Term Sustainability
OpShin brings smart contract development in Python to Cardano, expanding the network’s technical accessibility and lowering barriers for long-term developer onboarding. It aligns with efforts to diversify contract tooling beyond Haskell and Plutus.

Builder and Ecosystem Growth
By enabling a Python-based DSL for writing smart contracts, OpShin empowers a global pool of Python developers to contribute to the Cardano ecosystem. This promotes growth through broader language support and smoother dApp experimentation.

Decentralization and Community Engagement
The project is open-source and community-aligned, giving independent developers an alternative to Plutus. Supporting language diversity fosters decentralized innovation and reduces dependence on a single toolchain.

Responsible Treasury Spending
The requested ₳199,911 is proportionate to the technical scope and community impact. With active development, real deliverables, and strong ecosystem interest, we consider this a responsible and strategically inclusive use of treasury funds.

Long-Term Sustainability
Plutarch is a performant, typed DSL for writing Plutus smart contracts, aimed at improving safety, composability, and on-chain efficiency. Maintaining it contributes directly to the robustness of Cardano’s smart contract layer.

Builder and Ecosystem Growth
This tool enables developers to write safer and more optimized smart contracts with lower execution costs. Supporting Plutarch encourages best practices and unlocks more advanced dApp architectures.

Decentralization and Community Engagement
As an open-source alternative maintained by MLabs, Plutarch strengthens developer choice and fosters innovation outside of IOG-led tooling. It helps diversify contract development pathways within the ecosystem.

Responsible Treasury Spending
The budget is appropriate for sustaining critical tooling that serves multiple builders. It’s a targeted investment with ecosystem-wide benefit, making this responsible and technically strategic treasury funding.

Long-Term Sustainability
Cexplorer is a reliable, widely-used explorer that enhances transparency and infrastructure diversity. Funding its continued development contributes to Cardano’s ecosystem resilience by reducing overdependence on any single provider.

Builder and Ecosystem Growth
Cexplorer offers developer-centric features such as detailed stake pool insights, script views, and address tracking, making it a key tool for both experienced and new builders. Its focus on functionality over vanity adds practical value to the developer experience.

Decentralization and Community Engagement
Maintaining an independent explorer supports decentralization by offering users and developers more choice and trust-minimized access to chain data. Its consistent presence in the community strengthens transparency and self-sovereign interaction with the network.

Responsible Treasury Spending
This is a modest, targeted request with clear and ongoing utility. The team is known, the product is live, and the value is tangible. We consider this responsible treasury spending that delivers high impact relative to cost.

Long-Term Sustainability
Cardano.nix is a foundational infrastructure tool that enables reproducible, reliable builds for node software and other ecosystem components. Maintaining it helps ensure deterministic deployment across environments, which supports long-term stability.

Builder and Ecosystem Growth
This tool is widely used by developers and SPOs for configuration, testing, and deployment. Keeping it current reduces operational friction and accelerates builder productivity across the network.

Decentralization and Community Engagement
Cardano.nix is open-source and maintained by MLabs, a reputable ecosystem contributor. Its transparent development and community usage reflect healthy decentralization and collaboration practices.

Responsible Treasury Spending
At ₳45,217, this is a low-cost, high-utility maintenance request. The scope is clear, impact is proven, and the funding is well-targeted. We consider this highly responsible treasury spending.

Long-Term Sustainability
This proposal supports the development of a zero-knowledge rollup framework tailored for Cardano, aligning with the network’s need for scalable, trust-minimized infrastructure. zkFold advances Cardano’s Layer 2 strategy by integrating cutting-edge cryptographic techniques.

Builder and Ecosystem Growth
If successful, zkFold will provide developers with a powerful toolset for deploying high-throughput, low-cost applications. It expands the execution environment available to builders and strengthens Cardano’s position in the broader ZK ecosystem.

Decentralization and Community Engagement
The design emphasizes permissionless rollup deployment and integration with Cardano’s consensus, which supports decentralization. However, community involvement in development and specification remains minimal and should be improved.

Responsible Treasury Spending
The ₳1.16M request is significant for a project in early stages and lacks clear deliverables, milestones, or a breakdown of what the funds cover. We support the concept, but require milestone-based disbursement, public dev updates, and clear definitions of success. Treasury funds should be tied to verifiable outputs, especially for experimental cryptographic infrastructure.