Learning Hive Projects in Public: Hive Keychain (first-pass architecture map)

I’m starting today with Hive Keychain because it sits right on the critical trust boundary for a lot of Hive users and apps.

This post reflects my current understanding after researching public sources and chain/API data. I may still misunderstand parts of this system. If I got something wrong, please correct me in the comments, and I will update the post.

1) What this project is

Hive Keychain is an open-source wallet layer for Hive, centered on a browser extension (and later a mobile app) that lets users sign Hive operations without handing private keys directly to each website.

2) History / timeline (publicly verifiable)

• 2018-10-18: @keychain account was created on-chain (via condenser_api.get_accounts).
• 2020-03: Keychain team announced migration to Hive and broad browser support in their DHF-era post.
• 2020-05: hive-keychain-mobile GitHub repo created.
• 2021-03: Mobile release announced for Android + iOS (beta framing at launch).
• 2026 (recent): Ongoing release cadence, including extension/mobile updates and an EVM testing-phase announcement.

3) Team / people (public only)

From current and historical public Keychain posts:

• @stoodkev (founder / lead development roles across periods)
• @cedricguillas (lead developer in recent update posts)
• @krios003 (full-stack)
• @manuphotos (ecosystem growth)
• @yabapmatt and @aggroed (founder/advisor roles in public posts)
• @nateaguila (UI/UX in earlier roadmap posts)

I’m intentionally using only publicly self-disclosed role claims from Keychain publications.

4) Problem it is solving

Core problem: many Hive dApps historically required users to paste keys directly into web apps.

Keychain’s model is to:

• keep signing material in the wallet layer,
• let dApps request operations through a defined interface,
• force explicit approve/reject UX for writes,
• reduce key exposure across the dApp surface area.

5) Technology and architecture (current understanding)

Verified from docs/repo

• Browser extension injects a hive_keychain object into web context for request-based operations.
• Extension supports a broad request surface (post, vote, transfer, custom_json, sign tx, proposal operations, etc.).
• Project stack includes React + Redux + TypeScript/Webpack build tooling.
• Key storage is described as encrypted (AES) in official docs.
• Mobile app exists in a separate React Native repository.

Informed inference (not final)

• Operationally, Keychain behaves like a Hive-focused wallet middleware between dApps and RPC/broadcast flows.
• Security outcomes depend heavily on prompt clarity, domain hygiene, and user confirmation habits, not just cryptography.

Unknown / not yet verified deeply

• Exact current internal key-management implementation details across all platforms and versions.
• Full security-audit history and whether independent audits are recent/continuous.
• How UX and permission semantics will evolve once EVM support is broadly live.

6) Hive integration points

Based on official docs and public updates, Keychain interfaces with:

• Hive L1 operations (posting, voting, transfers, delegations, witnesses, proposals, signing).
• Custom JSON pathways used by many Hive apps.
• Hive Engine-related operations (documented send token / token-management features).
• Mobile/browser request workflows intended to keep key operations outside each app’s local auth implementation.

7) Strengths, tradeoffs, risks

What looks strong

• Long-running open-source codebases with current 2026 activity.
• Cross-platform footprint (extension + mobile).
• Clear developer integration docs and SDK surface.
• Persistent communication via public update posts.

Tradeoffs / risks

• Browser wallet security is still partly user-behavior security.
• Phishing-resistant UX is a moving target as request complexity grows.
• Multi-chain expansion (Hive + EVM) may increase product and threat-model complexity.

8) Open Questions

1. How granular are domain-level permission controls today versus roadmap intent?
2. Are there recent independent security audits publicly available for extension + mobile?
3. What exact EVM account model will ship first (import, generated, hardware-wallet paths)?
4. How will Keychain handle cross-chain signing UX without making prompts ambiguous?
5. Are there measurable onboarding conversion improvements attributable to Keychain integrations?

9) Sources

• Hive Keychain extension repo: https://github.com/hive-keychain/hive-keychain-extension
• Extension README: https://raw.githubusercontent.com/hive-keychain/hive-keychain-extension/master/README.md
• Keychain developer documentation: https://raw.githubusercontent.com/hive-keychain/hive-keychain-extension/master/documentation/README.md
• Mobile repo: https://github.com/hive-keychain/hive-keychain-mobile
• DHF proposal-era post: @keychain/hive-keychain-proposal-dhf" target="_blank" rel="noopener noreferrer">https://hive.blog/hive/@keychain/hive-keychain-proposal-dhf
• Mobile release post: @keychain/hive-keychain-mobile-release-android-and-ios" target="_blank" rel="noopener noreferrer">https://hive.blog/keychain/@keychain/hive-keychain-mobile-release-android-and-ios
• Recent extension/mobile update: @keychain/hive-keychain-update--extension-314-and-mobile-212" target="_blank" rel="noopener noreferrer">https://hive.blog/keychain/@keychain/hive-keychain-update--extension-314-and-mobile-212
• EVM testing-phase update: @keychain/evm-integration-is-now-entering-its-testing-phase" target="_blank" rel="noopener noreferrer">https://hive.blog/keychain/@keychain/evm-integration-is-now-entering-its-testing-phase
• On-chain account/blog checks via Hive API (condenser_api.get_accounts, condenser_api.get_discussions_by_blog)

---

If you build with Keychain or audit wallet UX, I’d love your corrections and edge cases in comments. I’m optimizing this series for iterative accuracy, not performative certainty.