Sebastien Guillemot セバ

See previous rationale on L2 proposal

although I generally don't vote on commercial projects, I think this is a serious team trying to do good work and generally have a good understanding of the technology they need to achieve their goals.

Generally supportive, but here is my ranking of priority from the items listed:

• Consensus improvements
• Data availability
• Post-quantum (VRF/KES)
• EasySM (maybe, little detail on what this actual is)
• Mithril

Here are the ones I'm less sure of given the current capabilities/priorities of Cardano:

• compliance use cases
• Identity / selective disclosure of identity
• SPO incentives
• HSM-enabled node CPS and prototype integration for secure KES/VRF key management
• Hydra

Here are things I don't really feel are research problems

• minUTXO / atomic swap prototype
• agent chain specification
• Babel fees (there are different constructions possible (esp. with ZK), but we should build a v1 before going too far on research on this

Unsure

• Cavefish protocol: it's a very interesting primitive. I feel for any powerful enough privacy-preserving ZK system, you can achieve a similar result with recursive SNARKs. Therefore, this proposal is useful when you don't have / don't want ZK compute on the L1 (just use plain signatures). I do think there is some possibilities for this to be powerful (esp. around the fact that the onchain cost is low given you don't need an onchain verifier circuit). I'd be interested in seeing the CPS - especially on how this might relate to babel fees which has a bit of conceptual overlap
• ZK verification toolkit (unclear why should be done other than just precompiles). There are ways general "recursive systems" could help, but it's a bit vague which Cardano initiative this would be targeted to (Starstream, Midnight, bridging, identity, something else?). Fundamental theoretical research is fine (many open problems), but just not enough specification provided for me to really judge this one

Changing from Abstain to YES, as

• There seems to be a fairly broad interest in different projects and members of the community in attending the event
• Charles and other notably members have decided to attend
• I've attended Token2049 before, and I think it's generally a good event
• Last year had a very metric-driven approach to the booth, which was encouraging to monitor ROI
• Consensus Miami had really good conversion rates based on our data at the Midnight Foundation, which makes me feel that events right now, esp. around institutional conversations, has a higher ROI than previous events in general at this given time

based on this, and the new lowered cost for the event, I think voting YES can bring benefit to the ecosystem

I think Linear Leios (the proposed version of Leios being implemented) makes sense architecturally, and is a reasonable way to introduce Leios concepts on a modular way. Leios also introduces some ideas and architectures that can also be reused for DA layer concepts on Cardano, which I think will speed up scalability and functionality

I would have liked more transparency in the proposal on:

1. Expected future governance to implement any future ideas cut from Linear Leios. I understand that probably, given the trajectory, future work won't be called "Leios" anymore and we'll need a new name. However, given consensus improvements are a never ending endeavor, it could be interesting to know what future steps this research work will unlock
2. Expected compatibility with DA layer ideas. I think it's not unlikely we'll see a large treasury ask for DA next year at the latest (since the ecosystem really needs it), so it would be useful to know that the architecture of Leios is either complementary or at the least compatible with DA plans (I know this is a very hard question to ask without doing a lot of deep thought though, as a DA is a very complex in itself)

However, I think the proposal and extra document as-written is sufficient to get a good idea of what the team is working on, and the value to the ecosystem

See my previous rationale for why I'm skeptical of this proposal. However, with the fact this proposal now is separate from Pebble, and the fact the amount was lowered a bit, I think this is sufficient for me to change from a "no" to an "abstain"

See my previous rationale (I don't think Aiken is the main bottleneck for Cardano adoption)

I've thought a lot about this proposal, and decided to vote no. I'll share my rationale below:

First off, as everybody knows, treasury spending is limited and there are a lot of proposals. That means that we have to triage features we want to build this year. In my mind, Plutus is very stable. It's extremely rare that I meet a developer that wants to onboard onto Cardano, and the main blocker ends up being the Plutus usability. Almost always it's a consensus feature, a ledger feature, or a feature that Plutus fundamentally cannot deliver since it wasn't built for it (ex: ZK)

That being said, Plutus does need to be maintained in three important ways even if working on it is not a core bet for how we will grow Cardano:

1. Ensuring correctness (esp. against growing AI threats to code)
2. Performance improvements (Plutus still powers many contracts, so improving Plutus performance benefits every user)
3. Adding new precompiles (ex: upcoming post-quantum primitives being added to Cardano)

However, all three of these features are more "maintenance" than "enhancing Plutus". In fact, the "Cardano Maintenance" proposal by IOG even mentioned Plutus Core maintenance in relation specifically to these points (and post-quantum work is proposed as different treasury proposals, so the cost of adding these precompiles I believe will largely not need to be covered by this proposal)

I think Cardano needs some bold bets right now over maintenance. For example, if you gave developers the choice between making Plutus 1.5x faster or having event support for Cardano, I think a large number of people would pick events (and I think it would have a much bigger effect on Cardano adoption that slightly faster Plutus). However, adding events to Plutus requires a lot of rethinking about how things work (outside the scope of what this proposal is trying to do). I really don't think any of the "Developer experience" improvements mentioned in the proposal will move the needle at all (I think almost everybody will just dismiss these) compared to some of bigger ideas.

However, I'll be monitoring this proposal to see how others vote. If it gets close to passing and I end up being the blocker, I may change my vote to avoid me being the blocker on this passing. I'm voting no mostly to signal my feeling on this proposal, but if the rest of the ecosystem wants this to pass as-is I do feel the Plutus team will use the funding honestly and will try to do their best with the funds received

I believe the team does a very honest job when it comes to maintenance initiatives, and I do feel there will be quite a bit more work than historically given the rise of AI creating a lot more maintenance work in security all parts of the software. I have confidence in IOG to deliver on this.

In my mind, account support for Cardano is a big bet, which is exactly the kind of bet we should be making as an ecosystem at the moment. I think it will simplify a lot of things (esp. in relation to the treasury), will strengthen concepts like observer scripts (esp. in relation to multi-token support which can be used as indicators of the state of an account), and help avoid a lot of min UTXO issues that have been bottlenecks for different apps.

Given the fact a lot of the power of account address comes from using token to encode state, I think the "Cardano Multi-Asset Treasury" part of this proposal makes sense. In my mind, the main benefit is not really the treasury, but the fact that the treasury is an account means that it indirectly benefits from this multi-token account work and could enable for some more interesting treasury proposals (esp. in relation to stablecoin holdings as part of the treasury).

Lastly, I think the Nested Transactions feature outlined will be critical in making a lot of this work. Right now, there's no way for dApps to upgrade atomically between Plutus versions (you can't use two different Plutus versions in the same tx). Similarly, people won't be able to update their dApps to the new account address system atomically without this feature. Even more, new VMs like Starstream will need this feature to talk easily with Plutus.

In my mind, these three features together form a very logical bundle, and a strong logical bet on how we can increase adoption of Cardano.

I really love the work Eternl has done. However, the attempt at having people pay for a "Pro" plan was already somewhat tried with the NFT collection that the Eternl team put out (I know it's not exactly the same, but it's close) and that didn't really work out. I don't generally see this kind of "pro" plan being a popular business model for wallets in general. Given Eternl has received money from the treasury before, I would prefer if the proposal just accepted the reality that until things like built-in swaps can generate more revenue (the most common wallet revenue generation model) that Eternl acts somewhat as a public good and therefore should be open sourced.

I really like a lot of the ideas behind Pogun, but I generally abstain for commercial proposals

I think Project Cayley could be architectured in a lot of different ways which has a very big impact on whether or not voting for this proposal makes sense. For example, projects like Paima and txpipe have had a lot of different thoughts about ways to attempt indexing in different ways and commercializing those ideas. I think a lot of the negativity on this proposal comes from lack of clarity, and therefore people just assume it will go to fund Blockfrost operations as-is (which, from my understanding, isn't really the case)

that being said, I generally abstain for commercial proposals so I will be abstaining from this one as well

Before I talk about Hydra, I just want to get the other two sections out of the way:

1. I think this proposal only has very loose financial connections with Midgard, so I won't talk about it
2. The proposal only vaguely talks about wanting to build a DA layer, but doesn't elaborate on how it would achieve that. DA layers are a complex topic, so if we're going to fund some DA layer effort (which I think is important), I would rather see a more concrete pitch on how that would actually be achieved. Some technical challenges just for insight:
   1. What cryptography would you use for the DA layer? If it's ellitpic-curve based, it may have to be phased out in a few years due to quantum computers. Therefore, if a proper DA layer takes a few years to build, elliptic curves is not an option (for example, Ethereum's DA layer is based on elliptic curves, and they've already started working on their plan to migrate it to post-quantum cryptography). We can use hashes as the post-quantum scheme (similar to what Ethereum is planning to move to, and there are papers on hash-based DA layers like FRI-based DA), but this would be somewhat unfortunate given Midnight and Starstream are working working on lattices for PQ cryptography (although I don't think there is much research on lattice-based primitives required for DA layers). The reason aligning the cryptography for DA with other choices matter is because, as the ZOTA paper shows, there is quite a lot of performance benefit gained by aligning cryptography across primitives.
   2. How to best model a DA layer in the UTXO context? All other DA layers are in the account setting (other than maybe something like Chia, which isn't a DA layer per-se, but has some ideas). If we instead try and build the DA layer more at the protocol level than at the ledger level, then we're have to think about how this aligns with Leios (since there is quite a bit of overlap, and there was even a "Blob Leios" concept at some point to use Leios for DA)

Given the above, I feel this proposal is actually mostly for Hydra. In my opinion, although Hydra does have some users, it hasn't quite hit the level of adoption that was originally expected. Even for fixed-party payment systems (the use-case state channels were advertised as best suited for), people have instead been leveraging privacy-preserving ZK solutions (ex: Ligero is used in Midnight City to do fast private payments at ~500tps, which is enough for most use-cases). I see two potential directions for this proposal if it gets resubmitted:

1. Be very clear about this being a "capstone", and clearly identify which features would be needed by Hydra to make it v1 complete. I don't really feel like existing projects using Hydra are demanding a lot of features, so I feel like we must not be far from this kind of milestone (let me know if I'm wrong)
2. Be very clear about a new potential direction for L2 strategy (experience and things built for Hydra can be very beneficial for this!). For example
   1. what if we built a more restrictive (not general plutus) version of Hydra that also has ZK that uses UTXOs? There is some prior ideas around this (zSwap-based L2 for Midnight, intmax in ethereum, Ligero in Midnight City, etc.)
   2. what if we want to combine state channels with general ZK solutions? Starstream can somewhat model state channels because within a single transaction, you can "pass" the utxo set to somebody else for them to continue the proof. However, Starstream can't cover the entire set of use-cases you might care about at the moment since you may lose privacy when passing utxos (may require some MPC system for this), and there's nothing stopping somebody from ending the proof by submitting the UTXO diff onchain at any time. I feel ideas from Hydra can be combined with Starstream to achieve this though

I've looked through the Blaster project and I think it represents a very solid bold bet that makes strategic sense to do now. It helps strengthen the security of projects on the chain at a time where AI makes both formal verification and attacks on insecure code easier. It comes at a time where I feel UPLC is fairly stable, and so it makes sense to focusing on locking down a solid basis in parallel to more ambitious next-gen efforts like Starstream.
The team has done a great job on the existing work, and the fact they've been able to concretely apply this to real production contracts gives me the confidence on the application of Blaster in the future. For the cost of this project, it quite literally only needs to save Cardano from a single hack to pay off, and with more funds being planned to be locked in contracts than ever (with efforts from Midnight, other partnerchains, pentad projects, etc.) this comes at the right time to give us the safety to deploy capital for these upcoming big bets.

I feel like this initiative is maybe a bit too vague in its current form.

Some initiatives like the Developer HUB, Community Collaboration, Developer Outreach, etc. require a fairly different skill set and team than cardano-init and ContractsLibrary. Although I trust IOG to do both in a sense, I think Cardano needs some bold bets at the moment and I'd prefer to see some bold bet on a specific idea that the community can rally around for developer onboarding

For example, I think "cardano-init" as described is not necessarily bad, but it won't really go deep enough to really solve some of the developer onboarding problems. In the pat few years, tools like yaci-devkit, dolos and utxorpc have made it much simpler to spin up node and start indexing, but how to make your Cardano project easy to index is still an unsolved problem. Other than some problems like Plutus not having events (making it hard to have a no-code way to index your app as you develop it, even with tools like utxorpc and dolos), even the orchestration about what transactions you need to make to setup your localhost testnet for your app are hard to specify. There have been attempts at this in Ethereum (ex: TheGraph, hardhat ignition), but they're hard to port to Cardano both because they're a bit old (use patterns and techniques that computer science in general can solve in better ways now), but also because Cardano doesn't have the same composability that people usually leverage when using an OpenZeppelin-like project to compose templates together. I think a more comprehensive solution would probably take some of these older ideas, some other attempts at this like EffectStream (fka Paima Engine), tx3, Starstream, etc. and try and figure out how to apply some of these ideas in the contract deployment setting (esp. in relation to what Cardano can do today, and possibly some upcoming features like nested transactions which may help with this)

All that to say, I think some of these solutions are more complex to properly solve. Cleaning up tools like aiken-mdx so you can have an OpenZeppelin-like UI for seeing different contracts on Cardano to leverage any pre-existing tools to build your dApps is definitely a step in the right direction, but I think you would get more excitement from layout out a more comprehensive vision (even if your proposal cannot build the comprehensive vision in one shot, having a comprehensive vision would make it clearer for other developers, dReps, etc.. what you're trying to do, why this doesn't overlap with previously funded initiatives, and the background to decide if this is a good bet to make)

Keep in mind this review is in the context of the 2.25m ask

Pebble

I don't believe an alternative to Aiken that's 50% better will be difference maker in getting Cardano more adoption. Definitely any improvement to Plutus usability is nice and I've heard many good things about Pebble, I would rather fund somebody to try building a totally different approach to UTXO smart contracts that has some solid idea behind it. Especially because although Starstream development is going well and we haven't hit any issues, there's never a sure thing in software engineering so there's always a chance something goes wrong with Starstream (proof generation too slow, transactions too big, people don't like the devx, etc.). Instead of putting all the eggs in the Starstream basket, I'd be more comfortable if there was another alternative plan (even if multiple ways to achieve some end goal getting funded always leads to issues).

Realistically Plutus hasn't really gotten much adoption in the world, and I don't think an iterative improvement will be what gets a new wave of developers to come build on Cardano. It's not a new narrative. It's not a 10x unlock in new capabilities. It's meaningful work and true improvement, but I think Cardano needs some big new ideas. If you ask a lot of the large projects that tried to build on Cardano (either internally or externally), it's not that they weren't able to build because the language was too complicated or they were missing one feature or two. It's often times because they were missing big-ticket features that are fundamentally incompatible with the way Cardano is architectured today. yeah but it doesn't solve the fact events are missing (and basically impossible to properly add), the fact that ABIs are missing (and basically impossible to properly add), that data-heavy use-cases like L2s are infeasible, that privacy / crypto-heavy use-cases are basically blocked, that compute-heavy use-cases can't be atomic, that state channels are missing features to really deliver, that composition is so limited at the protocol level that most dApps live in isolation, etc. etc. etc.. These are the problems almost everybody runs into, and Pebble can make some iterative improvements on these, but almost all of them are fundamental problems at the ledger/plutus core level that Pebble cannot easily address.

For example, if the author is passionate about composability, I'd rather have a proposal where they go deep into what the UTXO could look like in relation to MPC/coSNARKs/FHE/related concepts and try and come up with what the UTXO model could look like in that lens. I think for sure there has got to be multiple ways you could rig the UTXO model to connect to these that gives you orders of magnitude more expressiveness in composability compared to what we have now. It can grow into an alternative to Starstream, or orthogonal to it. it's entirely possible the result of the investigation (just like was the case for Starstream) is that it requires a lot of new cryptography, a lot of hard work, and multiple ledger-level changes to make happen, but I think that's the kind of rethinking and new narrative that Cardano needs

Gerolamo

Although the project is meaningful and unique, for these kinds of these I always feel like we would end up with a better result (both for our ecosystem and the world) if you instead just put $1m into funding wasm development in general and leveraged the result of that (Wasm makes progress every year and I think a lot of people are sleeping on how much progress has been made, but there are still many areas that I think could make a big difference if improved where standards committees have already agreed and it's just missing an implementer).

For example, this is the kind of thing I'm talking about though

for example, if you need to model code that accesses the file system (often the case in typical nodes), the Wasm Component model allows for this through wasi-filesystem (https://github.com/WebAssembly/WASI/tree/main/proposals)

for threading (another common ask), the new Wasm Component 0.3 supports async and streams, which makes it very easy to implement a lot of concurrency systems (and compile many new kinds of languages into Wasm components). Additionally, with new standards like wasi-gfx, you can outsource certain computations to the user's GPU directly from Wasm which lowers a lot of cases people historically needed threads in Wasm (rendering UI or doing expensive computation)

There's a lot of work being done on Wasm components, but there are still a lot of specification blockers for big projects (ex: how does the Wasm GC proposal compose with the Wasm component system?), as well as implementation blocks (ex: Firefox said they want to implement Wasm Components in the browser natively, but no clear when they'll finish this work), but although there are a lot of work to be done on Wasm components, I think a lot of things are now within reach and could be accelerated over giving up and doing stuff in the JS layer (which historically was the go-to solution). By spending the money to instead make a node like Dingo is compatible with Wasm Components, we probably take on less engineering debt (no need to update Gerolamo every hardfork), and any work we need to do (probably not that much work) is beneficial to any project in the web that is built using wasm components (and increasing number of projects, including other Cardano efforts)

The Dingo team has done impressive work. Developer agility at the protocol level (how long it takes for the community to experiment and decide on shipping protocol-level improvements) continues to be one of the largest hurdles in the growth of the project, and Dingo seems to be the team furthest along in tackling this issue at this point.

The usage of Go over Rust is a very unfortunate choice when it comes to interoperability with a lot of the cryptography ecosystem (especially in zkVMs which I believe are the future of most projects) as well as poorer interoperability with Wasm (which I also believe is the future of the web for most use-cases).
However, with AI, which language you choose to get something done now-a-days is a lot less of an issue than it used to be in the past. As long as it's possible to write a good reference implementation of something in some language, AI is usually pretty good at converting it to another language passing the same set of test suites. That means that any work Blink Labs does generally to improve client diversity (documenting edge-cases, contributing to the specs, providing a high-quality implementation) benefits any other attempts.
At the same time, the growth of AI has made replacing the Haskell node also less important than it used to be (for the same reason)

Given this, voting "Yes" for this proposal is a hard decision for me. However, I also recognize for the need to be pragmatic and move things forward, as cryptocurrencies cannot easily stand still waiting for the team to come and build the perfect thing. You have to work with what you've got, and we've got a good team with Blink Labs.

I don't think the amount asked matches the value gov.tools brings to the ecosystem

while I support this project directionally, I'm abstaining as this is not a technical proposal (so I'm not the best expert on this topic)

However, here are my thoughts:

there are two types of parties you might care to onboard with this:

1. Whales (ex: large entities) who are looking to deploy who are just looking for good yield (don't necessarily care about Cardano)
2. Many small people (ex: everyday users) who are doing nothing with their ADA, and you want them to start using DeFi

If the target audience is (1), my question is: will $50m in liquidity really convince them to onboard onto ADA? How do we know if it's true or not? Have we talked to any of these larger entities, and have they committed to deploying capital onto ADA if we get this 50m? I know of entities that commit to deploying capitals to various chains as long as we meet some set of metrics they'd like to see. If we can't get the same thing for ADA, then low liquidity was not the blocker for them. If that's the case, 50m on liquidity is a waste of money because we don't have the product-market fit that companies are looking for in the first place

If the target audience is (2), my question is: why are we doing this DeFi liquidity management solution, when other approaches like Arbitrum which are less managed have had good success in attracting TVL? Crypto is filled with failed liquidity incentives so it's not a clear win, but instead of picking winners and losers, it may be better to do like Arbitrum and incentivize liquidity across the board (I'm not an expert on this topic though)

The Snek team has an undeniable positive track record, and we should not be solely relying on founding entities for exchange relations.

The situation with CNT listings may change with the release of Midnight, but the snek have always shown themselves to be good actors and I so I trust them to pivot appropriately if needed as the ecosystem evolves.

I agree with the changes in principle, but I don't like the idea of replacing the info action with a new "roadmap" info action as I believe this will be too limiting and too prone to have the process captured and centralized

The user interface has always been confusing and burdensome. It's a lot of money to ask for a product which I think has delivered a bad experience - especially when there are alternatives that I think work better

https://www.youtube.com/watch?v=qpRTr7PuPZ0