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.
- Yes587.6K ₳No rationale
- No535.2K ₳Rationale
Developer costs and inoperability will become much cheaper over time. Right now high assuarance is first with Rust and GO coming soon.
- No499K ₳Rationale
- Yes487.9K ₳No rationale
- Abstain480.2K ₳No rationale
- Yes478.5K ₳No rationale
- No383.2K ₳No rationale
- Yes377.7K ₳Rationale
Basic infrastructure for many projects should be funded by the treasury to stay not-for-profit and openly available.
- Abstain365.9K ₳No rationale
- No360.4K ₳No rationale
- Abstain309.6K ₳Rationale
Review Methodology Disclaimer [EN]
Due not only to the unusually high volume of Treasury Withdrawal Governance Actions and budget proposals submitted in April and May 2026, but also to the lack of meaningful incentives for DReps to perform proposal analysis work, it is not feasible to apply my full standard review framework and reporting template to every proposal.
My standard analysis process usually requires approximately four hours of work per Governance Action. During that process, I research the proposal, review supporting materials, compare different perspectives from DReps and other ecosystem participants, and weigh both positive and negative arguments before reaching a reasonably qualified decision. Even with the use of artificial intelligence to automate parts of the workflow and improve productivity, a responsible evaluation still requires substantial human review, judgment, and contextual understanding.
In addition, this work does not end with the vote itself. It also involves writing and publishing rationales, preparing reports or summaries, communicating the reasoning publicly, and socializing the analysis through public channels and social media. This creates a significant workload, especially when dozens of proposals must be reviewed in a short period.
At present, this work carries no clear financial incentive and only limited reputational incentive, despite requiring substantial time, attention, and accountability. In practice, it is not sustainable to dedicate near full-time effort over several weeks or months to this activity without any form of compensation or institutional support.
Since I have a clear standard for my work and do not want to lower the quality of my judgment, I will reduce the scope of my analysis where necessary rather than rush decisions or produce superficial rationales. This means prioritizing focused due diligence over exhaustive review.
Under these constraints, my methodology during this period will focus on identifying critical strategic, operational, governance, reputational, or execution-related risks that could materially compromise a proposal’s viability, accountability, or successful delivery. In practical terms, this means narrowing my research toward the most critical gaps that may make approval unjustifiable. Where such a serious risk is identified, I may use it as the basis for a rejection vote.
This approach also helps reduce review overload: proposals with clear and material gaps would likely require rework regardless, so voting against them when those gaps are significant can be a responsible way to preserve review capacity while maintaining minimum due diligence.
Examples of such high-priority concerns may include, but are not limited to:
- Serious delivery failures in previous funded proposals;
- Significant unresolved delays in ongoing work;
- Major reputational or accountability issues within the ecosystem;
- Lack of credible execution capacity;
- Structural governance or transparency concerns;
- Severe budgetary or coordination risks.
Where I do not have sufficient time for a deeper evaluation, and no significant red flags or imminent execution risks are identified, I may abstain rather than issue an underdeveloped approval or rejection rationale.
This does not mean that other dimensions of proposal quality are unimportant. It means that, under current constraints, I will prioritize a narrower but still responsible review scope that preserves minimum due diligence, avoids rushed decisions, and keeps the quality of my judgment at an acceptable standard.
Governance Action Report
1. Introduction
Scalus is an established open-source Cardano development platform created by Lantr Engineering and developed continuously over three years. Its components support complex protocols and applications such as Gummiworm L2, the Bifrost bridge, SugarRush DEX, Vela stablecoin, and DID/DIDComm identity infrastructure. They are also reused through developer tools including MeshJS, Evolution SDK, Lucid Evolution, Cardano Client Lib, and YaciDevKit.
The governance action requests ₳2,464,844, approximately US$394,375 at a reference rate of US$0.16 per ADA, for nine months of milestone-based work. The scope covers maintenance of the existing infrastructure, preparation for the Dijkstra hard fork, interoperability across JVM and JavaScript/TypeScript ecosystems, and a first scoped application-runtime release. The standalone L1 node, full Gummiworm integration, broad formal verification, and contingency reserve included in the previous version have been removed. Delivery is administered through SundaeSwap treasury contracts, an independent oversight board, third-party technical assurance, quarterly reporting, and public transaction records.
2. Governance Action Analysis
Positive aspects
The new version represents a substantial improvement over the previous proposal. The main concern regarding the excessively broad scope was largely mitigated. The budget was reduced by approximately 71%, the scope was significantly narrowed, development of the L1 node, full integration with Gummiworm, and the broader formal verification work were removed, and the proposal became focused on maintaining the existing infrastructure, preparing for the Dijkstra hard fork, interoperability, and a first stage of the application runtime. This significantly reduces execution risk and makes the proposal much more proportional.
The KPIs also evolved compared with the previous proposal. There are objective and verifiable targets for interoperability, documentation, adoption, and hard fork readiness.
The overall quality of the proposal is high. The document is well structured, responds directly to the criticisms received during the previous submission, and demonstrates concern for governance, accountability, and transparency. The team’s track record also inspires confidence, both because of its accumulated experience and its history of previous deliveries within the Cardano ecosystem.
Negative aspects
The budget, on the other hand, continues to be based on a compensation methodology positioned in the upper range of the market. The rate of approximately US$210,000 per FTE per year, approximately US$101 per hour, remains high even when compared with benchmarks from developed countries with traditionally high compensation levels. This, by itself, does not mean that the costs are inflated or inappropriate, especially considering the level of specialization expected for the work. However, it also does not characterize a particularly cost-effective proposal or an exceptional opportunity for the Treasury. It is a premium budget for a highly specialized team.
Agora also does not regard positively the decision to eliminate the budget contingency entirely solely to reduce the requested amount. The existence of a risk-mitigation reserve is a common practice in software development projects and contributes to increasing execution resilience in the face of unforeseen events. Although removing the contingency made the proposal leaner, reducing the budget at any cost is not, in itself, regarded as desirable. Under certain circumstances, an appropriately justified contingency reserve may represent more prudent risk management than an excessively compressed budget.
Although the KPIs have evolved, they remain relatively modest and are concentrated mainly on delivery and initial-adoption indicators, providing limited evidence regarding broader ecosystem impact.
The broader context of resource allocation also needs to be considered. Treasury distribution data indicate a strong concentration of resources in infrastructure proposals during both this cycle and the previous one. This allocation bias reduces the marginal competitiveness of new initiatives in the same category, since other strategic areas of the ecosystem remain relatively less supported and compete for the same limited budget.
Risks and concerns
The point that continues to generate the greatest uncertainty is the proposal’s strategic thesis itself. Although the document presents plausible arguments for expanding the Scalus platform and strengthening its integration with the JVM ecosystem, Agora does not find that the pitch demonstrates sufficiently convincingly the need for this implementation or the adoption potential that would justify prioritizing it over other competing initiatives. The proposal presents evidence of use and technical reuse, but it still does not provide Agora with sufficient conviction regarding future demand or the strategic priority of this investment for the ecosystem as a whole.
3. Vote and Rationale
Vote: ABSTAIN
It is also recognized that Agora is not the most qualified party to assess, with a high degree of confidence, the technical merit and strategic importance of this specific technological direction.
The new version substantially mitigates the previous concerns regarding breadth, proportionality, and execution risk. The proposal has evident qualities, objective KPIs, a well-structured governance and accountability model, and an experienced team with a history of delivery. However, the premium compensation methodology remains, the KPIs provide limited evidence of broader ecosystem impact, Treasury resources are already strongly concentrated in infrastructure, and the necessity, future demand, and strategic priority of this implementation have not been demonstrated with sufficient conviction.
Faced with evident qualities, but also relevant limitations and uncertainties, sufficient conviction was formed neither to support the proposal nor to reject it. For these reasons, the position remains ABSTAIN.
4. Conclusion
The narrower scope and reduced execution risk materially improve the proposal. However, the premium budget, modest impact indicators, existing concentration of Treasury funding in infrastructure, and uncertainty regarding demand and strategic priority prevent a definitive position in either direction. The vote therefore remains ABSTAIN.
Nota sobre metodologia e escopo de análise [PT]
Devido não apenas ao volume excepcionalmente alto de Treasury Withdrawal Governance Actions e propostas orçamentárias submetidas em abril e maio de 2026, mas também à falta de incentivos significativos para que DReps realizem o trabalho de análise de propostas, não é viável aplicar meu framework completo de revisão e meu template padrão de relatório a todas as propostas.
Meu processo padrão de análise normalmente exige aproximadamente quatro horas de trabalho por Governance Action. Durante esse processo, eu pesquiso a proposta, reviso materiais de suporte, comparo diferentes perspectivas de DReps e de outros participantes do ecossistema, e peso argumentos positivos e negativos antes de chegar a uma decisão razoavelmente qualificada. Mesmo com o uso de inteligência artificial para automatizar partes do fluxo de trabalho e aumentar a produtividade, uma avaliação responsável ainda exige revisão humana substancial, julgamento e entendimento contextual.
Além disso, esse trabalho não termina no voto em si. Ele também envolve escrever e publicar rationales, preparar relatórios ou resumos, comunicar publicamente a justificativa e socializar a análise por meio de canais públicos e mídias sociais. Isso cria uma carga de trabalho significativa, especialmente quando dezenas de propostas precisam ser avaliadas em um curto período.
Atualmente, esse trabalho não possui incentivo financeiro claro e oferece apenas incentivo reputacional limitado, apesar de exigir tempo, atenção e responsabilidade substanciais. Na prática, não é sustentável dedicar um esforço próximo de tempo integral durante várias semanas ou meses a essa atividade sem qualquer forma de compensação ou apoio institucional.
Como tenho um padrão claro para o meu trabalho e não quero reduzir a qualidade do meu julgamento, irei reduzir o escopo da minha análise quando necessário, em vez de tomar decisões apressadas ou produzir justificativas superficiais. Isso significa priorizar uma diligência focada em vez de uma revisão exaustiva.
Sob essas restrições, minha metodologia durante este período se concentrará em identificar riscos críticos estratégicos, operacionais, de governança, reputacionais ou relacionados à execução que possam comprometer materialmente a viabilidade, a accountability ou a entrega bem-sucedida de uma proposta. Na prática, isso significa concentrar minha pesquisa nos gaps mais críticos que possam tornar a aprovação injustificável. Quando um risco sério desse tipo for identificado, poderei usá-lo como base para um voto de rejeição.
Essa abordagem também ajuda a reduzir a sobrecarga de revisão: propostas com gaps claros e materiais provavelmente exigiriam retrabalho de qualquer forma, então votar contra elas quando esses gaps forem significativos pode ser uma forma responsável de preservar capacidade de análise enquanto se mantém uma diligência mínima.
Exemplos dessas preocupações de alta prioridade podem incluir, mas não se limitam a:
- Falhas graves de entrega em propostas anteriormente financiadas;
- Atrasos significativos e não resolvidos em trabalhos em andamento;
- Problemas graves de reputação ou accountability dentro do ecossistema;
- Falta de capacidade crível de execução;
- Preocupações estruturais de governança ou transparência;
- Riscos severos de orçamento ou coordenação.
Quando eu não tiver tempo suficiente para uma avaliação mais profunda, e nenhum alerta significativo ou risco iminente de execução for identificado, poderei me abster em vez de emitir uma justificativa de aprovação ou rejeição pouco desenvolvida.
Isso não significa que outras dimensões da qualidade de uma proposta não sejam importantes. Significa que, sob as restrições atuais, priorizarei um escopo de revisão mais estreito, mas ainda responsável, que preserve uma diligência mínima, evite decisões apressadas e mantenha a qualidade do meu julgamento em um padrão aceitável.
Relatório de Ação de Governança
1. Introdução
Scalus é uma plataforma open source de desenvolvimento para Cardano estabelecida pela Lantr Engineering e desenvolvida continuamente ao longo de três anos. Seus componentes apoiam protocolos e aplicações complexas, como Gummiworm L2, a bridge Bifrost, SugarRush DEX, Vela stablecoin e a infraestrutura de identidade DID/DIDComm. Também são reutilizados por ferramentas de desenvolvimento como MeshJS, Evolution SDK, Lucid Evolution, Cardano Client Lib e YaciDevKit.
A ação de governança solicita ₳2.464.844, aproximadamente US$394.375 com uma taxa de referência de US$0,16 por ADA, para nove meses de trabalho baseado em milestones. O escopo inclui a manutenção da infraestrutura existente, preparação para o hard fork Dijkstra, interoperabilidade entre os ecossistemas JVM e JavaScript/TypeScript e uma primeira versão de escopo limitado do application runtime. O node L1 independente, a integração completa com Gummiworm, o trabalho amplo de formal verification e a reserva de contingência presentes na versão anterior foram removidos. A execução será administrada por contratos de tesouraria da SundaeSwap, um conselho de supervisão independente, garantia técnica de terceiros, relatórios trimestrais e registros públicos das transações.
2. Análise da Ação de Governança
Aspectos positivos
A nova versão representa uma melhoria substancial em relação à proposta anterior. A principal preocupação sobre o escopo excessivamente amplo foi amplamente mitigada. O orçamento foi reduzido em cerca de 71%, o escopo foi significativamente enxugado, o desenvolvimento do node L1, a integração completa com Gummiworm e o trabalho mais amplo de formal verification foram removidos, e a proposta passou a concentrar-se na manutenção da infraestrutura existente, preparação para o hard fork Dijkstra, interoperabilidade e uma primeira etapa do application runtime. Isso reduz significativamente o risco de execução e torna a proposta muito mais proporcional.
Os KPIs também evoluíram em relação à proposta anterior. Existem metas objetivas e verificáveis para interoperabilidade, documentação, adoção e preparação para o hard fork.
A qualidade geral da proposta é elevada. O documento é bem estruturado, responde diretamente às críticas recebidas na submissão anterior e demonstra preocupação com governança, prestação de contas e transparência. O histórico da equipe também inspira confiança, tanto pela experiência acumulada quanto pelo histórico de entregas anteriores no ecossistema Cardano.
Aspectos negativos
O orçamento, por outro lado, continua baseado em uma metodologia de remuneração posicionada na faixa superior do mercado. O rate de aproximadamente US$210 mil por FTE/ano, cerca de US$101 por hora, permanece elevado mesmo quando comparado a benchmarks de países desenvolvidos com remunerações tradicionalmente altas. Isso, por si só, não significa que os custos estejam inflados ou sejam inadequados, especialmente considerando o nível de especialização esperado para o trabalho. No entanto, também não caracteriza uma proposta particularmente eficiente do ponto de vista de custo-benefício ou uma oportunidade excepcional para o Tesouro. Trata-se de um orçamento premium para uma equipe altamente especializada.
Agora também não considera positiva a decisão de eliminar integralmente a contingência orçamentária apenas para reduzir o valor solicitado. A existência de uma reserva para mitigação de riscos é uma prática comum em projetos de desenvolvimento de software e contribui para aumentar a resiliência da execução diante de eventos imprevistos. Embora a remoção da contingência tenha tornado a proposta mais enxuta, a redução do orçamento a qualquer custo não é, em si, um aspecto que Agora considera desejável. Em determinadas circunstâncias, uma reserva de contingência adequadamente justificada pode representar uma gestão de riscos mais prudente do que um orçamento excessivamente comprimido.
Embora os KPIs tenham evoluído, permanecem relativamente modestos e concentram-se principalmente em indicadores de entrega e adoção inicial, oferecendo evidências limitadas sobre impacto mais amplo para o ecossistema.
O contexto mais amplo de alocação de recursos também precisa ser considerado. Os dados de distribuição do Tesouro indicam uma forte concentração de recursos em propostas de infraestrutura tanto neste ciclo quanto no anterior. Esse viés de alocação reduz a competitividade marginal de novas iniciativas da mesma categoria, uma vez que outras áreas estratégicas do ecossistema permanecem relativamente menos contempladas e disputam o mesmo orçamento limitado.
Riscos e preocupações
O ponto que continua gerando maior incerteza é a própria tese estratégica da proposta. Embora o documento apresente argumentos plausíveis para a expansão da plataforma Scalus e para o fortalecimento da integração com o ecossistema JVM, Agora não considera que o pitch demonstre de forma suficientemente convincente a necessidade dessa implementação nem o potencial de adoção que justificaria priorizá-la frente a outras iniciativas concorrentes. A proposta apresenta evidências de utilização e reutilização técnica, mas ainda não transmite a Agora convicção suficiente sobre a demanda futura ou sobre a prioridade estratégica desse investimento para o ecossistema como um todo.
3. Voto e Justificativa
Voto: ABSTAIN
Também se reconhece que Agora não é a parte mais qualificada para avaliar, com elevado grau de confiança, o mérito técnico e a importância estratégica dessa direção tecnológica específica.
A nova versão mitiga substancialmente as preocupações anteriores relacionadas à amplitude, proporcionalidade e risco de execução. A proposta possui qualidades evidentes, KPIs objetivos, um modelo bem estruturado de governança e prestação de contas e uma equipe experiente com histórico de entregas. No entanto, permanecem a metodologia de remuneração premium, a capacidade limitada dos KPIs de demonstrar impacto mais amplo para o ecossistema, a forte concentração de recursos do Tesouro em infraestrutura e a ausência de convicção suficiente sobre a necessidade, a demanda futura e a prioridade estratégica dessa implementação.
Diante de qualidades evidentes, mas também de limitações e incertezas relevantes, não foi formada convicção suficiente nem para apoiar a proposta nem para rejeitá-la. Por essas razões, a posição permanece ABSTAIN.
4. Conclusão
O escopo mais enxuto e a redução do risco de execução melhoram materialmente a proposta. No entanto, o orçamento premium, os indicadores modestos de impacto, a concentração existente de recursos do Tesouro em infraestrutura e as incertezas sobre demanda e prioridade estratégica impedem uma posição definitiva em qualquer direção. O voto permanece ABSTAIN.
- Abstain299.1K ₳Rationale
This is a tough one. I don't see much point in investing in the Java development ecosystem. At the same time this is a legitimate infrastructure funding request and I would rather not vote something down and in doing so cause valuable projects to be jeopardised. I am therefore abstaining as a sort of half way vote.
- No298.3K ₳No rationale
- Yes270.3K ₳Rationale
I am voting YES on “Scalus 2026 Maintenance, Dijkstra Readiness, Interoperability & Application Runtime.” Scalus is already established open-source infrastructure in the Cardano ecosystem, with three years of continuous delivery, active use in serious protocols and applications, and indirect reuse across widely used tooling such as MeshJS, Lucid Evolution, Evolution SDK, Cardano Client Lib, and YaciDevKit. This proposal is not asking the Treasury to fund a speculative new platform from scratch, but to maintain and extend infrastructure that other teams already depend on.
My earlier reservations about Scalus were primarily about the size and breadth of the previous proposal rather than the quality of the work itself, and this resubmission responds to that feedback in a credible way. The ask has been reduced substantially, the scope is narrower and more disciplined, and the most contested items from the earlier version — including the standalone L1 node, full L2 integration, and broad formal-verification track — have been removed from the funded scope.
The funded work is focused on three concrete priorities: keeping existing Scalus infrastructure maintained and ready for the Dijkstra hard fork, improving interoperability across the JVM and JavaScript/TypeScript ecosystems, and delivering a bounded first application runtime that helps teams move from protocol development toward running applications in production. Those are all reasonable next steps for infrastructure that is already in active use, and they are paired with milestone-based delivery, independent oversight, and third-party assurance.
I also view the budget as proportionate in its revised form. At 2,464,844 ADA over 9 months, with no contingency and only 2.25 FTE of staffing, this is a much more defensible continuation request than the earlier, broader platform expansion. Under current NCL pressure, every YES requires discipline, but this proposal clears the bar because it protects prior public investment, reduces ecosystem breakage risk ahead of Dijkstra, and supports infrastructure that already compounds across multiple teams and tools.
For those reasons, I am voting YES. This is the kind of scaled-down, feedback-responsive, technically credible infrastructure continuation that Treasury funding should be able to support, even in a tighter budget environment.
- Abstain262.3K ₳Rationale
Abstain due to personal involvement
- Yes260.4K ₳Rationale
Voting YES. A strong example of addressing DRep feedback — budget cut 71% and refocused on core priorities like Dijkstra hard-fork readiness. Funds are held in an audited escrow with an independent oversight board and automatic sweep of unused funds back to the Treasury, giving solid protection on both disbursement and refund.
- Yes246.1K ₳Rationale
This is a much more reasonable price tag than previously asked for this open-source infrastructure that's already embedded in MeshJS/Lucid/Evolution SDK and used by protocols. It keeps in-use public infrastructure working through the Dijkstra transition at a proportionate price.
- No227.9K ₳No rationale
- No215.5K ₳No rationale
- Yes196.1K ₳No rationale
- No191.2K ₳No rationale
- Yes182.3K ₳No rationale
- Yes180K ₳No rationale
- No162.9K ₳No rationale
- Yes142.6K ₳No rationale
- Yes136.2K ₳Rationale
Scalus 2026 — Treasury Withdrawal (₳2,464,844) — Voting Rationale
Governance Voting Rationale GAID gov_action1xg6...qa63yc Title Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime (Lantr Engineering) Type of GA Treasury Withdrawals Date submitted Epoch 640 (Jun 29, 2026) Expiration Date Epoch 647 (Aug 2, 2026) Contents
1.0 Introduction {#1.0-introduction}
1.1 Summary {#1.1-summary}
We are voting YES on the Scalus 2026 treasury withdrawal — ₳2,464,844 over nine months to Lantr Engineering, to maintain the Scalus development platform, ready it for the Dijkstra hard fork, deepen its reuse across the JVM and JavaScript stacks, and ship a scoped first step toward an application runtime.
The reason is straightforward, and its being straightforward is the point. Scalus is open-source infrastructure the ecosystem already depends on — directly, in the protocols built on it, and indirectly, through its components embedded in tooling many teams use every day (MeshJS, Lucid Evolution, Evolution SDK, the Cardano Client Lib, Yaci). Keeping a shared, freely forkable good like that maintained and current through a protocol transition is close to the clearest case there is for what the treasury exists to fund.
There is a test this DRep applies to any treasury request from a for-profit entity, and it is worth naming because Lantr is one: a for-profit drawing treasury funds has to show its claim rests on maintaining something the whole ecosystem depends on and can freely use, not on growth it projects while keeping the upside. Scalus meets that test plainly — the good is a non-rival public asset under an open licence, and the ask funds the effort to maintain and extend it, with no private-surplus mechanism attached. The construction around the money is sound, the amount is modest, the exposure is staged, and the whole thing reverses simply by not being renewed. This is a proposal with little that could go wrong unseen, and that is exactly what a low-scrutiny reading means. The one thing worth carrying forward is not an objection but a note for future cycles, set out at the end.
1.2 Description of Governance Action {#1.2-description-of-governance-action}
This Treasury Withdrawals action requests ₳2,464,844 (about $394,375 at the proposal's $0.16/ADA reference rate) for nine months of milestone-based work, July 2026 through March 2027, with no contingency. Lantr Engineering is the sole vendor. The work spans three lines beyond continuous maintenance: readiness for the Dijkstra hard fork (Plutus V4, nested transactions, accounts, and the associated ledger and tooling changes), interoperability improvements across the JVM and JS/TS ecosystems, and a bounded first release of an application runtime, validated through reference applications and early users.
The funds are held and released through the audited SundaeSwap treasury-contracts framework, with milestone-based vesting, an independent oversight board (members from Blink Labs, the Cardano Foundation, and IOG) that co-signs disbursements and can pause or halt funding, third-party technical assurance from No.Witness Labs, and an independent financial audit. Escrowed funds are set to auto-abstain in governance and cannot be delegated to a stake pool, and anything unspent at expiry sweeps back to the treasury automatically. The proposal is a reduced resubmission of an earlier, larger Scalus proposal (₳8.5M over twelve months), rescoped to answer the scale concerns raised in that vote. It discloses prior funding — earlier Catalyst awards and a 2025 treasury grant of ₳657,692 — and sits within the current 350M net-change limit at submission.
2.0 Discussion {#2.0-discussion}
2.1 The question a for-profit treasury request has to answer {#2.1-the-question-a-for-profit-treasury-request-has-to-answer}
The treasury is a shared resource, held in trust for the whole ecosystem, and a for-profit company asking to draw from it raises a fair question about the shape of the claim. This DRep states that question as a standing test, published so it is applied the same way every time: the question is not whether the recipient is a company — it is whether the thing being funded is the maintenance of something the ecosystem collectively depends on and can freely use, or the funding of a private venture that keeps its own upside. The first is a claim rooted in the commons. The second is not, and arguments from projected growth do not convert one into the other.
Scalus discharges that test about as cleanly as a for-profit request can. The good is open-source under Apache 2.0 — non-rival, freely usable, and forkable, so nothing here is enclosed or made exclusive. Its degradation would be felt across the ecosystem precisely because so much tooling embeds its components, which is the mark of a genuine commons relation rather than a private one. And the ask carries no private-surplus instrument: no performance fee, no equity, no revenue share. The funding buys engineering effort, priced as effort, against a public asset the ecosystem keeps regardless of how Lantr fares commercially. That the same team also builds commercial products on top of Scalus does not change this — the platform itself remains the shared, forkable good, and the treasury is paying to maintain that good, not to underwrite the products. This is worth saying with some care because the contrast is real: a request that asked the treasury to fund growth while routing the resulting upside to a private party would be a different proposal facing a much harder question. This one does not.
2.2 Why this reads as a low-scrutiny proposal — and why that is the right reading {#2.2-why-this-reads-as-a-low-scrutiny-proposal}
This DRep sorts every action before reading its merits, to decide how much scrutiny it earns — the goal being to spend the most attention where the most could go wrong without announcing itself. Scalus earns a light reading, and it is worth being explicit that "light" is a description of risk surface, not of quality. A few things account for it. This is a single, self-contained decision, not one half of a pair of actions arranged so the real commitment lands where scrutiny is lowest — a maneuver this DRep watches for, and which is simply absent here. It tunes a spend within the existing rules rather than changing any structural constraint or installing a standing default. If it proves a poor use of funds in eighteen months, reversing it costs nothing more than declining to renew: the term ends on its own, unspent funds return automatically, and because the code is open-source and forkable, the ecosystem keeps everything already built and no party is left holding leverage against the reversal. And if the work degraded, the degradation would show up loudly through ordinary channels — public repositories, releases, download counts, conformance tests, third-party assurance, and the many dependent projects that would notice breakage first.
None of those readings requires trust in the proposer; they are properties of the action's structure, and they are the reason this proposal does not need the deeper machinery this DRep reserves for actions that can fail quietly or irreversibly. Most sound proposals read this way. A framework that manufactured suspicion here would be miscalibrated, and part of what this reading is for is to say plainly when there is little to contest.
2.3 The construction, and the money it asks for {#2.3-the-construction-and-the-money-it-asks-for}
This DRep's framework reads relations rather than pricing allocations, so the question of whether ₳2,464,844 is well spent — the right amount, the right instrument, a good use of finite treasury against everything else it could fund — is read through a separate capital-stewardship instrument maintained by a peer DRep. For open-source infrastructure, that instrument treats the continuity of the public asset itself as the principal return to the treasury, which is the right frame for what this is.
On that reading the proposal is in good order. The amount is modest — roughly on par, in dollar terms, with the single 2025 grant, and a substantial reduction from the earlier version. The exposure is staged rather than released at once: milestone vesting, a board that must co-sign disbursements and any one of whose members can pause a milestone, and an automatic sweep of anything unused. The delivery record is real — every milestone of the 2025 cycle was delivered on time, with additional work beyond the committed scope. The ADA pricing is honest: the $0.16 reference rate sits slightly below the current market price of around $0.17, and the proposal commits to hedging into stable assets on receipt, a direct and candid response to the roughly fifty-percent purchasing-power loss the 2025 grant suffered as ADA fell during that delivery window. Most importantly for a capital-stewardship read, there is no private-capture structure for the instrument to flag — no upside routed away from the commons. The allocation reading concurs with the vote; it finds nothing that should lower it.
2.4 What the vote does not reach {#2.4-what-the-vote-does-not-reach}
A few observations belong in this DRep's longer-run record rather than in the vote, because they are about trajectory across cycles rather than about this action, which is sound.
The first concerns the application runtime. It is the one workstream that reaches beyond maintaining what already exists toward building something new, and while it is bounded, open-source, and validated with real teams this cycle, it is the part most worth watching over time. An application runtime that the ecosystem comes to build on could, in a few cycles, become infrastructure whose health the ecosystem reads through — at which point a future Scalus proposal would earn a deeper look than this one does. That is a note for the next reading, not a reservation on this one.
The second is about recurring funding generally. This is the second Scalus treasury withdrawal in twenty-four months, and a maintainer the ecosystem depends on can, over enough cycles, drift from being funded because it earns each round toward being funded because too much now depends on it to stop. The thing that keeps that exit genuinely open is the forkability of the code, and the honest discipline is to re-read at each renewal whether that exit is still real. Today it plainly is.
The last is not about Scalus at all. The proposal's own retrospective describes a treasury process where a bundled budgeting path stretched five to six months from proposal to first payment, offered no protection against ADA's decline, and carried standing governance risk in the bundling itself — enough that this proposer, like others before it, chose to submit independently and on-chain instead. That teams capable of maintaining critical infrastructure are routing around the coordinated process is a signal about the process worth tracking on its own, separately from any single vote.
3.0 Conclusion {#3.0-conclusion}
We vote YES. Scalus is public infrastructure the ecosystem already relies on, the request maintains and extends it as a freely forkable common good, and the for-profit test that a treasury request of this kind must meet is met plainly — the claim rests on a maintained commons relation, not on a private surplus. The construction is sound, the amount modest, the exposure staged, the delivery record demonstrated, and the whole action reverses by simply not being renewed.
The framework's work here was not to find fault but to confirm that the burden is discharged and the risk surface is genuinely shallow, and to say so without manufacturing scrutiny the action does not warrant. The one thing carried forward is a matter for future cycles rather than this vote: to re-read, as the runtime grows and the funding recurs, whether the ecosystem's exit from this dependency stays as open as the code's licence currently keeps it.
Thank you for reading this rationale and for supporting it with your delegation. And the work continues...
References / Sources {#references-sources}
The following background may help a reader new to this DRep's approach:
- The evaluation framework — this DRep's standing method of judging governance actions by their long-run trajectory and their risk of failing unseen, rather than by a single snapshot, first set out in the rationale on the Cardano Constitution. Coordination Commons
- The claim a for-profit makes on the shared treasury — the published test distinguishing the maintenance of a non-rival, forkable good the ecosystem depends on from the funding of a private surplus. Private-Surplus Burden
- The DRep Treasury Rule Book — the capital-stewardship instrument, maintained by a peer DRep, used here as the allocation check. DREP Treasury Rulebook v17
DRep ID: drep1yfaq8dsam7nusdccey2x2p684f6ulhr42pv24tslv0terqs3nq50q
Stay in touch!
X: https://x.com/styg50
- Yes131.9K ₳No rationale
- No123.8K ₳No rationale
- Yes92.6K ₳No rationale
- No72.7K ₳No rationale
- Abstain63.3K ₳No rationale
- Yes59.9K ₳No rationale
- No56K ₳No rationale
- No50.5K ₳No rationale
- Yes47.8K ₳Rationale
I vote YES for this proposal
- No45.3K ₳No rationale
- Abstain31.7K ₳No rationale
- Abstain26.7K ₳Rationale
Not going to pass
- Yes24.4K ₳No rationale
- No16.6K ₳No rationale
- Abstain8.1K ₳No rationale
- No6.7K ₳No rationale
- Yes688.2 ₳No rationale
- NoChanged0 ₳History
Earlier votes
Yes24d agoSuperseded
No1mo agoSuperseded