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.
- No584.2M ₳Rationale
Summary
Yoroi DRep votes NO on "Scalus: Cardano's Application Platform for Building, Launching, and Scaling", recognising the team's delivery track record and the legitimacy of the problem being addressed, while concluding that the scale of the request is not justified by the adoption evidence available today.
Rationale
A capable team addressing a real problem
Lantr Engineering has delivered consistently across prior funding cycles, completed milestones on time, and contributed meaningfully to Cardano's developer tooling ecosystem. The application layer bottleneck Scalus is designed to address is real, and an integrated build-to-production platform is a reasonable response to it. Yoroi does not question the team's capability or intent.The funding leap is disproportionate to demonstrated adoption The proposal requests 8,503,000 ADA, nearly eight times the cumulative funding Scalus has received to date, with adoption targets that set a floor of five external teams and two production deployments during the funding period. That gap between the scale of the ask and the scale of validated demand is difficult to bridge. Treasury commitments of this magnitude are most defensible when they are building on proven traction, not projecting it.
The JVM thesis needs more validation before this level of investment The central argument for Scalus is that it opens Cardano to the JVM developer ecosystem. That argument is credible in principle, but the evidence of actual JVM developer interest in Cardano today is limited. Yoroi would be more comfortable supporting a focused follow-on proposal that demonstrates early platform adoption and validates the JVM entry thesis before the community commits to platform-scale funding.
Conclusion
Yoroi respects the work Lantr Engineering has contributed to the Cardano ecosystem and the technical quality behind the Scalus platform. Our NO vote is a considered view on proportionality, not a rejection of the project, and we would welcome a resubmission with a scope that better reflects current adoption. - No435.8M ₳Rationale
I am voting NO to "Scalus: Cardano’s Application Platform for Building, Launching, and Scaling."
This is because I believe the current proposal does not provide sufficient justification for the demand for Scalus to justify an $8.5 million investment. However, I may change this vote if I can find more evidence to support the demand for Scalus.
—
私は「Scalus: Cardano’s Application Platform for Building, Launching, and Scaling」にNOを投票します。
現在の提案書上、Scalusに8.5Mを投資することを正当化しうる需要の根拠が記載されていないと判断したためです。ただし、Scalusの需要についての裏付けが取れたらこの投票を変更する可能性があります。
- Abstain332.2M ₳No rationale
- No293M ₳Rationale
Summary
EMURGO as a DRep votes NO on the treasury withdrawal titled "Scalus: Cardano's Application Platform for Building, Launching, and Scaling", with rationale outlined below.
Rationale
EMURGO recognises the quality of the Lantr Engineering team and the genuine problem Scalus is designed to solve. The application layer remains a real bottleneck for Cardano, and the argument that builders need an integrated platform rather than a collection of tools to assemble themselves is well-founded. The team has demonstrated delivery discipline across three years of Catalyst funding and a 2025 treasury cycle, completing milestones on time and publishing public reporting throughout.
The core concern is proportionality. Scalus has received approximately 1,085,692 ADA in total across Catalyst and treasury funding. This proposal requests 8,503,000 ADA, nearly eight times all prior funding combined, for a platform whose JVM adoption thesis within Cardano remains largely unvalidated. The developer survey data available today shows Cardano developers primarily rely on JavaScript, TypeScript, Python, Rust, and Haskell, with Scalus selected by a small number of respondents as their smart contract language of choice. The argument that Scalus opens Cardano to 26 million JVM developers reflects long-term market potential, not demonstrated current demand within the ecosystem.
Treasury funding at this scale should be anchored to demonstrated traction, not projected adoption. The proposal itself sets adoption targets of five external teams and two production deployments during the funding period, which does not reflect the level of validated demand that would justify a commitment of this magnitude. For these reasons, EMURGO votes NO. - Abstain222.9M ₳Rationale
ABSTAIN on Scalus: Cardano’s Application Platform for Building, Launching, and Scaling;
Sound proposal, capable team, nice-to-have features. But we can't currently justify a YES vote.
- Yes165.7M ₳No rationale
- Yes120.2M ₳Rationale
The Cardano Foundation votes YES. We believe Scalus is a credible application platform that supports Cardano’s developer experience, node diversity, and scalable application delivery, with appropriate milestone oversight.
A PDF version of this rationale is also made available.
We recognize Lantr Engineering as a capable and professional team with three years of continuous delivery behind Scalus. Our decision to support this proposal is driven by the following factors:
- Demonstrated Delivery and Adoption: This proposal extends an existing platform rather than funding a greenfield concept. Lantr delivered against its 2025 Treasury Withdrawal, and our technical reviewers note that Scalus is, in their assessment, among the smart-contract ecosystems on Cardano showing measurable adoption, with capabilities already integrated into MeshJS SDK, Cardano Client Lib, and Evolution SDK, and projects such as Hydrozoa and Bifrost building on it. We view a track record of shipped, used infrastructure as material evidence of execution capability.
- Strategic Alignment: The proposal aligns with the Core Development principle of "Our Cardano." An application-focused, JVM-native node contributes to client diversity and conformance work alongside the Node Diversity initiative, mitigating single points of failure, while the broader platform targets the application layer that underpins Cardano 2030's adoption goals.
- Robust Administration and Oversight: Funds are held in the independently audited SundaeSwap treasury-contracts escrow, with milestone-based vesting, an independent oversight board empowered to co-sign disbursements and halt funding, an independent technical assurer (No.Witness Labs), and an external financial audit. Escrowed funds are subject to auto-abstain DRep delegation and no SPO delegation, and unused funds sweep back to the Treasury at the contract level. This is a suitable standard of verifiable transparency and accountable deployment.
We note that not all of these merits are yet fully proven: the platform's uptake into shipped, end-user applications remains an open question, and the roadmap depends in part on third-party projects. We view the proposal's milestone structure, public quarterly reporting, and oversight mechanisms as adequate to surface and manage these risks during delivery.
The Cardano Foundation votes YES. We commend Lantr Engineering for building on a proven platform with disciplined budgeting and strong oversight, and we look forward to seeing the funded work translate into more teams shipping, operating, and scaling serious applications on Cardano.
---> **_NOTE on 'Internal Voting':_**> The fields _constitutional_ and _unconstitutional_ below reflect the CF governance teams' individual opinions whether they are _for_ or _against_ the proposal. Reason for this inconsistency is, that CIP-136 is at the moment only applicable to CC rationales, but we want to record the internal opinions of our DRep assessment transparently as well. - Abstain92.2M ₳No rationale
- No91.5M ₳Rationale
As a DRep, I decided to vote NO for proposal: Scalus: Cardano’s Application Platform for Building, Launching, and Scaling
My rationale:
I want to be clear that this is not a vote against Scalus as a technical project or against the capabilities of Alexander Nemish and the Lantr team. The team has delivered tangible outputs and has clearly contributed meaningful work to the Cardano ecosystem.
However, treasury decisions must evaluate not only technical ambition, but also adoption, ecosystem demand, proportionality of funding, and whether prior treasury allocations have demonstrated enough traction to justify significantly larger follow-on funding. After reviewing those factors, I do not believe this proposal meets that threshold.
My primary concern is that this proposal asks the Treasury to make a very large leap before the original thesis has been sufficiently validated.
In 2025, Scalus already received an approved treasury withdrawal of ₳657,692 for “Scalus – DApps Development Platform.” That proposal was approved to validate the idea that Cardano developers could benefit from a Scala-based unified development experience where smart contracts, transaction building, and application logic could all be written in one language.
That treasury allocation was already a significant step up from earlier Catalyst grants, where the team requested much smaller and more narrowly scoped funding.
For example, one Catalyst proposal requested only ₳100,000 for a three-month engagement involving roughly 2.5 months of development by two engineers to build a cross-platform transaction builder API. Earlier Catalyst proposals were similarly focused and relatively modest in scope. In total, Scalus has previously received roughly ₳1.08M across Catalyst and treasury funding.
Now, less than a year later, the team is requesting ₳8.5M, which represents nearly eight times all prior funding combined. While ADA volatility makes USD comparisons imperfect, this is still a very substantial increase.
Last year, the treasury funded a development platform. This year, the Treasury is being asked to fund a full application platform, runtime infrastructure, formal verification tooling, L2 integrations, observability tooling, enterprise onboarding capabilities, and significant node-level infrastructure.
This moves far beyond validating product-market fit and instead expands horizontally into multiple adjacent areas before proving that the original thesis has achieved broad adoption.
That leads directly to my second concern: ecosystem demand.
The proposal repeatedly argues that Scalus unlocks access to millions of JVM developers and creates a bridge for enterprise adoption. However, the actual data we have about Cardano developers tells a different story.
The Cardano Foundation 2025 Developer Ecosystem Survey shows that Cardano developers primarily rely on JavaScript, TypeScript, Python, Rust, and Haskell for broader application development.
On the smart contract side, Aiken has clearly become the dominant non-Haskell language because it directly addresses many of the developer experience concerns highlighted in the survey. When developers were asked what they would use to write Plutus scripts, 83 respondents selected Aiken, while only 10 selected Scalus, the same number as Plu-ts.
The survey highlights demand for better onboarding, documentation, examples, and simpler workflows, but it does not indicate strong demand for a large Scala-centric platform. The “26 million JVM developers” argument reflects theoretical market potential rather than evidence of actual developer adoption within Cardano today.
The proposal also fails to provide meaningful adoption metrics that would justify funding at this level. For an ₳8.5M request, I would expect clear evidence of active developer usage, recurring external contributors, meaningful production deployments, or measurable ecosystem dependence.
The proposal itself reflects how early adoption still is by setting targets of only five external teams, two production deployments, and two ecosystem integrations during the funding period.
I am also concerned about the proposal’s node-related scope. It introduces significant node-level infrastructure ambitions while remaining unclear about how far this effort goes and why this additional infrastructure is necessary at this stage.
Cardano has already allocated substantial treasury resources toward infrastructure, including initiatives such as Amaru and Dingo. Perhaps the Gerolamo proposal will also be approved.
While infrastructure remains important, I believe future treasury allocations should increasingly prioritize growth, user adoption, and helping existing builders scale successfully.
Cardano’s biggest challenge today is not a lack of infrastructure proposals. It is a lack of users, applications with meaningful traction, and broader ecosystem growth. This proposal continues expanding deeper into infrastructure before proving strong demand for what has already been built.
Ultimately, my concern is not the quality of the team or the legitimacy of the project. My concern is proportionality.
Treasury should fund demonstrated ecosystem demand rather than speculative platform expansion. I would have been far more supportive of a smaller proposal in the range of ₳1M–2M focused on validating adoption, proving real usage, and expanding incrementally based on demonstrated demand.
Scalus may still become a valuable part of Cardano’s tooling ecosystem, but I do not believe this level of funding is justified today.
For these reasons, I voted NO.
If you find my governance work valuable, consider supporting me:
MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp - Yes86M ₳Rationale
SIPO DRep votes YES, with expectations, on Scalus: Cardano's Application Platform.
Governance Action ID: gov_action1uzgqlh049u0j7epel29r425vyf9ttxmqwngw9kemyly0q6cwt5esqpwp09a
Legacy Governance Action ID (CIP-105): e0900fddf52f1f2f6439fa8a3aaa8c224ab59b6074d0e2db3b27c8f06b0e5d33#0
DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
Date: 2026-06-03Scalus, built by Lantr Engineering, is an established Scala 3 application-development platform for Cardano with three years of continuous delivery. This proposal extends it from a development environment into a full application platform — one coherent stack to build, verify, launch, operate, and scale Cardano applications, with a Scala-native smart-contract compiler to Plutus Core, an application-facing L1 node, native Hydrozoa/Gummiworm L2 integration, formal-verification integration, an in-memory emulator and local devnet, and a production-grade runtime. SIPO's doctrine treats the application layer as decisive: Cardano's 2030 KPIs — total value locked, monthly transactions, and monthly active users — are all downstream of applications shipping. Scalus addresses the EUTXO "assembly problem" for builders and opens a developer funnel to the large JVM ecosystem (Java, Scala, Kotlin), complementing existing TypeScript and Rust tooling rather than replacing it.
The proposal aligns with several axes SIPO has consistently supported. Its Scala 3 node component — Conway-plus ledger rules, Dijkstra hard-fork readiness, and conformance testing aligned with the Node Diversity initiative — extends client diversity into the JVM language family, alongside Amaru (Rust), Dingo (Go), and the browser node (Gerolamo, TypeScript/WebAssembly). Lantr brings a real delivery record: Catalyst F11 and F13 work delivered at 100%, a 2025 Treasury allocation in execution, and ecosystem dependents — Hydrozoa/Gummiworm state-channel applications and the Bifrost Bitcoin bridge build on Scalus. This extends components that already exist and are in use; it is not a greenfield bet.
SIPO also sees a forward-looking strategic case. As AI-assisted development and AI-agent development advance, Cardano needs more than separate SDKs: it needs an integrated platform where AI and humans can iterate safely and verifiably. Scalus's direction — type-safe contracts, a local emulator and devnet, embedded L1 access, L2 integration, formal-verification integration, and an explicit LLM/AI-readiness workstream including MCP integration and AI-friendly APIs and documentation — positions Cardano to differentiate not on the EVM world's speed and volume, but as a high-assurance, verifiable, autonomously-operable platform for AI-assisted applications. SIPO views this as a strategic investment in that direction.
On treasury protection, the proposal meets SIPO's standard. The withdrawal recipient is a script credential rather than a single key — like the Cardano Vision 2026 research programme SIPO supported this cycle, it is administered through script-based, escrow-style on-chain controls rather than a direct key-controlled payout. An independent, multi-party oversight board with no stake in Lantr co-signs disbursements, reviews milestones, and can pause or halt funding; disbursements are quarterly and milestone-gated; third-party assurance and public reporting continue; and the 10% contingency is refundable, with unspent funds returning to the Cardano Treasury. This is materially different from key-controlled, allocator-style structures, and it is why treasury protection supports rather than blocks this vote.
SIPO's support is not unconditional. Real questions remain — the adoption breadth of a niche language (Scala/JVM) relative to the ₳8,503,000 ask, the width of a scope spanning platform, node, L2, and runtime, the portfolio boundary with TypeScript tooling such as Evolution SDK, MeshJS, and the Cardano Client Lib, and the current strong No trend among DReps. SIPO treats these as matters to monitor after support, not as grounds for rejection. SIPO therefore votes Yes with the following expectations: (1) publish quarterly KPIs for JVM/Scala developer onboarding and real-application adoption; (2) make explicit the complementarity boundary with Evolution SDK, MeshJS, and the Cardano Client Lib; (3) align the Scala 3 node implementation with the Node Diversity initiative and conformance testing; (4) strengthen AI-assisted-development readiness — documentation, templates, the test loop, and MCP integration; and (5) continue returning unused contingency to the Treasury and maintaining a public transaction journal. SIPO supports Scalus as an investment in Cardano's application layer, EUTXO developer experience, and a high-assurance application platform for the AI era. This vote is SIPO DRep's recorded position.
SIPO DRep として、本提案「Scalus: Cardano's Application Platform」に期待事項付きで賛成（YES）を投じます。
Governance Action ID: gov_action1uzgqlh049u0j7epel29r425vyf9ttxmqwngw9kemyly0q6cwt5esqpwp09a
Legacy Governance Action ID (CIP-105): e0900fddf52f1f2f6439fa8a3aaa8c224ab59b6074d0e2db3b27c8f06b0e5d33#0
DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
Date: 2026-06-03Scalus は、Lantr Engineering が 3 年にわたり継続提供してきた、Cardano 向けの Scala 3 製アプリケーション開発プラットフォームです。本提案はそれを開発環境から完全なアプリケーション基盤へと拡張します ― Cardano アプリを「作る・検証する・起動する・運用する・スケールする」ための一体のスタックであり、Plutus Core へコンパイルする Scala ネイティブのスマートコントラクト、アプリケーション向けの L1 ノード、Hydrozoa/Gummiworm の native L2 統合、形式検証統合、in-memory emulator とローカル devnet、本番グレードの runtime を含みます。SIPO のドクトリンはアプリケーション層を決定的と捉えます ― Cardano 2030 の KPI（TVL・月次トランザクション・月次アクティブユーザー）はすべてアプリの出荷の下流にあるためです。Scalus は builder の EUTXO「組み立て問題」に応え、TypeScript や Rust のツールを置き換えるのではなく補完しながら、巨大な JVM エコシステム（Java・Scala・Kotlin）への開発者ファネルを開きます。
本提案は、SIPO が一貫して支持してきた複数の軸に合致します。Scala 3 のノード実装（Conway+ 台帳ルール、Dijkstra ハードフォーク対応、Node Diversity initiative と整合した conformance テスト）は、Amaru（Rust）・Dingo（Go）・ブラウザノード（Gerolamo、TypeScript/WebAssembly）に並び、クライアント多様性を JVM 言語族へと拡張します。Lantr には実績があります ― Catalyst F11・F13 を 100% 完納、2025 Treasury 配分を実行中、そしてエコシステムの依存先（Hydrozoa/Gummiworm の state-channel アプリ、Bifrost の Bitcoin ブリッジ）が Scalus 上に構築されています。これは既に存在し使われているコンポーネントの拡張であり、greenfield の賭けではありません。
SIPO は前向きな戦略的論拠も見ています。AI 支援開発・AI エージェント開発が進むほど、Cardano には個別の SDK 以上のもの ― AI と人間が安全かつ検証可能に反復できる統合プラットフォーム ― が必要になります。Scalus の方向性（型安全なコントラクト、ローカル emulator と devnet、embedded L1 アクセス、L2 統合、形式検証統合、そして MCP 統合や AI フレンドリーな API・ドキュメントを含む明示的な LLM/AI 対応ワークストリーム）は、EVM 圏の「速さと量」ではなく、「高保証・検証可能・自律運用可能な AI 支援アプリケーション基盤」として Cardano を差別化する方向に位置づけられます。SIPO はこれをその方向への戦略的投資と見ます。
トレジャリー保護の点で、本提案は SIPO の基準を満たします。引き出し先は単一鍵ではなく script credential であり ― 今期 SIPO が支持した Cardano Vision 2026 研究プログラムと同じく、鍵による直接払い出しではなく、script ベースの escrow 型のオンチェーン制御で管理されます。Lantr に stake を持たない独立した multi-party 監督ボードが disbursement を co-sign し、マイルストーンをレビューし、資金を一時停止・停止できます。disbursement は四半期・マイルストーン条件付きで、第三者 assurance と公開報告が継続し、10% の contingency は返還可能で未使用分は Cardano Treasury に戻ります。これは鍵管理・allocator 型の構造とは本質的に異なり、トレジャリー保護が本投票を妨げるのではなく支える理由です。
SIPO の支持は無条件ではありません。現実の論点は残ります ― ニッチな言語（Scala/JVM）の採用裾野が ₳8,503,000 の要求額に見合うか、platform・node・L2・runtime にまたがる scope の広さ、Evolution SDK・MeshJS・Cardano Client Lib といった TypeScript ツールとの portfolio 境界、そして現時点での DRep の強い No トレンドです。SIPO はこれらを、否決の根拠ではなく、支持後に監督すべき事項と捉えます。したがって SIPO は、以下の期待事項とともに賛成します：(1) JVM/Scala 開発者のオンボーディングと実アプリ採用の四半期 KPI を公開すること、(2) Evolution SDK・MeshJS・Cardano Client Lib との補完境界を明確にすること、(3) Scala 3 ノード実装を Node Diversity initiative と conformance テストに整合させること、(4) AI 支援開発への対応（ドキュメント・テンプレート・テストループ・MCP 統合）を強化すること、(5) 未使用 contingency の Treasury 返還と public transaction journal を継続すること。SIPO は Scalus を、Cardano のアプリケーション層・EUTXO 開発体験・AI 時代の高保証アプリケーション基盤への投資として支持します。本投票は SIPO DRep の記録上の立場表明です。
- No84.3M ₳Rationale
The $2.1 million USD price tag seems very steep for 12 months for a proposal that only seems to list two named team members. Given that our current expenditure trajectory would exhaust the treasury within a decade, I am unconvinced this is the best use of Treasury funds.
- No77.7M ₳No rationale
- No75.2M ₳No rationale
- No74.5M ₳Rationale
I have decided to vote NO on this proposal.
First, I want to clearly state that I strongly support the overall direction of this proposal. Strengthening Cardano’s application layer, improving developer experience, and making it easier to build sophisticated applications are all important long-term goals for the ecosystem. I also recognize that Scalus already has existing integrations and a meaningful development history, which deserves credit.
However, at this stage, I do not believe the actual demand for this platform has been sufficiently demonstrated. While the proposal presents possible future growth in TVL and ecosystem usage, much of that remains based on assumptions and projections. It is still difficult to objectively measure whether there is strong enough ecosystem demand for such a broad integrated application platform today.
In my view, Cardano’s current priority is not primarily the lack of development tooling, but rather the lack of people, businesses, users, and external demand entering the ecosystem. At this stage, attracting developers, business operators, liquidity, and real-world adoption may be more urgent than expanding the tooling stack further.
The current challenge for Cardano appears to be less about technical capability itself, and more about adoption, business development, and ecosystem growth. Given the current Treasury situation, allocating 8.5M ADA toward such a large-scale and wide-scope infrastructure initiative feels difficult to justify at this time.
While I understand and respect the technical vision behind this proposal, I believe a smaller, more incremental approach with clearer demand validation would have been more appropriate under the current circumstances.
私はこの提案に対してNOで投票します。
まず、この提案の方向性そのものには強く賛成しています。Cardanoにおけるアプリケーション層の強化、開発体験の向上、そしてより高度なアプリケーションを構築しやすくするという思想は、長期的に見て非常に重要だと考えています。また、Scalusが既に一定の実績と既存統合を持っている点も評価しています。
しかし一方で、現時点では「このプラットフォーム自体にどれほどの需要が存在するのか」がまだ十分に証明されていないように感じています。提案内では将来的なTVLや利用拡大の可能性が示されていますが、その多くは前提や期待値に依存しており、現段階で明確な需要を測定することは難しいと考えています。
また、現在のCardanoにおける最優先課題は、開発ツールの追加よりも、まず「人を引き込むこと」にあると私は考えています。開発者、事業開発人材、ユーザー、流動性、そして外部のビジネスプレイヤーをCardanoへ呼び込むことが、今はより重要なフェーズではないでしょうか。
現在のCardanoは、技術力不足というよりも、ビジネス面・需要面・採用面の課題が大きいように感じています。その状況の中で、8.5M ADAという大規模な予算を、広範かつ長期的な統合開発プラットフォームへ投入することには慎重であるべきだと考えます。
方向性や技術的価値は理解できる一方で、現在のTreasury状況や優先順位を踏まえると、より小規模な段階的アプローチ、あるいは需要検証を伴う形で進める方が望ましかったと考えています。
- Abstain73.1M ₳Rationale
I am voting ABSTAIN on this standalone proposal. I commend Lantr Engineering for their unbundled request and technical talent. I am standing by my prior position in the current market.
A PDF version of this rationale is also made available.
I am formally registering an ABSTAIN vote on the standalone Scalus treasury request.
I commend Lantr Engineering for their comprehensive, unbundled proposal and their strategic focus on opening our blockchain to the massive JVM developer ecosystem. Their technical track record and commitment to the application layer are undeniable. I previously voted abstain on high-cost infrastructure proposals, and I am standing by this position in the current market.
Whilst I recognise the immense technical advantages of a unified application platform and the value it brings to our ecosystem, an 8.5 million ADA request for a 12-month delivery window is an extraordinary draw on the treasury. I cannot allocate funds for this as a priority at this moment in time given the market and my current planned focus on strict fiscal prudence.
- YesChanged69.4M ₳History
Earlier votes
Abstain2mo agoSuperseded
- Abstain62.7M ₳No rationale
- No53.8M ₳Rationale
I'm voting No on the Scalus: Cardano's Application Platform for Building, Launching, and Scaling proposal.
I recognize Lantr Engineering's strong delivery track (Catalyst F11/F13 at 100%, 2025 Treasury Budget on track), the existing Scalus adoption by Hydrozoa, Bifrost, Mesh, Lucid Evolution, and CCL, and the solid governance hygiene (SundaeSwap escrow, credible oversight board, candid 2025 retrospective). That said, I'm voting No on the scope and priorities for two reasons.
- The demand the proposal is trying to address isn't demonstrated as a Cardano-specific problem.
The core value proposition here is "bringing 26M developers from the JVM ecosystem to Cardano." But Cardano already has JVM-side tooling in operation, such as Bloxbean's Cardano Client Library (CCL) and Yaci DevKit, and there's no evidence presented that JVM developers aren't coming to Cardano because of the absence of an integrated application platform.
- Both client diversity and dev tooling are already being addressed by multiple projects in progress.
On the L1 node side, alongside the Haskell node, Amaru (Rust) and Dingo (Go) are already underway with treasury funding, and the Gerolamo (TypeScript browser) proposal is on the table in this same cycle. The differentiated value of adding a JVM-native L1 node on top of that isn't clear. On the application platform side, Mesh SDK, Lucid Evolution, CCL and others have already become the standard stack for the builder ecosystem, so the case for a separate integrated platform being "essential" is weak.
- Abstain50.5M ₳Rationale
Given the technical nature of this proposal, I don’t feel I have enough expertise to make a fully informed decision. For that reason, I believe abstaining is the most responsible choice.
- Abstain50M ₳Rationale
I haven't had the chance to review this proposal yet, and I'm going to do that a bit later. For now, I'm voting Abstain in case I don't manage to get to it before the deadline, just to allow the proposal to move forward.
- No49.5M ₳No rationale
- No47.6M ₳No rationale
- No40.1M ₳Rationale
As much as I'd love to see this funded because I believe its a great project, I simply can not support spending more money on technical infrastructure at this point.
- Yes38.1M ₳Rationale
I believe Cardano needs more mature and integrated development platforms if we want to attract larger teams and enterprise-grade applications in the future.
Scalus is also building on years of existing work rather than starting from scratch. Retaining experienced teams and continuing to develop ecosystem knowledge is important for Cardano's long-term growth, so I will vote Yes.
- No37.8M ₳No rationale
- No36.9M ₳No rationale
- No34.6M ₳Rationale
優れたツールであっても、この財政難の時期に一気に850万ADAも拠出するのはリスクが高すぎる。もっとフェーズを細かく分けて、少しずつ予算を請求すべき
- No31.4M ₳Rationale
I am voting NO.
While I recognise the value of Scalus as an application platform for Cardano, I believe that at this stage treasury funding should prioritise concrete dApps and real-world use cases over additional developer platforms and infrastructure.
Cardano already has multiple strong tools and frameworks, and I consider it more important now to fund teams that ship production applications on top of this existing foundation, directly contributing to adoption, transactions, and TVL. - Yes27.9M ₳Rationale
I think Scalus is taking the right approach by building a vertically integrated stack that combines smart contract development, application tooling, chain access, and L2 scaling. Especially native Hydrozoa/Gummiworm which are improvements to Hydra. It also offers a different value proposition by focusing on use cases that should not have to depend on third-party chain-access providers. Scalus also opens Cardano to the much larger JVM ecosystem through Java, Kotlin, and Scala. In addition to enterprise and financial applications, I think this could eventually create a stronger foundation for Android-native Cardano tooling and applications across a massive global device ecosystem. The ask is pretty high, but Scalus is an established open-source platform with existing integrations and applications already building on it. For these reasons, I am willing to justify the price by voting YES.
- No27.9M ₳No rationale
- No26.3M ₳No rationale
- No26.1M ₳No rationale
- Yes23.5M ₳Rationale
Scalus is not "another node" like Dingo or Amaru. It's a complete development platform in the most common enterprise development language. This is a huge market and a fully integrated stack on top of the Java Virtual Machine targets them well.
- No21.5M ₳No rationale
- Abstain21.5M ₳No rationale
- Abstain21.4M ₳No rationale
- Yes20.4M ₳No rationale
- No20.3M ₳No rationale
- No19.9M ₳Rationale
Looks interesting, but we already are way too heavy on infrastructure spent in the current proposal lifecycle. While beneficial, this doesn't feel essential to me. Thus for now I vote "NO" on this. This can be revisited in another cycle.
- No17.3M ₳Rationale
Scalus: Cardano’s Application Platform for Building, Launching, and Scaling
- No16.7M ₳Rationale
Scalus is technically serious and the proposal is relatively transparent, but the market-demand signal is not strong enough for an ₳8.5M ask. Aiken is currently the dominant go-to smart contract platform in Cardano, while Plutus is now preferred by a smaller group; Scalus appears to face a similar adoption challenge. The proposal’s own targets are still modest: 5 external teams and 2 Scalus-owned chain-access deployments. We would prefer a smaller adoption-validation proposal first.
- No16.4M ₳No rationale
- Abstain14.2M ₳No rationale
- No14.1M ₳No rationale
- Abstain13.3M ₳Rationale
RCADA votes ABSTAIN on Scalus: Cardano’s Application Platform for Building, Launching, and Scaling.
RCADA recognises Scalus as a credible technical effort and appreciates the track record of Lantr Engineering. Scalus is not a greenfield idea; it has several years of delivery history, existing ecosystem integrations, and prior Cardano community funding where completed milestones were delivered and publicly reported.
We also agree with the core problem the proposal identifies. Cardano needs more serious applications reaching production. Builders should not have to repeatedly assemble smart contract tooling, testing, off-chain logic, chain access, runtime infrastructure, formal verification, and scaling integrations from scratch. Improving the application-development experience is important for Cardano’s long-term growth in users, transactions, TVL, and real utility.
The Scalus vision is therefore valuable. A JVM-native platform that helps Scala, Java, and Kotlin teams build and operate Cardano applications could broaden the ecosystem’s developer base, especially among enterprise and financial software teams. RCADA also sees value in self-sovereign application operations, better local development environments, formal-verification integration, and L2 scaling support.
However, RCADA cannot fully endorse the proposal as presented.
Our concern is not primarily the team’s competence or the usefulness of Scalus. Our concern is the scale and framing of the Treasury request. The proposal asks for ₳8,503,000 to expand one language-oriented platform into a broad full-stack application environment. While this may produce public-good benefits, it remains closely tied to one vendor, one primary technical stack, and one product direction.
In a constrained Treasury environment, large developer-platform requests need an especially clear public-good case. RCADA would have preferred a smaller, more modular proposal focused first on the most reusable ecosystem components: shared conformance work, open formal-verification integrations, public runtime components, documentation, JS/TS interoperability, and integrations that clearly benefit multiple Cardano tooling ecosystems beyond Scalus-native users.
We also believe the proposal would be stronger with clearer non-duplication against other funded or proposed work in Plutus, high assurance, developer experience, L2 scaling, node diversity, and open-source maintenance. Scalus may complement these efforts, but the proposal should make those boundaries and shared benefits easier for the community to assess.
RCADA also remains cautious about execution risk. The roadmap is ambitious for 12 months, especially around the application-focused L1 node, production-grade runtime capabilities, L2 integrations, and formal verification dependencies. These are valuable goals, but they are technically demanding and partly dependent on progress from other ecosystem projects.
Finally, RCADA notes the future maintenance question. Expanding Scalus into a wider application platform may create larger ongoing maintenance needs. Future funding requests should show a clearer path toward diversified support from users, commercial services, ecosystem partners, or other non-Treasury sources.
For these reasons, RCADA votes ABSTAIN. We respect Lantr’s contribution and believe Scalus can be valuable for Cardano, but the current proposal is too broad, too large, and too platform-specific for RCADA to fully endorse at this stage.
A revised proposal with smaller scope, stronger public-good framing, clearer ecosystem-wide integrations, tighter non-duplication, stronger adoption evidence, and a more explicit sustainability path would be easier for RCADA to support.
RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/."
- No12.1M ₳Rationale
We recognize the technical competence of the Scalus team and acknowledges the importance of improving Cardano's developer experience. We agree that application development on Cardano can be complex and that reducing integration friction remains a worthwhile ecosystem objective.
However, our decision is based on four key governance questions.
- What specifically remains unsolved, and how has this been demonstrated?
The proposal argues that developers face excessive complexity due to fragmented tooling and infrastructure. While this concern is broadly valid, we do not believe the proposal sufficiently demonstrates which specific ecosystem bottlenecks remain unresolved after years of prior investments in developer tooling, SDKs, smart contract languages, transaction builders, infrastructure services, and application frameworks. The proposal identifies a problem category but does not provide enough evidence that existing solutions are incapable of addressing the stated challenges.
- Why is Scalus the appropriate ecosystem-wide integrator?
The proposal positions Scalus as a unifying application platform for Cardano. However, Cardano remains a diverse ecosystem with multiple actively maintained development stacks, languages, and frameworks. We are not convinced that sufficient justification has been provided for why ecosystem resources should be concentrated around a Scala/JVM-centric platform rather than continuing to support interoperability among existing tooling ecosystems. The proposal does not clearly establish why Scalus should become the preferred integration layer for the broader ecosystem.
- What evidence justifies the scale of the funding increase?
Scalus has previously received ecosystem funding and has delivered meaningful work. Nevertheless, this proposal represents a substantial increase in requested funding relative to prior allocations. We do not find sufficient evidence of ecosystem adoption, production usage, developer growth, or demonstrated demand to justify an investment of this magnitude at this stage. Before committing treasury resources at this scale, we would expect stronger evidence that the platform has achieved adoption levels commensurate with the requested expansion.
- How will success be objectively measured?
A significant portion of the proposal's value proposition relies on future ecosystem outcomes such as improved developer experience, increased application deployment, greater adoption, and ecosystem growth. While these are desirable objectives, the proposal does not provide sufficiently concrete, measurable, and independently verifiable success criteria that would allow DReps to assess whether the treasury investment achieved its intended impact. We believe clearer adoption metrics, utilization targets, and ecosystem outcome measurements are necessary for accountability.
- No10.9M ₳No rationale
- No10.8M ₳No rationale
- No10.4M ₳Rationale
I voted no because, from a business perspective, this proposal tries to do too much at once for Treasury to fund comfortably as one package.
This is not one focused product ask. It is a bundled platform strategy:
- smart contract development
- application runtime
- application focused L1 node
- L2 integration
That may be a strong internal product vision for Lantr, but Treasury should be more careful about funding a broad platform bet before there is stronger proof that the market will converge around it.
That is my first issue. Platform demand is assumed more than proven. The proposal shows activity, integrations, and prior delivery. That is good. But that is not the same as proving that Scalus has already become, or is clearly becoming, the default application platform for Cardano builders.
My second issue is the node strategy. A meaningful part of the proposal is about building and hardening an application-focused L1 node. But Cardano already has multiple node, chain-access, and data-access efforts across the ecosystem. Treasury should ask whether this is truly filling a critical gap or whether it is helping one vendor vertically integrate its own stack at ecosystem expense.
My third issue is dependency risk. Some of the most important roadmap items depend on third-party projects like Hydrozoa/Gummiworm and Blaster, which are outside Lantr’s direct control and not funded through this proposal. That makes delivery risk materially higher.
My fourth issue is the proposal’s own framing. "Scalus is a product, not a project." That may make sense from a startup perspective. Public ecosystem capital should come with tighter delivery clarity than a flexible product roadmap built around reprioritization and internal sequencing shifts.
And finally, the proposal already starts normalising future maintenance dependence. Once Treasury funds a platform like this, it is difficult to stop, because maintenance, hard fork support, patches, compatibility, and ecosystem support all become recurring asks.
This proposal may be technically interesting, but it is too broad, too vendor-centric, too speculative in its ecosystem impact and too open ended in its future support expectations for me to support at this size.
That is why I voted NO
- NoRevoted9.2M ₳History
Earlier votes
No1mo agoSuperseded
No2mo agoSuperseded
No2mo agoSuperseded