Voting YES

I scored this proposal using my own public rulebook and scoring system, which is available here: Cardano DRep Commercial Treasury Rule Book v11 – v11 Intelligent Risk, Protected Infrastructure & Ecosystem Coordination Edition (https://docs.google.com/document/d/1NzqqbqteMl_ZLta3_p-05nZfyyNvsuptCPzTZIsW1lc/edit?usp=sharing). The document is still evolving, but it reflects how I assess commercial and hybrid Treasury proposals.

I use AI assistance in this process because I want a scoring method that I can apply as neutrally and consistently as possible across the large number of proposals requesting funding. AI does not make the decision for me. It helps me structure the review, test the proposal against the same criteria, and spot issues I may otherwise miss. When a proposal is borderline, I look at it even more closely.

Vote: Yes. I started this assessment from zero and made the proposal earn every point. Blockfrost clears the bar because Cardano receives a real public asset, not just a promise of future ecosystem benefit. The proposal asks for ₳9,832,979 to move Blockfrost into a free, community-governed not-for-profit, with source code, trademarks, domains, and associated assets transferred into community stewardship. Blockfrost already matters to Cardano builders: the proposal reports heavy API usage, widespread developer adoption, more than 100 Icebreakers, and more than 50% of transactions submitted through Blockfrost in most epochs. The team also has strong public delivery evidence: its earlier Catalyst proposal to open-source Blockfrost is marked complete, IOG announced a strategic investment in Blockfrost in 2024 to support decentralization, and the Blockfrost GitHub organization shows active public repositories. The ask is large, and the sustainability model still depends on the future board choosing the right commercial or vendor-backed structure. That lowers the score. But the proposal still reaches a plain Yes because the main Treasury return is not speculative revenue. It is the transfer of critical access infrastructure into community-governed public ownership, supported by milestones, third-party assurance, public reporting, refund rules, and smart-contract-based fund administration.

Voting NO based on my current voting framework

I scored this proposal using my own public rulebook and scoring system: Cardano DRep Commercial Treasury Rule Book v11 – Intelligent Risk, Protected Infrastructure & Ecosystem Coordination Edition. The document is still evolving, but it reflects how I assess commercial and hybrid Treasury proposals.

I use AI assistance in this process because I want a scoring method that I can apply as neutrally and consistently as possible across the large number of proposals requesting funding. AI does not make the decision for me. It helps me structure the review, test the proposal against the same criteria, and spot issues I may otherwise miss. When a proposal is borderline, I look at it even more closely.

I would vote No / Revise and Resubmit. Eternl is a real and important Cardano wallet, not a speculative startup. The Chrome listing shows 100,000 users and a July 1, 2026 update, Google Play also shows a July 1, 2026 update, and Cardano’s own app directory describes Eternl as a power-user wallet for browser and mobile. Prior Catalyst records show strong delivery: Enable Eternl, Evolve Eternl, Translate Eternl, Enable Eternl F10, and Accessible Multi-sig F10 are marked complete. But v11 raises the bar for closed or protected infrastructure. Eternl does not justify the closed main UI as legally, security, privacy, custody, or compliance sensitive. It keeps the main commercial product closed, excludes service-fee revenue from repayment, and asks for a large non-milestone runway payment. The repayment promise is better than a plain grant, but it depends on future Pro-plan surplus and lacks hard enforcement. The proposal adds public fund-use audits and on-chain Pro-plan reporting, which helps. It still does not give Cardano enough open infrastructure, neutral access, binding upside, or downside control for ₳2,350,000.

Voting NO as submitted

I scored this proposal using my own public rulebook and scoring system, which is available here: Cardano DRep Commercial Treasury Rule Book v9 – Intelligent Risk Edition (https://docs.google.com/document/d/13EcIlJguBz-MJv91a3YYtb8O96K8uf9B9AOHsDOxeVE/edit?usp=sharing). The document is still evolving, but it reflects how I assess commercial and hybrid Treasury proposals.

I use AI assistance in this process because I want a scoring method that I can apply as neutrally and consistently as possible across the large number of proposals requesting funding. AI does not make the decision for me. It helps me structure the review, test the proposal against the same criteria, and spot issues I may otherwise miss. When a proposal is borderline, I look at it even more closely.

Rationale: I would vote No as submitted. Strike is a real Cardano DeFi product with meaningful traction, public smart-contract repositories, and a serious market thesis for Cardano-native perpetuals. The proposal also uses a better instrument than a grant because the Treasury would own the deployed liquidity position and receive returned yield. But the ask is still too large and too risky for the controls offered. It sells 9,000,000 ADA into USDM, exposes the Treasury to ADA upside loss, stablecoin risk, smart-contract risk, operational custody risk, derivatives-market risk, and protocol-specific execution risk, while giving Strike significant competitive liquidity advantage over other Cardano DeFi venues. Current public DeFiLlama data apparently shows lower cumulative volume and revenue than the proposal claims, so an independent reconciliation might be needed before trusting the headline figures (if this is correct) . The audit and assurance structure is also not strong enough for a deployment of this size, the drawdown triggers are too soft, and the proposal does not provide first-loss capital from Strike or other private parties. I like the direction and would reconsider a smaller, capped pilot with completed audit, enforceable custody documents, hard exit rights, independent reporting, wash-trading exclusions, and private first-loss protection. For this version, the risk-adjusted value is not good enough for the Cardano Treasury.

Scoring Table

Voting NO as it currently stands

I scored this proposal using my own public rulebook and scoring system: Cardano DRep Commercial Treasury Rule Book v11 – Intelligent Risk, Protected Infrastructure & Ecosystem Coordination Edition. The rulebook is still evolving, but it reflects how I assess commercial, hybrid, ecosystem-coordination, and strategic Treasury proposals.

I use AI assistance in this process because I want a scoring method that I can apply as neutrally and consistently as possible across the large number of proposals requesting funding. AI does not make the decision for me. It helps me structure the review, test the proposal against the same criteria, and spot issues I may otherwise miss. When a proposal is borderline, I look at it even more closely.

I would vote No / Revise and Resubmit. Cardano Builder DAO has delivered real work. It ran two funding rounds, funded 34 companies with roughly 11 million ADA, used smart-contract-governed treasury execution, improved its governance documents, and returned 354,790 ADA of unused funds after Round 2. The Cardano developer portal also lists Builder DAO as a smart-contract-governed funding path with KPI reporting expectations. But v11 sets a much higher bar for a very large repeat allocation, and says such proposals should need exceptional terms, strong treasury return, independent review, and very low upfront risk. This proposal asks the Treasury to fund another allocator, not to approve the final recipient projects directly. It gives Cardano public governance records, dashboards, reports, and possible KPI growth, but it does not give the Treasury repayment, revenue share, warrants, treasury-owned assets, matched capital, or enforceable upside from the commercial value created. v11 treats weak or unenforceable upside as a serious defect, especially where public money may fund private upside. The Code of Conduct also says a member’s vote on its own treasury withdrawal application is not treated as a conflict, which may fit the DAO’s internal design but still creates structural self-allocation risk for public funds. The milestones verify process more than retained ecosystem outcomes. The KPI system is improving, but the proposal still lacks strong causal attribution, hard anti-gaming rules, recipient-level DRep review, clawbacks, and a credible sustainability path after Treasury funding. Cardano’s Treasury is finite. At 20 million ADA, this is useful but not yet a good enough deal.

Voting NO as currently offered

I scored this proposal using my own public rulebook and scoring system, which is available here: Cardano DRep Commercial Treasury Rule Book v11 – Intelligent Risk, Protected Infrastructure & Ecosystem Coordination Edition (https://docs.google.com/document/d/13EcIlJguBz-MJv91a3YYtb8O96K8uf9B9AOHsDOxeVE/edit?usp=sharing). The document is still evolving, but it reflects how I assess commercial and hybrid Treasury proposals.

I use AI assistance in this process because I want a scoring method that I can apply as neutrally and consistently as possible across the large number of proposals requesting funding. AI does not make the decision for me. It helps me structure the review, test the proposal against the same criteria, and spot issues I may otherwise miss. When a proposal is borderline, I look at it even more closely.

I do not support this withdrawal as submitted. The proposal has a real adoption case. Sellout is an operating ticketing company, Anvil has a visible Cardano delivery record, Phase 1 is already claimed live, and ticketing is a useful non-speculative use case for Cardano. I give the team credit for that. But v11 treats this as a very large commercial/hybrid request, not a simple adoption grant. The proposal asks for ₳4,969,231, keeps most of the customer relationship and commercial upside private, and does not give Cardano enough firm public-asset rights. The revenue share is meaningful, but the exact revenue base, receiving vehicle, cadence, and enforcement details are still pushed into M1 contracting. That is not strong enough before a vote of this size. The marketing portion also fails v11 price discipline because it lacks rate cards, vendor quotes, reusable public content/data rights, and hard retained-impact thresholds. Milestone gating, an audit, public dashboards, and Intersect/Sundae-style administration reduce risk, but they do not fix private capture, weak open-source/public-asset terms, or the opportunity cost. I would vote No / Revise and Resubmit. I would reconsider a smaller staged version with binding revenue-share terms before enactment, clear clawbacks, a public/open or protected-components schedule, independent KPI source data, stronger continuity rights, and benchmarked marketing spend.

v11 classification

General Investor-Hard Scorecard — non-marketing software/commercial portion

Appendix A — Marketing & Adoption Scorecard for the separable marketing spend

Combined v11 result

Voting NO as submitted

I scored this proposal using my own public rulebook and scoring system, which is available here: Cardano DRep Commercial Treasury Rule Book v9 – Intelligent Risk Edition (https://docs.google.com/document/d/13EcIlJguBz-MJv91a3YYtb8O96K8uf9B9AOHsDOxeVE/edit?usp=sharing). The document is still evolving, but it reflects how I assess commercial and hybrid Treasury proposals.

I use AI assistance in this process because I want a scoring method that I can apply as neutrally and consistently as possible across the large number of proposals requesting funding. AI does not make the decision for me. It helps me structure the review, test the proposal against the same criteria, and spot issues I may otherwise miss. When a proposal is borderline, I look at it even more closely.

Rationale: I do not support this proposal in its current form. Alchemy targets a real gap: Cardano needs credible Bitcoin liquidity and reusable BTCfi infrastructure, and the proposal offers useful public pieces such as reserve reporting, SDKs, dashboards, audits, integrations, staged treasury-owned launch liquidity, ADA price protection, and quarterly return of treasury liquidity yield. The market thesis is also credible; Strategy reported large STRC proceeds and daily volume, and Strive has moved into daily SATA preferred dividends, so structured Bitcoin exposure is not fantasy. The team is not vaporware either: Sundial has an active Fund13 Catalyst project with 4 of 6 milestones completed and ₳1,148,250 already distributed, and Charms has public MIT-licensed Bitcoin/Cardano code. But the ask is too large for the current proof. This is a ₳10,000,000 request for a novel structured BTC protocol whose reserve model, Charms dependency, oracle path, accounting, custody/locker design, regulatory treatment, fund administration, and real user demand are not yet independently proven. I give credit for staging, audits, dashboards, rollover language, and treasury-owned liquidity, but the Treasury still takes meaningful first-loss and execution risk while receiving no binding fee share, revenue share, warrants, equity-like rights, hard repayment right, or treasury-controlled exit beyond a later governance vote after a $60M TVL condition. I also weigh Sundial’s own Fund13 statement that it would make no future attempts to draw from Catalyst or the Cardano treasury and community; even if Alchemy is a different structure, that weakens confidence in sizing discipline. Given the opportunity cost, including alternatives like the Orion Fund’s equity-first mandate for Cardano-native institutional DeFi and Bitcoin/Cardano liquidity, I would vote No / revise and resubmit unless the ask is reduced, private capital takes more first-loss risk, and Cardano receives enforceable upside plus clearer legal, custody, audit, and exit controls.

Classification: Hybrid public/commercial BTCfi infrastructure, liquidity deployment, and tokenized protocol growth. I used the general investor-hard scorecard, not the marketing appendix.

Voting NO, updated rationale

Wirex Treasury Withdrawal Score: 51 / 100

I scored this proposal using my own public rulebook and scoring system, which is available here: Cardano DRep Commercial Treasury Rule Book v9 – Intelligent Risk Edition (https://docs.google.com/document/d/13EcIlJguBz-MJv91a3YYtb8O96K8uf9B9AOHsDOxeVE/edit?usp=sharing). The document is still evolving, but it reflects how I assess commercial and hybrid Treasury proposals.

I use AI assistance in this process because I want a scoring method that I can apply as neutrally and consistently as possible across the large number of proposals requesting funding. AI does not make the decision for me. It helps me structure the review, test the proposal against the same criteria, and spot issues I may otherwise miss. When a proposal is borderline, I look at it even more closely.

I score this proposal low because it asks the Cardano Treasury to fund a commercial payments product without giving Cardano enough enforceable return. Wirex looks capable, and payments are a real gap for Cardano, but the proposal does not clearly lock down the open-source assets, access rights, maintenance duties, revenue share, repayment terms, or clawbacks. In plain terms, the Treasury takes the risk while Wirex keeps most of the upside.

ABSTAIN

I am not fully convinced this is absolutely necessary, so I will abstain from voting.

Last year I voted YES for Intersect. This year I will abstain on voting on Intersect MBO proposals.

I am not convinced. I admit I might be misunderstanding the wider situation (Cardano without Intersect) and will leave the decision to other DReps. Next year I might vote NO if the organization cannot easily prove that all of its structures are worth it.
It is not news to Intersect, but Intersect is too dependent on the Treasury, which means it is on a very risky path. I would like to see a plan for a minimal Intersect. Like Minimal Djed. An Intersect without the nice to haves.
If the current structure is ideal, it doesn't need reform. It probably is not, so it needs further reform and to cut the number of committees and activities to essential ones.

Last year I voted YES for Intersect. This year I will abstain on voting on Intersect MBO proposals.

I am not convinced. I admit I might be misunderstanding the wider situation (Cardano without Intersect) and will leave the decision to other DReps. Next year I might vote NO if the organization cannot easily prove that all of its structures are worth it.
It is not news to Intersect, but Intersect is too dependent on the Treasury, which means it is on a very risky path. I would like to see a plan for a minimal Intersect. Like Minimal Djed. An Intersect without the nice to haves.
If the current structure is ideal, it doesn't need reform. It probably is not, so it needs further reform and to cut the number of committees and activities to essential ones.

Voting NO. Not urgent.

I vote No. Governance has sucked out a lot of air from the Cardano space. Its July 2026. Lets focus on using the platforms and products we have now - for a few months.

I don't even have time to use Cardano with all these governance actions dropping. Many users are just reading and debating the latest governance proposals.

Voting NO as the package is too much - would vote YES for a resubmitted version (details below)

DRep Assessment Rationale

I am using a personal Cardano DRep Commercial Treasury Rule Book v6 that I created to reflect some of my thinking and help me assess commercial and commercial/hybrid proposals more consistently.

This framework may still evolve. I am being assisted with AI in this process because I want to create a process that I can apply relatively neutrally across the large number of proposals requesting funding. If a proposal is borderline, I will look at it even more closely.

The document is here:
https://docs.google.com/document/d/1fXaNY3L8oGWEGJmMubTKn7FnyhXCzOhiophXzFQFC_c/edit?usp=sharing

Assessment

I think Work Package 3 (WP3): American Options is currently the weakest and riskiest part of the proposal. It probably has the highest market-adoption risk. I would vote No on a proposal that includes WP3.

WP1 and WP4 are much cleaner public infrastructure.

• WP1 maintains DeFi Kernel as a public standard.
• WP4 gives wallets, bots, indexers, and dApps SDK tooling.

WP2 is still commercial, but it is the better product bet. Leveraged spot trading has a clearer user story than American options.

Scorecard

Conditional Support Terms

I would consider Conditional Support only if the proposal were revised to include the following terms as binding conditions, not merely as general intentions.

WP1 and WP4 should be true public assets

The registry, SDK, adapters, schemas, documentation, examples, and related tooling should be published in public repositories under a permissive license such as MIT or Apache-2.0, with clear documentation, tests where applicable, tagged releases, and practical fork rights before final payment.

WP2 should provide stronger Treasury upside

The current 5% protocol-fee return for 12 months is not enough for a Treasury-funded commercial DeFi primitive. I would want either a longer protocol-fee share, a higher fee share from the Treasury-funded leverage product, a repayment trigger, or another enforceable economic return to the Treasury.

Disbursement should be milestone-based with low upfront exposure

The proposal should define payment amounts per milestone, acceptance criteria, deadlines, evidence required, and failure rules. Upfront funding should be limited, especially for WP2.

Verification should be independent and evidence-based

Milestones should not rely only on applicant dashboards or self-reporting. Verification should use public repositories, audit reports, on-chain data, published script hashes, independent milestone review, and clear evidence that each deliverable was completed.

The trading-volume KPI should include an anti-wash covenant

The $1M rolling 30-day trading-volume KPI for WP2 should exclude related-party trading, subsidized trading, circular volume, bot farming, applicant-funded activity, rebate-driven usage, wash trading, and other artificial volume.

Security review should remain mandatory before mainnet release

WP2 involves leverage, collateral, borrowing, liquidation, and debt accounting. A bad design could harm users quickly.

Mainnet deployment should require a completed security review or audit, an issue-resolution report, and a rule that unresolved critical issues block release.

Plain-English Rationale

With WP3 removed, the proposal becomes focused enough to consider. It funds a public registry, reusable SDK tooling, and one serious DeFi primitive instead of trying to fund a full leverage-plus-options roadmap.

I would still not treat it as a normal grant. WP2 gives Dano commercial upside. The Treasury should receive stronger protection and stronger public assets.

Conditional yes if the open-source, milestone, anti-gaming, audit, and Treasury-upside terms are tightened.

Voting YES on the 5 TxPipe proposals.

I voted YES on 4 TXPipe proposals and NO on the TX3 proposal on Ekklesia. However, I have decided to vote YES on the TX3 proposal as well, as it adds a new interface description format for UTxO blockchain protocols, plus the associated tooling

Voting YES on the 5 TxPipe proposals.

I voted YES on 4 TXPipe proposals and NO on the TX3 proposal on Ekklesia. However, I have decided to vote YES on the TX3 proposal as well, as it adds a new interface description format for UTxO blockchain protocols, plus the associated tooling

Voting YES on the 5 TxPipe proposals.

I voted YES on 4 TXPipe proposals and NO on the TX3 proposal on Ekklesia. However, I have decided to vote YES on the TX3 proposal as well, as it adds a new interface description format for UTxO blockchain protocols, plus the associated tooling

Voting YES for the Hardware wallet maintenance proposal

This is a pretty important continuity proposal for ADA holders who use hardware wallets. Cardano is continuously undergoing a series of upgrades through softforks and hardforks. The wallets need to remain compatible with the newest versions of Cardano.

Voting YES on the 5 TxPipe proposals.

I voted YES on 4 TXPipe proposals and NO on the TX3 proposal on Ekklesia. However, I have decided to vote YES on the TX3 proposal as well, as it adds a new interface description format for UTxO blockchain protocols, plus the associated tooling

Voting YES on the 5 TxPipe proposals.

I voted YES on 4 TXPipe proposals and NO on the TX3 proposal on Ekklesia. However, I have decided to vote YES on the TX3 proposal as well, as it adds a new interface description format for UTxO blockchain protocols, plus the associated tooling

This Mithril proposal builds on the strengths of Cardano's infrastructure, allowing for significant improvements in the user experience. I have already voted YES for this proposal on the Ekklesia voting platform. This is just a confirmation of that YES vote.

Daedalus is not the leading Cardano wallet today. It spent years on the backburner, so it fell behind on speed, features, and user experience.
A faster Daedalus, improved in stages, could win back a meaningful share of users. The SecondFi wallet fumble reminded people why wallet architecture matters. Convenience is not enough if it adds hidden trust assumptions. Users need options that reduce dependence on companies, servers, and third-party backends. The fewer trust points Cardano requires, the stronger its global adoption case becomes.
Daedalus is a flagbearer for Cardano’s original values. It tells ADA holders that self-custody should mean more than holding a seed phrase inside someone else’s interface. A normal user should be able to connect directly to Cardano, validate the chain, and avoid middlemen where possible.
That is the point of an efficient financial operating system. It should reduce middlemen. It should help people take personal responsibility while lowering their risk.
Daedalus is collective insurance for individual users. Today, that may mean thousands of users. If Daedalus becomes faster, easier, and more capable, it could serve far more. The proposed upgrades [hard-fork readiness, more hardware wallet support, CIP-30 (to unlock DeFi and dApp access for full-node users), Japanese localisation, and continued full-node support] give Daedalus a real chance to regain relevance.
Daedalus downloads and validates the Cardano blockchain itself. It gives users a direct relationship with the chain. In an era of speculation, short attention spans, and convenience-first products, Cardano risks losing a key building block of its financial OS.
Daedalus is Cardano’s home terminal. It lets users verify and interact with the chain without asking permission from a middleman. That is secure home banking and it's worth preserving. Daedalus may not be the most popular wallet today, but it represents the kind of financial independence Cardano should still fight for.

Voting ABSTAIN as I am developing a more structured approach to Commercial and Hybrid proposals

I'm working on my own rulebook (+ scoring framework) for assessing Commercial (and Hybrid) Treasury Withdrawal requests.

I need more structure.

I will change my votes to Abstain on all such active proposals at this moment.
Sharing latest rulebook v4 doc (link in tweet below):

https://docs.google.com/document/d/1xp9jkdT23bVy1igj4HeCVKjdHvAcPhjtM1zlMtKzGUo/edit?usp=sharing

Voting ABSTAIN as I am developing a more structured approach to Commercial and Hybrid proposals

I'm working on my own rulebook (+ scoring framework) for assessing Commercial (and Hybrid) Treasury Withdrawal requests.

I need more structure.

I will change my votes to Abstain on all such active proposals.

Sharing latest rulebook v4 doc (link in tweet below):

https://docs.google.com/document/d/1xp9jkdT23bVy1igj4HeCVKjdHvAcPhjtM1zlMtKzGUo/edit?usp=sharing

Voting YES for the Hard Fork

If at least 85% of stake pools by active stake upgrade to the version of the node, I so no reason to block it.

I ABSTAIN as I don't see this as a comprehensive proposal yet, but on the other hand I welcome debate on Reforming Treasury Governance

I welcome initiatives to improve processes. Many of the diagnostic elements in this governance action are evidently true. The proposed solution does have some suggestions for improvement. Some of the proposed ideas for improvement make sense - but this is not a concrete implementation and the proposer admits it is beyond scope here.

So, as it contains a snapshot of the situation and some elements that are food for further thought, I abstain.

I would point out that there are no experts who can actually transpose success to Cardano and it is hard to enlist such experts in the expert commission. The term expert commission might be alluring and might comfort us.

Domain expertise in a group of experts will not naturally result in a comprehensive strategy that is coherent. Like having an expert for car brakes, an expert for tires and an expert for headlights and an expert for interior design - who may all disagree on the best model of car that should be developed for the market. When do we have all the necessary experts on board? What if we miss the raw materials expert, the marketing expert, the human resources expert, the foreign trade expert, the business expert, the distribution network expert, the fuel expert, etc... It is hard to develop things by committee.

Essentially, this is a field where things are pretty tricky. We have had some projects developed on Cardano by extremely expert people and they failed to lead to adoption. So, I remain skeptical about proposals until they convince me. The expert commission does not convince me.

Voting YES on Hydra

Lots of legitimate talk about Infra dominance in the Treasury Withdrawals of 2026. I'm a small DRep unlikely tp sway the vote. I think the infra aspect is dominating because of a perception 9right or wrong) that Cardano is doomed with the current infrastructure - if it does not a more robust, more powerful version of itself that can at least theoretically offer a path for long-term sustainability. Yes, we are currently not maxing out our blocks, but what if we were maxing out our blocks in 3-4 months. The Cardano can't scale headlines start all over again.

Now back to this proposal, I voted NO on the bundled Hydra + Midgard proposal stating that Midgard needed to catch up to declared MVP stage and Mainnet readiness stage from earlier funding proposals. As this proposal is for Hydra only and expands the practical capabilities of Cardano in a unique way - while also benefiting teams that are using Hydra right now, I vote Yes.

Previously I voted NO, as the proposer did not include easy instructions for me to verify it is the same proposer (as I asked in the governance info action that I voted YES on).
I've seen a few helpful posts on X confirming that the proposer of this Treasury Withdrawal controls the same stake address as the proposer of the Ikigai proposal. However, there were too many proposals this time around and I didn't have a simple way of independently verifying it fast.
The easiest way to verify that the same address was used to submit the original Ikigai action and the current treasury withdrawal was sent to me by the Tempo Vote team.

1. The Stake address used to submit the original Ikigai proposal is
   stake1uys93fhep4lc2u6lu0q09kcxayxzthasded35c0x0w60ugc9s0cm5
   This can be verified on AdaStat (older design) at:
   https://adastat.net/governances/59fd353253eb177e2104e8f23ea4c63e3d32ef95c7865d03e90d3884424dc1db00
2. The stake address to submit this current Treasury Withdrawal is also
   stake1uys93fhep4lc2u6lu0q09kcxayxzthasded35c0x0w60ugc9s0cm5
   This can be verified on Tempo.Vote on the following link (click on the Metadata tab):
   https://tempo.vote/governance-action?governanceActionId=d52a4917df4f91c342eaf06ebb4c0a5c3156f6412d137f307cc77eb911f47ab1%230
   Shoutout to DRep LongHo of the Tempo vote who took the time to explain to me how I can verify it independently. He added: "It would be an oversight not to point this out, as it may help the original proposer recover funds that they should have received back months ago. Thank you 🙏"
   So, as this may help other DReps, I am including the instructions above - allowing a simple verification by every DRep.
   Long Ho is a DRep:
   https://forum.cardano.org/t/long-h-individual-introduction/143212
   His DRep ID: drep166gcv68vrh3qmgeprvzxkjqnpc5a5nuzu56xa8fauydyvmllfnv
   Using Tempo.Vote to change my vote to YES

Voting YES for a reduction of the committeeMinSize parameter from 7 to 5

This proposal makes sense in the current governance environment. CC positions are not being compensated, there are very many GA proposals. CC members must be tired already and it is only a matter of time before a new CC member resigns.

We do not have the luxury of time in case of a resignation. I have also consulted one of the current CC members about their own opinion on the merits of this action.

I voted NO on the original proposal. Voting YES on the new submitted proposal as I think TWEAG correctly understood the desire of the wider DRep body.

Tweag has resubmitted the proposal with a much narrower scope. It now focuses on the core work many DReps asked for: getting Peras v1 to mainnet, supported by History Expiry and conformance testing.

I noticed that the original (rejected) 2026-2028 proposal had a work package for Peras v1 ready-to-mainnet that was worth ₳4,954,688.00. The new, slimmer 2026-2027 proposal for the Peras v1 ready for the mainnet and support work package is at ₳10,586,720

A Tweag team member [ https://x.com/qnikst/status/2062302581053882688?s=20 ] has responded to my question on X to clarify that the new Peras v1 ready for the mainnet proposal segment now includes: not only making Peras v1 MVP mainnet ready, but also tech support and SPO support, and development of the dropped tasks until Apr 2027. The addition of Tech support and SPO support is reasonable as consensus upgrade needs live operational support.

This also explains why the new Peras v1 budget includes the 10-week post-release maintenance milestone.

Overall, voting early - - for fast finality of this proposal and so that Peras can be delivered sooner.

Changing my vote to ABSTAIN for the time being as there are seemingly some changes that are not backwards-compatible, according to votes from other DReps.

This means I need to look into what this means as a precedent - in more detail instead of relying only on a technical assessment by the Intersect Parameter Committee as I did in my original YES vote.

TL;DR: I don't want to help adopt of this proposal until I look at the circumstances in more detail. If I am unable to come to a different decision, my ABSTAIN will remain in effect.

I cannot support treasury withdrawals where EMURGO is a direct beneficiary while the EMURGO Group and the Yoroi DRep continue to benefit from self-preferential governance delegation inside Yoroi wallet. Cardano governance is stake-weighted. Wallet design therefore matters. Yoroi is the largest DRep by delegated voting power and still steers users toward its own DRep during staking - despite claiming on March 16, 2026: We will pause DRep delegation within Yoroi.
Yoroi wallet browser extension still tells its users at the moment when they choose an SPO that they can "save time and fees by delegating to our Yoroi DRep". This is a fact as of 27 May 2026 as I personally verified this in a Yoroi browser extension with a new wallet that was not staked to any SPO.
This situation with Emurgo and Yoroi creates a serious conflict of interest when treasury withdrawals that benefit them require DRep approval.
Yoroi should present neutral DRep discovery, equal options, clear disclosures, and public metrics showing whether affiliated voting power is being reduced.
Until EMURGO makes real progress on this, I will vote No on treasury withdrawals that make EMURGO a beneficiary. I will reassess EMURGO’s progress on 1 June 2027.
Screenshot of Yoroi wallet prompt: https://x.com/InputEndorsers/status/2059290418064277960?s=20

Voting YES

Cardano’s edge is still security, formal methods, eUTXO, and hard infrastructure. Adoption is a bit like unemployment: tough to influence directly as it depends on the macro and on the health of the underlying system. This proposal works on that system, longer term. I do not think there is a magic button for adoption right now. I am not for throwing everything at the wall just to boost transaction volume, because that tends to end badly. Even if adoption only grows gradually in 2026, Cardano is not doomed. Cardano still lacks enough serious monetary research, which would be useful for a protocol aspiring to become hard money. Some streams will likely fail or prove marginal. That is fine only if IO cuts weak work early and redirects effort to what shows a clear path to a CIP, prototype, benchmark, or engineering handoff. I don't feel comfortable pre-selecting research streams, as unexpected hurdles can be found in the ones that seem closest at hand and unexpected breakthroughs may emerge where we don't expect them. However, this is a Yes, not a blank cheque. I also propose to IO to set the highest transparency standard in the ecosystem. That discipline will make the Treasury last longer for everyone.

Sorry NO, too much requested, too long of a timeline, still unproven.

This asks for too much money too early. The proposed structure is still unproven. Cardano should not commit ₳12 million over three years before all key components have been validated. Maybe start much smaller. I want to see support for this exact scope and structure and plan from independent maintainers, affected projects, other ecosystem stakeholders

Voting NO

Scalus appears to have delivered most of its 2025 proposal, which was focused on the developer workflow. The team is talented and is pushing the Bifrost bridge with Fluid Tokens.
The 2026 Cardano Treasury already funded Amaru and Dingo, and Gerolamo is possibly also in the mix for 2026. So I do not think we have room for another large L1-node workstream in 2026. There is a limit to what the Treasury can responsibly fund in one cycle - especially with the future maintenance coming down the line later.
Scalus still looks useful. Cardano needs more application-layer leverage, and Scalus can help teams build serious apps faster. But in 2026, it should sit above the node projects, not become another one in 2026. Given the funding reality we have right now, there might be room for a narrower Scalus proposal focused on the application layer - if this does not pass. Keep in mind I lean conservative with the spending.

Voting NO

I voted NO on the Eternl maintenance proposal last year and am voting NO this year. I like Eternl wallet. But I don't think the treasury should finance the operations, maintenance, and improvements costs for a closed source light wallet, regardless of how good it is. We are not in the early Cardano days any more. There are multiple light wallets in the ecosystem in this segment. Some are also open source. I would probably have to lean towards approving other requests from many other light wallets wallets, if I said Yes to this withdrawal.

There is sparse competition in the full node wallet segment, so I will assess the Daedalus proposal separately - as it also offers additional security guarantees for users.

Voting NO to this proposal

This is actually an interesting “real-world adoption” proposal that identified a concrete export problem, in a real market. I actually know about the difficulties that Vietnam and other exporters face when trying to break into the Chinese market and this is actually a real issue. The strict quality monitoring - traceability issue is real. Clearly, there is also abuse in the form of fraud and compliance problems.

One key concern for me is the Bio-ID system reliability at scale - it is used for telling durian fruits - one from another. Bio-ID is OriLife’s idea that the product itself becomes the identifier. For durian, the system claims to use the fruit’s rind surface micro-pattern as a biological fingerprint.
The document also says that implementation details, proprietary biometric algorithms and internal engineering specifications are excluded. Essentially, we do not get the information needed to judge Bio-ID scientifically. I mean - this is a bit of a wild bet on a system that has many chances to fail. Identifying one durian in a demo is not the same as identifying 180 million fruits per season under messy field conditions: dirt, lighting, rain, handling damage, ripening changes, camera differences, etc...
Claims of 100% precision / zero false positives can depend on the testing or internal testing environment.
Bio-ID is the heart of the proposal. Even if it were fail safe, Bio-ID would make identity inseparable from the fruit after registration, but it does not by itself prove that the first registration happened honestly, at the right farm, by the right person, under the right growing-area code. Essentially, this is really outside of the scope of Cardano Treasury funding, for me personally.

My view is usually if this Cardano integration is of significant commercial interest for durian exporters and it does make sense for Vietnam due to the huge Chinese market, it makes sense for Vietnamese players to invest and use Cardano do achieve this. It does not make sense for Cardano Treasury to allocate funds to this project.

Voting YES

I support both HLabs proposals - part of as public infrastructure, not just private product work. But I do appreciate their original approach too.

The Pebble and TypeScript maintenance proposal funds tools and libraries that Cardano builders already use, and it helps keep that stack working through protocol upgrades. Pebble also gives Cardano a more familiar path for TypeScript, JavaScript and Solidity-style developers, which matters if we want more people building here.

Gerolamo may be "riskier", but I think this is the kind of technical risk the Treasury should sometimes take. In my view a real Cardano node in the browser would be a strong differentiator. It could reduce dependence on centralised providers and give wallets and dApps a more trust-minimised way to interact with the chain. Not just a nice feature if it clicks properly.

The new split is also better than the original bundled proposal. I would not support risk for every proposal, but if Cardano wants to stand out, we need some carefully scoped bets like this. Here, one proposal supports infrastructure builders use today, while the other tries to create a real future-facing Cardano advantage. I like a bold attempt from time to time - if it clicks with me as a Cardano user. This is a joint review for both proposals.

Voting YES

I support both HLabs proposals - part of as public infrastructure, not just private product work. But I do appreciate their original approach too.

The Pebble and TypeScript maintenance proposal funds tools and libraries that Cardano builders already use, and it helps keep that stack working through protocol upgrades. Pebble also gives Cardano a more familiar path for TypeScript, JavaScript and Solidity-style developers, which matters if we want more people building here.

Gerolamo may be "riskier", but I think this is the kind of technical risk the Treasury should sometimes take. In my view a real Cardano node in the browser would be a strong differentiator. It could reduce dependence on centralised providers and give wallets and dApps a more trust-minimised way to interact with the chain. Not just a nice feature if it clicks properly.

The new split is also better than the original bundled proposal. I would not support risk for every proposal, but if Cardano wants to stand out, we need some carefully scoped bets like this. Here, one proposal supports infrastructure builders use today, while the other tries to create a real future-facing Cardano advantage. I like a bold attempt from time to time - if it clicks with me as a Cardano user.

Changing my Abstain vote to YES

I am changing my Abstain vote to a YES vote. The team behind this proposal has addressed most of my concerns from my rationale and I think they not only identify a real chokepoint for Cardano - based on feedback received from developer surveys - but they also have a plan how to tackle the issue. There are a lot of complaints about problems for existing builders working on Cardano right now (however we can hear those complaints loud and clear)- but we can't hear the complaints of the people who tried on their own, gave up and left. There is a lot of inward focus on teams who are here right now. Yes, they are our stars and building up the ecosystem. Data presented shows our environment is rich with senior heavy devs. We are not attracting junior devs who don't even enter... or give up as soon as they see the fragmented onboarding experience. Ultimately, I don't care who was responsible - what we need is to eliminate this lack of competition - or lack of inflow if you want - and a limited number of ideas circulating in a small circle of partners or rivals. Furthermore, this proposal is also fertile ground for cooperation among relevant people at IOG, CF and Intersect and others. From the feedback that I have received publicly over X to my questions - I see there is willingness to cooperate. Cardano will fail if everyone has to climb a mountain or devote months to learn how to start or must have a special talent to start building here. Lowering the entry bar will ultimately lower the costs for the ecosystem - that is what I want to see. This will also increase the value and utility of each and every tool that we have collectively financed so far. This is a public goods proposal that I can support as my original concerns have been sufficiently well addressed. I would advise the proposers to keep the collaboration spirit alive - a proposal like this will fail without it.

Pogun is ambitious, and I can see why BTC liquidity, credit and yield would be useful for Cardano. I also recognise that the proposal is not framed as a simple grant. It includes milestone-gated disbursement, refund clauses, quarterly reporting, a 20% EBITDA repayment mechanism until the USD funding amount is repaid, and then a 5% perpetual EBITDA return. That is more serious than a normal grant.

However, I am still not comfortable with the Treasury funding commercial products directly on these terms. This can tilt competition toward one team, distort the market, and create expectations that other commercial teams should also receive Treasury funding. In my view, the Treasury should be very careful about stepping into markets where private capital, users and product-market fit should normally decide winners.

There is also a negotiation imbalance. A commercial team can move quickly, negotiate clearly, and optimise terms for itself. The Treasury is a slower and more diffuse governance system. Once funding is approved, the Treasury may have limited ability to renegotiate terms later, so the protections need to be clear before approval, not worked out after the fact.

The proposal does include a Treasury return model, but I do not think the economic terms are tight enough for this type of commercial funding. If the return is based on EBITDA, the community needs a clearer definition of how EBITDA will be calculated, what costs can be deducted, how related-party costs are treated, and how the return is protected if the business later restructures, spins out products, changes ownership, or moves revenue into another entity. EBITDA can be shaped. Otherwise, the Treasury may have a headline return, but little real control over whether meaningful payments arrive.

I also think the open-source and infrastructure split needs to be clearer. The proposal says the credit market is open-source and composable, and later milestones mention documentation, open-source references and integration guides. That is positive. But for Treasury funding, I would still want a clearer separation between what becomes reusable Cardano infrastructure and what remains Pogun’s private commercial advantage. The bridge components, operator software, backend services, APIs, proof infrastructure, yield app and frontend should be treated explicitly.

The bridge operator model also needs more practical detail. The proposal describes a 1-of-N security model and says institutions can act as operators to protect their own assets. I want to understand who can realistically become an operator, what capital is required, what technical setup is required, what the bond or slashing rules are, and how operator onboarding works in practice. If the operator set is difficult for outsiders to join, then the bridge may be less open than the headline suggests.

The bridge is complex enough that I would also want independent technical review before later bridge funding is released, not only audits near launch or an infeasibility review after problems appear. The yield layer also needs more legal and compliance clarity, especially if it touches RWAs, private credit and structured fixed-income products.

So I am voting NO. The idea may be strong, and the proposal already has more guardrails than a normal grant. But I do not think the Treasury should fund a commercial product unless the terms, protections, public/private split, operator model and technical review process are much clearer. A path to a different vote would require a stronger explanation of why this should be funded by the Treasury rather than private capital and stronger protections if the Treasury is being asked to take commercial risk.

I’m voting ABSTAIN, but there is a path to YES.

I like this proposal, and also the new IO proposals more generally, because this is structured as a technical collaboration rather than a purely IO-internal build. IO, Lantr, Harmonic Labs, SAIB, Midgard Labs, TxPipe and No.Witness Labs are all involved. This kind of collaboration makes sense not only politically, but technically as well. This is a kind of mini-Cardano build fest under the hood too.

Teams can easily end up competing for funding instead of building together. This more collaborative approach from IO is commendable. I would encourage all participating teams to commit to hard milestone discipline. If this proposal is delivered well, it can become real public infrastructure for Cardano developers.

Blaster operating at the UPLC level is potentially very valuable long-term as Cardano gains more traction. Since UPLC is the common target for Cardano smart contract languages, this gives the work broader ecosystem value. Coverage for Aiken, Pebble, Scalus and Futura makes the proposal more ecosystem-wide. I would like to see clear acceptance criteria for what counts as a successful language integration.

The proposal also acknowledges that scaling Blaster from single-contract verification to multi-script DApp-level verification may be harder than expected. The adoption risk is also real.

The claim that formal verification directly addresses the security risk that deters institutional capital from Cardano DApps might be a bit overblown. It helps, but it is only one part of institutional confidence. Liquidity, audits, UX, stablecoins, custody and market depth also matter. However, security is becoming a bigger point of interest as AI makes vulnerability discovery and automated probing easier.

For me, the main things to clarify are long-term maintenance and real-world usage. Who maintains Blaster, CBDE and the language integrations after Q2 2027? Is this going to become a standing Treasury obligation? I ask because we are developing a lot of tools and infrastructure that seem to have ongoing costs. Is there room for the Cardano Foundation to be involved, or for Intersect to steward some of the public-good components?

I would also like the teams to provide evidence, before project closure, that non-IO developers can actually use the system in real development work. External developer testing and feedback should be part of the success criteria, not just promotion after delivery. If these points are incorporated into the milestones or reporting, I would be comfortable voting YES.

I'm sorry this kind of scope of a proposal 2026-2028 needs some kind of independent expert verification and support. It is supposed to drive Cardano into a certain direction and at a substantial cost.

Do you have any support for this scope of work either from the Cardano Foundation, IOG, Emurgo, Intersect technical experts, a very representative group of SPOs, a very representative group of Cardano builders, etc.?

I'm sorry, but just submitting this package as a whole is not enough without multiple third-party independent confirmation that this exact scope of work is needed and worthwhile. Not only desirable, but really worth the amount requested and that it meets Cardano's needs today.

Until such independent verification and confirmation is provided, I would be happy with the full delivery of the proposal approved last year: Withdraw ₳11,070,323 for TWEAG's Proposals for multiple core budget project

YES

I am voting YES on this proposal. It targets real Cardano usability issues: better wallet and DeFi fee models, a more resilient treasury design, and the ability for users to transact without first acquiring ADA.

CIP-159 can unlock micro-fees and better account-address functionality. Babel Fees on protocol level can remove a major onboarding friction for users coming with stablecoins or bridged BTC.

I had concerns about whether the Babel fees proposal did not look at previous implementations by FluidTokens or MLabs, the IO team responded the reviewed other implementation designs that were based on smart contract approaches [https://x.com/MichaelSmoIO/status/2050187840005275830?s=20 ] and opted for a new ledger primitive . I was worried about the Babel Fees MVP being too tied to one provider or wallet, but the team clarified [https://x.com/MichaelSmoIO/status/2050244374034825636?s=20] that it will include an open-source reference implementation and aims to become wallet-neutral and provider-neutral over time. I would still like that reflected clearly in the milestones, but overall this is a practical upgrade package worth funding.

NO, with path to YES

IO is requesting ₳62.1m from the Treasury for nine months of maintenance of the primary Cardano node implementation. Effectively, this is around $20m in annualised costs. I cannot justify approving this level of maintenance cost based on the detail currently given in the proposal.
I am voting NO on this proposal (there is a path to YES if it hinges on my vote), not because Cardano maintenance is optional. It clearly is not. The node, releases, security, testnets, monitoring and related infrastructure all need serious support.
My issue is that a ₳62.1m request for nine months is too large to approve without a clearer cost breakdown. I would want to see more detail on team size, rates, infrastructure costs, security and audit costs, overhead, and what is actually being delivered under each workstream. At the moment, too much is bundled together.
After almost a decade of Cardano being live, some ecosystem-facing services should gradually become more modular and open to competitive bidding. This proposal is not only about maintaining IO’s node implementation. It includes work that benefits the whole ecosystem, such as mainnet and mempool monitoring, testnet maintenance, disaster recovery, security support, Cardano Blueprint documentation, conformance testing, DB-Sync, API/CLI maintenance and support for future alternative node implementations. These are shared ecosystem costs, not just IO delivery costs.
That is why I think some of these ecosystem-facing parts should be separated more clearly and, where appropriate, co-funded by the Cardano Foundation. If they are properly scoped, other qualified teams could also bid for some of this work in future cycles. That would reduce dependence on one provider, improve accountability and give the treasury better price discovery.
Core maintenance should be funded, but not as a blank cheque. I would be much more comfortable with a revised proposal that has a clearer budget, clearer milestones, and more visible coordination between IO, relevant Intersect technical and assurance experts, and the Cardano Foundation. There should also be a clearer path for possible co-funding of ecosystem-facing parts. It is time to create a path for some of these bundled services to become less dependent on one provider over time.
I would vote YES, if the proposal is resubmitted with consideration given to the points above.

I am using the CF voting tool and it forces me to use this summary field "The summary field is mandatory". So this is just filler. Rationale is below.

I see a lot of unfinished business on Cardano itself that probably needs addressing relatively urgently now. SPO sustainability, scalability, overall chain sustainability, governance participation / hardening, delivery of all critical integrations and then their proper integration by projects building on Cardano, improving the end user experience for Cardano users, lowering the costs of the Haskell node work through competition, possibly BTC DeFi, among others. I just don't feel comfortable spending funds on marketing until fundamental issues are sorted out properly. Cardano seems semi-finished for a new user, with a lot of copies of narratives from other chains where they might be implemented better, and that is probably one reason why users are leaving. Right now, maybe even later, I do not see Treasury funds being used for event sponsorships as a wise use of the Treasury. Maybe it would make sense when Cardano is ready to offer a new, unique narrative and a new set of services to the crypto world. This seems to be a transition period during which Cardano is seeking how to carve out its role in the crypto world - and it is struggling. I would prefer to wait until a clear message on what Cardano is doing well - can be sent.
Separately from the merits of this specific proposal, I have a standing platform commitment to vote NO on EMURGO-related treasury withdrawals until March 15, 2027. That commitment is tied to unresolved concerns around the Yoroi wallet governance UI issue and the accumulation of DRep power through that soft nudging of wallet users. I acknowledge the announced effort by EMURGO and Yoroi to address this, but it has taken too long. The first Voltaire vote took place back in September 2024. As a result, I will use a sufficiently long period to assess whether this issue has been remedied properly.

I am using the CF voting tool and it forces me to use this summary field "The summary field is mandatory". So this is just filler. Rationale is below.

I see a lot of unfinished business on Cardano itself that probably needs addressing relatively urgently now. SPO sustainability, scalability, overall chain sustainability, governance participation / hardening, delivery of all critical integrations and then their proper integration by projects building on Cardano, improving the end user experience for Cardano users, lowering the costs of the Haskell node work through competition, possibly BTC DeFi, among others. I just don't feel comfortable spending funds on marketing until fundamental issues are sorted out properly. Cardano seems semi-finished for a new user, trying to copy narratives from other chains where they might be implemented better, and that is probably one reason why users are leaving. Right now, maybe even later, I do not see Treasury funds being used for event sponsorships as a wise use of the Treasury. Maybe it would make sense when Cardano is ready to offer a new, unique narrative and a new set of services to the crypto world while being ready to absorb a wave of new users. Right now we seem to be in a transition period during which Cardano is seeking how to carve out its role in the crypto world - and it is struggling. Part of the difficulty is related to decentralized governance and its ability or inability to coalesce around a strategic vision. I would prefer to wait until a clear message on what Cardano is doing well - can be sent, before we just market and promote Cardano - just because marketing is a thing to do.
Separately from the merits of this specific proposal, I have a standing platform commitment to vote NO on EMURGO-related treasury withdrawals until March 15, 2027. That commitment is tied to unresolved concerns around the Yoroi wallet governance UI issue and the accumulation of DRep power through that soft nudging of wallet users. I acknowledge the announced effort by EMURGO and Yoroi to address this, but it has taken too long. The first Voltaire vote took place back in September 2024. As a result, I will use a sufficiently long period to assess whether this issue has been remedied properly.

Having a Cardano Summit may be important, but trust in the Foundation is a bigger issue for me. I don't want to be in a position to second guess what the foundation presents to DReps. Unfortunately, I have to second guess now.
In the previous vote on the Cardano Summit I welcomed the proposal from the CF and Emurgo and voted No - one of the reasons was that the CF moved away from its own plan for achieving Cardano Summit sustainability that helped it get funding for the previous Cardano Summit. To me, this represents a breach of trust.
My point is that if the CF’s mandate is, broadly speaking, to support institutional adoption, Cardano usage and long-term sustainability, then this proposal undermines the very credibility the CF needs to perform that role.
It is difficult to reconcile the CF’s role as a credible institutional partner with its inability to maintain its own sustainability plan for a controlled event such as the Summit for even one year. Plans can change, and mistakes can happen. Not holding a Summit is not the end of the world.
I could understand a mistake. However, the Cardano Foundation tweeted the following on April 14, 2026: "We must be clear that there will be no modified Cardano Summit proposal. There simply isn't time on the calendar to reengineer an event of this size." That was just two weeks ago.
I am losing trust in the CF as a body that is able to present reliable and consistent information in support of its proposals. The tweet could reasonably be read as putting pressure on undecided DReps to vote YES by implying that there would otherwise be no Summit in 2026.
Finally, the proposal contains a revenue rollover mechanism, but not a credible, measurable path to Summit self-sustainability or reduced Treasury dependence. In my view, the sustainability of the Summit should be resolved before the Treasury is asked to fund it again. The long-term issue is much more important to me than holding the Cardano Summit in 2026.
To me, the CF appears to be transferring the consequences of an overextended event strategy to the Treasury. I cannot vote in good faith for this as I do not have sufficient confidence in the proposal, its assumptions, or its long-term funding model.
Please note that this vote does not reflect on all CF activities. It is specifically aimed at this proposal and the context in which it is being proposed.

First, if you are considering voting No on this proposal because this is "Plutus", think again. This proposal is not aimed at improving the standard PlutusTx language (the word Plutus is used interchangeably in Cardano lore, so you might be misunderstanding which Plutus this proposal is referring to). No, this is not the Plutus language that you heard about - that was overtaken in usability and dev-friendliness by new languages such as Aiken et al.

So, this proposal is about improving the unsexy brain of Cardano - Untyped Plutus Core (UPLC). UPLC is pretty-much as low-level as you can get when it comes to Cardano smart contracts (stole this definition from the Aiken website). So, in my view, this type of proposal is literally one of the reasons why the Treasury exists. We have a smart Cardano, but we want a smarter Cardano that is easier and safer to use with more capabilities.

We need to improve the smart contract platform if we want to stay competitive. Cardano is a proof of stake Bitcoin version with much more expressiveness than Bitcoin, but still not enough expressiveness as some of our competition. This proposal does not aim to improve the higher level PlutusTx, it aims to improve the UPLC base for all the higher level languages such as Aiken, Pebble, OpShin, Scalus, etc. UPLC is the low-level bytecode that actually runs on the Cardano blockchain.

For more context, do not read only the proposal on-chain, but there is a pretty good higher-level explanation on: https://momentum.cardano.iog.io/proposals/plutus . Read that first.

Also, keep in mind that I am not a developer, so I might have made a technical error or misspoken on something, but I have no intention to mislead. Still - this is the pulsing mind of Cardano that needs a new chip implant. Yes for me.

This proposal builds upon the needs of Cardano's 2030 strategy, but more than that, it is just common sense. This proposal addresses one of the weak points of Cardano today. Cardano does not have the throughput for a large number of concurrent transactions (or transactions crammed in peak periods) - while preserving the traits that we value, such as decentralization. True, we are not at maximum capacity at this moment - however the global ambition that Cardano has in many spheres of financial applications do not correspond to the current abilities that Cardano has.
A global network that has the ambition of serving as an alternative financial infrastructure to be capable of serving more than the current ~800,000 transactions per month (as stated in the proposal) - has to be capable of delivering on its promise. If the current throughput is correct, that means that Cardano can currently serve one transaction per month for Bhutan - a country with a population of over 800,000 people. That's not a global financial OS.
Imagine a crypto revival - especially in countries suffering from fiat debasement - and Cardano manages to attract ten times more new users later this year. What will happen is we will again hit the congestion wall and disappointed users leave, while we go back to square 1 - asking ourselves why can't we process more L1 transactions.
Finally, Leios will probably change the way we and others view Cardano - but it will not, magically bring new users. This is more about getting to a robust Cardano 2.0 than immediate adoption. However, a resilient Cardano 2.0 with Leios will open up the possibility of new use cases.

This proposal includes two components: : Project Cayley ($1,000,000) to build the next-generation indexing architecture, and an operational subsidy ($900,000) to maintain the free-tier infrastructure that Blockfrost has funded entirely on its own since inception.

Project Cayley is the more interesting one for me. However, I would prefer to see this as a proposal in 2027, when Leios becomes a reality. Cardano mainnet is still not overloaded and Project Cayley sounds like it could also be realized in 2027, after we see Leios hit mainnet and how it functions in a real-life scenario.

As regards the free-tier infrastructure - it may now be subsidizing commercial projects that cannot survive on their own. Shifting the subsidy to the Treasury - for many projects that cannot survive is not something I would support. In short, I would reconsider my current NO vote on Project Cayley if it were resubmitted in 2027, based on the Leios reality we have then.

I appreciate both teams and I have voted in favor of Hydra and Midgard proposals previously. Unfortunately, there is an unfinished Catalyst Fund 12 proposal Anastasia Labs - Midgard: Cardano Layer 2 with 500,000 $ADA requested. Three milestones have been verified as completed, three are still outstanding. The proposal was supposed to deliver a Midgard MVP. Last year, I also voted in favor of a Treasury Withdrawal worth ₳2,162,096 for Midgard - Optimistic Rollups administered by Intersect. That proposal stated: "Midgard is already in active development, and we have already made significant progress towards our goal of EOY mainnet readiness." I voted Yes with the expectation of end of 2025 mainnet readiness. This current proposal states: "Midgard is approaching its testnet phase". Essentially, as much as I appreciate both teams building on Cardano, I think this proposal is somewhat premature - at this moment of the 2026 budget year. Also, if resubmitting, please do revisit the original Catalyst proposal and 2025 Treasury withdrawal. For example, the Catalyst proposal stated: "Several projects, including FluidTokens, have already committed to utilizing Midgard. This early adoption showcases the confidence of the community and developers in the capabilities of Midgard to deliver a high-performance Layer 2 solution." I have seen that there are some differences now with the FluidToken team - not that it matters to me as a DRep. Business relationships are business relationships. What I am interested in is: are there projects - now in 2026 - that have expressed interest or are committed to utilizing Midgard? The demand for Midgard matters for a positive vote.

I appreciate that both CF and EMURGO are offering their services. The strategic dual-event concept is coherent. I also appreciate that both founding entities have voted YES on a number of important matters for the ecosystem, including support for node diversity and several critical projects. More broadly, both entities seem more agile than a few years ago, and EMURGO appears to have renewed its focus on Cardano.
That said, I am voting NO.
My objection is not that events have no value, but that this is not a compelling treasury use of funds in 2026 at this scale. Decentralization in Cardano is happening in front of our eyes, with many small teams taking initiative and building real resilience.
If it comes down to the Treasury, I am comfortable with not holding a Cardano Summit in 2026 and not sponsoring TOKEN2049 this year from the Treasury. For me, such large spending is hard to justify to ADA holders at this moment in time.
The proposal relies heavily on marketing and visibility KPIs - more than hard adoption outcomes. The requested scale is substantial: $2.5 million for the Summit and $1.16 million for TOKEN2049.
I also think treasury-funded marketing and outreach should not automatically default to founding-entity-led execution. If Cardano funds marketing from the treasury, I would rather see a more decentralized, experimental, and non-institutional approach in 2026. The founding entities, like any large institutions, have their own blind spots, internal narratives, and echo chambers, and treasury financing risks amplifying them.
At the same time, as major players in the ecosystem, CF and EMURGO are of course free to participate in TOKEN2049 with their own resources and continue promoting their work there. The question is whether the Treasury should finance this presence at this scale.
I am also concerned by the cost. In the current proposal, the 2026 Summit withdrawal request is $2.5 million. From what I saw the CF previously indicated that the 2025 Summit budget was about $1.4 million and that the 2026 Summit budget would be about $1.2 million. Based in this, I see a large discrepancy with the new proposal. This is not a reduction but a very large increase.
Separately from the merits of this specific proposal, I have a standing platform commitment to vote NO on EMURGO-related treasury withdrawals until March 15, 2027. That commitment is tied to unresolved concerns around the Yoroi wallet governance UI issue and the accumulation of DRep power through that soft nudging of wallet users. I acknowledge the announced effort by EMURGO and Yoroi to address this, but it has taken too long. The first Voltaire vote took place back in September 2024. As a result, I will use a sufficiently long period to assess whether this issue has been remedied properly.

A handful of things we get here that are of strategic importance in a tough market year for crypto. We get a new node implementation - production-ready light node Gerolamo that will allow DApps to run their own lightweight nodes. If Cardano light wallets are able to offer Daedalus-like security (I think it is a massive win), we might wake up thousands upon thousands of risk-averse Cardano holders from their long sleep and even bring over new risk averse crypto users.
We get a new programming language for smart contracts - pebble. With Cardano smart contracts being unique, lowering the hurdle brings competition and choice.
Third, we keep a competent infrastructure team actively working on key components of Cardano. Thus we gain more resilience and reduce dependency on one core provider. This directly helps ADA holders and the Treasury become less dependent one one core player. Competition and choice will lower costs and lower treasury outflows in the years ahead.
To quote a US president: In any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing. We need to take action in times of difficulty. This is likely to be no ordinary year.

Yes, this is a good move by IOG and Cardano Foundation to request approval from the community. This would help to close out the ongoing projects from Fund 10 to Fund 14. Funds for unused funds Fund 15 and Fund 16 are being returned to the Treasury - as they should be. Catalyst should outgrow its experimental nature and it does fit squarely under the mandate of Cardano Foundation, not so much under IOG's umbrella. Kudos to IOG for maintaining Project Catalyst so far and for graciously reaching a deal with the Cardano Foundation. Congrats to the CF also for agreeing to take over this responsibility. I do have a small conflict of interest in this matter. I am active as a Milestone Reviewer in Project Catalyst from Funds 10 to 14, monitoring some projects that have not been closed out yet. I do stand to benefit if these projects continue successfully submitting Proofs of Achievements. However, I abstained from voting YES to Catalyst funding for Fund 14 to Fund 16 due to conflict of interest and this vote here does not propose any new treasury withdrawals or disbursements from the treasury.

Treasury capital should only fund investment vehicles that are clearly defined, independently validated, and structurally simple enough for the community to evaluate. Valiant effort by the Cardano Foundation to structure an ecosystem investment fund. I am voting NO on this proposal for several reasons. I feel more confident voting YES on proposals that are more risky - if I feel that they are air tight and scoped well. So, language matters too. Specifically, I know what is a Cardano-native company ... but I don't know what is a Cardano-integrated company. The proposal wants to support both Cardano-native and Cardano-integrated companies. The latter is such a loose term that it means very little. A company that mints one Cardano NFT collection, for example? Or will a selected company do a token Cardano NFT mint just to get some funding from the Cardano treasury? I don't know. If I don't know, I would then go for Cardano native companies. Next. The fund aims to return capital to the Treasury and external limited partners. The target is around 3x gross multiple on invested capital and a 25%+ internal rate of return. This goal is benchmarked to institutional crypto VC funds. So, lets be real - those targets are not impossible, but Orion Fund is very ecosystem-constrained, has a very volatile treasury backing, Cardano political risk, and is also expected to fund broader ecosystem support, this stated return looks very unrealistic. The Orion Fund is also only seeking at least $5M of outside LP capital in the broader framing. THis is not the kind of external validation that would make me confident this will behave like a top-tier VC vehicle. The strongest likely outcome is some ecosystem stimulation. The proposal combines several different uses of capital inside one vehicle. Direct startup investments sit alongside venture studio activity, accelerator programs, exchange listings, integrations, post-investment portfolio support, governance, and community tooling . These activities serve different purposes and carry very different risk profiles. When they are bundled together, it becomes difficult to evaluate performance. The part that I find most believable in this proposal is its ambition to build a stronger founder and talent pipeline for Cardano. That is much closer to what Draper/DU are visibly set up to do than, say, turning Cardano into the dominant institutional chain. It is not me who said that - the proposal does claim its goal is "establishing Cardano as the leading institutionally adopted blockchain". Success metrics are also too soft. TVL growth, developer activity, and ecosystem visibility. Treasury-backed capital should prioritize harder outcomes: sustainable protocol revenue, externally led follow-on investment, and audited capital returned to the Treasury. I think this proposal has a low chance of achieving its headline financial and strategic claims at the level implied by the pitch. Approving the first tranche effectively commits the community to the legal structure, governance model, and management approach of the fund. Why? Because sunk cost pressure appears and the structure has been endorsed with this first vote. In that sense, this vote functions as a major underwriting decision rather than a limited pilot. Finally, we have not been given access to the contents of the side letter that the Orion Fund expects to enter into with Arouet Holdings that outlines how capital and returns flow back to the Treasury. Overall, this is a bit of a hodge-podge that may mask what we truly get out of it - as it will be difficult to track the many different uses of capital. Outside investment that is planned is low. If sophisticated outside capital believes the strategy is attractive, then a cleaner structure would require a meaningful first close from third parties before Treasury money is released, or at least a matched-capital threshold. Without that, the outside interest point remains more rhetorical than binding. In short, this umbrella proposal is too much of a mish-mash for me.

I voted NO on the preceding budget info action with a rationale and expressed my concerns. A 73% majority of DRep voting power did support it when it was put forward as a budget info action. The proposal was put forward by Elder Millenial who has built SteelSwap - a Cardano DApp (no token!) that I have used most frequently over the years. This also makes me aware that the proposer does have significantly more extensive experience with Cardano DeFi.
There is some level of pragmatism that is needed if one is acting as a DRep, as was the case with the Pentad proposal. Specifically, pragmatism here for me means I do not wish to stand in the way of something already approved by more than two-thirds of DReps AND proposed by someone who has built an extremely useful and performant Dex Aggregator for ADA holders/users at a high risk as it was NOT coupled with a token sale. A passive abstain (me avoiding to vote) would effectively be counted as a No vote on this treasury withdrawal. An active abstain (me voting Abstain) does not tilt the balance towards a Yes or a No. It allows other DReps who approved the original budget info action to proceed if the current withdrawal request meets their expectations. Taking into account the proposer's unique contribution and experience with Cardano DeFi - I acknowledge my understanding of the proposal might be incomplete for me to confidently vote NO on the withdrawal. TL;DR: The specific constellation of factors for this treasury withdrawal is such that I do not see a blocking vote from me is merited. I wish the proposing team success.

We are in a tough market, for sure. I was always going to support node diversity proposals for Cardano in 2026. These alternative node implementation proposals by established yet independent Cardano teams have the added benefit of giving us more resilience, more surface area with non-Haskell developers, retaining a wider pool of Cardano-committed talent, and the ability of expanding the Cardano gene pool (code pool) - ensuring we have more options down the line. We have funded a lot of expensive fantasy projects through Catalyst. I mention that not because I want to single out Catalyst, but because I had lot of insight into projects that received funding in the past years. It is what it is. We are where we are. Putting all our eggs in the Haskell basket may seem cheaper, but it will not be. A biological analogy probably could work here. The more diverse the gene pool of a population - the more potential resilience it is likely to have when (not if!) the environment becomes adverse. The environment will turn against us, maybe it is already. Reliance on one node - could be the path to Cardano's eventual death on top of an ivory tower. I understand the need to be cautious with spending. It definitely is necessary. Yet, taking a misplaced revenge hammer to what is an internal insurance policy for a blockchain is no solution. Finally, I am happy to see teams like Amaru, Blink Labs and soon HLabs putting forth their own proposals. It is more expeditious, feedback can be received faster. DReps know what they are voting on. Personally, I hate bundled proposals - and this direct approach to funding is appreciated.

Intersect submitted the largest budget last year. There were a lot of improvisations and uncertainties with the Ekklsia voting stage, especially with how short it lasted, how much advance warning was given, how the thresholds were calculated, how Intersect interpreted what the vote meant - and how many DReps did not participate. I would argue that large institutional DReps that are more present in Intersect bodies are always more aware of the deadlines and will have an advantage over small DReps - in terms of participation. Also, will this last 6 epochs on Ekklesia or just a weekend or a few days? The new governance action does not explain how long will the Ekklesia polling last, how will the 67% of participating stake in the Ekklesia poll be calculated exactly (per proposal, per entire voting session, what is the minimum participating threshold for DRep participation if any, will there be YES NO and ABSTAIN, How is active Abstain used to calculate the results, what does a passive Abstain mean (a DRep not taking part in the voting), what if a DRep votes on one proposal but does not vote on another, etc.. ). Too much power to interpret the results is left to Intersect.
Overall, the language is vague, the Ekkelsia voting process and interpretation of results is not sufficiently fleshed out, I vote No. I want to understand the entire pre-voting, voting and post-voting process on Ekklesia beforehand in full and glorious detail. This is no joke, it is likely to be the biggest request in 2026. Insufficient.

Easy yes. This team is taking care of a lot of critical, yet unsexy unfinished business for Cardano. Decentralization is the name of the game. Cardano should not risk its future on a single point-of-failure Haskell node. Attached documents are very well presented. Keep it up.

I am pragmatic minded about governance in the early days of Voltaire. Everything stops when one CC member is removed or stops voting. Real time is lost, real momentum is killed and outsiders will see that paralyzed Cardano governance can freeze critical decisions for indetermined amounts of time. A buffer makes sense in the real world. Governance should be efficient when possible. It should not become a new stumbling block to normal blockchain operations. A majority of DReps voted NO to add an 8th volunteer member to the Constitutional Committee recently. I voted YES. That was one possible pragmatic solution to governance paralysis that we have already experienced when one CC member retired. So as DReps recently voted No to an eight member, Yuta-san proposed another pragmatic solution to avoid governance paralysis. Again I vote YES. If this is not an ideal solution, it does not stop the holding of a new CC member election and voting in 2 or more CC members. Then, if centralization is a concern, later increase the (committeeMinSize) from 5 to 7 again. Navel gazing is no solution.

A 300M ADA NCL is the more careful choice than than 350M (or 700M): spending more doesn’t magically create more value - it just funds more things while each recipient ends up with ADA that’s worth less. I also don’t treat NCLs as some sacred number. They are a constitution-required snapshot that can be changed later if the majority of DReps want to. So I’m going to focus on disciplined treasury spending: voting No on weak, low-signal proposals (even if they’re under the NCL) and voting Yes on the smaller set of builders most likely to move adoption. What matters is giving the highest value we can to the best teams, not how much ADA we can shovel out.

I voted no on the Stablecoin DeFi Liquidity Budget info action, I have not changed my mind since so I also vote no on this Treasury Withdrawal. I wish the proposers success and hope that the investment will bear fruit for the Cardano ecosystem. This is a market intervention that is dependent on a number of things going right and the ability to address a cause of the problem that it attempts to resolve. It is a complex proposal. My worry is that - like water, money finds a way of flowing towards an escape point - if it does not want to stay somewhere. The market might end up reverting back to an equilibrium - despite our best efforts to boost liquidity through injections like this. Overall risk associated with this market intervention is too high (from my point of view) for me to vote yes on the Stablecoin DeFi Liquidity Budget withdrawals.

No specific security concerns are raised by this change. Performance results indicate that Praos timing guarantees will be maintained following this change.

This seems to be a relatively straightforward parameter change that has been carefully examined.

I support this motion.

TL;DR: NCLs are in reality a bit of performative theater mandated by the constitution. I abstain. Theater that can and will be modified - if the majority of DReps desire so. We have seen that. So, I will focus my attentions on voting No to proposals that to me seem worth less than what Cardano holders are being asked to invest in them and voting Yes to projects that are likely to yield more for Cardano.
I listened to an interesting IntersectCBC space on the 2026-27 Net Change Limit. Essentially, we have a bit of performative theater in Cardano with the NCL. As we have seen in the first year, if the majority wants to extend / increase the NCL to fit something that the majority wants, it will be done, regardless of what was previously approved.
I also voted to extend the first NCL in order to fit in the Critical Integrations Budget and Treasury Withdrawal. The NCL - as a social consensus that is preformed 12 or 18 months in advance - does not matter as much as we think it will matter.
What matters down the line will be identifying projects that are worth more than what Cardano holders will allocate to them from the Treasury. It's a high bar.
NCL schmNCL.... I want caution when approving "spending" from the Treasury - the NCL is just a mental crutch that may be an excuse not to carefully scrutinize Treasury outflows. We don't want to approve projects just because they are below the NCL.
A few weeks ago I thought of rejecting NCLs that are higher than 99% of the Net Income available from the inflows during the preceding period of the same length. That would mean voting no for the 120% that this NCL action proposes. Treasury inflows for 2025 are projected to be approximately 290 million ada. That would mean approving something closer to 285 million ada.
However, NCLs seem to be more of performance theater. The real battles are the treasury withdrawals. So, there is no need to stop the train - over the NCL. There is literally no one who knows the ideal NCL today. It could be 150 Million ADA, it could be 250 Million ADA. Or it could be 400 MIllion ADA if we are to integrate the NASDAQ in 2026. Also, weak proposals may pass the withdrawal stage early on in the year, with a great proposal appearing at the end of the NCL period (we saw this with The Pentad proposal in 2025)... so we will stimulate a race to fill up the NCL - to avoid this artificial cut.
Finally, as my preference was to have an NCL smaller less than 100% of the Net Income, I abstain from approving 120%. There is a solid case for removing the NCL from the constitution - as it fundamentally does not limit anything - and is seemingly more red tape.

DeltaDeFi has built a very interesting and innovative Hydra-based DeFi platform and I've been following discussions around it. I also helped test it early on and was impressed by its speed and ease of use. I appreciate that the team is asking DReps to signal whether this direction (Hydra-based trading infrastructure) - is a good direction.
Let me add that I have voted for SIDAN Lab's proposals in Catalyst previously, I appreciate their role as an SPO and DRep and their leadership role in the Cardano HK community. Additionally, I love their committment to open source and great track record.
Thank you for taking the time to consult DReps (I have seen your requests on social media) and I understand this Info Action also as a temperature check. So I am happy to voice my feedback.
The team wants to harden and scale DeltaDeFi into a production-grade Hydra trading venue for ADA and key CNT pairs. What I do not see here is a deep dive by the team into the product-market fit: as far as I understand it - using Hydra involves some trust assumptions. Someone called it a "Delegated Authority Hydra Topology". Namely, someone has to open and close the Hydra Head and - namely someone has to be the operator.
Which Hydra topology is DeltaDeFi today (beta) and which is targeted in 6 months? Hydra apparently gives strong guarantees to head participants. The moment end users are not participants and instead rely on a small set of “delegates/operators,” they are (if I understand well) in a delegated/managed topology where the user experience can inherit extra trust assumptions. What are the exact failure modes (operator down, partial signer collusion, network partition)? Can a user unilaterally exit to L1 if the operator is offline? Etc...
I have seen some equally respected members of the ecosystem point out that Hydra gives L1-equivalent security only to those who are running a node as a participant in that Hydra head. So, not to everyone. If not running the Hydra Head, but just participating, funds are in the custody of the head participants. I may be wrong, but then again - this might be the soft spot of a Hydra Dex and it should be clear to me - what is coming regarding the soft spot in the future.
Why do I mention this - well, because of product market fit. I wonder who is the end customer of the DeltaDeFi Dex. If I am right, the team hosts currently all nodes. DeltaDeFi says that it will become more and more decentralized as time go by - according to the docs, but this info action does not go into this.
Are there any in-depth decentralization milestones that are auditable (not just “over time”)?
Without a specific and clear and understandable component of this plan regarding security of user funds, the trust model and what does it mean for end users - I cannot signal support for this info action - not to speak of a Treasury Withdrawal. For Treasury Withdrawals, I am also limited by my self-imposed "no more funding except for emergencies" rule for the first year of governance - and by my general tendency not to support situations where we are asked to pick winners in a competitive market.
Yes, unlike existing AMM Dexes, in this case, we have innovation in the form of a Hydra Dex, but if the DeltaDefi team wants to increase the chance of getting a Treasury Withdrawal approved by DReps in general, they might be well served by delving more into how they intend to address the issues above. Yes - they do state that the proposal aligns with "Pillar 1: L2 Integration – "High-frequency, low-latency transactions with L1 security". Does DeltaDeFi directly offer L1 security? If not, how much security does it offer and - please offer a clear, roadmap with milestones about the statement from your documents: "DeltaDeFi will become more and more decentralized as times go by, and eventually a fully decentralized DApp for the community."
Finally, the Hydra benefits are very clear for all. What may be unclear for end users - potential customers - are the tradeoffs. From this Info Action, I am not convinced that a Hydra-based Dex is the right approach for a commercial project building on Cardano. If I am not convinced, others may not be either. It's up to the proposer to focus equally on the benefits and how to address the tradeoffs.

Finally, I may have misunderstood some things and/or wrongly interpreted - if I did so, it was unintentional. And thank you for building on Cardano.

I recognize this document was built through extensive community input and consultation. Due to the busy governance year, I did not have time to engage deeply, so I’m judging the proposal as it stands. I agree with the general concern that hype cycles can steer an ecosystem without intentional strategy. There is some danger that this document will also unintentionally absorb current hype cycles and trends.
I disagree with the claim that it can create a “community-vetted filter” that DReps should use "to rigorously evaluate funding requests". I prefer not to use it in the future as a filter - as DReps may agree with some parts more, with some parts less. The proposal describes itself as a strategic document that does not compel votes or set constitutional rules - good and it should be treated that way. My concern about using this as a filter is practical: approved strategy documents often become soft policy. Over time, they can be cited to socially pressure decisions, reward conformity, or penalize novelty, even when conditions change. If approved, it should be used as one input without becoming a gatekeeping tool.
[Vision] - [Cardano is the most secure, reliable and censorship-resistant blockchain for mission critical applications to power economies and societies of the future.]
I support the emphasis on security, reliability, and censorship resistance. I am not sure about the addition of "to power economies and societies of the future". Maybe it will serve as as an alternative platform to centralized economies and societies of the future? Maybe Cardano will power individual economic and political freedoms, or maybe it will underpin an alternative, parallel P2P economy. Maybe all of the above. For me, the vision line can be stronger and more durable if it focuses on core differentiators and includes sustainability explicitly. Cardano is a Proof-of-Stake financial network; long-run sustainability (economic and operational) is mission-critical for its survival and security. A tighter vision statement I could support: “Cardano is the most secure, reliable, censorship-resistant, and sustainable blockchain for applications.”
[Mission] - [To empower a global ecosystem of builders, businesses, organizations, governments and communities by providing a scalable, secure, and research-based platform that enables the creation of transparent and fair digital economies.]
The mission does not explicitly include individual people. Yes, communities contain individuals, but explicit naming matters because it signals who we optimize for. Strategic documents signal priorities through what they name. Individuals are not a minor stakeholder group in Cardano, they are foundational. Individuals became SPOs, builders, educators, delegators, and long-term users. Many were attracted by self-sovereignty and sound-money principles. If the mission statement lists institutions but does not explicitly include individuals, it risks drifting toward an institution-first posture and away from a key demographic that sustained Cardano. I would revise the mission to include individuals directly. Empowering the ordinary person is part of the mission for me, especially as many individuals turned to Cardano for its sound money philosophy.
Pillar 1 (Infrastructure & Research Excellence): aligned
I broadly agree with Pillar 1. Security, scalability, interoperability, research rigor, client diversity, and resilience are core strengths and valid priorities.
Pillar 2 (Adoption & Utility): focus is good, but pinpointing “four high-value verticals” is premature. My concern is the strategy’s explicit selection of four “high-value verticals” at the top level. Strategy does require focus, but hard-coding a short list of verticals in 2025 - in a 2030 document risks trend capture and creates accidental exclusion. We have repeatedly seen what the industry labels “high value” change drastically across cycles. Here we have the views of the Cardano industry. I understand that this is a common thread from the inputs gathered, but there is a risk groupthink could be wrong. That would be very very costly. I would support framing verticals as current hypotheses or examples, not definitive long-term exclusions, define specific criteria for “high-value” (durability, real demand, true - not imagined - regulatory feasibility, etc..). This would allow us to pivot if current verticals remain elusive and there should be a a review cadence (e.g., every 12-18 months) where the community can update vertical priorities via an Info Action based on data. Picking 4 verticals means all other Verticals are then classified as not being High Value. If this was written a couple of years agoi we might have had NFTs, the Metaverse, memecoin launch platforms as Verticals etc...
Pillar 3 (Governance): overall sounds good. I support the overall direction of making governance hard to capture, accessible, and paced. I am not convinced the document has sufficiently grounded certain mechanisms, such as “adaptive/turnout-aware thresholds” in real-world precedents or referenced research. Maybe I missed it. These ideas may be promising, but they also have trade-offs (legitimacy, complexity, manipulation vectors, minority protection). If they are included at the strategy level, they should be framed more carefully as exploratory, and ideally supported by examples, research, or a plan to test and evaluate them.
Pillar 4 (Community & Ecosystem Growth): Some elements here read too broad relative to the document’s own principle that prioritization requires exclusion. For example, “pilot programs for blockchain education in schools and university curricula” may be beneficial, but it is a long-horizon activity with difficult attribution and high coordination costs. If the goal is a global financial system or high-assurance infrastructure, I currently see higher ROI in targeted efforts such as: attracting a small number of top-tier researchers, engineers, and novel monetary experts from outside the ecosystem and improving developer onboarding and tooling (which is more directly measurable).
Pillar 5 (Sustainability & Resilience): introduces a major treasury shift without explicit risk governance. A “Multi-asset treasury” is reasonable - especially as Cardano native assets are "first class citizens". But the language of “managed treasury,” “generate yields,” “strategically deploy capital,” and explicit “10%+ ROI” implies a significant strategic shift. If we are going to move in this direction (fully debatable), the framework must explicitly include risk management and accountability, not only return objectives. No emphasis here on conflict-of-interest protections, custody and operational risk,failure modes and rollback plans, mandates (what is allowed / not allowed), risk limits and drawdown tolerance, transparency and reporting, governance process and accountability, etc... The treasury section reads premature
The "Decentralization Target" segment - regarding stakepool operators - at first reading does not sound like a change from what we have now, I may be misreading it. The key word used is "Keep"..... While in some other Focus Areas the Strategy starts with the words "Improve" or "Refine" or... "Incentivize" ... "Evolve".... "Allow"... I see room for more ambition here - and room to improve, I would not settle for "Keep" as part of the vision. There are community efforts underway to improve decentralization through parameter changes.

Framing: The strategic framework also omits the word FINANCIAL from its title. The title “Cardano 2030 Strategic Framework: The World’s Operating System” is too expansive and conflicts with the document’s own call for focus and exclusion. “World OS” can be used to justify almost any scope. Even “financial operating system” is already a large ambition, the choice of “world OS” is broader still and risks strategic dilution. I don't see "The World's Operating System" as something that should be on the path to 2030.
Back to the financial operating system - if Cardano is one, it must care about the value of the underlying currency - which secures the network. There are multiple paths to increasing the value of the underlying resource. I am not asking for “price talk” - I miss some deeper insight into the resource underpinning everything. It practically deserves a Pillar of its own - as it underpins the health of the other Pillars. The valuation of the resource is a key element of the economic security budget, of incentives, of fee/reward sustainability and operator profitability. It is We have 15 years of blockchain technology and markets behind us - we are moving towards Treasury spending at large. How will this impact the underlying currency - and all pillars that are linked to it's value. I can see a future where the volatility of the underlying currency undermining the grandest of plans.

I have been following this document's genesis from the very beginning and overall, I support the intention behind it. The idea is to streamline the constitution into a more manageable, applicable document. The proposal - does recognize that the the “budget layer” in the existing constitution may creates more ambiguity than control. Right now, the budget mechanism is conceptually useful, but structurally awkward and easy to turn into confusion. The current V1 of the budget clauses explicitly allow multiple budgets and variable time periods (shorter or longer) - this is a recipe for a mess that we have already seen appear. It leads to questions about which budget is in effect and which budget supersedes the other budget - and how long do the multiple budgets last. This causes governance fatigue and an illusion of control. Yes, budgets, in theory, force prioritization - so this removal of a messy budget process can lead to ad-hoc, proposal-by-proposal spending unless the ecosystem creates a respected off-chain planning cycle. Food for thought, there. However, v 2.4 does strengthen per-withdrawal accountability where it matters.

The Defined Terms block up front is welcome and the minor corrections, tweaks and fixes throughout the document help it's overall clarity - which is a win.

There has been a back and forth over ADA holder vs ADA owner - and as a general matter of principle I would side with the ADA owner side of the argument as owners are the rightful beneficiary. However, ADA holder sort of matches how the ledger actually works. Cardano tracks control of UTxOs/keys, not legal title. Ownership is a legal concept that depends on facts the chain can’t see. However, v2.4 reverts back to the original constitution in this segment, so we are not changing anything here. Maybe there was a case for including something about ADA Owner in the Defined Terms of v.24. Owner becomes legally fuzzy - allowing multiple claims of ownership - and the the outright legal owner of a pooled wallet can vary based on legal details, terms of service, jurisdiction, etc. Anyhow, yes.

One approach to blockchain governance will be to mimic the rigidity of constitutional systems seen in the legacy world. The word "constitution" itself is loaded - as it brings about images of constitutional courts, togas, and supreme authority. However, the Cardano constitution is essentially a rulebook. We want to make sure we are playing by a set of pre-agreed rules. That's it.
So, yes we can still experiment and show that our nascent governance system is fair but also flexible. Having an extra CC member - above the bare minimum - makes sense for a global decentralized system, especially as one CC member can easily be incapacitated for a certain period of time. Allowing a small buffer might be prudent.
Overall, having more individuals who want to dedicate their free time to governance is a net benefit for Cardano. Thank you for your service all former and current CC members. All of you received a lot of community support - and in this case the recent Ekklesia poll showed this to be true for this candidate as well.
Why stop an apparently committed candidate from helping the other 7 CC members? It's a thankless job as it is - and having a small buffer above the minimum CC number will probably help relieve some pressure from the other 7 members who are under a (thankless) spotlight with every word of their rationales being scrutinized around the globe.

Voting to confirm the Cardano Curia CC member in order to make the Constitutional Committee functional again., allowing normal governance to resume.

Decentralized should not mean disorganized.

I voted yes on the budget info action, I vote yes to the treasury withdrawal.

This motion aligns with my original preference, which was to have a longer-lasting NCL. This would mean that the treasury withdrawals would be prolonged - and a new NCL would be approved later, rather than sooner. This motion does not increase the NCL, so it is OK with me.

Let me address the elephant in the room: I committed to approve up to ₳200-250M of spending in 1st year of minimum viable governance (MVG). DReps approved 272M ADA. I voted YES to ₳172M so far.
If I vote YES here, I come to ₳242M

I expected we would come to a moment like this. Budgets have been submitted as a smorgasbord so far - without a focus on major items that REQUIRE collaboration of the Big 3.

I have also voted against the Cardano Summit, which involved 2 out of the 3 founding entities - in part because of this piecemeal approach. We are too small of an ecosystem to plunge into Voltaire disunited.

I am well aware that I committed that cardano govtool would be my last YES vote this NCL year (apart from emergencies). So, for me, the logical path is to vote NO on this proposed Cardano Critical Integrations Budget as the current NCL expires on 4 January 2026. Then a new NCL would be approved and I would be able to vote YES for this proposal under a new NCL.

This path would allow me to keep my promise to my delegators. It would allow me to stay true to my own words. Don't compromise. Focus on my narrow DRep agenda.

Is the strategic need for: Stablecoins, Institutional Digital Asset Custodies and Wallet Infrastructures, On-chain Analytics Platforms, Cross-Chain Bridges and Pricing Oracle Infrastructures - a true emergency that requires a YES vote from me now?

It is not. If these issues were not an emergency until 27 November 2025, they could certainly wait for 4 January 2026 - allowing me to stick to my own line in the sand until a new NCL is approved.
I should say no, technically.

Previously I also voted NO to the Tier 1 listing proposal for SNEK and to the Stablecoin proposal - that were attempts by teams to patch up some Cardano commercial holes - through valiant yet piecemeal efforts. Piecemeal and haphazard efforts will probably not save us in the commercial sphere.

So, is there an emergency here? Is the Cardano Critical Integrations Budget an emergency?

In my view - yes. But for a different reason.

With the advent of Voltaire - the founding entities have been struggling to shape their new roles. Their visions of their own future independent roles collided with the reality that the ecosystem is not ready to paddle on its own - as participants often row in different directions.

The Soft Fork incident demonstrated - that governance decentralization is a process and that true leadership is always welcome. Be it a centralized or decentralized system.

Ecosystem-wide leadership is needed for big ticket items. And it cannot emerge from small Cardano nodes yet.

This proposal is an emergency - as it is an attempt to redefine the relationship of the 3 Cardano Founding entities based on their common future interests with the community, rather than on their disparate versions of the past and their past roles.

As the 3 Cardano founding entities found the strength to compromise, I too can compromise by voting YES. There is an added value of having Intersect and the Midnight Foundation onboard with these efforts.

I compromise at the price of mine own DRep credibility, as I believe that the community's interests take precedence over my narrow DRep interests.

It is a vote of trust in the cooperation among Emurgo, in the CF, in IOG, in Intersect and the Midnight Foundation.

A YES vote with a warning: do not disappoint us. The warning is based on the fact that the success metrics as stated: Integration is live on mainnet - are weak. Without binding KPIs. A poorly delivered result could permanently damage trust in treasury governance and the entire decentralized governance model.

Uniti nos stare, divisi cadimus.

I have voted No on the Budget Proposal that preceded this Treasury Withdrawal with a more detailed rationale. I repeat my vote for the Treasury Withdrawal.

I was one of the many Cardano community members who supported for the reimbursement of the submitters of the Cardanoの生きがい - Ikigai governance action. Thanks for being an early tester of Cardano governance. Sad about what happened. I am glad to support your claim - with some advice below - for the Treasury Withdrawal stage.

In general, I do support this motion. I agree that the submitter should not lose one hundred thousand ada, for being an early pioneer of Cardano governance and for the glitch with the submission of governance actions - that did not refund the funds. It was a sufficiently unique case that requires a tailored remedy.
Please note that my final vote on the Treasury Withdrawal will depend on the following:
a. I will vote NO on the Treasury Withdrawal if it does not include verifiable addresses and proof that it was submitted by the same wallet / proposers that submitted the Cardanoの生きがい - Ikigai governance action. I do not want to refund the sum to the wrong wallet/persons.

From what I can see - (just glancing through explorers, I may be wrong):

Cardanoの生きがい - Ikigai - was submitted by Stake Address: stake1uys93fhep4lc2u6lu0q09kcxayxzthasded35c0x0w60ugc9s0cm5

This motion is being submitted by stake address: stake1u8453de8xhhqa9c4ftvylkke8we84tmaq5hz75qwfgaaf2qac45ja

If the original address wasn't staked back then (which caused the problem), then I am not reading the on-chain data well.
So, my point is: the burden of investigating the the chain of events is now being shifted to me as a DRep instead of being provided in a clear and easily understandable way inside the current governance action. Include the addresses from which the Cardanoの生きがい - Ikigai governance action was submitted and the address to which you intend to receive the payout. Walk me through why I should be convinced that this is the same person/submitter.
b. I will vote NO on the Treasury Withdrawal if the total compensation sum goes above the 100,000 ADA plus a calculation (not just self-declared) staking rewards. The average staking rewards - from epoch when you submitted to epoch when the withdrawal is roughly approved - should be calculated and the calculation should be included in the Treasury Withdrawal action - and it should be easily verifiable by DReps. Yes, there is some leeway there in terms of precision, but I want to follow the calculation.

c. I will vote NO on the Treasury Withdrawal if it asks for further additions, for example "Increasing the compensation sum for Midnight airdrop eligibility and other opportunities" - this will not be acceptable to me as it opens new precedents - which is not necessary here, imho. As any precedent to include additional compensation funds - has to be air-tight. The Midnight airdrop was optional and is not an automatic part of the Cardano protocol - nor have all Cardano participants claimed it. "And other opportunities" opens the way for refunds from the Treasury for other things by others, such as claims towards the treasury - for the a missed ability to provide liquidity to Cardano DeFi... etc..

TL;DR I agree to refund the 100,000 ADA + precisely calculated staking rewards that were missed out on (small variations understandable) - with clear and verifiable proof that the identity of the original proposer / wallets and the current proposer are the same. I do not want to refund the sum to the wrong wallet/persons. If compensation for anything else is included ("airdrop eligibility / other opportunities") I will probably vote No on the treasury withdrawal.

Positively surprised by this initiative. It came out of the blue for me and it does contribute to a new way of using governance actions and verifying the validity of a proposed course of action (which will have an ecosystem-wide impact) by - in this case - one of the founding entities. It is a motion that is effectively being pursued in the name of the community.

I do think founding entities have some form of bigger responsibility towards the community - its a bit like carrying a 'nobility title'. They come with strings attached. You can't just use the 'title' Founding Entity, but then also have an expectation not to be held to higher standards.
Very nice to see the Cardano Foundation proposing to fund this effort for registering new generic Top-Level Domains - and to secure a community mandate to do so. The latter part did not require an explicit confirmation from DReps, but doing so - sort of widens the legitimacy of this initiative.

Essentially, if successfully implemented, this is also a marketing push that will be globally visible. Very nice.
I would also highlight an element from the plan: "to establish a dedicated Community Advisory Group to guide the management and development of the gTLDs".

I would personally advise the CF to use this opportunity (creating a Community Advisory Group) - to explore the creation (or to document) possible templates for the creation of future functional Community Advisory Groups - for different purposes.

Obtaining community input in a fair and balance way, while not succumbing to analysis paralysis and in-fighting or disputes - is difficult. A successful process with the Community Advisory Group - could set out the best practices for providing community input in cases where there is a need to combine a lead (institutional) player - with feedback from a decentralized community.

Essentially, there could be some space to develop some proto-governance on-the-go (takeaway) solutions for specific initiatives. What comes to mind from real life as inspiration - for different purposes are Citizen Groups which advise through various mechanisms.

These - in real life include Advisory Boards - groups that provide input on specific issues, and ... maybe also important Assemblies, which are randomly selected groups that engage in deliberative processes to develop recommendations.

Well, back to the proposal. Proposing to fund it without Treasury funds - seems to be the right approach and a well balanced decision. Involving community players, developers and conducting consultations with them - is another point that I appreciate.
To keep it short, I see it as constructive and future-oriented.

This is something new, that was not possible before. No reason for me to look back into relationships among founding entities. Our Cardano cards have been dealt and for brand new future initiatives (that do not involve any legacy commitments) - we have the starting point that we have. So, if I chose to move forward or move back - move forward.

Clock ticking. Not waiting 5-6 epochs to cast my vote.
Preface to rationale: DRep compensation is a different ball game. DRep compensation would likely introduce a layer of new problems in minimum viable governance at this stage - through a proliferation of DRep-to earn players.
Not so for the Constitutional Committee (CC). The CC should serve an independent and formidable barrier to governance capture. Especially when it comes to pressure from the big Cardano players, current or future.
I set a personal DRep limit to approve up to ₳200-250M of spending in 1st year of minimum viable governance. I committed to vote YES to open source @cardano_govtool as my last YES vote this year (apart from emergencies).
Governance integrity in a period of minimum viable governance is a barrier to capture. The CC should be able to vote on the constitutionality of all motions - while dedicating sufficent time and effort to the process. Empowering a community elected, independent CC to protect Cardano from governance capture falls under emergency motions in my view, as the governance system is untested.
Conflicts of interest: I am not affiliated with the future CC members, apart from a staking relationship as an ADA holder. My SPO (TECH) is member of the Tingvard CC member. I have never met any of the CC members. TECH pool refunded part of the pool revenues to stakers in earlier epochs - and I benefited from that as one of the pool's many stakers.

Ralph Waldo Emerson:

"The other terror that scares us from self-trust is our consistency; a reverence for our past act or word" and "Why drag about this corpse of your memory?"

This is a better version than the existing constitution 1.0 and the proposed v 2.0 in my opinion. More precise, less typos and some important improvements, including immutable documents. More clarity about the term Net Change Limit is a big win. The unified terminology will be of help to the Constitutional Committee. The elimination of the Budget Info Action mechanism could simplify governance and help with DRep fatigue.

Finally, the biggest point of this proposal for me is to show that our constitutions are but snapshots in time of an ephemeral consensus -not a national constitution. They can and should be improved by the community without waiting for one of the big entities to spearhead the process. If this is a permissionless process and someone is proposing a clearly better, tighter, less ambiguous constitution, why would I vote No?

Let's move forward. If we can improve the constitution - let's be proud that we can do it and do it again.

This is a dynamic space. We might need to revisit the constitution many more times.

Evolution waits for no one.

I vote YES on the treasury withdrawal for active maintenance and development of the open source GovTool. Cardano's governance is not an afterthought - it was long planned as a core element of the Voltaire era. Realistically, we are at the very beginning. We only have minimum viable governance (MVG) but enabled, however this makes this proposal even more important. Having in-built governance in a blockchain protocol and then not funding an open source governance platform, does not make sense to me in the early days of Voltaire. GovTools has evolved through its trials. I personally use it on Cardano Preview, PreProd and Mainnet. Is there an functional alternative that is present on all three networks? GovTools now works smoothly for me as a minor DRep and I appreciate the ability to pin rationales automatically via IFPS. The inclusion of a Proposed roadmap with a dozen or so new initiatives to strenghten governance tooling makes sense. This is not a vote for GovTools, its a vote for Cardano open source governance platforms and tooling. I see these proposals like this one as an integral element of widening the footprint of the Voltaire era. I also remain open to supporting a competing fully open source proposal as well. We have seen how competition from other players has helped improve the GovTools proposal over the past few months. The success of Voltaire can not come in darkness. We need open source governance platforms to champion reason, liberties, and good decisions. We cannot lock ourselves out governance through closed-source platforms, or governance platforms controlled by large players who may prevent us from criticizing abuses of power.

ADDENDUM: No more YES votes from me in the first budget year of minimum viable governance (MVG). The current system of minimum viable governance - with heavy concentration of DRep power in the hands of a few DReps makes me even more wary of approving more treasury withdrawals. The majority of DRep power approved ₳272 million in treasury withdrawals in the first budget year of MVG. This effectively ties my hands for the rest of the budget year - apart from emergencies. I set a personal DRep limit to approve up to ₳200-250 million of spending in 1st year of MVG. I respected that. I voted YES to approve treasury withdrawals totallng around ₳173 million so far. As things stand, this could be my last YES vote to a Treasury Withdrawal this budget year, apart from open source governance tooling (if good) - I see that as a necessity/emergency under MVG. Other emergencies may crop up - which might require an emergency YES vote if a true emergency.

オープンソースのGovToolの積極的な保守と開発のための資金引き出しに賛成票を投じます。Cardanoのガバナンスは後付けではなく、Voltaire時代の中核要素として長らく計画されてきました。現実的に、私たちはまだ始まったばかりです。最小限の実行可能なガバナンス（MVG）は有効化されているものの、だからこそこの提案はさらに重要になります。ブロックチェーンプロトコルにガバナンスが組み込まれているにもかかわらず、オープンソースのガバナンスプラットフォームに資金を提供しないのは、Voltaireの初期段階では私には理解できません。GovToolsは試行錯誤を経て進化してきました。私は個人的にCardano Preview、PreProd、Mainnetで使用しています。3つのネットワークすべてで機能する代替手段はありますか？GovToolsは現在、マイナーDRepとしてスムーズに動作しており、IFPSを介して根拠を自動的にピン留めする機能には感謝しています。ガバナンスツールを強化するための10数個の新しいイニシアチブを含むロードマップ案が含まれているのは理にかなっています。これはGovToolsへの投票ではなく、Cardanoオープンソースガバナンスプラットフォームとツールへの投票です。今回のような提案は、Voltaire時代の足跡を拡大する上で不可欠な要素だと考えています。また、競合する完全オープンソースの提案も支持する用意があります。過去数ヶ月にわたり、他のプレイヤーとの競争がGovTools提案の改善にどのように貢献してきたかを目の当たりにしてきました。Voltaireの成功は暗闇の中では実現しません。理性、自由、そして適切な意思決定を推進するためには、オープンソースガバナンスプラットフォームが必要です。クローズドソースプラットフォームや、権力の濫用を批判することを阻む可能性のある大手プレイヤーが支配するガバナンスプラットフォームによって、ガバナンスを自ら締め出すことはできません。

追記：最小限の実行可能なガバナンス（MVG）の最初の予算年度には、私はもう賛成票を投じません。DRepの権限が少数のDRepに集中している現在の最小限の実行可能なガバナンスシステムを考えると、私はさらなる資金引き出しの承認にさらに慎重になります。 DRepの権限の大半は、MVGの最初の予算年度に2億7,200万ナイラの国庫引き出しを承認しました。これにより、緊急事態を除き、残りの予算年度は事実上、私の手が縛られることになります。私は、MVGの最初の年度に2億～2億5,000万ナイラまでの支出を承認するように個人的なDRepの制限を設定しました。私はそれを尊重しました。これまでに合計約1億7,300万ナイラの国庫引き出しの承認に賛成票を投じました。現状では、オープンソースのガバナンスツール（良質であれば）を除けば、これが今予算年度の国庫引き出しに対する最後の賛成票になる可能性があります。私は、オープンソースのガバナンスツールはMVGの下では必要不可欠/緊急事態だと考えています。他の緊急事態が発生する可能性があり、真の緊急事態であれば緊急の賛成票が必要になる可能性があります。

I vote NO on this motion as it - for all purposes - seems to have been submitted incomplete. I may change my vote if credible information to the contrary emerges. If this motion is indeed incomplete, it should not pass. I am basing my NO vote on information from the vice-chair of the Intersect Product Committee Kyle Solomon who stated in his own vote on this very motion that: "the Product Committee is already planning to solicit feedback via info action circa end of October". What is more, Solomon added that this current motion "is essentially heavily incomplete work" and that there will be a subsequent vote again - on a more complete proposal.
Link to the Intersect Product Committee vote: https://raw.githubusercontent.com/adosiawolf/drep-rationale/refs/heads/main/0052

I'll vote NO - see "ADDENDUM" at the end of this rationale for explanation why I will not vote YES for more spending in first year of minimum viable governance.
What follows from "THOUGHTS" below to the "ADDENDUM" are my thoughts on the process/proposal right now. If I made some mistakes, it wasn't on purpose. Could be my lack of knowledge, my lack of understanding, an oversight and/or just exhaustion from L2 Catalyst moderation stage. Anyway, feel free to ignore. Just thinking out loud and appreciate all efforts to create a better present & future for Cardano. I'm sorry, but I don't have time to shorten this rationale.

THOUGHTS:
We have a system of minimum viable governance on Cardano today. I approach treasury funding with caution - as minimum viable governance is young and untested - especially in terms of ultimate outcomes.
In my opinion, this proposal is too big a bite for the first year of MVG. I do appreciate Elder Millennial's attempt to resolve a major issue on Cardano that was not resolved during the period of the Cardano Triumvirate (Emurgo, IOHK, and Cardano Foundation).
The objective makes sense. Cardano could benefit from deeper stablecoin liquidity. Yet, I have personal doubts that this can be implemented properly today with the current oversight abilities that we have, despite the good intentions.
For me the proposal expands the treasury’s role to a sort of a market-maker - not that it cannot be changed, but it is important to note it is being modified and this is a precedent. This early in on-chain minimum viable governance, the perceived risks to the treasury are greater than the perceived ecosystem benefits to me. A market-maker role is possibly also going to bias future net change limit (NCL) votes for 2026 as it normalizes protocol-owned liquidity and expectations for repeat funding - and having Emurgo, CF and IOHK reps in the committee could contribute to using this as a precedent for higher NCLs. This creates a sort of path dependence and expectations for repeat funding. Only one of the three above is not a major DRep.
I would have liked to see more reference to risk policies in regards to deploying the funds. Are there hard caps per issuer/protocol, a freeze playbook, rules for managing impermanent loss. I don't know, I'm not a DeFi expert - however, there could be some sudden market swings, depegs, etc... will there be a general rule / play book?
Legal structures to fully support the fund, the committee, and the tDAO will be proposed to the community, which addresses legal risk management but also further complexity at this early stage of governance. I understand they are necessary. Yet, complexity builds upon complexity.
Can we really predict that this will lead to good outcomes? The "three-body problem" - predicting the motion of three celestial objects under their mutual gravitational influence - apparently leads to chaotic and unpredictable orbits (sorry, reading the Deep Simplicity book right now, so this just crossed my mind) Are we setting up an unpredictable and untested set of bodies to manage stablecoin liquidity that will be seeded with a large sum of money from the treasury from the outset? With no pilot, small test of real viability?
The tDAO kill-switch/return-to-treasury is a good construct, still needs to be proven in practice.
Now, about the bodies. The committee executes, the tDAO (DReps) oversees. Speaking of the tDAO, representatives of some of the largest DReps are both in the committee, while their home orgs are performing oversight functions on the committee through the tDAO.
DRep oversight is not mature enough today. I doubt the ability of DReps this early in the governance game with the tools they have at their disposal - to monitor the true outcomes of complex liquidity operations in real-time - and to follow and react fast enough if problems emerge with the committee or its performance.
Concentration, capture, and political pressure are risks. The ethical considerations for the Committee are not strong enough. Some of the language - I will capitalize it: "In cases where a committee member is an employee of an organization that develops or runs a protocol, they SHOULD abstain from the vote. Other cases such as contract or consulting work MAY ALSO CONSIDER ABSTAINING on a case by case basis depending on the nature of the relationship." Mandatory recusals, public disclosures on every decision are needed from all committee members - overall I would like to see a more robust and airtight section on Ethical Considerations for the Committee and conflicts of interest. Add more guardrails, consider disinterested majority votes and public recusal logs.
Having heavyweight representatives from Cardano Foundation and Emurgo on the committee side while they’re also among the largest DReps (Emurgo additionally owns Yoroi wallet) is a concern for me. It concentrates influence in the committee and can sway tDAO oversight outcomes - they are large voting blocs of ADA.
EMURGO serves as the technology provider for USDA, although has not provided funding to Anzens Technology. A technology provider is a related party, still not neutral. Emurgo can still have economic and strategic incentives to sway events to its benefit. Those incentives create a related-party situation. This is less severe than direct ownership, but it is not neutral. Recusals and disinterested voting are underappreciated.
While Emurgo is a technology provider for one of the stablecoins, USDM is built by W3i Software, Inc. and issued by Moneta Digital, with support and investment from the Hoskinson Family Office, a venture co-founded by IOG founder Charles Hoskinson. However, IOHK is not a DRep and does not directly participate in governance as a DRep. IOHK and Charles not acting as DReps removes the direct DRep voting conflict. The office's investment in USDM’s issuer creates some economic alignment with a beneficiary of the program, which could be an indirect conflict - depending on the relationships between IOHK, the office, etc... The proposal should make sure that this is a conflict to be disclosed and properly managed as well.
Overall, to conclude, a smaller, time-boxed pilot with super strong conflict of interest management, KPIs and more rule books / play books may be more acceptable to me.

ADDENDUM: No more YES votes from me in the first budget year of minimum viable governance (MVG). The current system of minimum viable governance - with heavy concentration of DRep power in the hands of a few DReps makes me even more wary of approving more treasury withdrawals. The majority of DRep power approved ₳272 million in treasury withdrawals in the first budget year of MVG. This effectively ties my hands for the rest of the budget year - apart from emergencies. I set a personal DRep limit to approve up to ₳200-250 million of spending in 1st year of MVG. I respected that. I voted YES to approve treasury withdrawals totalling around ₳172 million so far. As things stand, the upcoming @cardano_govtool proposal (if good and if submitted) could be my last YES vote to a Treasury Withdrawal this budget year, I see that as a necessity/emergency under MVG. Other emergencies may crop up - which might require an emergency YES vote if a true emergency.

This loan proposal is apparently a better deal for the Cardano treasury than the previous proposal that was submitted on August 2 ["Withdraw ₳5M for Cardano's Global Listing Expansion - Powered by Snek"]
I do not hold Snek and I have never purchased it. I appreciate its contributions and I wish them massive success and a lot of investments and commercial interest and a profitable future.
I have to preface this rationale by the contents of a disclosure warning that pops up immediately after visiting the snek.com website: "SNEK is a meme coin with no intrinsic value or expectation of financial return. There is no formal team or roadmap. The coin is for entertainment purposes only." One is unable to visit the site until one clicks "Confirm".
The team does state on the web page that: "Snek is the largest token in the Cardano ecosystem by market cap and by all-time trading volume. It is a memecoin that stands out by having built an ecosystem of products around its brand. These products include: Snek.fun (token launchpad), SNEKx (token minter), SNEKbot (telegram trading bot), SNEKalerts (alert bot for X, discord, and telegram) and Snek Energy (energy drink)." The team claims that the products ensure Snek's long-term sustainability.
Obtaining exchange access is real leverage. SNEK already broke through on Tier-1s (Kraken, Crypto.com, KuCoin). A loan (vs. grant) is healthier for Cardano's Treasury culture.
I do remember a DC Spark request for a loan from Catalyst. I do not remember how I voted on that one (I think I may have voted NO), the team has since repaid it. So there is a positive precedent. That was Catalyst, this is now the Treasury. Similar, but different.
However, we have to be real here about credit risk. Is credit risk actually controlled and enforceable?
This proposal represents mostly token-specific marketing + liquidity for a meme asset with a commercial arm. Right now it is being pitched as “global listing expansion for Cardano.”

The board with CF/EMURGO/Midnight leaders is a heavyweight move that lends credence.
Overall, I see this as a risky precedent for the Cardano treasury. It sets a token-specific subsidy with weak creditor protections - it seems like a near risk-free loan.

There is no amortization from day 1 with quarterly repayments, as the loan repayment must commence no later than the last day of year 3. A lot of water will pass under the bridge by the end of year 3.
The risk for the Cardano treasury is underpriced at an interest rate of 2.44% (the budget motion states: "the current average Cardano staking rewards rate of 2.37% per year, plus an additional 0.07% as a gesture of good faith"). I presume that this collateral-free loan should be at a much higher rate, if it were to be implemented.

Are there signed letters from each proposed advisor? Will they publish conflict-of-interest and recusal policies?
EMURGO, the commercial arm of Cardano with an investment arm (EMURGO Ventures), is designed to do exactly this kind of thing/ It is interesting that they are not opting to place structured, risk-priced capital into this project. Does it mean that it does not believe it will drive adoption and generate returns? I do not know. If EMURGO or other commercial investors won’t underwrite on commercial terms, the Treasury shouldn’t step in on under-priced, unsecured terms.

Addendum: No more YES votes from me in the first budget year of minimum viable governance (MVG). The current system of minimum viable governance - with heavy concentration of DRep power in the hands of a few DReps makes me even more wary of approving more treasury withdrawals.
The majority of DRep power approved ₳272 million in treasury withdrawals in the first budget year of MVG. This effectively ties my hands for the rest of the budget year - apart from emergencies.
I set a personal DRep limit to approve up to ₳200-250 million of spending in 1st year of MVG. I respected that. I voted YES to approve treasury withdrawals totalling around ₳172 million so far.
As things stand, the upcoming @cardano_govtool proposal (if good and if submitted) could be my last YES vote to a Treasury Withdrawal this budget year, I see that as a necessity/emergency under MVG. Other emergencies may crop up.

No more YES votes from me in the first budget year of minimum viable governance (MVG).
The majority of DRep power approved ₳272 million in treasury withdrawals in the first budget year of MVG. This effectively ties my hands for the rest of the budget year - apart from emergencies.
Why? I set a personal DRep limit to approve up to ₳200-250 million of spending in 1st year of MVG. I personally voted YES to approve treasury withdrawals totalling around ₳172 million so far.
As things stand, the upcoming @cardano_govtool proposal (if good and if submitted) could be my last YES vote to a Treasury Withdrawal this budget year, I see that as a necessity/emergency under MVG.
"The Cardano in Oceania: A community-led strategic plan for investing in growth" info action does not fit the bill of what I would deem an emergency. So, I vote NO.
I have to add that I am naturally disinclined to vote YES for regional-based proposals, bar exceptional circumstances and the weight of providing overwhelming evidence in favour of such an approach will be on the proposer.
Hence, I am already indicating to the proposers of "The Cardano in Oceania: A community-led strategic plan for investing in growth" info action that it is unlikely that I will support this proposal IF it is resubmitted in the following budget year.

I commend Yuta as the main author of the CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION v2.0.
Although I previously participated in a Cardano Constitutional Workshop - before the original constitution 1.0 was approved - the workshop I attended was rigid, comnstrainted by 10 narrow pre-selected questions that participants were forced to discuss and the sessions were overlong and overly scripted. That's my experience and I cannot refer to any other experience.

Essentially, workshop participants (in the workshop that I took part in), were awarded a role akin to infants permitted to play with 10 small toys in a large toy shop. It was limiting and uninspiring and sort of irrelevant.
YUTA put forward a document for CONSTITUTION v2.0, allowed everyone to leave feedback multiple times over a long enough period. Every time I did leave suggestions, he carefully considered each input, responded and took on board all suggestions for improvements, while carefully weighing their possible implications.
There are many, almost invisible tweaks that this version makes, improving the original document. I think this version also clarifies many aspects in the original constitution that could be misinterpreted or could allow room for differented understandings.

There are also many substantial improvements that have been introduced. Overall, I think this is a better, more relevant document than the original constitution 1.0.
Is it perfect? No. Is it better than the original constitution 1.0 ? Yes, in my opinion - although there might be some major issues that someone else would like to raise. If so, raise them. This attempt could fail, but could be improved further with inputs from some other quarters.
Could there be some hidden flaws? Possibly. Fortunately, we also have the Cardano Constitutional committee as well to double-check that we are not transgressing on some important point. And other geat governance experts and legal minds.
Am I biased? Yes, clearly. So take my opinion with a large grain of salt. I see multiple instances of some of my wordings that were incorporated in this version. Seeing one's own words makes one more partial to the document. So, caution! Read it for yourselves.
I've read it several times along the way as it was been refined . THis means I am not coming at it with fresh eyes and I may be missing something, so other DReps who did not participate in this process, should look at the proposed CARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION v2.0 very carefully.
Should the community try to improve constitution 1.0 - definitely yes. Should it wait for some big entity to organize a top-down process, I think no.
Also, please read constitution 1.0 and the typos, errant phrases, different phrasings for the same thing, and loose wording - that this version tightens up.
Overall, this might be a welcome step forward.

CARDANOブロックチェーン・エコシステム憲法v2.0の主要執筆者として、YUTA氏を称賛します。
私は以前、憲法1.0が承認される前にCardano憲法ワークショップに参加したことがありますが、私が参加したワークショップは堅苦しく、参加者は事前に用意された10個の限定的な質問について議論を強いられ、セッションは長すぎ、過度に台本化されていました。これは私の経験であり、他の経験について言及することはできません。

本質的に、ワークショップ参加者（私が参加したワークショップ）は、大きなおもちゃ屋で10個の小さなおもちゃで遊ぶことを許された幼児のような役割を与えられていました。それは制限的で、刺激がなく、ある意味無意味でした。
YUTA氏は憲法v2.0の文書を提出し、十分な期間にわたって全員に複数回フィードバックを残す機会を与えました。私が提案を残すたびに、彼はそれぞれの意見を慎重に検討し、返信し、改善のためのすべての提案を慎重に検討しながら、その影響を慎重に評価してくれました。
このバージョンでは、ほとんど目に見えない多くの修正が加えられており、元の文書を改善しています。また、このバージョンでは、誤解を招きやすく、異なる解釈の余地を残しかねない多くの側面が明確にされていると思います。

また、多くの重要な改善点も導入されています。全体として、これは元の憲法 1.0 よりも優れた、より適切な文書になっていると思います。
完璧ですか？いいえ。元の憲法 1.0 よりも優れているか？はい、私の意見ではそうです。ただし、他の誰かが指摘したいと思う重要な問題がいくつかあるかもしれません。もしそうなら、指摘してください。この試みは失敗するかもしれませんが、他の方面からの意見を取り入れることで、さらに改善できる可能性があります。
隠れた欠陥があるでしょうか？可能性はあります。幸いなことに、重要な点に違反していないかを再確認してくれるカルダノ憲法委員会もいます。そして、他にも優れたガバナンスの専門家や法律家がいます。
私は偏っているでしょうか？はい、もちろんです。ですから、私の意見は鵜呑みにしないでください。このバージョンには、私の言葉が複数取り入れられているのが分かります。自分の言葉を見ると、よりその文書に偏ってしまうものです。ですから、ご注意ください！ご自身で読んでみてください。
私は、この文書が改訂される過程で何度も読み返しました。つまり、新鮮な視点で取り組んでいるわけではなく、何かを見落としている可能性があります。そのため、このプロセスに参加していない他のDRepの方々は、提案されているCARDANO BLOCKCHAIN ECOSYSTEM CONSTITUTION v2.0をよく読んでください。
コミュニティがConstitution 1.0の改善を試みるべきか？もちろんそうすべきです。しかし、大規模な組織がトップダウンのプロセスを組織するのを待つべきかどうか？私はそうは思いません。
また、Constitution 1.0をよく読んで、誤字、誤った表現、同じ内容の異なる表現、そして曖昧な表現など、このバージョンでは改善されている点を確認してください。
全体として、これは歓迎すべき前進と言えるでしょう。

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
Cardano’s treasury should not become the crypto equivalent of a 2009 bank bailout. While the situations differ, the principle is the same: public funds shouldn’t underwrite private risk.
OK, maybe I started strongly (just to remind us why are we all here), but personally, I am generally not inclined towards spending Treasury funds directly for supporting individual commercial projects, regardless of how deserving they are and how much they have contributed or if there might be potential positive spillover to other projects by association.
I am not saying I am 100% right, just that I need to be convinced that it is worth it and this proposal does not convince me.
The proposal partly reads as a grant. Yes, there could be down-the-line positive externalities for other projects, but overall this proposal is outside my comfort zone for using Treasury funds.
If a single-asset promotion of this size is approved, it may encourage other memecoins (and serious projects) to line up with “list us too” requests. They will see a precedent and they will follow it.
We also have some opportunity cost here. The ask for ₳5M could fund some core tooling (HD wallet libraries, indexers, etc..) that benefit all dApps, not just one token pair.
I have to take into account that the cost of developing Aiken (compiler, standard library, language server, installer, documentation, editor integrations, testing framework and all peripheral tooling) amounted to $500k-$1M. [ https://x.com/_KtorZ_/status/1888287575464464540 ]
We do not know which token will succeed two or ten years from now and we cannot second guess the future, however we do know that if we do not have the tooling and the infrastructure the best will not emerge.
SNEK's success was largely due to the team's innovative approach, but also due to the investments in core tooling made by Cardano that may seem invisible, but these investments today power the Cardano protocol and its underlying tokens.
I think the Treasury should not give precedence to individual projects when possible to avoid selecting winners and losers.
However, I am not saying my opinion should prevail, so I will give a few suggestions to improve this Treasury Withdrawal request:

1. Make sure it is constitutional
2. Show proof that the proposed Board of Advisors is indeed "on board" with this initiative.
   I did not see confirmation that the following people have accepted the proposed roles:
   a. Tal Cohen, former CEO of Kraken
   b. Phillip Pon, CEO of Emurgo
   c. Rapha C-Roy, CEO of Snek Foundation
   d. Prominent leaders from the Cardano ecosystem and the compliance sector - more to come on this.
3. See point 2d above, "more to come on this" sounds like unfinished business. Finish the entire proposal before submitting a Treasury Withdrawal. Also, provide Tal Cohen's current roles, not only former ones. Provide the board's biographies, instead of one-liners.
4. Many projects can make the following argument (some with less, some with more justification): "Backing this initiative isn’t simply an investment in a single token" or "This proposal isn’t just about Snek". Essentially, no investment in a token is really just an investment in a token - as there is some spillover for Cardano. Are the ecosystem-wide risks or benefits of the proposal as currently written - worth the grant ask?
5. SNEK has undeniably pushed the envelope. Kraken and Crypto.com listings are tangible wins. Essentially, this proposal bundles some very legitimate Cardano ecosystem pain points with a memecoin-centric marketing spend. I think these two can be linked - but I am not convinced that the spend will resolve the Cardano ecosystem pain points that were stated.
   Finally, the constitutionality of the proposal will be assessed by the Interim CC. There are some signs that there might be some possible issues for consideration in terms of constitutionality.

This proposals has requested just 5ADA in the field for the withdrawal amount- it is unlikely they will achieve the goals with 5 ADA, so I have to presume it is a likely typo. Hence, I vote NO.

The constitutionality of the proposal will be assessed by the Interim CC. There are some signs that there might be some possible issues for consideration in terms of constitutionality.

I am modifying my earlier NO vote on this proposal, after reconsidering. Essentially, my arguments still stand that I think that this proposal would be better served if it were not bundled in a single withdrawal action with a combined ₳11,070,323 budget. However, I did make an exception in the case of the IOG core proposal and I've been thinking about this inconsistency in my voting record - an inconsistency in approach that is penalizing this specific team and proposal.
Furthermore, the first year's process was very complicated for all vendors and Tweag went with a similar approach to IOG and I penalized them with a NO vote - while giving a free pass to IOG to bundle everything in a proposal that is 5-6 times more expensive. In my original rationale - which is added to the bottom of this one - I specified which components I would have supported as individual submissions. For clarity, I did not include Peras in that list originally, as I thought there was potential duplication with IOG. However, now I would include Peras in a YES vote - following clarifications from TWEAG on social media (see full exchange below). Essentially, I do support the following components: Peras (NEW ADDITION), Canonical Ledger State, Black box Ledger Conformance Testing, Conformance Testing of Consensus, Block Cost Investigation, and History Expiry.
I will make an exception in this First year of governance - for core infrastructure - and will modify my NO vote to a YES. I have not been contacted or asked to modify my vote by anyone, but this has resulted after a public exchange of tweets that started with me seeing this tweet from Samuel Leathers @therealdisasm "I can't emphasize this enough. Part of Modus Team is covered by the IOG contract, but the rest is working on the initiatives in this proposal. If we don't get this one across the line, it's going to really slow down Cardano Haskell node development. Please support it Dreps!!!" [ https://x.com/therealdisasm/status/1951317916915290193 ]. I followed up with questions to Tweag: "1. Is there any duplication/overlap with the IOG core proposal? (will possible duplication issues be resolved) 2. Also what's Modus Team? 3. The Haskell node work by Tweag will be part of the wider multi-node approach being pursued currently? Thanks!@KrisKowalsky " [ https://x.com/InputEndorsers/status/1951324660760461792 ]. The response I got was " Hi, thank you for your questions. 1. There is no duplication and our team is helping with Leios. While IOE is already helping with Peras. Example of two crucial projects. 2. Tweag is part of Modus Create, we currently have more than 20 engineers working on various cardano projects. 3. We are collaborating on Multi Node initiatives, I would like @osymandias to give a better answer. " [ https://x.com/KrisKowalsky/status/1951329436801941538 ].
I would - at this point in time - advise teams not to submit Mega bundles of proposals as it can be difficult to support them in early days of governance. Also, I think ensuring that IOG has healthy competition in this core engineering space RE: Haskell node is good for Cardano. It might have been good to see Well Typed and others also submit some proposals of its own.
MY OLD RATIONALE TO VOTE NO IS ATTACHED BELOW.

I voted NO on this proposal in Ekklesia and unfortunately, despite the stellar reputation that TWEAG has, this omnibus proposal has not convinced me that it should be a single package. \nNote: I would like to see TWEAG continue to participate in developing Cardano. \n\nI have already voted for a couple of omnibus and high-cost IOG proposals (the IOG proposals are a case sui generis in 2025) and - although TWEAG has rightfully copied the approach by IOG, I think that this proposal would be better served if it were not bundled in a single withdrawal action with a combined ₳11,070,323 budget. \nAlso, I want to commend TWEAG for providing a really stellar accompanying PDF on "TWEAG’s Proposals for multiple core budget projects for Cardano 2025". I twas an interesting read. \nI would have voted for some of the components of this proposal - if they had been submitted individually. \nI could see myself supporting the following components of this omnibus proposal (had they been submitted separately):\n1. Canonical Ledger State\n2. Black box Ledger Conformance Testing\n3. Conformance Testing of Consensus\n4. Block Cost Investigation\n5 History Expiry

I voted NO on this proposal during the budget structuring stage that was organized over Ekklesia by Intersect. I have not changed my original intention. I thank the proposers for submitting this proposal. This proposal intends to provide a Treasury-financed Ecosystem Exchange Listing and Market Making service pool which will provide MMAAS (Market Making as a Service). The eligible tokens are SNEK, IAG, MIN and HOSKY, as well as stablecoins USDM, USDA, iUSD, DJED, KINKA (gold backed). This proposal has not convinced me that the Treasury should fund the listing of tokens on exchanges. This entire process - if it is to be performed with treasury funds - should be part of a grand strategy that should look into the merits, costs and benefits for the entire Cardano ecosystem. We have so far heard different narratives about the responsibilities of different Founding Entities and their alleged failures to help list Cardano native tokens on Tier-1 exchanges. We are unable to get a definitive narrative that explains the background of these efforts and responsibilities.
So, we sort of start from zero, but we do not start from zero. Treasury Funding is not Genesis ADA. We all see that some Founding Entities still retain significant amounts of Genesis ADA and this ADA is deployed in governance to swing votes directly or indirectly through a choice of DReps. Without full accountability regarding what was whose responsibility and what was a success and what was a failure, I do not feel that the Cardano Treasury should double fund something that was allegedly supposed to have happened so far. I prefer to make strategic investments in open source infrastructure that reinforces decentralization. Subsidies to native tokens - should probably be a rare exception, not the rule.

I voted ABSTAIN on the "A free Native Asset CDN for Cardano Developers" proposal over the Ekklesia voting tool during the Intersect budget vote stage. I have spent days going back and forth over this proposal and how can I align it with my views about what can we do with Treasury funds sustainably.
Essentially, I always have a lingering feeling that if we fund something commercial for "18 months" - we are really kicking the can down the road. And later in that many months we have the same can and just less money available.
Yes, this is an important tool for the NFT world to display Cardano native assets (NFTs &FTs) efficiently. The team members are known for their committment to Cardano and this works in favor of the proposal - as they have already built in our ecosystem and know it.
NFTCDN is a managed Infrastructure-as-a-Service (IaaS) provider that here is asking essentially for direct funding of NFTCDN to make it free for all Cardano builders for 18 months under an SLA contract.
My knee-jerk reaction is to say no. However, this will ease the ability of other teams building on Cardano to integrate NFTs and FTs... However, they have shown the the cost can be seen as lower - if we factor in savings in other projects that will be able to use this service for free.
Still, I am wary of precedents, so I asked the proposers over X (Twitter) about "any intentions, plans, considerations about open sourcing your codebase?" [ https://x.com/InputEndorsers/status/1949430196945178975 ]. Fortunately, the team saw the question and responded. "@nftcdn_io Jul 28 Hey - great question & we appreciate you asking! 💙 Short Answer: If funded, this proposal gives us the usage data to pursue one (or more) of 3 possible future directions for NFTCDN: Open-source, Decentralise, or Transfer (e.g. to a gov-aligned org stewarding core Cardano infra). Longer Answer: Following valuable feedback from @yuta_cryptox and other DReps, we've scoped three strategic routes post-proposal:(i) Open-sourcing NFTCDN for the Cardano public to use, (ii) decentralising NFTCDN, so that no one person/company is responsible for running it, or (iii) transferring NFTCDN to a public-good org that can scale it w/ sustainable ops (e.g. low-cost-country resourcing) to operate and/or maintain. Each route has pros/cons, and none of them are straightforward, but they all serve the long-term goal; ensuring Cardano's native asset display capability is accessible, resilient and easy for developers. This proposal enables us to collect meaningful usage and impact data, which will underpin the case for any of these options and our aim is to bring option papers for DRep signalling which would convert to proposal(s) for execution.Hope this answers your question!" [ https://x.com/nftcdn_io/status/1949900316549202270 ]
To summarize, I intend to vote YES to this proposal, thanks to this clarification. However, my expectation is that the proposers behind this proposal will come up with detailed and credible options to put in front of DReps about the future direction of NFTCDN: Open-source, Decentralise, or Transfer. If these options are not clearly developed - based on meaningful usage and impact data, which will underpin the case for any of these options - well before the 18 month funding expires, I will not support a similar future funding request for NFTCDN.

This governance action is a formal ratification of a voting process that was held to replace the current Interim Constitutional Committee with the new committee selected by participating DReps during the Intersect-hosted election process from May 5th to July 6th, 2025.

As the seven candidates have received the most support in the election, I hereby vote YES to ratify this decision through my on-chain vote as a DRep.

I voted NO on the HAUS proposal to "Withdraw ₳3,000,000 for High-yield RWA Asset for Cardano: Tokenized Real Estate" in the Ekklesia voting tool. It is admittedly an interesting proposal and with Emurgo's renewed focus on RWAs under the leadership of new CEO P. Pon - I though I should pay more attention to the RWAs side of blockchain. So, I reread this proposal carefully.
The vendor wants to build an open-source Tokenized Home Equity Liquidity Protocol... and adds that they prototyped and deployed this model on a private Ethereum blockchain (not sure which one - maybe they should have mentioned which one and how it works now exactly - with some more flesh on the bones).
One problem I have with the proposal is that the case for moving from Ethereum to Cardano is not well explained. The failure or lack of success or maybe success (?) on Ethereum is also glossed over. We have an attached document on "Why Cardano is the Ideal Blockchain for Haus" - however the document is pretty shallow in my view. Also, if it is entitled "Why Cardano is the Ideal Blockchain" ... I would presume that the vendor would not even require Treasury funds for the move - "Ideal" is a pretty strong word for a business to use.
I would have loved to read about when Haus chose Ethereum and why did it not play out. Who made the decision to launch on Ethereum and why was that a mistake (if it was?). What was the main bottleneck - was it the L1 blockchain? Or was that a side issue. I just needed to read something that pinpoints that this marriage to Cardano is THE missing piece for HAUS (and by proxy for Cardano).
There also seems to have been an add on LinkedIn earlier this year about Haus Coin hiring a dev for a migration to Solana. The team responded that "1️ Solana was part of early exploration 2️ Today, Haus is focused on Cardano" [ https://x.com/haus/status/1949573434406789289 ], they also added "Thank you, great question. We think Solana is an incredible ecosystem: the developer energy, user growth, and innovation in DeFi and payments are undeniable. We’ve had great conversations with teams there. For Haus, the decision to focus on Cardano for this next phase isn’t about rejecting Solana, but about aligning with the specific things we need right now, namely, a deeply research-driven approach to security, a robust identity framework, and a governance model designed for real-world asset tokenization." [ https://x.com/haus/status/1949574817105248714 ] .
However, fortunately for HAUS, I found the "The Haus Protocol: A Technical Blueprint for Onboarding $34.5T of Real-World Home Equity to Cardanoblog post on Essential Cardano [ https://www.essentialcardano.io/article/the-haus-protocol-a-technical-blueprint-for-onboarding-dollar345t-of-real-world-home-equity-to-cardano ] - I did not see it linked on the ADA Stat governance page - nor on Gov Tools. Actually, this document - the technical blueprint - is probably the strongest supporting material they could have produced - shame they didn't link it to the governance action.
The Technical Blueprint seems an impressive piece of work and analysis: it proves the team understands Cardano’s primitives (eUTXO, CIP‑68 NFTs, Aiken, multi‑oracle patterns) and sketches a credible path to plug $HAUS into the general Cardano scene.
The team states that key infrastructure components and design patterns will be open‑sourced and audited by two Cardano‑specialist firms. They also propose to make sure that treasury grants get “repaid from a percentage of protocol operating profits”.
$HAUS coin seems to be a security. As such, its issuance and transfer are subject to securities regulations. They do outline how non‑accredited investors could join later, however this remains a plan and that filing has not started.
There are some unverified asset and revenue claims, such as the $20 million TVL, the 30,000 strong waitlist and $4.1 B pipeline are still self‑reported; no on‑chain proofs, no auditor letters.
Haus Coin on LinkedIn defines itself as a "A Cryptocurrency Revolution in Real Estate", but has 67 followers and 2-10 employees. I don't see the traction there, although I might be wrong.
The open source commitment isprospective, not evidence of an OSS repo for the ETH version today. The offered budget is a bit of a black box, lacking granularity for the ₳ 3 M ask.
Generally, I am not keen on blockchain migration proposals - when they are dependent on financing from the next blockchain that a project migrates to. Yes, it does make sense on paper - but it leaves open questions of whether these projects will always migrate to the newest platform / L1 that offers financing for migration.
What I am keen about is reading about the problems and failures and mistakes on the original L1 platform. Yet, this is usually glossed over. I mean I want details. Real nitty gritty details. I didn't see that here. I want to be convinced that this migration to Cardano is the only possible solution - or bust. That would convince me that the business model is not the problem nor the leadership - but the platform.
Anyhow, too big of an ask and risk at this moment for my appetite - I think its not a good fit for Treasury funding. Thank to the team for submitting the proposal, but I think we can spend the 3M ADA better with teams that have already deployed and committed to Cardano - by investing their own resources into Cardano - as a first step. Maybe try to build on Cardano if you believe in it so much - and then try to ask for additional Treasury funding to expand your project. Your first ask is too big for the associated risk of having the Treasury invest in your migration.

During the voting stage on Ekklesia, I voted ABSTAIN as I wasn't really sure about the merits of the proposal. Yes, the UTXo chains narrative is in vogue, but still this is a hefty ask from the treasury. I was especially interested in the open source aspects of GoMaestro's (Maestro's) output. I have to admit I did not have enough time to look into it during the Ekklesia voting stage - so, I ended up Abstaining.
With Intersect now submitting 39 different Treasury Withdrawal actions, I am now able to move from a more protective stance towards the treasury withdrawals to a slightly less protective one - as Intersect is not bundling dozens of proposals together. I was using the initial Ekklesia voting to mostly support proposals that I was more certain about.
In the case of the "Complete Web3 developer stack to make Cardano the smart contract layer for Bitcoin" proposal, I noticed a tweet from Maestro's Marvin DeFi stating that: "Maestro will be open-sourcing its core multi-chain indexer framework.We were going to share this later, but since multiple people have contacted me regarding our Budget Proposal. I wanted to make it clear to everyone." [ https://x.com/MarvinDefi/status/1918923821979164936 ]
The key featuers of the developer stack will be:

• Multi-chain compatible
• Modular and extendable UTXO indexer
• Block reorganization rollback protection
• Battle-tested, billions+ in request volume
  Maestro has already received investments from Emurgo - which I think seems to be a very good decision by Emurgo to strenghten core Cardano projects - which are also trying to bring to life the compatibility narrative among UTXO chains.
  From what I searched, it seems that Maestro provides open-source blockchain indexing and data-layer tools for UTXO chains like Cardano, Bitcoin, Dogecoin. Their API-based services include UTxO indexing, blockchain event notifications, mempool monitoring, market price feeds, smart‑contract triggers, wallet management, and transaction orchestration, all built on the same Apache-2.0 license opensource foundations.

I have voted ABSTAIN on this proposal during the Ekklesia tool voting stage. I reiterate my ABSTAIN vote for a Treasury Withdrawal.

I have voted ABSTAIN on this proposal during the Ekklesia tool voting stage. I reiterate my ABSTAIN vote for a Treasury Withdrawal.
This proposal for Cardano Ecosystem Pavilions at Exhibitions has - in the meantime - adjusted its budget downwards to ₳889,500, from the Budget Info Action approved ₳1,119,333. WHich is welcome for the Treasury, hopefully it is good enough for the team's plans still.
This is a tough one and I sense the committment from Dave and the DiscoverCardano team and their wish to promote the Cardano ecosystem through an approach that they have devised.
I am not a marketing expert. Yet, none of the marketing proposals (among the 39 ones) so far have received a YES vote from me.
I generally have a feeling that Cardano marketing has been stumbling - however it might also be a reflection of Cardano's better-than-thou serious narrative (research-driven... functional programming... yada, yada, yada ). Maybe this narrative is just off-putting to outsiders.
For this proposals - despite reading through the materials I do not know enough to be able to confidently judge the effect of ecosystem pavilions in the proposed events (listed as: Web3 Amsterdam, Paris Blockchain Week, HODL Summit Dubai, Crypto Expo Dubai, Gitex Nigeria, Future Blockchain Week Dubai, Gitex Thailand, and India Blockchain Week).
Overall, I think that the other marketing proposals involving some of the Cardano founding entities showed less sel-awareness (in terms of the image problems that Cardano faces - and how they have accumulated between 2017 and 2025) and as those ones were also much more demanding in financial terms, I had to vote NO on those.
For this one, I leave the possibility that I may be unable to grasp its significance, so I will ABSTAIN, thus not weighing against it with a direct NO vote.

I have voted YES on this proposal during the Ekklesia tool voting stage. I reiterate my YES vote for a Treasury Withdrawal.

I have voted YES on this proposal during the Ekklesia tool voting stage. I reiterate my YES vote for a Treasury Withdrawal. This is a proposal for Cardano's integrations with the UTXO world. Seems like a possibly very valuable set of tools (depending on how interests for Cardano links to other chains progresses). The vendor wants to allow devs to interact more easily with UTxO-based blockchains using a shared specification with focus on developer experience and performance. As an open-source initiative, it seems very good in scope for treasury funding. If it later needs maintenance and enhancement it might be a good fit for future funding from the "OSC Budget Proposal - Paid Open Source Model for Sustainable Development " ... which I also supported and I hope will prosper as a viable model for supporting such maintenance and enhancements.

I have voted NO for this proposal in Ekklesia and then voted over Tempo, however my rationale has not been added - not sure why. Alas, I didn't save the rationale, so this is a novel effort to write it up - as I try to accompany every vote with a rationale.
I maintain my NO vote on this proposal.

I have voted NO for this proposal in Ekklesia and then voted over Tempo, however my rationale has not been added - not sure why. Alas, I didn't save the rationale, so this is a novel effort to write it up - as I try to accompany every vote with a rationale.
I maintain my NO vote on this proposal. Let me preface this rationale with information that I think that the Cardano Builder DAO (CB DAO) is a worthwile idea and that the members are many renounced builders.
One issue here is whether DReps divest their responsibility to disburse Treasury funds to a DAO that will then manage the treasury allocation based on principles that it sets. The DAO states it wants to "support the application-layer growth of the Cardano ecosystem". This is necessary, of course.
The DAo wants to provide sustainable financial backing and strategic oversight to high-impact projects. I agree with the oversight part.
I disagree with the conclusion that "there remains a substantial gap in ongoing support for live, user-facing products/services." The Treasury mechanism in now live and DReps are participating in minimal viable governance.
As DReps we already have accepted the idea of having middlemen in the form of Budget Administrators - which are needed. There is no need to devolve DRep powers to multiple DAOs - that will be allocated funding. DReps represent the wider interests of the entire ADA holding community, DAOs represent the interests of the DAO members.
For example this very Cardano Builder DAO proposal proves that it is already possible to apply for Treasury Funding directly - I think that direct applications are better especially in these early days of governance. Namely, DReps have a mandate to look at proposals holistically, from the point of view of ADA holders, SPOs, the ecosystem interests and the needs of the application-layer.
Cardano Builder DAO proposes to use a transparent governance framework, strict accountability mechanisms, and a metrics-first funding approach. However, I think that on-chain governance already provides us with new opportunities, as well as initatives such as Project Catalyst.
I would not be in favour of derogating DRep responsibilities to mutliple DAOs, as if I vote YES to this proposals I would find it difficult to say NO to a second and third DAO applying for a fruther ₳12,000,000 or ₳20,000,000.
I think that governance decisions relating to allocating Treasury Funds should in principle be performed by DReps primarily, unless there are other circumstances that warrant it.
The proposals states that it "seeks to address the lack of dedicated, sustainable financial support", however I would point towards the examples of Gov Tool that was not approved as part of the Intersect Ekllesia process, but still applied with a budget governance info action and if approved it will move to the Treasury Withdrawal stage.
I think that there is now a dedicated source of financial support for projects that are deemed to be worthy of it. Maybe Cardano Builder DAO should think of coming with a proposal for specific projects - individually or in small groupings.

Still, I am not in favour of DReps - at this moment for sure - entrusting a DAO to choose what should be financed among their member projects with Treasury funding.
Many of CB DAO projects are stellar with exceptional devs and they have projects already live on mainnet. Having a CB DAO is a worthwile initiative - but I do not favour allocating ₳12,000,000 to create a new funding structure through CB DAO - that does not involve direct DRep approvals of such withdrawals / funding.

Maybe rethink the approach. Finally, I would point out that there are many Devs and Dev teams that are active as DReps and I am sure that their endorsement for all and any projects supporting the application-layer growth of the Cardano ecosystem - would be widely heard by the entire DRep group.

There is opportunity to apply directly to the Treasury by such projects or a group of projects - for specific needs. I prefer that to a delegation of such decisions by DReps to one or multiple member-based DAOs.

I voted NO for this proposal on Ekklesia and I will vote NO again. The proposal is welcome, as all proposals are. I think it lacks any deeper introspection into why the situation is as they describe it to be. This is relevant as two proposers are Cardano founding entities.

I voted NO for this proposal on Ekklesia and I will vote NO again. The proposal is welcome, as all proposals are. I think that the proposers have failed to identify the reasons why the Cardano ecosystem "currently faces challenges in establishing a consistent and impactful presence at global blockchain events."
Two out of the three vendors: Emurgo and Cardano Foundation have been in roles that were supposed to contribute significantly to Cardano's profile at such events.
As the proposal states that "Competitors like Solana, Aptos, and Sui have established significant brand recognition by strategically aligning global events with developer-focused initiatives." - it would seem that their founding entities may have had better strategies towards this type of goals.
I think that IOG has had an outsized influence on the Cardano global image and marketing presence in general and that entrusting the CF and Emurgo with more funds to establish a consistent and impactful presence at global blockchain events - might be a mistake.
I sort of expected a much deeper analysis of why "competitors like Solana, Aptos, and Sui have established significant brand recognition". This seems like a superficial approach to a much deeper problem that is Cardano's brand image.
I am careful not to lump Rare Evo into this assessment.
I come to this proposal wondering what has prevented the founding entities from working on a unified global events marketing strategy for Cardano so far. It is 2025.
The issue is I was not convinced that this proposal will make a difference - as two of the three entities have essentially not built up the credibility that they can make this work - truly. Yes, I believe the events will be held, the boxes will be ticked, and the speeches will be held and that we will rub shoulders with Solana, Aptos, and Sui at these events - but I do not see the "Je ne sais quoi" factor that this will make a difference and that the main proposers are able to self-critically look at their own roles so far.

I voted NO for this proposal on Ekklesia and I have decided to vote NO again. This is a sizeable request from the treasury so it does require due consideration. The withdrawal amount is for ₳4,000,000.
This is a proposal submitted by Anzens which is the main legal entity behind Cardano-native stablecoin USDA - in my understanding. Might be wrong about the relationship between the two, if so, mea culpa.

The proposal does claim the following:
"Despite Cardano's $700M+ DeFi ecosystem, its native assets---including stablecoins---are severely underrepresented on centralized exchanges (CEXs) and OTC desks."
Alas, the proposal does not explain why are they severely underrepresented. There must be a reason - and I do not think that the ₳4,000,000 requested is the sole reason.
Maybe wrongly, I presume that some of the founding entities may have had as part of its original mandate to help with the integration of Cardano native assets on centralized exchanges (CEXs) and OTC desks. Maybe not.
As far as I am aware some of the founding entities still do have some genesis ADA that was probably allocated partly towards purposes such as this one.
Hence, without a deeper analysis of the reasons behind the "severe underrepresention on centralized exchanges (CEXs) and OTC desks" - Was it resistance on the part of the CEXs? Was it a lack of will on the part of the founding entities? Was it a lack of capacity? Was it technical complexity? Was it low consumer demand? I feel that we should not plough ₳4,000,000 into a problem whose origins and true causes we do not understand properly.
Do we have any open source products coming out of this proposal? Treasury only funds should favor public‑good pieces (custodian/native‑asset integrations, open APIs, SDKs, whatever).
Finally, we do have several fiat-based commercial stablecoins in the Cardano system. I would prefer to see joint proposals that benefit all of them in as wide a scope as possible - while maximizing the value for public
Strategic problem - but narrow proposal. We do need liquidity, ramps, institutional custody for native assets - I was not convinced that Anzens with treasury funding can address issues that Emurgo, Cardano Foundation and IOG were together unable to resolve so far.
This package seems oversized, overoptimistic, under‑evidenced, and mixes “business expansion” with public‑good claims.

Seems I forgot to attach my rationale the previous time I voted. So, let me try to sum it up off the top of my head. I voted NO in Ekklesia on the. ₳583,000 for Eternl Maintenance.
I am a heavy Eternl user and have been a user since it was CC Vault, so I am biased towards the wallet. I have started moving towards open source wallets... as I think that it is time to practice what I preach.
Furthermore, there is a lot of competition in the Cardano wallet space and the Treasury should not be picking winners and losers - by funding a subset of wallets. But if will be used to fund their maintenance, I want them open source.
The proposal states:"Reliable access to the Cardano blockchain requires trustworthy wallet solutions." Open source wallet solutions are more trustworthy.
Eternl has benefited previously from Catalyst funding, which is good. I voted to fund Eternl in Catalyst: ( https://x.com/InputEndorsers/status/1699858107130683723 ) in Fund 10.
Eternl stated in 2021 that it would open source: "Yes, we will open source the code in Q4 while we rebrand the wallet." ( https://x.com/eternlwallet/status/1436754831293784068 ). I asked the team about this intention recently but received no answer ( https://x.com/InputEndorsers/status/1947434903764894194 )
I also applaud Eternl for integrating MonsterSwap with the choice of multiple aggregators. However, my vote is NO.

I voted NO on this proposal in Ekklesia, but thanks to Intersect's decision to unbundle the single treasury withdrawal action into multiple ones, I have been able to reconsider some of my original votes. However, my vote for this proposal remains a NO.
I wanted to see a lower budget or a lower scope for the Cardano Summit proposal.
I will quote from the proposal: "The Cardano Summit is not optional". I tend to agree with this. Let me add, I have never attended a Cardano Summit live (only virtually) - so I am also speaking from an outsider's point of view.
What I disagree is the bundling of the Cardano Summit with the 4 x Regional Cardano Tech Events into one take-it-or-leave-it proposal. Forced with the choice, I leave it. My hope is that a pure Cardano Summit proposal will be put forward.
Also, the proposal does state the strenghts of its co-hosts. One of the arugments is: "The Cardano Foundation's proven delivery of three consecutive, globally impactful Cardano Summits". The PDF adds that IOG financed it in 2021. I see Emurgo has not financed a Cardano Summit - although it has participated as a sponsor previously. Not criticising, just reiterating the facts.
The proposal does not explain why The Cardano Foundation - as one of the major backers - is modifying the previous model of funding the Cardano Summit by itself (2022, 2023, 2024) into a new model where the Summit is being financed from the treasury. Without the explanation - I can only presume that the reason is that this is no longer seen as a sole financial responsibility of the Cardano Foundation.
When was this decision made? Why is it not a responsibility of the CF - we are left to guess. It seems it is the Treasury's baby now. Well, as a DRep - I would like a Cardano Summit proposal pure and simple. My feeedback is that is too expensive and ambitious - for one the Summit proposal should be separated from the 4 Regional Events and I would reconsider my vote.
I commend the proposers for exploring how to create a path towards a revenue-based Cardano Summit in the future - by 2029, according to projections.

I voted ABSTAIN on this proposal in Ekklesia, but thanks to Intersect's decision to unbundle the single treasury withdrawal action into multiple ones, I have had some more room to reconsider some of my original decisions.
I want to be frank (and I may make a mistake) - the fact that ENCOINS V1 was not a successful product at the level that I expected it could be - was a factor that did influence my original NO vote. If I am correct Eryx are active contributors to the ENCOINS protocol, currently deployed on the Cardano mainnet
The perceived low usability of the ENCOINS V1 product did influence my decision towards this proposal (for what its worth) during the Ekklesia vote - as it just did not bode well for me. Yes, these are completely different initiatives - but I was not able to ignore information that I had.
In the meantime, several things have changed. I have early tested ENCOINS V2 on PreProd and found it to be much much more intuitive and straightforward to use. I essentially do support the effort to building a ZK bridge for Cardano.
I think there is room for a change of my vote to a YES.

I voted ABSTAIN on Ekklesia for this proposal - when I was an Intersect member. I was originally going between a NO and an ABSTAIN - but was leaning NO.
I think that those who voted YES in the early stages - months ago - may have made somewhat of a mistake as Intersect has been greatly shaped into a leaner and meaner machine by pushback, not by support. Fortunately, there were sufficient NOs and ABSTAINS to create enough pusback.
IIn the meantime my Intersect inddividual membership has expired (have yet to renew it), but I am voting YES as a non-Intersect member at the moment. I have changed my vote to a YES for the new ₳15,75M treasury withdrawal, because a lot of proposals are now dependent on the presence of a rational and functional administrator.
Other reasons for the change:

1. Jack Briggs and his communication skills and responsive style - yep, it matters
2. Intersect cut the treasury withdrawal request from the massive 20M ADA
3. The new Intersect leadership avoided the massive - and almost irresistible - temptation of bundling all the proposals in 1 or 2 Treasury Withdrawals, finding a convenient excuse to do so, and steamrolling ahead. They demonstrated respect and trust in a large segment of the community. This create more space for some of us to expand our list of proposals we can support.
4. I want to reciprocate with my own leap of faith, by supporting a key cog in the system - the new community minded Intersect. In this space, all we have the power to do is really to make a decision when and if to trust someone. The pieces are now there for Intersect to continue as a new servant, not master.

I voted ABSTAIN on Ekklesia. I ABSTAIN again. I try my best to keep myself in check (objective) as much as I can - of course, this is limited by my biases. I like that project Catalyst has funded many of the successful Cardano teams and projects. It has given a chance to many outsiders to launch their businesses.

Specifically in this case I have served as a Project Catalyst community reviewer too long (since Catalyst Fund 2) and a milestone reviewer (since Catalyst Fund 10). I have been paid for these roles thousands of ADA overall.

When Intersect included the budgetary proposal for Project Catalyst in its voting tool Ekklesia, I abstained from voting - due to conflict of interest. Project Catalyst has funded some of our best teams, yet - I do not want to use that as an excuse to vote YES, as my remuneration from Catalyst may be clouding my judgement.

I do not want to be a tipping vote in favor of my own compensation. Why? Is this showboating? Vanity? Well, my reasoning is that - I have no platform as a DRep to call out conflicts of interest in other parts of the ecosystem - if I do not actively try to curb my own conflicts of interest.

I try to keep myself in check, because I don't want to be forced to keep my mouth shut if I see detrimental behavior elsewhere.

Apologies to Catalyst Team, however, I cannot be a DRep properly if I can't hold myself in check.

I voted NO to the Beyond Minimum Viable Governance: Iteratively Improving on Cardano Voltaire proposal on Ekklesia. I repeat my NO vote here.
I generally am in favor of initiatives that aim to improve Cardano's governance system. So, my default position coming to a proposal like this is to be interested in it such proposals. I am a DRep so obviously, I would be partial to it.
The proposed outcome here is a 'State of Governance' report that will be produced by engaging the Cardano community through various channels.
I think that a proposal of this type - because it is being proposed by one of the founding entities - runs a risk of being less objective. Admittedly, I would be more worried if IOG was directly participating in governance as a DRep or a CC member.
I agree with the proposed statement that to "truly evolve beyond Minimum Viable Governance (MVG) and unlock Cardano's full potential, we must establish a robust, data-driven foundation for continuous improvement."
What I think is missing in this proposal is outside views. The proposal to me reads like to much of a Cardano-centric approach to MVG and its criticisms. I think that most of the players involved behind this proposal are too close to the process to be as neutral as outsiders can be.
Essentially, I would have liked to see more Cardano-unaffiliated governance researchers and experts involved with this proposal.
I would even start with presuppositions such as "This initiative ... ensuring Cardano remains a leader in decentralized decision-making.". I think that the Beyond Minimum Viable Governance proposal should be objective enough to determine whether Cardano's MVG is a leader and in which segments of decentralized decision-making, while also finding out where - if anywhere - it trails behind others. Starting with presuppositions that it is a leader, sort of stacks the decks of cards towards an outcome that will mean we are slapping ourselves on the back.
To use IOG own example from developing Leios, IOG recently decided to part ways with Well Typed on the upcoming work on Leios. There are good arguments for changing vendors, and I think that shaking up things from time to time may be good.
In this case, after MVG has been delivered, I would have prefered to read a proposal that shakes things up a bit. This proposal offers that the "project will be driven by a robust coalition of experienced stakeholders dedicated to the advancement of Cardano's governance. nput Output's Voltaire team will provide core leadership, leveraging their unique role as the architects of Cardano's governance framework. As the team responsible for implementing key governance mechanisms---including the Cardano Constitution, the DRep liquid democracy model, and various on-chain and off-chain tools---we possess strong insight into their performance and optimization potential.".
I am afraid that the team will not be able to be objective enough without strong outside experts to realistically assess any failures or shortcomings in the current governance system.
Yes, there will be other players: Constitutional Delegate Committee Members (already participated in creating/approving MVG), Partner organizations (also already involved in determining MVG) and Active community members (still no outside - indepedent - non-Cardano participation).
As I want more outside expertise and more critical thinking from outside the Cardano governance bubble, I vote NO again. However, I would vote YES for a resubmitted proposal by this team - if it were to include a much more significant non-Cardano outside governance expertise and voices. Probably, even if it was sligthly more expensive.

I originally voted NO for this proposal in the Ekklesia temp poll check because I presumed it would remain closed source. Now I am voting YES.

The reasons for my change in voting intention:

a. ADAStat this is one of the essential tools that we now use in the governance era of Cardano. Yet, its closed nature was off-putting to me. I do not want governance and its tools to be a locked garden.
b. I asked ADAStat over X (Twitter) whether they would open source the code:
https://x.com/InputEndorsers/status/1947431858968666491

ADASTat team responded:
Hi, thanks for your interest! AdaStat will be open-sourced in the very near future, regardless of the outcome of the budget vote. Right now, we’re cleaning up the code, updating dependencies, and making other improvements to minimize the risk of vulnerabilities due to outdated components. Once that's done, the entire codebase - both front end and back end - will be published on GitHub.

https://x.com/ada_stat/status/1947559172473528735

c. with the public commitment to open source the platform, I will change my vote - in order to prevent further delays. However, I do this under the assumption that this commitment will be respected by ADAStat

NOTE: In general, I have now come to a position where I think that this might not be the best way forward for maintenance and enhancement proposals of open source tools. Meaning that direct funding of smaller open source maintenance and enhancement proposals from the treasury might not be the best approach going forward.

if this were to be resubmitted in 2026, I would consider this carefully. Why? I am more in favor of seeing proposals like this funded through an initiative such as the OSC Budget Proposal - Paid Open Source Model for Sustainable Development. I voted YES for the OSC Budget Proposal - Paid Open Source Model for Sustainable Development.
Such budgetary initiatives do not have to come from the OSC, it could be another umbrella group of open source advocates / body that will prioritize and correctly value certain critical packages of maintenance and enhancement work on open source tools that are important for the Cardano ecosystem.
This group or groups would ideally rank the importance / relevance of these open-source tools and software kits or platforms, as well as realistically estimate how much maintenance / enhancement is needed and when it is critical.
Multiple tiny contracts approved by the treasury complicate oversight, whereas larger open-source infrastructure umbrella programs can rank repos by impact and rotate funding annually. The more exceptions the Treasury grants, the harder it becomes to enforce future budget discipline.
I imagine the maintenance and improvement of open source tools or platforms as something that could be tentatively grouped. Of course, these larger maintenance and enhancement support groups (like the OSC) for open source tooling could start discriminating against certain tools. In those cases, if a proposer is dissatisfied with the ranking or grouping, they could always directly apply to the Treasury with a rationale why the proposal needs funding and why it cannot obtain it elsewhere - but only directly from the Treasury.

I voted NO on this proposal in Ekklesia, but thanks to Intersect's decision to unbundle the treasury withdrawal action, I have had some more room to reconsider some of my original decisions.
I want to be frank (and I may make a mistake) - the fact that ENCOINS V1 was not a successful product at the level that I expected it could be - was a factor that did influence my original NO vote. If I am correct ZKFold and ENCOINS projects do trace back to some of the same people.
I admit the perceived low usability of the ENCOINS V1 product did influence my decision negatively towards this proposal (for what its worth) - as it just did not bode well for me. Yes, these are completely different initiatives - but I was not able to ignore information that I had.
In the meantime, several things have changed. I have early tested ENCOINS V2 on PreProd and found it to be much much more intuitive and straightforward to use.
I esssentially do support the effort to introduce more scalability through ZK rollups. An additional pathway to greater scalability is welcome. We need options.
Also, Intersect decided not to submit a Mega Treasury Withdrawal action, allowing me to revisit some of my earlier "No votes".
Finally, I am human, so my decisions will be influenced by environmental cues. I recently listened to a NerdOut space with Rul from FluiDTokens speaking about the work to connect BTC and Cardano. There was a mention of the work being done with ZKFold team on a ZK aspect of this. I think there is room for a change of my vote to a YES.

I originally voted NO for this proposal in the Ekklesia temp poll check. I am voting NO again.
The team does seem uniquely qualified to deliver this project. However, it seems to be based on several suppositions that have not convinced me sufficiently to risk treasury funds on this proposal. I do commend them for putting it forward to a vote.

These ideas seem worth experimenting with. Anyhow, the ask is too large for the current moment in Cardano imho and the zero‑operational‑costs claim opens more questions to me. I feel this to be more of a risk for the treasury. As a very different alternative to Catalyst that is based on several presumptions (such as willing donations) - would probably benefit from starting with a smaller pilot. Maybe financed through Catalyst itself. This pilot would be best gated by hard KPIs (donor‑matching ratio, active‑user growth, impact‑reporting dashboard) before scaling to seven figures.

I originally voted NO for this proposal in the Ekklesia temp poll check. Now I am voting YES.

The fact that Intersect pushed forward 39 individual treasury withdrawal actions, allows me to be more flexible with my planned votes - as I no longer feel an obligation to voice my displeasure and fight against the mega-bundling of proposals into one or two mega treasury withdrawals.

In Ekklesia, I was trying to keep my votes down to mostly essentials - however, with this discrete voting mechanism, I choose to add this proposal to my YES list.

Cardano needs flexible on‑chain cryptography if we want native bridges, privacy tokens, or recursive proofs without waiting for every curve to become a built‑in. MLabs are the right team and the budget is fair.

I voted YES for this proposal in the Ekklesia temperature check. I think is one of the essential proposals from the point of view of an end user who uses a cold wallet to secure his or her Cardano / ADA funds. What I would like to see in the future is more competition from competent teams that wish to do further cold wallet integrations and improvements of end user experience. The success of Cardano will be made through a smooth and painless user experience. This proposal aims to deliver a better end user interface for the end holder. Currently, Cardano is the only Ledger application with non-standard UI - and it requires double-clicks during the confirmation process.

I voted YES for this proposal in the Ekklesia temperature check. I think is one of the essential proposals from the point of view of an end user who uses a cold wallet to secure his or her Cardano / ADA funds. What I would like to see in the future is more competition from competent teams that wish to do further cold wallet integrations and improvements of end user experience with different and novel ADA and native token storage methods.

I voted YES for this proposal in the Ekklesia temperature check. I have now come to a position where I think that this might not be the best way forward. Meaning that direct funding of smaller open source maintenance and enhancement proposals directly from the treasury might not be the best approach going forward.
As I have already indicated my support for this proposal in Ekklesia, I will not overcomplicate matters by changing my vote at this - the final treasury withdrawal stage. So my original vote indication remains in place and I vote YES. Note: if this were to be resubmitted in 2026, I would consider this carefully.
Why? I am more in favor of seeing proposals like this funded through an initiative such as the OSC Budget Proposal - Paid Open Source Model for Sustainable Development. I voted YES for the OSC Budget Proposal - Paid Open Source Model for Sustainable Development.
Such budgetary initiatives do not have to come from the OSC, it could be another umbrella group of open source advocates / body that will prioritize and correctly value certain critical packages of maintenance and enhancement work on open source tools that are important for the Cardano ecosystem.
This group or groups would ideally rank the importance / relevance of these open-source tools and software kits or platforms, as well as realistically estimate how much maintenance / enhancement is needed and when it is critical.
Multiple tiny contracts approved by the treasury complicate oversight, whereas larger open-source infrastructure umbrella programs can rank repos by impact and rotate funding annually. The more exceptions the Treasury grants, the harder it becomes to enforce future budget discipline.
I imagine the maintenance and improvement of open source tools or platforms as something that could be tentatively grouped. Of course, these larger maintenance and enhancement support groups (like the OSC) for open source tooling could start discriminating against certain tools. In those cases, if a proposer is dissatisfied with the ranking or grouping, they could always directly apply to the Treasury with a rationale why the proposal needs funding and why it cannot obtain it elsewhere - but only directly from the Treasury.
Note: some other similar open source maintenance and enhancement proposals might differ in their perceived importance - and my vote indication in Ekklesia. I am currently considering to mostly mirror my voting indications from Ekklesia - in order to not overcomplicate the process. Exceptions will be indicated.

I voted YES for this proposal in the Ekklesia temperature check. I have now come to a position where I think that this might not be the best way forward. Meaning that direct funding of smaller open source maintenance and enhancement proposals from the treasury might not be the best approach going forward.
As I have already indicated my support for this proposal in Ekklesia, I will not overcomplicate matters by changing my vote at this - the final treasury withdrawal stage. So my original vote indication remains in place and I vote YES. Note: if this were to be resubmitted in 2026, I would consider this carefully.
Why? I am more in favor of seeing proposals like this funded through an initiative such as the OSC Budget Proposal - Paid Open Source Model for Sustainable Development. I voted YES for the OSC Budget Proposal - Paid Open Source Model for Sustainable Development.
Such budgetary initiatives do not have to come from the OSC, it could be another umbrella group of open source advocates / body that will prioritize and correctly value certain critical packages of maintenance and enhancement work on open source tools that are important for the Cardano ecosystem.
This group or groups would ideally rank the importance / relevance of these open-source tools and software kits or platforms, as well as realistically estimate how much maintenance / enhancement is needed and when it is critical.
Multiple tiny contracts approved by the treasury complicate oversight, whereas larger open-source infrastructure umbrella programs can rank repos by impact and rotate funding annually. The more exceptions the Treasury grants, the harder it becomes to enforce future budget discipline.
I imagine the maintenance and improvement of open source tools or platforms as something that could be tentatively grouped. Of course, these larger maintenance and enhancement support groups (like the OSC) for open source tooling could start discriminating against certain tools. In those cases, if a proposer is dissatisfied with the ranking or grouping, they could always directly apply to the Treasury with a rationale why the proposal needs funding and why it cannot obtain it elsewhere - but only directly from the Treasury.
Note: some other similar open source maintenance and enhancement proposals might differ in their perceived importance - and my vote indication in Ekklesia. I am currently considering to mostly mirror my voting indications from Ekklesia - in order to not overcomplicate the process. Exceptions will be indicated.

I voted YES for this proposal in the Ekklesia temperature check. I have now come to a position where I think that this might not be the best way forward. Meaning that direct funding of smaller open source maintenance and enhancement proposals from the treasury might not be the best approach going forward.
As I have already indicated my support for this proposal in Ekklesia, I will not overcomplicate matters by changing my vote at this - the final treasury withdrawal stage. So my original vote indication remains in place and I vote YES. Note: if this were to be resubmitted in 2026, I would consider this carefully.
Why? I am more in favor of seeing proposals like this funded through an initiative such as the OSC Budget Proposal - Paid Open Source Model for Sustainable Development. I voted YES for the OSC Budget Proposal - Paid Open Source Model for Sustainable Development.
Such budgetary initiatives do not have to come from the OSC, it could be another umbrella group of open source advocates / body that will prioritize and correctly value certain critical packages of maintenance and enhancement work on open source tools that are important for the Cardano ecosystem.
This group or groups would ideally rank the importance / relevance of these open-source tools and software kits or platforms, as well as realistically estimate how much maintenance / enhancement is needed and when it is critical.
Multiple tiny contracts approved by the treasury complicate oversight, whereas larger open-source infrastructure umbrella programs can rank repos by impact and rotate funding annually. The more exceptions the Treasury grants, the harder it becomes to enforce future budget discipline.
I imagine the maintenance and improvement of open source tools or platforms as something that could be tentatively grouped. Of course, these larger maintenance and enhancement support groups (like the OSC) for open source tooling could start discriminating against certain tools. In those cases, if a proposer is dissatisfied with the ranking or grouping, they could always directly apply to the Treasury with a rationale why the proposal needs funding and why it cannot obtain it elsewhere - but only directly from the Treasury.
Note: some other similar open source maintenance and enhancement proposals might differ in their perceived importance - and my vote indication in Ekklesia. I am currently considering to mostly mirror my voting indications from Ekklesia - in order to not overcomplicate the process. Exceptions will be indicated.

I voted YES for this proposal in the Ekklesia temperature check. I have now come to a position where I think that this might not be the best way forward. Meaning that direct funding of smaller open source maintenance and enhancement proposals from the treasury might not be the best approach going forward.
As I have already indicated my support for this proposal in Ekklesia, I will not overcomplicate matters by changing my vote at this - the final treasury withdrawal stage. So my original vote indication remains in place and I vote YES. Note: if this were to be resubmitted in 2026, I would consider this carefully.
Why? I am more in favor of seeing proposals like this funded through an initiative such as the OSC Budget Proposal - Paid Open Source Model for Sustainable Development. I voted YES for the OSC Budget Proposal - Paid Open Source Model for Sustainable Development.
Such budgetary initiatives do not have to come from the OSC, it could be another umbrella group of open source advocates / body that will prioritize and correctly value certain critical packages of maintenance and enhancement work on open source tools that are important for the Cardano ecosystem.
This group or groups would ideally rank the importance / relevance of these open-source tools and software kits or platforms, as well as realistically estimate how much maintenance / enhancement is needed and when it is critical.
Multiple tiny contracts approved by the treasury complicate oversight, whereas larger open-source infrastructure umbrella programs can rank repos by impact and rotate funding annually. The more exceptions the Treasury grants, the harder it becomes to enforce future budget discipline.
I imagine the maintenance and improvement of open source tools or platforms as something that could be tentatively grouped. Of course, these larger maintenance and enhancement support groups (like the OSC) for open source tooling could start discriminating against certain tools. In those cases, if a proposer is dissatisfied with the ranking or grouping, they could always directly apply to the Treasury with a rationale why the proposal needs funding and why it cannot obtain it elsewhere - but only directly from the Treasury.
Note: some other similar open source maintenance and enhancement proposals might differ in their perceived importance - and my vote indication in Ekklesia. I am currently considering to mostly mirror my voting indications from Ekklesia - in order to not overcomplicate the process. Exceptions will be indicated.

I voted YES for this proposal in the Ekklesia temperature check. I have now come to a position where I think that this might not be the best way forward. Meaning that direct funding of smaller open source maintenance and enhancement proposals from the treasury might not be the best approach going forward.

As I have already indicated my support for this proposal in Ekklesia, I will not overcomplicate matters by changing my vote at this - the final treasury withdrawal stage. So my original vote indication remains in place and I vote YES. Note: if this were to be resubmitted in 2026, I would consider this carefully.

Why? I am more in favor of seeing proposals like this funded through an initiative such as the OSC Budget Proposal - Paid Open Source Model for Sustainable Development. I voted YES for the OSC Budget Proposal - Paid Open Source Model for Sustainable Development.

Such budgetary initiatives do not have to come from the OSC, it could be another umbrella group of open source advocates / body that will prioritize and correctly value certain critical packages of maintenance and enhancement work on open source tools that are important for the Cardano ecosystem.
This group or groups would ideally rank the importance / relevance of these open-source tools and software kits, as well as realistically estimate how much maintenance / enhancement is needed and when it is critical.
Multiple tiny contracts approved by the treasury complicate oversight, whereas larger open-source infrastructure umbrella programs can rank repos by impact and rotate funding annually. The more exceptions the Treasury grants, the harder it becomes to enforce future budget discipline.
I imagine the maintenance and improvement of open source tools as something that could be tentatively grouped. Of course, these larger maintenance and enhancement support groups (like the OSC) for open source tooling could start discriminating against certain tools. In those cases, if a proposer is dissatisfied with the ranking or grouping, they could always directly apply to the Treasury with a rationale why the proposal needs funding and why it cannot obtain it elsewhere - but only directly from the Treasury.
Note: some other similar open source maintenance and enhancement proposals might differ in their perceived importance - and my vote indication in Ekklesia. I am currently considering to mostly mirror my voting indications from Ekklesia - in order to not overcomplicate the process. Exceptions will be indicated.

I voted YES for this proposal in the Ekklesia temperature check. I have now come to a position where I think that this might not be the best way forward. Meaning that direct funding of smaller open source tools maintenance and enhancement proposals from the treasury might not be the best approach going forward.
As I have already indicated my support for this proposal in Ekklesia, I will not overcomplicate matters by changing my vote at this - the final treasury withdrawal stage. So my original vote indication remains in place and I vote YES. Note: if this were to be resubmitted in 2026, I would consider this carefully.
Why? I am more in favor of seeing proposals like this funded through an initiative such as the OSC Budget Proposal - Paid Open Source Model for Sustainable Development. I voted YES for the OSC Budget Proposal - Paid Open Source Model for Sustainable Development.
Such budgetary initiatives do not have to come from the OSC, it could be another umbrella group of open source advocates / body that will prioritize and correctly value certain critical packages of maintenance and enhancement work on open source tools that are important for the Cardano ecosystem.
This group or groups would ideally rank the importance / relevance of these open-source tools and software kits, as well as realistically estimate how much maintenance / enhancement is needed and when it is critical.
Multiple tiny contracts approved by the treasury complicate oversight, whereas larger open-source infrastructure umbrella programs can rank repos by impact and rotate funding annually. The more exceptions the Treasury grants, the harder it becomes to enforce future budget discipline.
I imagine the maintenance and improvement of open source tools as something that could be tentatively grouped. Of course, these larger maintenance and enhancement support groups (like the OSC) for open source tooling could start discriminating against certain tools. In those cases, if a proposer is dissatisfied with the ranking or grouping, they could always directly apply to the Treasury with a rationale why the proposal needs funding and why it cannot obtain it elsewhere - but only directly from the Treasury.
Note: some other similar open source maintenance and enhancement proposals might differ in their perceived importance - and my vote indication in Ekklesia. I am currently considering to mostly mirror my voting indications from Ekklesia - in order to not overcomplicate the process. Exceptions will be indicated.

I voted YES for this proposal in the Ekklesia temperature check. I have now come to a position where I think that this might not be the best way forward. Meaning that direct funding of smaller open source tools maintenance and enhancement proposals from the treasury might not be the best approach going forward.

As I have already indicated my support for this proposal in Ekklesia, I will not overcomplicate matters by changing my vote at this - the final treasury withdrawal stage. So my original vote indication remains in place and I vote YES. Note: if this were to be resubmitted in 2026, I would consider this carefully.

Why? I am more in favor of seeing proposals like this funded through an initiative such as the OSC Budget Proposal - Paid Open Source Model for Sustainable Development. I voted YES for the OSC Budget Proposal - Paid Open Source Model for Sustainable Development.

Such budgetary initiatives do not have to come from the OSC, it could be another umbrella group of open source advocates / body that will prioritize and correctly value certain critical packages of maintenance and enhancement work on open source tools that are important for the Cardano ecosystem.

This group or groups would ideally rank the importance / relevance of these open-source tools and software kits, as well as realistically estimate how much maintenance / enhancement is needed and when it is critical.

Multiple tiny contracts (this is a relatively tiny ask) approved by the treasury complicate oversight, whereas larger open-source infrastructure umbrella programs can rank repos by impact and rotate funding annually. The more exceptions the Treasury grants, the harder it becomes to enforce future budget discipline.

I imagine the maintenance and improvement of open source tools as something that could be tentatively grouped. Of course, these larger maintenance and enhancement support groups (like the OSC) for open source tooling could start discriminating against certain tools. In those cases, if a proposer such as MLabs is unsatisfied with the ranking or grouping, they could always directly apply to the Treasury with a rationale why the proposal needs funding and why it cannot obtain it elsewhere - but only directly from the Treasury.

Note: some other similar open source maintenance and enhancement proposals might differ in their perceived importance - and my vote indication in Ekklesia. I am currently considering to mostly mirror my voting indications from Ekklesia - in order to not overcomplicate the process. Exceptions will be indicated.

I will keep the rationale brief for expediency - as 38 proposals were submitted concurrently by Intersect today. I voted YES for this proposal in the previous Ekklesia temp check and will vote YES now again.

This proposal wants financing for a Typescript node implementation. The team is aiming for a a fully functional light node that can run in the browser and can be integrated in dApps and wallets. I decided that the diversity of approaches to Cardano node development merits support as it is in line with our aim of fostering decentralization. Harmonic Labs is known for its dedication to Cardano ethos and tackling hard problems in our space.

I will keep the rationale brief for expediency - as 38 proposals were submitted concurrently by Intersect today. I voted YES for this proposal in the previous Ekklesia temp check and will vote YES now again.

This proposal wants financing for Scalus a Cardano DApps development platform. The budget breakdown seems internally coherent. I admit to having doubts whether to go for a new platform like Scalus. I decided that the diversity of approaches to DApp development merits support.

I will keep the rationale brief for expediency - as 38 proposals were submitted concurrently by Intersect today. I voted YES for this proposal in the previous Ekklesia temp check and will vote YES now again.

This proposal helps bridge two probably important goals. Ensuring a decentralized approach to developing Cardano further, while also maintaining core competency and experienced oversight through the Cardano Product Committee. As they say themselves, we need an "open, shared, and transparent process for the Cardano community to define a long-term vision and a roadmap". Thumbs up.

I will keep the rationale brief for expediency - as 38 proposals were submitted concurrently by Intersect today. I voted YES for this proposal in the previous Ekklesia temp check and will vote YES now again.

To be frank, I am not an SPO (if we do not count my hobby - failed attempt to set up a Jörmungandr node to play around with it during the ITN stage.

But, tbh I was a bit wary of voting for another IOG proposal apart from the ones that I already supported. I have to admit, that IOG fest was not one of my approaches to this budget process. Trying to stay as objective as I can.

So, I delegated a lot of my thinking on this proposal to my SPO. My SPO is TECH pool run by Bjarne (he is a fab SPO). The feedback I received was that Blockfrost has shown to deliver in the past and they are always available for support in their discord server. Plus the added value is that they willing to decentralize their apis and source code, showing their care for "the core cardano ethos, decentralization 😎" Thanks Bjarne - enjoy your nice holiday. Ooops, was I supposed to share that?

I will keep the rationale brief for expediency - as 38 proposals were submitted concurrently by Intersect today. I voted YES for this proposal in the previous Ekklesia temp check and will vote YES now again.
This might be a good approach to finding a way to fund long-term sustainability of open-source development in the Cardano ecosystem. Pretty important and gets my support. I hope it yields to positive results and avoids any gridlock during implementation, while setting a positive example how to support common infrastructure that is significant for all of us.

I will keep the rationale brief for expediency - as 38 proposals were submitted concurrently by Intersect today. I voted YES for this proposal in the previous Ekklesia temp check and will vote YES now again.
The IOG proposal is a continuation of work on a several seemingly critical pieces of research for Cardano - as well as some new research. The team has delivered Cardano's unique architecture and vision. It is an omnibus proposal - I think some of these bundled research items seem clearly more important than others. Their timelines might be a bit questionable, and as all research, some will fizzle out. However, some research might lead to new strands of knowledge and Cardano - as a science-based blockchain - cannot stay static in an ever-shifting environment. This proposal also probably serves as a good example for other ambitious teams that may see this proposal as inspiration to deliver competing omnibus research proposals and competing research agendas for Cardano's future in 2026. Like IOG is doing here.

I will keep the rationale brief for expediency - as 38 proposals were submitted concurrently by Intersect today. The IOG proposal is a continuation of work on a several seemingly critical pieces of infrastructure and research for Cardano. The team has delivered Cardano's unique architecture and vision. It is an omnibus proposal and probably serves as a good example for other ambitious and competent teams that may see this proposal as inspiration to deliver competing omnibus proposals and competing visions for Cardano's future in 2026. Not just technical pieces of a disjointed jigsaw puzzle, but also a rival masterplan of sorts - like IOG is doing here in 2025.

I have voted YES for this proposal in the Ekklesia temperature check and confirm that vote here.

I will keep the rationale brief for expediency - as 38 proposals were submitted concurrently by Intersect today.

Midgard should allow the building of true L2 rollups that inherit full security from Cardano. The proposing team has contributed massively to Cardano so far. This is an important proposal to improve one of the current bottlenecks of Cardano. Direct funding from the treasury seems appropriate for a proposal of this format.

I read the MLabs Core Tool Maintenance & Enhancement: Cardano.nix and it did not convince me that the direct funding from the Treasury is necessary at this moment nor that Catalyst Fund 14 would not be a better avenue. If approved, Catalyst Fund 14 should launch with ₳20 M budget. I judge that Cardano.nix can tolerate that delay, while admitting that the funds would be disbursed only later this year - if the proposal is funded by Catalyst.

Catalyst aside, I have assessed the importance of this proposal through my individual understanding of the current environment and the text of the proposal. This is a personal assessment and it might be wrong. However, I will try to explain my reasoning.

Note: some other similar open source maintenance and enhancement proposals might differ in their perceived importance - and in those cases I may make exceptions in the first year of on-chain governance. I am still developing my personal approach.

For this proposal, I was not convinced I should set it as an exception. I am more in favor of seeing proposals like this funded through an initiative such as the OSC Budget Proposal - Paid Open Source Model for Sustainable Development. It doesn't have to be the OSC, it could be another umbrella group of open source advocates / body that will prioritize and correctly value certain critical packages of maintenance and enhancement work on open source tools that are important for the Cardano ecosystem.

This group or groups would ideally rank the importance / relevance of these open-source tools and software kits, as well as realistically estimate how much maintenance / enhancement is needed and when it is critical.

Multiple tiny contracts (this is a relatively tiny ask) approved by the treasury complicate oversight, whereas larger open-source infrastructure umbrella programs can rank repos by impact and rotate funding annually. The more exceptions the Treasury grants, the harder it becomes to enforce future budget discipline.

I imagine the maintenance and improvement of open source tools as something that could be tentatively grouped. Of course, these larger maintenance and enhancement support groups (like the OSC) for open source tooling could start discriminating against certain tools. In those cases, if a proposer such as MLabs is unsatisfied with the ranking or grouping, they could always directly apply to the Treasury with a rationale why the proposal needs funding and why it cannot obtain it elsewhere - but only directly from the Treasury.

So some granularity at the open source program‑level (with an annual ranking) might be interesting, so individual repos needn’t come to governance each time. We might not need on-chain governance to micromanage every repo.

So, in this case I maintain my original intention to vote YES for the OSC Budget Proposal - Paid Open Source Model for Sustainable Development when it comes to a vote - and I maintain my original intention to vote NO for the "Withdraw ₳45,217 for MLabs Core Tool Maintenance & Enhancement: Cardano.nix".
Yes, I want granularity in decision-making, but some kind of over-arching approach to funding maintenance and enhancment of open-source infrastructure tools might be needed. There may be exceptions to this approach - if I encounter some proposals that I deem to be more urgent in Year 1. Note: as a DRep, I am still developing my approach to this issue - and some of my votes might be in conflict as time passes. This is part of "learning on the job".

If I am at a lower level of certainty whether a direct withdrawal from the treasury is necessary right now, I will tend to vote No as this is being financed by the Cardano Treasury. My objection is about process efficiency for this type of proposals and prioritisation, not about spending less. If the OSC budget fails, I would reassess stand‑alone asks like this one based on proven urgency.

English version. The Japanese translation is below the English version.
英語版。日本語訳は英語版の下にあります。
Let me prefact this vote with this comment: I like what Tempo.vote contributed to Cardano governance. They provided an alternative way of voting for DReps and were very proactive in improving their platform. I regularly pinged them with problems over their Telegram group and they would respond usually in 24 hours max and fix the issue. I have a profile on Tempo.vote - so I am appreciative of what they have contributed. I am even going to submit this vote over Tempo.vote.
Now that they built the product, they should probably consider the big picture future for Tempo. I was leaning to vote YES on a Tempo governance action - as Cardano governance (Minimum Viable - lets be truthful) is one of the key distinguishing features of Cardano. However, several problems in this budget are preventing me from doing this.
I want to be clear that this is not just about this proposal. We are setting precedents in Cardano governance with every vote. So, I would rather that we set positive precedents (better budgetary proposal actions now) - than make exceptions (weaker budgetary info actions) that may lead to more issues down the line as they proliferate.
I do not see any committment in this proposal to make it open source with a specific license and a definite date to do so. Not saying it is obligatory, but unless there are some extenuating circumstances - it makes it more difficult for me to vote YES - as governance is a key component of running Cardano. Locking governance into proprietary tools - requires a deeper explanation and rationale - especially if it is to be financed from the Treasury. Not saying that there is no argument to be made there, but the proposal lacks any argumentation on this topic. I want to see a future roadmap for Tempo - as we could see Tempo pack up and go after the 6 month period (1 Aug 2025 - 31 Jan 2026) that they are requesting funding for. And there would be no public good left after they leave.
The financial numbers should be disaggregated and could quote specific rates, identify roles and also look forward towards the financial future of Tempo and what are the plans downstream.
I find the entire proposal a bit light-weight - and it is much less comprehensive than a typical Project Catalyst proposal. This is a Treasury Budget proposal and should be more - rather than less detailed.
Tempo.Vote tackles a real usability gap. Overall, I'd say the proposal seems - with the current sparse information - over-budgeted and under-specified. Committing to open-source transparency - with a clear future strategy - will significantly raise its chance of a Yes in the on-chain vote, in my view. However, that is just personal feedback.
Some more background about the administrator Selfdriven would have been helpful, as I am not aware of this company - although I recognize one or two Cardano community names from their webpage.

Japanese translation via Google Translate:

Google翻訳による日本語翻訳：
この投票の前に、一言付け加えさせてください。Tempo.voteがCardanoガバナンスに貢献してくれたことに感謝しています。彼らはDRepsへの投票方法を提供し、プラットフォームの改善にも積極的に取り組んでくれました。私はTelegramグループで定期的に問題を報告していましたが、通常24時間以内に返信があり、問題を解決してくれました。私はTempo.voteにプロフィールを登録しているので、彼らの貢献に感謝しています。この投票もTempo.voteから提出するつもりです。
製品を構築した今、彼らはTempoの将来像を大局的に検討すべきでしょう。Cardanoガバナンス（正直に言って、最小限の実行可能なもの）はCardanoの重要な特徴の一つであるため、Tempoのガバナンスアクションには賛成票を投じようと考えていました。しかし、この予算にはいくつかの問題があり、賛成を阻んでいます。
これはこの提案だけの問題ではないことを明確にしておきたいと思います。私たちは、すべての投票を通してCardanoガバナンスの先例を作っています。したがって、例外（予算情報に関する対応が弱まる）を設けて、将来的に問題が拡大するリスクを高めるよりも、前向きな前例（より良い予算提案）を作る方が良いと思います。

この提案には、特定のライセンスと明確な日付でオープンソース化するという確約は見当たりません。義務だと言っているわけではありませんが、特別な事情がない限り、ガバナンスはCardano運営の重要な要素であるため、賛成票を投じることは難しくなります。ガバナンスを独自のツールに縛り付けるには、より深い説明と根拠が必要です。特に財務省からの資金提供となる場合はなおさらです。議論の余地がないと言っているわけではありませんが、この提案にはこの点に関する議論が欠けています。Tempoの将来のロードマップを見たいです。資金を要請している6ヶ月間（2025年8月1日から2026年1月31日）後にTempoが撤退する可能性もあるからです。そして、彼らが撤退した後には公共の利益は何も残らないでしょう。
財務数値は細分化され、具体的なレートを引用し、役割を特定し、Tempoの財務的な将来像と今後の計画について言及できる必要があります。
提案全体がやや軽薄で、典型的なProject Catalystの提案よりもはるかに包括的ではありません。これは財務予算案であり、詳細度が低いのではなく、より詳細であるべきです。
Tempo.Voteは、ユーザビリティのギャップを埋めるものです。全体として、現状の情報が乏しいため、この提案は予算超過で詳細度が不足しているように思われます。明確な将来戦略とともにオープンソースの透明性にコミットすることで、オンチェーン投票で賛成される可能性が大幅に高まると私は考えています。ただし、これはあくまで個人的な意見です。
管理者であるSelfdrivenについて、もう少し背景情報があれば助かります。この会社についてはよく知りませんが、ウェブサイトでCardanoコミュニティの名前をいくつか見覚えがあります。

I vote YES on this reworked and improved GovToools proposal.

The original proposal for Cardano GovTool that was rejected by DReps was worth ₳2 million. I voted NO on that previous one (earlier this year) due to concerns about the size of the budget request and a perceived (from my point of view) lack of agility and responsiveness of GovTool to the concerns from DReps who were one of the end user categories of their tool.

My key concern was mainly the inability to vote in a smooth and orderly and uninterrupted fashion over GovTools. The user experience was not there. However, my NO vote was mostly a message - that they need to go back to the drawing board.

I originally voted NO mainly because of: (a) perceived high cost vs what we were using (b) lack of engagement by GovTools team to proactively prevent voting disruptions on their platform.
My impression is that the GovTool team rolled with the punches and managed to turn what was a major loss into a much better proposal and improved approach to how GovTools should be developed (with community feedback).

Equally importantly for me - the new budget info action adds up to ₳1.15 million. The Tier 3 (most robust) version encompassing full active dev & maintenance (for ₳1.15 M) delivers the same five-pillar (Proposals Pillar, Delegation Pillar, Voting Pillar, Outcomes Pillar and Budget Discussions Pillar) coverage for 43 % less ADA. Savings mainly come from slimmer FTE assumptions and sharing ops overhead.

They regrouped, refocused, held Twitter spaces and consultations with the community. They now submitted this budget info action - separately from Intersect. Although the details of the administration process are aligned with the structure provided by Intersect as administrator.

The new proposal was drafted with users after four weeks of feedback. It also dedicates funds to grassroots contributors and companion tools. This is an important concession and a strong match for Cardano’s decentralized and participatory ethos. This should remain part of GovTools philosophy as we progress.
I welcome the team's idea to introduce a tiered structure and streamed contracts - allowing DReps to dial spending up or down and stop payment quickly if milestones slip.

The explicit grants for projects like 1694.io or Tempo.vote and cardanobudget.com also are encouraging for creating "an ecosystem of complementary front-ends" rather than a single monopoly tool.

As regards the constitutionality of this proposal, I defer the ultimate judgement of this aspect of this proposal to the Interim Constitutional Committee.

**Summary:
**
This is an excellently written proposal. The quality of the treasury withdrawal package (documentation, team, clarity of purpose, smart contract support) sets a high bar (but also a welcome example) for all future treasury withdrawal actions. There is no time to lose. Affordable, yet outstanding.

**Rationale Statement:
**This is an excellently written proposal. The quality of the treasury withdrawal package (documentation, team, clarity of purpose, smart contract support) sets a high bar (but also a welcome example) for all future treasury withdrawal actions. Rationally priced. Very promising.

I re-read the Amaru CARDANO BLOCKCHAIN ECOSYSTEM BUDGET DETAILED PROPOSAL in PDF format and it was not only written to propose a budget, but it also demonstrates a level of forethought and planning that is encouraging.

I have independently checked that each of the Receiving Addresses that will be receiving funds from the Treasury Withdrawal action have their vote delegated To "Abstain" DRep and that the address is "Not delegated" to any stake pool.

Independent of this treasury action, as an independent Project Catalyst Milestone Reviewer since Fund 2, I have reviewed multiple work Proof of Achievements from several of the involved Pragma members. Generally, my personal experience is that I have been impressed with the quality of their work and deliverables. This is important - for me as an individual DRep - who has to take into account more than what is just written in a proposal. No proposal lives in a vacuum. There is wider context for most events that occur in the Cardano ecosystem - and this type of feedback also influences my decisions. I could pretend that it doesn't, but that would be self deceiving.

**Precedent Discussion:
**## The Pragma group shows that being lean and being focused can yield benefits (especially in the form of speed) for teams that wish to access Treasury Funding.

Pragma shows it is possible to set up an alternative administrator structure to Intersect (and other MBOs) - which is a nice precedent to make.

The introduction of a smart contract in the process just serves to show how the treasury withdrawal actually builds on the existing Cardano protocol and further contributes to it - instead of just "withdrawing" from it.

The idea to introduce a comparison to similar projects (RETH, Firedancer, Cardano-node) is a good approach, as no proposal exists outside a real world context.

This proposal also maximizes resources for the Treasury by not charging for the funded time of certain of its team members. Total of the resources already available or funded: 2 FTEs from people that are employees of the Cardano Foundation.

I welcome the team's breadth to view this proposal as much more than a technical contribution to the blockchain. The team states: "This proposal is more than just a funding request; it is an invitation to collaborate and innovate together" AND "By focusing on building, learning, and demonstrating tangible progress, we are confident that Amaru will pave the way for a more resilient and decentralized Cardano ecosystem, ensuring long-term reliability and innovation. This to me suggests an understanding that this type of technical work is much more than a mere developer-focused temporary paid gig. It has a wider and broader significance and the team is aware of the wider context.

Contingency Funds - this is a precedent that can have negative implications. However, the team has addressed this in a sensitive and in-depth way. See next section on Counter Argument Discussion

**Counterargument Discussion:
**

Personally, I am not a fan of adding contingency funds. Yet, I am aware that the real world is the real world. However, the precedent that is being created ("we will add a 25% contingency fund") could serve as a template for all future treasury withdrawal actions that will be marked up with increasing percentages. This needs to be mitigated somehow. However, I am aware that this stems from the volatility of ADA exchange rate vs fiat currency.

This is partialy mitigated by the team's foresight to specify that they intend to "secure the treasury withdrawal with stablecoins whenever possible to keep the value until final payment to contributors is done

The most important aspect of the Amaru proposal - regarding the contingency funds - is that the team calls for the sending of the "Contingency" back to the Cardano Treasury - if not spent. The budget proposal states: "12 months after the treasury withdrawal what's left within the contingency account will be transferred back to the Cardano Treasury."

**Conclusion:
**
In short, I am happy that this is the first Treasury Withdrawal request that I can vote YES on. It sets a lot of positive precedents and it will hopefully shape the future of wisely crafted and well presented Treasury Withdrawals - as we progress developing Cardano.

I will change my vote for the 300M NCL from NO to YES.

a. It is not backdated to the start of the 2025 calendar year, meaning that a new NCL will not be needed for a full year
b. The spending period matches a full year from now (around May 17 when epoch 563 started), and the rate is more sustainable than the 350M ADA NCL that has been approved.

Given we're still figuring out the budgeting process, this is a more responsible choice than the already approved 350M ADA NCL.

OLD RATIONALE FOR NO VOTE BELOW

I voted YES for an earlier previous NCL action that sought to set the NCL at ₳200M for 8 months until the end of the calendar year. I saw that as a better choice than the initially proposed ₳350M NCL motion. That vote still stands and I think it would help to jumpstart the budget process.

This current action proposes to set the NCL at ₳300M for 12 months from Epoch 532 to the end of Epoch 604. On the face of it, they may be similar.

Yet, for a 12 month period, I do not support ₳300M ADA in spending.

I favor an annual (12 month) NCL of up to ₳200M - 250M ADA at a time when budgetary
processes are weak, auditing capacity is unproven, DRep resistance to outside pressure is low, the fate of Intersect MBO is uncertain and the entire process remains convoluted because it is minimum viable governance.

A complex Minimum Viable Governance voting stage means that many small DReps who cannot devote hours and hours to the process with the current rugged tooling and shifts - are either unable to participate or unwilling to participate.

More organized institutional DReps or holders some of whom may be both DReps and also requesting funds from the treasury - face lower barriers to accessing funds. I see this as a danger.

Over the Ekklesia tool, I have voted YES for ₳141.43m in funding requests. I have abstained from voting on Catalyst that is a further 70M ADA (likely to pass) and from voting on Intersect's budget (max 20M ADA, possibly lower after recent changes).

If my voting tally were to be added up with the Intersect and the Catalyst requests - the total would still be below ₳250M.

By voting NO on this proposal, I am signaling that a NCL of up to ₳200M - 250M ADA would be my preferred choice as it is more responsible at this stage of minimum viable governance.

The provided rationale for a second node implementation is technically strong and strategically aligned with decentralization principles. Reducing reliance on the Haskell node is sound from both a security and governance standpoint. Of course this argument would not apply ad infinitum, as adding too many nodes may lead to wasted efforts. There’s a thin line between strategic redundancy and fragmentation. However, so far Cardano has put all eggs in the Haskell basket. The Rust node will add resilience through implementation diversity and represent a new pathway to approach Cardano for dev teams.
Is seems to be fairly priced by Web3 standards for a 6-month effort with a senior team.
The proposal takes governance seriously, with credible disbursement and reporting mechanisms.
I further appreciate the direct submission and the avoidance of going through a much more convoluted process with many other proposals that need to be "packaged together" in one info action. This direct submission allows DReps to vote directly on this proposal and its own merits.
Last but not least, the implementing team is quite capable and well-known for their quality contributions to the ecosystem through a myriad of different projects.

I am voting NO on the proposed 2025 Cardano Blockchain Ecosystem Budget because I believe the total amount requested is too high, especially for the first year of minimum viable on-chain governance.

I also believe that bundling 39 proposals together into a single vote limits DReps’ ability to express the differentiated support that we saw in earlier stages. This approach flattens nuance and imposes an all-or-nothing decision on a diverse set of funding priorities.

I also acknowledge the existence of the three founding entities that were allocated Genesis ADA that are working with different levels of success to improve Cardano according to their original missions. Some of these missions have been nominally completed, some of these missions continue in their original form, some continue in a new form. I do not pretend to know all the nuances.

Still I take that as a factor in my decision-making. Treasury funds should be used judiciously in complement and in awareness of the existence of the entities.

This vote against this Budget in its full size is based on:

1. My participation in the DRep voting stage and the level of DRep participation as a whole;
2. The level of support that some proposals received relative to others;
3. The relative importance of certain proposals vs others and the quality of the teams and their dedication to Cardano’s mission;
4. And the expectation that Catalyst will likely gain sufficient support (in this or future budget proposals) to continue to support smaller, experimental, or commercial projects.

While spending from the Treasury is not new (Catalyst has done it before), this is the first major annual on-chain budget, and it sets a precedent.

In my view, the issue is not inflation within the Cardano economy — most ADA will not be used to buy NFTs or FTs. Nor is it simply about a slightly higher disinflation rate. The deeper issue is ADA devaluation due to external sell pressure. Most of the funded ADA will be exchanged for fiat (USD, EUR, etc.), not recycled internally. This adds downward pressure on ADA’s price.
It is a see-saw that has its quirks.

In a real-world economy, if you spend more to "jumpstart" the economy, face inflation if the supply of services and goods cannot meet demand.

In a still nascent blockchain economy, spending more essentially means converting the native token for fiat, and the result is devaluation. We are not exchanging ADA directly for Cardano economy goods and services, we are selling it into the real world. The ADA is not recycled internally. This adds downward pressure on ADA’s price.

This devaluation affects everyone:

1. The most important funded projects
2. The projects that were not funded
3. The builders who didn’t ask for funding
4. The ADA holders who fund all of it through opportunity cost

Of course, that is unavoidable. Most of the ADA allocated will likely be converted to fiat (USD, EUR, etc.) to pay for services, not retained or reused within the ecosystem. This creates exchange rate pressure, weakening ADA’s value.

The question isn’t whether devaluation will occur — it will. The real question is: Where do we draw the line? Do all 39 proposals in this budget bring more value than the cost of the devaluation they collectively impose? Do we need to bundle them all in one YES/NO budget vote? I think No.

We are approving a large, externally-focused budget at a time when Cardano’s “blockchain economy” and governance mechanism is still immature and internally fragile.

Treasury funds should primarily be focused on critical public goods in different forms. Especially if they are open source; support infrastructure, research, tools, even education, promotion of Cardano. This applies when the goods align with the long-term mission of Cardano as public infrastructure. Yes, there may be exceptions that emerge, but those exceptions are expensive — and others will pay for them.

If we overfund less impactful proposals, we risk undermining the impact of the most critical ones, simply by diluting the value of what they are paid in.

For this reason, I believe a smaller, phased budget focused tightly on foundational public goods would be a better and safer starting point.

I include this rationale as an earnest view of the proposed budget action with the aim of contributing to the process by encouraging the submitter (Intersect) to take more factors into account.

I abstain from this vote as the proposers have indicated on social media that they intend to resubmit the proposal with some changes or adjustments to it.

The seven proposals bundled together in this motion have all received very high approval ratings from DReps in the off-chain temperature check process that took place over the Ekklesia tool developed for Intersect MBO a few days ago.

During the Ekklesia voting stage I voted YES for all 7 proposals that are now bundled and as all 7 have received a lot of YES votes compared to the total participating DRep poewr in Ekklesia (I checked and saw that one of the top voted on proposals (2025 Input Output Engineering Core Development Proposal) was voted on by a participating stake of Total voting power: 4,009,632,409 ADA

The proposals listed in this budget action have received YES votes from at least 2,695,223,782 ADA that took part in Ekklesia voting. This indicates a support of more than half of the DRep voting power.

Yes, governance is still performing baby steps, however, support for these proposals has been clear and there is no evident need to slow them down by requiring a mandatory bundling of these 7 into a larger budgetary package now that the action has been proposed.

As regards the constitutionality of this proposal, the true measure of its constitutionality will be given by the Constitutional Committee. As a DRep, my impression is that this proposal does not have glaring omissions that would require us to stall the DRep process. The CC will address the constitutionality in its own right.

We are in 2025. I've been in Cardano since 2017. The general expectation that transaction fees would start contributing meaningfully to increasing the treasury has not yet materialized. This is today's reality. It is April 25, 2025.

Our collective optimism about rapid widespread blockchain adoption - especially Cardano - was probably misguided. A lower limit in 2025 than the previously approved 350M ADA limit, essentially forces governance participants to focus on priorities that will give more bang for the buck. For ADA holders.

There are needs and there are wants. 200M ADA will cover the needs and not just basic ones. Reminds me of the debate of what is the purpose of art. What is the purpose of all this?

Reminder: ‘L’art pour l’art’ was a phrase and a philosophy that pushed back against the idea that art must serve moral, political, or educational functions. As ‘l’art pour l’art’ was challenged for ignoring purpose, so too we must challenge development for development’s sake. Treasury funds must serve real Cardano needs—not just the desire to build and develop through treasury subsidies.

"Développement pour développement”—development for its own sake funded by the treasury —is not a sustainable principle for Cardano’s treasury strategy. We will be best served by funding needs and clear common sense strategy, not enabling endless creation and dependence without clear purpose or prioritization. Some teams may drop off, some products may not survive.

Every expenditure is risking funds. I still see lots or risks and few certain bets.

I've read 100 or so Cardano 2025 budget proposals so far, or roughly half. An NCL of 200M ADA seems a better choice than the previously approved 350M ADA - from what I have read so far. I also share the concerns voiced earlier by Cardano Whale about releasing too much ADA into the market - especially as 200M ADA seems to be sufficient for 2025. The NCL can easily be raised in case of outstanding circumstances.

My only potential gains from the Cardano 2025 budget process are:
a. DRep compensation (I will vote against)
b. milestone/community reviewer payments from Project Catalyst (I will abstain from voting on Project Catalyst - (this is just a personal decision - not advocating it to others!) to attempt to maintain a higher level of personal objectivity in the entire process)

I welcome the proposed Net Change Limit proposal. It is important to approve an NCL and I am voting NO on this one due to several reasons:

1. The problem I see with a very large first year NCL is that our budgetary and governance processes are the weakest, keep changing from week to week and are probably the most inefficient in the first year. Our ability to audit, prevent waste and abuse are questionable. A lower NCL would focus minds.
2. The proposers have stated that from January 5th, 2024, Epoch 459, through December 30th, Epoch 531, the actual total income into the Cardano Treasury was 335,957,093 ada. The proposed NCL is 350M ada. This is roughly 14M ada HIGHER than the total income in the Cardano Treasury for 2024. I welcome the proposed reference to modelling and the reference to a previous period for which we have data. The motion uses modelling of ADA inflow for the previous year as the main basis for approving an NCL. It is indeed one of the factors that must be considered.
3. What I am missing in this proposal - as it proposes a relatively large NCL - is even a minor economic analysis of how approvals of different NCLs could impact the valuation of ADA. An NCL of 350M ADA is sending a signal to the market. What is this signal? How does it compare to previous signals? If we do not have the data, is there room for a prediction at least? With the lack of this economic/monetary analysis, we are left to speculate. My feeling is that NCL approvals in the future will shape the ADA exchange rate vs the USD. It is a signal how much ADA could be released - a signal approved by the majority of DReps. The approval of a large NCL could have an immediate price impact on the value of ADA, thus diminishing the purchase power of the 350M ADA. Before the budget elements are approved.
4. After approving a large NCL, the budgetary discussions will probably take place in the shadow of a lower ADA/USD exchange rate. Thus we might be forced by the market to push an annual budget towards the top limit of the NCL. We could create a self-fulfilling prophesy.
5. Without a monetary/economic analysis or forecast, I would consider voting for a NCL in the 200-250M ADA in 2025 (depending on the text of the NCL proposal) as it would give a better signal to the market about our intentions to balance the development of the system and the intention to safeguard the value of ADA and Cardano's Top 10 position. Especially, as our abilities to manage the potential spending of so much ADA in the early days of decentralized governance are the lowest.
6. I see this conservative approach as something that protects the interests of ADA holders and stakers. We SHOULD approve the closest NCL to the actual budget that we want as DReps. If the intention is to approve a lower budget than 350M ada as some (many?) DReps seem to have indicated, then to preserve the value of that ada for those who will receive it, the best thing we can do is to vote for an NCL that is closest to that intended 2025 budget total.

While there seem to be some open questions surrounding the definition of NCL in the Cardano constitution, I will sidestep that issue here.
The reason why I am voting against the proposed governance action is because it wishes to set a Net Change Limit for two years in one swoop.
This not only weakens the chances for the motion to pass, but it also makes it less clear what needs to be corrected if the motion fails.
Future proposers should probably focus on proposing a Net Change Limit for one year, due to the slow nature of decentralized governance.
Finally, I was not convinced by the motion that there is an absolute need to set an NCL for 2026 this early, as it is March 2025. A lot can happen between now and 2026, setting a 2026 limit seems premature - hence a bad precedent.
I welcome the attempt by the proposers to highlight a need for conservative spending, by roughly limiting the NCL to the volume of of Cardano annual treasury inflows in 2025 and 2026.

The proposed elements of the Cardano Vision and Roadmap for 2025 and beyond seem to be pretty wide-ranging and I think that the product committee has done a good job.
I would like to see more explicit references in the 2025 Vision & Roadmap web page (https://product.cardano.intersectmbo.org/vision-roadmap-2025/) to:
a. research on quantum resistance for Cardano
b. research of improved algorithmic/collateralized stablecoin models for Cardano (i.e. improved versions of Djed-style stablecoins) - if possible
c. as Cardano is being built as an alternative financial operating system, there could be value in conducting dedicated research on Cardano's current limitations/opportunities for serving as a financial operating system for the world. Especially, on how Cardano's capabilities can be improved to achieve this global ambition - outside of the typical blockchain trilemma focus (decentralization, scalability, security).
I may update this vote with a larger rationale if the ongoing debate leads to new insights from delegators and other sources.

The proposed governance action [Decrease Treasury Tax from 20% to 10%] asks for an immediate reduction of the initial 20% treasury cut that was set at the launch of Shelley to the lowest possible rate of 10%. The Cardano constitution permits the value for the "treasuryCut" parameter to range between 10% and 30% (0.1 to 0.3).
This motion specifically requests change of the the parameter "treasury_growth_rate". It proposes the parameter be halved from 0.2 to 0.1.
However, the "reasoning part" of the motion does not mention the treasury_growth_rate parameter - specifically. I was also not able to find the parameter in the linked documents to this motion.
The reasoning in this motion references mentions "tau", "treasury cut" and "treasury tax". The proposal does not directly confirm that this is in fact the same parameter that is proposed for reduction as the "treasury_growth_rate" parameter .
However, this has been cleared up by IO Engineering Head of Product for Cardano Samuel Leathers who posted: "It's tau in Shelley Genesis. CLI team made the human readable name treasuryCut. DB sync made the human readable name treasury_growth_rate. all 3 are names for the same thing." [https://x.com/therealdisasm/status/1893361564780032172]
Knowing all the terms above refer to the same thing, it makes it possible to vote on the proposed change.
My vote will be AGAINST this specific motion, but it is likely that I would support a gradual decrease of the tau parameter in the near future under similar circumstances. This would also allow us to observe the effects of such changes and also it would set a precedent for gradual changes of economic parameters, which I think should probably be the norm when possible.
Cardano is now a global financial system that DReps should carefully steer if possible. I have not been convinced there is a need for a sharp swing from 20% to 10% as there is no impending catastrophic event that prevents us to chose a gradual reduction.
If we are building a financial system, there is something to be said for financial predictability and gradual change. Outsiders looking at Cardano as an alternative financial system will look at how we manage change. Change is systems like this is supposed to look like gradual evolution - whenever possible.
Disclosure of conflict of interest/bias:
If voting YES: As an ADA holder, I have a conflict of interest here, as there is a possibility that my staking income will increase by supporting this proposal. As a Catalyst Community Reviewer and Milestone Reviewer, I stand to potentially indirectly benefit from the continued and larger financing of Catalyst from a larger treasury. However, this conflict will be mitigated by the fact that I intend to either ABSTAIN on any future vote about the budget component/bucket that will involve funding for Catalyst or even vote NO if I find that the requested budget component/bucket that includes Project Catalyst is too large. I will never vote YES to finance Project Catalyst, due to my conflict of interest and my intention to remain objective. Also, I stand to benefit from possible DRep compensation if approved from the Treasury. However, this is something that I do not support and I will not vote in favor of DRep compensation. I think a vote on DRep compensation should not be packaged with other items and should be separate from the annual budget.
If voting NO: I am not aware of a conflict of interest. As an individual paying member of Intersect, I am watching the Intersect budget process - but I am not a paid or unpaid member of any Intersect working group, committee, organ or team.
I am not an SPO, a member of a Cardano dev team or Cardano project. Nor am I affiliated or ever was affiliated with IOG, Emurgo or Cardano Foundation.

Gov.tools limits rationale to 500 characters! Proposed constitution - step towards further Cardano decentralization. Not perfect. Constitution continues to divest governance power from 3 founding entities and redistributes it to ADA holders.
Cardano was designed to evolve. The constitution can evolve. Document reflects the essential nature of the blockchain whose principles it codifies.
My YES vote is a vote of trust in the Cardano community and its ability to wisely use constitutional tools

The Cardano Foundation as a CC member says the vote is unconstitutional. They are not judging the K parameter issue. I agree with the CF there is a lack of RELEVANT supporting materials. Governance actions should respect the required form & minimum requirements. Article III, Section 6 requires them to be included. I agree that "consistent standards across all types of governance actions is crucial to preserve the effectiveness and credibility of the governance system. Vote changed to NO.

The proposal is a respectful and well-meaning message that contributes to creating a positive atmosphere to the wider debate on governance and to governance itself. Cardano started almost a decade ago, it has a long history and this governance action serves to acknowledge it. I vote YES.

Although this is rumored to be the name-the-next-hard-fork Hosky governance action, alas it is missing data on gov.tools

Hence, I abstain.