Know what
protects your assets.

Build your USB key vault.

1. Prepare a USB. Back up existing contents. If necessary, format it through your operating system; exFAT is a common cross-platform choice. Formatting erases data. Entangled Bit installs files into a fresh folder and never formats a drive or flashes its firmware.
2. Create a recovery identity. In the vault, generate an ENTB1 key and back it up somewhere separate from the drive. Re-enter it to confirm. It unlocks encrypted backups and is not a Solana seed phrase.
3. Install a verified release. The Downloads page verifies the ML-DSA publisher signature and file hashes. The folder installer copies the kit and reads every file back to check integrity. The ZIP includes the standalone HTML client, a guide, a manifest, and an optional Python copy tool.
4. Disconnect for account creation. Open the HTML client on a trusted offline computer. Restore your ENTB1 identity. No receipt or subscription is required. Generate a Solana account or import a 64-byte CLI JSON/base58 keypair.
5. Prove recovery works. Save the encrypted .entb backup, then reopen it. The client checks that its private key regenerates the stored address. Keep separate backups of the encrypted file and recovery key.
6. Export the public account file. Bring this file to the online transfer desk. It contains an address, a public vault key, and ownership proofs. No private key is included.

All current features are free: creation, import, encrypted backups, file encryption, recovery, exports, signing, balances, and the transfer desk. Solana network fees and account rent still apply.

Prepare online. Sign offline.

1. Import your public account file at the transfer desk. Choose devnet for testing or mainnet for real assets.
2. Enter the recipient and amount. For classic SPL tokens, supply the mint; the desk reads decimals and validates the source and destination accounts.
3. Review and download the request. It includes the full addresses, base-unit amount, network, fee, rent estimate, and blockhash or nonce.
4. Open the request in the offline client after recovering your encrypted account. Compare every field with your intended operation and explicitly authorize signing.
5. Return the signed packet to the online desk. It reconstructs the transaction, compares the bytes, and checks both signatures.
6. Simulate the exact signed transaction. The desk verifies its signature and keeps the original blockhash. Then explicitly authorize submission.
7. Check the transaction status. Submission is not confirmation; wait for confirmed or finalized status and inspect failures.

Supported operations

SOL transfers; classic SPL Token TransferChecked with optional idempotent recipient associated-account creation; and System Program nonce creation, advancement, and closure. One signer is supported: the account in your encrypted vault also pays the fee.

Arbitrary transactions, arbitrary message signing, approvals, authority changes, Token-2022 transfers, wrapped SOL transfers, delegated source token accounts, and unknown fields are rejected. Token-2022 remains supported for balance viewing. Public mint addresses are authoritative; the app does not invent token symbols or valuations.

Time to sign: blockhash or nonce

A recent blockhash expires quickly. If it expires while you move files, prepare and sign a new request; an old signature cannot be reused with a refreshed blockhash.

A durable nonce is held in a separate System Program account controlled by your wallet. Create it first with a recent-blockhash request, then use its address for transfers that need more time. The nonce advancement instruction is always first. The desk checks its authority, initialized state, and current value before submission.

A signed nonce packet does not expire by a wall clock. Anyone holding it can submit it until the nonce advances. Deleting a file does not revoke it. Use the explicit invalidate operation and confirm that transaction to change the nonce. An old transfer can execute first in a race. A transaction that executes but fails can still consume its nonce and fee.

Closing a nonce returns its current SOL balance to your account. Current Solana documentation notes that durable nonces may be deprecated in a future release.

Assets on-chain.
Keys in your hands.

A USB stores the secret material that authorizes use of blockchain assets. Coins and tokens remain on Solana. Encrypting a backup protects its contents when the decryption key remains secret.

Backup format

A random 256-bit ENTB1 seed derives independent ML-KEM and ML-DSA key-generation seeds. Every backup uses fresh KEM encapsulation, an HKDF-derived AES-256 key, a random 96-bit nonce, and a 128-bit GCM tag. Exact header bytes are authenticated. Filenames, file contents, and Solana account secrets are encrypted. Ciphertext size and recipient linkage remain visible.

Solana accounts use independently generated 32-byte Ed25519 seeds. Import requires a valid 64-byte keypair with a matching public half. Restoring verifies the stored address against the private key. General file encryption remains limited to 64 MiB per file.

Transfer format

Versioned JSON requests allow only explicit supported intents. An offline signer reconstructs instructions instead of trusting imported transaction bytes. A fixed domain-separated memo commits to the request. On return, exact-byte comparison and Ed25519/ML-DSA verification precede chain-state checks, simulation, and broadcast. Network genesis hashes are pinned and compared against the selected RPC.

The ML-DSA packet approval protects the application workflow. It is not verified by Solana and does not make the underlying account quantum-resistant.

Key protection ≠ chain protection.

Solana’s standard accounts authorize transfers with Ed25519. A sufficiently capable quantum attacker breaking that scheme from a public key would not need to decrypt your USB. The current product provides post-quantum encryption for keys at rest, plus an offline signing workflow.

Ordinary USB drives are cloneable storage. A vault ID identifies software keys, not a tamper-resistant chip or a physical device. The product does not include secure boot, whole-disk encryption, secure erase, hardware attestation, or a native signed installer.

The offline HTML bundles every runtime dependency and blocks network requests with CSP. Accessible private buffers are cleared on lock/close and the vault locks after 15 minutes of inactivity. JavaScript cannot guarantee full memory erasure. Using an infected computer defeats protection while keys are unlocked.

Importing an existing private key does not revoke copies, token delegates, freeze authorities, or other on-chain permissions. The balance viewer flags returned frozen/delegated accounts but is not a complete permissions audit.

NIST standardization of these algorithms is not certification of this application. No independent audit has been completed. Use devnet while validating the product.

Where the full vision leads.

The next layer requires a program-controlled vault that verifies a post-quantum proof before releasing assets. A normal fee payer could submit the transaction without becoming the withdrawal authority. This must be enforced on-chain, not merely in this website.

1. Verifier and resource proof. Benchmark a reviewed post-quantum verifier under Solana’s current transaction and compute limits. Legacy/v0 and newer transaction formats have different limits; feasibility needs measurements.
2. Program-controlled custody. Use PDA custody and bind every authorization to the chain, program, vault, asset, recipient, amount, and state transition.
3. No classical bypass. Withdrawal, recovery, key rotation, and upgrade paths must not grant an ordinary Ed25519 key an override.
4. Safe key lifecycle. A Winternitz approach requires one-time-key discipline even after failed or abandoned transfers. Copied USBs and rolled-back backups must not trigger key reuse.
5. Token-specific validation. Model classic SPL and Token-2022 extensions, fees, freeze powers, permanent delegates, and transfer hooks before accepting assets.
6. Independent review and deployment. Complete adversarial tests, an external audit, funded deployment, and operational monitoring before claiming production quantum-resistant custody.

The Solana Winternitz Vault is a research reference for hash-based SOL authorization. No Entangled Bit program derived from it is deployed. Custom secure hardware also requires hardware design, manufacturing, firmware review, and physical testing beyond a USB file installer.

Connect online. Fund your offline account.

The online funding page connects an existing Solana wallet, reads balances, verifies your exported public account, and prepares SOL or classic SPL funding. Compare the destination with your offline client, review the amount and fees, approve signing in the connected wallet, then submit the verified transaction.

Reown AppKit supports WalletConnect QR/mobile when configured. Compatible browser wallets remain available without a relay project. Connecting shares public account data; it does not import or encrypt your existing private key. The connected wallet signs only its own funding transaction. Outgoing vault transfers still use the offline signer. Account, network, or form changes invalidate pending requests.

Your vault stays free.

All existing functionality is available without a subscription, account registration, connected wallet, trial, or offline activation receipt. This includes account creation/import, backups, general file encryption, recovery, export, offline signing, balance checks, simulation, and transaction submission. Network fees and account rent are charged by Solana, not a vault subscription.

Older releases gated new encryption behind a signed receipt. Release 0.4 removes that requirement from both the website and offline client. Download the new kit and retain your existing encrypted files and separate recovery key. The encrypted format is unchanged. Legacy trial, verification, receipt-refresh, and payment endpoints are retired; configuring old payment variables cannot reactivate them.

Entangled Plus: an optional hosted service.

After launch, Plus is planned to provide continuous monitoring of selected Solana addresses and token accounts, movement and balance-threshold alerts, token delegate and account-authority changes, cold-wallet activity detection, and activity history. Notifications are planned through Telegram, email, and an in-app inbox, with rules, severity, retries, and delivery status.

Plus subscriptions, pricing, address limits, and retention are not available yet. There is no active monitor, notification delivery, paid activation, or enrollment in this release. Subscriptions will open only after the monitoring and delivery service has been implemented and validated. Cancelling Plus will affect its hosted services only.

Public addresses. Private keys stay local.

The local vault sends no recovery seed, Solana private key, or file content to the service and creates no new subscription record. Online balance checks and transfer submission send public addresses and transaction data to the selected RPC. Historical service records remain retained; this update does not delete them.

Future Plus enrollment will require explicit selection of watched addresses and notification destinations. It will associate that public activity with a service account, with retention, deletion, and notification controls specified before activation. Plus will never require custody of private keys.

Alerts describe observed activity; they cannot reverse completed transactions or guarantee prevention of loss. Monitoring does not alter Solana’s Ed25519 authorization. Existing simulation and transaction review remain free.

Release 0.4.

Automated tests validate cryptography, request tampering, exact units, nonce rules, reconstruction, signatures, failed simulation, release integrity, and read-back checks. Live genesis-hash RPC reads succeeded. A devnet faucet error blocked funded integration testing in this environment; no successful on-chain transfer is claimed by these checks.

The product remains an engineering alpha. Read the security model and complete a small devnet round trip before relying on a workflow.

Published foundations.

NIST FIPS 203 — ML-KEM ↗
NIST FIPS 204 — ML-DSA ↗
Noble post-quantum implementation ↗
Solana transactions ↗
Durable nonces ↗
Checked token transfers ↗
Transaction simulation ↗
Offline client checksum ↧