Withdraw ₳657,692 for Scalus - DApps Development Platform
152 DReps voted · 43 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 will keep the rationale brief for expediency - as 38 proposals were submitted concurrently by Intersect today. I voted YES for this proposal in the previous Ekklesia temp check and will vote YES now again.
This proposal wants financing for Scalus a Cardano DApps development platform. The budget breakdown seems internally coherent. I admit to having doubts whether to go for a new platform like Scalus. I decided that the diversity of approaches to DApp development merits support.
- No 6.2M ₳ No rationale
- No 6M ₳ Rationale
Voting decision was made to be consistent with my reconciliation back in May 2025;
https://2025budget.intersectmbo.org/voters/drep1yfdfs28uwafjgmrkatdektlzrvha2cmvqjhuz700e04mawq23rmrgReady 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 security) -- 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
- No 5.3M ₳ Rationale
Scalus is a technically ambitious proposal with a highly qualified team, and its strategic goal aligns with our objective of enhancing developer efficiency and attracting new talent.
While the proposal is structured and the vendor is credible, we believe innovation-stage tools like Scalus are better suited to Catalyst until product-market fit and/or initial traction are demonstrated. In our view, treasury funds should focus on proven, ecosystem-critical infrastructure with validated usage. - Yes 4.8M ₳ Rationale
Being able to utilize scala.js on the front end has value. Approving it.
Being able to utilize scala.js on the front end has value. Approving it.
- Yes 4.8M ₳ No rationale
- Yes 4.6M ₳ No rationale
- Yes 4.5M ₳ No rationale
- No 4.4M ₳ 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
Scala is a vital language in the financial sector, and the vendor's tooling will enable Web 2 developers to seamlessly build on Cardano. Additionally, Oleksandr's extensive expertise and proven track record in the field inspire confidence in the proposal's potential for success.
- 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 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.
- Abstain 2.6M ₳ No rationale
- Yes 2.5M ₳ No rationale
- No 2.5M ₳ Rationale
Scala based smart contract and dapp development. I have run scala engineering teams. However, it is still a relatively small community. For minimum viable governance this does not attract many new devs. Aiken has the lions share of usage and for this first run I dont see this being worth it. Perhaps try catalyst or the next governance round.
- Yes 2.5M ₳ Rationale
ScalusはScala 3による統一的な開発体験を提供し、Cardano dApp開発の学習コストと断片化を軽減する提案です。Web2開発者への橋渡しとして効果的であり、提案内容も明確かつ予算は控えめであるため、賛成します。
Scalus offers a unified Scala 3-based development platform that simplifies the Cardano dApp stack. By reducing the learning curve and aligning with familiar Web2 tooling, it can broaden developer adoption. Given the clarity of the proposal and modest budget, I vote in favor.
- Abstain 2.5M ₳ No rationale
- Yes 2.1M ₳ No rationale
- Yes 1.9M ₳ No rationale
- Yes 1.9M ₳ No rationale
- No 1.8M ₳ Rationale
I am voting No. While the goal of improving developer onboarding is valid, this proposal does not demonstrate how it meaningfully complements or improves upon existing tools like Plutus, Marlowe, or ongoing SDK and Layer 2 efforts. The strategic focus on Scala may appeal to a niche audience, but without a proven need or ecosystem integration plan, the value proposition does not justify the requested budget.
- Yes 1.7M ₳ No rationale
- Yes 1.7M ₳ Rationale
Scaling also should include lateral diversity even if the current usage is small. It will never grow if we do not scale diverse accessibility as well, so I am supporting this.
- Yes 1.7M ₳ No rationale
- Yes 1.4M ₳ No rationale
- No 1.4M ₳ No rationale
- No 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
- No 1M ₳ Rationale
This is a typical story of the blockchain development gap reduction, tooling fragmentation and cognitive overhead reduction. The intent is good: Cardano ecosystem is too difficult for newcomers coming from the traditional enterprise stack, and even despite being a beautiful tech stack. But the proposal does not mention some key facts: Cardano already has multiple mature development environments in different languages (Plutus in Haskell, Marlowe in DSL, Glow in DSL) and a lot of work in place on good SDKs and Layer 2.
Is Scalus a step in this direction or it is a copy of the same effort, but with a Scala coat of paint? The vendor's credentials are good: Oleksandr Nemish used to work at IOG and is a functional programmer expert. But there is no proof in the proposal that Scala 3 integration will be better or complementary to the existing Cardano tools and this is not enough to justify the budget. There is no proof of new technical breakthrough and there is no clear idea how Scalus is going to work with Cardano's eUTxO model and Hydra scaling solutions. Without this, the risk of tool fragments is that they will be siloed and incompatible and will result in more fragmentation of the ecosystem, which contradicts the objective of the proposal.
In terms of strategy, the proposal that focuses on Scala developers is a double-edged sword. Some enterprise developers will be attracted, but the strength of the Cardano ecosystem is in the scientific side and functional programming. It is likely that introduction of another complex language and toolchain will make the onboarding process more difficult for the wider community and the fragmentation of the developers' efforts will be even more severe. The productivity boost at scale is not justified without benchmarks or pilot results.
I like the idea of lowering the barrier for Web2 developers but this proposal does not have enough technical differentiation, ecosystem alignment and the proof of need to justify the requested funds. It is likely to copy the existing effort and to fragment our tooling landscape when we need to be cohesive and scalable.
- Yes 1M ₳ No rationale
- Yes 947.9K ₳ No rationale
- Abstain 922.9K ₳ No rationale
- Yes 819K ₳ No rationale
- Yes 810K ₳ No rationale
- Yes 793K ₳ Rationale
Another valuable initiative to build out our developer reach and onboarding.
- Yes 785.2K ₳ No rationale
- Yes 733.1K ₳ No rationale