Scalus has now received detailed feedback from several DReps, including serious concerns around adoption, proportionality, ecosystem demand, and the scope of the proposed expansion. Those are legitimate questions for a Treasury proposal of this size, and they deserve a direct response.
This article expands on the rationale behind the proposal beyond what could reasonably fit into the on-chain submission. It focuses on the core issues raised in review: what has already been validated, what adoption looks like today, why the scope expands from development into runtime, chain access, and scaling, and how we think about proportionality in the context of the actual delivery capacity being requested.
The goal is not to restate the proposal, but to make the investment thesis clearer.
Where Scalus is already used?
What is already building on Scalus or on Scalus-backed technology today:
- Hydrozoa/Gummiworm: state-channel + custody settlement L2 protocol
- Bifrost: Bitcoin-Cardano bridge
- Sugar Rush: central limit orderbook DEX (using Hydrozoa/Gummiworm L2)
- Vela: decentralised synthetic stablecoin
What is already integrating Scalus capabilities:
- Cardano Client Lib
- MeshJS SDK
- Evolution SDK
Those integrations already use Scalus capabilities such as script evaluation, cost calculation, and the Cardano L1 node emulator in JS/TS.
Our view is that at least the L2 and the bridge are ecosystem-significant projects that depend on Scalus today.
How to read the size of the ask?
The headline ADA ask is large. But let's look at it closer in comparison to the previous funding:
FTE-months
- 2025 Treasury + Catalyst F13: 5.5 FTE × 6 months = 33 FTE-months
- 2026 ask: 7 FTE × 12 months = 84 FTE-months
That is roughly a 2.5-3x increase in delivery capacity.
Budget-wise
The same applies on the budget side:
- 3 Catalysts: ₳428k, approx. $220k
- 2025 Treasury: ₳658k, $427k planned
- 2026 ask (engineering): ₳5.88m, $1.47m
Engineering-to-engineering: ~2.2x. Total proposal (security audits, development enablement, assurance): ~2.9x. With refundable contingency (uniquely provisioned for the delivery risks): ~3.2x.
Scope-wise
In terms of scope, the 2026 proposal (over 12th months) is roughly 2-3x what we've done in 6 months last year.
So we agree that proportionality matters. The point we would make is that the increase is better understood as a larger, but still bounded expansion of delivery capacity over a longer period for new production-grade capabilities, rather than an 8x jump in like-for-like scope.
Why the scope expands beyond the original development platform?
We would frame the 2025 thesis slightly differently.
The point was to validate whether Cardano teams benefit from a more unified development model: smart contracts, transaction building, testing, and application logic in one coherent stack and development experience. Not a Scala-based contract language.
We already see evidence that teams choose Scalus for its capabilities rather than for the language itself. Hydrozoa is one example: the decision was driven by the development model, ledger rules framework, testing environment, and integrated stack, not by prior Scala experience. Another team already has the smart contracts, and using our testing infrastructure to increase coverage.
2 teams told us that native L2 integration out of the box is the bottleneck, not the language. Serious applications cannot rely on 3d-party services in production, and would prefer the integrated/local node service for the security reasons.
All of this are the signals that validate our vision, an integrated development / application platform that has all of this and just works.
In that sense, the runtime, sovereign chain access, and native L2 support are not separate platform bets. They are the next capabilities required to turn a development platform into something teams would use to launch and operate production-grade applications.
What kind of developer demand Scalus is addressing?
Firstly, the Cardano Foundation survey reflects the current ecosystem shape and it's progression, and Aiken's growth shows that targeted investment in tooling can shift developer adoption over time.
Second, Aiken and Scalus are not solving the same problem in the same way. Aiken is a smart contract DSL. Scalus is positioned as an development / application platform, for teams building end-to-end systems, the comparison axis is different.
Why does the JVM still matter for Cardano?
We hear you that "26 million developers" reads as theoretical TAM. Honest critique. However, looking into experience with finance/fintech companies on Etherium, Corda, Canton Network, we see the enterprise adoption disproportionately lands on JVM stacks. Cardano currently has a limited entry path for those teams, which is part of what we're trying to build. That was the initial reason why we choose JVM over JavaScript ecosystem to build the platform.
Why application-owned L1 node is part of the platform?
We agree that Cardano does not need more generic node infrastructure for its own sake. The case for Scalus is narrower: application-owned chain access embedded in the application lifecycle.
Amaru, Dingo, and the Haskell node primarily optimise for block production and network-facing infrastructure roles. Scalus targets a different audience: applications that need their own chain access for development, testing, integration, and operational control. Those application-optimised/integrated nodes are missing on Cardano.
That is also why the node work is not meant as a separate infrastructure agenda. It is part of the same product thesis: one node model across the lifecycle of the application.
- prototyping with an in-memory node
- development with a configurable devnet (also exists for JS/TS environments)
- testnet with the same node connected to Preview or Preprod
- production with the same node running against mainnet
- scaling through Hydrozoa on the same stack
Just change the configuration and your node supports you! That continuity is important for development speed, operational simplicity, and reducing environment drift.
Why is this ultimately about applications, users, and growth?
We share the underlying view that adoption is Cardano's primary challenge. That is exactly what this proposal is trying to address.
The core question is not whether Cardano needs more infrastructure in the abstract. It is what helps more serious applications reach production, because that is what brings users, transactions, and TVL.
Our view is that teams should spend their time building the business logic that attracts users, not assembling five underlying solutions or debugging/building L2 infrastructure themselves.
Use cases
That is why the proposal is built around three application outcomes:
- New applications — reducing setup burden and shortening the path from idea to testnet
- Mission-critical applications and protocols — bringing rigorous testing, runtime, formal verification, and sovereign chain access closer to the application itself
- Applications with native L2 scaling — providing a path to higher throughput, lower operational overhead, and custom business logic without stepping outside the same platform
In that sense, the proposal is not “infrastructure instead of adoption.” It is infrastructure aimed specifically at improving Cardano's ability to launch more real applications.
Impact model
This is also how to read the 5 teams building with Scalus target. It means five serious product efforts in categories such as bridges, oracles, prediction markets, orderbook exchanges, or other non-trivial applications.
The impact model behind that target is pragmatic. At Cardano's current DeFi TVL baseline, one serious application reaching even a moderate $5M TVL would represent roughly 4% of current TVL. Three such applications would represent roughly 11%-12%. That is why we treat a small number of real product deployments as a meaningful ecosystem outcome.
Conclusion
We understand the proportionality concern. If this proposal were asking Treasury to fund a speculative platform expansion ahead of real usage, we would share that concern.
Our view is different. The current scope is a response to concrete bottlenecks surfaced by teams already building on Scalus, and other ecosystem teams that need to wire own L1 node with all interfaces, debug/setup/develop their own L2 solution, etc.
We appreciate the seriousness of your review, and we would welcome a continued discussion on what evidence, adoption threshold, or milestone signal would be most decision-relevant for future support.
Thank you again for engaging with the proposal in depth.