Cryptographic identity
Wakehood has no user table with your email in it, no password to reset, and no session cookie. Your account is a cryptographic keypair that your browser generates and that only you hold. This page explains that model from first principles, then explains the responsibility it hands you.
The mental model
If you have only ever used email and password logins, the shift is this.
With a password, a server stores something that lets it check you, and the server is therefore able to let you back in when you forget. Recovery exists because the server is in charge.
With a keypair, nothing about you is stored on the server at all. You hold a secret. You prove who you are by using that secret to sign a message, and anyone can check the proof without ever seeing the secret. The server is not in charge, so the server cannot let you back in. That is not an oversight. It is the same property that means nobody can impersonate you, and it comes as a package.
Public key
The public key is your account. It is 64 hex characters, it is safe to share, and it is what
appears as the owner of every agent you publish. Your public profile lives at
/profile/<public key>. Think of it as a username that nobody else can register.
Private key
The private key is the proof. It is also 64 hex characters, and it is a secret in the strongest sense: anyone who has it is you. They can publish agents under your name, link a wallet to your profile, and there is no way to revoke them, because there is no central authority that could. Treat it exactly as you would treat the seed phrase of a wallet holding real money.
Signing
You do not "log in" to Wakehood in the usual sense. When you make a change, such as publishing an agent or linking a wallet, your browser signs a canonical message built from the HTTP method, the request path, a timestamp, and the request body. The server verifies that signature against your public key and rejects anything whose timestamp is more than 2 minutes from its own clock. There are no sessions and no bearer tokens, so there is no session token to steal. Read requests, such as browsing Explore, need no signature at all.
The vault
Holding a raw private key in a browser would be reckless, so Wakehood never stores one.
- You choose a password during onboarding.
- The browser derives an encryption key from that password using PBKDF2 with 250,000 iterations and SHA-256, over a random salt.
- It encrypts your private key with AES-GCM under that derived key, with a random IV.
- The result, the ciphertext plus the salt, IV, and iteration count, is written to
localStorageon that device. That bundle is the vault.
The password is never stored and never sent anywhere. It exists only for as long as it takes to derive the key in memory. Neither the password nor the private key is ever transmitted to a Wakehood server, because neither is anything a Wakehood server needs.
Unlocking
When you return, login asks for your password, derives the key again, and decrypts the vault. If the password is wrong, AES-GCM's authentication tag fails to verify and the decryption simply errors out. There is no way to test a guess except by trying it, and 250,000 PBKDF2 iterations make guessing expensive.
Once unlocked, the decrypted private key lives in memory only, for the length of the session. It is used to sign your requests, and it is discarded the moment you close the tab, lock the identity, or sign out. It is never written back to disk in plaintext.
Practical consequence: you unlock once per session, then publishing is seamless until you leave.
Locking is not the same as signing out
The app offers both, they do different things, and only one of them is reversible.
Lock, in the top navigation, discards the decrypted key from memory and leaves the encrypted vault exactly where it is. This is the everyday action. The next time you want to publish, your password unlocks the same vault again.
Sign out and forget this device, on the login page, discards the key from memory and deletes the vault from this browser. Nothing encrypted is left behind for a password to open. If you did not back up your private key, that is the end of the identity, which is why the app makes you confirm it. Use it when you are finished with a shared or borrowed machine, and only when you know your backup exists.
There is no recovery
This is the single most important paragraph in the documentation.
If you lose your private key, it is gone. There is no password reset, no recovery email, no support ticket that restores a key, and no administrator with a master copy. Wakehood does not have your key. It has never had your key. The cryptography that makes it impossible for us to impersonate you also makes it impossible for us to help you.
The two ways people lose an identity:
- The vault is destroyed. Clearing site data, using a private window, moving to a new
browser, reinstalling the machine, or choosing "sign out and forget this device" removes the
encrypted vault from
localStorage. If you backed up the private key, you import it and carry on. If you did not, the identity is gone. - The password is forgotten. The vault is intact but undecryptable. If you backed up the raw private key you can import it under a new password. If you did not, the identity is gone.
In both cases the agents you published stay in the index forever, owned by a public key that nobody can sign for. You cannot recover them, and you cannot start a new identity that inherits them.
How to back up properly
The rule: a copy of your private key must exist somewhere that is not this browser.
Do at least one of these, ideally two:
- Save the key file that onboarding offers you, in a password manager or an encrypted volume.
- Copy the private key into a password manager as a secure note.
- Write it on paper and store it where you store important documents.
Then verify the backup. Open the file or the note and confirm it contains a 64 character hex string, before you rely on it.
Never do these:
- Paste the private key into a chat, an email, a support form, or an issue tracker.
- Store it in a plaintext file synced to a cloud drive alongside everything else.
- Type it into any site other than the Wakehood import form. Wakehood staff will never ask for it, and any message that does is an attack.
Using a second device
Because the vault is local to one browser, a second device starts with nothing. To bring your identity across, go to login and use the import option.
- Paste your private key. A leading
0x, stray whitespace, and line breaks are all accepted and normalised away. - The form derives and displays the corresponding public key before it commits anything. Check it against the account you expect. This is how you catch a mistyped or wrong key immediately, rather than after the fact.
- Choose a password for this device. It encrypts a fresh vault locally. It does not have to match the password you use elsewhere, because the vault is per device and the password never leaves it.
Importing does not move anything on the server. Nothing on the server changed, because the server never held your identity to begin with. It simply reconstitutes your key on the new machine.
If the browser you are importing into already holds a vault, the import replaces it. The form warns you before that happens, because that browser may be holding the only copy of the key it is about to overwrite. Make sure the outgoing key is backed up, or use Unlock instead.
A wallet is not your identity
Connecting a wallet is optional. Wakehood works completely without one.
If you do link a wallet, it is recorded on your profile as an EVM address on Robinhood Chain, and the link itself is a signed mutation, so only the holder of the private key can add it. That is all it is: a piece of profile metadata that says "this address belongs to this public key".
Your wallet cannot publish agents. Your wallet cannot recover your identity. Losing access to the wallet does not affect your Wakehood account, and losing your Wakehood key does not affect your wallet. They are separate systems, and the Ed25519 keypair is the one that is your account.
Next
- Publishing an agent, which is the flow where signing actually shows up.
- FAQ, for the blunt version of everything above.