drep1ytf9f78k7rkwk...

See discussion on Cardano Forum: https://forum.cardano.org/t/withdraw-4-000-000-for-expanding-stablecoin-cardano-native-asset-support-fiat-ramps-yay-or-nay/147887

Concern about feasibility and ability to deliver. Project specifications are sparse. Project Catalyst would be a better funding mechanism.

It is persuasive and trustworthy that the lead maintainer of BloxBean Java tools is a salaried employee of Cardano Foundation. The proposal does not seek refund of CF development costs, but rather funding for additional development.

This risks duplicating research currently underway at IOG. It would be better to consider funding such a proposal via Project Catalyst after IOG has open sourced the Midnight code, which will happen shortly.

I have nothing against the committee members listed on this proposal. However, this Cardano Product Committee might create a similar problem to what we see in USA politics today where voters can only choose between a Republican elite sanctioned candidate or a Democrat elite sanctioned candidate.

Imagine if a select small clique get to influence the agenda of meetings and topics discussed in order to massage the items considered as options for the roadmap. Eventually, DReps might feel pressured to vote for committee sanctioned roadmap options feeling they were freely selected by the community absent committee influence. Voting this through will deliver special powers to Cardano Product Committee members allowing them to heavily influence what options are considered, debated, and ultimately voted on, for the roadmap.

It would be better to spend this money on developing a decentralised mechanism to gather and curate raw community sentiment.

Please continue to address funding needs via Project Catalyst.

More appropriate to seek funding for such a proposal through Project Catalyst.

Project Catalyst is the more appropriate mechanism to seek funding such a project.

Structures that look like a slush fund governed by a single individual must be avoided. Project Catalyst is preferable for such funding with its direct community voting and oversight.

Another more opaque version of Project Catalyst whereby a small committee can obtain the power to control a slush fund. Project Catalyst is preferable for such funding with its direct community voting and oversight.

This represents a more opaque version of Project Catalyst whereby a small committee can obtain the power to control a slush fund. Project Catalyst is preferable for such funding with its direct community voting and oversight.

It would have been easier to vote in favour of this withdrawal if it was possible to trust Cardano Foundation (CF) to always act in the best interests of the Cardano community. Unfortunately, CF members have publicly confirmed that the Swiss Govt can exert more control over how CF employees vote CF's genesis gifted Ada than can the Cardano community. This unfortunate reality diminishes the decentralisation of Cardano.

It would have been easier to vote in favour of this withdrawal if it was possible to trust Cardano Foundation to always act in the best interests of the Cardano community. The fact that Cardano Foundation members publicly assert that Cardano Foundation is not required to act in the best interests of the Cardano community is concerning, and furthermore this stance reduces the decentralisation of Cardano.

Until now AdaStat have been supported via staking rewards, helped by delegation from Cardano Foundation. The community should fund the work to develop and maintain this blockchain explorer directly. Importantly, AdaStat have publicly committed to open source all back end and front end code, "so everyone can run their own copy of the AdaStat Cardano explorer".

Unclear how much this proposed work overlaps with that already being done by IOG, BOS and Sundial. Also unclear whether deliverable APIs will be fully open source. Given the somewhat speculative nature of this work, perhaps Catalyst might be a more appropriate funding mechanism?

Vote changed. It is not clear how many users prefer to use NixOS. I think the money could be better spent on packaging Cardano software for mainstream Linux distributions using their built in package managers. Eg: Building deb packages for Debian and Debian derived distributions such as Ubuntu, Mint, etc.

nftcdn.io is not a decentralised solution for content delivery.

Must fully open source code including backend in order to demand community funding.

There doesn't appear to be overwhelming demand for building smart contracts using Scalus paired with Scala 3.

Eternl can either remain proprietary and fund itself through subscription fees, advertising, and other business revenues, or it can commit to fully open source its code and request community funding.

IOG is already building bridge technology required for Midnight which will be released soon. We should wait for this development before funding similar initiatives.

Too much funding to be controlled by a committee lacking transparency and community oversight. Cardano does not need a slush fund for funnelling resources to some politically well connected mates.

Don't spend treasury funding on hardware wallets that won't commit to full open source compliance. There are fully open source alternatives that are more deserving such as Keystone.

Important reasonably priced project being delivered by a professional team to enhance resilience and decentralisation.

Cardano treasury funds should not be used to speculatively provide extra funding liquidity to chosen lending apps and DEXs, nor should treasury funds be used to purchase fiat backed stable coins. Selling treasury Ada for fiat backed stable coins will negatively impact the Ada price as well as negatively impact Cardano decentralisation through dependence upon the stable coin issuer.

I will individually approve many of these budget items but I don't approve of commingling service providers and bundling as an omni-bus budget proposal. Furthermore, I don't support wasting software development resources on devices, such as Ledger, that haven't fully open sourced their code.

I will individually approve many of these budget items but I don't approve of commingling service providers and bundling all this as an omni-bus budget proposal.

Stop all these competing net change limit info actions that span different epoch windows. A majority of DReps already supported a net change limit info action for 2025 of 350M.