How Lockx Works

Cryptocurrency security has been plagued with trade-offs between convenience and protection. Traditional wallets require users to manage private keys directly, while centralized exchanges control user funds entirely. This creates a fundamental problem: either users bear the full burden of security, or they surrender complete control to third parties.

Lockx addresses this through zero-knowledge proofs and multi-party computation. The system uses soul-bound NFTs (ERC-5192) as non-transferable asset containers. Backend services verify signature ownership through ZK proofs without ever seeing the actual signatures. They only receive rsHash (SHA256 of r||s components).

Each NFT is linked to keys derived using HKDF-SHA256 with rejection sampling to ensure valid SECP256K1 scalars. Private keys are split into shares through additive secret sharing (Share1 + Share2 = FullKey mod SECP256K1_ORDER), with shares combined only during signing for ~50ms before immediate destruction.

Soul-Bound NFT Implementation (ERC-5192)

The lockbox system implements ERC-5192 soul-bound NFTs that cannot be transferred between addresses. The _update function in the contract explicitly reverts any transfer attempts between non-zero addresses, while the locked() function always returns true. This ensures permanent binding to the original owner's wallet, preventing theft even if private keys are compromised.

Assets are deposited into lockbox NFTs through smart contract calls that transfer ownership from the user's wallet to the lockbox contract. The contract maintains internal mappings of which assets belong to each NFT token ID, supporting ERC-20 tokens, ERC-721 NFTs, and native ETH within a single container structure.

Unlike traditional NFTs that derive value from external metadata or artwork, lockbox NFTs derive their utility from the cryptographic access control they provide to contained assets. The NFT serves as both proof of ownership and the access mechanism for withdrawal operations.

Multi-Party Computation and Zero-Knowledge Proofs

The system employs zero-knowledge proofs (implemented in Noir v0.19.4) to verify signature ownership without revelation. Users generate ZK proofs that demonstrate knowledge of signature components (r, s) that hash to a public rsHash value and validate against a message. The backend verifies these proofs without ever accessing the actual signature.

Key derivation uses HKDF-SHA256 with carefully constructed inputs: IKM combines rsHash with server keys and a version string, salt incorporates wallet address and transaction context, and info contains chain-specific metadata. The system performs rejection sampling to ensure derived keys are valid SECP256K1 scalars (0 < k < SECP256K1_ORDER). Google Cloud KMS encrypts server fractions with authenticated additional data (AAD) binding.

Multi-party computation splits keys into Share1 (derived deterministically from full key) and Share2 (calculated as FullKey - Share1 mod SECP256K1_ORDER). The MPC service maintains Share2 in a 60-second TTL cache, combining shares only during EIP-712 signing operations (~50ms window) before immediate cleanup. This ensures no single service ever possesses complete private keys.

The security model operates on the principle that server compromise cannot result in key theft, as only encrypted fragments are stored. Similarly, user wallet compromise cannot provide access to lockbox assets without the corresponding server component. This cryptographic separation eliminates traditional single points of failure while maintaining the operational capabilities needed for asset management.

Two-Factor Authentication

Traditional two-factor authentication systems store TOTP secrets in encrypted databases, requiring trust that servers properly manage these secrets and decrypt them only for legitimate validation requests. This approach creates a central repository of cryptographic secrets that, if compromised, undermines the security of the entire 2FA system.

TOTP secrets are derived using the same HKDF-SHA256 pattern as key derivation, with IKM incorporating signature bytes and a TOTP-specific version string. The system generates standard 6-digit TOTP codes with SHA256 algorithm and 30-second steps. Secrets are never stored. They're reconstructed on-demand for each verification, then immediately discarded.

This approach eliminates persistent storage of TOTP secrets entirely. Each authentication event requires fresh reconstruction of the secret, and the secret is discarded immediately after validation. Server compromise cannot reveal 2FA secrets because they do not exist in storage, and user wallet compromise alone cannot generate valid TOTP codes without the corresponding server component.

The result is a 2FA system that provides equivalent security to traditional implementations while eliminating the storage-based vulnerabilities that have compromised numerous authentication systems. Users must possess both their wallet (for signature generation) and their authenticator device (for TOTP code entry) to complete withdrawal operations.

Withdrawal Operations

Asset withdrawals from lockbox NFTs require authorization through EIP-712 structured message signing. This standard ensures that withdrawal requests contain properly formatted, tamper-evident data that smart contracts can verify cryptographically. Each withdrawal creates a structured message containing the lockbox NFT token ID, asset details, destination address, and protective elements like nonces and timestamps.

The withdrawal process begins when users initiate a request through the interface. The system first requests a wallet signature for TOTP generation, requiring users to provide their 6-digit authenticator code. This dual authentication (wallet signature plus TOTP code) enables reconstruction of both the signing key and verification of the user's possession of their authenticator device.

Once authenticated, the MPC service combines Share1 and Share2 for approximately 50ms to sign the EIP-712 structured message. The signature includes domain separation, nonce incrementing for replay prevention, and 15-minute expiry windows. The smart contract performs ECDSA recovery to verify the signer matches the stored Lockx public key before executing transfers.

This process ensures that withdrawals require active participation from both the user (through wallet signatures and TOTP codes) and verification by the smart contract (through signature validation). The combination of cryptographic proofs and on-chain verification prevents unauthorized access while maintaining user control over their assets.

Conclusion

The Lockx architecture addresses fundamental trade-offs in cryptocurrency security by distributing cryptographic responsibilities without requiring complete trust in any single party. Through soulbound NFTs, key fraction technology, and dynamic 2FA generation, the system maintains the security properties of self-custody while reducing the operational burden on users.

Key fraction technology eliminates single points of failure by ensuring that neither user wallets nor server infrastructure hold complete cryptographic material. The application of this same approach to 2FA implementation removes the storage-based vulnerabilities that have compromised traditional authentication systems, creating a more robust security model.

This approach demonstrates that trustless systems need not sacrifice usability for security. By carefully distributing cryptographic operations between users and infrastructure, Lockx provides practical asset management capabilities while maintaining the decentralized principles that make cryptocurrency valuable. The result is a system that enhances security through cryptographic design rather than relying solely on operational trust.