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.
- Abstain575M ₳Rationale
"Yoroi DRep votes ABSTAIN on Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime. Yoroi recognises the importance of responsible governance during periods of ecosystem uncertainty.
- Ecosystem Situation: The trust our delegators place in Yoroi requires that we act only when we can do so with full confidence. In light of the current situation, Yoroi is choosing to withhold its vote on this proposal and will reassess our position once conditions allow for a considered decision."
- Abstain384.3M ₳Rationale
Please check the following link for the reasons for the vote.（投票理由は次のページを参照してください。)
- Abstain331.6M ₳No rationale
- Abstain299.7M ₳Rationale
"EMURGO as a DRep votes ABSTAIN on Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime, with rationale outlined below.
Given the ongoing situation in the ecosystem, responsible governance requires us to act with full clarity and confidence. Until the current situation reaches resolution, EMURGO prefers to withhold judgment rather than vote without the certainty our mandate demands. We will revisit this proposal once the situation is resolved."
- Yes258.5M ₳No rationale
- Yes219.4M ₳Rationale
They listened and the new proposal is much leaner. Easy YES now.
- Abstain175.4M ₳No rationale
- Yes171.3M ₳No rationale
- Yes123.7M ₳Rationale
The Cardano Foundation votes YES. Scalus components are already embedded in tooling the ecosystem depends on, and this reduced, unbundled resubmission is proportionate to keeping that infrastructure maintained through the Dijkstra hard fork.
A PDF version of this rationale is also made available.
We recognise Lantr Engineering as a capable team with three years of continuous delivery behind Scalus. Having thoroughly assessed this governance action, our decision is driven by the following factors:
- A Proportionate Resubmission: The ask is 2,464,844 ada over nine months at a $0.16/ADA reference rate with no contingency, reduced from 8,503,000 ada over twelve months and from 8.25 to 2.25 FTE. The standalone JVM L1 node, full L2 integration, and the broad formal verification track have been removed from scope. This responds directly to the concerns raised on the previous submission rather than restating the same case at a lower price.
- Maintenance of a Dependency: Scalus's script evaluation, cost calculation, and in-memory node emulator are embedded in MeshJS, Lucid Evolution, Evolution SDK, Cardano Client Lib, and Yaci Dev Kit. Many teams therefore depend on these components without ever choosing Scalus. Our review found Scalus to be among the smart contract ecosystems on Cardano showing measurable adoption. Dijkstra introduces Plutus V4, new builtins, and updated cost models; if these components fall behind, the consequences reach teams who never selected this platform.
- Delivery Record: Lantr's 2025 treasury withdrawal of 657,692 ada is complete, with the final milestone delivered and publicly reported, and a retrospective published alongside this proposal. We view delivery against a prior withdrawal as material evidence of execution capability.
To ensure transparency, we note that Matthias Benkort of the Cardano Foundation is named as a member of the proposal's independent oversight board.
The Cardano Foundation votes YES. We commend Lantr Engineering for returning with a leaner, unbundled proposal and for the transparency of its 2025 retrospective, and we look forward to Scalus and the tooling built on it remaining current through the Dijkstra transition.
---> **_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. - Yes90.6M ₳Rationale
As a DRep, I decided to vote YES on the proposal: Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime
My rationale:
I voted NO on the previous Scalus proposal because the ₳8.5M budget and broad scope were not sufficiently supported by demonstrated adoption. It attempted to fund the complete long-term vision at once, including a production-grade L1 node, L2 integration, formal verification, an advanced devnet, and a comprehensive application runtime.
The team responded constructively to this feedback. The new ask has been reduced by 71% to ₳2.46M. Staffing has been reduced from 8.25 to 2.25 FTE, and the 10% contingency has been removed.
The L1 node, full Gummiworm integration, broad formal-verification work, and advanced devnet expansion are no longer included. This proposal is therefore materially different from the one I previously rejected.
The remaining scope is more proportionate.
Maintenance and Dijkstra readiness are legitimate public-infrastructure expenses. Scalus components are reused by Cardano tools such as MeshJS, Lucid Evolution, Evolution SDK, YaciDevKit, and Cardano Client Lib. Developers can therefore benefit from Scalus without directly choosing Scala or integrating the complete platform.
Components embedded in widely used SDKs can benefit a much larger part of the ecosystem. Keeping them compatible with future protocol versions also protects Cardano’s previous investment.
The Dijkstra hard fork is expected to affect Plutus, ledger rules, transaction construction, cost models, and other parts of the development stack. Scalus and the tools depending on it will therefore need to be updated. Funding compatibility work before the hard fork is more responsible than waiting for problems to appear afterwards.
It also helps Cardano maintain multiple independent development environments rather than relying on a single toolchain.
The team has demonstrated its ability to deliver. Its three funded Catalyst projects, totaling ₳428k, and the previous ₳657k Treasury allocation were completed. All reported milestones were delivered.
The annualized rate of $210k per FTE is at the upper end of the market, but it is defensible given the specialized senior expertise required in compiler engineering, Plutus, and protocol-level development. Combined with the substantially reduced team size and overall budget, the current request appears proportionate to the proposed scope.
This is the type of constructive resubmission that governance should encourage. The team listened to DRep feedback, removed the most contested components, substantially reduced the budget, and focused on maintaining proven open-source infrastructure while testing the next step at a controlled scale.
For these reasons, I vote YES.
If you'd like to support my work, consider delegating to the MANDA pool and backing me as a DRep. Your support is the only way I can get time for governance.
MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqpBuy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0 - Yes88.4M ₳Rationale
SIPO DRep votes YES on the treasury withdrawal "Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime" (2,464,844 ada).
This is the resubmission of a proposal SIPO supported at 8,503,000 ada and the wider DRep body rejected as too large relative to demonstrated demand and treasury capacity. The proposers answered that directly: the request is down about 71%, the term is nine months rather than twelve, staffing is 2.25 FTE rather than 8.25, contingency is 0% rather than 10%, and the production standalone L1 node, full L2 integration, advanced devnets, and broad formal verification have been deferred to a later phase. The remaining scope is three goals: maintain the existing Scalus infrastructure and make it ready for the Dijkstra hard fork; deepen interoperability for JVM and JavaScript/TypeScript developers; and deliver a first, limited application runtime. The on-chain recipient is a script credential at stake17xzhu4tdpl4gdsupfmn3yjlngt2f3mjes3v6wwg9yd767ps8k5qvl.
SIPO supports this. It is the public-good and builder-infrastructure category SIPO backs: essentially all spend is engineering, maintenance, and developer enablement, with no brand-marketing component, and the funds return to a builder inside the ecosystem rather than leaving it. Scalus is a live dependency, and maintaining what already exists across a hard fork is not optional work. Bringing Java, Kotlin, and TypeScript developers onto Cardano through the toolchains they already use is among the cheaper ways to widen the builder base. The oversight board carries independent technical credibility from IOG, the Cardano Foundation, and Blink Labs. Treasury funds sit under an escrow that enforces auto-abstain DRep delegation and no stake pool delegation, so they cannot convert into governance power or staking rewards. Development is verifiably active.
SIPO also supports it because the iteration deserves to be answered. The proposers asked DReps whether the scale was wrong, were told that it was, and returned smaller rather than repackaging the same request. If governance is to produce better proposals rather than merely rejected ones, that behaviour needs to be met with support.
Two notes on the numbers. The $0.16 reference price now sits essentially at market - ada trades at about $0.1646 - so the ada quantity is not inflated, though it no longer carries the margin in the Treasury's favour that it did when the resubmission was filed. With contingency at 0%, further ada weakness is absorbed by the proposers rather than the Treasury; SIPO expects scope to be held rather than a top-up request, and would treat a later top-up as a material change of terms. SIPO also expects Dijkstra readiness to land ahead of the hard fork rather than after it, and notes that Lantr Engineering is also delivering Bifrost Phase 1 in this same batch, so reporting should evidence that the two are separately staffed. This vote is SIPO DRep's recorded position.
SIPO DRep は、トレジャリー引き出し提案「Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime」（2,464,844 ADA）に賛成（YES）を投じます。
本件は、SIPO が 8,503,000 ADA の時点で支持し、DRep 全体としては実証された需要とトレジャリー容量に対して規模が大きすぎるとして否決された提案の、再提出版です。提案者はその論点に正面から応答しました。要求額は約 71% 減、期間は 12 ヶ月から 9 ヶ月、人員は 8.25 FTE から 2.25 FTE、コンティンジェンシーは 10% から 0%、そして本番用スタンドアロン L1 ノード、完全な L2 統合、高度な devnet、広範な形式検証は後続フェーズへ繰り延べられています。残る範囲は 3 つの目標です。既存の Scalus インフラを保守し Dijkstra ハードフォークに対応させること、JVM および JavaScript/TypeScript 開発者に向けた相互運用性を深化させること、そして限定的なアプリケーションランタイムの初版を提供することです。オンチェーン受領先は script credential（stake17xzhu4tdpl4gdsupfmn3yjlngt2f3mjes3v6wwg9yd767ps8k5qvl）です。
SIPO はこれを支持します。SIPO が支持する公共財・ビルダーインフラの類型に該当し、支出のほぼ全額がエンジニアリング、保守、開発者支援に向かい、ブランドマーケティング的要素を含みません。資金はエコシステムの外へ流出するのではなく、内部のビルダーへ還流します。Scalus は現に使われている依存物であり、既存のものをハードフォークをまたいで維持することは任意の作業ではありません。Java・Kotlin・TypeScript の開発者を、彼らが既に使っているツールチェーン経由で Cardano に迎え入れることは、ビルダー層を広げる手段として相対的に安価な部類に入ります。監視ボードは IOG、Cardano Foundation、Blink Labs による独立した技術的信認を備えます。トレジャリー資金は、auto-abstain の DRep 委任とステークプール非委任を強制するエスクロー下に置かれ、投票力にもステーキング報酬にも転化しません。開発活動は検証可能な形で継続しています。
SIPO が支持するもう一つの理由は、この反復に応えるべきだからです。提案者は規模が過大かどうかを DRep に自ら問い、過大であると告げられ、同じ要求を包み直すのではなく縮小して戻ってきました。ガバナンスが単に否決された提案ではなく、より良い提案を生み出す仕組みであるべきなら、この振る舞いは支持で応えられる必要があります。
数値について 2 点付記します。参照価格 $0.16 は現在ほぼ市場価格と一致しています（ADA は約 $0.1646）。したがって ADA 数量の水増しはありませんが、再提出時に有していた国庫側に有利なマージンはもはや存在しません。コンティンジェンシーが 0% であるため、ADA のさらなる下落は国庫ではなく提案者が吸収します。SIPO は範囲が維持され追加要求が行われないことを期待し、後日の増額要求は条件の実質的変更として扱います。また SIPO は、Dijkstra 対応がハードフォーク後ではなくそれに先行して完了することを期待します。加えて Lantr Engineering は同じ batch で Bifrost Phase 1 も担当しているため、両者が別個の人員体制で遂行されていることが報告で示されるべきです。本投票は SIPO DRep の記録上の立場表明です。
- No85M ₳Rationale
I am unconvinced this proposal represents spending that would be the best use of funds at this time.
- Abstain77.8M ₳No rationale
- Yes76.7M ₳No rationale
- No75.9M ₳Rationale
I recognize the value of Scalus as an open-source project that improves the Cardano developer experience, and I appreciate that this proposal has significantly reduced its scope and budget compared to the previous submission. I also acknowledge its existing integrations and contributions to the ecosystem.
However, under the current Net Change Limit (NCL), I believe Treasury funding must be prioritized toward proposals with the highest strategic impact.
At this stage of Cardano's evolution, I believe our highest priority is not expanding the number of development tools, but attracting new developers, businesses, users, liquidity, and real economic activity into the ecosystem.
While this proposal may improve the developer experience, I am not convinced that it will directly translate into meaningful ecosystem adoption or that the demand for this platform is sufficiently demonstrated to justify prioritizing it over other proposals competing for limited Treasury resources.
The purpose of the NCL is not simply to distinguish between good and bad proposals, but to force difficult prioritization decisions.
Given the current funding constraints, I believe Treasury resources should first support proposals that strengthen the core protocol or have a clearer and more immediate path to bringing external users, capital, businesses, and developers into Cardano.
For these reasons, I vote No.
ScalusがCardanoの開発体験向上を目指すオープンソースプロジェクトであり、前回提案から大幅にスコープと予算を見直した点は評価しています。また、既存の利用実績やコミュニティへの貢献についても理解しています。
しかし、限られたNet Change Limit（NCL）の中でTreasuryを配分する以上、私はより高い優先順位を持つ提案へ資金を振り向けるべきだと考えます。
現時点のCardanoに最も必要なのは、開発ツールを増やすことではなく、新たな開発者、企業、ユーザー、流動性、そして実需をCardanoへ呼び込むことです。
本提案は開発者体験の改善という価値はあるものの、それがCardano全体の採用拡大へどの程度直接結び付くのか、また限られたTreasury資金を優先的に配分すべき水準の需要が存在するのかについて、十分な確信を持つことができませんでした。
NCLは「良い提案」かどうかではなく、「今、最も優先すべき提案は何か」を判断するための制約でもあります。
私は、限られたTreasury資金は、Cardanoプロトコルそのものを強化する提案や、外部から新たなユーザー・資本・企業・開発者を呼び込み、Cardano全体の成長を加速させることが期待できる提案へ優先的に配分すべきだと考えます。
Scalusの技術的価値は認めますが、現時点ではNCLの優先順位という観点から、本提案には反対します。
- Abstain74.6M ₳No rationale
- Yes73.6M ₳Rationale
I am voting YES to fund Scalus because this is a textbook example of how builders should engage with governance.
A PDF version of this rationale is also made available.
I am voting YES to fund Scalus because this is a textbook example of how builders should engage with governance.
When DReps pushed back on their previous 8.5 million ADA ask, the team listened, rescoped the project, and reduced their budget by 71%.
Maintaining essential JVM and JS/TS developer tooling ahead of the Dijkstra hard fork is exactly the type of foundational infrastructure the treasury should support.
This is a highly strategic, fiscally responsible spend that directly empowers builders across the Cardano ecosystem. - Yes53.8M ₳Rationale
I'm voting Yes on the Scalus 2026 proposal.
Scalus's script evaluation and node emulator components are already embedded in MeshJS, Lucid Evolution, Evolution SDK, and Cardano Client Lib. If that layer isn't maintained through the Dijkstra hard fork, which introduces Plutus V4 and nested transactions, the tools that rely on it and the teams building on those tools are all affected.
This proposal cuts the ask by 71% and removes the L1 node, L2 integration, and formal verification from scope, focusing instead on maintenance, hard fork readiness, and interoperability. It's designed around 2.25 FTE with no contingency, and comes with SundaeSwap escrow, an independent oversight board, and third-party assurance.
That said, the application runtime is a new expansion, different in nature from maintenance. I think that part needs to prove its necessity through actual adoption results in any future request.
- Abstain51M ₳Rationale
Because of fundamental concerns with the current treasury process, I vote Abstain on all Treasury Withdrawal proposals until the treasury budgeting process undergoes fundamental reform.
More information: https://x.com/ada_stat/status/2068315882539921703
- Abstain50.2M ₳Rationale
As this is a technical matter beyond my expertise, I am not comfortable voting either for or against the proposal. I will abstain.
- No49.5M ₳No rationale
- Yes47.5M ₳No rationale
- Abstain39.9M ₳No rationale
- No37.4M ₳No rationale
- No37.3M ₳No rationale
- Yes34.5M ₳Rationale
直面しているハードフォークへの備えと既存ツールの維持だけにスコープを7割以上削減して再提出されている点を評価いたします。
- Abstain33.5M ₳Rationale
Vote: Abstain. This action requests 2,464,844 ADA over nine months for Scalus maintenance, Dijkstra readiness, interoperability, and a scoped application runtime.
A PDF version of this rationale is also made available.
Scalus is established open-source Cardano infrastructure with a credible delivery record. Its components are used directly and indirectly by several Cardano projects and development tools.
The revised proposal responds seriously to earlier DRep concerns. The requested amount has been reduced by approximately 71 percent, the duration has been shortened, the contingency has been removed, and several broader workstreams are no longer included.
Maintenance and Dijkstra hard-fork readiness are reasonable uses of treasury funding. Existing projects should not lose compatibility because shared infrastructure falls behind the protocol. The uncertainty is the decision to combine that maintenance with interoperability expansion and a new application-runtime step.
The proposal does not yet show enough external demand for the runtime work to make it a clear treasury priority. A No vote would discount the value already delivered and the importance of compatibility work. A Yes vote would endorse an expansion whose adoption case remains unsettled.
I will not oppose the continuation of Scalus, but I cannot give the complete scope an affirmative mandate.
I vote Abstain. - Yes31.4M ₳Rationale
This proposal provides essential maintenance and Dijkstra hard‑fork readiness for Scalus, a public‑good infrastructure already embedded in major Cardano developer tools such as MeshJS, Lucid, Evolution SDK, Yaci, and Cardano Client Lib. The scope and budget have been significantly reduced in direct response to prior DRep concerns, focusing strictly on maintenance, interoperability, and hard‑fork alignment. Given the ecosystem-wide dependency on Scalus and the proven delivery record of the team, continued support is necessary to preserve developer experience and platform safety. The reduced budget is appropriate for the narrowed scope. I vote Yes.
- Yes30.6M ₳No rationale
- Yes28M ₳No rationale
- Yes27.9M ₳Rationale
Scalus maintains a suite of heavily-used Cardano tools and pushes the frontier of innovation with things like Gummiworm. The team is well respected and the ask is reasonable. This is an easy YES vote for me.
- Yes27.2M ₳No rationale
- Yes26.1M ₳No rationale
- Yes23.6M ₳Rationale
Scalus is the basis for several infrastructure projects.
- Abstain21.5M ₳No rationale
- Abstain21.4M ₳No rationale
- Abstain20.9M ₳No rationale
- No20.4M ₳No rationale
- No20.3M ₳No rationale
- Yes20M ₳Rationale
I say yes to open source core infrastructure basic funding.
- Yes17.4M ₳Rationale
Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime
- Yes16.9M ₳Rationale
We support this proposal because Scalus is open-source, reusable developer infrastructure with clear public-good value for Cardano.
The revised scope is much more focused than the earlier version, concentrating on maintenance, Dijkstra readiness, interoperability, and a bounded runtime step. We appreciate that the team responded to DRep and community feedback by narrowing the proposal and reducing the ask.
Scalus adds useful diversity to Cardano’s developer tooling stack, especially for JVM/Scala developers, and supports important ecosystem projects.
For future funding, we would like to see clearer adoption and usage reporting. However, the open-source nature, narrowed scope, prior delivery, and Dijkstra-readiness value justify support.
- Yes16.3M ₳Rationale
Vote: YES
This is a Treasury Withdrawal, "Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime" (gov_action1xg6...qa63yc), submitted June 29, 2026 with voting closing August 2, 2026. Lantr Engineering requests ₳2,464,844 (approximately $394,375 at the $0.16/ADA reference rate) over nine months, July 2026 through March 2027, to maintain the Scalus toolchain — a JVM-native development stack for writing, evaluating, testing, and deploying Cardano smart contracts — keep it compatible with the Dijkstra hard fork including Plutus V4 and new builtins, improve Java/Kotlin and JavaScript/TypeScript interoperability, and deliver a scoped first application runtime. No ADA burning is involved.
This is a resubmission that took DRep feedback seriously rather than repackaging it. The ask fell from ₳8,503,000 over twelve months to ₳2,464,844 over nine — a 71% reduction — with the team cut from 8.25 to 2.25 FTE, the standalone L1 node and L2 integration removed from scope, the formal verification track dropped, the contingency buffer eliminated entirely, and pricing set at a conservative $0.16/ADA. Few proposals in this cycle have responded to rejection by actually shrinking. The accountability apparatus matches the strongest structures Dracula DAO has seen: funds held in audited SundaeSwap escrow contracts, disbursements requiring approval from a three-member independent oversight board drawn from Blink Labs, the Cardano Foundation, and IOG, quarterly technical review by No.Witness Labs, public quarterly reports and transaction journals, and automatic return of unused funds to the treasury. Lantr's disclosed track record supports the request: ₳328,000 across two Catalyst F11 projects and ₳657,692 from the 2025 Treasury, both fully received with all milestones delivered. The tooling has real users — Scalus is already a dependency of Gummiworm L2, the Bifrost bridge, SugarRush DEX, Vela stablecoin, and DID/DIDComm work — so the maintenance milestone protects infrastructure the ecosystem already depends on rather than speculating on adoption that has not happened.
The structural objection still applies. This is priced as 2.25 FTE of a named team's time for nine months, not as a grant paid against completed features, and there was no competitive bidding — Scalus is Lantr's own product, and the treasury is funding its upkeep. Dracula DAO names that gap plainly. The application runtime component is also the weakest part of the request: unlike maintenance and hard-fork compatibility, it is new scope whose demand is asserted rather than demonstrated, and it is the piece most likely to consume budget without producing something the ecosystem misses if it never ships. DRep sentiment is currently against, at roughly ₳1.97B no to ₳1.16B yes.
Dracula DAO votes YES. Developer tooling that keeps working through a hard fork is unglamorous, foundational, long-term infrastructure — exactly the category this DREP exists to favor over tactical spending. If Scalus breaks at Dijkstra, every project built on it breaks with it, and the cost of that failure lands on builders who made no such request of the treasury. At ₳2.46M this is one of the smallest asks of the cycle, roughly a fifth of the Bifrost Phase 1 request and under half of the Hydra v2 hardening grant, for work with immediate and verifiable consequences. Money moves only when an independent board with no stake in the outcome signs off against a defined quarterly milestone, and undelivered funds return automatically. That is not the competitive completion-grant model Dracula DAO would prefer, but it is honest gating on real deliverables from a team that has delivered before.
Dracula DAO will judge any 2027 continuation on whether the runtime component found genuine users and whether the Dijkstra compatibility work shipped on schedule. Maintenance funding earns renewal by keeping things working; new scope earns it by being adopted.
- No14.1M ₳No rationale
- Yes13.3M ₳Rationale
RCADA votes YES on Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime.
RCADA supports this proposal because it is a focused and materially improved resubmission of the earlier Scalus proposal. RCADA previously abstained on Scalus: Cardano’s Application Platform for Building, Launching, and Scaling because the earlier request was too broad and too large, even though RCADA recognised the technical quality of Scalus, the credibility of Lantr Engineering, and the potential value of JVM-native Cardano developer infrastructure.
This revised proposal directly addresses those concerns. The ask has been reduced from 8,503,000 ADA to 2,464,844 ADA, the duration has been reduced from 12 months to 9 months, the FTE commitment has been reduced from 8.25 to 2.25, and the most contested parts of the previous proposal have been removed from scope. The revised proposal no longer funds a standalone L1 node, full L2 integration, broad formal verification, or a large platform-scale expansion.
RCADA views this response to DRep feedback positively. Treasury governance should reward teams that listen, narrow scope, reduce risk, and resubmit stronger proposals. This version is more clearly focused on protecting existing public infrastructure, preparing for the Dijkstra hard fork, improving interoperability, and taking a bounded first step toward an application runtime.
RCADA supports the maintenance and Dijkstra-readiness components in particular. Scalus is already used directly by complex Cardano projects and indirectly through tooling used by other builders. Keeping that infrastructure maintained, compatible, and ready for protocol changes helps protect prior public investment and reduces disruption for teams that rely on Scalus components.
The interoperability work is also valuable. Cardano benefits from multiple developer pathways, and Scalus provides a JVM-native route for teams working in Scala, Java, Kotlin, and related enterprise backend environments. Improving reuse across JVM and JavaScript/TypeScript tooling can broaden Scalus’s practical value beyond teams that adopt the full Scalus stack directly.
RCADA also sees merit in the scoped application runtime, provided it remains bounded. Helping teams move from protocol development toward operating applications is a real ecosystem need. However, this runtime work should not become a backdoor expansion into the broader platform scope that DReps previously found too ambitious. RCADA expects this part of the work to be validated through reference applications, integration tests, and feedback from real users.
The proposal’s governance and accountability structure is strong. It uses audited SundaeSwap treasury contracts, an independent oversight board, third-party technical assurance through No.Witness Labs, independent financial audit, public quarterly reports, a public transaction journal, auto-abstain delegation, no SPO delegation, and automatic return of remaining funds after expiry.
RCADA also notes Lantr’s prior delivery record. The proposal discloses previous Catalyst and Treasury funding and states that all prior milestones were delivered and publicly reported. Prior funding should never create automatic entitlement to new Treasury funding, but delivery history is relevant when assessing execution credibility.
RCADA’s support comes with expectations. Scalus is specialised developer infrastructure, so ecosystem value should be demonstrated through visible delivery, integrations, downloads, repository activity, documentation, reusable examples, Dijkstra-readiness evidence, and feedback from active builders. Reporting should clearly distinguish developer-preview readiness from final hard-fork readiness if Dijkstra timelines or specifications change.
On balance, RCADA believes this revised proposal meets the standard for support. It is smaller, better scoped, more accountable, and more clearly aligned with open-source developer infrastructure than the previous version. It protects existing ecosystem tooling, responds constructively to prior governance feedback, and funds a proportionate continuation of proven work.
RCADA's full vote assessment can be found here:
https://brolloks.github.io/rcada-drep-votes/ - Abstain12.1M ₳Rationale
We recognize the importance of maintaining developer infrastructure, ensuring readiness for the Dijkstra era, and improving interoperability within the Cardano ecosystem. We appreciate the team's efforts to address concerns raised in previous discussions by significantly reducing the scope and budget of the proposal and by placing greater emphasis on maintenance and ecosystem support. We also acknowledge the value that Scalus and its associated tooling may provide to developers building on Cardano.
However, we have decided to abstain because several critical questions remain insufficiently addressed, making it difficult to confidently assess the proposal's long-term impact and value to the ecosystem. While the proposal provides detailed technical milestones, it does not explicitly demonstrate the extent to which the wider ecosystem depends on Scalus or whether all proposed workstreams, particularly the application runtime represents the most effective use of treasury resources at this time.
First, the proposal does not clearly establish how much of the current Cardano ecosystem would be materially affected if Scalus maintenance and development were to cease. Understanding the degree of dependency across projects, applications, and developer workflows is essential in determining whether the requested funding addresses critical infrastructure needs.
Second, although the proposal highlights several integrations and downstream tools, it does not provide sufficient evidence regarding the number of developers and projects that actively use Scalus directly, nor does it identify external teams that have explicitly committed to adopting the proposed application runtime. Without clear indicators of demand and adoption, it is difficult to evaluate the necessity of this component.
Third, the proposal does not define objective success criteria for the application-runtime workstream beyond activity-based indicators such as downloads and reference implementations. We would like to understand how the practical ecosystem impact of this investment will be measured and independently verified.
Fourth, given that a significant portion of the budget supports experimental runtime functionality, the proposal does not adequately justify why treasury funding should extend beyond maintenance, Dijkstra readiness, and interoperability into areas where ecosystem demand remains uncertain.
Finally, the proposal lacks a clear sustainability strategy beyond the proposed funding period. We believe it is important to understand how ongoing maintenance and future development will be supported without creating a recurring dependence on treasury funding.
- No10.9M ₳No rationale
- Yes10.4M ₳No rationale
- Yes8.6M ₳Rationale
本提案に賛成します。Scalusは、CardanoにおけるJVMおよびJavaScriptエコシステム向けの重要な開発基盤であり、既存ライブラリの保守、Dijkstra対応準備、相互運用性の向上は、開発者エコシステム全体にとって価値があると考えます。また、本提案は前回からスコープと予算を大幅に見直し、保守やDijkstra対応準備を中心とした現実的な内容となっています。ガバナンスや監査体制も明確に示されており、要求されているTreasury資金は妥当であると考えます。そのため、私はこの提案に賛成します。\n\nI vote Yes on this proposal. Scalus is an important development platform for the JVM and JavaScript ecosystems within Cardano, and I believe that maintaining its existing libraries, preparing for Dijkstra, and improving interoperability will provide meaningful value to the broader developer ecosystem. This proposal has also significantly refined its scope and reduced its budget compared to the previous version, resulting in a practical proposal focused on maintenance and Dijkstra readiness. In addition, the governance and oversight framework is clearly defined, and I believe the requested Treasury funding is justified. Therefore, I vote Yes on this proposal.
- Yes7.4M ₳Rationale
Voting YES on the slimmed down Scalus proposal, after a No on the earlier one
I scored this proposal using my own public rulebook and scoring system, which is available here: Cardano DRep Commercial Treasury Rule Book v12 – Three-Layer Capital Allocation, Portfolio Discipline & Execution Reality Edition. The document is still evolving, but it reflects how I assess commercial and hybrid Treasury proposals.
I use AI assistance in this process because I want a scoring method that I can apply as neutrally and consistently as possible across the large number of proposals requesting funding. AI does not make the decision for me. It helps me structure the review, test the proposal against the same criteria, and spot issues I may otherwise miss. When a proposal is borderline, I look at it even more closely.
Vote: Yes
Final score: 87 / 100
Rationale: I would vote Yes on this proposal. Scalus already exists, ships in public, has prior delivery history, and solves a real Cardano developer-infrastructure problem. The earlier ask was too broad, but this resubmission cut the budget sharply, removed the standalone L1 node, removed full L2 integration, removed broad formal verification, and focused on maintenance, Dijkstra readiness, interoperability, and a bounded runtime step. The price is still meaningful, but about $394k for 2.25 FTE over 9 months is not excessive for senior compiler, ledger, JVM, and Cardano infrastructure work. The strongest points are open-source public value, prior delivery, Dijkstra timing, escrow, independent oversight, technical assurance, and a failsafe sweep of unused funds. The weakest points are still adoption depth, repeat Treasury dependency, and the fact that the Treasury receives no financial upside beyond public infrastructure. On balance, this is one of the better-shaped infrastructure continuation asks: it protects previous public investment, reduces hard-fork risk for dependent tooling, and gives Cardano a credible JVM-native path for serious application builders. I would not treat this as a blank cheque for future platform expansion, but this narrower 2026 package earns support.
Category Weight Score Assessment Public value, additionality, timing, and counterfactual harm 12 10 Strong public-good case. Dijkstra readiness and maintenance protect existing developer infrastructure. Adoption impact is indirect, not immediate user growth. Team quality, traction, adaptive execution, and founder-market fit 7 6 Strong technical team and visible shipping record. Traction is real but still niche. 10x improvement, innovation quality, and asymmetric upside 6 5 JVM-native full-stack Cardano development is differentiated. The runtime thesis is promising but not fully proven. Price versus value and ADA volatility discipline 7 6 The revised ask is much more proportionate. The $0.16 ADA reference rate is conservative. No contingency helps, but there is still volatility and repeat-funding risk. Applicant integrity, conflicts, prior delivery, and outcomes record 8 7 Prior funding is disclosed. Public records show completed Catalyst work and public milestone reporting. Public asset, open-source, verifiability, data rights, and continuity 11 10 Strong open-source/public-asset profile. Apache-licensed public repositories, docs, releases, and reusable tooling score well. Treasury upside, instrument fit, and risk sharing 12 8 A grant is acceptable for public-good infrastructure. The Treasury gets public code and ecosystem reuse, but no repayment, revenue share, warrants, or co-funding. Milestones, independent verification, anti-gaming, and enforceability 12 11 Strong structure: SundaeSwap escrow, oversight board, technical assurer, public reports, and contract-level sweep. Risk management, margin of safety, and obsolescence resilience 9 7 Scope is narrower and risks are named. Dijkstra timing and adoption remain the main uncertainties. Sustainability, exit plan, and operator reality 8 6 Maintenance ownership is clear, but long-term sustainability beyond Treasury support remains only partly solved. Portfolio exposure, opportunity cost, competitive neutrality, and decentralization delta 6 5 The ask is material but not excessive against the current Treasury context. It does increase reliance on Lantr, but open-source licensing and public repos reduce lock-in. Ecosystem coordination quality 2 2 Reuse through Cardano tooling and engagement with JVM/JS ecosystems creates real coordination value. Base score 100 83 Ecosystem coordination premium +0 to +5 +2 Added for credible shared infrastructure and integrations across existing Cardano tooling. DRep conviction adjustment -5 to +5 +2 Added for the disciplined resubmission, prior delivery, and strong execution posture after a materially oversized first ask. Final score 100 87 Passes my large-request threshold. Actual vote Yes Support the narrowed proposal. Do not treat this as automatic support for future larger platform expansion.