Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime
144 DReps voted · 54 with a rationale · 3 changed their vote
Open a row to read the rationale.
- No5.9M ₳Rationale
I am voting No.
This is consistent with my prior review during the Intersect budget process, where this proposal did not make my final supported list. While I recognize the effort and potential value behind Scalus, I remain unconvinced that this funding request should be prioritized against the broader set of treasury needs. The scope is large, the adoption case is still uncertain, and I do not believe this clears the bar for support at this time.
- No5.7M ₳No rationale
- Abstain5.4M ₳No rationale
- No5.4M ₳Rationale
as per rationale through intersect process
- Yes4.8M ₳No rationale
- Yes4.6M ₳No rationale
- Abstain4.4M ₳No rationale
- Yes4.2M ₳No rationale
- Yes4.1M ₳Rationale
[Portuguese]
Optamos por votar "SIM" nesta ação de governança "Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime" (gov_action1xg6...qa63yc), pois entendemos que a proposta assegura a continuidade e a evolução de uma infraestrutura já utilizada por diversos projetos e ferramentas do ecossistema Cardano. Além da manutenção da plataforma, a iniciativa prepara o Scalus para o hard fork Dijkstra e amplia sua interoperabilidade com os ecossistemas JVM e JavaScript/TypeScript, fortalecendo a base tecnológica para o desenvolvimento de aplicações descentralizadas. O valor solicitado, de aproximadamente ₳2,46 milhões para um período de nove meses, é significativamente inferior ao da proposta anteriormente apresentada e nos parece compatível com o escopo previsto, oferecendo uma boa relação entre custo e benefício. Também avaliamos positivamente a experiência da equipe e o potencial impacto da iniciativa para desenvolvedores e projetos que dependem dessa infraestrutura. Além disso, consideramos adequados os mecanismos de governança, controle e transparência previstos, incluindo pagamentos condicionados ao cumprimento de marcos, contratos de custódia auditados, supervisão por um conselho independente, auditoria técnica externa, relatórios trimestrais e registro público das movimentações financeiras. Esses elementos proporcionam maior segurança na utilização dos recursos da Tesouraria e permitem um acompanhamento transparente da execução do projeto.
[English]
We chose to vote "YES" on this governance action "Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime" (gov_action1xg6...qa63yc), because we believe the proposal ensures the continued maintenance and evolution of infrastructure already used by multiple projects and tools across the Cardano ecosystem. Beyond maintaining the platform, the initiative prepares Scalus for the Dijkstra hard fork while expanding interoperability with the JVM and JavaScript/TypeScript ecosystems, strengthening the technological foundation for decentralized application development. The requested budget of approximately ₳2.46 million over a nine-month period is significantly lower than the previous proposal and, in our view, represents a reasonable cost-benefit balance given the scope of work, the team's experience, and the potential impact on developers and ecosystem projects. We also view the proposal’s governance, oversight, and transparency mechanisms positively. These include milestone-based payments, audited escrow contracts, oversight by an independent council, external technical audits, quarterly reporting, and public disclosure of financial transactions. Together, these measures provide greater confidence in the responsible use of Treasury resources while enabling transparent monitoring of project execution. - Yes3.5M ₳No rationale
- Yes3.2M ₳No rationale
- No3.1M ₳Rationale
I have reached the limit I am willing to spend on research-related products for this year's NCL. I don't see how this spend will have any financial benefit for Cardano.
- YesChanged2.8M ₳Rationale
Request is extremely reasonable.
Financial information is there.
Widely adopted and open source.
Earlier votes
Abstain17d agoSuperseded
Request is extremely reasonable.
Financial information is there.
Widely adopted and open source.
- Yes2.8M ₳No rationale
- Yes2.6M ₳Rationale
私は本Treasury Withdrawalに賛成します。
本提案は、Scalusを広範なapplication platformへ拡張する大きな構想から、Cardanoの共有開発者インフラとして継続・保守する、より焦点を絞った提案へ修正されています。特に、Dijkstra hard forkへの対応は、smart contract、transaction building、emulation、testing、developer workflowの互換性を維持するうえで重要です。
また、JVM-nativeな開発導線は、企業や金融系backend開発者とCardanoをつなぐ戦略的な橋渡しとして評価できます。加えて、前回案に含まれていたstandalone L1 nodeの開発スコープが除外されたことで、資金要求はより適正な規模となり、実行リスクも低下しています。
I support this Treasury Withdrawal because the proposal has been narrowed from a broad platform expansion into a focused continuation of Scalus as shared Cardano developer infrastructure. In particular, Dijkstra readiness is important for maintaining compatibility across smart contracts, transaction building, emulation, testing, and developer workflows. I also value the JVM-native path as a strategic bridge to enterprise and financial backend developers. Importantly, the previous standalone L1 node scope has been removed, which makes the ask more proportionate and reduces execution risk.
- Abstain2.5M ₳No rationale
- Abstain2.5M ₳Rationale
Due to rationales becoming stressful and the bear market vibes - I will not be providing rationale. I voted the way that I did bc we need a 'no stress' environment more than ever.
- YesChanged2.3M ₳History
Earlier votes
No1mo agoSuperseded
- Yes2.2M ₳No rationale
- No2.2M ₳No rationale
- Yes2.1M ₳Rationale
This proposal represents a proportionate continuation of an established open-source developer platform that alredy provides value to the Cardano ecosystem.
- Yes2.1M ₳Rationale
I am voting YES on the revised Scalus 2026 proposal.
My previous concern with Scalus was not that the technology lacked value, but that the earlier proposal was too broad, too expensive, and tried to fund too much at once relative to demonstrated demand and current treasury capacity.
This revised proposal materially addresses those concerns.
The ask has been reduced significantly to 2,464,844 ADA over 9 months, with no contingency. The scope has also been narrowed meaningfully. The standalone L1 node, full L2 integration, and broad formal-verification work are now out of scope. Instead, the proposal focuses on maintaining the existing Scalus stack, preparing it for Dijkstra, improving interoperability across JVM and JavaScript/TypeScript ecosystems, and validating a bounded application-runtime step.
That is a much more proportionate and responsible request.
Scalus is already used directly or indirectly across parts of the Cardano developer ecosystem, including projects and tools such as Gummiworm L2, Bifrost, SugarRush, Vela, DID/DIDComm, MeshJS, Evolution SDK, Lucid Evolution, Cardano Client Lib, and YaciDevKit. I believe there is value in maintaining and improving a JVM-native development path for Cardano, especially where it supports serious protocol, DeFi, bridge, identity, and enterprise-style application development.
In the current NCL environment, I am prioritising infrastructure, developer tooling, compatibility work, self-custody, and open-source public goods over larger speculative or commercial treasury requests. This revised Scalus proposal fits that framework far better than the original version.
I also view positively the milestone-based delivery structure, independent oversight, third-party assurance, financial audit allocation, escrow-based treasury management, and automatic return of unused funds.
This is a good example of governance working as intended: DReps and the community raised concerns, the proposer listened, and the revised proposal came back smaller, narrower, and more accountable.
For these reasons, I consider this a responsible use of treasury funds.
I vote YES.
- No1.9M ₳No rationale
- Yes1.8M ₳No rationale
- Yes1.8M ₳Rationale
I voted no last time, but this is a different proposal with a reduced scope and ask.
What’s left is worth funding: including keeping the widely-used Scalus components maintained, and making them easier to reuse.
- Yes1.8M ₳No rationale
- Yes1.7M ₳No rationale
- Abstain1.6M ₳No rationale
- Abstain1.5M ₳No rationale
- No1.3M ₳No rationale
- No1.2M ₳No rationale
- No1.2M ₳No rationale
- No1.2M ₳No rationale
- No1.1M ₳No rationale
- Yes1.1M ₳Rationale
Scalus is a key part of Cardano’s developer tools. The planned budget cut from ₳8.5M to ₳2.5M, along with a cautious ADA reference rate, shows that they're paying attention to community concerns and financial realities, which is good.
However, this proposal has to find a balance between keeping things running smoothly and expanding slowly, without falling into the trap of relying too much on a single vendor. By dropping ambitious plans like the standalone L1 node and full L2 integration, they are lowering risk, but they’re also missing opportunities for significant improvements in scalability and composability. While the focus on interoperability and application runtime is encouraging, the actual demand and adoption figures are still pretty low, making the return on this funding a bit uncertain.
There are other options in the Cardano ecosystem, like better support for Plutus-native tools or cross-language SDKs, that might attract developers more quickly. I appreciate the transparent governance they propose, but the true challenge will be executing everything effectively with a small team and getting buy-in from the ecosystem. Since it’s important to balance innovation with careful handling of finances, I’m in favor of support but want to make sure we keep a close eye on everything and demand measurable results. I expect stringent accountability for milestones and transparent reporting on adoption.
- No988.7K ₳Rationale
We vote NO on this proposal.
We acknowledge that the revised Scalus proposal is more focused and significantly smaller than the previous version. We also recognize the technical quality of the team and the potential value of better interoperability, Dijkstra readiness and developer tooling.
However, we are not convinced that funding another open-source development platform is the right priority for the Cardano Treasury at this stage. The ecosystem already has several developer stacks, libraries, SDKs and tooling initiatives, and we believe the focus should be on stabilizing and maintaining the tooling that is already broadly used by builders.
In particular, we would prefer to see treasury funding directed toward keeping existing TypeScript infrastructure, wallet integrations, SDKs and core developer tools reliable, compatible and easy to use. Adding or expanding another platform risks further fragmenting the developer experience instead of improving it.
Cardano needs better developer experience, but that does not necessarily mean funding more platforms. Given limited treasury resources, we believe the priority should be consolidation, maintenance and adoption of existing tooling rather than expanding the tooling landscape further.
For these reasons, we vote no.
- Abstain988.4K ₳No rationale
- Yes964.5K ₳No rationale
- Yes881.9K ₳No rationale
- Yes870.4K ₳No rationale
- Abstain862K ₳No rationale
- Yes830.3K ₳Rationale
Expanding Cardano beyond its Haskell-centric roots is critical to attracting mainstream developer talent. The JVM environment hosts millions of developers worldwide. Scalus is not merely an experimental framework; it is an essential piece of infrastructure that allows enterprise systems to interact natively with Plutus smart contracts on the JVM.
Funding the 2026 roadmap ensures that as the Cardano ledger evolves through its upcoming technical phases (such as Dijkstra), enterprise integrators will not be left with broken or outdated tools. The requested funding represents a high-value return on investment regarding long-term infrastructure stability and enterprise readiness.
Treasury NCL Check: The requested budget is reasonable and does not breach the current epoch’s Net Change Limit (NCL).
Historical Coherence: This vote aligns consistently with our prior support for developer tooling diversity, open-source alternative runtimes, and robust technical infrastructure.
Latin American Ecosystem Impact
For Latin America, the success of Scalus 2026 is highly strategic. The region possesses a vast pool of legacy Java and JVM-centric software engineers working in major fintech, banking, and government sectors (notably in countries like Brazil, Colombia, and Argentina). By maintaining a fully compatible, production-ready Scala/JVM Plutus implementation, we lower the barrier of entry for local software factories and financial institutions. This enables them to build secure Cardano-based decentralized applications using their existing engineering talent, driving regional institutional adoption without requiring expensive Haskell retraining. - Yes799.1K ₳Rationale
Reason: Scalus is an established open-source development platform with demonstrated ecosystem reuse and a strong delivery record. This revised proposal responds directly to prior governance feedback by substantially reducing its budget and scope while focusing on maintenance, Dijkstra hard-fork readiness, interoperability, and a narrowly scoped runtime enhancement. Protecting existing public infrastructure and ensuring compatibility through protocol upgrades represents a high-leverage use of treasury funds, and the proposal combines that with credible governance, transparent reporting, and milestone-based accountability.
- No795K ₳No rationale
- Yes753.7K ₳No rationale
- Yes698.7K ₳No rationale
- Yes626K ₳Rationale
Vote Yes on Scalus 2026. Funds developer infrastructure and Dijkstra readiness for a platform used by Gummiworm, Bifrost, SugarRush, and embedded in MeshJS and Lucid Evolution. Ask reduced 71 percent from prior proposal. Strong accountability with independent oversight.
A PDF version of this rationale is also made available.
I am voting Yes on this proposal. Scalus is proven developer infrastructure with components embedded in tools that thousands of Cardano developers use every day. The 2.46 million ADA ask is proportionate and represents a 71 percent reduction from the prior proposal that DReps found too large. This shows the team listened to feedback and adjusted accordingly.
The maintenance and Dijkstra readiness work alone justifies the ask. Without it, embedded Scalus components in MeshJS, Lucid Evolution, and other tools risk becoming incompatible with the next protocol version. That would create friction for developers across the ecosystem.
I acknowledge Lantr Engineering has multiple active Treasury requests including Bifrost. I evaluated each proposal independently on its merits. Scalus stands on its own as a sound continuation of proven work with a reasonable price tag.
- Abstain620K ₳No rationale
- No608.1K ₳No rationale
- Yes590K ₳Rationale
We're going for number 1 and this helps us get there.