Hephaestus Stake Pool

I vote YES on the hard fork initiation action titled “Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)” (fdd468da5cc4ac...344d#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 Info Action titled “Approve Cardano Foundation as New Managing Entity of Project Catalyst” (b518efa4665939...4a1e#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 YES on the Info Action titled “Cardano Budget Process Framework (facilitated by Intersect)” (e9693ed6b6465b...98fa#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 am voting ABSTAIN on the governance action to set a “Net Change Limit of 300 Million ADA for Epochs 613–713” (gov_action1wwj...tft9tp).

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 vote to ABSTAIN on the proposal for the “Net Change Limit (Epoch 613 to Epoch 713)” (gov_action1m3x...4jsr7q) 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_action15ce...qr7jkr) following the recent enactment of the Cardano Blockchain Ecosystem Constitution v2.4 (gov_action1jxn...p6vp3p).

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 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 (eb8ef28ca80dbd...8ccd#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.

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.

I vote YES on the budget info action to reimburse the proposers of the Ikigai info action (59fd353253eb17...c1db#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 (59fd353253eb17...c1db#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 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.

Although SPO votes are not considered for budget info actions, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the associated proposals see transaction hash: 08d58719267b43b1e2adb914e5f70a82ab386ef7a06ff515ce7055ff480044fe.

Although SPO votes are not considered for budget info actions, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the associated proposals see transaction hash: eaf44f50a6e4317340279dac3c23bcbc27172e0c46df029d34d5201657a1f54c.

Although SPO votes are not considered for budget info actions, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the associated proposals see transaction hash: eaf44f50a6e4317340279dac3c23bcbc27172e0c46df029d34d5201657a1f54c.

Although SPO votes are not considered for budget info actions, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the associated proposals see transaction hash: eaf44f50a6e4317340279dac3c23bcbc27172e0c46df029d34d5201657a1f54c.

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.

Although SPO votes are not considered for budget info actions, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the associated proposals see transaction hash: ffe6487f7472f80ce86dad43a3ab13081d129e32acb222d81fc5b2fcba712310.

Although SPO votes are not considered for budget info actions, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the associated proposals see transaction hash: ffe6487f7472f80ce86dad43a3ab13081d129e32acb222d81fc5b2fcba712310.

Although SPO votes are not considered for budget info actions, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For a detailed DRep rationale regarding the proposed 275 million ada budget to be administered by Intersect see transaction hash: f817f64c3a8f048859a015095d4371bbfc20bb9aac4100de8aa18cb31a2cf4d2.

Although SPO votes are not considered for Net Change Limit (NCL) and Budget actions, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the associated proposals see transaction hash: 80e9e852c68ae53fa95d9dce90d27f4934b0c351216cbea415e8d60e22e48453.

Although SPO votes are not considered for Net Change Limit (NCL) and Budget actions, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the associated proposals see transaction hash: 80e9e852c68ae53fa95d9dce90d27f4934b0c351216cbea415e8d60e22e48453.

Although SPO votes are not considered for Net Change Limit (NCL) and Budget actions, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the associated proposals see transaction hash: 80e9e852c68ae53fa95d9dce90d27f4934b0c351216cbea415e8d60e22e48453.

Although SPO votes are not considered for Net Change Limit (NCL) and Budget actions, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the associated proposals see transaction hash: 80e9e852c68ae53fa95d9dce90d27f4934b0c351216cbea415e8d60e22e48453.

Although SPO votes are not considered for Net Change Limit (NCL) and Budget actions, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the associated proposals see transaction hash: 80e9e852c68ae53fa95d9dce90d27f4934b0c351216cbea415e8d60e22e48453.

Although SPO votes are not considered for a Net Change Limit (NCL) vote, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the first two NCL proposals see transaction hash: 94645f03b921e7d6c5ba9aa1bcc27bebcae7ee5f785d7ad6f6bdb1ad625a98fd.

Although SPO votes are not considered for a Net Change Limit (NCL) vote, the ledger nonetheless allows SPOs to vote on all info actions. This vote is submitted to the chain in order to maintain the pool voting record. For detailed DRep rationales regarding the first two NCL proposals see transaction hash: 94645f03b921e7d6c5ba9aa1bcc27bebcae7ee5f785d7ad6f6bdb1ad625a98fd.

The info action (56f39054758f1a...c636#0) explicitly calls for a DRep vote on the proposed '2025 Vision and Roadmap'. While the Cardano blockchain allows for both DRep and SPO votes on Info Actions, this abstain vote simply serves to maintain my SPO vote record while respecting the intention of the proposal to gather feedback from DReps specifically.

HEPHY pool is voting YES on the Plomin hardfork governance action. Having considered ecosystem readiness including exchange liquidity, SPOs and block production, DRep distribution and finally tooling/wallets/dApp readiness as of 20 Jan 2025 1500 UTC.

Exchange liquidity:
61.26% of exchange liquidity has reported as ready with a further 24.84% in-progress giving a total of 86.11% soon to be ready.

SPOs:
86% of blocks this epoch have been validated using 10.1.4 nodes, mitigating any potential risks previously identified with nodes 10.1.1-3.

Tooling, wallets and dApps:
The majority of tooling, wallets and dApps have reported as ready.

DRep distribution:
The only reservation remaining around the hardfork is DRep distribution and ADA holder participation, as the DRep role will become fully active following the hardfork. 87.11% of ADA is currently not actively taking part in governance while there are some centralisation concerns regarding the distribution of actively participating ADA.

16 DReps could currently reach a 60% threshold needed for future hardforks.
21 DReps could currently reach a 67% threshold needed for no-confidence votes, parameter changes and treasury withdrawals.
28 DReps could currently reach a 75% threshold needed for updates to governance parameters and the constitution.

Given the current readiness of the wider ecosystem and the liquid nature of Cardano governance, HEPHY is voting YES to move forward with the hardfork. This hardfork will enable the full set of governance features as outlined in CIP-1694 and will allow the ecosystem to move on from the current Interim Constitution and Interim Constitutional Committee.

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.