Withdraw ₳99,600 for BloxBean Java Tools Maintenance and Enhancement

System 11mo ago1post

158 DReps voted · 41 with a rationale

Open a row to read the rationale.

  • Yes 8.1M ₳ No rationale
  • Yes 7.8M ₳ No rationale
  • No 7.3M ₳ No rationale
  • Yes 7.1M ₳ Rationale

    I voted YES for this proposal in the Ekklesia temperature check. I have now come to a position where I think that this might not be the best way forward. Meaning that direct funding of smaller open source tools maintenance and enhancement proposals from the treasury might not be the best approach going forward.

    As I have already indicated my support for this proposal in Ekklesia, I will not overcomplicate matters by changing my vote at this - the final treasury withdrawal stage. So my original vote indication remains in place and I vote YES. Note: if this were to be resubmitted in 2026, I would consider this carefully.

    Why? I am more in favor of seeing proposals like this funded through an initiative such as the OSC Budget Proposal - Paid Open Source Model for Sustainable Development. I voted YES for the OSC Budget Proposal - Paid Open Source Model for Sustainable Development.

    Such budgetary initiatives do not have to come from the OSC, it could be another umbrella group of open source advocates / body that will prioritize and correctly value certain critical packages of maintenance and enhancement work on open source tools that are important for the Cardano ecosystem.

    This group or groups would ideally rank the importance / relevance of these open-source tools and software kits, as well as realistically estimate how much maintenance / enhancement is needed and when it is critical.

    Multiple tiny contracts (this is a relatively tiny ask) approved by the treasury complicate oversight, whereas larger open-source infrastructure umbrella programs can rank repos by impact and rotate funding annually. The more exceptions the Treasury grants, the harder it becomes to enforce future budget discipline.

    I imagine the maintenance and improvement of open source tools as something that could be tentatively grouped. Of course, these larger maintenance and enhancement support groups (like the OSC) for open source tooling could start discriminating against certain tools. In those cases, if a proposer such as MLabs is unsatisfied with the ranking or grouping, they could always directly apply to the Treasury with a rationale why the proposal needs funding and why it cannot obtain it elsewhere - but only directly from the Treasury.

    Note: some other similar open source maintenance and enhancement proposals might differ in their perceived importance - and my vote indication in Ekklesia. I am currently considering to mostly mirror my voting indications from Ekklesia - in order to not overcomplicate the process. Exceptions will be indicated.

  • No 6.2M ₳ No rationale
  • Yes 6M ₳ Rationale

    Voting decision was made to be consistent with my reconciliation back in May 2025;
    https://2025budget.intersectmbo.org/voters/drep1yfdfs28uwafjgmrkatdektlzrvha2cmvqjhuz700e04mawq23rmrg

    My votes, I hope, align with my overall goal as a DRep to see continuous improvement in the ecosystem.

    A PDF version of this rationale is also made available.

    Voting decision was made to be consistent with my reconciliation back in May 2025;
    https://2025budget.intersectmbo.org/voters/drep1yfdfs28uwafjgmrkatdektlzrvha2cmvqjhuz700e04mawq23rmrg

    Ready to move forward overall with the budgeting process and look forward to a smoother process next year. I voted for a lower NCL overall (200M), however found in supporting things that we really ought to have funded to keep momentum in development and enhancements on-chain (supporting both open and non-open-sourced projects) I came a bit higher than that (250M+).

    We will need to strike a balance in treasury withdrawels for projects that push development forward (and therefore the chains efficiency, performance, resiliancy, and seucrity) -- and businsess that wish to participate, of any size, and extend the capabilities and real-world use cases of Cardano.

    My votes, I hope, align with my overall goal as a DRep to see continuous improvement in the ecosystem. https://raw.githubusercontent.com/Tarrant64/mr_cata_gov/refs/heads/main/mr_cata_gov%20.txt

  • Yes 5.5M ₳ No rationale
  • Yes 5.3M ₳ No rationale
  • Yes 5.3M ₳ Rationale

    STORM Partners supports this proposal as it maintains open-source infrastructure for Cardano’s Java developer ecosystem. While the ask is modest and the tools serve real utility, we believe that long-term maintenance of small libraries is better handled through broader umbrella programs like the OSC’s open-source budget model. Such structures would improve prioritization and reduce overhead moving forward. With that being said, until those frameworks are fully operational, we consider this a justified use of treasury funds and vote YES.

  • Yes 4.8M ₳ Rationale

    Java dev tool compatible with Cardano mini protocol is valuable for strengthening and diversifying the whole Cardano ecosystem.

    Java dev tool compatible with Cardano mini protocol is valuable for strengthening and diversifying the whole Cardano ecosystem.

  • Yes 4.8M ₳ No rationale
  • Yes 4.6M ₳ No rationale
  • Yes 4.5M ₳ No rationale
  • No 4.4M ₳ No rationale
  • Yes 4.2M ₳ No rationale
  • Yes 4.2M ₳ Rationale

    I vote YES as core engineering is a top priority of my DRep.

    Strength and honor.

  • Yes 4M ₳ No rationale
  • Yes 3.7M ₳ Rationale

    BloxBean has demonstrated expertise in developing Java tooling for the Cardano ecosystem, and their proposal appears well-justified and cost-effective. Therefore, I will support their proposal.

  • Yes 3.7M ₳ No rationale
  • Yes 3.5M ₳ No rationale
  • Yes 3M ₳ No rationale
  • Yes 2.8M ₳ Rationale

    I am following through with my YES vote from the Cardano Budget 2025 Ekklesia process. This proposal falls within my personal NCL of 250,000,000 ADA.

  • Yes 2.7M ₳ No rationale
  • Yes 2.7M ₳ Rationale

    A couple of months ago, I supported the resolution to bundle all of the Intersect Budget Proposals into 1 or 2 formal on-chain governance votes.

    Each of these proposals has already received 50% or greater support from the active DReps in the ecosystem, and I will honor that prior decision.

    A PDF version of this rationale is also made available.

    A couple of months ago, I supported the resolution to bundle all of the Intersect Budget Proposals into 1 or 2 formal on-chain governance votes.

    Each of these proposals has already undergone extensive scrutiny and received 50% or greater support from the active DReps in the ecosystem, and I will honor that prior decision and the work these prospective developers have put in by voting yes on all the proposals from the Intersect Budget team.

  • Yes 2.6M ₳ Rationale

    I believe that supporting such tools benefits the ecosystem by expanding the potential reach of developers and integration opportunities. Moreover, the requested budget appears very reasonable given the stated commitments and motivations.

  • Yes 2.5M ₳ No rationale
  • Yes 2.5M ₳ No rationale
  • Yes 2.5M ₳ Rationale

    BloxBeanは、Javaを用いたCardano開発に不可欠な複数のオープンソースツール(CCL, Yaci, DevKit等)を継続的に提供しており、Java圏の開発者に対する参入障壁を下げる重要な役割を果たしています。今回の提案は、維持・拡張のための少額支援であり、長期的なエコシステム拡張の観点から妥当と判断し、賛成票を投じます。


    BloxBean’s Java tooling lowers the entry barrier for JVM developers and enables broader dApp development on Cardano. Given its open-source nature, proven adoption, and low funding request to support ongoing maintenance, this proposal is aligned with long-term ecosystem growth. I vote Yes.

  • Yes 2.5M ₳ Rationale

    Low treasury impact but i still believe that this belongs more in Catalyst or bundled along with another proposal. I voted yes due to the minimal impact on the treasury while also providing good value in the sense of money spent per FTE.

  • Yes 2.1M ₳ No rationale
  • Yes 1.9M ₳ No rationale
  • Yes 1.9M ₳ No rationale
  • Yes 1.8M ₳ Rationale

    I am voting Yes. These tools provide vital support for Java developers working with Cardano, enabling broader language accessibility and fostering integration across enterprise and backend systems. Continued maintenance and improvements will help ensure long-term stability and usability for a growing segment of the developer community. Given the modest cost and high utility, this proposal is a sensible and strategic investment in Cardano’s multi-language development ecosystem.

  • Yes 1.7M ₳ No rationale
  • Yes 1.7M ₳ No rationale
  • Yes 1.4M ₳ No rationale
  • Yes 1.4M ₳ No rationale
  • Yes 1.2M ₳ No rationale
  • Yes 1.2M ₳ Rationale

    I decided to vote ✅ YES on 37 treasury withdrawals, ➖ ABSTAIN on none, and ❌ NO on 2 treasury withdrawals from the Intersect 2025 budget.

    It’s obvious I consider all proposals I approved in the budget vote on Ekklesia beneficial for Cardano, so those all receive a ✅ YES vote.

    I also vote ✅ YES for most proposals I initially abstained from or voted against in the Ekklesia vote. There are a few reasons for this:

    • Some proposals gained strong community support after all, so I don’t want to be the one standing in the way, especially when the requested amount is negligible in the bigger picture.
    • Some proposals I actually liked, but I found them more suitable for Catalyst. However, with all the delays, it now makes more sense to fund them as soon as possible.
    • Some didn’t get my initial support because I thought the requested amount was too high. But I now believe it’s better for the ecosystem to fund them, despite the larger budget, than not fund them at all.
    • I needed to vote for budget proposals with my own NCL in mind. Not all those I approved made it, however, so that leaves some room for other ones.

    I won’t approve the treasury withdrawal for two proposals:

    ❌ Withdraw ₳3,000,000 for High-yield RWA Asset for Cardano: Tokenized Real Estate
    This proposal won’t bring much value to our ecosystem, imho.

    ❌ Withdraw ₳1,500,000 for Complement Catalyst: Extended Quadratic Funding---Zero Operational Costs
    While the proposal includes some interesting ideas for a fairer voting mechanism, I now support Catalyst and don’t see the need for an additional funding system at this moment, especially considering total spending. The requested amount also seems too small to meaningfully fund multiple projects. While the model relies on donations, it’s unclear what the donor incentive is. Since voting power is tied to donation size, why wouldn’t donors just support specific fundraisers run directly by the projects they care about? That way, they can ensure their contribution goes straight to their preferred initiative without needing it to win a vote first.
    I do appreciate the idea of a hybrid funding model where the treasury covers part of a project, but ideally, the remaining portion should come from investors rather than donations, imho.
    Lastly, I don’t appreciate that the proposal’s title refers to Catalyst, even though it has no relationship to it. This seems intended to mislead people into thinking Catalyst would benefit from this proposal, which it doesn’t...

    I acknowledge there’s a metadata issue in the proposal “Withdraw ₳45,217 for MLabs Core Tool Maintenance & Enhancement: Cardano.nix”, but I approved it nonetheless, as the problem is minor and not worth obstructing the process.

  • Yes 1.1M ₳ No rationale
  • No 1.1M ₳ No rationale
  • Yes 1.1M ₳ No rationale
  • Yes 1M ₳ Rationale

    I acknowledge the importance of maintaining and enhancing BloxBean’s Java tools as part of Cardano’s ecosystem infrastructure. The requested budget is modest relative to the potential long-term value of solid developer tooling.

  • Yes 1M ₳ No rationale
  • Yes 947.9K ₳ No rationale
  • Yes 922.9K ₳ No rationale
  • Yes 819K ₳ No rationale
  • Yes 810K ₳ No rationale
  • Yes 793K ₳ No rationale
  • Yes 785.2K ₳ No rationale