Qlyphs The wallet
How the wallet stores keys, approves transactions, and handles recovery.
Where do your keys live, and who can use them?
Qlyphs Wallet is non-custodial: keys are created, encrypted and used in your browser. Its normal connection and transaction protocols send public data, not recovery phrases or passwords. A compromised device, wallet page or privileged update can still compromise an unlocked wallet.
Two forms, one wallet
| Qlyphs Keys | Browser extension | |
|---|---|---|
| Where | A web page, nothing to install | Chrome and Firefox |
| Code | Downloaded on every visit, verifiable | Installed package; store distribution is not yet available |
| Installation | Open the wallet origin | Build and load unpacked from the public repository |
Both are built from the same source and use the same account format: one recovery phrase opens the same account in either when the network, signing scheme and derivation path match. Keep an independent recovery copy; browser profiles do not synchronize vaults automatically.
The vault
The wallet persists encrypted recovery material. The sequence below describes a newly created vault; legacy encrypted backups are validated before migration.
- 01 / 04
24 words
When you create a wallet, your 24 recovery words are generated on your device from 256 bits of randomness. They are the master secret for deriving your accounts: anyone who obtains them can recreate those accounts without your wallet password.
- 02 / 04
Your password
Your password is stretched with PBKDF2-SHA256, 600,000 rounds, and a fresh random salt. This increases the cost of testing password guesses; it does not make a weak password safe against offline guessing.
- 03 / 04
Encrypted
The stretched password becomes a key that seals your words with AES-256-GCM. Encrypted vault data and public account metadata are stored in this browser profile. Authentication detects changes to the protected vault; account identities are checked again during restoration.
- 04 / 04
Unlocked, briefly
Unlocking starts an absolute five-minute session. Expiry, locking or a worker restart ends signing access. The wallet clears its secret buffers, but JavaScript and the browser do not guarantee erasure of every memory copy.
The wallet does not persist or send your password to a dapp. Recovery requires the correct phrase, or an encrypted backup and its password. A passkey alone does not restore the wallet in a new browser profile. Keep recovery material outside the browser; enter it only in a wallet interface you have verified, never in a connected dapp. Starting fresh after a forgotten password creates a different wallet and does not recover the old assets.
Walls inside the wallet
- Websites are outside. A site talks to the wallet through a narrow channel that carries requests and public answers only. That protocol provides no method to read a key, phrase or password.
- Only allowed sites. The wallet answers only to the sites built into its release. Anything else is refused; an allowed origin still needs your explicit account grant.
- Approval on the wallet's own screen. Every signature is shown and approved in the wallet, never on the site. A request that is rejected, expires or is used once cannot authorize anything else.
- Fixed endpoints. The Quantus node and the Qlyphs service the wallet talks to are set when it is built. A website cannot change them.
- Bundled code. The wallet uses its packaged scripts and dependencies, with no third-party script
origin, analytics or
eval. The web wallet downloads this package from its own origin on each visit.
What it shows you
- Your QTC balance, read from the Quantus network, with what is still waiting for finality shown apart.
- Every transaction with its status: pending, confirmed, final, or "check status" when an answer was lost and the wallet is finding out what happened.
- Before you sign: the recipient, exact amount, estimated network costs and any Qlyphs fee. Send checks reserve estimated fees and the minimum account balance.
Mainnet token purchases remain disabled until their post-quantum witness verification is validated. A switchable local build keeps network histories and grants separate, but its explicit carry action can reuse development phrases and addresses on mainnet; this does not create independent keys.