wallet · the phone's vote
the phone's key: …A P-256 key this browser holds (non-extractable, in IndexedDB). Turnkey knows it as the API key of the phone user, tagged human: its vote completes any co-signed activity, and it can do nothing else (the DENY guardrails hold for every non-root user). Register it once: Turnkey dashboard → Users → create phone → API key → paste the public key → tag human.
The dashboard's Create API key GENERATES the pair and shows it once — it has no field for a public
key we made here. Registering one we made is an API call (
CREATE_API_KEYS), and that is denied to
every non-root user, so this is the way in without a policy edit. Understand the trade: this private key
existed in plaintext, on a screen and probably in a clipboard, which the key above never did. It can only
vote, and root can delete it in the dashboard in two clicks — treat it as the rehearsal credential it is.
Paste both values here, in this page. Never into a chat, a terminal, or a file.
the phone's passkey: …A passkey demands a fresh biometric for every vote — the difference between "this phone was unlocked" and "you pressed your thumb to this vote". It is bound to this page's domain () and works nowhere else, so mint it on the host you will vote from. Whether the private key stays in this device's secure hardware or is synced by a password manager is the authenticator's choice, not ours: the flags below say which. Minting costs the vendor nothing — Turnkey learns of it only when the wallet submits CREATE_AUTHENTICATORS, which the DENY guardrails forbid until the narrow rule is live.
no activity in the link. A link looks like …/#a=<activity id>&c=<card>