Keys and recovery

Where the keys come from

Nagare asks your wallet to sign one fixed message and hashes the signature into a seed. Every key it needs comes out of that seed by a fixed path: sender keys by slot, a recipient key per schedule, keys for offers you make. The signature moves no funds and the seed is held in memory for the session only.

This is why the browser holds no secrets worth stealing. It stores public keys and the path each one came from, so it knows which schedules are yours, and it asks your wallet again whenever it needs to actually sign something.

A new browser, or a cleared one

Connect your wallet on Your schedules. The first time a wallet connects to a browser with an empty list, Nagare signs once and reads the contract looking for keys that match, and everything it finds comes back. There is a Check again button on the same page for a schedule that was transferred to you afterwards.

Recovery finds the schedules you opened, the schedules whose recipient key came from your wallet, and the offers you placed. It reads only the contract, so it works from a browser that has never seen Nagare before.

An offer key does double duty. It authorizes the offer while it stands, and it becomes the recipient key if the holder accepts, because that is the key the contract writes to the schedule. Nagare promotes it to your recipient role the moment the contract shows the sale, so a schedule you bought needs nothing extra from you.

Each offer gets its own key, tied to the round it was made in, and the escrow behind an offer stays with that round until you reclaim it. An offer that ran out therefore keeps its own key and its own money, separate from anything you offer later.

The exception: a key that arrived in a claim link

A claim link carries a key that your sender generated in their browser. It was never derived from your wallet, so your wallet cannot rebuild it and recovery cannot find it. That key exists in two places: the browser that opened the link, and the browser of whoever created it.

Clearing site data in that browser before re-keying therefore puts the schedule out of your reach for good, and so does losing the device. Re-keying to a key from your own wallet ends that exposure, which is why the claim page pushes you to do it immediately. Until you do, the sender can also still act as you.

Forgetting a key on purpose

A sender who used a claim link keeps a copy of the recipient key so the link can be rebuilt. Forget on the schedule page drops that copy, which is the only way to give up that hold before the recipient re-keys. It is irreversible from that browser, and if the recipient never received the link, nobody can reach the schedule afterwards.

Two limits

• One signature rebuilds 32 sender keys, so a wallet holds at most 32 cancelable schedules. Uncancelable ones consume no slot.
• A key reused across two schedules links them to each other. Nagare derives a fresh sender key per schedule to avoid that, which is why the slots exist.

Switching wallets

Roles are scoped to the wallet that derived them, so connecting a different wallet hides the first one’s schedules. They come back when you reconnect the original. A schedule you can see but hold no key for still shows all its public detail, because everything on that page is readable by anyone.