π Lanningham

I am voting YES on governance action 3f0ff0d848cab1036621f92732fef5ea1cb6466305889777ee95496933dfd1e4#0.

First, I know of no potential conflict of interest here. I will receive no funds, free tickets, or anything else from this proposal. I'm not even sure whether I'll be able to attend the event this year or not.

With that out of the way, I feel comfortable voting YES on this proposal, as it focuses directly on placing Cardano into arena's where it is usually not. A presence at events where we have a chance to attract new businesses and advocates is, in my opinion, neccesary (if not sufficient) for our survival and growth as an ecosystem. If we continue to focus on events or spending that simply amplify and excite those who already believe in Cardano, we will surely expire in a dazzling conflagration.

The presence at this event should focus relentlessly on:

• Successful, high volume dApps and opportunities. The current star of the show is Strike, but there are many other unsung gems, and new products such as RealFi
• Capability upgrades. Leios, Peras, Better UX through Aiken
• Existing advantages. UTxO, Determinism, Uptime
• Collaboration over competition. Midnight, LayerZero, USDCx.

You can find a larger writeup justifying my vote here.

I am voting YES on governance action 73e171a4c0730b4b59ecae271ab89f12a9d56360b02920e1f95107dbdc1d6762#6.

I came very close to voting NO on this proposal, as I believe many of the things outlined in the roadmap to be a misallocation of resources.

Continuing to evolve Plutus, the underlying runtime and execution model on which all dApps rely, is essential in the long term. It has come a long way since 2021, but still has many glaring gaps, and this proposal does include several of those.

However, it also continues to invest resources in things that I think are superfluous or distractions. Plinth is (through no fault of the team) not a serious contender for the construction of most dApps that have yet to be built. Those serious about performance will reach for lower level primitives like Plutarch or hand-rolled UPLC. And the vast majority will be written in Aiken, Pebble, Opshin, or others.

Additionally, another team has formalized the CEK machine and ledger rules in Lean. Agda is the less-approachable cousin, and to me represents redundant and duplicated work.

Overall, I want to see the new builtins described in the proposal, and they alone (barely) justify the cost. My hope is they will unlock a new era of efficiency, much as reference inputs and inline datums did in the past. I want to see the underlying execution framework evolve and reduce fees for users. And it's clear to me, from looking at the advocacy on social media, this is where the teams head is really at.

My hope is that, if this proposal passes (as seems likely right now), the team has liberty to evaluate and restructure their roadmap. Stay flexible to the needs of the developers, rather than locking in a full years roadmap up front. If these work items finish faster than expected, devote those resources to the things Phil called for here, instead.

You can find a larger writeup justifying my vote here.

I am voting NO on governance action 73e171a4c0730b4b59ecae271ab89f12a9d56360b02920e1f95107dbdc1d6762#4.

First, I don't believe I have a conflict of interest on this proposal. I am not set to receive any funds from the proposal, nor do I consider it a competitor to projects Sundae Labs is building. Some might see Midgard as a competitor to Gummiworm, for example, but neither Philip DiSarro nor I view it that way. In fact, we are working closely together to make sure that Midgard and Gummiworm complement eachother and integrate deeply; and we're currently working on a version of the SundaeSwap protocol that can be deployed to Midgard.

Given the above, and Sundae Labs history as the first company to successfully execute smart contracts on Hydra; the first company to demo a working application on Hydra; our open source contributions to Hydra; our involvement in the Hydra Doom project; and our role in the Glacier drop, Hydra has a place near and dear to my heart.

Unfortunately, I cannot vote Yes on this proposal. In particular:

• Continuing to invest heavily in Hydra has hit a point of diminishing returns. I believe that Hydra should be supported by and work at the direction of those who are building businesses on top of it. If funding is directed to Hydra, it should be in driving adoption in more businesses, not in continuing to iterate on the core.
• Hydra is not a suitable technology for most forms of DeFi; Despite the branding, for example, "Delta DeFi" is a (fantastic and useful) centralized exchange. By proposing that one of the deliverables here should be a "reference implementation for DeFi", I fear the proposal fundamentally misunderstands either Hydra or DeFi.
• The proposal is an Omnibus proposal, covering three workstreams that appear to only be tangentially related, in an effort to trade on the recognition and excitement for one to fund the other.

I would be far more supportive of a proposal that focused exclusively on the Data Availability solution hinted at in this proposal. Alternatively, I would support a Hydra specific proposal that focused on finding and supporting business that would be directly suitable for Hydra, such as business-to-business settlement, gaming, point of sale settlement systems via Maravedí, and driving improvements to the Hydra core based on direct engagements with said ventures and their revealed needs.

Ultimately, it's painful to vote no on this. Hydra has been a key inspiration for much of our ambition, and has the potential to unlock many exciting things for the Cardano ecosystem. However, I must vote my conscience, and after carefully considering this proposal, I believe this would take Hydra in the wrong direction and misallocate public resources.

You can find a larger writeup justifying my vote here.

I am voting ABSTAIN on governance action 73e171a4c0730b4b59ecae271ab89f12a9d56360b02920e1f95107dbdc1d6762#0.

Initially, I planned to vote No on this proposal.

Historically, IO's particular expertise has not been aligned with developer experience. Organizationally, they do fantastically robust engineering, but produce terrible user and developer experiences. This is not a criticism of IO: no organization can do it all. But if you look at their track record with Plutus, cardano-cli, breaking API changes, the PAB, etc. it is clear that having the people who build the core infrastructure also build the tools needed by the layer above them is a failing premise.

I believe that the proposal as written suffers from xkcd/927, it overlooks existing tools, built by companies already trying to solve these problems, convinced that this time will be different.

I would be much more supportive of a proposal that focused on:

• Hackathons, which historically IO has done well at organizing
• Providing assistance to existing tools, through engineers and deeper integration with infrastructure tools (as is already happening with UTXO RPC support in the node)
• Giving existing tools Discoverability and Legitimacy with an official endorsement

as I believe this would be a far more effective and higher leverage way to improve the developer experience for Cardano.

However, after discussing with the project manager assigned to this proposal, Robertino Martinez, I have decided to vote abstain instead.

It is clear that Robertino has a better perspective on this than his proposal implied, and he was receptive to my feedback. So while I can't vote on this proposal as is, I also wouldn't be heartbroken if it passed, as I believe Robertino could steer it in effective directions.

If the proposal fails, as seems the current trend, I would strongly support a revised proposal that focused on amplifying existing efforts.

You can find a larger writeup justifying my vote here.

I am voting YES on governance action 73e171a4c0730b4b59ecae271ab89f12a9d56360b02920e1f95107dbdc1d6762#8.

I am voting yes on this primarily because of the opportunity to generate perpetual returns for the Cardano treasury.

The 5% perpetual return is equivalent to a 5% unvoiced equity deal at ~60m valuation. Competitors in the space have raised at higher valuations, and I believe the technology described, the chance of success, and the benefit to Cardano to all be pulling in this proposals favor.

However, my Yes vote comes with Caveats after discussion with Omer Husain, the lead on this project.

I expressed concerns that the 20% post-EBITDA terms are highly manipulable by the team, and could be extended indefinitely with little return for the treasury. Omer's response was that there is little incentive to manipulate the EBITDA in that way. He argues that the 20% is high enough that the incentive is to pay back the loan as fast as possible; increasing OpEx to defer repayment would simply be burning their own cash rather than growing the business.

He suggested a structural backstop: if full repayment hasn't been reached within x years of first positive EBITDA, the repayment basis switches to 10% of net revenue, rather than post EBITDA. I also suggested a flat maximum term on this phase.

I expect the final contract drafted with Intersect to include such a term, or any revised proposal to explicitly state this.

My other concern is on liquidation terms. If the company is liquidated, I expect the Cardano treasury to have preferred repayment rights for any assets, ahead of, or at least pro-rata preferental compared to, any other investors or equity holders.

I think it is fair to demand that, if you're receiving public funds from the treasury, the treasury have first repayment rights.

I expect the final contract drafted with Intersect to reflect this as such, or any revised proposal the explicitly state this.

You can find a larger writeup justifying my vote here.

I am voting YES on governance action 73e171a4c0730b4b59ecae271ab89f12a9d56360b02920e1f95107dbdc1d6762#2.

While Sundae Labs has been a consultant on Leios R&D work in the past, we have no ongoing consulting work, nor do we currently have the Haskell expertise required to deliver on this directly. Therefore, I do not forsee a direct conflict of interest.

I am voting yes on this, as I believe the capacity increase represented by Leios is essential, not just for ultimate sustainability of the protocol, but for the economic relevance of Cardano as a platform.

That being said, I have a severe criticism of this proposal in line with something I've been saying for over a year now.

Simply building increased capacity is wholly insufficient if nobody uses that capacity. We cannot simply take a "build it and they will come" appraoch to the delivery of Leios. This will shift the burden for demonstrating that value to already starved and resource constrained product focused organizations building on Cardano.

This proposal is severely lacking a clear, concrete, and budgeted line or plan for driving adoption of the chain in light of the improved capabilities.

IO is largely a technical organization, and so I recognize that their strengths may not be in business development or marketing. Other founding entities were supposed to carry that burden and (without arguing about specifics) have only done so to limited success.

However, that is exactly why IO needs to be clear about what their plan is for manifesting that expertise.

The request for funds here, and the steep allocation to developer resources, without so much as a "In conjunction with organization X", or "by hiring consulting firm Y" to address this is a major and concerning oversight.

IO doesn't need to be the entity, themselves, that is attracting businesses to build on Cardano in the wake of Leios; but in order to justify such a steep spend, they must have the mentality and plan to find the people who will:

• Run Hackathons or large scale stress test events to demonstrate capacity
• Secure MOU's from businesses who have previously been skeptical or unable to build on Cardano
• Offer small grants or technical consulting to businesses interested in trying the waters

And other such efforts.

I'm voting yes on this proposal because at the end of the day this is a correctable oversight, but the success of this initiative will ultimately be entirely contingent on this missing component. If there is any flexibility when drafting the legal contracts with Intersect for oversight of the funds, I strongly encourage reallocating a portion of funds to this half of the problem space, rather than expecting or hoping that others will solve it independently.

You can find a larger writeup justifying my vote here.

I am voting ABSTAIN on governance action 73e171a4c0730b4b59ecae271ab89f12a9d56360b02920e1f95107dbdc1d6762#7.

I have had discussions in the past, and have a reasonable expectation, of Sundae Labs being an external vendor that could help with the delivery of this proposal. Thus, I must abstain.

That being said, I believe the proposal is a good one, with the caveat that I am forced to mentally penalize it due to being an omnibus proposal.

It funds public good infrastructure in the form of Project Cayley and the blockfrost free tier.

Lack of public funding for the would force blockfrost to raise prices on other customers to subsidize the free tier, or remove the free tier entirely. Both, in my opinion, would cause more than the $900k asked for. Additionally, the $900k cost is within a reasonable range, if on the higher end of the spectrum, for what such infrastructure and staff are likely to cost.

With regards to Ceyley, I believe the proposed indexing structure is a good one, and directly addresses the need for the first category of public spending. By reducing infrastructure costs, Blockfrost makes the free tier more sustainable and self funding, and more decentralized and robust.

You can find a larger writeup justifying my vote here.

I am voting YES on governance action 73e171a4c0730b4b59ecae271ab89f12a9d56360b02920e1f95107dbdc1d6762#1.

While I would normally penalize this proposal for being an omnibus proposal, the three initiatives are synergistic, and bundling them reduces risk and saves on costs.

Overall, the three workstreams provide intense value:

• Account Address Enhancement allows for richer, more flexible dApp designs that address deep usability concerns within Cardano. Beyond just the stated use case, dApp developers will likely find many creative use cases for this upgrade.
• Enabling a multi-asset treasury would also unlock more flexible and sustainable asset management models for dReps. I will add that I expect this to include not just the ability for the treasury to hold these funds, but extensions to enable smart contracts controlled by DReps. My vote is contingent on that clarification.
• Native babel fees support, built on top of the DMQ and Nested Transactions work being delivered under last years budget, is a natural extension. While many user-land solutions have been built, the reason they've seen no adoption is because without tight integration into all aspects of the node and downstream tooling, the adoption curve becomes too difficult to surmount. Similarly, ledger integration is neccesary to keep the platform neutral, rather than a solution built by (and thus paying fees to) any one particular third party.

I think IO is currently in the best position to deliver this, in conjunction with the third parties mentioned in the proposal, given their history of node development. That being said, the timelines for delivery on past projects has left something to be desired. As a software engineer myself, I'm the first one to give timeline slippages the benefit of the doubt, but I believe IO and the larger Cardano community have built up a culture of decision paralysis, rather than a culture of delivery. I hope to see this improve, and my evaluation of IO's proposals next year will be benchmarked around how successful they've been in overcoming these long timelines. We've invested heavily in high assurance engineering, it's time for that to start paying dividends.

You can find a larger writeup justifying my vote here.

I am voting YES on governance action b11527fbcdc9d41e8f497de64a029a18673a5eefc413718459046f0b7a1a6656#0.

I came very close to voting NO or ABSTAIN on this proposal, but ultimately came in as a YES.

(Nearly) All arguments for node diversity that I made in my Dingo vote apply year as well.

However, here is why I was on the fence and this was a much harder decision to make for me:

1. Feasibility
   I believe the vision of having a full typescript node that runs in the browser is a pipe dream and likely to fail for many reasons:

• Communication challenges between the browser and other nodes; unless we fundamentally change all node implementations, the browser node will always be dependent on a separate backend relay.
• Performance challenges; The performance budget for Cardano nodes, is already challenging to hit: a node has to produce a block within 1 second, propagate blocks efficiently, evaluate many chains, hold a lot of state in memory or persisted to disk, etc; While not insurmountable for typescript currently, it's a huge engineering lift. And this likely becomes impossible to do safely for the full Leios protocol.

In the end, despite high chance of failure in the end goal, I think this is a case of landing among the stars. Even if the project fails, it will produce artifacts that are well worth the cost:

• Additional skilled engineers focused on contributing to conformance testing and specification of the Cardano protocol
• Useful parsing and validation libraries for use in the browser
• Light-wallet / trustless validation primitives for dApps

1. Overlap

In my estimation, there is a spiritual overlap between the deliverables in Intersect administered Gerolamo vote from last year and this one.

Consider the following excerpts from proposal deliverables from both proposals:

2025 budget:

The goal is to have a fully functional light node that can run in the browser and can be integrated in dApps and wallets.
This proposal
a production-ready light node (Gerolamo);

In the end, last years ask was sufficiently small, and "production-ready" load bearing enough that I'm willing to overlook this.

1. Delivery risk

I am not as certain about Harmonic Labs' ability to deliver as I am of Blink Labs on the Dingo node. Based on milestone submission for the previous Intersect administered project, milestone submission has come in consistently late.

Additionally, a cursory glance at the teams Github seems to indicate they have 3 developers currently. This proposal asks for funding for 10 engineers (it doesn't specify which of these are already part of the project vs net-new additions, so charitably, this is covering the existing teams salary and 7 new hires). However, running a team of 3 engineers, and running a team of 10 engineers, are fundamentally different beasts; Unlike Dingo, where the team has practical real-world experience running larger teams and big open source projects, HLabs' ability to scale their team is unproven. Hiring that many engineers in a short period of time adds additional risks. They also run the risk of stretching themselves thin with other projects, such as their unreleased DEX and unfinished Catalyst projects.

In the end, I know the engineers involved are competent (by their existing deliveries on other projects) and well intentioned. Their 3rd party oversight board consists of respected community members, using well tested and familiar contracts (written in part by myself). This limits the risk to opportunity cost (the risk that we allocate funds out of our NCL that cannot be used elsewhere), not risk of lost funds.

1. Omnibus

I have a documented preference against omnibus proposals; Lumping Gerolamo, Pebble, and maintenance on existing libraries here is immediately distasteful for me.

That being said, the 3 projects likely have a high degree of overlap, and so I can see why pooling resources for them is valuable.

1. My personal conflict of interest

If I'm being totally honest, I have a conflict of interest here. This is why, had I decided the balance of the above was pushing me towards a no, I likely would have voted Abstain instead. Michele and I do not get along, and I do not believe he engages in protocol level discussions in a healthy way. He escalates tensions, discounts hard work and analysis from smart thinkers if it doesn't align with his goals, and has a tendency to assume that if he can't see the utility in something, it doesn't exist.

Him and I are also building competing products with different priorities, which doesn't do either of us any favors in giving the other a benefit of the doubt.

(And if you're reading this, Michele, no, I'm not talking behind your back. I can't tag you in on-chain metadata, nor do I consider speaking publicly about you in a way consistent with feedback I've tried to share with you before to be 'talking behind your back', nor is it censorship to reserve my energy for interacting with people who don't exhaust me; Your accusations to this effect fall flat because I've never tried to hide how my opinion about you has evolved over time in response to your own behavior, even if that has been in public discussions with other people. For what it's worth, I don't bear you any ill will, and hope you're successful in your endeavors for the benefit of us all. I just don't have the energy to participate in the kind of energy-draining "proof-by-exhaustion" argumentation tactics that you sometimes resort to.)

In the end, however, the reason I have a framework to evaluate proposals is exactly to identify these personal biases, be transparent about them, and attempt to correct for them in the way I vote. I don't believe I believe all of the above reservations are valid, and still don't override the existential threat to Cardano that is our reliance on a single node.

You can find a larger writeup justifying my vote here.

I am voting YES on governance action f35285db3c4e085ad331843b3007737952b8a322bb3216311edc37fdf44ad3da#0.

Dingo, a Go block producing node, is a clear net-value-add to our ecosystem, and Blink Labs is the only company that can deliver it.

Because of the security properties of Ouroboros, the Cardano network needs to reach a state where no single node has more than 50% of the stake. Without that, any single bug in the Haskell node threatens to permanently ratify a bad ledger state. For example, a bug in the Haskell node could ratify a ledger state with more than the 45 billion max supply of ADA, or corrupt wallet balance. We're lucky that the high-assurance engineering employed by Input Output has insulated us against such failures for 8 years, but the law of large numbers (and the increasing pace of innovation and change from Peras, Leios, and other large initiatives) tells us that it will happen eventually.

Such a bug would likely completely and permanently destroy trust in the network. Since we are already fighting with our hands tied behind our back in the arena of public perception, the network would likely not survive such a blow.

Instead, if the network operates with a diverse set of nodes, all with less than 50% of the stake, we are innoculated against such bugs. If the haskell node had 45% stake, and several alternative nodes had 55% of the stake, then such a bug would be rejected by the rest of the network well before making it past the 2160 block event horizon that makes it permanent.

Yes, Amaru is working on building an alternative node implementation in Rust, but a single alternative node alone cannot bring the stake distribution below 50% in the long term. Each additional node that gets built makes it easier to spread the stake across node implementations and reduces our risk of this kind of catastrophic total failure.

Of course, such diversity brings with it it's own risks and challenges; A bug in a node with a large portion of the stake can cause a short lived fork, which is economically disruptive, as we saw last year in the pig-chain fork. As such, we need these alternative nodes to be built by competent and proven teams who understand the responsibility and dangers of a non-conforming node. We need engineers who are dedicated not just to implementing what we know about the behavior of the Cardano node, but finding and implementing what we don't know.

For example, this is why I remain skeptical of AI driven node implementations. AI is very good these days, I use it every day to accelerate the work I do. But their skill is deceptive. Given the way they are trained, they are very good at implementing the things that have already been implemented many times. It is very easy for an AI coded node to appear to be progressing very quickly, implementing the things that are well known surface areas by this point: node to node protocols, node to client protocols, even a first pass at ledger validation.

But the bugs and subtle differences that lie off the beaten path can prove nearly incredibly damaging. These are the untrodden path, and it is much harder for an AI alone, without the guidance of an experienced engineer with deep Cardano expertise.

Indeed, by funding multiple teams, each with their own perspective, each building in a different language, but all collaborating and sharing notes, we dramatically increase the likelihood that all such efforts will be successful. The blindspots that a rust engineer, or one architectural design might have can be revealed by a completely different implementation. Because these teams share test suites and notes, each initiative is strengthened by the others, up to a point of diminishing returns.

This is why I believe it is valuable, even essential, to fund teams like Dingo.

You can find a larger writeup justifying my vote here.

I am voting YES on governance action e9693ed6b6465b2b46daaf641486a12b4b2946081634b5967b9d98897b0598fa#0.

I believe the proposed budget process is well thought out and will result in net positive benefit to the Cardano ecosystem.

However, I maintain several reservations. I would hope that Intersect incorporates the following pieces of feedback, provided they judge these suggestions as not sufficiently deviant from the spirit of their proposal to require a separate vote.

First, I agree with KtorZ's analysis that the framing of this proposal subconciously views this as "the" budget process for Cardano, even while leaving room for "other" budget proposals. The language repeatedly frames it this way (the title of the proposal, references to "the" budgeting cycle, etc., and even structurally assuming that Intersect is entitled to "the rest" of the NCL). After several conversations with members of Intersect, I do believe this is unintentional, but it's an unconcious bias that I believe Intersect should control for in their implementation of the proposed budget process.

Second, I believe Intersects budget process should not seek to define a net change limit for the Cardano Treasury, I believe that is the remit of the DReps entirely. Instead, they should define their budgetary limit, justify it based on the impact they want to effectuate, and then relate that to the global network NCL.

Third, I believe the intention of the "work package" based budgeting is to push back against omnibus proposals, but the proposal does not use clear enough language to this effect. I believe Intersect administrators should reserve the right to make judgement on the "cohesive value" of a work package, and work with vendors to break unrelated and independent projects into separate proposals that can be voted on independently by DReps during the Ekklesia voting stage.

Fourth, I believe the waterfall funding mechanism, borrowed from Catalyst, will prove just as damaging as it has been in Catalyst. It is damaging in both directions: projects that can expect a high degree of popularity are incentivized to inflate their ask, because there is plenty of room for them to crowd out other projects; and smaller, lessk known projects are forced to race to the bottom on price in the hopes that they'll be able to "fill in the gaps". It may be too large a deviation to change this, but I would encourage you to rethink this structure for future years.

Overall, I believe the proposal is a good one, and I'm excited to see it's impact, specifically with a new focus on KPIs and Impact, and I hope the above reservations will be carefully considered.

You can find a larger writeup justifying my vote here.

I am voting YES on governance action 73a4eb2148781c37ef37c90a33a1d3d00511a8eefe9cdfaa1ea593b090f23f96, which sets the net change limit to 300 million ADA. This represents a trending decrease in expenditures, is less than the total inflow of funds, while still representing aggressive investment in our ecosystem.

You can find a larger writeup of my beliefs and values here.

I am voting NO on governance action dfdac5921ab657241fce58583d61bef59a369e01d2ba78191d6df6632a07fdfd, which adjusts the minimum constitutional committee size. I agree with the direction of this change, but it was prepared without consideration of the memory limit budget, which I voted yes for, and thus these two would conflict.

You can find a larger writeup of my beliefs and values here.

I am voting YES on governance action c21b00f90f18fce4003edf42b0b0d455126e01c946e80cc5341a9f9750caf795, which increases the transaction and block memory unit limits. I'm the original proposer of this change, 2 years ago. Ample work has been done by IOG and others to validate the safety of this change, and I believe we have several times this margin in terms of ability to increase these limits.

You can find a larger writeup of my beliefs and values here.

I am voting ABSTAIN on governance action 4b10e5793208cb8f228756e02113227c91602248eac4d992681a0ee760b6c4e2, which disburses 400,000 ADA, less than 2 basis points of the treasury. As a direct recipient of funds in this withdrawal, as a service provider for the treasury management platform, I feel I must abstain from the vote. Were it not for this conflict of interest, however, I would vote yes, as I believe this proposal is well structured, reasonably priced, and in line with the longer term goal of fostering deeper and more active liquidity within the Cardano DeFi ecosystem.

You can find a larger writeup of my beliefs and values here.

I am voting YES on the Cardano DeFi Liquidity budget.

Cardano must reach economic feasibility. As the reserves dwindle, so too
will staking rewards and compensation for SPOs. As that happens, we will
need a strategy to replenish and even bolster it. Given the criticality,
I believe we should tackle that problem in depth:

• Leios, to increase the network capacity
• Business development, to drive more traffic
• Actively Validated Services, to diversify revenue streams
• Appreciation of the value and utility of ADA through the above
  and governance
• Active wealth management of our sizable treasury

The stability fund proposed here is, to date, the most comprehensive
proposal for the last bullet point I've seen.

I believe the administration costs are reasonable given the size of the
fund, but would expect those to grow in future iterations as the fund
continues to attract premier ecosystem talent.

I would also expect to see future iterations of this proposal have more
detailed descriptions of exactly how the decision making will be done,
beyond simply a multisig: what criteria and metrics will be considered,
what due diligence will be performed, what thresholds need to be met,
how returns will be evaluated, accounted, and reported, etc.

However, I also appreciate that this first round exists to help develop
those processes, so I'm willing to vote yes without them this time.

I considered abstaining on this proposal, given my role in the Sundae
protocol which would be one candidate for receiving funds; However,
since I will not be a decision maker on how these funds are used, and
only a supplicant, I do not feel it is neccesary.

I am voting YES on governance action 60ed6ab43c840ff888a8af30a1ed27b41e9f4a91a89822b2b63d1bfc52aeec4500; Normally, I would abstain, due to a conflict of interest. However, the info action received 80% support, and the governance action is due to pass regardless in a few hours, and so I wanted to participate just this once. I made a public announcement and didn't hear from any delegators objecting to this vote.

I am voting to abstain on the Amaru Node Development budget info action with hash bd488931f792651fefa9c6fda185a2c6cec83245b51d994e33090ce36e29cc26#0.

I am abstaining because of a potential conflict of interest. I am one of the scope owners on this project, and Sundae Labs will be one of the development teams employed to help deliver on the goals of the project, and so I cannot in good conscience vote on this proposal. That being said, I believe very very strongly in the need for Node Diversity. Beyond just the added robustness to the network, reimplementing the Cardano protocol in another language is a forcing function: all of the design decisions, implementation details, and protocol trivia must be opened and re-examined in order to build a node. As we do so, we are making sure to document these things clearly, making them accessible to any who want to build on Cardano, from nodes. The beneficiaries of this effort extend far beyond those building alternative nodes, but to those building tooling, dApps, and interconnectivity solutions. Building an alternate node will help decentralize not just the network, but the brain trust of the entire protocol.

Additionally, while some hold reservations about how it may impact delivery timelines of other projects, I'm actually quite optimistic. I believe that having a fresh, lower risk code base to experiment in may ultimately accelerate some of these roadmap items like Leios or Starstream.

So, while I am abstaining on a matter of principle, if you are looking for guidance on how I would have voted absent that conflict, it would be a resounding yes.

I am voting NO on governance action 941502b0aa104c850d197923259444d2b57cab7af18b63143775465aaacc84f5, which lowers the treasury cut to 10%. I believe it will be harder to raise this value in the future if we need to than it is to lower it, so a more gradual approach should be taken. I am unconvinced by the justification provided in the proposal or seen throoughout the online discussions.

You can find a larger writeup justifying my vote here.

I am voting YES on governance action 8c653ee5c9800e6d31e79b5a7f7d4400c81d44717ad4db633dc18d4c07e4a4fd00, which establishes an initial Cardano Constitution.

I believe the constitution has material faults that should be addressed in a future revision, but none of these are in violation of my values, and recognize the reality that we could iterate on this forever and never reach consensus. I believe that forward progress with something that is mostly good will foster a rich culture of iterating on and revising and updating the constitution, a culture that has been absent in other contexts and lead to an ossification of values.

You can find a larger writeup of my beliefs and values here.