Pebble + Gerolamo - HLabs 2026 Budget
199 DReps voted · 87 with a rationale · 21 changed their vote
Open a row to read the rationale.
- Abstain16.7M ₳Rationale
I like the direction and I see real value here. Gerolamo targets trust-minimized dApps/light wallets and relay diversity, Pebble can broaden the developer funnel with a more familiar imperative/TypeScript-like experience, and ongoing TypeScript tooling maintenance reduces hard-fork fragmentation risk.
My hesitation is not about HLabs’ capability, but about process and procurement. This is a large, core-infrastructure request that will influence long-term maintenance commitments and how Cardano funds non-Haskell node/tooling work.
Before approving additional major node/tooling initiatives, I want to see an RFP/tender-style process for alternative nodes (and also for Haskell node maintenance): side-by-side comparison of scope, security/audit requirements, delivery milestones, adoption plan (including SPO/wallet/dApp uptake), and cost/maintenance expectations. Without that, it’s difficult to claim we’re achieving fair price discovery or choosing the best option among competing approaches.
For these reasons, I’m abstaining — I’m open to supporting HLabs in a revised process where proposals are evaluated competitively and granularly for this critical infrastructure category.
- Yes16.4M ₳No rationale
- Yes14.1M ₳No rationale
- Yes13.9M ₳Rationale
I am voting YES on governance action b11527fbcdc9d41e8f497de64a029a18673a5eefc413718459046f0b7a1a6656#0.
I came very close to voting NO or ABSTAIN on this proposal, but ultimately came in as a YES.
(Nearly) All arguments for node diversity that I made in my Dingo vote apply year as well.
However, here is why I was on the fence and this was a much harder decision to make for me:
- Feasibility
I believe the vision of having a full typescript node that runs in the browser is a pipe dream and likely to fail for many reasons:
- Communication challenges between the browser and other nodes; unless we fundamentally change all node implementations, the browser node will always be dependent on a separate backend relay.
- Performance challenges; The performance budget for Cardano nodes, is already challenging to hit: a node has to produce a block within 1 second, propagate blocks efficiently, evaluate many chains, hold a lot of state in memory or persisted to disk, etc; While not insurmountable for typescript currently, it's a huge engineering lift. And this likely becomes impossible to do safely for the full Leios protocol.
In the end, despite high chance of failure in the end goal, I think this is a case of landing among the stars. Even if the project fails, it will produce artifacts that are well worth the cost:
- Additional skilled engineers focused on contributing to conformance testing and specification of the Cardano protocol
- Useful parsing and validation libraries for use in the browser
- Light-wallet / trustless validation primitives for dApps
- Overlap
In my estimation, there is a spiritual overlap between the deliverables in Intersect administered Gerolamo vote from last year and this one.
Consider the following excerpts from proposal deliverables from both proposals:
2025 budget:
The goal is to have a fully functional light node that can run in the browser and can be integrated in dApps and wallets.
This proposal
a production-ready light node (Gerolamo);In the end, last years ask was sufficiently small, and "production-ready" load bearing enough that I'm willing to overlook this.
- Delivery risk
I am not as certain about Harmonic Labs' ability to deliver as I am of Blink Labs on the Dingo node. Based on milestone submission for the previous Intersect administered project, milestone submission has come in consistently late.
Additionally, a cursory glance at the teams Github seems to indicate they have 3 developers currently. This proposal asks for funding for 10 engineers (it doesn't specify which of these are already part of the project vs net-new additions, so charitably, this is covering the existing teams salary and 7 new hires). However, running a team of 3 engineers, and running a team of 10 engineers, are fundamentally different beasts; Unlike Dingo, where the team has practical real-world experience running larger teams and big open source projects, HLabs' ability to scale their team is unproven. Hiring that many engineers in a short period of time adds additional risks. They also run the risk of stretching themselves thin with other projects, such as their unreleased DEX and unfinished Catalyst projects.
In the end, I know the engineers involved are competent (by their existing deliveries on other projects) and well intentioned. Their 3rd party oversight board consists of respected community members, using well tested and familiar contracts (written in part by myself). This limits the risk to opportunity cost (the risk that we allocate funds out of our NCL that cannot be used elsewhere), not risk of lost funds.
- Omnibus
I have a documented preference against omnibus proposals; Lumping Gerolamo, Pebble, and maintenance on existing libraries here is immediately distasteful for me.
That being said, the 3 projects likely have a high degree of overlap, and so I can see why pooling resources for them is valuable.
- My personal conflict of interest
If I'm being totally honest, I have a conflict of interest here. This is why, had I decided the balance of the above was pushing me towards a no, I likely would have voted Abstain instead. Michele and I do not get along, and I do not believe he engages in protocol level discussions in a healthy way. He escalates tensions, discounts hard work and analysis from smart thinkers if it doesn't align with his goals, and has a tendency to assume that if he can't see the utility in something, it doesn't exist.
Him and I are also building competing products with different priorities, which doesn't do either of us any favors in giving the other a benefit of the doubt.
(And if you're reading this, Michele, no, I'm not talking behind your back. I can't tag you in on-chain metadata, nor do I consider speaking publicly about you in a way consistent with feedback I've tried to share with you before to be 'talking behind your back', nor is it censorship to reserve my energy for interacting with people who don't exhaust me; Your accusations to this effect fall flat because I've never tried to hide how my opinion about you has evolved over time in response to your own behavior, even if that has been in public discussions with other people. For what it's worth, I don't bear you any ill will, and hope you're successful in your endeavors for the benefit of us all. I just don't have the energy to participate in the kind of energy-draining "proof-by-exhaustion" argumentation tactics that you sometimes resort to.)
In the end, however, the reason I have a framework to evaluate proposals is exactly to identify these personal biases, be transparent about them, and attempt to correct for them in the way I vote. I don't believe I believe all of the above reservations are valid, and still don't override the existential threat to Cardano that is our reliance on a single node.
You can find a larger writeup justifying my vote here.
- Feasibility
- Yes13.3M ₳Rationale
RCADA supports this treasury withdrawal proposal from Harmonic Laboratories (HLabs) as a high-impact infrastructure investment aligned with Cardano’s long-term decentralization, developer accessibility, and ecosystem resilience.
The proposal presents a coherent and well-structured funding request across three interrelated workstreams: Gerolamo (a TypeScript-based node implementation), Pebble (a developer-friendly smart contract language and tooling suite), and ongoing maintenance of critical TypeScript ecosystem libraries. While these components are bundled, we find that they form a vertically integrated and mutually reinforcing stack spanning infrastructure, developer experience, and ecosystem continuity. This distinguishes the proposal from broader multi-project bundles and supports its evaluation as a unified initiative.
From a governance and treasury perspective, the proposal demonstrates a mature and robust design. Funds are held in audited smart contract escrow, disbursements are milestone-based, and an independent oversight board with credible ecosystem representation has meaningful enforcement powers, including the ability to pause funding and co-sign releases. Importantly, unused funds are automatically returned to the treasury at contract expiry. These mechanisms provide strong safeguards against misuse and materially reduce execution risk.
We also recognize the strategic importance of the proposed deliverables. Gerolamo contributes directly to client diversity and decentralization, particularly through its light-node and browser-based capabilities. Pebble lowers the barrier to entry for a large pool of Web2 and EVM developers, expanding Cardano’s potential developer base without displacing existing tooling. Continued maintenance of foundational TypeScript libraries ensures ecosystem stability across protocol upgrades and reduces fragmentation risk. Collectively, these contributions align with the Cardano 2030 vision and represent meaningful public goods for the network.
That said, this proposal is not without concerns.
First, the inclusion of a 25% contingency buffer within the upfront funding ask raises important governance considerations. While the justification—accounting for uncertainty and optimism bias in complex R&D work—is reasonable, and while the escrow model ensures that these funds are not automatically disbursed, we remain cautious about the precedent this sets. Large pre-allocated contingencies, even when refundable, risk inflating treasury requests and reducing funding discipline over time. We strongly encourage future proposals to explore more conditional or milestone-triggered contingency mechanisms rather than incorporating significant buffers into the initial ask.
Second, although we find the bundling in this case to be justified due to the tight coupling of the three workstreams, we reiterate our general preference for modular governance actions wherever feasible. Bundling inherently limits DRep granularity in decision-making and should be applied carefully. This proposal sits at the acceptable boundary of that practice, but broader or less cohesive bundling approaches would likely not receive the same level of support.
In summary, RCADA views this proposal as meeting the bar for responsible treasury allocation: it is strategically aligned, technically credible, and supported by strong governance and oversight mechanisms. Our support should be interpreted as endorsement of this specific implementation and structure—not as blanket approval of bundled proposals or large upfront contingencies as a general standard.
We therefore vote YES, while signaling clearly that future proposals adopting similar patterns—particularly around contingency design—may face increased scrutiny and could result in an Abstain or No vote if not sufficiently justified or refined.
RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/
- Abstain12.1M ₳No rationale
- Yes10.9M ₳No rationale
- No10.8M ₳No rationale
- AbstainChanged10.4M ₳Rationale
I wanted to add a rational. Wasn't able to do this without changing my vote from Abstain to No. I will change to Abstain again
I can the advantage Gerolamo for non-tech people, easy onboarding for a light node. Different from other proposals. I would vote Yes if it was only for Gerolamo.
I cannot say (as I'm not a developer) Pebble, is advantageous or not. This is why I would prefer that the proposals be separated. I would vote Abstain on Pebble and Yes for Gerolamo.
Earlier votes
No3mo agoSuperseded
I wanted to add a rational. Wasn't able to do this without changing my vote from Abstain to No. I will change to Abstain again
I can the advantage Gerolamo for non-tech people, easy onboarding for a light node. Different from other proposals. I would vote Yes if it was only for Gerolamo.
I cannot say (as I'm not a developer) Pebble, is advantageous or not. This is why I would prefer that the proposals be separated. I would vote Abstain on Pebble and Yes for Gerolamo.
Abstain3mo agoSuperseded
- YesRevoted9.2M ₳History
Earlier votes
Yes3mo agoSuperseded
- Yes8.8M ₳Rationale
本提案に賛成します。本提案は、CardanoエコシステムにおけるTypeScript基盤ツールの継続保守に加え、Gerolamoによる軽量ノード実装の前進と、Pebbleによる開発者体験の拡充に向けた方向性を評価します。ハードフォーク対応を含む基盤整備はエコシステム全体の安定性に資すると考えられ、あわせて開発者層の拡大にもつながることから、本提案を支持します。\n\nI vote Yes on this proposal. I value that it supports the continued maintenance of core TypeScript infrastructure in the Cardano ecosystem, while also advancing Gerolamo as a lightweight node implementation and moving toward improving developer experience through Pebble. Hard-fork readiness and ongoing tooling support contribute to ecosystem stability, and lowering barriers for developers can expand participation. Given these factors, I support this proposal.
- Yes8.1M ₳No rationale
- YesRevoted7.6M ₳Rationale
A handful of things we get here that are of strategic importance in a tough market year for crypto. We get a new node implementation - production-ready light node Gerolamo that will allow DApps to run their own lightweight nodes. If Cardano light wallets are able to offer Daedalus-like security (I think it is a massive win), we might wake up thousands upon thousands of risk-averse Cardano holders from their long sleep and even bring over new risk averse crypto users.
We get a new programming language for smart contracts - pebble. With Cardano smart contracts being unique, lowering the hurdle brings competition and choice.
Third, we keep a competent infrastructure team actively working on key components of Cardano. Thus we gain more resilience and reduce dependency on one core provider. This directly helps ADA holders and the Treasury become less dependent one one core player. Competition and choice will lower costs and lower treasury outflows in the years ahead.
To quote a US president: In any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing. We need to take action in times of difficulty. This is likely to be no ordinary year.Earlier votes
Yes3mo agoSuperseded
- Yes6.4M ₳No rationale
- No6M ₳No rationale
- YesChanged5.9M ₳Rationale
My initial hesitation was around whether this directly drives near-term adoption and user growth. I still believe that’s the primary gap Cardano needs to solve, and that we need to be intentional about building stronger demand-side pipelines across the ecosystem.
That said, I also recognize that this proposal contributes to foundational capabilities that align with where we want the ecosystem to go—particularly around trustless access and developer experience.
This isn’t a shift away from my broader view that we need to prioritize adoption, but rather an acknowledgment that we can—and should—do both. Strengthening the foundation while building better pathways to users doesn’t have to be mutually exclusive.
Earlier votes
Abstain3mo agoSuperseded
I am voting Abstain.
This proposal is technically sound and budget-wise manageable. I do not view it as irresponsible from a treasury perspective. My hesitation is more strategic: I do not yet see how it changes anything meaningfully urgent for Cardano right now (the needed outcomes aren't aligned in my opinion).
Gerolamo, Pebble, and tooling maintenance may all be useful, but they read to me more as infrastructure and developer-capability expansions than as proposals that materially move users, growth, economic activity, or near-term developer demand. The key results are laid out fairly well, but they still feel more like technical outputs than ecosystem outcomes.
I have supported node diversity proposals such as Dingo and Amaru because those more directly advance client diversity and reduce single-client risk. This proposal is different. It may contribute to relay/light-node diversity and better tooling, but that is not the same strategic category to me - the outcome for the ecosystem (to me) just isn't there. "Nice to have, but not a need."
So this is not a No. I do not want to stand in the way if the broader ecosystem sees value here, especially given the manageable cost. But I cannot directly support it because I am not convinced it addresses Cardano’s most urgent priorities at this time. I think if we can address some other outcomes first - drive the user/economic growth - it'll help generate the demand for infrastructure that aids to more trust-less apps. Let's focus on generating demand to "pull" this type of infrastructure forward.
- No5.8M ₳No rationale
- Yes5.4M ₳No rationale
- Yes5.3M ₳Rationale
Great for node diversity. Pebble and Gerolamo also bring some really unique developer and user experiences that’ll help strengthen our ecosystem
- Yes5.3M ₳No rationale
- Yes4.8M ₳No rationale
- Yes4.8M ₳No rationale
- Yes4.7M ₳No rationale
- Yes4.6M ₳No rationale
- Yes4.4M ₳Rationale
Node diversity, light wallet infrastructure and an easy & efficient smart contract programming language. It's a YES from me!
- Yes4.2M ₳No rationale
- Yes4.1M ₳No rationale
- Yes4.1M ₳Rationale
[Portuguese]
Optamos por votar "SIM" nesta ação de governança "Pebble + Gerolamo - HLabs 2026 Budget" (gov_action1ky2j077de82par6f0hny5q56rpnn5hh0csfhrpzeq3hsk7s6vetqquz3scv), pois ela apresenta potencial para fortalecer a infraestrutura do ecossistema Cardano, ao investir em ferramentas desenvolvidas em linguagens amplamente utilizadas, como TypeScript/JavaScript. Essa abordagem contribui para reduzir dependências centralizadas e ampliar o acesso de desenvolvedores, ao utilizar tecnologias mais familiares e acessíveis. A combinação entre manutenção contínua, desenvolvimento de novas soluções — como um light node — e melhorias na experiência de desenvolvimento tende a impulsionar a resiliência, a descentralização e o crescimento sustentável da rede, estando alinhada às metas estratégicas de longo prazo da Cardano. Além disso, consideramos a proposta bem estruturada sob a ótica de governança e responsabilidade no uso dos recursos do tesouro. O texto apresenta mecanismos claros de transparência e controle, incluindo administração via contrato inteligente, prestação de contas pública, auditoria financeira, devolução de saldos remanescentes ao tesouro e uso restrito da contingência exclusivamente para mitigação de volatilidade de mercado.
[English]
We chose to vote "YES" on this governance action "Pebble + Gerolamo - HLabs 2026 Budget" (gov_action1ky2j077de82par6f0hny5q56rpnn5hh0csfhrpzeq3hsk7s6vetqquz3scv), as it has the potential to strengthen the Cardano ecosystem infrastructure by investing in tools built with widely adopted programming languages such as TypeScript/JavaScript. This approach helps reduce centralized dependencies and broadens developer accessibility by leveraging more familiar technologies. The combination of ongoing maintenance, new solutions — such as a light node — and improvements to the developer experience can enhance the network’s resilience, decentralization, and sustainable growth, while aligning with Cardano’s long-term strategic goals. Furthermore, we consider the proposal well grounded from a governance and treasury responsibility perspective. It outlines clear mechanisms for transparency and accountability, including smart contract-based fund management, public reporting, financial auditing, the return of unused funds to the treasury, and restricted use of contingency funds solely for mitigating market volatility. - No4M ₳No rationale
- Abstain3.8M ₳Rationale
This proposal is well-structured from a technical execution and financial control perspective, but it fails to establish a credible, evaluable return on investment (ROI) thesis.
As a result, the proposal cannot be properly valued. I will Abstain.
⸻
- Strength: Technical and Operational Clarity
The proposal demonstrates competence in two areas:
a. Technical Definition
• Clear articulation of what is being built (Pebble, Gerolamo)
• Defined responsibilities and delivery structure
• Consideration of service-level expectationsb. Financial Controls
• Mechanisms to manage disbursement
• Attention to fraud mitigation and accountabilityThese are necessary conditions for funding—but not sufficient.
⸻
- Core Deficiency: Absence of ROI Framework
The proposal emphasizes what will be built and how funds will be controlled, but does not adequately address:
What measurable value will be created for the ecosystem, and how that value justifies the cost.
Key gaps:
• No quantified or even directional estimate of ecosystem impact
• No clear articulation of who the end users are
• No evidence of demand (committed builders, partners, or adopters)
• No framework to measure success post-deploymentThe result is that:
• The investment (“I”) is explicit
• The return (“R”) is undefined⸻
- Public Goods vs. Utility Validation
The proposal implicitly positions these tools as public-utility infrastructure.
That raises specific evaluation requirements:
• Are these tools actually needed?
• What friction do they remove in the developer or user workflow?
• How many projects are currently blocked or constrained by the absence of these tools?
• Are there credible teams prepared to build on top of them?None of these questions are answered in a way that allows independent validation.
Without this, the “public good” framing becomes non-falsifiable—it cannot be tested, challenged, or benchmarked.
⸻
- Pricing Without Value Anchoring
The proposal includes a substantial funding request.
However:
• There is no benchmark against comparable tooling efforts
• No linkage between cost and expected ecosystem impact
• No scenario analysis (e.g., low / base / high adoption cases)This makes it impossible to determine whether the price is:
• Efficient
• Reasonable
• ExcessiveValuation requires both sides of the equation. Here, only cost is specified.
⸻
- Decision Logic
I am not voting “No” because:
• The proposal does not demonstrate that the investment is negative EV
• The technical work may have meritHowever, I cannot vote “Yes” because:
• The proposal does not demonstrate that the investment is positive EV
• The return cannot be independently assessedTherefore, the only logically consistent position is:
Abstain due to insufficient information to evaluate ROI.
⸻
- What Would Be Required for a “Yes”
A revised proposal would need to include:
• A clear ROI thesis (even if probabilistic)
• Defined target users and use cases
• Evidence of demand or committed adoption
• Measurable success metrics tied to ecosystem impact
• At least a directional value model (e.g., developer growth, transaction volume, TVL impact)⸻
Conclusion
This proposal meets baseline standards for execution and control, but fails at the level that matters most for Treasury allocation: value creation clarity.
Until the return case is made explicit and testable, capital allocation cannot be justified.
- Yes3.4M ₳No rationale
- YesChanged3.1M ₳Rationale
I originally voted no on this proposal only due to the low cost of ADA and the need to prioritize spending, however as it is now clear that IOG intends to raid the treasury every year for funding, alternative nodes are a top priority.
Without node diversity and a seriously reduced dependence on IOG, IOG will continue to hold the network and treasury hostage.
I therefore see this spending as excellent value and I hope that Pebble + Gerolamo get funded!
Earlier votes
No3mo agoSuperseded
While alternative nodes are important, given current market conditions for Cardano, I have to say no at this time. Spending needs to be on essentials only right now, and we already have two alternate nodes that are now being funded (and I only said yes to one of them myself).
When the value of ADA is higher ($1 or more), I'd be happy to vote yes for this proposal.
- Yes3M ₳No rationale
- YesChanged2.8M ₳Rationale
After careful consideration, I will be voting YES for this proposal.
There are many things I would of liked to see changed but ultimately the need to fund community led initiatives outweighs my concerns.
Earlier votes
Abstain3mo agoSuperseded
- Yes2.7M ₳No rationale
- Yes2.7M ₳No rationale
- Yes2.6M ₳Rationale
本提案は約10FTE（フルタイム換算人員）による中規模開発であり、Gerolamo（軽量ノード）、Pebble（新言語）、および既存ツール保守の3本柱から構成されています。中でもGerolamoは「誰でもノードになれる」環境を実現し、dAppやウォレットの中央依存を低減する重要な基盤技術です。これによりネットワークの分散性と耐障害性が向上し、Cardanoの理念に直接貢献します。また、この変化はSPOの役割を奪うものではなく、「ブロック生成という本質への純化」を促すものであり、長期的には信頼性と運用力に基づく健全な競争を生むと評価します。Pebbleについては採用不確実性はあるものの、TypeScript系開発者の参入を促す可能性があり、言語の適切な分散と開発者基盤拡大に寄与する点を評価します。以上より、本提案はリスクを伴いつつも中長期的価値が高く、強く支持します。
This proposal represents a mid-sized effort (~10 FTE) covering Gerolamo (light node), Pebble (new language), and tooling maintenance. Gerolamo is particularly important, as it enables a “node-for-everyone” model, reducing reliance on centralized infrastructure and strengthening decentralization and resilience. This does not weaken SPOs, but rather refines their role toward reliable block production and professional operation.
Pebble carries adoption uncertainty, but it has potential to attract TypeScript developers and support a healthy diversification of programming languages in the ecosystem.
Overall, while there are risks, the long-term strategic value is significant. I strongly support this proposal.
- Yes2.5M ₳No rationale
- Yes2.5M ₳Rationale
This helps realize our previous vision for light nodes - the browser is the easiest entry point. I think this is a valuable add.
- Yes2.3M ₳No rationale
- No2.3M ₳No rationale
- NoChanged2.1M ₳History
Earlier votes
Yes3mo agoSuperseded
- Yes2.1M ₳No rationale
- No2.1M ₳Rationale
NO — I support the strategic value of HLabs’ work on Gerolamo, Pebble and TypeScript ecosystem maintenance, and I believe these workstreams could materially improve Cardano’s decentralization, developer experience and infrastructure resilience. However, this Treasury Withdrawal does not clearly satisfy Article II, Section 7(4) of the current Cardano Constitution, which requires an allocation of ADA for periodic independent audits and oversight metrics. The proposed escrow and oversight board are strong safeguards, but they do not clearly replace the need for an explicit audit/oversight allocation in the funding request itself. Given the size of the request and the importance of maintaining clean Treasury standards, I am voting NO on this version while encouraging HLabs to resubmit with the constitutional gap addressed and clearer budget separation.
- Yes2M ₳No rationale
- Yes1.9M ₳No rationale
- No1.8M ₳Rationale
We don’t think the priority right now is to explore entirely new approaches beyond Plutus or to chase another alternative that is marginally better than Aiken.
From our perspective, the current bottleneck of Cardano is not developer tooling or the lack of new technical directions. The real issue is the lack of users. When there are not enough users, there is not enough incentive for developers to come and build.
We see this as a sequencing problem. The ecosystem needs to reach a certain level of adoption before expanding into new smart contract paradigms. At this stage, even a significantly better developer experience will not drive meaningful adoption if user demand is still weak.
It is also important to point out that the limited adoption of Plutus is not mainly due to its complexity. Developers are willing to learn difficult systems when the opportunity is large enough. What is missing today is that opportunity, because the number of active users is still too small.
We recognize that there are architectural limitations such as missing event systems, lack of standard ABI patterns, limited composability, and difficulties with data heavy or compute heavy use cases. These are real issues, but they are not the primary constraint holding back growth right now. They only become critical when the ecosystem reaches a scale where those limitations start to block real demand.
Our position is simple. We should focus on growing the user base and creating real demand first. Once that foundation is strong, developers will naturally follow, and more advanced technical approaches beyond Plutus will become both necessary and impactful.
- Abstain1.8M ₳No rationale
- No1.8M ₳Rationale
I am voting No on Pebble + Gerolamo – HLabs 2026 Budget. While I recognize the value of maintaining critical infrastructure and see some potential in Gerolamo, this proposal bundles essential maintenance with nice-to-have initiatives, making it difficult to justify the full ₳8M request. The cost structure, including high per-FTE compensation and contingency, appears disproportionate relative to the demonstrated needs and current adoption levels. Neither Gerolamo nor Pebble show sufficient evidence of immediate demand or ecosystem priority to warrant this level of investment at this time. Introducing additional node implementations and a new smart contract language also raises concerns about fragmentation and duplication of effort when existing tools are still maturing. I would be more supportive of a narrower, clearly scoped proposal focused on essential maintenance and proven needs, with expansion efforts evaluated independently and held to a higher standard of validation.
- Yes1.7M ₳No rationale