Drivekey

DriveKey dev update We signed a USDC payment offline and recovered its verified receipt after restart. A fresh offline VM restored the test wallet from its encrypted backup. 18 of 22 cases passed on the matching Ethereum fork.

Today we will be sharing our new found discovery and new signing model focusing on next level security surpassing all competitors.

ETH staking is on the DriveKey roadmap. We’d love to hear what you think. Should we add SOL staking too?

hardened Hinkal request binding and encrypted-note validation. 43 focused tests passed. ETH exercised through the offline USB VM, with receipt recovery and duplicate protection.

DriveKey: online preparation. Offline authorization. Verified settlement. We’re building the next release around a clear security model that connects the dapp and bootable USB OS into one deliberate workflow. One PC. Three operating stages. Prepare online: create and save the exact transaction request. Authorize offline: boot the USB OS with networking disconnected, review the terms, verify the encrypted backup and sign. Submit and verify online: explicitly submit once, independently confirm settlement and retain the receipt. Offline key control The spending key stays inside the offline signing environment. The browser handles preparation and public transaction data. Before signing, the software checks the account, chain, recipient, token, amounts, selected inputs, change and expiry. Approval is bound to those exact terms. Changed terms require a new review. Separate signing and proof generation Private-payment authorization and zero-knowledge proof generation run in separate isolated workers. The key worker creates the spending authorization. The prover receives the witness needed to construct the proof. The spending seed stays in the key worker. Recovery built into the workflow Encrypted-backup verification is part of signing. Retained results support recovery of exact outputs without blindly generating another signature. Durable records, single-use controls and duplicate checks connect what was approved, what was submitted and what actually settled. An uncertain result requires reconciliation. An independently stored encrypted backup remains essential for protection against device loss. What we’ve strengthened Recent development has tightened Hinkal request binding, encrypted-note validation, worker placement and recovery checks. The ETH workflow has been exercised through the offline USB VM, including receipt recovery and duplicate prevention. What comes next The complete private-payment workflow and mainnet qualification remain unfinished. The security model also depends on trusted boot media, firmware and the operating environment. Our target is ambitious: private Ethereum payments and swaps with offline key control, understandable approvals and verifiable recovery. That complete lifecycle is what we’re working to deliver.

Big DriveKey progress today: ETH↔WETH passed dapp → offline VM → fork settlement, with backup checks, offline signing, once-only submission, receipts and restart/duplicate protection. Fixed worker exports and portable storage placement.

DriveKey build update: Rebuilt the compact USB OS + host and fixed verification bugs. Hinkal ETH deposits passed offline signing, one explicit submission to a local fork, receipt replay and restart recovery.

Big progress on the new os. Compiled Host R19 passes both Uniswap fork routes, including exact fees, allowance cleanup, retained receipts and duplicate prevention. The 1% rounding defect is fixed.

SMS alerts are coming to DriveKey. On-chain confirmation → DriveKey alert relay → Twilio → your phone. Opt-in updates. Signing keys stay offline on your USB. Your wallet, without the constant dashboard checking. Coming soon.

DriveKey is building a bootable USB OS + dapp around offline signing. Prepare online → review offline → sign offline. Ethereum. Solana. Privacy. The next chapter of self-custody is taking shape. Development preview. More progress soon

Independent review accepted the packaged dapp’s initial UI and public USB-download handoff, including file identity and process cleanup. I’m publishing the evidence, screenshot, and setup guide. Full Host, financial, physical-device, and mainnet qualification remains complete. Testing continues

The previous turn made concrete progress: the corrected dapp build, rendered page and candidate 0008 download all passed bounded review. We are now checking the remaining private transaction path, starting with how execution evidence reaches the original journal and submission gate.

DriveKey dev update: The bootable USB candidate runs our offline wallet UI in VM tests. ETH request review → offline signing → verified response export passed with an unfunded test wallet. Next: private-flow integration and physical USB validation. Still pre-release.

Keep in mind the ui isnt final thats the beta version.

DriveKey update The bootable offline OS now passes BIOS, UEFI and Secure Boot VM startup tests. Vault creation, wrong-passphrase rejection, encrypted backup and restoration across two separate boots have also passed. The goal is one airgapped workflow for: • ETH and USDC payments • Uniswap ETH/WETH - USDC • Hinkal deposits, private payments, swaps and withdrawals • Canonical USDC bridging between Ethereum and Solana Each route still needs end-to-end qualification. The workflow: Prepare in the dapp → save the exact request and recovery files → boot offline → review and sign → return online → explicitly submit once → independently verify settlement. The signing device never submits transactions to the network. Current work focuses on spending-limit enforcement, recovery after interruptions, duplicate-submission prevention and genuine private proofs.