Hito Zcash: Stable Firmware, Internal Security Review, and Maintenance

1. Executive summary and decision snapshot

Hito Inc requests $88,000 for four months of Zcash hardware-wallet firmware and mobile integration, testing, internal security review, and release, followed by 12 months of maintenance. Mikhail and Daniil Kirillov would deliver the engineering. Payments comprise development advances and monthly maintenance funding. The application is under review. [1][4]

The strongest capability evidence is the team’s detailed reporting of physical-device signing and Android transaction flows, including reported mainnet tests—not merely its previous grant’s approval. Evaluation inference: the key funding questions are whether unfinished earlier obligations are being funded twice, whether release assurance is adequate, and whether payment conditions preserve leverage through final acceptance. [7][4]

2. Applicant and team track record

Mikhail is Hito’s founder, project lead, and firmware/iOS engineer; Daniil covers firmware, Android, and device testing. Both are proposed full-time for development. Herb Stephens is listed as advisor and Denis Ivanov in operations. [1][4]

ZCG approved Hito’s first $50,000 grant in May 2026. Subsequent applicant reports describe Android hardware-account onboarding, offline transaction review and signing, and tested Orchard/Ironwood flows on physical hardware. Hito says ZCG accepted and paid the milestones; the supplied committee minutes independently establish approval, not final acceptance. [8][7][4]

Assessment: these reports support relevant implementation experience. No grounded evidence found for independently measured adoption, reliability in sustained use, or security outcomes.

3. Proposal scope, milestones, budget, technical approach, and dependencies

The approach replaces Slint with the public, MIT-licensed hito-ui, completes Zcash screen migration and Android/iOS integration, and stabilizes existing devices. Hito reports its Slint build consumes 98.8% of the allocated firmware flash region—not total device flash. Preliminary UI measurements are applicant-generated, uncontrolled, and do not establish whole-wallet savings. [4]

Dates assume November 1 funding and shift with funding or acceptance delays. [4]

Budget: integration $30,000; testing/review/fixes/release $30,000; tools $1,000; maintenance $27,000. Proposed advances are $15,000 at startup, $15,000 after M1, $16,000 after M2, and $15,000 at January’s checkpoint. No further engineering payment is due at February acceptance. Maintenance is $2,250 monthly for six combined engineer-days; tool spending is capped and unused funds reconciled under grant terms. [4]

Release requires passing required tests and resolving critical/high internal findings. Plans include malformed-input, interrupted-connection, upgrade, recovery, and repeated-signing tests; cross-engineer fix checks; reproducible unsigned builds; and a published report. Independent auditing, physical-attack testing, and full mobile-app audits are excluded. Least Authority discussions have no agreed scope, terms, or funding, and that audit is not a completion dependency. [4]

4. Community discussion, arguments, responses, and resolution

Current independent community arguments: No grounded evidence found. The supplied current discussion contains the applicant’s substantive case and clarifications, not an independently demonstrated consensus. [4]

• Strongest argument for, applicant’s position: functioning signing needs hardening, while measured UI constraints justify replacement. The applicant proposes staged integration, testing, and maintenance rather than manufacturing or distribution funding. [4]
• Strongest counterargument, evaluation inference: the first grant already covered UI, stabilization, documentation, and release. Hito acknowledges this overlap and says allocation of remaining work must be agreed with ZCG. This concern remains unresolved. [4]
• Capability concern and response: earlier committee discussion questioned small-team capacity and companion-wallet arrangements. Later Android demonstrations address the feasibility of a companion workflow, but do not establish the earlier-described Zodl integration; the renewal explicitly promises no Zodl integration or partner distribution. [8][7][4]
• Clarifications resolved at scope level: Hito explicitly distinguishes internal review from independent audit, limits its benchmark claims, and says the integration budget does not repay completed Ironwood or hito-ui work. These clarify the offer, without independently validating performance or security. [4]

5. Relevant precedents and documented outcomes

• Zaino—Stability, Performance & Testing, $50,000: relevant to follow-on hardening after broader development funding. ZCG approved it because the work was specific, considered nonduplicative, and had communicated upstream readiness. Completion is recorded, but No grounded evidence found for measured post-delivery performance outcomes; that label alone does not establish impact. [9]
• ChainSafe maintenance, $168,000: relevant to a first maintenance year following implementation. Approval emphasized support absent from the original grant and monthly payments capped by completed work. Later committee discussion documented delayed maintenance and protocol updates that reportedly left dependent wallets unusable temporarily—substantive evidence that maintenance funding did not ensure timely service. [10][11]
• ChainSafe maintenance renewal, $168,000, declined: directly relevant to renewal value and accountability. Committee reasons included slow responses to reported problems and preference for targeted, user-driven fixes or bounties rather than indefinite maintenance funding. Inference: Hito’s maintenance evaluation should emphasize responsiveness and delivered fixes, not continuity alone. [11]

6. Material risks and execution considerations

• Payment exposure—inference: all $61,000 of engineering/tool funding would be advanced before final release acceptance, weakening the financial incentive at the last delivery gate. [4]
• Capacity concentration—inference: two engineers cover firmware, two mobile platforms, testing, review, and fixes. Cross-checking improves accountability but leaves limited independent review capacity or staffing redundancy. [4]
• Maintenance boundary—inference: six combined engineer-days monthly may not accommodate urgent compatibility work, while major upgrades are excluded. Unclear escalation arrangements could turn protocol changes into service gaps or additional funding requests. [4]
• Reach—inference: excluding manufacturing and distribution limits what this grant can establish about availability to users; it funds software readiness, not deployment at scale. [1][4]

7. Material gaps and questions for the applicant

• Which unfinished tasks remain obligations of the first grant, and what credit or funding adjustment will prevent duplicate payment? [4]
• Will Hito accept a final-release holdback, and who will validate each milestone independently of the engineering team? [4]
• What numerical thresholds define acceptable full-flow memory use, responsiveness, repeated-signing reliability, and Android/iOS parity on all five devices? [4]
• What user-release restrictions or disclosures apply before independent auditing, and what findings would halt release despite schedule pressure? [4]
• What response times, urgent-fix capacity, and protocol-upgrade responsibilities apply within the maintenance allowance? [4]
• How many users or integrators are ready to test and use the release, and what evidence would demonstrate grant value beyond successful transactions? The supplied history reports transaction functionality, not adoption. [7]

8. Neutral decision considerations

Committee options, not an approval or rejection recommendation:

• Assess engineering and maintenance separately, with maintenance contingent on accepted release.
• Consider explicit prior-scope settlement, measurable acceptance tests, and a final-payment holdback.
• Distinguish acceptance as an internally reviewed release from assurance suitable for broader deployment.
• Evaluate capped monthly support against a targeted-fix alternative.

These are possible funding conditions addressing the proposal’s advance-payment structure, acknowledged scope overlap, review boundaries, and maintenance limits—not documented agreements. [4]

9. Numbered source list

• [1] Grant Application - Hito Zcash: Stable Firmware, Internal Security Review, and Maintenance — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/468
• [4] Hito Zcash: Stable Firmware, Internal Security Review, and Maintenance — posts 1–5 — https://forum.zcashcommunity.com/t/hito-zcash-stable-firmware-internal-security-review-and-maintenance/58051/1
• [7] Grant Application - Hito Hardware Wallet - Zcash Cold Signing (Orchard) — posts 16–20 — https://forum.zcashcommunity.com/t/grant-application-hito-hardware-wallet-zcash-cold-signing-orchard/55539/16
• [8] Hito - decision minutes — https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-5-11-2026/55677
• [9] zaino - Stability, Performance & Testing — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/328
• [10] ChainSafe Systems — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/2
• [11] ChainSafe #3 - Zcash Metamask Snap and Webzjs maintenance renewal — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/272