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.
- No794.5K ₳No rationale
- No717.5K ₳No rationale
- No705.1K ₳Rationale
No.
- No605.7K ₳Rationale
🗳 Cardano Governance Vote: Scalus — Treasury Withdrawal
They are asking for ₳8,503,000 ADA from the Cardano Treasury for the Scalus project by Lantr Engineering.
Timeline: 12 months
Period: July 2026 — June 2027
Proposal type: Treasury Withdrawal
Submitted: May 14, 2026
Expires: June 14, 2026The proposal focuses on building a large Cardano application platform with:
• Smart contracts
• L1 node infrastructure
• L2 integration
• Formal verification
• JVM / Java / Kotlin / Scala ecosystem supportMy answer: NO.
Why?
Because this project already exists.
Because they already received funding before.
Because they should finish and prove real ecosystem results first before asking for another massive Treasury withdrawal.Cardano Treasury should not become an endless funding machine where the same teams continuously request millions of ADA without delivering clear large-scale impact first.
First results.
Then new funding requests.My vote: NO.
I registered as a DRep and I am ready to help shape the future of the ecosystem.
Optimistic about building the largest digital community in the world. 🖤My DRep ID:
➡️ drep1y269ehxj30k4vfzfc2z84v0xykd3amuy2xn0kv9zf8rhcec2fg2jrMore info: https://t.me/PROCENT666/338
🚀 LEDGER COLD CRYPTO WALLET COURSE | METAMASK
https://edgarbagdasarian.justclick.ru/order/LEDGERMETAMASK🔥 PRIVATE VIP CHAT PAID SUBSCRIPTION
https://t.me/MREDGARCROSS_BOT🌐 ALL COURSES AND LINKS
https://mredgarcross.com/#Cardano #ADA #DRep #CardanoGovernance #Scalus #Crypto #Blockchain #Web3
- No590.5K ₳No rationale
- Yes589.7K ₳Rationale
I am voting yes because this proposal addresses Cardano’s next stage of growth: moving from infrastructure maturity to application delivery. By funding an integrated platform that brings smart contracts, verification, chain access, operations and scaling into one coherent stack, the Treasury can help reduce complexity for builders, attract devs.
- Yes587.6K ₳No rationale
- No533.9K ₳Rationale
Not critical right now. Infastructure and usage is the most important part of the equation and fiscal responsibility
- No499K ₳Rationale
- Yes487.7K ₳No rationale
- Yes466.2K ₳No rationale
- No438.7K ₳No rationale
- Abstain385.2K ₳Rationale
Abstaining, as I’m part of the Cardano Constitution Committee Tingvard.
Reading proposals and staying updated, just like you.
Thanks to all fellow DReps who are also doing the hard work.
Follow and DM me on X: @kenerik if you have any questions. - No383K ₳No rationale
- No381.1K ₳No rationale
- No365.7K ₳No rationale
- No360.3K ₳No rationale
- Yes328.9K ₳No rationale
- Abstain314.4K ₳Rationale
I have decided to abstain. This proposal is too technical for me to objectively evaluate. While an enterprise JVM platform is promising, real market demand isn't guaranteed. Also, funding another node isn't a treasury priority right now. I'd reconsider in a future budget cycle.
A PDF version of this rationale is also made available.
I have decided to abstain on this proposal. Because it is highly technical, it is very difficult for me to objectively evaluate it.
There are certainly good things here. The enterprise-grade JVM platform seems very promising and could serve as a bridge for institutional adoption. Still, building it does not automatically guarantee that there will be real market demand or real-world usage.
Also, a big part of this proposal is funding another node. Since the treasury has already funded alternative nodes like Dingo and Amuru, financing another one does not seem like a top ecosystem priority at this current stage.
Taking our current treasury spending into consideration, I would be much more willing to vote "yes" on a proposal like this under more favorable market conditions and in a future budget cycle - specifically, a cycle where we don't already have two or more other nodes under development.
- No300.6K ₳Rationale
More infrastructure. I don’t see a clear way to measure the return on the work. It’s like: ‘I’m going to build the platform and see if someone shows up and builds on it.’ It’s the same as throwing darts at the wall to see what sticks. This project sounds very Marlowe to me. I can’t support it.
- Abstain298.9K ₳Rationale
This proposal seems unlikely to pass. I am therefore abstaining to reclaim my time.
- No294.4K ₳No rationale
- Abstain279.8K ₳No rationale
- No271.8K ₳No rationale
- No270.1K ₳Rationale
I am voting NO on “Scalus: Cardano’s Application Platform for Building, Launching, and Scaling.”
This decision is not a reflection on the quality of the team or the technical merit of Scalus. Lantr has a strong delivery record, prior Catalyst and 2025 Treasury funding have produced tangible outputs, and the proposal is well structured from a constitutional, escrow, and oversight perspective. Scalus also addresses real pain points around application delivery, L2 integration, and sovereign chain access, and I agree that the application layer is a critical next focus for Cardano.
My concerns are primarily about proportionality, adoption, and scope at this point in time.
First, the scale of the ask. Scalus has already received approximately ₳1.08M in community funding across three Catalyst rounds and the 2025 Treasury budget proposal. The current request of ₳8.503M represents roughly eight times all prior funding combined, less than a year after the first Treasury withdrawal was enacted. While the unit cost assumptions for senior engineering and audits are reasonable, I do not believe ecosystem demand and usage have yet reached a level that justifies such a large follow‑on allocation.
Second, the adoption signal remains relatively early. The proposal cites integrations and use by projects such as Hydrozoa, Bifrost, SugarRush, and Vela, and Scalus clearly has technical traction. However, Cardano-wide data still shows that most smart‑contract developers are choosing other languages and toolchains (notably Aiken) as their primary option, and Scalus remains a minority choice today. The proposal’s own targets—five external teams, two production(-like) deployments, and two deeper integrations over the funding period—are modest relative to the size of the request. In my view, Treasury should see stronger evidence of broad, pull‑driven demand before committing to a platform expansion of this magnitude.
Third, the scope is very broad for a single 12‑month proposal. This is effectively four major initiatives bundled together: a smart contract platform, an application runtime, an application‑focused L1 node, and native L2 integrations. While there are synergies in pursuing an integrated stack, this breadth concentrates risk and makes it difficult to assess value per component. It also overlaps with multiple other infrastructure efforts (Amaru, Dingo, Dolos, Yaci, Balius, and potentially Gerolamo), at a time when many in the ecosystem are calling for more emphasis on user growth and application traction rather than additional platform-infrastructure bets.
Fourth, there is non‑trivial dependency and maintenance risk. Some of the most impactful roadmap items—L2 scaling and formal verification—depend on external projects such as Hydrozoa/Gummiworm and Blaster, which are not funded through this proposal. In addition, the proposal already anticipates an increased maintenance footprint in 2027 (2–2.5 FTE) before any diversified funding model is in place. Once Treasury funds a platform of this scope, ongoing maintenance and hard‑fork support become difficult to decline, even if adoption does not grow as expected.
In summary, I view Scalus as a serious, credible project with meaningful technical contributions and a well-governed proposal, but I do not believe this ₳8.5M bundled platform ask is proportionate to its current ecosystem adoption or to the broader Treasury context. I would be more inclined to support a smaller, more focused follow‑on proposal in the ₳1–2M range, aimed at deepening adoption, hardening specific layers, and demonstrating clear usage and impact, with larger expansions considered only after those results are evident.
For these reasons, I am casting a NO vote on this proposal at this time. - Abstain261K ₳No rationale
- No260.2K ₳No rationale
- No245.5K ₳Rationale
I have not witnessed a heavy demand for JVM development support within Cardano, so I do not believe this is the time to spend so much on this effort. That's not to say the time won't come one day.
- No238.8K ₳Rationale
Treasury runway is shrinking rapidly and must be protected. 1.51 - 1.62B ADA remains ($260M USD at ~0.16 USD/ADA). The 350M ADA 2026-27 NCL already risks ~21% treasury drawdown. Aggressive prior spending + ADA weakness demands selectivity to avoid depletion before real adoption.
Infrastructure is important, but it is not the primary bottleneck. Cardano's core tech is solid. The ecosystem stalls on adoption, liquidity, developer experience, and compelling use cases (DeFi, RWAs, revenue-generating apps). Broad infrastructure funding without adoption KPIs won't drive organic ADA demand.
Hoskinson's concerns deserve respect, but governance requires balance. Core maintenance matters for competitiveness. DRep duty is long-term sustainability: not unlimited spending. Past allocations often failed to yield proportional TVL/users/ADA utility. Prioritize evidence-based proposals.
Better capital allocation strategy: Favor high-leverage use-case initiatives with clear milestones, revenue/ADA return mechanisms, private co-funding, and proven traction. Target specific tech unlocks only when tied to measurable adoption impact. This builds real value without creating dependency. - No234.2K ₳No rationale
- No233.2K ₳No rationale
- Yes232.7K ₳No rationale
- Abstain215.5K ₳No rationale
- No207.6K ₳No rationale
- Abstain200.5K ₳No rationale
- No191.1K ₳No rationale
- No182.2K ₳No rationale
- No178.9K ₳No rationale
- No142.5K ₳Rationale
I would support a more focused proposal:
smart contract development,
L1 node capabilities (Pillars 1 and 3), - Yes137.4K ₳No rationale
- Abstain131.9K ₳No rationale
- No110.9K ₳No rationale
- No92.6K ₳No rationale
- No69.4K ₳No rationale
- AbstainChanged68.8K ₳History
Earlier votes
Yes2mo agoSuperseded
- Yes56.2K ₳Rationale
I agree that we need to get more apps and more users into the cardano ecosystem. I think the proposal is accurate where it states there needs to be one coherent stack, like how squarespace or shopify make it easy for people to build a website or online shop.
- Yes55.9K ₳Rationale
hell yes. this is Ethereum's remix for Cardano. Remix is responsible for A LOT of the success of EVM and Solidity. It serves as much as dev tooling than it serves as onboarding and education tool. Highly needed and great potential
- No52.4K ₳No rationale
- No50.5K ₳No rationale
- No46.5K ₳No rationale