Cardano Critical Integrations Budget
59 SPOs voted · 1 with a rationale
Open a row to read the rationale.
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- AbstainNo rationale
- YesNo rationale
- YesNo rationale
- YesRationale
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.
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale