Lockbox: Sovereign Credential Management on Solana
My password manager just won a rare honorable mention at the largest crypto hackathon
I spent the last quarter of 2025 building something that grew out of a straightforward observation: every mainstream password manager still depends on centralized infrastructure and recurring fees, and even the “self‑hosted” or “zero‑knowledge” options force people to manage a second, separate set of encryption keys on top of their wallet keys. That model clashes with what blockchains are supposed to offer. It fragments a user’s security posture, increases the number of ways things can go wrong, and forces people to juggle multiple critical secrets just to keep access to their own data. Not ideal.
When I considered how credential management could look given the unique advantages of a decentralized network like Solana, the existing approaches suddenly seemed inadequate. The result was Lockbox, a protocol for secure, recoverable credential management that lives entirely on-chain with zero central servers, zero subscriptions, and no mandated user interface.
Lockbox just received a coveted honorable mention at the Solana Cypherpunk Hackathon, the largest crypto hackathon on record.
This breakdown walks through what we built, why the hackathon itself demonstrates the scale of innovation happening in the Solana ecosystem, what technical approaches make Lockbox distinct, and why this kind of work matters for my own analytical practice.
Hackathon Scale & Winners
While I led Lockbox’s design and implementation, my partner, Jason Schorr, provided targeted implementation guidance, drawing on his experience as an Ecosystem Engineer at the Solana Foundation and his work with other companies in the broader Solana ecosystem.
To be honest, I was initially intimidated to compete when Jason suggested submitting my app to the hackathon (which I only learned about after building the initial prototype), but he saw the vision, and I am glad he pushed for it.
Solana is a blockchain network that processes transactions far faster and cheaper than Bitcoin or Ethereum. It's not some niche experiment anymore: Visa partnered with Solana to build payment infrastructure on the network, signaling that major financial institutions see real utility in what Solana can do. The nonprofit Solana Foundation and this hackathon’s commercial sponsors, such as Phantom, Arcium, Forward Industries, Raydium, Reflect, and Triton, organize these recurring coding competitions to identify the next wave of products that could strengthen the ecosystem.
The sheer numbers around Cypherpunk matter because they signal something very real about developer momentum in the Solana ecosystem. More than 9,000 participants from 150+ countries submitted 1,576 final projects across six tracks: Infrastructure, Consumer, DeFi, Stablecoins, Real World Assets, and Undefined Applications.
That volume made Cypherpunk the largest crypto hackathon to date.
Solana Breakpoint is the main industry event where the ecosystem gathers each year to see what builders have actually shipped. The Cypherpunk Hackathon winners were announced there, which meant the top projects had a real audience watching: other developers, founders with capital, and people who actually understand what good technical work looks like.
It’s the kind of stage where a project either lands or it doesn’t, depending on whether you’ve built something that solves a real problem.
We received an honorable mention in the “Undefined” track. To contextualize this, the baseline win rate was roughly 5-6% for projects receiving either top-five placements or public recognition.
First place went to attn.markets with its revenue tokenization protocol. Second through Fifth places went to Echo, PlaiPin, Solana ATM, and Humanship ID, respectively. Honorable mentions in that track included legends.fun and Scanna.
The density of competing projects and the breadth of approaches to novel problems say this ecosystem isn’t short on builders attempting to solve tough technical challenges.
What Lockbox Actually Does
I described Lockbox to the hackathon judges as a functional proof of concept for the first Solana infrastructure layer that lets wallets and dApps treat encrypted credential storage as a native, composable, permanent system. The user experience is intentionally familiar: users can store encrypted vaults directly on-chain, associated with their wallet, without any central server ever seeing plaintext data.
The technical architecture works like this: user data is encrypted client-side, before it ever leaves the user’s device. The plaintext is cleared from memory immediately after encryption. A user’s encrypted vault is stored on-chain as a program-derived account associated with their wallet. Our dApp never touches the keys or the plaintext. Instead, wallets, dApp developers, and enterprises can build their own interfaces on top of the Lockbox protocol and SDK, or use the reference implementation we built.
Where Lockbox diverges substantially from existing blockchain-adjacent solutions is in its recovery mechanics. If a user loses access to their wallet seed phrase, they can still recover limited access to their encrypted vault using offline-generated backup codes. These codes are generated off-chain, never exposed to any server, and provide what I think of as an “offline lifeline” for recovery after seed loss.
Based on my research into blockchain password managers and credential storage solutions, this recovery mechanism appears to be unique. Other approaches I examined either abandon users who lose their keys or require centralized servers to hold recovery data.
Technical Approach & Cryptographic Design
The core security assumption is straightforward: the user’s encryption key is derived from material they control, and the plaintext is never transmitted to or stored on untrusted infrastructure. I used industry-standard encryption with authenticated encryption to prevent tampering. The vault structure allows for multiple encrypted credential entries, so a user can store passwords, API keys, or other secrets under one wallet-associated account.
The backup recovery codes are the most novel part of the approach, because they provide that “offline lifeline” without ever exposing plaintext or relying on a server.
They are generated using a cryptographic scheme that produces short, memorable codes that can be stored offline. When a user later wants to recover access after losing their wallet keys, they can use one of these codes to restore access to a subset of their vault data. The codes themselves don’t store plaintext; they’re derived from the recovery seed in a way that allows verification and re-encryption with new key material.
What makes this architecture interesting from a security engineering perspective is the constraint: the Lockbox server and dApp must never see the plaintext keys or credential data, even during recovery. This means the recovery flow has to rely entirely on material the user stores offline and cryptographic primitives that don’t require server-side decryption. I used zero-knowledge proofs in parts of the verification logic to prove ownership of recovery material without exposing it, which keeps recovery interactive without widening the trust boundary.
For enginers who want to go deeper, full architecture and cryptography documentation for Lockbox is available in the project repository’s docs directory.
Business Model & Ecosystem Integration
Existing password managers charge either a recurring subscription (roughly $36-60 per year for consumers; that’s $360-600 over a decade just to keep access to your passwords) or per-user-per-month fees for enterprise (often $5-10 per employee, which balloons for larger teams). In both cases, users face recurring costs indefinitely, and enterprises face mounting annual overhead that procurement teams actively try to escape.
Lockbox’s model is fundamentally different.
Users pay linear, one-time fees for storage upgrades as they need them. If a user decides to close their vault, the storage rent is returned immediately—there is no subscription trap and no year-after-year extraction. This is technically possible because the vault data lives on-chain, which means Solana’s rent mechanism handles the economic model. Additionally, Lockbox transactions create network activity every time a credential is added, expanded, or accessed, which supports a sustainable fee structure through transaction costs.
For wallets like Phantom or Solflare, Lockbox integration could become a significant product differentiator. A wallet that offers secure, built-in password management, integrated with the wallet SDK and delivered through a partner protocol rather than developed in-house, becomes much stickier for users. It increases daily active use cases for holding and accessing the wallet. The wallet bears no backend infrastructure cost, because the infrastructure is decentralized and on-chain. For Lockbox, integration drives daily network activity and user adoption across multiple wallet platforms simultaneously.
The actual moat here is less about the code and more about the credibility and operational burden required to maintain a security-critical application like this in production. Vulnerabilities in a password manager are catastrophic for end users. A credible founding team in this space needs demonstrable infosec expertise, rigorous code review practices, ongoing vulnerability management, and clear incident response procedures. These are not negligible requirements. That burden of proof and operational complexity is what makes it less likely that a wallet would attempt to build password management in-house rather than integrating a specialized partner solution.
The Role of AI
Claude Code sat in the middle of the Lockbox development process, not as an author of security-critical logic but as an accelerant for getting there. I used it obsessively to draft and refactor non-sensitive scaffolding, propose alternative patterns for account layout on Solana, and quickly explore different ways to structure the vault lifecycle without touching the cryptographic core or recovery semantics.
From a security standpoint, Claude’s main value was speed under constraint: it let me explore implementation options quickly while preserving a hard rule that anything touching secrets or recovery had to pass manual review and testing. I could ask for multiple candidate implementations for state transitions, error handling, or client-side flows, then stress-test those against the threat model documented in the architecture and cryptography notes. That let me refine the design for how vaults are created, updated, and closed and how recovery codes are handled while keeping the trust boundary tight and the plaintext exposure surface as tiny as possible.
This is where AI-assisted development becomes part of the new professional baseline rather than a gimmick. Used correctly, tools like Claude Code help surface implementation options quickly, but cannot replace disciplined review, adversarial thinking, or formal reasoning about how secrets move through a system. In Lockbox, AI-suggested changes touching the vault model, encryption flow, or recovery path were treated as untrusted input: reviewed manually, tested, and checked against documented assumptions in the design docs.
How This Work Fits My Practice
I publish investigative pieces on national security, geopolitical interference, and the connections between government agencies and private actors. Those investigations require tools. I need to parse large datasets, understand network relationships, trace funding flows, and sometimes assess the technical credibility of claims I encounter.
Building Lockbox and experimenting with Solana development is not a departure from that core work; it’s a necessity. I do a lot of development work that never ships, never gets published, and never appears on my public profiles. That experimental space is where I develop the technical depth I need to continue producing quality analytical output.
When I analyze surveillance systems, evaluate the credibility of cybersecurity claims, or work through the technical implications of government hacking capabilities, I’m drawing on a reservoir of practical engineering experience. I’ve implemented cryptographic primitives, designed and defended systems where failure is not acceptable, and thought through threat models where an adversary has significant resources. That hands-on work sharpens my ability to read a technical claim in a news article and understand whether it’s plausible or whether someone is making assertions that don’t hold up under scrutiny.
An honorable mention at a hackathon of this scale won’t lead to consulting contracts or convert directly into newsletter subscribers. What it does is demonstrate that the experimental work I’m doing is rigorous enough to compete at scale and sufficiently substantive to warrant recognition from peers and judges who understand the space. Readers of my analytical work should know that when I make technical claims about cryptographic systems, surveillance infrastructure, or the capabilities of state actors, I draw from hands-on experience.
Conclusion
Lockbox sits at an interesting intersection: it solves a universal user pain point that crypto has failed to address; it demonstrates a business model fundamentally different from centralized competitors; and it showcases a technical approach to credential recovery that I believe is novel in the blockchain space. The fact that it earned recognition alongside 1,575 other projects at the largest crypto hackathon to date is validation that the work was worth doing.
More importantly, it represents exactly the kind of technical experimentation that makes my primary analytical work more credible and more substantive. Understanding infrastructure that people depend on for security is not a hobby outside my main career.
It is core professional development for writing with authority about systems that matter.
This publication operates on reader subscriptions. If this analysis demonstrated value, please consider becoming a paid subscriber to support continued investigation.