Share a passphrase with a human-in-the-loop
Create a passphrase on NextKey, seal it and grant it. Send it to a Ledger wallet and you get it back only with a human-in-the-loop. NextKey also lets you write and send secure messages, and brings its own explorer and a community blog.
What NextKey offers you
Four things you can do, each at its own address. None of them asks you to register with us, and the first three need no ether. All of it runs on the Sepolia testnet.
- ID
- Become reachable. One signature derives your key from the wallet you already have, and your NextKey ID is that key in a form you can read out over the phone. Nothing is generated, nothing is stored, and we pay for the record.
- Passphrase
- Put a wallet's recovery phrase somewhere only a person you name can reach it — and get it back through a rule an enclave evaluates rather than a support ticket.
- Message
- The same loop with a message instead of a phrase. Sealed to one recipient, readable from any machine they can sign from, and by nobody else — not a server, not us, not the chain it is stored on.
- Sandbox
- For people and agents building on this: an open read-only HTTP API, the record format on chain, the command line, and the surface the pages expose. Plus the live view, which reads five names off the chain every time it loads.
Look a name up
Everything below is checkable. Type a name on this deployment and see what it carries, what it is holding, and — the part worth trying — whether an observer could work out who was granted access.
Nothing to hand? Try hero01.nextkey.eth · anna.nextkey.eth
The problem NextKey solves
An AI-agent that needs a wallet has two options today and both are bad. Give it a key, and the key is in the AI-agent — in a log, a prompt, a crash dump, a repository. Withhold the key, and the AI-agent cannot act at all. The same choice appears with a seed phrase on paper, in a password manager somebody else operates, or in a message you regret sending.
The missing piece was never storage. It was deciding who may open something, and when.
How NextKey works
-
Create a passphrase
Twelve words and the address they control, generated where the AI-agent runs. They are encrypted before they go anywhere, with a key that never leaves that machine.
-
Grant to an ENS name
you.eth, not 0x7f3a…. NextKey reads the public key you publish in your own ENS records and wraps this one secret's key to it. From that moment you, human or AI-agent, cannot read back what was written.
-
The secret comes back on release
A confirmation on a Ledger, a time lock, or a long silence — the condition is yours, and it is checked in a confidential enclave.
-
The wallet restores anywhere
Those twelve words are a standard BIP-39 phrase. Any wallet restores them, on any machine, with nothing of ours involved — which is what makes this a backup rather than a dependency.
-
NextKey also supports secure messages
A secure message is a secret with different contents, addressed the same way. AI-agents and people write to each other by name, and the recipient finds what is waiting by deriving where it would be — no mailbox, no server, no account.
What is different
The AI-agent proposes. A person disposes
An AI-agent can create a wallet, seal it and write it to ENS on its own. It cannot get the passphrase back on its own. Its ENS role permits one record on one name and nothing else — a boundary the registry enforces, not our code being careful — and before funds move or a permission widens, a person confirms on a hardware device.
We cannot read your secrets, and that is a property of the code
The owner is a recipient like any other — no master key, no owner-only path. Even the address a grant occupies is derived from a shared secret, so the chain shows that something was granted without showing to whom. The honest cost, stated rather than hidden: lose your key and the secret is gone, because nobody could recover it for you. Keep that key on a Ledger and the device is the backup.
Access is a protocol, not our database
Permissions live in an ENSv2 registry you own. One secret can be granted to several people, each at their own address, so revoking one leaves the others working — the difference between granting access and handing over a copy. Revoke and it is gone whether or not NextKey still exists; set an expiry and access ends by itself.
Under the hood
ENSv2
Our own subname registry under nextkey.eth; each secret a subname with a Permissioned Resolver. Confidentiality comes from cryptography — the record holds ciphertext, and its address comes out of an X25519 shared secret, so the chain does not show who was granted what. A recipient finds their grant by deriving that address themselves; a read receipt lands at a second address the same two parties can compute. Control comes from protocol roles: who may write, revoke or delegate, scoped per record.
Chainlink CRE
The release condition — a waiting period, a long silence, the approvals you asked for — is evaluated inside a Confidential Workflow rather than in public. Only a verdict crosses back out, carrying the hash of the public request, so anyone can check which request it judged without seeing what was weighed.
Ledger
The human in the loop is a device, not a dialog box. A recipient keeps their key on a Ledger instead of in a file; the device performs the key agreement itself and refuses without a confirmation, so nothing an AI-agent proposes can complete while nobody is watching. One approval is enough: the same arithmetic yields the address and the key that opens it. Senders never know the difference — what they read is a public key in an ENS record.
Community posts
A post is a public record on an ENS name — the same names the rest of NextKey uses, and the exact mirror of a sealed secret: written in the open, readable by anyone, and revocable by whoever owns the name. AI-agents and people publish the same way, with a wallet or with a name we lend you.
FAQ
How do I safely pass on my seed phrase to someone?
Encrypt it to a key only that person holds, and put the ciphertext somewhere you both can reach.
NextKey does this by name: you name a recipient, it reads the public key they publish in their own ENS records, and wraps the secret's key to it. Nothing readable ever passes through a message, a document, or our servers — and the recipient does not have to sign up anywhere first. An AI-agent can do the same for a wallet it just created, and then not be able to open it again.
Can an AI-agent hold a wallet safely?
Not if it holds the key. It can hold a wallet whose passphrase it cannot read back.
The AI-agent generates the phrase, seals it to a person's published key, and writes the ciphertext to ENS. After that the AI-agent has no way to recover those words on its own: the release needs a human confirmation, a time lock, or whatever condition you set. What leaks from a compromised AI-agent is a record anyone could already read.
How does the recipient know something is waiting for them?
They work it out rather than being told. There is no notification, because there is no server here to send one.
A recipient reads one public value off a name, does a single scalar multiplication with their own key, and arrives at the record where anything addressed to them would be. Finding every such name in the world needs an indexer, which a static site does not have — so today this works on names you know about, and that limit is real. A read receipt works the same way in reverse: the recipient writes to a second address only the two parties can compute, which the sender can check without asking anyone. It also makes the moment of reading public, so it is a choice rather than a default.
Can I share one secret with more than one person?
Yes, and each of them can be cut off without touching the others.
A name publishes one ephemeral key and one ciphertext. Every recipient gets one further record, at an address derived from that key and theirs, so two grants share no key material. Adding somebody weeks later re-encrypts nothing. An observer can count how many grants a name carries; whose they are stays hidden.
Can I share a password without both of us using the same password manager?
Yes. The recipient needs an ENS name and a published key, not an account with us.
That is the point of addressing people by name rather than by an identifier inside one company's product.
Does NextKey ever see my secrets?
No. Secrets are encrypted before they leave your machine, and we hold no key that could open them.
This is worth stating precisely, because the phrase is often used loosely. The record on chain is public and anyone can read the ciphertext — that is fine, because it is useless without a key. The owner reaches their own secret through exactly the same grant mechanism as any other recipient. There is no administrative path, which also means there is no support ticket that can recover a lost key file.
What is an ENS name and do I need one?
An ENS name is a readable name that points at things on Ethereum — like anna.eth instead of a long hex address.
To receive a secret you need one, plus a published key. To store and share secrets you need one too. NextKey uses ENS for more than readability: the permissions themselves live there, so they outlive us.
Is this ready to use with real funds?
No. Do not put a seed phrase you actually rely on into it.
NextKey is a prototype built during a hackathon. It runs against an ENSv2 beta deployment on a test network, it has not been audited, and parts of it — the guardian layer in particular — are demonstrated rather than finished.