Scalus: Cardano’s Application Platform for Building, Launching, and Scaling
158 DReps voted · 57 with a rationale · 5 changed their vote
Open a row to read the rationale.
- No8.1M ₳No rationale
- No7.6M ₳Rationale
Voting NO
Scalus appears to have delivered most of its 2025 proposal, which was focused on the developer workflow. The team is talented and is pushing the Bifrost bridge with Fluid Tokens.
The 2026 Cardano Treasury already funded Amaru and Dingo, and Gerolamo is possibly also in the mix for 2026. So I do not think we have room for another large L1-node workstream in 2026. There is a limit to what the Treasury can responsibly fund in one cycle - especially with the future maintenance coming down the line later.
Scalus still looks useful. Cardano needs more application-layer leverage, and Scalus can help teams build serious apps faster. But in 2026, it should sit above the node projects, not become another one in 2026. Given the funding reality we have right now, there might be room for a narrower Scalus proposal focused on the application layer - if this does not pass. Keep in mind I lean conservative with the spending. - Abstain7.2M ₳No rationale
- Abstain5.9M ₳Rationale
I am voting Abstain.
This is one of the more thoughtfully constructed proposals in the cycle, and unlike many infrastructure asks, it is at least directly focused on improving application delivery and reducing builder friction. The team has existing integrations, prior delivery history, and a credible understanding of the operational challenges developers face on Cardano today.
My hesitation is primarily around scope, scale, and execution risk. This proposal attempts to cover an enormous surface area simultaneously — smart contracts, runtime infrastructure, node capabilities, developer tooling, and L2 integration — all within a single large funding ask. While the vision is compelling, it remains unclear how much of this will translate into durable ecosystem growth versus expanded infrastructure complexity.
I also remain cautious about projecting adoption outcomes too far ahead. More tooling and platform capability do not automatically guarantee meaningful increases in users, transactions, or economic activity. We have seen that pattern before across the ecosystem.
I respect the quality of the work and the seriousness of the proposal, but given the size of the ask and the number of assumptions embedded in the long-term adoption thesis, I am not fully convinced enough to support it outright at this stage.
- No5.8M ₳No rationale
- Yes5.4M ₳No rationale
- No5.3M ₳Rationale
STORM Partners votes NO on Scalus: Cardano’s Application Platform for Building, Launching, and Scaling.
We recognize the technical strength of the proposal and the credibility of the Lantr team. Scalus addresses a real problem in Cardano: application delivery remains too complex, and builders often need to assemble too many fragmented tools before they can ship serious products. The JVM focus is also strategically relevant, especially for enterprise and financial software teams.
That said, the requested amount is significant at ₳8.5M, and the roadmap is broad across smart contracts, node infrastructure, application runtime, L2 integration, formal verification, and production operations. While these are valuable areas, the proposal still reads more like a platform expansion than a near-term adoption driver with clear usage already pulling it forward.
Given the current Net Change Limit constraints and the volume of infrastructure-related proposals competing for treasury capacity, we believe the treasury should prioritize proposals with more direct, measurable, and near-term adoption impact. This is a respectful NO based on prioritization, not a rejection of the team or the long-term value of the work.
- No4.8M ₳No rationale
- No4.7M ₳No rationale
- Yes4.6M ₳No rationale
- Abstain4.4M ₳Rationale
I will abstain from proposals that are nice to have but not true priorities at this stage.
Adding support for yet another language on top of those we already have falls squarely into this category, especially in the current AI era, where developers routinely leverage powerful AI tools to work across languages efficiently.
- Yes4.2M ₳No rationale
- No4.1M ₳Rationale
[Portuguese]
Optamos por votar "NÃO" nesta ação de governança "Scalus: Cardano’s Application Platform for Building, Launching, and Scaling" (gov_action1uzgqlh049u0j7epel29r425vyf9ttxmqwngw9kemyly0q6cwt5esqpwp09a), pois, embora reconheçamos a relevância da proposta e o histórico técnico da Lantr Engineering, entendemos que o pedido de ₳8.503.000 representa um investimento elevado diante dos riscos de execução ainda presentes. A proposta apresenta uma visão ambiciosa para criar uma plataforma integrada de desenvolvimento, lançamento e escalabilidade de aplicações em Cardano, com potencial para fortalecer significativamente a experiência de desenvolvedores e acelerar a adoção do ecossistema. No entanto, parte importante do valor prometido depende da conclusão bem-sucedida de diversos componentes ainda em desenvolvimento, incluindo o application runtime, funcionalidades mais avançadas do nó L1 e integrações com projetos de terceiros, como Hydrozoa/Gummiworm e Blaster. Também observamos que a própria proposta reconhece riscos relevantes relacionados à execução, adoção de mercado, coordenação técnica e capacidade operacional da equipe. Em nossa avaliação, a combinação de um escopo amplo, múltiplas dependências externas e benefícios ainda condicionados à adoção futura reduz a previsibilidade dos resultados e dificulta a avaliação objetiva do retorno esperado para o ecossistema. Apoiamos investimentos em infraestrutura aberta, ferramentas para desenvolvedores e iniciativas que fortaleçam a camada de aplicações da Cardano. Contudo, entendemos que uma solicitação dessa magnitude deveria estar acompanhada de maior maturidade dos componentes centrais, metas mais graduais e mecanismos adicionais de validação dos resultados. Por esse motivo, nosso voto é "NÃO" neste momento, não por discordarmos da visão do projeto, mas por considerarmos que a relação entre custo, risco de execução e impacto mensurável ainda não se encontra suficientemente equilibrada para justificar a aprovação do valor solicitado.
[English]
We chose to vote "NO" on this governance action "Scalus: Cardano’s Application Platform for Building, Launching, and Scaling" (gov_action1uzgqlh049u0j7epel29r425vyf9ttxmqwngw9kemyly0q6cwt5esqpwp09a), because although we recognize the relevance of the proposal and the technical track record of Lantr Engineering, we believe that the requested ₳8,503,000 represents a substantial investment given the execution risks that remain. The proposal presents an ambitious vision for an integrated platform focused on building, launching, and scaling applications on Cardano, with the potential to significantly improve the developer experience and accelerate ecosystem adoption. However, a significant portion of the promised value depends on the successful completion of several components that are still under development, including the application runtime, more advanced L1 node capabilities, and integrations with third-party projects such as Hydrozoa/Gummiworm and Blaster. We also note that the proposal itself acknowledges meaningful risks related to execution, market adoption, technical coordination, and team capacity. In our assessment, the combination of a broad scope, multiple external dependencies, and benefits that remain contingent on future adoption reduces delivery predictability and makes it more difficult to objectively evaluate the expected return for the ecosystem. We support investments in open infrastructure, developer tools, and initiatives that strengthen Cardano’s application layer. However, we believe that a funding request of this magnitude should be accompanied by greater maturity of the core components, more gradual milestones, and additional mechanisms to validate outcomes. For these reasons, our vote is "NO" at this time—not because we disagree with the project’s vision, but because we believe the balance between cost, execution risk, and measurable impact is not yet sufficient to justify approval of the requested amount. - Abstain4M ₳No rationale
- Abstain3.8M ₳No rationale
- No3M ₳No rationale
- Abstain2.8M ₳No rationale
- Yes2.7M ₳No rationale
- Yes2.6M ₳No rationale
- Yes2.6M ₳Rationale
私は本提案に賛成します。Scalusは、単にScalaでCardanoスマートコントラクトを書くための開発環境ではなく、Cardano上で本格的なアプリケーションを構築し、検証し、起動し、L2で拡張するための統合アプリケーション基盤へ発展しようとする提案です。
Cardanoの次の課題は、L1そのものだけでなく、実用アプリを継続的に作り、運用できるアプリケーション層にあるとの考えに同意します。また、ScalusがScala、Java、Kotlinを含むJVMエコシステムからCardanoへの導線を作る点も重要です。金融機関やFinTechの実務システムではJVM系技術が広く使われており、Cardanoの企業・金融領域への接続を広げる可能性があります。
Scalusは、主権的チェーンアクセスを重視し、外部APIや集中型データアクセスへの依存を減らす方向性を持っています。Cardano本体が分散していても、アプリのデータアクセス層が集中すれば、実利用は再び中央集権化します。その意味で、ScalusはBlockfrost / Cayleyの議論ともつながる重要な別解です。
一方で、₳8.5Mという規模を正当化するには、外部チームによる実利用、production-like deployment、採用KPI、マイルストーン達成状況を厳格に確認する必要があります。私はその継続的な需要検証と公開報告を前提に、本提案を支持します。
I support this proposal.
Scalus is not merely a development environment for writing Cardano smart contracts in Scala. It aims to evolve into an integrated application platform for building, verifying, launching, and scaling serious applications on Cardano, including L2 support.
I agree with the view that Cardano’s next challenge is not only the L1 itself, but also the application layer where real-world applications can be continuously built and operated. It is also important that Scalus creates a path from the JVM ecosystem, including Scala, Java, and Kotlin, into Cardano. Since JVM-based technologies are widely used in financial institutions and FinTech backend systems, Scalus may help expand Cardano’s connection to enterprise and financial use cases.
Scalus also emphasizes sovereign chain access and aims to reduce reliance on external APIs or centralized data access providers. Even if Cardano’s base layer is decentralized, actual usage can become re-centralized if the application data access layer is concentrated. In this sense, Scalus provides an important alternative path connected to the broader Blockfrost / Cayley discussion.
At the same time, an ₳8.5M request requires strict validation of demand and adoption. I support this proposal on the condition that external team usage, production-like deployments, adoption KPIs, and milestone progress are reviewed and reported transparently.
- Abstain2.5M ₳No rationale
- No2.5M ₳Rationale
if you use this and want it DM me
- No2.3M ₳No rationale
- YesChanged2.1M ₳History
Earlier votes
No2mo agoSuperseded
- No2.1M ₳Rationale
This proposal still appears unbalanced in terms of scope, dependencies, and schedule.
- Abstain2.1M ₳Rationale
I am voting ABSTAIN on the Scalus: Cardano’s Application Platform proposal.
I believe this proposal is directionally valuable and addresses a real challenge for Cardano: improving developer experience, application-layer infrastructure, smart contract tooling, verification workflows, and the ability for builders to ship production-ready applications more easily.
I also recognise that the Lantr / Scalus team has already delivered meaningful work, and this proposal is materially stronger than many treasury requests in terms of structure, technical ambition, milestone design, oversight, and treasury-control mechanisms.
However, I am not fully comfortable voting Yes on this version of the proposal.
The ask of ₳8.503m is significant, and I do not believe there is currently enough demonstrated adoption, community consensus, or proven demand from the wider developer market to justify approving this level of funding at this stage. The proposal may be technically strong, but treasury funding also requires proportionality, timing, and confidence that the requested investment matches ecosystem readiness.
I also take the current community signal seriously. The live voting trend shows substantial resistance, and while I do not believe that should automatically determine every DRep’s vote, it does suggest that the proposal has not yet won sufficient trust or conviction from the ecosystem.
My abstain vote is therefore not a rejection of Scalus, Lantr, JVM tooling, developer infrastructure, or application-layer investment. It is a signal that I would like to see this proposal return in a more staged, smaller, adoption-measured format with clearer evidence of demand and a more incremental funding path.
I support the direction, but I cannot actively support the full treasury ask in its current form.
For those reasons, I am voting ABSTAIN.
- Abstain2M ₳No rationale
- No1.9M ₳No rationale
- No1.8M ₳Rationale
This looks like an interesting project but the ask is too high for an early-stage initiative. It would be better suited for Catalyst funding, in smaller more focused workstreams.
- No1.7M ₳No rationale
- No1.7M ₳No rationale
- No1.6M ₳No rationale
- No1.6M ₳Rationale
I am voting NO on this proposal because, given the limited treasury resources and competing priorities, I do not believe the requested amount of 8.5 million ada represents a justified use of treasury funds at this time.
- No1.6M ₳No rationale
- No1.4M ₳No rationale
- Yes1.4M ₳No rationale
- No1.4M ₳No rationale
- No1.3M ₳No rationale
- Yes1.2M ₳No rationale
- Abstain1.1M ₳No rationale
- YesRevoted1.1M ₳History
Earlier votes
Yes1mo agoSuperseded
- No1.1M ₳Rationale
Scalus got funded in 2025 to validate a development platform thesis. Now, **less than a year later, the ask jumps to ₳8.5M and the scope balloons. With verification still ongoing and not concluded. We're horizontally expanding the scope, which is unacceptable without concrete evidence. **Finish the validation first, then we talk!
I say if often, but it's worth repeating: The treasury is not a venture fund underwriting platform ambition. The treasury is first and foremost risk capital for demonstrated ecosystem demand. And the numbers here do not support this leap. JavaScript, TypeScript, Python, Haskell, Aiken… there's the pull. has real pull. Scalus, by their own metrics, is early and narrow.
What the wizkids on Cardano still don't understand in their coding dorms is that **enterprises do not adopt blockchains because the runtime feels familiar. Institutional adoption happens when users, liquidity, and revenue already exist. **Platforms follow traction, not the other way around!
Furthermore, adding another application‑centric node stack without clear necessity risks fragmentation, duplication, and governance fatigue. Infrastructure gravity is already heavy. What we lack and dearly need is usage.
- No971.5K ₳Rationale
Scalus: Cardano’s Application Platform for Building, Launching, and Scaling
Rationale
We are voting against this proposal because, while we recognize the quality of the team and the work already delivered, we are not convinced that Cardano currently needs another large-scale application platform. The ecosystem already offers a wide range of developer tools, SDKs, frameworks, and infrastructure solutions, and we believe the priority should be driving adoption and usage of existing solutions rather than funding yet another platform.
With a treasury request of over 8.5 million ADA, we do not see a sufficiently clear path to ecosystem-wide impact that justifies the cost. Given limited treasury resources, we would prefer funding initiatives that directly drive users, transactions, liquidity, and adoption rather than expanding an already crowded tooling landscape.
- No964.1K ₳No rationale
- No931.8K ₳No rationale
- No923.6K ₳No rationale
- No861.5K ₳No rationale
- No825.2K ₳Rationale
Impact Assessment (Pros/Cons)
Pros
Enterprise Language Bridge: Taps into the vast Java Virtual Machine (JVM) developer ecosystem (Java, Kotlin, Scala), lowering the entry barrier for traditional enterprise developers who find Haskell or pure Plutus restrictive.Full-Stack Cohesion: Enables a unified development experience where a single language can theoretically span smart contracts, backends, and frontends, speeding up development lifecycles.
Mature Ecosystem Foundations: Builds upon the existing Scalus open-source implementation, leveraging familiar tooling, robust compilers, and existing JVM debugging infrastructure.
Cons
Aggressive Treasury Ask: A request of over ₳8.5 million imposes a substantial burden on the Cardano Treasury during a time when resource conservation is paramount.Unclear Direct Growth Metrics: While the technical infrastructure is highly sophisticated, the proposal lacks definitive, short-term indicators showing how this platform will immediately translate into a surge of live on-chain transactions or active users.
Execution Risk: The broad scope of building, launching, and scaling a unified platform within a fixed timeline presents significant delivery and oversight challenges.
Final Recommendation
Vote: NORationale
Our core governance mandate requires us to protect user trust, maintain long-term treasury viability, and champion sustainable ecosystem expansion. While Scalus is an impressive technical milestone that provides valuable engineering options for JVM developers, the current market climate necessitates strict fiscal responsibility.The ₳8,503,000 price tag is exceptionally steep. At this juncture, treasury deployment must be explicitly tied to immediate, measurable ecosystem growth, transaction volume, or user acquisition. Because it remains unclear how this application platform will directly catalyze rapid adoption relative to its high cost, we cannot justify the expenditure at this time. We highly encourage the proposers to refine their growth onboarding strategies and resubmit a more modular or cost-effective version under better market conditions.
Historical Coherence Report
This decision marks a strategic shift from our recent pattern of supporting core developer tooling, such as our positive votes on the Developer Experience Initiative and High Assurance Technical Collaborations. While we historically champion technical infrastructure, the combined scale of recent treasury withdrawals demands that we raise the financial bar for approval. This shift is a direct response to community feedback regarding treasury preservation and a macro-level necessity to prioritize immediate real-world utility over long-term tooling optimization.Latin American Ecosystem Impact:
For the Latin American community, expanding JVM-compatible infrastructure holds immense potential, as the regional IT sector is heavily populated by Java and corporate software developers. However, allocating a massive portion of collective treasury funds to deep infrastructure projects—rather than local grassroots expansion, builder grants, and direct regional onboarding—restricts the immediate capital liquidity needed to drive real-world adoption in LatAm. Defending the treasury now ensures that funding remains available for high-impact, locally accessible initiatives that directly empower Latin American builders and users. - No798.6K ₳Rationale
The Scalus platform vision is compelling and the team has a strong delivery record, but the core of this proposal is a significant investment in another Cardano node implementation. We'd prefer to see how those efforts mature before committing to additional nodes in the ecosystem. We remain open to revisiting as the node diversity landscape becomes clearer.
- Yes798.4K ₳Rationale
Voting YES. Cardano’s next bottleneck is application delivery, not base-layer infrastructure. Scalus directly addresses that by building an integrated application platform combining smart contracts, runtime infrastructure, sovereign chain access, and native L2 integration in a JVM-native stack. The proposal is technically ambitious, but strategically aligned with improving developer experience, application-layer growth, and long-term ecosystem competitiveness.