The first node in the browser; a Cardano USP
182 DReps voted · 73 with a rationale · 12 changed their vote
Open a row to read the rationale.
- No1.4M ₳No rationale
- No1.3M ₳No rationale
- Yes1.2M ₳No rationale
- Abstain1.1M ₳No rationale
- No1.1M ₳Rationale
The pitch is undeniably seductive: “a fully validating Cardano node in the browser” sounds like the sort of category-defining differentiator that makes conference stages purr. And yes, Cardano’s eUTxO architecture gives this idea more technical plausibility than most chains can honestly claim. I give the proposal that much. But plausibility is not yet treasury-worthiness, and Cardano governance should not confuse an elegant narrative with a proven necessity.
**
Treasury should fund indispensable commons, not merely fascinating engineering. This proposal may indeed produce useful code, research spillovers, and a compelling demo. But “could become foundational” is not the same as “must be treasury-funded now.” If the primary value is strategic optionality, ecosystem signaling, and future bridge/L2 relevance, then I want stronger evidence of demand pull, integration commitments, and why the private sector, partner co-funding, or a narrower scoped ask would not be the more prudent route.** - Yes964.1K ₳No rationale
- Yes948.9K ₳No rationale
- No931.8K ₳No rationale
- No861.5K ₳No rationale
- Yes825.2K ₳Rationale
Impact Assessment (Pros/Cons)
Pros
True Trust-Minimized Ecosystem: Currently, the vast majority of decentralized applications (dApps) and light wallets on Cardano rely on centralized indexers and backend APIs to query ledger states. Gerolamo eliminates these single points of failure by letting client applications verify transactions and UTxO sets directly within a web worker.Cardano-Only Structural Advantage: Cardano's unique eUTxO architecture allows local state verification. A browser node doesn’t need to hold the entire global ledger state to validate the exact transaction path it interacts with, providing a massive scalability and user experience advantage over account-based L1 platforms.
Client & Node Tier Diversity: Relying entirely on a single node implementation poses systemic risk. Adding a production-grade TypeScript/Wasm client client provides structural resilience to the tier handling user interactions.
Strong Strategic Alignment: The proposal natively meets the core benchmarks outlined in the Cardano 2030 Strategic Framework, specifically advancing "Ecosystem Growth & Real-world Adoption" by significantly lowering hurdles for light wallet providers.
Cons
Substantial Treasury Allocation: The request of ₳4,600,000 represents a major capital deployment from the global treasury.Technical and Maintenance Risks: Maintaining cross-era hard-fork compatibility inside a browser environment over a long period introduces complex up-keep requirements, placing high reliance on the sustained commitment of HLabs.
Final Recommendation
Vote: YES
Rationale
The implementation of a true browser-based node is a fundamental paradigm shift for client-side decentralization. While the capital layout is substantial, the milestone-driven framework, clear 5-FTE resource management, and alignment with the open-source ethos justify the investment. Crucially, this action builds upon previous governance feedback, bringing refined structural parameters and clear delivery indicators.Historical Coherence Check
Our previous stance regarding early technical architectures or tooling frameworks from HLabs leaned cautious (e.g., voting "No" on the Pebble + Gerolamo HLabs framework earlier in April 2026 due to budgetary/packaging parameters). However, this resubmitted, focused proposal presents distinct clarity, isolation of scope, and a strong risk-mitigated milestone schedule. Evolving technical alignment and structured accountability parameters warrant this transition to a YES vote.Latin American Ecosystem Impact
For Latin America, local web infrastructure and mobile-first limitations often restrict user interaction with fully sovereign full nodes due to high hardware overhead. By facilitating a secure, ultra-lightweight node that operates right inside consumer web browsers and web workers, Gerolamo vastly lowers the entry barrier for LatAm developers and everyday users. It enables localized dApps and light wallets to function securely without high-bandwidth infrastructure dependencies, amplifying true financial sovereignty and trustless web3 access across the region. - No798.6K ₳Rationale
The proposal frames an in-browser validating node as a critical decentralization investment. But Cardano already operates one of the most decentralized networks in the industry by meaningful measures: a large, globally distributed SPO set, multiple node client implementations in active development, and a governance model that is live and participatory. The marginal decentralization gain from a browser light node — whose own success metric is just 3 integrations — does not constitute an urgent need that justifies 4.6M ADA from a treasury under active spending constraint.
- Yes798.4K ₳Rationale
Voting YES. A fully validating Cardano node running directly in the browser is a genuinely differentiated infrastructure play that aligns strongly with Cardano’s architecture and decentralization goals. Beyond the UX narrative, the underlying work on lightweight validation and client diversity has meaningful long-term value for wallets, dApps, bridges, and L2 infrastructure.
- Yes794.5K ₳Rationale
I like the team and what they are trying to do here. I get there is some execution risk, and that even without this the node diversity roadmap has multiple avenues in progress. But this is also unique and compelling in terms of a competitive advantage that would make some noise.
- Yes717.5K ₳No rationale
- No705.1K ₳Rationale
No!
- Yes625.9K ₳Rationale
Ask: ₳4,600,000 FTE cost: $200K/year Duration: Q2 2026 – Q1 2027 (12 months) Oversight board: Santiago Carmuega, Lucas Rosa, Chris Gianelloni Gerolamo is genuinely differentiated infrastructure. Cardano's eUTxO design
A PDF version of this rationale is also made available.
I'm voting yes on Gerolamo for the same reason I voted yes on the combined proposal it was originally part of: a fully-validating browser node is something only Cardano can build without redesigning its base layer, and shipping it turns a latent architectural advantage into a competitive moat. Most Cardano wallets and dApps currently depend on centralized API providers to interact with the blockchain. That dependency reintroduces trust assumptions that decentralization is supposed to eliminate and it makes browser-based governance participation fragile in ways that matter to me directly. Gerolamo's browser extension, backed by its own validating node and exposing a CIP-30-style messaging API, removes that dependency at the application layer. A DRep with Gerolamo installed can verify chain state locally. A wallet can query UTxOs without asking Blockfrost. That's not a convenience feature; it's what "trustless" is supposed to mean in practice.
HLabs builds on its own production infrastructure here. The ouroboros-miniprotocols-ts library, the TypeScript implementation of Cardano's networking stack that Gerolamo's peer connectivity layer runs on is maintained by HLabs and in production use across the ecosystem. This team isn't learning how to implement mini-protocols in TypeScript; they wrote the library everyone else depends on. The browser-specific engineering challenges are real (IndexedDB performance, WebSocket proxy architecture, stable peer management across browser sessions) but these are solvable engineering problems, not open research questions. The M4 requirement of ≥15 stable peers maintained for ≥24 hours across ≥3 independent browser sessions with a non-Chromium screencast committed to the repo is a strong production-readiness bar.
At ₳4,600,000 (~$1.15M at $0.25), five FTEs at $200K annually with the best kickoff ratio in this batch (10% upfront, 90% against quarterly deliverables), the ask is appropriately scoped. The governance structure is the same dual-audited SundaeLabs escrow and same three-person oversight board with unilateral pause rights as the Pebble + tooling proposal. The public transaction journal and monthly status updates add a layer of transparency that exceeds anything else in this budget cycle. Separating Gerolamo from the combined proposal is better governance and it lets DReps evaluate each deliverable on its own merits and prevents a single component concern from blocking unrelated work. The merits here are clear. - No605.7K ₳Rationale
Voting: NO ❌
Harmonic Labs is asking for 4.6 million ADA from the Cardano treasury for the Gerolamo project — a browser-based light node for dApps and wallets.
The idea sounds attractive:
run a validating Cardano node directly inside the browser and reduce dependence on centralized RPC servers and APIs.But in reality, this looks like another expensive R&D experiment wrapped in decentralization marketing.
📌 My position is simple:
I vote NO.Cardano does not need another multi-million ADA research proposal with endless milestones, audits, reports, and FTE calculations.
The ecosystem needs:
— real adoption
— real users
— real liquidity
— real growth4.6 million ADA is a massive amount of treasury funds.
And what does the average ADA holder get right now?
Almost nothing.
No direct impact on adoption.
No major increase in network activity.
No meaningful benefit for the majority of users.Again:
roadmaps, committees, reports, oversight boards, milestones.A lot of presentations.
Very little real-world impact.The Cardano treasury should not become an endless ATM for teams constantly asking for millions before delivering meaningful ecosystem-wide results.
First results.
Then more funding.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 details: https://t.me/PROCENT666/338
#Cardano #ADA #DRep #CardanoGovernance #Web3 #Crypto #Blockchain #DeFi
- No590.5K ₳No rationale
- Yes589.7K ₳Rationale
I support this proposal because it develops a genuinely unique capability that few, if any, other blockchain ecosystems can realistically deliver: a fully validating Cardano node running directly in the browser, providing both meaningful decentralisation benefits and a powerful marketing differentiator that showcases Cardano’s architectural strengths in a tangible, user-facing way.
- Yes587.6K ₳No rationale
- No533.9K ₳Rationale
No node needed in the browser ATM.
- No499K ₳Rationale
- Yes487.7K ₳No rationale
- Yes478.3K ₳No rationale
- Yes466.2K ₳No rationale
- No442.9K ₳No rationale
- Yes438.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
- Yes381.1K ₳No rationale
- NoRevoted365.7K ₳History
Earlier votes
No2mo agoSuperseded
No2mo agoSuperseded
No2mo agoSuperseded
- No360.3K ₳No rationale
- Yes314.4K ₳Rationale
In line with my past vote, I'm voting YES for Gerolamo. This in-browser light node gives Cardano trustless on-device validation for dApps/wallets.
A PDF version of this rationale is also made available.
In line with my previous vote, I am voting YES for Gerolamo. Cardano uniquely benefits from an in-browser, fully-validating light node that allows wallets and dApps to verify data directly on-device without trusting centralized servers. While this phase focuses on client-side validation to contain costs, I strongly entertain the idea of this project evolving into a full block-producing client node during a secondary funding phase in 2027.
- No313.4K ₳No rationale
- Abstain300.6K ₳Rationale
Please, I need you to include in future proposals the same in PDF format. With so many proposals being uploaded per week, it is almost impossible for one person to read all of this. We need PDFs to use them in AI tools and analyze the information faster regarding what I look for in a proposal. For that reason, I vote No.
- Yes298.9K ₳Rationale
Voting YES on The first node in the browser; a Cardano USP
May 22nd 2026
Summary
The request comes from Harmonic Laboratories. In this proposal they are asking for a total of 4,600,000 ADA to develop Gerolamo which is a Cardano node running in the web browser.
Quote: This proposal funds Gerolamo, the first production-ready Cardano node that runs in the browser, at 5 FTE.
Conclusion
I think this is a great proposal. I voted for the previous hlabs budget and felt it a shame it did not pass (see that vote context here). I'm glad they've resubmitted and I hope we can get it across the line this time.
Signed,
William DoyleYour friendly neighbourhood DRep!
$computerman
drep1yfpgzfymq6tt9c684e7vzata8r5pl4w84fmrjqeztdqw0sgpzw3nt
@william00000010 on 𝕏
contact@williamdoyle.ca - No294.4K ₳No rationale
- NoChanged271.8K ₳History
Earlier votes
Yes2mo agoSuperseded
- Yes270.1K ₳Rationale
I am voting YES on “The first node in the browser; a Cardano USP.”
This proposal funds Gerolamo, a TypeScript implementation of a Cardano node scoped to a production‑ready browser‑extension light node that dApps and wallets can use for local, trust‑minimized validation instead of relying entirely on centralized RPC/indexer infrastructure. It directly advances the Cardano 2030 KPI for alternative full node clients and the “Security & Resilience → Client Diversity” objective by adding an independently developed client in a different runtime and footprint (browser/TypeScript) than the existing Haskell and Rust implementations.
The scope and budget are focused and reasonable for core infrastructure. The ask is 4,600,000 ADA (~USD 1.15M at 0.25), representing 5 FTE at USD 200k/year plus a 15% contingency. The rate is clearly defined as a company‑level rate that includes taxes, non‑developer staff, compliance, legal, and an independent financial audit, not just salaries. The work is strictly limited to the browser light‑node use case: full block production, SPO infrastructure, and server‑side relay roles are explicitly out of scope for this funding period, which keeps the mandate narrow and avoids overlapping with Amaru and other server‑side clients.
Deliverables and milestones are objective and user‑relevant. Over 12 months (Q2 2026–Q1 2027), the plan is to:
Implement full ledger rules and Praos chain selection in a browser‑compatible way, with state stored in IndexedDB and correct rollback handling.
Release a public browser extension (e.g., via Chrome Web Store) exposing a messaging API for basic and indexed queries (tip, UTxO by output reference, UTxOs by address/asset, plus transaction submission), along with a demo dApp that demonstrates these flows against a public testnet without any backend.
Achieve stability criteria: syncing from genesis to tip, maintaining ≥15 peers for extended periods, correct behaviour across rollbacks, and working in at least one non‑Chromium browser (e.g., Firefox or Safari).
Acceptance criteria are tied to tagged releases, sync logs, store listings, tests, screencasts, and public documentation, not self‑reported status, and production‑readiness is defined in terms of sync reliability, performance, peer connectivity, and rollback safety.
Governance, custody, and oversight are strong. Funds are held in SundaeLabs’ treasury.ak/vendor.ak contracts, audited and in production, with milestone‑based disbursement gated by an independent oversight board (TxPipe, Aiken/Midnight, BlinkLabs/Dingo) that can co‑sign releases, pause milestones, and help sweep unused funds back to the Treasury. The proposal includes an independent financial audit of fund flows (quarterly plus final), monthly public updates, quarterly detailed reports (technical and financial), and a transaction journal logging every on‑chain action tied to this GA. All escrowed ADA is delegated to the always‑abstain DRep and cannot be staked with SPOs; any remaining funds after expiry are automatically swept back to the Treasury at the contract level. The proposers also reference a 2025 retrospective on prior funding and delivery, which is important for continuity and accountability.
I acknowledge the concerns raised by some DReps about execution risk, demand visibility, and the number of concurrent node efforts. A fully validating browser node is technically challenging, and adoption by wallets and dApps will need to be earned over time. However, this proposal is one‑year, tightly scoped, and heavily milestone‑gated, with independent technical and financial oversight. It does not seek to fund another general‑purpose full node; it targets a unique niche that Cardano’s eUTxO design makes realistic: on‑device, browser‑based validation for dApps and light wallets. In my view, that is the kind of foundational, decentralization‑oriented infrastructure the treasury should support, especially when the ask is moderate and the accountability structure is strong.
For these reasons, I am comfortable voting YES on this proposal. - No261K ₳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.
Main reasons for voting NO
- Insufficient strategic priority
The proposal addresses infrastructure decentralization and additional network resilience, which are valuable objectives. However, I do not consider this initiative sufficiently urgent under the current treasury constraints. Cardano is already highly decentralized relative to most blockchain networks, while several existing ecosystem projects are struggling to maintain continuity or remain operational. In this context, I believe treasury resources should prioritize more immediate ecosystem needs rather than additional resilience for infrastructure that is already comparatively decentralized.
- Insufficient budget granularity
The budget is primarily presented through aggregated FTE rates of US$200,000 per year. If interpreted mainly as developer compensation, these rates would appear high even compared with expensive labor markets such as the United States. The proposal states that the rates include salaries, taxes, overhead, complementary personnel, compliance, legal expenses, and financial auditing, but it does not quantify these components separately. A dRep should not be required to infer the internal composition of a substantial treasury request. The burden of providing a sufficiently detailed and verifiable budget rests with the proposer.
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.
Principais motivos para o voto NÃO
- Prioridade estratégica insuficiente
A proposta aborda a descentralização da infraestrutura e o aumento da resiliência da rede, objetivos que possuem valor. No entanto, não considero esta iniciativa suficientemente urgente diante das atuais restrições orçamentárias do Tesouro. A Cardano já apresenta um elevado nível de descentralização quando comparada à maioria das outras blockchains, enquanto diversos projetos existentes no ecossistema enfrentam dificuldades para manter sua continuidade ou permanecer operacionais. Nesse contexto, considero mais apropriado priorizar necessidades imediatas do ecossistema em vez de financiar resiliência adicional para uma infraestrutura que já é comparativamente descentralizada.
- Granularidade orçamentária insuficiente
O orçamento é apresentado principalmente por meio de taxas agregadas de US$ 200 mil por FTE ao ano. Caso fossem interpretadas predominantemente como remuneração de desenvolvedores, essas taxas pareceriam elevadas até mesmo em comparação com mercados de trabalho caros, como o dos Estados Unidos. A proposta afirma que os valores incluem salários, impostos, despesas operacionais, pessoal complementar, compliance, custos jurídicos e auditoria financeira, mas não quantifica esses componentes separadamente. Não cabe ao dRep deduzir a composição interna de um pedido significativo ao Tesouro. O ônus de apresentar um orçamento suficientemente detalhado e verificável pertence ao proponente.
- Yes260.2K ₳No rationale
- Yes245.5K ₳Rationale
Sticking to my initial vote decision for this, and it's an even easier decision now that Pebble was separated: Three new nodes on the treasury payroll at once may seem like too many, however a browser-capable node is incredibly valuable. So for that alone, this has my support.
- 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.
- Treasury runway is shrinking rapidly and must be protected.
- No234.2K ₳No rationale
- Yes233.2K ₳No rationale
- Yes232.2K ₳No rationale
- Abstain215.5K ₳No rationale
- Yes207.6K ₳No rationale
- Abstain200.5K ₳No rationale
- Abstain191.9K ₳Rationale
not a techie, but this seems cool. we have a lot of node client teams, which is fantastic for the ecosystem. i can't make an expert assessment on whether we need this one too, so i'll abstain