Withdraw 1,310,960 ada for Hardware Wallet Maintenance 2026
158 DReps voted · 51 with a rationale · 3 changed their vote
Open a row to read the rationale.
- No1.1M ₳Rationale
Keeping hardware wallets well-maintained is important for Cardano’s security and for building user trust, especially as Ledger and Trezor continue to develop. Even more so after the recent SecondFi hack.
However, ₳1.3M looks more like a recurring expense than a smart investment. The proposal falls short on showing any signs of innovation or efficiency improvements. Are we just paying for basic upkeep, or are we really advancing hardware wallet integration and making them more resilient? Given Cardano’s unique UTxO model and Layer 2 goals, we need hardware wallet solutions that are not just well-maintained but are also future-proof and compatible with newer tech beyond the old vendors.
Maintenance is important, but I'm not known for writing a blank check without enough strategic thought or innovation.
- Yes1M ₳No rationale
- Yes988.7K ₳Rationale
We vote YES on this proposal because hardware wallet support is a security-critical part of the Cardano ecosystem. Many users rely on Ledger and Trezor devices for secure signing, staking, governance participation, DeFi interactions, and long-term custody of ADA and Cardano native assets. If hardware wallet compatibility breaks due to Cardano protocol upgrades, vendor firmware changes, or evolving wallet and dApp requirements, users and integrators can lose reliable access to essential functionality.
This proposal is not about funding a new wallet product. It is about maintaining an already proven and important access layer for the ecosystem. Reliable hardware wallet support improves security, user trust, developer experience, and adoption. Given the focused scope, the moderate budget, and the importance of keeping secure signing infrastructure operational, we believe this is a sensible and necessary treasury investment.
- Yes988.4K ₳No rationale
- Yes964.5K ₳No rationale
- Yes924.2K ₳No rationale
- Yes881.9K ₳No rationale
- Yes870.4K ₳No rationale
- Yes862K ₳No rationale
- Yes830.3K ₳Rationale
We support Intersect's budget process. This proposal is part of it.
- Yes799.1K ₳No rationale
- Yes795K ₳No rationale
- Yes626K ₳Rationale
Voting YES. Hardware-wallet maintenance is essential security infrastructure, broken Ledger or Trezor support means stranded funds and forced migrations. ₳1.31M for 12 months across both integrations is proportionate. Proven team, clear scope. Transparency gaps noted but not blocking.
A PDF version of this rationale is also made available.
This proposal funds 12 months of maintenance for Cardano's hardware-wallet support: Ledger and Trezor compatibility updates, cardano-hw-cli and supporting libraries, developer support for ecosystem integrators, and vendor-required security audits.
Hardware wallets are not a luxury feature they are the primary security layer for serious Cardano users. If Ledger or Trezor firmware updates break Cardano support, users lose secure signing, large holders face forced migrations, and the ecosystem's credibility suffers. This is maintenance of existing, proven infrastructure.
The ask at ₳1.31M is proportionate for maintaining two major hardware-wallet integrations across a 12-month protocol evolution cycle. The team has prior funding and delivery history. The public value is clear and immediate.
Same transparency concerns as other Intersect proposals (thin budget, no ADA volatility policy, invisible milestones), but at this scale and for this function, they are manageable.
Hardware-wallet maintenance is not glamorous, but it is essential. Ledger and Trezor support is the primary security layer for serious Cardano users, and without continuous maintenance, it breaks as protocols and firmware evolve. The consequences like stranded funds, user attrition, reputational damage, and push toward centralized custody, are severe and avoidable.
This proposal asks for a modest amount (₳1.31M) to maintain proven infrastructure for 12 months. The team has a track record. The scope is disciplined. The public value is immediate and clear.
I note the same transparency gaps that appear across Intersect-administered proposals: thin budget detail, no ADA volatility policy, and invisible milestones. At this scale, they are concerns but not blockers. I also raise a longer-term sustainability question: hardware-wallet vendors should eventually bear more of this cost. But that transition is not today's problem. For now, the value justifies the vote. - Abstain620K ₳No rationale
- Yes608.1K ₳No rationale
- Yes590K ₳Rationale
Wallets gotta be maintained. Supporting withdrawal
- No587.6K ₳No rationale
- Yes535.2K ₳Rationale
Enhancing security with harware wallet maintenance is critical. Secure and safe systems is what we must have if we really want to change the world.
- Yes480.2K ₳No rationale
- Yes444.7K ₳No rationale
- Yes431.9K ₳No rationale
- No415.3K ₳No rationale
- Yes377.7K ₳Rationale
Hardware wallet support is a basic infrastructure requirement for the Cardano ecosystem. And it is hard to do in a for-profit way. So, this is a prime example of what the treasury is for.
- No365.9K ₳No rationale
- No360.4K ₳No rationale
- No321.3K ₳Rationale
Lately I'am seeing companies like Ledger requesting funds to support Cardano. However should the burden be up to them? They are selling hardware wallet for blockchains, it should be their prerogative to support at least the major chains, otherwise why should I buy their products?!? Panda feels conflicted
- No309.6K ₳Rationale
Review Methodology Disclaimer [EN]
Due not only to the unusually high volume of Treasury Withdrawal Governance Actions and budget proposals submitted in mid 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 - Hardware Wallet Maintenance 2026
1. Introduction
This Treasury Withdrawal funds Hardware Wallet Maintenance 2026. It requests 12 months of funding for production maintenance of Cardano hardware-wallet support: Ledger and Trezor compatibility updates, maintenance of supporting interoperability libraries and
cardano-hw-cli, developer support for ecosystem integrators, support for integration paths involving externally maintained components where shared hardware-wallet flows intersect, and vendor-required product or security audits where firmware or app changes trigger them. This is a continuity proposal for an already-proven Cardano access layer, not a request to build a new wallet product. The requested budget is 1,310,960 ADA, equivalent to USD 314,630 at an ADA/USD conversion rate of USD 0.24. VacuumLabs is the proposer and Intersect is the administrator. The delivery model is capped time and materials, with milestone claims every eight weeks, public progress reporting, and evidence-backed acceptance. Any portion of the approved cap not consumed by delivered work will remain unclaimed, and any audit reserve not required by vendor-triggered audit conditions will not be drawn.2. Governance Action Analysis
Positive aspects
The maintenance of hardware-wallet integrations has evident strategic importance for the Cardano ecosystem. Compatibility with devices such as Ledger and Trezor is not merely a convenience for individual users, but forms part of a sensitive layer of security, custody, and network access. If these integrations fail to keep pace with Cardano protocol updates, firmware changes, new device models, or changes to manufacturers’ applications, users may face difficulties signing transactions, moving assets, participating in governance, or interacting with wallets and decentralized applications.
For this reason, there is relevant alignment with Cardano Vision 2030. Primary alignment is with Pillar 1, Infrastructure & Research Excellence, because the work seeks to preserve security, interoperability, reliability, and operational continuity. There is also secondary alignment with Pillar 2, Adoption & Utility, because a secure and compatible user experience is a necessary condition for users and applications to use Cardano in practice. Hardware-wallet infrastructure that ceases to function properly harms both existing users and the development of new integrations.
VacuumLabs’ specific experience must also be recognized. The company states that it has worked with Cardano hardware-wallet integrations since 2018 and maintains components related to Ledger, Trezor,
cardano-hw-cli, and interoperability libraries. Agora is not aware of another team that currently performs the same function comprehensively within the ecosystem. This does not establish that VacuumLabs is technically the only team capable of performing the work, but it demonstrates that, in practice, there is a relevant dependency on its accumulated knowledge and operational continuity.The preventive nature of the maintenance must also be recognized: correcting incompatibilities before they affect users may be safer and less costly than reacting only after a production failure.
Another favorable aspect is that blockchain ecosystems funding hardware-wallet integrations does not appear to be unique to Cardano. There are examples of foundations, grant programs, and community funds from other networks financing the development or maintenance of applications and integrations for Ledger and other devices. Therefore, it would not be correct to reject the proposal solely on the argument that a blockchain should never fund this type of work. In some cases, this is protocol-specific infrastructure that would not be economically maintained by the manufacturer without some support from the interested ecosystem.
The proposal’s financial model also includes some protections. The work follows a capped time-and-materials model rather than constituting an automatic entitlement to receive the entire approved amount. The proposal states that unused capacity will remain undrawn and that the audit reserve will not be consumed if no audit is required. Accountability cycles are also planned every eight weeks, presenting hours consumed, pull requests, releases, tests, fixes, documentation, and any audit evidence. These mechanisms partially reduce the risk of full payment for work that was not actually performed.
Negative aspects
Despite these merits, an institutional issue is not adequately explained. Ledger and Trezor are commercial, for-profit companies. Their products are sold to users who wish to store and move various assets, including ADA and Cardano Native Tokens. Although the available information does not make it possible to determine what portion of their sales comes specifically from Cardano users, it is reasonable to state that these users generate revenue for the manufacturers.
For this reason, there should be a clearer explanation of the division of responsibilities and costs. It is not sufficiently demonstrated how much of the work is financed directly by Ledger or Trezor, how much is performed by employees of those companies, how much is VacuumLabs’ technical responsibility, and how much must be subsidized by the Cardano Treasury. It is also unclear whether there is any form of co-funding or contribution from the manufacturers.
If the Cardano ecosystem fully funds all updates, fixes, tests, integrations, and audits required for commercial products to continue functioning, a comfortable situation is created for the manufacturers: compatibility-specific expenses may be socialized while sales revenue remains private. This does not mean that no Treasury contribution is legitimate. It only means that funding should be accompanied by transparency regarding which responsibilities are public, which are commercial, and why the Treasury should assume a particular share.
The proposal should distinguish, for example, between maintenance of Cardano-side components that function as public infrastructure, changes required within manufacturers’ applications, support requested by commercial wallets, specific third-party integrations, and audits imposed by the vendors themselves. Without this separation, it is not possible to understand whether the Treasury is funding an indispensable public good, subsidizing obligations of private companies, or doing both simultaneously.
However, this is not the main reason for the opposing vote. The decisive objection is the lack of budget granularity.
The budget divides development costs into only two broad items. The first allocates 845,208 ADA, equivalent to approximately USD 202,850, for 156 person-days of compatibility updates, release engineering, and integration maintenance. The second allocates 281,736 ADA, equivalent to approximately USD 67,617, for 52 person-days of incident response, developer support, and partner integration support. Together, these items represent 208 person-days, presented as 0.8 annualized FTE. There is also a USD 35,000 reserve for external audits and the Intersect administration fee.
This information provides some quantification, but remains too superficial for an adequate value-for-money evaluation. The proposal does not state how many people will work on it, what roles they will perform, the seniority of each professional, how much time will be allocated to development, support, management, coordination, or testing, or the hourly or daily rate for each category.
It is also not explained whether the amount includes corporate overhead, profit, administrative management, incident availability, charges, equipment, or other expenses. It is not possible to identify whether the 208 person-days correspond predominantly to the work of highly specialized senior developers, a combination of professionals with different experience levels, or a broader team structure.
Using eight hours per person-day solely as an estimate, the 208 days would correspond to 1,664 hours. The USD 270,467 allocated to the two development items would result in an approximate implicit cost of USD 162.54 per hour, or about USD 1,300 per person-day.
This amount cannot automatically be interpreted as an individual salary. It may represent a blended rate that includes salaries, charges, administration, corporate profit, management, and other costs. However, this is precisely the problem: the proposal does not provide enough information to determine what the amount represents.
The implicit hourly rate appears high and has already been questioned by other dReps, but there is not enough data to conclude definitively that it is inflated. There is also not enough data to conclude that it is reasonable. The lack of granularity prevents both proper validation and proper challenge of the budget.
Merely stating 0.6 FTE for one broad set of activities and 0.2 FTE for another does not permit evaluation of allocation efficiency. It is unknown whether one person will work part-time throughout the year, several people will work during different periods, a team will remain available on demand, or some combination of these models will be used. The historical volume of incidents and updates that justifies this capacity is also unknown.
A comparison with the previous cycle should be presented: approved budget, amount actually consumed, number of people involved, hours used, releases produced, incidents handled, audits performed, and scope delivered. Without this basis, it is not possible to determine whether the 208 person-days represent a realistic projection, an excessive reserve, or a reduction compared with the previous effort.
The milestones also do not resolve this deficiency. The six eight-week cycles present practically the same deliverables and completion criteria. All contain generic references to pull requests, releases, fixes, tests, reports, audits where applicable, and budget consumption. This structure may make sense for unpredictable maintenance, but it does not establish sufficiently specific commitments before execution.
The proposal mentions incident response, remediation time, compatibility coverage, and audit turnaround, but does not define concrete targets. There is no specific response time for priority incidents, maximum mitigation period, minimum coverage of devices and versions, expected number of releases, or defined window for completing audits. The indicators are relevant, but remain without clear thresholds for success or failure.
Risks and concerns
The dependency on VacuumLabs increases the risk of not funding any form of maintenance. Abruptly interrupting the work without an alternative team prepared could create an operational gap. If incompatible changes occur in the protocol or manufacturers’ products, there may be no other provider immediately able to respond, test, coordinate audits, and publish updates.
In its current version, it is not possible to determine whether the requested amounts correspond to acceptable market prices, include an excessive margin, whether the projected capacity is proportional to demand, or whether some costs should be borne by the commercial manufacturers. The information asymmetry is too significant for public resources to be approved safely.
3. Vote and Rationale
Vote: NO
The position is not opposed to hardware-wallet maintenance, to VacuumLabs as a team, or to the principle of using the Treasury to fund strategic infrastructure. The proposal has potential value, strategic alignment, and a plausible continuity justification. Other ecosystems also fund similar work, and abandoning a security layer without an operational alternative would be risky.
The decisive objection is the lack of budget granularity. The strategic importance of the work does not remove the obligation to justify its price, and classification as critical infrastructure cannot authorize approval of a budget without sufficient information about its composition. The vote is conditioned on the insufficiency of the information provided and is not a definitive rejection of the work.
The vote would be converted to YES if a more granular budget were provided, containing at least the team composition, roles, seniority levels, hours or days by activity, hourly or daily rates, applicable overhead, demand estimates, a comparison with the previous cycle, and an explanation of the division of costs among VacuumLabs, Ledger, Trezor, and the Cardano ecosystem. If that documentation demonstrated that compensation is within reasonable market parameters and that there is no unjustified cost inflation, the proposal’s strategic relevance would be sufficient to justify approval.
4. Conclusion
The strategic importance of hardware-wallet maintenance does not compensate for the inability to evaluate the budget adequately. Until the requested costs, projected capacity, market parameters, and division of responsibilities with commercial manufacturers are demonstrated with sufficient granularity, the information asymmetry remains too significant for approval of public resources.
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 no meio 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 capa
- Yes299.1K ₳Rationale
HW wallet support needs some attention. There are many limitations detailed in CIP-21 I would like to see addressed. Personally I would really like HW wallets to be able to cast multiple votes in a single transaction.
- No298.3K ₳No rationale
- Yes271.8K ₳No rationale
- Yes270.3K ₳Rationale
I am voting YES because this is a continuity request for a critical security and compatibility layer rather than a speculative new product build. Cardano hardware-wallet support for Ledger and Trezor must be maintained continuously as Cardano, vendor firmware, and integrations evolve, or users and ecosystem integrators will lose secure access when breaking changes occur.
VacuumLabs is a credible vendor for this work, with an established track record on Cardano hardware-wallet integrations, cardano-hw-cli, AdaLite hardware-wallet support, and prior upgrade-readiness work. The scope is bounded around compatibility maintenance, supporting libraries and tooling, integration support, and vendor-triggered audit work, and the funding is structured as capped T&M with clear milestones, evidence, and reconciliation language rather than an open-ended entitlement.
- Yes260.4K ₳No rationale
- Yes246.1K ₳Rationale
I'd like this to be the last time we fund this maintenance. I understand that Cardano's transaction volume has been lower than some other blockchains that have this hardware wallet support - and that is falsely used to measure user interest in the blockchain - but Cardano does have a very high number of real humans storing real assets on hardware wallets, versus other chains where most users are bots or people using temporary hot wallets for quick on/off-ramping. Cardano does bring these hardware wallet companies a lot of real business through sales, so in the near future it needs to become their own responsibility to keep up with the chain's growth and developments if they'd like to keep all of those paying customers.
- Yes215.5K ₳No rationale
- Yes196.1K ₳No rationale
- Yes194K ₳No rationale
- Yes191.2K ₳No rationale
- Yes182.3K ₳No rationale
- Yes180K ₳No rationale
- No167.9K ₳No rationale
- No162.9K ₳No rationale
- No157.4K ₳Rationale
- Wasn't clear to me why for profit hardware wallet companies rely on ADA treasury for maintenance.
- Treasury runway is shrinking rapidly and must be protected. The 350M ADA 2026-27 NCL already risks ~21% 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, especially RWAs and revenue generating applications that commit to direct revenue or ADA return mechanisms back to the treasury, with clear milestones, private co-funding, and proven traction. Target specific tech unlocks only when tightly tied to measurable adoption impact. This builds real value without creating dependency.
- Yes142.6K ₳No rationale
- Yes137.5K ₳No rationale
- Yes131.9K ₳No rationale
- Yes129.3K ₳No rationale
- YesRevoted123.8K ₳History
Earlier votes
Yes24d agoSuperseded
- Yes63.3K ₳No rationale
- Yes56K ₳No rationale
- No50.5K ₳No rationale