Hephaestus Stake Pool [HEPHY]

I vote YES on the treasury withdrawal action “Eternl: Path to Sustainability - v2” (fbb8d1a4a8d6b62f8cd706944a0582b884c2b90187b8fada7953d5c6a33eb5a7#0).

I voted YES to funding this last year, with the benefit of the doubt. I was disappointed to see Milestone Acceptance Forms simply state “Eternl was online for users this month” when I first started to check in on various project progress in late 2025. I also voted to fund AdaStat and Cexplorer last year and that funding has resulted in a visible change to my daily interactions with the Cardano blockchain, often for the better. My interactions with Eternl, have not evolved in the same way. With that said, version 2.0 did drop right around budget season last year and 2.1 has just released this year, although I wish these big upgrades didn’t feel like they were held back just for budget season.

I was prepared to vote ABSTAIN or even NO this year but the recent events around other ecosystem wallets have shifted the landscape somewhat. The Lace 2.0 release, and the long-awaited mobile wallet, has been a massive disappointment. So much so I deleted it from my mobile the same day. For a flagship wallet from a founding entity, the one who wrote the original Icarus light wallet reference implementation that Yoroi was built from in 2018 no less, it was an overwhelming let down. For me, a mobile wallet should have hardware wallet support and the ability to send via your own node as a minimum requirement or the cypherpunk dream really is dead.

Secondly, the whole Yoroi/SecondFi incident, from another founding entity, has been a disaster. Forcefully migrating users from the longest standing open-source wallet, available on both desktop and mobile, with nearly 8 years of track record, to a closed-source, poorly implemented wallet which resulted in the massive hack was wholly unacceptable. The brand damage, the financial cost to users who did not ask for the migration, and everything else that came with is reprehensible.

Although Eternl is closed-source and could equally carry the same risk while not having open-source code for the community to evaluate. It has a track record for security, is one of the most widely used wallets, and offers a strong feature set for advanced users. It remains my most used wallet provider. Additionally, it is the only wallet that supports Mainent, Preprod, Preview AND SanchoNet. No other wallet can boast that level of support and much like testnet SPOs, that service provides no income, but allows us all to develop and test new platforms and features ahead of Mainnet. Ensuring Mainnet stays secure, allows new people to experiment with the Cardano technology without any financial risk, burden or implications. That availability alone is invaluable and should be used to onboard more users than it is. For these reasons, I support this bridge funding towards a more sustainable Eternl wallet.

This vote corresponds with my previous vote on the Hydra Voting platform.

This vote corresponds with my previous vote on the Hydra Voting platform.

This vote corresponds with my previous vote on the Hydra Voting platform.

This vote corresponds with my previous vote on the Hydra Voting platform.

I vote YES on the treasury withdrawal action for “Mithril Protocol” (b3d452bff7769d7f557ec6b8974760ee6c5e496c276652b654032966621e0ccf#5).

I have been a Mithril supporter since day one and believe that the work absolutely must continue. As an SPO that has ran a Mithril Signer since day one on Mainnet (July/Aug 2023) I have witnessed the progress and development first hand. For those unsure of its value reading this, in 2025 alone Mithril facilitated 6,648 full node restorations, saving node operators ~46,500 hours in start-up time. Most recently it allowed Daedalus, the full-node Cardano wallet, to go from a fresh install to synced in an hour, having notoriously taken much, much longer in the past.

The Mithril technology is not just limited to reducing node sync times, it can also play an essential role in interoperability with other chains by providing securely provable snapshots of the chain state. Secured by SPO stake. The more stake that participates in the Mithril Protocol, the stronger the security guarantees of any certificate it produces. Therefore, stake to Mithril Signer SPOs! You can find an easy to search list on my HephyPool website and delegate in just a few clicks on Cexplorer.

While I have some reservations regarding some line items on this proposal, if it is to move away from IOG stewardship then I believe the technology absolutely must continue to be funded. My initial comments on the proposal can be seen on the Hydra Voting platform.

I vote YES on the treasury withdrawal action “Intersect Technical Steering Committee Support” (b3d452bff7769d7f557ec6b8974760ee6c5e496c276652b654032966621e0ccf#3).

The Technical Steering Committee of Intersect also supports the Parameter Committee, Hard Fork Working Group and Security Council. All elements that have played a pivotal role in Cardano’s growth and resilience over this past year. Including Plutus Cost Model, tx and memory unit, and committeeMinSize parameter updates, the van Rossem hard fork coordination, chain partition incident response and SecondFi assistance.

It’s not necessarily work that makes headlines but it does help keep Cardano secure and operational, reducing any negative headlines.

This vote corresponds with my previous vote on the Hydra Voting platform.

This vote corresponds with my previous vote on the Hydra Voting platform.

This vote corresponds with my previous vote on the Hydra Voting platform.

This vote corresponds with my previous vote on the Hydra Voting platform.

I vote ABSTAIN on the treasury withdrawal action “Strike Finance Liquidity Deployment” (8721696358acdd43e34e5ed9ef1b3e2a1d2af9c1aa1972e017b9b9271b7ddc70#0).

At this hour it does not look like this proposal is anywhere near close to passing. I am choosing to abstain out of acknowledgement of my lack of understanding around the subject rather than attempting to vote blindly on something I am not fully informed about.

I vote YES on the treasury withdrawal action “Se7en Labs: Daedalus Wallet Maintenance and Improvements 2026-2027” (d8de068952df50c862fa1bce9b8180d3387976cbae0fb2c3d9ef84f0faaf64d6#0).

As a user of Daedalus since March 2018 I am happy to see a team once again pick up the maintenance of Cardano’s only full-node wallet after years of neglect from IOG. The Yoroi/SecondFi incident recently highlighted the importance of self-sovereignty and the potential risks of closed-source light wallet providers. Running your own node is also central to the cypherpunk vision and an aspect of Bitcoin that staunch defenders have held onto and continue to champion today.

Daedalus, running cardano-node, had become a resource intensive platform and restricted its recent adoption after the being the only wallet available for the first year of Cardano’s existence. Back then the chain size meant that it had reasonable resource usage. When this crept up to 16-24 GB RAM and hundreds of GB in storage it became increasingly untenable for everyday users. Enter Mithril. The perplexing nature of IOG is that it designed and built Mithril, the solution to the painfully slow Daedalus sync times but it never merged the two technologies and wondered why Mithril adoption was slow. It sometimes appears as though IOG focuses on the “what can be built” and not enough on the “what have we built”.

I was sad to see that this did not get funded last year but the day that updated Daedalus was released by Se7en Labs, with the blessing of IOG, was genuinely one of the most positive days that I have had in this ecosystem in recent years, such is the contentious nature of Cardano governance these days. An updated Daedalus, hard fork ready on node version 11, with integrated Mithril. It went from fresh install to fully synced in an hour and the memory footprint on my Apple silicon Macbook Pro was just 4 GB. This is not all Mithril of course. Reduced sync times, yes. Reduced memory footprint, that is thanks to the newly implemented LSM trees and the ability to run UTXO-HD instead of having everything in memory.

I look forward to an expanded feature set for Daedalus now that it has a committed and dedicated team supporting it. I also hope that it can help bring some of those long dormant ada holders, sceptical of anything but an “official” wallet might once again find their way to participating in the ecosystem. Even if that means simply moving to a non-retied stake pool and delegating to DReps once that becomes available in Daedalus. Ada should be participating in the security of the ecosystem, not lying dormant in neglected wallets.

By the way, while you’re here, stake to a Mithril Signer SPO and support helping make Daedalus great again, find one on the HephyPool website, and delegate in a few clicks on Cexplorer.

I vote YES on the treasury withdrawal action “Cardano Enterprise Adoption: Ticketing Platform” (35b44189eb4795d5775122da52a3a115753f83fd662dd1ff205ea633fc99b34e#0).

I voted YES for this on the Hydra Voting platform, was sad to not see it receive enough support then, but respect to the team for now trying directly on-chain instead. Similar to my support for the 5am.earth proposal – if we don’t start taking a chance on commercialisation of this chain and increasing our transaction counts then what are we even doing here. The idea of blockchain to reduce the worldwide problem of ticketing and inflated secondary sales is not new, but we have yet to see anyone solve it at scale by merging the two systems. Even the UK government, as recently as June 2026, have been pushing to explore blockchain-based ticketing for major sporting events, highlighted in a recent X post. It feels as though this is one of those “right time, right place” moments and if we don’t seize the opportunity to demonstrate a real-world implementation of a solution then we will find Cardano once again in 2-3 years watching other chains having success in this area saying to ourselves “that could have been us, remember that team that kept requesting funding for something similar in 2026”. Time to be narrative leaders instead of narrative chasers.

I vote NO on the treasury withdrawal action “Alchemy by Sundial x Charms: Cardano-Native Bitcoin Treasury Protocol” (0f75dd11be0b7a6cb4b305a175b17cf4b60cd307c052fccabf9f572950e70583#0).

This appears to be a somewhat rushed proposal and I am not sure why extra time was taken to clarify key elements ahead of submission. I understand that there has been a “race to the NCL” in 2026 but some of the ambiguities in this proposal are perplexing to say the least.

First of all, “Intersect is proposed as interim fund administrator, subject to confirmation and final agreement”. Why was this not confirmed prior to submission? This ambiguity alone pushes this proposal into unconstitutional territory right out of the gate. Naming an administrator “in case they accept” is not the same as having a defined and agreed administrator. DReps are expected to vote on a proposal with a named administrator so that they can verify and vet the appointed administrator if required.

Secondly, the designated receiving address points to the Intersect 2025 Treasury Reserve Smart Contract. If Intersect has not been confirmed as the administrator, how can the proposer point the treasury withdrawal at Intersects smart contract framework in this proposal?

Furthermore, this is the 2025 smart contract which is the most curious aspect of this whole proposal given that Sundial is one of the co-proposers. All of the treasury withdrawal proposals from the Intersect budget process 2026 point to the 2026 Treasury Reserve Smart Contract. Sundial is a part of the recently expanded 2026 Oversight Committee, as listed in all of the Intersect TWGA proposals under “Intersect Budget Management Tooling – Specifics”. This distinction should have been well known and understood by them.

I vote YES on the treasury withdrawal action “Intersect: Governance coordination and technical stewardship for the Cardano ecosystem” (b3d452bff7769d7f557ec6b8974760ee6c5e496c276652b654032966621e0ccf#4).

First of all, voting YES to the Technical Steering Committee (TSC) proposal while voting NO to the Intersect core proposal seems nonsensical to me. It is highly unlikely that the former would exist without the latter. Secondly, requests to unbundle the proposal while seeing the value in the technical element, while the technical element is ~75% of the ask here seems equally perplexing.

Voting as someone who is both an SPO and a DRep, I am someone who downloads the source code for node upgrades from the Intersect repositories, and for the van Rossem hard fork (and Chang and Plomin before that) I received my information from the Hard Fork Working Group, who have operated under the Intersect Technical Steering Committee and coordinated three hard forks now. What happens to these repositories and to future hard fork coordination if funding stops?

We are all so keen to see Leios come to fruition and yet are we prepared to pull the rug out from under the coordination layer that has successfully overseen three hard forks now? It is not just the technical when it comes to Leios either. Constitutional changes are required to accommodate new block types and parameters, and the Civics, Technical Steering and Parameter committees are already in discussions with IOG on the best way to move forward here. Without funding, will Intersect still be able to support this coordination through to Leios? Coordination is often unseen and unsexy work but it is often the critical work that takes place in the background. When I turn my bathroom taps on every morning, I don’t think about the plumbing and the processes that result in the clean water that comes out, it just happens, I only notice something wrong when something breaks or that plumbing is no longer there.

It is unfortunate that the 3% administration fee did not exist last year as it would have likely helped reduce the ask here this year now that the Treasury Reserve Smart Contract is showing 500M+ ada under administration. However, the realisation and the move to this administration fee model in 2026 is encouraging as it makes the 2026 funding more of a bridge to a more sustainable Intersect and less of a recurring treasury dependency. The fixed fee should mean that Intersects revenue from these services should scale with their utilisation going forward.

With the future of Emurgo uncertain and IOG moving more of the technical scaffolding towards Intersect, I don’t think now is a good time to possibly lose another major entity from the ecosystem. Intersect might not be perfect and everyone has their own opinions and views on what it should be but the unseen work that stewards the core blockchain technology is too valuable to be haggling over it at this critical juncture for Cardano.

I vote YES on the treasury withdrawal action “Reimburse Ikigai Info Governance Action Deposit.” (d52a4917df4f91c342eaf06ebb4c0a5c3156f6412d137f307cc77eb911f47ab1#0).

This one has been a long running saga in Cardano’s short governance history. The withdrawal stake address matches the stake address that submitted the original info action that lost the funds (donated to treasury). While the 3000 ada “interest” can be questionable, as we cannot guarantee that these funds would have continued to have been held by the ada owner for all of this time. I do feel that it is time to put this particular discussion to bed. It happened early in governance, everyone was still learning at the time and it was a genuine mistake. Let’s correct it and move on.

I vote YES on the protocol parameter update action “Reduce the committeeMinSize parameter from 7 to 5” (c75bb221606687aa858ec89c7a15c88e9c17054f2e045ae31ecc8a9687cd206e#0).

I reluctantly vote in favour of this action having witnessed the ecosystem reject an attempt to increase the number of Constitutional Committee (CC) members to 8 last year. Preference would have been to increase the number, while keeping the minimum at 7. However, no system can sustainably operate at the limit continuously. Operating with 7 members while the protocol minimum is 7 has left the Cardano governance system exposed to a level of fragility that it should never have been placed in in the first place. With an increasing number of individual member seats, as opposed to consortiums, the risk of one or more being unable to fulfil their duties at any point in time risks stalling the governance system. As we have seen play out following the retirement of a CC member in late 2025.

Voting as a DRep, who is also a Civics Committee member, the timing of this (re)submission to Mainnet has been unfortunate. As the metadata highlights, this was approved by the Civics Committee on 2026-03-13. 84 days passed before reaching Mainnet submission.

Yes, careful coordination was required to prevent a repeat collision with another parameter update, as happened following the submission by a community member, and hindsight is a wonderful thing but over-cautiousness regarding the Plutus Cost Model update and the hard fork has resulted in some unfortunate timing. It was submitted during the CC election registration phase and made it appear as though this submission was a knee jerk reaction to low turnout numbers at the time. This was absolutely not the case. It was months in the making. Another impact of timing was that, had this been submitted sooner, it would have better informed the Intersect CC election process. Had the proposal failed, the process could have pivoted early enough to electing more than the minimum members. Not having this answer ahead of time hand tied the process into committing to the 4 minimum and now hoping that this proposal passes.

Additionally, the metadata put forth by the Civics Committee was largely changed by the Technical Steering Committee. The educational content and context as to why this was being resubmitted again was largely removed and focussed on the technicalities. Leading me to publish an explanation article on X here: https://x.com/HephyPool/status/2063399716084183367?s=20. Which at least one DRep has admitted actually helped inform their voting decision. Metadata should seek to educate and inform the community, not just focus on the technical. It would have cleared up many of the misconceptions and allowed DReps to vote more clearly.

All in all, I am voting YES. The idea has been discussed for long enough, received Civics and Technical Steering support, contains a reversion plan and uses the correct parameter name throughout. With that said, let’s increase the size of the CC in the future.

I vote NO on the info action “Reforming Treasury Governance” (5d3a1f657fe330b51b459ca9b482fc1a3b6e3336227f880d8a058771c23e3ce2#0).

This may be just an Info Action but it does not mean that we should lower proposal standards this far into year 2 of Cardano governance. DReps and CC members are already seriously overburdened this year without having to spend even more time voting on poorly executed governance actions. This action is unconstitutional out of the gate for not having an immutable metadata anchor link. It uses a standard GitHub url which could have been easily resolved by using a GitHub permalink. It also does not follow the CIP-108 standard of using GitHub markdown styling which has led to improper rendering of HTML tags on governance explorers. We have test networks explicitly for this purpose, with Preprod having recently lowered the govAction deposit amount to allow better access for testing govAction submissions. With a 100,000 ada deposit that has real world value, and often tax event implications, I find it hard to understand why more care is not taken with some proposals.

I vote YES on the treasury withdrawal “IO: Hydra” (4f6e5df9a6e14bd49e406e2bbb0d108b3be2be64b9569b930053a0c1eebe0d47#0).

This appears to have much broader community support having been unbundled from the Midgard proposal and resubmitted following feedback. I have noted builder DReps who have worked hands on with Hydra already are also in support which demonstrates that the value perceived is real and not just suggested in the proposal text itself. With my limited exposure to Hydra being that of the Hydra Doom demo, Hydra events at the Cardano Summit 2025 and most recently the Hydra Voting platform, I look forward to seeing the Mainnet use cases expand.

I vote YES on the hard fork initiation action titled “Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)” (fdd468da5cc4ac8431dcd7e2b3211666c73bc229f85879469f67f1d9d51d344d#0). This vote is submitted as both SPO and DRep and can be found in the same transaction.

I had wanted to hold off on voting until after the epoch boundary on June 28, 2026, and vote in epoch 640 as it has been my personal preference that this action not ratify on June 28, causing an enactment on July 3. Why? The July 3 epoch boundary lands on a Friday, late for UTC time zones and right before a major US holiday on July 4. Yes, we have had upgrades land close to major holidays before and this is an intra-era upgrade and so should have little-to-no breaking changes. However, given all of the headlines that Cardano has had to contend with recently, I’d much rather see this hard fork ratify on July 3 with an enactment on July 8 when we can guarantee more hands on deck to resolve any potential issues. They say, “don’t push to production on Friday”, it probably should count for hard forks too.

With that said, I do want to vote YES. This hard fork has been many months in the making, with Plutus Cost Model updates and hard fork initiation actions having passed through SanchoNet, Preview and Preprod test networks over the months of April, May and June.

Readiness is now looking strong. 87% of block production for this epoch, at time of writing, has been on node version 11. This satisfies the HARDFORK-04 constitutional guardrail of “At least 85% of stake pools by active stake should have upgraded to a Cardano Blockchain node version that is capable of processing the rules associated with the new protocol version”. This week has also seen massive progress from exchanges, with 77.37% readiness by liquidity being reported.

I have conceded to submitting my vote this epoch as there is a non-zero chance that this ratifies while I am away from my computer later today and the ledger does not care about our individual preferences, therefore this is submitted now to maintain my voting record. My voting weight certainly is not of any size to sway things one way or another, especially as a sub-1M SPO.

I vote YES on the treasury withdrawal action titled “Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2027” (17e43ffe4b2e0df1787d54f21ac66643c74abb131a326272fceecbdbbdd0d3fc#0).

This is a revised proposal from an earlier submission (af15a6627176f13be28100d7aa96a40f103f63c98e553869e38ab135ff4292cd#0) which reduces scope to focus on; Peras v1, History Expiry and Conformance Testing. As the only funding option on the table to get Peras over the line, I am voting YES on this proposal. It is an update that has been long discussed and it is time to finally see it reach Mainnet.

I vote YES on the proposal “5am.earth Trust Layer Targeting Vision 2030 KPIs“ (aaa6d9ccb72639c77db46b73bec2eaff9e5fcdfa04909cf1a0f7855a4d31485a#0).

According to the Transaction Leaderboard on Cardano.org (https://cardano.org/apps/leaderboard/) this project is already ranking among the top 10-15 on-chain activity drivers with 10,215 transactions over the past 30 days (as of 2026-06-18). This transaction count would also place it top 20 for the past year, although I am not sure why the site does not reflect this.

If Cardano as an ecosystem keeps funding infrastructure while denying any transaction generating project any support to grow here then it will build itself into oblivion. The community on X recently marked the 100,000+ transaction milestone of the Trivolve Forensic Management System (https://x.com/trivolvetech/status/2064732150935560238). A project that was made possible thanks to Catalyst funding, demonstrating what can be possible when we give real world adoption a chance.

I have read and understand some of the concerns from other DReps regarding this proposal but I feel signalling that Cardano is open for business and willing to support meaningful transaction generating projects is of much greater value in this instance than continuing to shun anyone attempting to build something here.

I vote YES on the proposal “Rare Evo and Dev Gov Day 2026: Cardano Title Sponsorship” (3f4b022c9913d52f9f39a8c82a1b9ebe5143fb745f3531f9366c7268bf9b9ce4#0).

Similar to my 5am.earth rationale, we cannot continue to build, build, build, without any marketing. Cardano already suffers from a chronic perception problem and hiding behind “fiscal responsibility” to vote down every growth and marketing effort while approving hundreds of millions for infrastructure is going to leave us all in a cathedral with no windows or doors.

Rare Evo began as a Cardano event. When the wider ecosystem still tried to shun Cardano, Rare Evo helped put it on the map. It eventually growing into a multi-chain event then gave the Cardano ecosystem exposure to the wider market. We can sit here and nitpick over the value of Summits and conferences like this but you honestly cannot put a value on the importance of in-person events. As someone who began a stake pool in rural UK, an ada holder since 2018, I probably wouldn’t still be in this ecosystem if it was not for the friendships and working relationships forged through in-person events. They are so important. If no one knows we are here, what are we even doing.

The proposal “Eternl: Path to Sustainability (2026-2027)” (9a020ea7a6a0d813ff08c92bd8300b26077ae69a4b827c4d432ac665120325d7#0) has already been deemed unconstitutional by 4/7 CC members and has subsequently been resubmitted by the proposers (fbb8d1a4a8d6b62f8cd706944a0582b884c2b90187b8fada7953d5c6a33eb5a7#0). Therefore, I vote NO in this instance. I will review the v2 submission and submit my vote with more detailed rationale there.

I vote ABSTAIN on the Treasury Withdrawal action titled “Cardano Summit 2026 and TOKEN2049 Singapore” (bd91fa7ea9b4e09f76cbde3abb0b564ffc60b27e18af464ccec9bef9c718d087#0).

This proposal has long since been rejected by the community in this format and there is already a revised proposal submitted on-chain for the Summit 2026 section previously bundled with Token2049 in this proposal.

I choose to ABSTAIN on this proposal as a DRep and a recipient of Cardano Foundation delegation. While I have voting autonomy and in no way influenced to vote one way or another, I feel that it is the right thing to do in this situation. CF delegation currently accounts for 96.65% of my voting power for which I am most grateful. I am also voting abstain due to this proposal having been resubmitted in some form already, at least with regards to the Cardano Summit 2026 element.

I would still like to take a moment to acknowledge the importance of having a Summit event, in light of some comments that I have read online. I have been fortunate enough to be able to attend the last 2 flagship events, and before that always made the effort to attend my regional satellite event in London in 2022 and 2024. Having that space to network and connect face to face has been invaluable in my experience within this ecosystem. I could even go so far as to say that I have recently found myself “full-time Cardano”, in large part to being able to attend a Summit event and meet the right people face to face and make a good enough impression that otherwise might not have been possible in the busy world that we exist in day to day, inside or outside of this industry.

I am happy to see that the Summit 2026 proposal has been revised and resubmitted following community feedback and look forward to reading it and catching up on the recently held X Space before voting and providing my feedback on it.

I vote YES on the Treasury Withdrawal action titled “Pebble + Gerolamo - HLabs 2026 Budget” (b11527fbcdc9d41e8f497de64a029a18673a5eefc413718459046f0b7a1a6656#0).

I have taken my time with voting on this proposal in an attempt to understand its place among other recent alternative node proposals and the community sentiment for or against it. It is clear that there is currently strong community support for this proposal and it is now close to passing with just a few hours left until the end of the epoch.

While the Amaru and Dingo proposals position themselves as fully functional (block producer capable) alternate nodes to the current Haskell node, this proposal offers a different target market at this stage of its development. Instead, it positions itself as “a complementary implementation focused on browser light node and data-node use cases, not a replacement for block-producing nodes yet”. Providing access to the Cardano blockchain through another programming language, Typescript, in addition to the Rust and Go implementations offered by Amaru and Dingo respectively. Widening developer access to the Cardano blockchain and its data is vital to onboarding more developers to build a greater array of applications on top of Cardano.

No, we probably shouldn’t fund every single alternate programming language proposal that comes around but a Rust, Go and Typescript set forms quite a big trident to land a new wave of developers interested in Cardano, across web3 and web2 ecosystems. It’s time to finally put to bed the old “nobody uses Haskell” narrative. It gave us the secure base, now it’s time to build on it with a variety of toolkits and see what’s possible.

I vote YES on the Info Action titled “Approve Cardano Foundation as New Managing Entity of Project Catalyst” (b518efa466593906ab388f978b3695449809aacdf28d2aaf4eb5ba16b3c24a1e#0).

This action appears to seek approval for a transfer of stewardship of the current Catalyst programme from IOG to the Cardano Foundation (CF). Where the CF will ensure the continuity of operations pertaining to ongoing Funds 10-14, while ensuring the returning of funds allocated for Funds 15-16 to the Treasury.

It does not outline any future plans for the future of the Catalyst programme or any potential replacements at this stage. It simply seeks to ensure that the administration of in-flight proposals is handled correctly while returning Treasury Withdrawals intended for the administration of uninitiated Funds 15 and 16 to the Treasury. I believe this to be the correct move in this instance as the Cardano community voted for IOG to run Catalyst in 2025 and not the CF and so returning the funds while attempting to form any kind of replacement programme proposal for the 2026 budget cycle seems prudent. Ensuring that those funding rounds that are already in in-flight are able to be administered to their rightful conclusions also appears to be the professional thing to do in this situation.

I vote ABSTAIN on the Treasury Withdrawal action titled “Cardano Defi Liquidity Budget - Withdrawal 1” (e5c4d7ebaad03ac127ec19a286605a188d6fea1c54e075c619ca6993b7fa9fd1#0).

I previously voted abstain on the original budget info action submitted for this project in 2025 under the previous NCL. I opted to abstain that time because although the intention behind it means well and sounds good, I was unconvinced that it would ultimately have the impact that it desired to have. This coupled with the fact that there are far more educated people on the topic than myself I did not feel comfortable voting no outright from a position that may not fully understand all the intricacies of the DeFi market.

I still can’t help but be reminded of the Cardano Summit 2024 panel “Does Liquidity Bring Users Or Do Users Bring Liquidity” where one of the members of the panel said that in order to bring attention to Cardano, it was “not a marketing issue but a perception issue”. (https://youtu.be/z1nw7munfXY) My concern remains that we could end up deploying Treasury funds to boost stable coin liquidity on Cardano “from within” but if the overall perception of Cardano across the wider crypto space remains, those users still are not going to come.

Cardano Whale was right, it is far stronger to fight from a position in the top 10-15 on Coinmarketcap than it is from 20-25+ and if we keep travelling on this trajectory, we could have all the liquidity in the world and it would still be irrelevant without the users. I chose to put my money on Cardano for its’ robustness and security, built on formal methods research. I remain here because I still believe that it has the best foundations. I have not lost funds to extortionate fees, I appreciate the determinism of transactions, I have not lost funds countless hacks. It’s a system open enough that someone like me, 5 years ago, with no Linux knowledge was able to build a stake pool on a testnet and grow along with this ecosystem. I have learned skills I never thought possible of myself since 2018, I couldn’t imagine achieving this in another ecosystem. It is frustrating to continue to see these positives not taken seriously from the outside, or frankly even marketed that much from the inside these days. It’s good to see the Cardano 2030 Vision finally highlight “Cardano is the most secure, reliable and censorship-resistant blockchain for mission critical applications to power economies and societies of the future”. This is the perception we need and I fear simply increasing liquidity at the detriment to our own Treasury will still be viewed as an attempt at “faking the numbers” by those from outside the ecosystem, not bring the desired users and leave us worse off than had we deployed that capital into other ventures.

In conclusion, I choose to continue to vote ABSTAIN because as much as I would like this project have the impact that it wants to have, I ultimately don’t believe it will, and so am unable to commit to a yes or a no vote at this time.

I vote YES on the Treasury Withdrawal action titled “Cardano x Draper Dragon: Orion Fund”. (8807e3cee3be5647742c329c1dea242f0c1c29b8ad050e15169e3b0302fcbfd6#0).

Although seemingly a big ask early on in the 2026 budget and net change limit period this is a very thorough and professionally written proposal and reflects an approach to governance action preparedness that has largely been lacking to date. Which is also why it is becoming increasingly important to consider a proposal such as this. A professional investment entity from outside of the Cardano ecosystem sends a strong signal to the wider space that Cardano is here, is open for business and is worth another look. As outlined previously in my DeFi Liquidity proposal rationales, Cardano has long struggled from a perception problem and I believe that should this proposal be successful, it will begin to finally turn the tide on that perception.

On the flip side of this, internally, there has been a growing perception of Cardano becoming more plutocracy and less meritocracy, with the same teams getting repeated funding, the same developers getting spread too thin across too many projects and with some bulk treasury proposals last year hard to follow the inputs and the outputs. Having an outside entity with investment experience looking at the ecosystem with fresh eyes and bringing more integrity, structure and accountability to funded projects can all help foster a sense that Cardano is a serious place for business.

If this project can be successful, highlighting Cardano as a serious place to build, an ecosystem worth investing in and all the while facilitating returns to the treasury that could help increase its sustainability, it has to be worth a shot. This has become even more important with the recent Catalyst situation and the uncertainty around any future ecosystem funding vehicle to replace it.

I vote YES on the Info Action titled “Cardano Budget Process Framework (facilitated by Intersect)” (e9693ed6b6465b2b46daaf641486a12b4b2946081634b5967b9d98897b0598fa#0).

It is an Info Action that seeks to outline a formal description of the Intersect Budget Process Framework for 2026 and future cycles until otherwise amended, administered by Intersect. As the rationale section states, this proposed framework is offered “to facilitate an ecosystem budget process for 2026”. The operative word here being “an” and not “the”. A singular process and not the definitive process. This leaves room for other governance actors to operate outside of the process outlined in this proposal, as should be their prerogative in a truly open and decentralised system.

While I understand concerns expressed regarding the phrasing of the NCL utilisation in Stage 3 of the proposal, namely that “Proposals will then be allocated in rank order, up to the available Net Change Limit (NCL)” I feel that there is a level of misunderstanding here. At first glance it does sound as though this particular Framework outlined here intends to hoover up the entirety of the remaining NCL, I think it is more of a case of unfortunate wording. It outlines the limit but fails to explain the likelihood of that much funding being approved. It could very well be the case that only 50% of the NCL gets utilised, in which case, this entire statement is redundant. I feel it has been pre-emptively included to avoid “what if more than the NCL gets approved” questions rather than offering the likelihood of that actually happening as a counterpoint.

I think this process is an improvement upon the process executed by Intersect in 2025 and does honestly seek to reduce procedural ambiguity and increase accountability, both of the proposers and of Intersect as an administrator. With a number of Treasury Withdrawal actions having been submitted in 2026 already, it does demonstrate that projects are not tied to only applying through the proposed Intersect Budget Framework.

I vote YES on the treasury withdrawal proposal “Dingo: a Production-Grade Block Producer in Go by Blink Labs” (gov_action17dfgtkeufcy945e3ssanqpmn09ft3gezhvepvvg7msmlmaz260dqqjtsmpe).

It is refreshing to see a continued return to detailed, well-composed governance action proposals, backed by numerous supporting links, after a recent drop in proposal quality. The Blink Labs team has a history of developing open source software for the Cardano ecosystem and are seeking funding for the continued development of a Cardano node written in the Go programming language.

I have already seen some comments like “no use case” and “a hobby project” from early voting DReps and so did some digging into current applications using Go in the wider world today. I knew IPFS was built on Go having installed it on a server at home already but beyond that I hadn’t quite appreciated the scale of its use in cloud infrastructure and distributed systems. Ethereum's primary execution node client Geth (short for Go Ethereum) accounts for ~66% of the Ethereum networks execution layer nodes as of October 2025 (having held a previous high of ~85%), while Go is also utilised across the Cosmos SDK, Docker and Kubernetes, and Hyperledger Fabric to name but a few instances. Its wide application across cloud computing, microservices and DevOps tools is supported by a global community of ~5 million+ developers. Investing in a Go node would not be merely funding a “hobby project”, it would be a strategic investment in opening Cardano up to a large developer community, predominantly in enterprise and cloud infrastructure fields.

This doesn’t appear to simply be a case of a team looking to cash in on a potential “node diversity goldrush”, coming so soon after the recent Amaru node proposal, they have a track record of work and delivery in the Cardano ecosystem and operate with a dedication to open source practices. While some DReps have expressed concerns regarding some of the quoted FTE rates within this proposal, it does feel like it could be an acceptable trade-off for the potential upside that a successful Go node implementation could bring by opening the Cardano ecosystem up to a much wider developer talent pool and the wider cloud computing/distributed systems space.

I have also seen some comments along the lines of “not necessary, everyone will use the Rust node”. This is also short-sighted. Funding node diversity to reduce the single node client risk to then all move to that same new client would be counter-intuitive to the intended decentralisation effort. Having a third node client here would be more beneficial to that end, not detrimental. The event of November 2025 highlighted the need for greater node diversity, now more than ever.

While a largely well written and documented proposal, it is worth noting for a moment that the Constitutionality Checklist does contain some errors. This practice of self-awareness has been much welcomed as governance progressed through its first year as it helped reduce bad proposals being submitted. Unfortunately, although stating that the checklist included here follows Constitution 2.4, it actually utlises an older template from Pragma that has not yet been updated since the previous Constitution (https://github.com/pragma-org/mnemos/blob/3402a6f12ffb042783112eeb5d3f30ae4f3965d4/BudgetInfoActionProposalTemplate.md) and as a result references incorrect Constitution articles within the proposal. While not a deal breaker here as a “Constitutionality Checklist” is largely an exercise in “self-awareness” and ultimately it is the Constitutional Committee that decides what is and what isn’t constitutional, it is an unfortunate blemish on what was otherwise a well put together proposal document. I have reached out to the proposer and it has been confirmed that the template used will be updated to reflect the new relevant sections of the Constitution, namely Article II Sections 6 & 7, for anyone else seeking to reference the template in the future.

I vote YES on the treasury withdrawal proposal “Amaru Treasury Withdrawal 2026” (gov_action19uhuy5uame2s60yrh6n8cyds8ps5q7tkh05dqlzmpcfy429p9w4qq5ll3g0).

It is great to see a return to professional, detailed and well-documented governance actions. This is a thorough proposal that outlines a new treasury withdrawal request as well as a detailed retrospective from the previous year of treasury funding. The Amaru team have acted with transparency and integrity while in receipt of treasury funds previously and have set a high standard that I imagine the community will soon hold other treasury proposals too, should other teams seek to apply for continued treasury funding, having received some in the past already. The end of the first Amaru treasury funding period culminated in the Amaru team returning 920,400 ada to the treasury prior to the submission of this proposal.

The event of November 2025 highlighted the importance and urgent need for node client diversity in the Cardano ecosystem and so far the Amaru node development appears to be the best shot at achieving this in a short to medium term time frame. The security risks of relying on a single node client have never been more evident to the Cardano ecosystem since November 2025, a situation where node version diversity may have saved the network from a catastrophic event. Node client diversity would help strengthen network security and resilience. Yes, there are trade-offs and it can make upgrades more complex in the future having to cater to multiple different node clients but having to choose between that and a potential single point of failure is a point where I would choose resilience over convenience.

The physical Amaru Pi node examples at the Cardano Summit were a nice touch, although sad to have missed out on one myself, they provided a great way to showcase a tangible output from a treasury funded project. While I appreciate that a lot of treasury funding goes toward research and tooling that may often feel abstract to end users of Cardano, tangible results can contribute greatly to ecosystem participants comprehending funding outcomes better.

Keep up the great work.

I am voting ABSTAIN on the governance action to set a “Net Change Limit of 300 Million ADA for Epochs 613–713” (gov_action1wwjwkg2g0qwr0mehey9r8gwn6qz3r28wl6wdl2s75kfmpy8j87tqqtft9tp).

As much as I would like to have voted YES on this proposal, I am choosing to vote ABSTAIN as a YES vote would validate the quality of the proposal submission. When compared side by side to the previous 350 million ada NCL proposal it lacks the detail and structure of the previous proposal. While it may be argued that this is simply setting a socially agreed off-chain parameter for Constitutional purposes, the quality of governance actions recently has taken a dip and voting YES here feels like it would be a validation of this standard and perpetuate the decline in quality.

The previous 350 million ada proposal provided supporting links that included “Treasury Inflows in 2025 data”, and a “Data Model”, as well as clearly outlining a proposed “ratification methodology” to account for inconsistencies in reporting across explorers. In comparison, the brevity of this proposal feels reactionary following the passing of the 350 million ada proposal and an attempt at achieving another quick win for the proposer, following the recent Constitution update, by submitting this proposal which is popular in sentiment but lacking in detail.

Reading through rationales that have been provided to date there does appear to be some confusion among DReps. I have read many that either believe that the previous NCL proposal failed to pass, or that they favoured a lower NCL.

The former stems from confusion regarding the Constitutional Committee vote on the previous proposal. With 3 absent votes, some explorers currently show the proposal as one vote shy of “approval”. An unfortunate side effect of CC participation rates and lack of clarity regarding when voting is required. Personally, as a former ICC member, I would never have failed to submit a vote and record feedback in a rationale and so the recent participation slump is frustrating to see, especially as someone who entered the past 2 CC election events as part of consortiums that were overlooked. That said, the Constitution states that an NCL requires >50% DRep voting stake approval, and so it is my understanding that the previous proposal did indeed pass and is currently active.

The latter, favouring a lower NCL, is equally perplexing to me (in this context). While I appreciate that voting NO to both 350 million and 300 million ada NCL proposals signals opposition to both and a desire for an even lower NCL, the fact of the matter is that the 350 million ada NCL is now in effect. Voting NO in favour of a lower proposal, while rejecting a proposal that is lower than the current one in the meantime feels somewhat counter-intuitive. A NO vote here is essentially reinforcing the previous 350 million ada NCL at this point. For this reason, I would have voted YES had the proposal been put together to a higher standard.

I would still like to see some in-depth evaluation and review of the first year of treasury spend before jumping straight into another funding round. I appreciate that a number of proposals focussed on research and tooling which might be largely abstract from the everyday user but so far, the only change to my day-to-day interactions on Cardano that has felt tangible as an end user are the vast number of updates released by Cexplorer, which have been great to see. I am referring to the first bulk budget votes here and appreciate that the recent arrival of USDCx is also a massive change to end-user experience on the chain.

Until the Pentad swooped in at the eleventh hour, the community had voted to approve 277/350 million of the NCL for year one. With one year of on-chain spend history, it will likely be even harder for the same actors to seek continued funding without demonstrable results and so I do still feel that a 300 million ada NCL is workable if approved.

Although only DRep votes are counted for NCL proposal results, the ledger nonetheless allows SPOs to vote on all info actions. An SPO vote is attached to this vote transaction to maintain the pool voting record.

I am voting NO on this Parameter Update proposal” Reduce minimum Constitutional Committee size (committeeMinSize) from 7 to 5” (dfdac5921ab657241fce58583d61bef59a369e01d2ba78191d6df6632a07fdfd#0). I have many thoughts on this proposal and the wider state of Cardano governance recently and that particular rationale was becoming extensive. As it stands now though, the future of this proposal is unclear as it is about to become null and void and so this vote is submitted in urgency to maintain voting record.

What? Exactly. When certain governance action types are submitted, they are required to reference the previously enacted action of that type. The four types are Update Committee, Update Constitution, Hard Fork and Parameter Update. The previous Parameter Update action was “Plutus V3 Cost Model Parameter Changes Prior to Chang#2” (b2a591ac219ce6dcca5847e0248015209c7cb0436aa6bd6863d0c1f152a60bc5#0) way back in November 2024.

This proposal was submitted at the same time as another existing Parameter Update proposal, “Increase Transaction and Block Memory Units (Part 1 of 2)” (c21b00f90f18fce4003edf42b0b0d455126e01c946e80cc5341a9f9750caf795#0). It referenced the same previously enacted governance action, which means that there would be a conflict if both were to pass as the earliest one would render the later one invalid. The newly enacted parameter update becomes the new “prevGovActionId”, meaning that the second proposal then have an incorrect reference.

Could this have been avoided? Yes. First witnessed on SanchoNet during simultaneous Update Committee actions, and then shortly after on mainnet, someone can submit a second proposal of the same type, if they pre-emptively reference the currently active proposal. There remains a risk here in the event that the earlier live action could still fail to pass, in which case the later one would too as it would once again be referencing an action that wasn’t enacted.

What this situation highlights is, the need for greater communication and co-ordination when it comes to governance action proposals with on-chain effects. It may be okay to throw as many Info Actions out there as you like at any one time, they have no on-chain effects. While we exist in a permissionless system and anyone is free to submit their own actions, if they have access to the required deposits, Update Committee, Update Constitution, Hard Forks and Parameter Updates, are usually submitted after much co-ordination, effort and research. They are often timed in order to avoid issues such as this. This year alone we have two Mem Unit updates, a Plutus Cost Model update and a Hard Fork action in the pipeline, that I know of. To have an individual essentially running around and playing with all of the governance knobs and dials that they can get their hands on at the moment is, frankly, counter-productive. The Parameter and Hard Fork committees may be put on edge unnecessarily now, unsure of whether their extensively co-ordinated and timed proposals now run the risk of colliding with a proposal from out of nowhere.

This is a theme that has continued since the recent Constitution update. For those that missed the recording of the Technical Steering Committee meeting dated January 21, 2026, one aspect that was overlooked in the rewriting of the Constitution was that changing the wording of the “PARAM-04a” guardrail. It was changed from “3 months” to “90 days” and as a result, the guardrail name should have also changed to “PARAM-04b” to highlight this amendment as per the Parameter Committee guidelines. They were not consulted, this did not happen and they have been left reasonably perplexed at the whole process. (Source: https://youtu.be/_jS-egZUH4c?t=3118).

I bring all of this up because it highlights a pattern of behaviour heading into an already busy Parameter Update period this year that really requires much better co-ordination going forward. Cardano is an ecosystem, not an individual.

I vote ABSTAIN on the Treasury Withdrawal proposal for “Cardano DeFi Liquidity Budget - Withdrawal 1” (gov_action1fvgw27fjpr9c7g582mszzyez0jgkqgjgatzdnyngrg8wwc9kcn3qqxtz8r7) following the recent enactment of the Cardano Blockchain Ecosystem Constitution v2.4.

Article II, Section 6, part 1 states that a governance action proposal format “shall include a URL hosting a document that outlines additional context for the proposed governance action, and the hash of this document. The document hosted by such a URL shall be immutable and incapable of being altered after submission, and the content of every on-chain Governance Action must be identical to the final off-chain version of the proposed action.” Whereas under the previous Constitution, immutable metadata was a “nice to have” or “recommended standard”, the newly enacted Constitution makes it mandatory. While it is reassuring to see all of the supporting links provided using the GitHub permalink format, the main rationale metadata is a standard GitHub url link (likely due to a GitHub permalink possibly breaking the --anchor-url character limit). As such I anticipate the CC deeming this one unconstitutional as a result and so I will abstain from spending further time on this proposal until it is re-submitted in-line with the newly enacted Constitution.

I vote to ABSTAIN on the proposal for the “Net Change Limit (Epoch 613 to Epoch 713)” (gov_action1m3xx08yv788vfxqh6nfvrjtvmqpwezsy0ggaczctkyjmttc2wmxsq4jsr7q) as some of the proposal text now requires an amendment… following a constitutional amendment.

Under the rationale section titled “Application and Compliance”, the proposal states that “This limit shall be applied in assessing treasury withdrawal actions to ensure compliance with Article IV of the Cardano Constitution and the Treasury Withdrawal Guardrails specified in Appendix I.”. Following the recent enactment of the Cardano Blockchain Ecosystem Constitution v2.4, this is no longer correct as “Article IV” now covers the “Amendment Process” and not “The Cardano Blockchain Ecosystem Budget” as the previous Constitution did. This, once again, highlights the perils of introducing changes to such a central piece of the Cardano governance system without proper co-ordination or consultation of wider governance participants before submitting proposals live on mainnet.

Regarding the intention of the proposal, to set a new Net Change Limit (NCL) of 350 million ada for a period of approximately 16 months and 20 days, I have conflicting views currently. My voting history shows that I voted NO to proposals of a 300 million ada and a 350 million ada during the setting of the first NCL, while I did vote YES for the proposal for a 200 million ada NCL. My concerns then were justified, while the NCL was billed as a “spending cap, not a spending target”, it became just that. To the extent that we found ourselves in December 2025 frantically rushing governance, on a chain renowned for is methodical approach, just so that the founding entities could “hoover up” the remainder of the NCL before it expired. DReps approved a 70 million ada budget and withdrawal in record time, equating to 20% of the entire NCL for that period. Not only that, we even voted to extend the NCL in order to accommodate the resultant Treasury Withdrawal due to lack of foresight by the “Pentad” with the timing of their submissions.

Now, I am also a realist and I have to objectively assess my previous stance with present day reality. The first NCL was often quoted using an ada price of $0.50 and I judged it accordingly. If I use my basis of 200 million ada and account for a present-day price of $0.36 per ada, it would require 278 million ada to account for the decline in ada price. Secondly, accounting for this proposal being for 16 months and 20 days as opposed to one calendar year, that would equate to a total of 385 million ada. Therefore, a proposal of 350 million ada for this period does on paper translate to a reduction when stood up against the previous NCL.

With that said, I really do think that we should take a moment to reassess. We speed run governance in December 2025 with little pause for review following that frantic period. To just roll onto the next thing and exacerbate more spending when we’ve barely had chance to analyse the impact of the previous NCL cycle funding could be viewed as irresponsible. Yes, we have the Treasury Withdrawal votes to exercise that power but with the recent removal of the budget info action requirement from the Constitution, those lines too have just become a lot finer.

I vote to ABSTAIN on the proposal for the DeltaDeFi: Hydra Trading Infrastructure Budget (gov_action15ce4qnwug759939wqv782pvh6qg68khspg8kh02gmex99mcsytwqqqr7jkr) following the recent enactment of the Cardano Blockchain Ecosystem Constitution v2.4 (gov_action1jxne7hynfd7frcczwumd2eggps4kvy0msjztz9t0mutpy870ksgqqp6vp3p).

Budget Info Actions were a mandatory requirement under the previously active on-chain Constitution. Now that v2.4 has been enacted, there is no longer a requirement for Treasury Withdrawal proposals to have a previously approved Budget Info Action which now ultimately renders this proposal redundant, unfortunately for the proposers of this governance action who have no doubt committed time, effort and substantial funds in crafting and submitting this proposal. It also demonstrates the side effects of voting to enact changes to such a central piece of Cardano governance while processes and proposals are currently running in parallel.

At this stage it also looks highly unlikely to reach threshold, regardless of which way I vote and so I hope that the proposers take on any feedback that they have collected from DReps so far and apply it to any future proposals that they may submit. It is evident that they put a lot of time and effort in crafting this proposal and so I would like to also commend them on that.

I vote YES on the proposed protocol parameter update proposal to “Increase Transaction and Block Memory Units”. This is the first proposal of a two-step process to increase the parameter value as the desired value is currently a larger increase than the current Guardrail script will allow in one step.

This is a well written proposal and uses the correct parameter names as found both within the Constitution text and output from the on-chain query cardano-cli query protocol-parameters –mainnet. I raise this point as I have previously stated that I would vote NO to any parameter change proposal that does not adhere to the correct naming scheme as found in these two searches. The proposal also provides sufficient evidence of the historical discussions regarding the parameter change including, Cardano Forum posts of the Parameter Change Proposal PCP-003, public survey results, benchmarking results and outputs from both the Parameter Committee and Technical Sterring Committee. There has also been a progressive and phased rollout of the proposed update across both Preview and Prerpod testnets.

The proposal also contains a reversion plan, as mandated by the Constitution, and so I am comfortable voting YES knowing that if any unforeseen circumstances arise as a result of this change that it should not create too much of an issue with regards to reverting to the current values.

There has also been a progressive and phased rollout of the proposed update across both Preview and Prerpod testnets.

I vote YES in favour of naming the next Cardano hard fork after Max van Rossem. It has become community tradition to name hard fork events after prominent community contributors, with past hard forks named Vasil, Chang and Plomin.

I was fortunate enough to have briefly met Max in Argentina during the Constitutional Convention, there in his capacity as Delegate for the Dutch Cardano community. It was only after his passing that I learned of his many other contributions, as outlined in this proposal.

As one of three members who formed Cardano Constitutional Consortium (CCC), Max also ran for election in the first fully community-elected Constitutional Committee elections last year. Unfortunately, CCC placed ninth and just out of the top seven which were elected. As a member of Adara Consortium, who placed eight in that same election, we joined forces with the remaining members of the CCC to once again run in the recent Snap CC Election, this time as Phoenix Alliance. The naming and symbolism we put forth chosen in part as a way to try and honour Max’s legacy in some small way. Our consortium was once again unsuccessful in that election too and so I welcome another opportunity to honour Max’s legacy with a YES vote for this proposal.

I am voting NO to replace the Constitution with the proposed constitution v2.4 for the same reasons as outlined in previous votes which can be found in transaction hash 8474b8633cde93e34da9ee905b30a79158ec4cd6e41f24656f24d43a5fca902c from five months and four days ago, and 07c64c03ff524e8a76be9dad5df8c3a4b32c0e383ce611bd8aec118a8b791b4b from two months and fourteen days ago. The current Constitution has barely just turned twelve months old and here I am voting on proposed changes for the third time in six months. While I appreciate that the current Constitution identifies itself as a “living document” with future amendments encouraged when the community and ecosystem deem it necessary, it also isn’t an iOS update.

There is a reason that updating the constitution has such a high threshold of 75% and that it is because it is the most fundamental guiding document for Cardano governance. While amendments may be necessary, attempts to change it so often risks undermining the legitimacy of the document itself. Admittedly, one of these proposals has yet to pass but here we are, voting on it for the third time in six months and my timeline is currently filled with hurried calls to vote, daily callouts to large voting power DReps and unhappy posts when anyone dares to vote or comment negatively against the proposal. It begins to raise another question as to how much of this is for the benefit of the ecosystem and how much is for personal achievement at this point.

I have previously voted no on the grounds of the large number of changes at once and for the level of accessibility for the community to participate. I still feel that there are too many changes at once here and it feels as though this is a product of attempting to please everyone at once in order to get one of these proposals passed. The proposer has argued in favour of bulk changes because individual updates could risk voter fatigue and lower turnouts over time, yet here we are for the third time in six months trying to pass a bulk edit to the Constitution. A process which in itself is already wearing thin for some and highlights that constitutional updates should be agreed upon through iteration rather than attrition. If DReps start to vote yes in the hope that they don’t have to face yet another update constitution vote three months down the line, this would also undermine the legitimacy of any eventually approved update.

These are largely procedural issues rather than content issues but they are important as the process should be informing the content. I am not saying that any amendments should go through as vigorous a process as the current Constitution and while it has been argued that there has been large community input already and that the past governance actions form part of that process, where is the evidence included in this particular proposal? The proposal simply lists the constitution text changes and links to documentation showing those changes. There are no links to any collaborative documentation or attribution of changes made to those who have suggested the edits. I know at least one document exists as it has been shared on social media and it really should be linked in this proposal as part of the supporting links to demonstrate the level of community contribution. Consider the depth of supporting links in the proposal for the currently active Constitution (https://ipfs.blockfrost.dev/ipfs/bafkreiehcekhhsq34ccezwn46brg3euj6tbs4g4yjkav34ukqvbnzaya2a) in contrast to supporting links provided in this proposal (https://ipfs.blockfrost.dev/ipfs/bafkreigxpweqv2rnh7ajt5hzdq6gikogmaq3nbyof5uvdntc4hkg52ghqy). See also the level of supporting documentation of recorded community feedback for the “Cardano 2030” Info Action (gov_action18fd7jwa06fksmwumlcvlft8v4guvaa672qsp6xgenekvs4kmvcqsq8cqks4) also currently up for vote at the moment.

Another issue I have regarding the content of the proposal is the adherence to the Constitution Specification as outlined in CIP-120. There is at least one glaringly obvious instance where text does not conform to the 80-character per line limit as outlined in CIP-120. Article II, Section 7, item 4 “as a part of such funding request to cover the cost of periodic independent audits and the implementation of oversight metrics as to the use of such ada.” CIP-120 “aims to describe a standardized technical form for the Cardano Constitution to enhance the accessibility and safety of the document.” While only currently implemented by one governance tool, if this proposed constitution is to be around for a long-time, it would be beneficial to future-proof the text so that it is compatible with more governance tooling that may seek to implement this CIP going forward.

My reservations are largely procedural issues and I am left with questions regarding the evidence of the level of community collaboration. How many of the original Constitutional Delegates and Alternates have given feedback on this current proposal? How much interaction has taken place between the proposer and Intersect Civics Committee? I know there is at least one attempt to formalise an amendment process under the Civics Committee and while Intersect doesn’t have to be the sole arbiter of governance processes in a permissionless system, the Civics Committee is one current example of an attempt to at least define a constitutional amendment process. It should be noted that this is a (singular) process and not the (definitive) process currently being worked on by the Constitutional Amendment Process (CAP) Working Group.

I vote YES on the Info Action titled “Cardano 2030: Vision, Mission, Strategy Framework and KPIs”. The proposal provides detailed documentation as to the breadth and depth of community input that has gone into this proposal (which is in stark contrast to the absolute lack of it provided in the update constitution action also currently up for vote). Data collection methods have included workshops, focus groups, surveys and business calls, with outputs recorded and links provided at the outset of this proposal.

As an Info Action it has no on-chain impact and as with other items approved via Info Action, such as a Net Change Limit, it serves as more of a social construct than one enforceable on-chain. There is always the risk, or likelihood in this instance, that the agreed upon strategy will change over time as the technology and ecosystem itself evolves, therefore it is great to see the inclusion of immutable copies of this initial proposal which can serve as a reference point at such times when the strategy needs to be reviewed in the future.

While not perfect, this proposal does offer some much-needed direction for the ecosystem now that the original five eras of Cardano development are largely complete. I hope this proves as a useful starting point that can continue to be iterated upon as time goes on so that it can adapt to evolving technologies, broadening use cases and accommodate new participants in the ecosystem.

I am voting YES on the governance action to add an eighth Constitutional Committee (CC) member (eb8ef28ca80dbd9ced6f577f013bdfc64897d1f4e326beb37a50fb6b62c38ccd#0). This rationale is submitted as a combined DRep and SPO vote and will outline the reasons for a YES vote, as well as outlining some reservations/recommendations, before ending with a note of credit for the origin of the idea for submitting an update committee action prior to an existing one being ratified.

I vote YES in support of this governance action as someone who has advocated for adding more members above the committeeMinSize parameter, both during discussions at the Cardano Summit in Berlin in November 2025 and as an elected member of the Civics Committee. Adding additional CC members above committeeMinSize is the easiest solution to improve resilience and prevent a repeat of governance stalling should another member step down or become unable to carry out their duties as a CC member. Yes, lowering the committeeMinSize parameter is another available measure but as the Cardano Blockchain Ecosystem Constitution lists this parameter as “Critical to the Governance System” it requires a 3-month off-chain consultation period before an on-chain parameter update action can be submitted (PARAM-06a). I have confidence in the candidate put forth in this action, having met Christina Gianelloni in person at Cardano Summit events as well as having had a meeting during preliminary discussions around forming Adara Consortium in the previous CC election. These interactions demonstrated Christina’s belief in operating with the utmost transparency and integrity. In the absence of CC checks to this proposal I have also taken the measure of querying the on-chain action and the off-chain content. The hashes match, the action does indeed propose adding a single CC member until epoch 653 and leaves the threshold unchanged at 2/3.

I also commend the community-initiated submission of this governance action as another demonstration that Cardano governance is open to all ada holders and that update committee actions are not just the purview of institutions and that the action ratification itself can provide the mandate, just as well as a formal off-chain election process prior to submission may do.

I do however recognise some reservations and have some recommendations for future community-initiated proposals. First of all, the governance action rationale references the wrong parameter name, it references minCommitteeSize instead of committeeMinSize used both in the Constitution and output from a cardano-cli protocol-parameters query. Typos have been a constitutionality issue for CC members in the past, and it is worth noting in this instance as the CC does not have a vote in an update committee action, only DReps and SPOs. Secondly, the proposal is based on the candidate coming a close second in the recent CC Snap Election, which was single-choice only and not ranked-voting like the previous CC election. There is no knowing if the candidate put forth here would still have ranked second in the election, for example, if Curia was indeed voted top because of a preference for consortium candidates. Thirdly, the proposal assumes everyone knows who Christina is and would have benefitted greatly from providing some more background information for those DReps and SPOs that did not participate in the off-chain CC Snap Election facilitated by Intersect. If we consider that only about 10% of all registered DReps voted (or about 20% of ledger-recognised “active” DReps), not including more information for the remaining DReps and SPOs at the proposal stage could have a detrimental effect on the chances of ratification.

Finally, I would like to acknowledge the inspiration behind the timing of this update committee action. It was submitted prior to the on-chain ratification of the previous update committee action to install CC Snap Election winners, Cardano Curia, on to the Constitutional Committee. This is a clever way to save time by referencing the previous governance action id ahead of time, assuming that it passes. Each update committee action is required to reference the previous successful governance action using its id at the action creation stage. By submitting this action before the Curia proposal passed, it ensures that it would not pass if the Curia proposal did not, and also saves an epoch as opposed to waiting for actual ratification of the previous action. This technique first appeared on SanchoNet recently when there existed two update committee actions on-chain at the same time. Phoenix Alliance, a candidate in the CC Snap Election, had submitted an update committee action during the election period as a way to demonstrate to voters that they had the capabilities to carry out the role of CC member. A member of Tingvard (TECH pool) also wanted to test out something and submitted another update committee action at the same time but this time referencing the previous, not-yet-ratified Phoenix Alliance action, in anticipation of its ultimate passing because SanchoNet is very much there for testing and actions can pass much more easily than on mainnet. So, credit where credit is due, to TECH pool and their flexible thinking when it comes to timing the submission of governance actions that require a reference to previously enacted governance actions. Additionally, it is worth noting that Phoenix Alliance were the only candidates in the CC Snap Election that undertook the step of proving their ability to carry out the role by submitting credentials to SanchoNet, a measure I hope becomes a standard requirement for applicants prior to receiving candidate status approval in future elections.

Having voted YES on the associated budget info action I once again vote YES to this treasury withdrawal action for the Critical Integrations Budget. As stated in the vote on the budget info action, this renewed co-ordinated approach from the proposers of this action can help to move these integrations along more efficiently, in both time and money, by reducing any potential duplication of effort and spend that may occur if the entities continued to pursue these deals independently.

Additional checks to this proposal include, matching metadata hashes for the on-chain / off-chain content, author signatures provided here also match those provided at the budget info action stage and the on-chain requested amount also match that stated in the proposal. Although usually the remit of the Constitutional Committee, given their current state of being below committeeMinSize and the size of this treasury withdrawal request being 70 million ada, it pays to remain prudent.

The Net Change Limit (NCL) was established as more of a social contract rather than a limit hard coded into the ledger. There needs to be an agreed upon NCL active at the time of a treasury withdrawal in order for it to be deemed constitutional. With the current rush to pass the Critical Integrations Budget before the end of the agreed NCL for 2025, the date of the actual withdrawal was overlooked and would ultimately fall short by one epoch (at the earliest possibility) due to the associated budget info action running for its full six epoch govActionLifetime.

This is the first year of on-chain governance for Cardano and the first time a Net Change Limit has been agreed upon and run for its agreed upon term. Concerns over setting a precedent by simply extending it whenever we see fit instead of it being enforced as originally agreed upon are valid. It risks undermining the significance of having an NCL in the first place. Again, if this was proposed in order to facilitate a treasury withdrawal by anyone else other than the founding entities then I imagine it would have been met with much more scepticism than it has.

While I would have preferred to have voted ABSTAIN following these considerations, I also have to reconcile the fact that I have voted YES to Critical Integrations Budget, which cannot proceed without this proposed extension of the NCL. As a result, the current four governance actions on the table for voting are all now intertwined to the point where just one missing piece and this does not happen. It is a situation I am uneasy with but acknowledge that there is an overwhelming community consent for this to happen. I only hope that future NCL proposals are structured better so that we do not find ourselves, as an ecosystem, in a similar situation once again. Otherwise, we truly do risk undermining our own processes in the future.

This is a combined DRep/SPO rationale, while SPO votes are not socially considered with regards to net change limits, the ledger nonetheless allows SPOs to vote on all info actions. An SPO vote is submitted here to maintain the on-chain record, in the past this would reference the DRep vote transaction hash, but this is not possible when submitted in the same transaction.

I vote YES on the Critical Integrations Budget info action. I do so with some reservations regarding how the Cardano governance process currently being carried out at the end of 2025. After listening to the recent X Space held with the entities behind this proposal, I respect that a renewed, co-ordinated approach by Input Output, Cardano Foundation, Emurgo and Midnight Foundation with oversight from Intersect, can help prevent a duplication of effort. It’s great to finally see a mature approach to fixing the issues of missing integrations that have held the ecosystem back to date. If this is what it takes to finally get everyone working together and in turn saves both time and money by reducing the risks of duplicate effort and duplicate spend where multiple entities may have inadvertently sought the same deals independently previously, then that is a positive. Between this and conversations with delegators, I am voting YES at this time.

My reservations, for the record. While I appreciate that all of the critical integrations listed within this budget info action are desperately needed for the Cardano ecosystem, I am uneasy at the level of speedrunning of governance that appears to be happening at the close of 2025. With 72,968,493 ada of the currently agreed NCL for 2025 remaining, this budget proposal comes across as a last-minute move to hoover up the remaining NCL. I have always viewed the Net Change Limit as a spending cap and not a spending target.

If this proposal were put forth by anyone other than the founding entities, then I imagine it would be subject to much more scrutiny than it has been so far. What’s more concerning with regards to this speedrunning of governance is that the timing was miscalculated and we now have another info action requesting an NCL extension just to accommodate any treasury withdrawal that would be linked to this proposal.

As we are in the first year of on-chain governance I have so far adopted a “fool me once / fool me twice” approach whereby I am willing to consider voting “yes” in favour of founding entities having access to their sometimes exorbitant asks, in spite of poor delivery histories, because on-chain governance does finally put a name on treasury withdrawals and provides more accountability than we have had historically. With that in mind, if another similar proposal arrives during the next NCL and I am not happy with the progress made with the funds requested here, then I will simply vote “no”. It’s time to “put up or shut up” as the saying goes.

This is a combined DRep/SPO rationale, while SPO votes are not socially considered with regards to budget info actions, the ledger nonetheless allows SPOs to vote on all info actions. An SPO vote is submitted here to maintain the on-chain record, in the past this would reference the DRep vote transaction hash, but this is not possible when submitted in the same transaction.

I vote YES on the update committee governance action. As with the previous update committee governance action, Intersect helped facilitate an off-chain election via the Ekklesia platform to determine the candidate put forth here. I will continue to praise the Ekklesia platform for its accessibility to CLI and multisig DReps, a standard of login I still hope to one day see across the wider selection of Cardano governance tooling. DReps had time to vote one choice from a selection of five candidates and after a close outcome between the top two most voted candidates, Cardano Curia is the candidate being put forward here.

It is essential for the continuation of Cardano governance that a new Constitutional Committee member be installed as soon as possible after the retirement of the Cardano Atlantic Council resulted in the Committee falling below the committeeMinSize parameter of 7, as mandated by the ledger. As a competing candidate in this election, I acknowledge the votes of the DReps who participated and vote YES on this proposal.

In order to avoid a similar scenario in the future I would also support updating the CC with 1-2 more members soon so that the Committee size has a buffer between its’ committeeMinSize and its’ current operating size. I have advocated for this since the Cardano Summit in Berlin last month and will continue to whenever the topic arises. I understand calls to reduce the committeeMinSize in the future but this will take time as the Constitution lists it a parameter “Critical to the Governance System” and has certain time-bound requirements to it before an action can be submitted on-chain. Simply voting in more members is the quickest and easiest solution to this risk right now.

This is a combined rationale for the required SPO and DRep votes submitted simultaneously in this transaction.

Following on from my YES vote on the previous budget info action, I vote YES on the treasury withdrawal proposal for a 5 million ada loan to expand Cardano’s global listings. I appreciate that the proposers have taken on community feedback, enlisted the help of Intersect, and put forth a Board of Advisors to help administer the use of funds. This is the first time that a treasury withdrawal has been made with an expressed intention to repay the requested funds and as Cardano governance continues to evolve it is encouraging to see proposers experimenting with ways to make both Cardano governance and the treasury more sustainable.

I vote YES on the budget info action to reimburse the proposers of the Ikigai info action (59fd353253eb177e2104e8f23ea4c63e3d32ef95c7865d03e90d3884424dc1db#0) with the funds that were lost due to a bug that allowed an unregistered stake key to submit a governance action. As a result, the governance deposit was sent to the treasury and not returned the proposer. The anonymity of the author or this proposal does give a reason for pause, however, provided that any subsequent treasury withdrawal action identifies the same address as was used to submit the Ikigai info action (59fd353253eb177e2104e8f23ea4c63e3d32ef95c7865d03e90d3884424dc1db#0) then I see little reason to vote NO on this proposal.

I choose to vote ABSTAIN on this budget info action for Constitutional Committee compensation at this time. Having been one of the few people to have participated in all three arms of Cardano governance (SPO, DRep and ICC) I know the level of work that goes into being a member on the Constitutional Committee and absolutely agree that there should be some level of compensation for the work. Having completed a term on the Interim Constitutional Committee, as one of ten members chosen to fulfil the role of the Intersect seat, I can attest to amount of time and energy that it can take.

In my opinion, consortiums are the best option for CC seats, they offer greater resilience to outside influence and flexibility when one or more members are unable to be present for one reason or another. With that said, they also come with greater organisational requirements; each member does their own research, meetings have to be co-ordinated to discuss and debate findings, votes have to be taken, rationale documents prepared and votes submitted. All of this work is carried out, usually alongside full-time jobs and other commitments. During my tenure as a team of 8-10 members I can confirm that by the end of the ICC term, I was exhausted. To expect this work to continue uncompensated is unsustainable and I welcome the discussion on this topic that this proposal has brought to the forefront.

Despite these words, I have chosen to vote ABSTAIN at this time due to the lack of clarity around the numbers in the budget info action and the lack of socialisation beforehand. I think that the submission caught the community by surprise and although cost breakdowns have been provided on social channels, I feel that this proposal would have been stronger for having had them included within the text.

It has been sad to hear of the Cardano Atlantic Council’s plans to retire their seat as a result of the community response to this proposal but I thank them for their services to date and for bringing this topic to the forefront of conversation once again.

I am voting NO on the Cardano Blockchain Ecosystem Constitution v2.3 proposal for many of the same reasons laid out in my previous vote on v2.0 which can be found at https://raw.githubusercontent.com/hephy-io/mainnet/refs/heads/main/drep_rationales/GA063-constitution-v2.jsonld (or transaction hash: 8474b8633cde93e34da9ee905b30a79158ec4cd6e41f24656f24d43a5fca902c).

In a nutshell, I feel that it is too many changes at once and I would still like to see more representation. The Constitution is still not even 12 months old at this point and while it has provisions for amendments and is to be considered a “living document” I still find myself questioning at what point an amendment becomes a full-scale rewrite. It has taken some time for Cardano governance processes to find their feet and my concern is that such large-scale changes could lead to more confusion due to the number of changes. If any particular article or section is causing a common pain point for the Cardano governance process and/or ecosystem progress, submit an amendment to just fix that, work on one area at a time. Large scale rewrites risk things being missed or overlooked in order to satisfy one particular pain point elsewhere.

I am also cautious regarding the approach whereby feedback is requested and urgent deadlines are given on social channels. I appreciate the desire to want to keep the conversation at the forefront of Cardano governance but putting time limits and rushing feedback in this manner with posts like, “I am still accepting feedback until MONTH DAY at HH:MM UTC”, almost makes this update process feel more personal rather than in the greater public interest. All ada holders should have the opportunity to have their voice heard and my concern is for those ada holders who are not active on social channels like X who may be being left out by this approach so far, despite the level of feedback that has been collected from active X accounts.

I see that there is currently work underway on formalising a Constitutional Amendment process and I am more inclined to wait and see the outcomes of this endeavour before entertaining any further update constitution proposals with this number of changes.

I vote YES on the info action “Securing Generic Top-Level Domains for the Cardano Ecosystem” and submit this rationale for both SPO and DRep votes. Both roles are allowed to vote on info actions and in this particular instance community sentiment has been requested from both by the Cardano Foundation.

I support the proposed move to secure generic Top-Level Domains (gTLD) for the Cardano ecosystem. This rationale will outline the importance and priority of this proposal and remind anyone reading it why this proposal has been submitted for feedback.

The last gTLD application window opened in 2012 when the application window ran from 12 January 2012, until 12 April 2012, although a system glitch led to a temporary shutdown and a subsequent re-opening of the application system until 30 May 2012. During which time over 1,900 applications were received.

This will be the first time in the “crypto era” that an application window has been opened and I respect the proposal to pursue securing gTLDs for the Cardano ecosystem. It is highly likely that there will be a proliferation of applications from crypto companies and projects and we will likely see “.btc”, “.eth”, “.xrp”, “.sol”, etc, etc applications being made. It has been 13 years since the last application window and who knows how long it could be until the next one. Therefore, there is a sense of urgency here or we risk missing out and potentially finding ourselves in a situation 2-5 years down the line asking, “why don’t we have “.ada” domains like other protocols and projects?”. Too often we lament that the Cardano ecosystem is left out or missed out on new developments that the wider crypto space capitalised on, let’s not let this become another. I am happy to see the Cardano Foundation and their external advisors who are taking the initiative on this now. You can guarantee that if they didn’t, it would be yet another thing added to the list that this community likes to hold up as having been the CF’s responsibility but not taken, which is why I find the few “CF should be doing other things” responses that I have seen so far somewhat baffling.

It's okay to suggest that Intersect should be the stewards of any Cardano gTLD instead of the Cardano Foundation but you have to ask yourself who has put the work in already, what happens if Intersect doesn’t secure funding in 2-5 years’ time, who then takes over stewardship and how? As for concerns over the gatekeeping of address registrations, it is my understanding that registries that operate and maintain a specific gTLD are still regulated by ICANN.

Finally, for those asking why the info action is even necessary here. The info action was originally meant for the very purpose of collecting community feedback and sentiment on-chain, it has been somewhat forgotten about with so many budget info actions being submitted in 2025. It is also my understanding that the feedback from this info action will be used as part of the application process to show ICANN the level of community support and demand for securing gTLDs such a “.ada” and “.cardano”. It is also worth reiterating that this is an info action and not a budget info action and that the Cardano Foundation has stated that this is an initiative for which they are funding themselves.

I am choosing to vote ABSTAIN on the Stablecoin DeFi Liquidity Budget info action. I find myself conflicted with regards to this proposal. My heart says yes while my head has its doubts. While I naturally want what is best for the Cardano ecosystem and hope that this proposal delivers as it intends to, I have reservations about the utilisation percentage of the NCL and whether the proposal will actually achieve what it intends to, especially when evaluated in the context of the wider cryptocurrency space.

I have always regarded the Net Change Limit as a spending cap and not a spending target. There is currently 77,968,493 ada remaining and using 64.12% of that (or 14.28% of the total NCL) on what is an as yet untested experiment feels too much.

One comment from the Cardano Summit 2024 has stuck with me over the past year and it came from the panel “Does Liquidity Bring Users Or Do Users Bring Liquidity?” no less. (https://www.youtube.com/watch?v=z1nw7munfXY). The comment was made by Senad Dilji and it was that regarding Cardano, “I don’t think it’s really a marketing issue, I think it’s more of a perception issue”. It was absolutely true, while we see our progress and growth within our own ecosystem, there is no denying the fact that the larger crypto space, to date, simply has not cared, largely because Cardano is rarely present where it needs to be. Thankfully recent months have seen moves to correct this with the unified front at Token 2049, the recent Asia tour and Discover Cardano presence at Gitex, Dubai.

To argue that Cardano isn’t taken seriously because of TVL and liquidity and that this proposal is needed to “first fix it ourselves, in order to attract others” potentially invites critics and naysayers to once again move the ever-moving goalposts and claim that the ecosystem is merely “propped up from within”.

With regards to many of the actual DeFi mechanics, I also choose to vote abstain in recognition of the fact that my knowledge and experience in this area is not at a level where I feel comfortable making the decision one way or another.

I do however wish the proposal the best of success and sincerely hope that it achieves what it sets out to do. I just cannot in good conscience throw my full weight behind it given my personal doubts and the shortcomings of my own knowledge on the topic.

Having previously voted in favour of the related budget info action, I am voting YES on this treasury withdrawal proposal for GovTool maintenance. The rationale for that vote can be found at https://raw.githubusercontent.com/hephy-io/mainnet/refs/heads/main/drep_rationales/GA020-info-GovTool.jsonld. For ease of readability, I will also include the previous rationale text here:

“As a cli-based DRep, I have no need for a user-interface like GovTool. If it disappears, I will still be able to check proposals on-chain and vote on-chain as I have done for the past year and a half (including SanchoNet). However, I am able to appreciate the importance of the role it has and can continue to play in Cardano governance, beyond the user-interface that we all see on the website.

GovTool has been there since the beginning, during the days of the Cardano governance testnet “SanchoNet”. While many apps and wallets appeared to wait until governance was on mainnet before putting in the work, GovTool was there building the foundations so that access was made easy for new DReps from day one of mainnet governance and arguably, we wouldn’t have the DRep registration numbers that we have today without it.

While new platforms have emerged alongside GovTool, they do not diminish the need for GovTool. The support for Mainnet, PreProd and Preview networks is rare across all governance platforms and allows access for developers and DReps who want to test out governance proposals in a safe environment without putting real world funds at risk. I may be a cli-based DRep who has submitted protocol parameter updates to both SanchoNet and Preview using the cli but without GovTool support for the Preview network, it would have been much harder to get Preview DRep participation and pass the proposal to fix the dRepActivity and govActionLifetime mismatch earlier this year (see https://preview.gov.tools/outcomes/governance_actions/35b81b424956f018bb4a4bb9e160375c1921a3b40b60a1efc539bcd6b5b20159#0).

The GovTool platform provides increased accessibility to Cardano governance, the main site hosts features like the DRep Directory, Budget Proposals, Governnace Actions (Proposals, Live Actions and Outcomes) as well as hosting documentation for Guides and an FAQs section. Less visible is the constitution sub-domain (https://constitution.gov.tools) that host the Cardano Constitution in an accessible format, Constitutional Committee Members page, ICC/CC voting updates page and the recent CC election portal. Furthermore, GovTool also provides free and open APIs used by many other tools and service providers in the ecosystem that would struggle if the APIs were to disappear.

In conclusion, while many may feel that GovTool needs much improvement, it does already provide much value to the ecosystem and the maintenance of open and accessible governance is vital for Cardano while governance is still essentially in its infancy. I vote to fund GovTool for 12 more months after which the community can reassess the state of Cardano governance once it has had chance to mature properly.”

This particular proposal has been submitted by a community member in an attempt to provide input for the Intersect Product Committee. However, Product Committee members have already publicly stated that this is a premature submission and that “PC has not signed off on current verbiage”. (https://x.com/ADAFrog_Pool/status/1971295372908822628) With this in mind I am voting to ABSTAIN at this time so as not to unnecessarily waste time on an incomplete proposal. I respect that this info action was submitted with good intentions but if it was not sanctioned by the Product Committee itself and there will be an official proposal submitted in the near future, this submission does little else but to take up more valuable DRep and CC members time and would have been better suited for the proposal discussion page on GovTool rather than going straight to on-chain (https://gov.tools/proposal_discussion).

I vote YES in favour of the budget info action proposing a 5 million ada loan for Cardano global listing expansion put forth by the Snek Foundation. I appreciate that the proposers have taken onboard community feedback following their previous proposals and revised this proposal, with the help of Intersect, to better meet the requirements of the Cardano governance process and going one step further by submitting a first-of-its-kind proposal in the format of a loan, a treasury withdrawal with a repayment commitment.

While voting YES in favour of this revised proposal, two issues surrounding it have given me pause for concern. The handling of the initial two proposals, it often gets forgotten that there were two and why the first one was even more of a complete false start, and the behaviour of some elements of the community towards anyone with opposing views or genuine questions in the time since the proposal became public.

First off, the hasty mishandling of the previous two proposals demonstrated both a complete disregard and lack of understanding of the governance process and also raised concerns at how quickly the proposers were willing to throw 200,000 ada at governance proposals that were ultimately locked up for 6 epochs because they were premature and incomplete. A detailed breakdown can be found in my previous rationale for these proposals at https://raw.githubusercontent.com/hephy-io/mainnet/refs/heads/main/drep_rationales/GA062-063-treasury-snek.jsonld. Yes, I appreciate all that the Snek team have achieved to date and the levels of their own funds that they have deployed to get to where they are today but you can’t deny that throwing a second wave of 100,000 ada at another proposal that was unconstitutional at the get-go because, just hours previously, the first one incorrectly requested 5 ada on-chain instead of 5 million, could come across as erratic at best, incompetent at worst. It also did little to reassure voters that they can handle 5 million ada when 200,000 was so hastily deployed incorrectly.

The second issue is with regards to some elements of the Snek community and their treatment of DReps throughout this process. The situation was not helped by having two incorrectly submitted proposals in the first place, that were never going to pass, which likely fed into community frustrations early on. That said, I did not appreciate seeing repeated labelling of DReps as “low IQ” and much worse on social media, especially when you consider that the initial proposal requested 5 ada and not 5 million. I appreciate that the minority does not reflect the majority and that there are many good actors amongst the Snek community, however such animosity from bad actors does little to win favour amongst the wider Cardano community and should be considered thoughtfully when you take into account that the actual treasury withdrawal proposal that will follow this will require a 67% approval threshold, greater than the >50% required for this budget info action.

That said, it has been encouraging to see the Snek team reach out to Intersect for assistance and for putting forward this much revised and improved proposal, which is also novel in its intention for treasury repayment.

Cardano on-chain governance was launched with the Chang and Plomin hard forks as “minimum viable governance” (MVG), it was always meant to iterate and improve upon these foundations to move towards what could be considered as a more “sustainable viable governance” (SVG). The Constitution lays the foundations for how governance actions should work, including the treasury withdrawal action processes. It does not lay out the processes for loan proposals and this can be seen as the Cardano ecosystem iterating upon the MVG towards SVG, much like the recent development whereby governance action proposals have begun to include a self-constitutionality checklist within their rationales, it isn’t constitutionally mandated but it is becoming a useful and accepted standard. This is the first time a treasury withdrawal has been proposed with repayment details and this is precedent setting in itself and a welcome one as we iterate towards a more sustainable system. I commend the Snek team for taking community feedback on board, for adapting their proposal and for putting forth this novel proposal that commits to repaying the requested funds to the treasury in the future.

This proposal still has to be submitted as a treasury withdrawal action and reach the 67% approval threshold after this budget info action and I hope during that time that the Snek community can keep itself in check and tone down some of the toxicity from some community members that has been directed towards DReps who hold different views or ask questions during their deliberations. It does little to win people over and creates unnecessary animosity within the Cardano community.

I am voting YES on the budget info action proposal for the Cardano in Oceania 2025-2026 strategy and budget. The proposal seeks funding for greater co-ordination of Cardano outreach efforts across the Oceania region, building upon previous experiences and efforts in the space. I appreciate the provision of a website that outlines the “Why, What, How and Who” in more detail, I particularly like the provision of the git commit used to build the website as it provides a level of immutability and a point of reference for the proposal content and ensures that any future alterations can be checked against the information provided for this proposal.

The site provided in the supporting links of the proposal (https://cardano-in-oceania.github.io) provides detailed team, supporters and administrator info, along with a detailed budget breakdown, implementation timeline and milestones.

I was fortunate enough to have been able to meet a number of individuals associated with this proposal during the Constitutional Convention, including Jo Allum and Peter Horsfall (Community Leaders), Nathan Barkell, Engie Matene and Corinne Phillips (Supporters & Contributors), as well as Mark Byers from Selfdriven Services (Administrator). In addition to these individuals, the proposal also lists other prominent community educators (Peter Bui) and governance advocates (Phil Lewis), SPOs (46S and ECO), a wallet (Tokeo) and DEX (VyFi) amongst its Sponsors and Partners.

I have had little contact with these individuals since the Constitutional Convention so there is no undue influence here but my experience online and offline is that this proposal has a very accomplished and professional team behind it and reflects the vibrant ecosystem that exists across the Oceania region. It draws on backgrounds such as technical, educational, legal, governance, and financial, and is well-rounded in this regard, putting the initiative in good stead to pursue and achieve its goals.

For those that say this proposal should go to Catalyst, you simply cannot achieve the goals set out in a proposal such as this with Catalyst funding. The budgets for associated rounds are too small for a co-ordinated effort on this scale and we as an ecosystem need to move beyond this knee-jerk reaction of “try Catalyst” for marketing and outreach. We have already witnessed another community outreach initiative, Discover Cardano, put up significant sums of their own money to represent Cardano at events where there was otherwise no representation, to great success, and still be twice rejected at the Catalyst level. It was only thanks to a big community push on socials that they even passed their recent treasury withdrawal proposal. We as a community often complain that founding entities are not doing enough of this work but when genuine and serious community actors step up to fill a gap we seem equally as hesitant.

First off, I would like to commend Yuta on the efforts and the intent behind this first update to the community-approved Constitution. I respect the efforts to reduce ambiguity and to improve on what has been created so far. However, I am unable to support this proposed update at this time.

Article VIII Section 1 states that the Constitution “should be treated as a living document” and the community “encouraged to periodically review and debate its provisions” and while this has been done to some degree so far , I feel that it falls short in “coming together in such forums that the community deem appropriate, to propose amendments to this Constitution”. The proposer has gone to decent lengths to ensure a wide range of community feedback, regularly updating their proposed document over multiple iterations as feedback has been provided. However, the wider Cardano community doesn’t exist solely on X and Google Docs and when viewed in retrospect to the lengths taken during the creation of the first Cardano Blockchain Ecosystem Constitution, I feel that it still currently falls short on community engagement and that further socialisation is required through workshops and other community forums. That is not to say that we need another global workshop series and a Convention like before, but a greater level of socialisation is needed to ensure legitimacy of a Constitution that represents the community.

I also feel that it is too soon to be proposing such changes. The community-ratified Constitution has been on-chain for almost 8 months. Great time and effort was put in to reach the result achieved at the Convention in December 2024 and it almost feels as though making such sweeping amendments, orchestrated by a small group, so soon could almost be seen as a discredit to the efforts of so many who participated in the global workshops and their elected delegates and of those at the Convention in Buenos Aires and Nairobi.

As an outgoing member of the ICC I have seen firsthand the evolving quality of governance action proposals over the past year, from Interim Constitution to the community-ratified Constitution. On-chain governance has been a learning curve for all involved and after some initial misunderstandings and frustrations, the quality of proposals has really begun to pick up recently as the community and proposers have come to understand the standards required for constitutionality. With 15 info actions (5 general, 4 NCL, 6 budget), 3 protocol parameter update actions, 1 update constitution, 1 hard fork, 42 treasury withdrawal actions and 1 update constitutional committee action prior to this proposal, there has now been established a good wealth of precedents of proposals in light of the current Constitution. My concern with updating the Constitution at this point in time would be more confusion regarding proposal expectations and a drop in quality of proposals as a result of this confusion as proposers get to grips with a changing ruleset regarding constitutionality without a greater socialisation of its intended amendments.

In summary, I believe that the current Constitution still needs more time so that the community can produce more learnings of the on-chain governance experience and to give the Constitution creation process more legitimacy by increasing the socialisation of any proposed amendments. It has been encouraging to see the level of community engagement so far and I would just like to note a recent post by Jane on X which I felt made some valid contributions also (https://x.com/Jane14457995/status/1954933866432434185). I encourage these efforts to continue until such a time that enough of the global community has had a chance to have their say through local workshops and other such forums in order to achieve a sufficient level of socialisation and legitimacy of representation of the global Cardano community.

This proposal was not originally one of my selections during the Ekklesia budget reconciliation process and I have decided to remain against funding this proposal at this time. Using treasury funds for exchange listings in this way could set a dangerous precedent whereby any future CNT looking to be listed on any and all exchanges finds that exchanges, having seen this precedent, then demand the same funding for any CNT listings going forward. The treasury should be used for ecosystem tooling, development and improving the user experience for ada holders, not as a cash cow for exchanges who see a few projects listed via treasury funding and then in turn attempt to make that the new norm in the listing process for the Cardano ecosystem alone due to its particular treasury and on-chain governance system.

This proposal was not originally one of my selections during the Ekklesia budget reconciliation process and I have decided to remain against funding this proposal at this time. It is a large ask for relatively unknown project in the ecosystem and I would consider an application to Cardano Use Cases: Partners and Products a better funding route for a pilot programme before graduating to a treasury withdrawal request of this size. I also attempted to read some of the supporting documentation only to find it sitting behind a request for an email address. Such information should be provided to the community and DReps openly in a publicly accessible format without any such barriers. This is the only proposal that I have come across so far that has linked further information in this manner.

This is a combined rationale for the two treasury withdrawal governance actions submitted by the Snek Foundation, with the action ID’s: “4ff43f1eab5252ef00ba6f1429dc23715e3899834f10c067e8065c8364d5559a#0” and “1d6aea56e6a523b13e03ae30ff24ebf9852543b4f7d415c7e50f55f6baaa4e3d#0”. A combined rationale is provided to give further context to the “NO” vote submitted here.

First and foremost, this is not a reflection of my views regarding Snek’s achievements, their position in the ecosystem to date, or whether treasury funds should be used for project listings and is an assessment of the handling of the submission of these two proposals.

While constitutionality is the remit of the Constitutional Committee and not DReps, it plays a role in assessing the handling of these two proposals. On August 2 2025, two treasury withdrawal actions were submitted less than an hour apart, with a combined governance action deposit of 200,000 ada. It appears as though the second action was submitted in haste following an input error that resulted in the first proposal requesting only 5 ada instead of 5 million ada. This is the first and foremost issue with the first governance action and any DRep voting yes without recognising this fact raises questions about their levels of due diligence when it comes to voting. Constitutional or otherwise, the on-chain treasury withdrawal request is for 5 ada and not the proposed 5 million ada in the proposal text.

A deeper assessment of the timeline of events raises further questions (times in UTC+1). The provided withdrawal address was first funded at 13:13:24 on August 2 2025 with the stake key registered and delegated to a DRep at 13:14:12, breaking the first constitutional requirement for treasury withdrawals before the proposal was even submitted (https://cardanoscan.io/address/addr1q9gcxfl9fe9ulluvtc2sxj6xux7jfa49zzq4aheyywqm0k3gudvqrjyfk4nqpvscu2ggqg67x9e0dk5l5p4s6msvkpys6qv4v6). This address was then funded with the 100,000 ada deposit funds at 13:15:55 with the first governance action submitted at 13:46:02 (https://cardanoscan.io/govAction/gov_action1fl6r784t2ffw7q96du2znhprw90r3xvrfugvqelgqewgxex42kdqq9tgrd5).

Less than an hour later, likely after noticing the 5 ada not 5 million ada error, the provided address was funded with a second round of 100,000 ada at 14:21:48 and a second action submitted at 14:34:22 with the correct 5 million ada value instead of 5 ada (https://cardanoscan.io/govAction/gov_action1r44w54hx553mz0sr4cc07f8tlxzj2sa57l2pt3l9pa2ldw42fc7sq5q3rtn). In the meantime, at 17:43, the Snek X account tried to make light of the situation claiming that this submission was intended for testnet (https://x.com/snek/status/1951685280462749958), despite a mainnet wallet being funded twice with 100,000 ada which is more than just a “button clicking error”. This post was a display of incompetence at best, deception at worst, and should have just honestly owned up to the mistake.

Following further feedback on social channels about constitutionality, the stake address was then delegated to the auto-abstain DRep at 18:13:19 in order to correct that constitutional requirement but with the absence of a previous budget info action, among other shortcomings, the damage there had already been done.

People can claim that “governance is still new” in defence of the handling of these proposals however, with 15 info actions (5 general, 4 NCL, 6 budget), 3 protocol parameter updates, 1 update constitution action. 1 hard fork initiation, 40 treasury withdrawal actions and 1 update constitutional committee action all on-chain prior to these proposals being submitted, that defence is wearing thin. We have plenty of precedents for these things that potential proposers can now look back on and see why actions may or may not have passed / been deemed constitutional/unconstitutional. We also have testnets exactly for this reason, use them! Not only can they help get things right first time but it also allows an opportunity to socialise the proposal and receive any feedback for any potential failings before committing 200,000 ada in deposits.

The submitters of these proposals should have waited after the first one, despite the 5 ada error, as it would have still allowed chance for feedback on other areas before hastily committing to another deposit. Additionally, it was short-sighted also to rush, in the wider context of the epoch timing, the epoch ended 3.5 hours after the second submission, voting periods are measured in epochs and by submitting so late in the epoch they actually sold themselves short of up to 116 hours additional voting time than had they submitted earlier in the epoch.

All-in-all the hasty mishandling of this situation raises questions for me, especially when requesting 5 million ada from the treasury while so nonchalantly throwing 200,000 ada at governance action deposits, now locked for the full voting period with a pair of ill-prepared governance actions.

This is a combined rationale for the two treasury withdrawal governance actions submitted by the Snek Foundation, with the action ID’s: “4ff43f1eab5252ef00ba6f1429dc23715e3899834f10c067e8065c8364d5559a#0” and “1d6aea56e6a523b13e03ae30ff24ebf9852543b4f7d415c7e50f55f6baaa4e3d#0”. A combined rationale is provided to give further context to the “NO” vote submitted here.

First and foremost, this is not a reflection of my views regarding Snek’s achievements, their position in the ecosystem to date, or whether treasury funds should be used for project listings and is an assessment of the handling of the submission of these two proposals.

While constitutionality is the remit of the Constitutional Committee and not DReps, it plays a role in assessing the handling of these two proposals. On August 2 2025, two treasury withdrawal actions were submitted less than an hour apart, with a combined governance action deposit of 200,000 ada. It appears as though the second action was submitted in haste following an input error that resulted in the first proposal requesting only 5 ada instead of 5 million ada. This is the first and foremost issue with the first governance action and any DRep voting yes without recognising this fact raises questions about their levels of due diligence when it comes to voting. Constitutional or otherwise, the on-chain treasury withdrawal request is for 5 ada and not the proposed 5 million ada in the proposal text.

A deeper assessment of the timeline of events raises further questions (times in UTC+1). The provided withdrawal address was first funded at 13:13:24 on August 2 2025 with the stake key registered and delegated to a DRep at 13:14:12, breaking the first constitutional requirement for treasury withdrawals before the proposal was even submitted (https://cardanoscan.io/address/addr1q9gcxfl9fe9ulluvtc2sxj6xux7jfa49zzq4aheyywqm0k3gudvqrjyfk4nqpvscu2ggqg67x9e0dk5l5p4s6msvkpys6qv4v6). This address was then funded with the 100,000 ada deposit funds at 13:15:55 with the first governance action submitted at 13:46:02 (https://cardanoscan.io/govAction/gov_action1fl6r784t2ffw7q96du2znhprw90r3xvrfugvqelgqewgxex42kdqq9tgrd5).

Less than an hour later, likely after noticing the 5 ada not 5 million ada error, the provided address was funded with a second round of 100,000 ada at 14:21:48 and a second action submitted at 14:34:22 with the correct 5 million ada value instead of 5 ada (https://cardanoscan.io/govAction/gov_action1r44w54hx553mz0sr4cc07f8tlxzj2sa57l2pt3l9pa2ldw42fc7sq5q3rtn). In the meantime, at 17:43, the Snek X account tried to make light of the situation claiming that this submission was intended for testnet (https://x.com/snek/status/1951685280462749958), despite a mainnet wallet being funded twice with 100,000 ada which is more than just a “button clicking error”. This post was a display of incompetence at best, deception at worst, and should have just honestly owned up to the mistake.

Following further feedback on social channels about constitutionality, the stake address was then delegated to the auto-abstain DRep at 18:13:19 in order to correct that constitutional requirement but with the absence of a previous budget info action, among other shortcomings, the damage there had already been done.

People can claim that “governance is still new” in defence of the handling of these proposals however, with 15 info actions (5 general, 4 NCL, 6 budget), 3 protocol parameter updates, 1 update constitution action. 1 hard fork initiation, 40 treasury withdrawal actions and 1 update constitutional committee action all on-chain prior to these proposals being submitted, that defence is wearing thin. We have plenty of precedents for these things that potential proposers can now look back on and see why actions may or may not have passed / been deemed constitutional/unconstitutional. We also have testnets exactly for this reason, use them! Not only can they help get things right first time but it also allows an opportunity to socialise the proposal and receive any feedback for any potential failings before committing 200,000 ada in deposits.

The submitters of these proposals should have waited after the first one, despite the 5 ada error, as it would have still allowed chance for feedback on other areas before hastily committing to another deposit. Additionally, it was short-sighted also to rush, in the wider context of the epoch timing, the epoch ended 3.5 hours after the second submission, voting periods are measured in epochs and by submitting so late in the epoch they actually sold themselves short of up to 116 hours additional voting time than had they submitted earlier in the epoch.

All-in-all the hasty mishandling of this situation raises questions for me, especially when requesting 5 million ada from the treasury while so nonchalantly throwing 200,000 ada at governance action deposits, now locked for the full voting period with a pair of ill-prepared governance actions.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to abstain from voting on this proposal at this time.

I understand the need for a cohesive roadmap going forward but I am unsure of the need to deploy a further 750,000 ada of treasury funds for this proposal at this time. Intersect has already received funding for its main proposal and even after having revised their ask down to 15,750,000 ada, given the rise in the value of ada since the initial budget proposals were submitted, there should still be more than enough there to allow Intersect to execute its role as community facilitator and co-ordinator in order to help the Product Committee achieve its plans as outlined here.

I have a hard time justifying funding free access to a service for 18 months from the treasury without knowing what happens at the end of that time period. While I appreciate that the problem outlined in the proposal is real, I do not feel that the treasury should be used to subsidise access to a service in this way. While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to vote against funding this proposal at this time.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to once again to vote against funding this proposal at this time. Project Catalyst has already received a sizeable chunk of treasury funding and the Fund 14 launch materials note that this latest funding round also includes “Generalised Quadratic Voting (GQV) as a proof of concept to the tallying stage. This preserves the existing vote-casting process and will compare traditional linear voting outcomes with quadratic results” (https://projectcatalyst.io/f14launchguide.pdf). While the vendor profile for this proposal is no doubt very well qualified and experienced in the Cardano ecosystem, I feel that we should wait to see the results of the proof-of-concept for this Catalyst fund before re-evaluating the need for an implementation of this proposal.

It is incredibly frustrating to see this sudden self-awareness of the “challenges in establishing a consistent and impactful presence at global blockchain events” only emerge the year that the Cardano treasury becomes accessible. We have had teams like Discover Cardano digging into their own pocket to try and plug a gap at a major convention in 2023 that otherwise had zero Cardano representation, demonstrating how such participation could be achieved in a cost-effective way, only to be refused recognition or future funding for their efforts. This situation is wholly a product of founding entities neglecting their remits and responsibilities as genesis ada holders. To now request treasury funding in year one to fix an issue largely of their own making for the past 4+ years is frankly absurd.

This request should come with a public apology, or at least an acknowledgement from those whom this was their remit and responsibility for the past 4+ years, before expecting ada holders to green light funding to fix a problem of their own making.

I will take a moment to acknowledge the efforts and achievements of Rare Network and this rationale is in no way directed at them. What they have achieved over the past 4 years for Cardano events and now the wider crypto ecosystem has been nothing short of amazing. Equally, I am hugely appreciative and respect the efforts that the Cardano Foundation has put in with hosting the Cardano Summit since 2022, this is also not a reflection of that.

I have attended crypto events in the UK over the past few years and last year had to witness Solana and their Superteam initiative go on to do a nation-wide hackathon tour of the UK’s universities, imagine how awkward that felt attending a conference at one of the top 2 universities in the country only to find Cardano, the “academic blockchain”, not even be so much as a footnote on the sponsorship board.

I appreciate the need for this proposal and wish that it had existed for the last 2-3+ years but I cannot in good conscience say yes without an acknowledgement of how we have ended up here in the first place. Therefore, I choose to abstain at this time.

Despite being 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I have decided to change my vote to an abstain at this time. During the budget reconciliation process I absolutely felt it necessary to move beyond minimum viable governance (MVG), it was a term used so much during the CIP-1694 process that this felt like the right initiative to begin progressing the state of Cardano governance to a more mature iteration.

That said, I recall how tailored the experience of the CIP-1694 and Constitution workshops were, where people believed they would have a real chance at shaping the process, only to be greeted with pre-determined topics and attempts to raise any other concerns were stonewalled and labelled “out of scope”.

I now see a pandering to a select number of DReps, unimpressed by language such as “top DReps” or “key DReps”. We like to preach about the liquid nature of voting power, so why one group should be favoured over others based on what is meant to be liquid voting power seems short-sighted. A large voting power doesn’t necessarily make someone a “top DRep”, some have low vote participation, may not provide on-chain rationales with their votes or simply vote yes to any proposal suggested by certain vendors without pause for evaluation. This does not bode well for what we like to proudly proclaim “decentralised governance”.

Until there can be assurances that this proposed iteration of Voltaire doesn’t descend into a repeat of past processes, with conversations shepherded to a pre-conceived outcome dressed up as decentralised consensus, I abstain from voting to fund such efforts at this time.

I have debated between abstain and yes for this proposal for a while. I recognise the need for a funding mechanism that complements Catalyst, that allows more established projects to receive development funding that doesn’t detract from Catalyst’s role as an innovation engine for new and smaller projects. I also appreciate that it could be too much to expect each and every project to seek treasury funding every time that they have a proposal for new products or features. This increases administrative burden on both the developers and DReps/CC.

However, I also respect that cryptocurrency is usually about removing/reducing middlemen and this approach also reduces the ability for DReps to have a say in what gets funded. Similar to my rationale for the Paid Open-Source Model proposal though, I feel that this does fill a gap in current funding avenues, allowing developers to focus on building rather than bureaucracy.

With that said, I will be watching the performance and outputs from this DAO going forward before committing to future funding.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to vote in favour of funding this proposal at this time.

As 1 of 3 proposals in this series of 39 treasury withdrawal governance actions that are around or below 100,000 ada I feel that requests of this size are better suited to the recently launched Catalyst Fund 14.

This was not originally one of my selections during the Ekklesia budget reconciliation process and I have decided to vote in favour of funding this proposal at this time. In-line with my Scalus and OpShin rationales, improving the developer experience on Cardano is important and increasing the number of programming languages available to developers is a good way to achieving this, especially with regards to dispelling the common misconception in the wider crypto community that Cardano is still “Haskell only”. PyCardano has been developed on Cardano for a while now and has some success with adoption to date and I will be interested to see how this treasury funding will help push this adoption amongst the Python community to the next level. As another project that has received Catalyst funding in the past, I will be interested to see the progress as a result of funding this time before approving any further treasury requests in the future.

Originally 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES. As stated in my Scalus proposal rational, improving the developer experience on Cardano is important and increasing the number of programming languages available to developers is a good way to achieving this, especially with regards to dispelling the common misconception in the wider crypto community that Cardano is still “Haskell only”. The team behind OpShin have been developing on Cardano for a while now and I look forward to seeing how successful they are at attracting Python developers to the ecosystem with their tools. Much like Scalus, I also see that OpShin has received Catalyst funding in the past and will keep this in mind ahead of any further request for treasury funding in the future.

As much as I would like to see growth and development in this area, I have to agree with other DReps who have asked the question “if this is a problem so easily solved with this amount of funds, why hasn’t it been done by now?”. It is encouraging to read that the proposers are “also raising external capital from additional investors to sustain operations” and leaves me wondering to what extent treasury funding is actually required here. This is also an area where founding entities such as the Cardano Foundation or Emurgo could easily step in to fill this gap without resorting to applying treasury funding.

Catalyst also has a category for “Cardano Use Cases: Partners & Products” where the maximum ask is 1 million ada. I would be more comfortable voting for this proposal if the proposers were to go that route first and demonstrate with a smaller amount of funds what they are capable of achieving before voting to deploy serious treasury funding in this direction.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to not vote in favour of funding this proposal at this time.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to vote in favour of funding this proposal at this time. Improving the developer experience on Cardano is important and increasing the number of programming languages available to developers is a good way to achieving this, especially with regards to dispelling the common misconception in the wider crypto community that Cardano is still “Haskell only”.

The team behind this proposal appear to have strong backgrounds with histories of working with IOG and traditional finance companies. I see they have received some funding through Catalyst already and so will be keeping an eye on how this develops with regard to any further treasury funding requests in the future.

As 1 of 3 proposals in this series of 39 treasury withdrawal governance actions that are around or below 100,000 ada I feel that requests of this size are better suited to the recently launched Catalyst Fund 14.

I have my reservations regarding handing 28.57% of voting power to just 2 individuals on this Committee and that DRep participation in this election was shockingly low, with the most voted candidate in this election still only receiving votes from less than 10% of DReps (85 votes out of ~900 Dreps).

However, the interim period of Cardano governance was meant to be just that, interim. With the official end of the interim period marked by the ratification of the community-agreed Constitution, the original Interim Constitution mandated that the Interim Constitutional Committee shall serve an inaugural term of 73 epochs from the date of the Chang hard fork (Article IV, Section 2 of the Interim Constitution). This leaves the election of all the seats of the Constitutional Committee to be the last remaining step towards reaching the full on-chain governance as decided by ada holders.

DReps had their chance to vote during the Constitutional Committee elections and if either DReps did not vote or ada holders did not move their delegation to those that best represented their choices in the time available, then that is a matter for them to re-evaluate. There was an election, results were audited and therefore I vote in favour of this update committee action.

As an outgoing ICC member, acting as one of several community members representing the Intersect Constitutional Council over the past year I would just like to say that it has been an honour to serve in this capacity and an experience as we all began to find our way in this new world of on-chain governance. Knowing the work that went into the role behind the scenes it is with both sadness and relief that I look forward to the new CC. Sadness that the work put in over the past year was not valued enough to earn another spot on the Committee and that there’s a wealth of experience among prospective Adara members that is now seeking a suitable outlet, but also relief with the knowledge of just how much work the past year has been behind the scenes. I wish the incoming Constitutional Committee all the best in their new / recurring roles.

For me, support for the people behind this proposal continues to be one of the most perplexing occurrences in this ecosystem. Reading other rationales I see other DReps saying “Catalyst would be better”, they’ve tried Catalyst… twice! And been discounted both times, after having invested significant sums of their own money to have a Cardano presence at a major industry event in 2023 where otherwise there would have been none. Personally, I do not blame them for now trying the direct treasury route instead.

Admittedly, it appears that there has been, to a degree, a case of “lost in translation” between the “Discover Cardano” who we may know from social media and the registered entity “Supplyoneers FZ-LLC” named on this proposal.

Throughout a period where it could be argued that the founding entities dropped the ball somewhat regarding their presence at wider industry events outside of the Cardano Summit and Rare Evo, Discover Cardano was there trying to fill that gap. Identifying funding restrictions that limited project participation they implemented a novel idea to represent projects at their event booth in Dubai in 2023. It has been mildly frustrating seeing founding entities come crawling out of the woodwork offering a global marketing presence now that the treasury has been unlocked while grass-roots efforts like this one continue to get kicked to the curb despite their best efforts.

They have provided detailed cost breakdowns and a plan of action and revised their proposal based on community feedback but somehow it appears as though it will never be enough. If we’re not careful as a community, we will lose good people like this altogether.

As 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES.

I support funding for a Ledger app rewrite. Ledger remains one of, if not the most, popular choice for retail users when it comes to hardware wallet security. We have already witnessed some difficulties with manufacturers like Trezor when it comes to merging the latest features even when Cardano-specific teams have done the work for them. It is essential for the safety of hardware wallet user funds and for wider Cardano adoption that the Cardano ecosystem be treated and represented fairly with a fully functional app that conforms to the expected standards for UI and testing.

As 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES. In keeping with previous voting intentions of keeping total treasury withdrawal expenditure below 250 million ada I have focussed my selections on core development and essential maintenance of community tooling as we enter this critical period of the market cycle. I have tried to balance between large project asks and smaller but still very essential maintenance for existing tooling, with projects that have a proven track record.

The Dolos project appears to be narrower in scope compared to some of the projects seeking funding at the moment. However, it is an open-source project and states that adoption for its specific case is growing. The Cardano ecosystem could use more node diversity within its ecosystem, especially as the chain and its history grows, it may not always be feasible or necessary for certain projects to run the traditional node infrastructure with its associated overheads as we know it. Dolos here seems to offer a lightweight alternative for those with very specific data requirements. I support funding it now with an eye to monitoring its adoption rates in the short to medium term, ahead of any additional future funding requests.

This is one of a number of treasury withdrawal requests from TxPipe and I respect that they divided their requests into their respective projects rather than bundling them all into one request, allowing ada holders the opportunity to express their views on what areas they would like to see treasury funds committed to.

As 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES. In keeping with previous voting intentions of keeping total treasury withdrawal expenditure below 250 million ada I have focussed my selections on core development and essential maintenance of community tooling as we enter this critical period of the market cycle. I have tried to balance between large project asks and smaller but still very essential maintenance for existing tooling, with projects that have a proven track record.

As one of two ZK proposals currently requesting funding from the Cardano treasury I think it is important to have teams exploring a range of scaling solutions for Cardano. While a lot of the zero-knowledge focus has been around Midnight it will be good to see some developments in this area for Cardano itself too. The vendor profile states that the team is making progress towards a tesntet deployment of their ZK Rollup and while some concerns remain over the vagueness of the team description provided, it is hoped that Intersect oversight of all funded projects will hold them accountable to sufficient milestone achievements in order to ensure the team is up to the task if funded.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to include this item amongst my funding choices at this time.

I support the treasury withdrawal request to fund the ongoing maintenance and development of Lucid Evolution, one of the most used off-chain libraries in the ecosystem. As I understand it, this is what was once Lucid, developed by Alessandro but now active development has been taken up by Anastasia Labs here with Lucid Evolution in order to ensure the continued maintenance and development of one of the longest standing building blocks for the wider Cardano developer community. As an essential open-source component for Cardano developers I support this treasury withdrawal even though at 130,903 ada it does come close to me considering it better suited for Catalyst funding.

As 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES. In keeping with previous voting intentions of keeping total treasury withdrawal expenditure below 250 million ada I have focussed my selections on core development and essential maintenance of community tooling as we enter this critical period of the market cycle. I have tried to balance between large project asks and smaller but still very essential maintenance for existing tooling, with projects that have a proven track record.

I support the continued funding for the development of UTxO RPC as it works towards greater blockchain integration for Cardano. I value it’s open-source nature and growing collaborations. Usage across the ecosystem to date includes listed projects such as Lace, Mesh and Amaru.

This is one of a number of treasury withdrawal requests from TxPipe and I respect that they divided their requests into their respective projects rather than bundling them all into one request, allowing ada holders the opportunity to express their views on what areas they would like to see treasury funds committed to.

As 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES. In keeping with previous voting intentions of keeping total treasury withdrawal expenditure below 250 million ada I have focussed my selections on core development and essential maintenance of community tooling as we enter this critical period of the market cycle. I have tried to balance between large project asks and smaller but still very essential maintenance for existing tooling, with projects that have a proven track record.

I support the continued funding for the development of Pallas as a critical piece of Rust tooling for Cardano. I value it’s open-source nature, wide collaboration and usage that it has achieved across the ecosystem to date with projects listed including Aiken, Lucid, Mithril and Amaru.

This is one of a number of treasury withdrawal requests from TxPipe and I respect that they divided their requests into their respective projects rather than bundling them all into one request, allowing ada holders the opportunity to express their views on what areas they would like to see treasury funds committed to.

As 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES. In keeping with previous voting intentions of keeping total treasury withdrawal expenditure below 250 million ada I have focussed my selections on core development and essential maintenance of community tooling as we enter this critical period of the market cycle. I have tried to balance between large project asks and smaller but still very essential maintenance for existing tooling, with projects that have a proven track record.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to vote in favour of funding this proposal at this time. The academic nature and thoroughness of the research behind Cardano was one of the reasons I chose this blockchain in early 2018. Economic systems should be built with the same rigour as other mission critical infrastructure and the resilience of the Cardano network throughout its lifetime is a testament to this approach. However, this one wasn’t a clear-cut decision for me.

I have debated between abstaining and voting yes on this proposal for a while. My initial thoughts were regarding the sheer amount of this budget being allocated to one entity. Break it out into IOE, IOR, or IOXYZ if you want, it’s all still Input Output. At first, I considered the near 97 million ada proposal for core development, with the recent price increases, to be more than enough to cover any remaining items put in by IO here. On further reading of the proposal PDFs it became clear that each cost breakdown was primarily a dollar valuation and that the ada amounts put forth (as mandated by the Constitution) were a reflection of these proposed work valuations at $0.50 per ada. Therefore, despite these sizeable asks, I hope that Intersect as administrator holds IO to these numbers and should the value of ada be higher than $0.50 at the time of funding then the ada disbursed should be adjusted accordingly.

It was also initially confusing as to whether this funding was for 1, 2.5 or 5 years. The proposal outlines a 5-year work programme, to be reviewed at 2.5 years but after closer reading this proposal is for one year of funding. I am uneasy with the idea of being locked into a “research funding subscription model” for 5+ years and I highly recommend that a close eye be kept on how much of these funds are withdrawn or returned to the treasury based on the dollar values requested and the evolving price of ada in this first year. Especially as even a $0.64 ada price would already allow the near 97 million ada proposal for core development to cover this proposed research cost.

Hardware wallets are an essential component to participating with security and confidence in the world of cryptocurrencies and it is equally essential that ada holders continue to have the ability to utilise these technologies to secure their assets. Vacuumlabs has been integral to integrating Cardano into the most common hardware wallets on the market and have demonstrated their track record in this area since 2018.

As 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES. In keeping with previous voting intentions of keeping total treasury withdrawal expenditure below 250 million ada I have focussed my selections on core development and essential maintenance of community tooling as we enter this critical period of the market cycle. I have tried to balance between large project asks and smaller but still very essential maintenance for existing tooling, with projects that have a proven track record.

I vote in favour of funding the Cardano Summit 2025 and regional tech events. The proposal does provide almost comprehensive global coverage with the flagship event in Europe for the first time in 3 years while North America, South America, Africa and Asia coverage is achieved by proposed 2-day tech events for each region. Regional events each have their own proposed “owner” that each have intimate knowledge of their regions which should hopefully maximise each events impacts and reach.

Having attended satellite events in 2022 and 2023, followed by the flagship event in 2024 I appreciate the importance that these events play in networking and outreach, both within our own ecosystem and out to the wider cryptocurrency ecosystem.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to vote in favour of funding this proposal at this time.

AdaStat is possibly my most used Cardano explorer and I am in favour of funding it’s continued development. They are not a project that has excessively applied or been funded by Catalyst in the past but have kept up with the development of their platform and always open to feedback on socials, often quick to respond and add any new features/changes suggested by the community. This funding request for a 24-month period is reasonable ask.

No one explorer is perfect yet, each offers some features that another might not but AdaStat is arguably one of the most referenced explorers in the age of governance with regards to tracking voting processes and personally I am a fan of their filtering tools when searching for stake pools (especially Mithril supporting pools). Loading speeds on the explorer are good and explorers are often one of the first point of contact for newcomers investigating a chain and so first impressions are everything, I support funding the future maintenance and development of this platform.

As 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES. In keeping with previous voting intentions of keeping total treasury withdrawal expenditure below 250 million ada I have focussed my selections on core development and essential maintenance of community tooling as we enter this critical period of the market cycle. I have tried to balance between large project asks and smaller but still very essential maintenance for existing tooling, with projects that have a proven track record.

Blockfrost has been an integral part to the development of the wider Cardano ecosystem with their API platform. It is encouraging to see their intention to move their platform to a more open-source and decentralised model and their intentions are already visible on-chain with the current progress of their Icebreakers programme. DISCLAIMER: In my capacity as an SPO, HEPHY is currently operating as part of the Icebreaker programme by contributing spare node resources.

As 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES. In keeping with previous voting intentions of keeping total treasury withdrawal expenditure below 250 million ada I have focussed my selections on core development and essential maintenance of community tooling as we enter this critical period of the market cycle. I have tried to balance between large project asks and smaller but still very essential maintenance for existing tooling, with projects that have a proven track record.

Much like wallets, I am hesitant to vote for treasury funds being used to fund explorers when Catalyst may be a better avenue. However, explorers are also one of the first points of call for newcomers and people looking to seek out information about a blockchain and Cexplorer (formerly adapools) has been one of the longest standing in the ecosystem. Significant work appears to have been put in recently towards their 2.0 release and early beta access has shown some impressive improvements, especially in the areas of overall speed of the explorer and of expanded governance features. It is essential for open and participatory governance that ada holders have various useful sources of information in order to inform their decisions. Therefore, I vote in favour of funding this long-standing team with a proven track record.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to vote in favour/against funding this proposal at this time.

I have had a hard time reconciling my vote for this proposal. I am uneasy with treasury funds picking winners and losers in the ecosystem, particularly when Cardano has such a vibrant wallet ecosystem and secondly, that this wallet is not open-source. However, Eternl is probably one of the most used wallets in this ecosystem and has an impressive feature set and history in support of a yes vote.

As I mentioned in my GovTool rationale, participation on SanchoNet during the development of CIP-1694 and Voltaire was scant. It appeared as though most wallets and projects were content with waiting until governance hit mainnet before putting in the work. Eternl was not one of them, they were there supporting SanchoNet and mostly keeping up with all the various network re-spins as features were developed and implemented. To this day, while most support has left SanchoNet following the completion and implementation of CIP-1694 on mainnet, Eternl still provides support for SanchoNet, allowing participants to discover and experiment with Cardano governance in a safe environment. In fact, Eternl is the only wallet that supports Cardano mainnet, PreProd, Preview and SanchoNet networks.

The wallet was one of the first implementors of the Keystone hardware wallet, helping them to finally integrate with the Cardano ecosystem having unsuccessfully reached out to another wallet provider a number of years before. The recent v2 upgrade has been largely well received and has a much more appealing UI to newcomers than the previous iteration.

All in all, while I am apprehensive about deploying treasury funds to a wallet provider I feel as though in this case it has been earned.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to vote in favour of funding this proposal at this time.

As one of two ZK proposals currently requesting funding from the Cardano treasury I think it is important to have teams exploring a range of scaling solutions for Cardano. While a lot of the zero-knowledge focus has been around Midnight it will be good to see some developments in this area for Cardano itself too. The vendor profile appears to indicate a promising team who already have a growing list of achievements in the zero-knowledge space. It is extra encouraging to note that they have committed to making their technology open-source.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to include this item amongst my funding choices at this time.

As stated during my vote for the IO Core Development proposal, I do not agree with bundling large scopes of work into one proposal of this size, forcing voters to agree to funding some elements that they might feel less necessary or restricting them the opportunity to convey which items they would like to see prioritised. However, TWEAG have an impressive record as developers in this space and have contributed in a big way to the development of Ouroboros Genesis and are one of the biggest development firms with an intimate understanding of core Cardano technology outside of IOG itself. It is important to diversify core development across more teams in addition to simply just IOG, operational resilience and greater mind share are both benefits of such an approach.

The PDF document put together by TWEAG was of a high standard and provided a detailed breakdown of the perceived problems, proposed solutions and explanation of their considered costs. Chief concern in my view is the continuation of the work on Ouroboros Peras and as stated in the IO Core Development rationale, interruptions to such key developments right now would be critical.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to vote in favour funding this proposal at this time.

Historically, MLabs has been one of the most prolific teams for both applying and receiving funding via Catalyst and they are a much-respected team. However, lidonation.com currently shows 19 outstanding projects under their name that were approved for funding, one such request is for 487,679 ada for “Advancing Plutarch and CTL”.

At this moment in time, I choose to abstain from using the treasury for further funding until more progress is made on these remaining Catalyst projects. Fund 14 is also imminent which also provides another avenue for this particular project should their treasury withdrawal proposal fail to pass.

This vendor currently has 9 open projects in Catalyst, including 3 from Fund 11 regarding the Typescript Cardano node (which have received 376,000 / 800,000 ada requested to date). Therefore, despite being in favour of increased node diversity for the Cardano ecosystem, I currently have a hard time justifying further treasury funding against the backdrop of these outstanding Catalyst proposals. Therefore, I choose to Abstain at this point in time.

I had initial reservations regarding adding another “middle man” into the equation when it comes to funding projects but I have come to see why an initiative such as this might be necessary. Catalyst rounds are too infrequent to be a sustainable source of funding for ongoing open-source work and evolving situations (such as bug bounties) and simply arguing “we have the treasury” now is an impractical expectation of small open-source teams to have to source and submit a 100,000 ada deposit every time they would like to request funding for completed work. The Cardano ecosystem currently lacks an effective system for smaller-scale and nimble funding of open-source work and bug bounty programmes.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to vote in favour/against funding this proposal at this time.

The Maestro team have a proven track record within Cardano and the wider ecosystem of UTxO-based blockchains. I appreciate some of the concerns raised by others regarding overlap across a number of projects also working on Bitcoin integrations, I feel that Cardano as an ecosystem needs to start paying those that have been successfully contributing to this ecosystem for a while now or risk losing that talent altogether. Maestro’s existing support for Fluidtokens, various wallets and other layer 2 solutions demonstrates their existing value to this ecosystem.

While not originally one of my selections during the Ekklesia budget reconciliation process, I have decided to include this item amongst my funding choices at this time.

As 1 of 3 proposals in this series of 39 treasury withdrawal governance actions that are around or below 100,000 ada I feel that requests of this size are better suited to the recently launched Catalyst Fund 14, therefore I have voted NO at this time.

I vote in favour of continued funding for Catalyst. It has been battle tested and iterated upon over 13 completed funds and is still the best way to fund smaller teams and novel projects in the Cardano ecosystem. Even though treasury withdrawals are now available it would be unreasonable to burden small teams and projects with the 100,000 ada deposit and in turn, DReps and CC who would be burdened with an increased workload by funnelling every conceivable funding proposal to the treasury. Catalyst provides a suitable pathway and milestone-based funding criteria, allowing smaller scale teams and projects to focus on building rather than bureaucracy. Vigilance is still required to ensure that projects aren’t “double-dipping” and accessing funds through both Catalyst and the treasury for the same development items.

As 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES. In keeping with previous voting intentions of keeping total treasury withdrawal expenditure below 250 million ada I have focussed my selections on core development and essential maintenance of community tooling as we enter this critical period of the market cycle. I have tried to balance between large project asks and smaller but still very essential maintenance for existing tooling, with projects that have a proven track record.

While I might not agree with bundling such a large scope of work into one proposal of this size, forcing voters to agree to funding some elements that they might feel less necessary or restricting them the opportunity to convey which items they would like to see prioritised I do recognise the critical juncture that we now find ourselves at with regards to continued development of the core protocol and the timing of the market cycle. Therefore, I vote in favour of this proposal at this time as any disruption in delivery or negative headlines would be far more damaging to progress than to attempt to push for a more refined or modular proposal at this time.

As 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES. In keeping with previous voting intentions of keeping total treasury withdrawal expenditure below 250 million ada I have focussed my selections on core development and essential maintenance of community tooling as we enter this critical period of the market cycle. I have tried to balance between large project asks and smaller but still very essential maintenance for existing tooling, with projects that have a proven track record.

Midgard is a promising development for Cardano and one that offers to showcase development opportunities and scaling technologies that are possible on Cardano and from a community development team rather than longstanding stalwarts Input Output. It could serve as a great demonstration of what is also possible from development teams that haven’t been the core builders over the past several years. With a goal of EOY mainnet readiness, a reasonable budget request when compared to some currently up for vote and with a team of accomplished developers at Anastasia Labs, well-known in the community, I support this proposal.

As 1 of 15 proposals in this series of 39 treasury withdrawal governance actions that I had previously voted for during the budget reconciliation process via Ekklesia I vote YES. In keeping with previous voting intentions of keeping total treasury withdrawal expenditure below 250 million ada I have focussed my selections on core development and essential maintenance of community tooling as we enter this critical period of the market cycle. I have tried to balance between large project asks and smaller but still very essential maintenance for existing tooling, with projects that have a proven track record.

I have decided to vote NO on the 2025 maintenance and development budget info action proposal for the Tempo platform, in its current form at least. I appreciate the work that the team at Tempo have put in to creating an additional governance platform for Cardano, providing an alternative to GovTool and thus helping decentralise reliance on a singular platform.

However, this proposal feels somewhat reactionary to the recent GovTool proposal and while providing an abstract, motivation and rationale, it feels a little light on the details. Previously approved budget info actions have been very detailed and included outlines for proposed budget administration processes. This proposal simply states a requested amount, vaguely outlined as infrastructure and development cost without further breakdowns and points simply to a named administrator without any further detail regarding potential fund management or dispute resolution mechanisms.

I appreciate that another long pause in Catalyst rounds may have left teams scrambling for funding at this point in time but with Fund 14 having just launched I would encourage the Tempo team to apply through that avenue when the opportunity arises, in the short term. If they wish to resubmit a budget info action (should this fail to pass this time) I would encourage them to re-evaluate existing examples for Amaru and Intersect, that have already passed, in order to help inform them to produce a more detailed proposal that might better serve to put any community questions to rest.

I vote YES in support of the proposed budget for 12 months full active maintenance and development of GovTool.

As a cli-based DRep, I have no need for a user-interface like GovTool. If it disappears, I will still be able to check proposals on-chain and vote on-chain as I have done for the past year and a half (including SanchoNet). However, I am able to appreciate the importance of the role it has and can continue to play in Cardano governance, beyond the user-interface that we all see on the website.

GovTool has been there since the beginning, during the days of the Cardano governance testnet “SanchoNet”. While many apps and wallets appeared to wait until governance was on mainnet before putting in the work, GovTool was there building the foundations so that access was made easy for new DReps from day one of mainnet governance and arguably, we wouldn’t have the DRep registration numbers that we have today without it.

While new platforms have emerged alongside GovTool, they do not diminish the need for GovTool. The support for Mainnet, PreProd and Preview networks is rare across all governance platforms and allows access for developers and DReps who want to test out governance proposals in a safe environment without putting real world funds at risk. I may be a cli-based DRep who has submitted protocol parameter updates to both SanchoNet and Preview using the cli but without GovTool support for the Preview network, it would have been much harder to get Preview DRep participation and pass the proposal to fix the dRepActivity and govActionLifetime mismatch earlier this year (see https://preview.gov.tools/outcomes/governance_actions/35b81b424956f018bb4a4bb9e160375c1921a3b40b60a1efc539bcd6b5b20159#0).

The GovTool platform provides increased accessibility to Cardano governance, the main site hosts features like the DRep Directory, Budget Proposals, Governnace Actions (Proposals, Live Actions and Outcomes) as well as hosting documentation for Guides and an FAQs section. Less visible is the constitution sub-domain (https://constitution.gov.tools) that host the Cardano Constitution in an accessible format, Constitutional Committee Members page, ICC/CC voting updates page and the recent CC election portal. Furthermore, GovTool also provides free and open APIs used by many other tools and service providers in the ecosystem that would struggle if the APIs were to disappear.

In conclusion, while many may feel that GovTool needs much improvement, it does already provide much value to the ecosystem and the maintenance of open and accessible governance is vital for Cardano while governance is still essentially in its infancy. I vote to fund GovTool for 12 more months after which the community can reassess the state of Cardano governance once it has had chance to mature properly.

I vote YES on the treasury withdrawal governance action requesting 1.5 million ada for the Amaru Node Development 2025. This treasury withdrawal proposal is made pursuant to the previously proposed budget info action which passed with over 80% DRep approval by active voting stake (Source: https://adastat.net/governances/bd488931f792651fefa9c6fda185a2c6cec83245b51d994e33090ce36e29cc2600).

As the first treasury withdrawal governance action it sets a very high bar with its professionalism and thoroughness. The proposal is excellently formatted with links to all of the relevant information including the proposers, the individuals involved, fund management structures and associated stake addresses. Appropriate diagrams help to make the smart contract setup accessible to non-technical voters and the provision of a publicly available journal regarding financial audits reinforces support for non-technical community members even further.

Node diversity remains one of the few areas of decentralisation left for the Cardano ecosystem to overcome and I am happy to see an endeavour such as Amaru be funded. It boasts a highly competent team, whose track record is well known in the Cardano community and has received strong support with the prior budget proposal. While some have raised concerns regarding ecosystem and development fragmentation with multiple nodes, finally having an alternative to the ultra-reliable Haskell node that has served the ecosystem so well to date may also breed competition and innovation from competing clients.

Should this proposal pass, it will also serve as a pivotal milestone as not only the first Cardano treasury withdrawal but also one that is the first development team to be funded by the community that is not a founding entity. This would serve as a great demonstration to the wider crypto community that if you have a serious project with serious intention, that you are welcome here and can get funded by the community.

I have also taken the extra step of checking the on-chain proposal via the command line to ensure that the values stated in the metadata match those requested on-chain.

Best of luck to the team on their alternative node endeavours.

I vote “YES” in favour of the proposed Cardano Blockchain Ecosystem Budget of 275,269,340 ada that would be administered by Intersect. While I may not agree on the high ada valuation of this budget I am fully aware that we are now in the month of June 2025 and fast approaching a critical window for funding the development and maintenance of the Cardano blockchain and its wider ecosystem. It is also an ada value that leaves some room in the currently active net change limit of 350 million ada for other projects who do not wish to appoint Intersect as their administrator to still be able to propose their own separate budgets.

The proposal is well constructed and has been informed by numerous off-chain processes, including initial project applications through Intersect, followed by voting on the Ekklesia platform, using live DRep voting stake, in order to narrow down the projects included in this proposed budget.

Treasury withdrawal and fund management processes are outlined in the proposal and also serve as a reminder that, even if this budget is approved, it does not automatically guarantee funding for the projects listed within. Projects will still be subject to due diligence and oversight throughout the budget period. Treasury withdrawal proposals will also have to pass with the consent of DReps and the ICC/CC, passing this budget would allow corresponding treasury withdrawals to be proposed as mandated by the Constitution. It would be a progression in the Cardano governance process and not necessarily a guarantee that the proposed budget limit would be reached or required.

I vote “NO” on the budget proposal of 7.5M ada for community builders. While this proposal may seem well-intentioned on the surface, it is lacking in a number of areas. It appears to be a reactionary proposal, hoping to address a perceived shortcoming of the Intersect-led budget process and offering a bundled proposal on behalf of several community development proposals that may lack the governance action deposit to submit their own individual proposals.

However, in doing so it has created an overlap whereby some proposals now feature in multiple budget proposals and causes unnecessary ambiguity for DReps voting on them. It has also become apparent during off-chain discussions that one of the projects included in this particular proposal has previously expressed that they did not wish to appoint Intersect as the administrator for their budget proposal. This in turn raises questions around the level of communication that may or may not have taken place between the proposer and those that they claim to represent before the submission of this proposal.

Finally, while the proposal provides ample supporting evidence, particularly the background voting process and results, it lacks any details of what comes next. This should include an outline of any auditing process and details regarding the administration of the requested funds.

I vote “YES” in favour of the proposed budget for Amaru Node Development 2025. This is an extremely well composed proposal and from a highly respected team in the Cardano ecosystem. It serves as an excellent example of a governance action proposal. It is well-written, making excellent use of markdown which allows for much better readability on sites like GovTool, and provides excellent transparency by providing numerous links to websites, code repositories and profiles of key contributors, as well as a detailed cost breakdown for the requested amount of 1.5M ada. The proposal also provides a detailed administration and reporting framework to improve transparency and provides accountability measures.

The need for the development of alternative node options, in addition to the long-standing and successful Haskell node implementation that has served as the backbone of the Cardano ecosystem to date, has gained significant traction in recent months. The importance of which was highlighted by the recent Node Diversity workshop held in Paris alongside Paris Blockchain Week 2025, demonstrating some ecosystem consensus that such development would be a suitable area for some treasury allocation for funding.

Finally, at the time of voting, the proposal metadata is hosted via the more immutable medium of IPFS where the file remains accessible and the hash has been verified as matching that provided at the time of proposal submission.

I vote “NO” on the proposal for a 300M ada net change limit (NCL) spanning epochs 563 – 635. At the time of voting, despite being hosted using IPFS, the metadata file for this proposal was inaccessible and I was unable to verify the content hash that was provided at the time of submission. This situation highlights a potential issue regarding immutable storage mediums. While files may appear to have a greater level of immutability about them when hosted using platforms such as IPFS, if the node(s) used for pinning such files become inaccessible over time, so does the content. For this reason, it is important that files be pinned to multiple nodes in order to ensure some level of redundancy.

I vote “NO on the proposal for a DeFi Liquidity Budget after an error in the submission process means that the hash values of the submitted proposal and accessible file do not match. This is an important part of the proposal process in order to ensure integrity of the voting process. The issue was identified early on and the proposer has already stated their intention to resubmit the proposal in the future once this one expires and the governance action deposit is returned. Therefore, this is a quick and easy decision in this instance.

I vote “YES” in favour of the proposed 200M ada net change limit (NCL). I do so in accordance with my past reasoning for voting “NO” on the previously passed 350M NCL proposal, believing that amount to be too high at the time and I still do. For example, much of the budget process has been carried out using an ada price of $0.50, a price the market has not seen since November 2024. At the time of this vote, the ada price is $0.77 and has sat in the $0.70-$0.84 range for much of this proposals’ voting period. 350M ada at $0.50 would be $175M while 200M at $0.77 today still accounts for around $154M, therefore I do not consider a potential 200M NCL to be as prohibitive for development spending as it may seem.

Many DReps at the time of the previous proposal for 350M ada stated in their rationales that they were voting in favour of that proposal in the absence of any other alternative and so it has been reassuring to see community members step forward with this proposal. It both demonstrates an example of a well-constructed community proposal and provides a forum whereby DReps are able to have their say on a broader range of net change limit options.

The proposal is well-written and stored via a more immutable medium, utilising IPFS to host the proposal metadata. At the time of voting, the file remains accessible and the submitted file hash matches with the currently accessible file.

I have decided to vote “no” to the second Net Change Limit proposal (9b62b3c632f329016a968ac25211825bb4f84b12461121c7da3aa11df92370f9#0). A Net Change Limit is a requirement before any treasury withdrawals can occur, as mandated by the Cardano Blockchain Ecosystem Constitution. Currently, there are two competing Net Change Limit proposals up for voting. This one, the second Net Change Limit proposal, has suggested a Net Change Limit of 350 million ada for the year of 2025.

The format of the proposal is solid. It provides a clear Abstract, Motivation, Rationale with a Metadata anchor link hosted in the more immutable IPFS format. Supporting links are similarly hosted in this manner and provides both CSV and PDF formats when providing economic models to support the proposals reasonings. The PDF versions provide easier access for voters to analyse as well as a snapshot of CSV files at the time of proposal, which may have data amended or appended in the future.

I am uneasy with the threshold being set to greater than just 50%. This is mandated by the TREASURY-01(a) Guardrail in Appendix I Section 3 of the Cardano Constitution. However, the Guardrails section was considered “out of scope” for large parts of the constitutional workshops and the Constitutional Convention itself. While I understand that many Guardrails are technical in nature and necessarily set by those with more technical expertise, the Net Change Limit is not an on-chain parameter and is to be determined by an info action. Other economic parameters have a 67% threshold and a Net Change Limit should be no different given its very economic nature. Treasury withdrawals have very economic consequences for the ecosystem and should be managed appropriately.

Secondly, a Net Change Limit has yet to even be approved and we have already seen budget proposals taking centre stage and frankly getting out of hand. The process has exposed itself prematurely and raised numerous concerns. The process has highlighted some duplication amongst proposals, exorbitant asks and some clear cash grabs. Meanwhile, we have some large DReps publicly announcing blind support for proposals without any further due diligence, in combination with a concerning rate of ever-increasing concentration of DRep voting power amongst a number of DReps, opening the system up to manipulation the more concentrated that voting power becomes.

I appreciate that a Net Change Limit is required before any treasury withdrawals can happen, as mandated by the Cardano Constitution itself, and is also essential for the growth and development of the ecosystem. The level of budgetary ask put forward by some already, in anticipation of a 350 million Net Change Limit, has demonstrated a need for a lower Net Change Limit to reduce the risk of fiscal irresponsibility. I liked the amounts proposed by the other proposal, 300 million for 2025 and 250 million for 2026. Although only a spending cap and not a spending target, it is clear that this is not how many budget proposals are approaching this right now.

I have decided to vote “no” to the first Net Change Limit proposal (7f320409d9998712ff3a3cdf0c9439e1543f236a3d746766f78f1fdbe1e06bf8#0). A Net Change Limit is a requirement before any treasury withdrawals can occur, as mandated by the Cardano Blockchain Ecosystem Constitution. Currently, there are two competing Net Change Limit proposals up for voting. This one, the first Net Change Limit proposal, has suggested two limits, one for 2025 at 300 million ada and one for 2026 at 250 million ada. I prefer these values over the second, higher proposal of 350 million ada.

However, I cannot vote in favour of this proposal in its current form as it was submitted using a mutable reference which was in fact altered within 48 hours of submission, resulting in a mismatching hash and causing confusion among voters. Although this error was rectified quickly following the public acknowledgement, it nevertheless highlighted the very real risk of using mutable references that could be potentially changed with malicious intentions in the future. Voters should be allowed to vote with confidence in knowing that what they are voting on will not change after they have voted. The confusion caused among voters in first few days of this proposal being live erodes trust and wastes voters’ valuable time.

I would like it to be noted that I have no issue with the proposal attempting to establish a higher mandate for itself. Although TREASURY-01(a) in Appendix I Section 3 of the Cardano Constitution mandates that a Net Change Limit must be agreed with a threshold greater than 50%, I do not have a problem with a proposal stating that it would consider a higher threshold for itself in order to bring it in-line with other economic parameter thresholds of 67%. It would still be greater than 50%, meeting the constitutional requirement. I do not consider it an attempt to change a threshold when it is simply a self-imposing one on one particular info action.

In closing, I would also like to convey an appreciation for the attempt to submit multi-year Net Change Limits. We are already almost one-third of the way into 2025 and appreciate the level of predictability to budget forecasting that a proposed limit in advance of 2026 would have given. Should this proposal be resubmitted with a more immutable reference link and the content not change during the voting period then I would be inclined to vote yes in the future.

While I am grateful for the efforts that have gone into the creation of this roadmap and largely agree with the content of the proposal submitted on-chain for DRep consideration, understanding the importance of setting a clear direction for the future of the Cardano blockchain ecosystem, I have some reservations around the implementation/use of the Info Action in this instance.

Firstly, the proposed roadmap linked in the on-chain proposal is not an immutable source. (https://product.cardano.intersectmbo.org/vision-roadmap-2025) While attempts have been made to remedy this concern, post-submission, by hosting a “static” version of the initial proposal (https://product.cardano.intersectmbo.org/vision-roadmap-2025-static) it still raises the issue of the immutability of governance proposals. The proposal and linked content both acknowledge that the proposed roadmap will evolve over time, for example, the linked roadmap states, “The vision and roadmap represents a high-level overview and will be further refined and iterated upon based on ongoing research, community feedback, and technological advancements. It is based on the results of the TSC survey.” With this in mind, I feel that it would have been helpful to at least provide a link to an immutable copy of the original intent, for reference in the future and to provide some level of accountability throughout the proposed development process.

I appreciate the irony that this rationale is hosted on Github and not IPFS but my vote decision will be permanent on the blockchain regardless of this rationale. It is different to a proposal that is actively being voted on, where the very content may evolve away from what was initially voted on.

Secondly, the submitted governance action also states, “While the referenced roadmap develops, Dreps should consider submitting multiple votes to signal approval across versions” but does not outline how this proposed revision process would work. Who will be expected to raise these future Info Actions for voting on these potential changes and how often is the roadmap expected to be reviewed using this particular feedback channel during its lifespan?

Split between my general support for the proposed roadmap content and the conflicting thoughts regarding the use of the Info Action in this instance, with its mutable references, I have decided to vote abstain at this time.

I welcome the initiative taken by those that have submitted this proposal and happy to see the first governance action submitted by the community following the Plomin hard fork.

The governance action proposes a reduction in the treasuryCut parameter from 20% to 10%. The governance action id is: 941502b0aa104c850d197923259444d2b57cab7af18b63143775465aaacc84f5#0.

The proposal highlights a potential increase in staking rewards as part of its mathematical justification which would be a welcome impact. Cardano is first and foremost a Proof-of-Stake system which derives its security from stake participation. If a boost to staking rewards leads to an increase in participation, then it is a positive for network security. However, it should be noted that staking rewards have not been 4% for a long time. Like Bitcoin, Cardano has its own reward halvings except that the issuance rate of ADA decreases along a curve and not with sudden drops at roughly 4-year increments like Bitcoin has. As a result, the decline in block rewards over time often goes unnoticed compared to the almost ceremonial anticipation that is witnessed around Bitcoin halving events. Therefore, staking APY is more accurately nearer 2.5-3.0% than it is to 4%.

Secondly, the recent Cardano Economic Parameters Report from the Cardano Foundation highlighted the fact that once all other network variables have been taken into consideration that the actual treasury growth rate has been nearer 25-35% over the past 4 years, higher than the 20% treasuryCut parameter would suggest when considered in isolation. Therefore, a reduction in treasuryCut may not be as drastic as it first sounds. It would be interesting to see it modelled out in the context of all the other variable factors to in order to see an accurate indicator of where true treasury growth would be.

That being said, it should be noted that this parameter change was considered in isolation and could have been served better with the kind of modelling suggested previously. I think explaining to the wider community that the treasury growth isn’t solely dictated by one parameter and that it may well currently be higher than 20% may have served to ease some of the backlash against what has sometimes been perceived as a drastic reduction.

The Parameter Committee report on the proposal highlighted that the staking reward boost effect from reducing treasuryCut may benefit larger stakeholders, larger pools and exchanges more than it would benefit smaller pools and stakeholders. This potential to contribute towards a further centralisation of ADA holdings should be considered.

For example, if the goal was to boost staking rewards, another way of doing this without centralising ADA holdings would be to consider a further reduction in minPoolCost. This would allow smaller pools to boost their APY to a more competitive level more closely in-line with mid to large-sized pools. Older, larger pools benefitted from minPoolCost being a smaller percentage of block rewards, allowing them to generate a more positive looking lifetime APY. New pools in the ecosystem have to deal with a minPoolCost that is a much higher percentage of block rewards and thus encouraging stake participation for them is much more difficult with a less attractive APY. For example, a small pool reducing minPoolCost from 170 to 100 could see a 25% boost to their delegators APY according to the recently updated cardano.org/calculator. Much higher than the 12.5% proposed by this treasuryCut reduction. Larger pools would see less of a boost, thus reducing the risk of further increasing ADA concentrations that this parameter change may have.

Finally, and most notably, the proposal lacks a reversion/recovery plan as mandated by the Constitution. Although it can be argued that there is less of a security concern around this particular parameter and some common sense would say to “just change it back if need be” and let it slide this time, it raises the question of to what extent do Dreps have to also apply the Constitutionality of a proposal to their evaluations?

I am not against the principle of lowering the treasuryCut parameter and would be comfortable with seeing it pass in the future. Overall, it is a solid first effort as a community-led proposal. I just feel that it would benefit from a recovery plan, for constitutionality, and a little further evidence/modelling to help ease the concerns of the Dreps regarding the true extent of the reduction to the growth of the treasury and it would likely pass in the future. At the end of the day, a proposal has to pass both DRep and ICC/CC votes and at this stage in the voting it is falling short of both at the moment.

I vote “No” on the proposal in its current form.

I have decided to vote YES in favour of replacing the Interim Constitution with the delegate-endorsed Cardano Constitution. However, I do so after much deliberation and with some reservations regarding the processes by which we have arrived here and considering the future.

Firstly, I would like to acknowledge the hard work and dedication of all Delegates, Alternates and Constitutional workshop attendees who have passionately fought to have their voices, and those of whom they represented, heard in this Constitution. Often in the face of some serious “shepherding” of the conversations.

Secondly, a thank you to community-built tools such as cgov.app by MadOrkestra who worked up to the eleventh hour in order to ensure that community members could be heard when they may have not been able to attend in-person events. The passion of the Cardano Community is one of its’ greatest strengths and will be a decisive factor in the success or failure of this ecosystem.

The delegate-endorsed Constitution is an improvement on the currently implemented Interim Constitution, both in terms of content and validity, given that no community-wide vote was held regarding the initial implementation of the Interim Constitution.

Given that the passing of this Constitution also opens the door to the potential ratification of future New Constitution, Update Constitutional Committee and Motion of No Confidence governance actions as per Interim Constitution Guardrail INTERIM-04, the current distribution of DRep delegation should be considered.

I feel that greater education efforts are required here. Simply telling ADA holders to “pick a DRep or Auto-Abstain” in order to withdraw their rewards without educating them on the impact of “Auto-Abstain” on the voting process has thus far been somewhat irresponsible. We now have almost 70% of all voting-registered stake addresses accounting for 50% of all DRep-delegated stake not participating in governance thanks to this current approach. At this moment in time, a minimum of 26 DReps could reach a 67% threshold and the fact that one of those DReps currently has a 12% thumb on the scale is a cause for concern. Thankfully, the tricameral model of Cardano governance means that SPOs should be able to mitigate any potential issues from outsized bad actors attempting to take advantage of the current levels of distribution.

While this vote is in support of the question raised in the Info Action it is important to provide further context and education on the subject. The Info Action refers to the K-parameter and while this has been a long-disputed topic amongst the Cardano community, namely SPOs and similarly technically minded individuals, it has also been something of a relative mystery to the everyday ADA holder. Secondly, this parameter is now known as stakePoolTargetNum, as found in Appendix I: Section 2.4 of the Interim Constitution which pertains to Technical/Security Parameters. Arguably, this is a much more accessible and identifiable name for the everyday user to understand also.

The parameter in question determines the ideal number of stake pools when the system is in equilibrium. As a result, it also determines the saturation point (or size) of a stake pool. This is calculated by dividing the current circulating supply of ADA by the stakePoolTargetNum (formerly K) value.

When the parameter was increased to 500 on 6 December 2020, the pool size limit was c.64M ADA. Following the increase in the circulating supply in the years since then, the pool size limit today is c.74M ADA. This has meant that a multi-pool operator of 5 or more pools has, in effect, almost gained the potential to amass the delegation of a whole extra pool at December 2020 levels without having to deploy any extra infrastructure.

While this vote supports another look into increasing the parameter value, I do not think that that it should be as drastic as the 1000 often put forward by many.

Example stakePoolTargetNum values and their corresponding pool size limits:

500 = 74,708,463 (current)
588 = 63,538,362
750 = 49,805,642
1000 = 37,354,231

A subtle stakePoolTargetNum (formerly K) increase to 588 would reset pool size limits to December 2020 levels and would be a more sustainable change so as to minimize the impact on the slow to move stake delegation that has become apparent in the years since Proof-of-Stake went live on the Cardano mainnet. Higher values could lead to problems like pool splitting which could increase infrastructure costs, over-saturation of single pools due to slow redelegation of stake and a reduction in rewards across the board.