Drivekey

Offline signing. Turn a bootable USB into your crypto signing environment. Keys stay off the web. Transactions stay in your control.

[Drivekey @DriveKeyyy]

https://t.co/19edIZPz4o

[Drivekey @DriveKeyyy]

DriveKey passed 22 Ethereum workflows with offline USB signing

We’re excited to share what the latest DriveKey build can do. Across the matching USB OS, dapp, and Host, all 22 Ethereum workflows passed on a local fork. That includes ETH and USDC payments, Uniswap and https://t.co/rt3U9PEsrd swaps, and Hinkal private payments, transfers, withdrawals, and swaps in both directions.

We also tested what happens when the browser loses its connection during submission and when you need to recover your wallet from an encrypted backup.

From the dapp to the offline USB and back

We prepare the transaction in the dapp and save the exact request. Then we boot the DriveKey USB offline, review the transaction details, and sign. Back online, the dapp imports the signed file and asks for separate confirmation before submitting it.

The spending keys stay offline throughout that workflow. The offline review shows the amount, recipient or spender, and fee limit before signing. Once the transaction settles, DriveKey verifies the result and saves a receipt you can reopen after a restart.

We tested the moment the connection drops

In one ETH payment test, the browser lost the response after submission. DriveKey recovered the saved transaction, verified that it had settled, and rejected a duplicate send.

We also tested the full https://t.co/rt3U9PEsrd USDC-to-ETH flow. DriveKey verified the exact USDC approval, confirmed the ETH arrived, checked that the remaining USDC allowance was zero, and recovered the receipt after a restart.

We restored the wallet from its encrypted backup

On the same USB image, we created a test wallet in an offline Secure Boot VM and restored it from its encrypted backup in a separate offline VM. The restored vault and public identity matched byte for byte.

We’re especially happy to see those pieces work together in one build. You can prepare a private payment or swap, review and sign it offline, and come back after a restart to see what settled. If you need to restore the wallet itself, you can do that offline too.

[Drivekey @DriveKeyyy]

Drivekey os demo will be live in 2 days.

The reverse swap passed. The dapp imported the offline signature, submitted once on the local fork, and recovered the same verified receipt after restart. That gives R18 passes on all four priority Hinkal cases.

[Drivekey @DriveKeyyy]

We closed the DriveKey dapp after a Hinkal ETH withdrawal. When we reopened it, the withdrawal was still marked settled and we could download the exact same verified receipt.

That’s a big milestone for R17. The USB OS verified the encrypted backup before signing, and the spending key stayed offline. The dapp took the signed file, required a separate confirmation to submit, verified the payout, and blocked a second submission.

The screenshot is from the actual R17 dapp after restart. You can see the saved withdrawal and the verified receipt ready to download.

We’ve now exercised the full ETH withdrawal flow on a local Ethereum fork, from offline approval through recovery. That gives us a concrete milestone heading into physical USB and mainnet qualification.

[Drivekey @DriveKeyyy]

DriveKey R17 hit a big release milestone today. We took a Hinkal ETH withdrawal from offline review all the way to a verified payout, restarted the dapp, and pulled back the exact same receipt.

Here’s what the test actually exercised.
1. Verify the encrypted backup before signing. We booted the 1 GiB DriveKey USB image in an offline VM and verified the wallet backup.

2. Review what will happen. The offline screen showed the recipient, withdrawal amount, private change, pinned contract, and maximum network fee. The Hinkal proof and the gas-paying Ethereum transaction each required their own approval.

3. Sign offline, submit once. The spending key stayed inside the offline environment. The matching dapp imported the signed file and submitted it to a local Ethereum fork after explicit confirmation. A second attempt was rejected.

4. Verify settlement and recover after restart. We checked block inclusion and the actual ETH payout, then reopened the dapp and recovered the verified receipt byte for byte.

That gives us a working withdrawal flow to take into release qualification, including what happens after you hit submit and after you close the app. Next up are the USDC withdrawal and both private swap directions. Physical USB and mainnet qualification are still ahead.

[Drivekey @DriveKeyyy]

https://t.co/YBTAQw6Rz1

[Drivekey @DriveKeyyy]

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.

[Drivekey @DriveKeyyy]

https://t.co/chu124tfkt

[Drivekey @DriveKeyyy]

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

[Drivekey @DriveKeyyy]

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

[Drivekey @DriveKeyyy]

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 @DriveKeyyy]

https://t.co/MsUXlKJz51

[Drivekey @DriveKeyyy]

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.

[Drivekey @DriveKeyyy]

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 @DriveKeyyy]

https://t.co/bfx6oNPA56

[Drivekey @DriveKeyyy]

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.

[Drivekey @DriveKeyyy]

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.

[Drivekey @DriveKeyyy]

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 @DriveKeyyy]

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

[Drivekey @DriveKeyyy]

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

[Drivekey @DriveKeyyy]

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.