[UPDATE] Lock beta status and answers to the main technical questionsHi all,
There have been a lot of thoughtful questions in this thread, particularly around the signing boundary, comparisons with offline Electrum, the scope of our post-quantum claims, and how the architecture will be validated.
The team has been focused on moving Lock into beta and internal testing, so this is a good point to bring the main answers together and provide a current status update.
CURRENT STATUSLock is now in beta and internal testing, with early access coming shortly.
The rollout is planned in stages:
- Wallet and Treasury first
- Node following soon after
This is a release sequence rather than a change to the reference architecture. Lock remains designed around three cooperating roles: Treasury, Wallet, and Node.
The exact operating-system and CPU architecture matrix for the first packaged release is still being finalised. We will publish that once the release builds are locked.
We also do not currently support Bitcoin testnet3 or testnet4.
Several people here asked for Bitcoin testnet support because they understandably do not want to evaluate preview wallet software with mainnet funds. That is a useful point, and we want to be clear about the current limitation.
WHAT TREASURY ACTUALLY ISSome of the earlier discussion used the phrase "Treasury OS", which has created an understandable impression that Lock is developing a new operating system.
That is not the architecture.
Treasury is the signing application and security boundary. In the intended high-security deployment, it runs on commodity hardware as a dedicated air-gapped or internet-isolated signing device.
It uses the underlying operating system and the protections available on that platform. The implementation includes platform-specific hardening paths for Windows, macOS, and Linux, including process and debugger restrictions, core-dump controls, machine-bound key protection, and, where configured, a separate Vault daemon running under another OS user.
Lock is therefore not attempting to build and maintain its own kernel, hardware drivers, or general-purpose operating system across arbitrary devices.
There is also an important distinction between air-gapped and internet-isolated use.
A fully air-gapped Treasury uses a deliberate physical transfer workflow. An internet-isolated Treasury may communicate over a constrained local or physical transport while remaining unable to make general public-network requests.
In Lock's default strict-egress posture, Treasury does not call public blockchain RPCs or other public internet services. Those network-facing responsibilities sit outside the signing boundary.
Treasury can still accept an approved Wallet connection over Lock's authenticated and encrypted protocol. The transport moves the data; the application protocol establishes the trusted session.
The aim is not to claim that an offline device is invulnerable. Removing public-network access greatly reduces the remotely reachable attack surface, but privileged compromise, malicious firmware, kernel or hypervisor attacks, physical access, side channels, and poor recovery practices remain relevant.
The security objective is containment and a smaller blast radius.
WHAT WE MEAN BY A "SMALL" TREASURYWhen we describe Treasury as small, the important property is not a tiny line count.
The more precise word is narrow.
Treasury owns seed handling, key derivation, signing policy, and signing. Those are substantial responsibilities and there is meaningful implementation behind them.
What Treasury does not need to own is equally important.
Public RPC integrations, provider aggregation, market data, transaction tracking, and the other noisy network-facing systems live outside it. The Node is the largest subsystem in Lock because it absorbs most of that public blockchain complexity.
The objective is to keep seed-dependent operations within the smallest practical privilege and trust boundary.
The current whitepaper does not publish a Treasury-only line count, so we are not presenting one.
HOW THIS COMPARES WITH OFFLINE ELECTRUMA Bitcoin-only setup using an offline Electrum signer and a separate online watch-only wallet is already a strong custody model.
Lock is not based on the premise that this setup is ineffective.
The difference is the surface over which Lock is trying to preserve the same general isolation principle.
The architecture separates:
- Treasury: seed storage, derivation, signing policy, and signatures
- Node: public-chain connectivity, providers, tracking, and other network-facing work
- Wallet: presentation, orchestration, and user intent
- Vault daemon: optional additional isolation of the device key under a separate OS user
In the high-security deployment, Treasury can live on a dedicated device while Wallet and Node remain outside the signing boundary.
That becomes particularly relevant for users who want active self-custody across a broader surface: multiple chains, swaps, bridges, Lightning, messaging, storage, and smart-contract interactions.
The goal is to prevent those additional functions from gradually pulling the seed into the same environment that handles the everyday interface and public network.
For someone who only needs Bitcoin cold storage and already operates an offline Electrum setup correctly, Lock has to earn its place through the released product rather than through an architectural slogan.
DOES LOCK MAKE HARDWARE WALLETS OBSOLETE?Our thesis is that, for a meaningful share of active self-custody, an isolated software Treasury running on a dedicated device can replace reliance on a proprietary hardware-signing peripheral.
That does not mean every hardware wallet is insecure or no longer useful.
Hardware wallets solved a real problem and remain an effective way to narrow key-extraction risk, particularly when the user wants a simple and well-understood signing device.
Lock is testing a broader custody model in which key isolation is combined with:
- Separate signing, UI, and network roles
- Signing policy and parameter limits
- Public-network isolation for Treasury
- Authenticated communication between components
- Signed update verification
- Optional Vault isolation of the device key
Within that model, "safer" has a specific meaning:
- Compromising the Wallet should not directly expose the seed
- Compromising the Node should not by itself authorise a spend
- Compromising a transport should not reveal signing keys
Those boundaries do not make every component harmless when compromised.
A fully compromised and already-authorised Treasury remains dangerous. If an attacker extracts the seed itself, Lock's signing policy cannot stop it being used outside Lock.
The architecture is designed to force an attacker across several boundaries rather than allow one compromised component to inherit every secret and authority.
OPEN CODE, TESTING, AND INDEPENDENT REVIEWAnother important distinction raised in the thread is the difference between code being available and code being independently audited.
Nobody should be expected to personally review an entire wallet codebase before using it.
The Lock whitepaper is an implementation-authored description of the system, its trust boundaries, and its known limitations. It is not an independent security audit, and it is not a formal isolation proof.
The tests described in the paper establish particular invariants under particular conditions. They complement, rather than replace:
- Independent security review
- Hostile-host testing
- Fault injection
- Live-network interoperability testing
- Operational security assessment
We are currently selecting independent audit partners.
Once internal testing is complete, we will update the public repository. Repository and licensing details will be published alongside that update.
The security argument has to be supported by inspectable implementation, reproducible testing, and external scrutiny.
WHAT "QUANTUM-SAFE" MEANS IN LOCKLock does not make Bitcoin, Ethereum, Solana, or any other existing blockchain quantum-safe.
On-chain transaction signatures remain whatever each blockchain's wire format and consensus rules currently require.
The cryptography Lock can control is its own internal and off-chain protocol layer.
Selected Lock-controlled paths use hybrid classical and post-quantum constructions:
- X25519 + ML-KEM-768 for hybrid key establishment
- Ed25519 + ML-DSA-65 for hybrid digital signatures
Under the intended constructions, defeating only the classical component or only the post-quantum component is insufficient.
The whitepaper applies these hybrid primitives to long-lived Lock-controlled surfaces including Wallet-to-Treasury and Wallet-to-Node channels, selected authentication paths, and chat envelopes.
SLH-DSA is also implemented as a separate stateless hash-based signature option. It is deliberately standalone rather than paired with a classical signature.
The term "quantum-safe" therefore applies to selected Lock-controlled off-chain protocols.
It does not mean:
- Every cryptographic operation in Lock is hybrid
- Existing blockchains have become quantum-safe
- Endpoint compromise is no longer relevant
- Recovery risk has disappeared
- Lock is "quantum-proof"
WHAT HAPPENS IF BITCOIN'S CRYPTOGRAPHY IS BROKEN?That remains a Bitcoin-level migration problem.
Lock cannot independently change Bitcoin's consensus signature scheme.
If a sufficiently capable quantum computer made secp256k1 practically breakable before Bitcoin migrated to a resistant signature system, affected funds would inherit that chain-level risk regardless of which wallet produced the transaction.
Lock can protect the communications and protocol identities whose cryptography it controls.
It cannot override the cryptographic rules of an external blockchain.
That boundary is deliberate and is stated explicitly in the whitepaper.
THE UNIVERSAL QUANTUM SEEDUQS addresses a different part of the long-term security model: generation, transcription, and recovery of the wallet's root seed.
The 36-word UQS format encodes 272 bits of entropy and includes a 16-bit checksum.
Its derivation pipeline is:
HKDF-Extract
-> PBKDF2-SHA-512
-> Argon2id
-> HKDF-Expand
The operating-system CSPRNG is the security floor.
Timing measurements, scheduling jitter, and optional user input provide supplemental diversity. They are not treated as seven independently strong entropy guarantees.
UQS uses 256 visual icons mapped consistently across 42 language tables. The same icon sequence can therefore be recognised and re-entered through different localised labels.
Recovery does not depend on a Lock server.
The seed backup is the recovery root. The machine-bound device key protects local state, but it is not the user's ultimate backup. If the local device protection is lost, the intended recovery path is to restore from the seed and rebuild the protected local state.
Lock also supports importing conforming BIP-39 seeds.
UQS is not based on a claim that properly generated BIP-39 seeds are suddenly unsafe or that existing users need to migrate immediately.
It is a more conservative default chosen for newly created Lock wallets.
BIP-39 also has a much more mature ecosystem of independent recovery tools. As UQS documentation and tooling are published, independent recovery and interoperability will need to be part of its review.
WHERE WE ARE NOWTo bring the current position together:
- Lock is in beta and internal testing
- Early access is coming shortly
- Wallet and Treasury are planned to launch first
- Node will follow soon after
- Bitcoin testnet is not currently supported
- The exact first-release OS and CPU matrix is still being finalised
- Independent audit partners are currently being selected
- The public repository will be updated after internal testing
- The whitepaper documents the implementation and its trust assumptions; it is not an independent audit
We will also keep this thread updated directly as the beta, documentation, repository, and review process progress.
Please keep challenging the assumptions and the boundaries. That is why we brought the architecture here before release.
Cheers,
Lock
