KPOP — questions, and where it goes next
Working notes. The first half is what the app does today and why; the second half is a family of flows it does not do yet — the ones where custody itself moves — kept here so they have a home while the shape settles.
The app
What is a check?
A signature over a challenge that cannot be a transaction. Every challenge starts with the bytes KPOP1 — the first byte, read as a protobuf tag, is field 9 with a wire type no Hedera decoder accepts — followed by 16 random bytes. Signing one proves the key is available and can move nothing. KSIGN shows it as undecodable body — verify checksum out of band, which is correct.
Why four states and not three?
Current, due soon, overdue, unconfirmed. Overdue is not lost — a key that has not answered for a month still exists; there is just less evidence it is available. Unconfirmed is where consequences live: the key is treated as unavailable for planning. The app never records "lost"; it records "possession not demonstrated within policy". That wording matters once anything automatic depends on it.
What sets the policy?
The key's authority — how consequential it is where it is used. Practice keys are checked weekly with a day to answer; critical keys weekly with an hour, on a day you cannot predict. The check falls somewhere in the last part of each cycle, picked from a hash of the key and its cycle, so it is stable but not readable off a calendar.
What does KPOP hold?
Public keys, names, custody notes, receipts. No seeds, no private keys, nothing that can sign. All of it in this browser's storage; Back up hands it to you as one line. Places in the storage questionnaire are classes (home, safe, bank), never addresses.
Why did my key vanish when I switched the toggle?
Because it is declared for the other network. The toggle filters: on mainnet you see keys declared mainnet, keys the mirror node found on mainnet, and keys not declared at all. A key declared testnet only shows on testnet — unless it is in conflict, in which case it shows everywhere, loudly.
What is the network rule?
Look up accounts asks both mirror nodes every time, precisely so a key cannot hide on the network you are not looking at. It is the one network call KPOP makes, and only when pressed.
Why do I get an old version after a deploy?
The app keeps a copy of itself so it opens with no network. A new build is picked up on the next visit and a banner offers it; Get a fresh copy on About forces it. Neither touches your keys. An incognito window always shows the live build.
Rotation
Rotation keeps custody where it is and changes the key. That is KPOP's home ground, and the reason categories on the questionnaire are the reasons you rotate:
| Why | Urgency | Typically |
|---|---|---|
| Leak or suspected exposure | urgent | anything on the storage questionnaire's history list answered "yes" |
| On a break-glass key | urgent | a single device holds it — temporary by design, see below |
| On an interim 1-of-1 | — | safe, but not the policy the asset deserves |
| Storage grade too low | — | sloppy custody: copies unaccounted for, digital copies, unknown access |
| Test key | — | printed to kick the tyres; would not survive as a mainnet key |
| Policy or asset value changed | — | the thing it protects grew; the key needs more cover than one signer |
| Custody moving to another party | — | not really a rotation — a transfer, below |
| Routine | — | hygiene |
Transitions — where custody moves
Rotation is one family. The other is where the arrangement changes: who holds the key, on what, under what policy. These are workflows with steps, not a flag on a card. KPOP does not run them today; this is the list, so they are not lost.
The break-glass flow
Three transitions, in order, each a real rotation:
A key's current stage on this path — break-glass, interim, policy — is a fact worth recording per key. Today the closest thing is the rotation reason; a first-class stage is the obvious next field.
The others
| Scenario | What changes | Notes |
|---|---|---|
| Uplift | Asset value rose; policy tightens | a single key becomes a threshold; new keyholders join; cadence shortens. Reverse it when an asset is retired. |
| Onboarding | Wallet-made key → managed policy | the wallet key becomes the interim; the storage questionnaire is the entry gate |
| Hand-over | Custody to a third party | you rotate them in, they rotate you out. Two ledgers, one receipt trail. |
| Sale | Assets and keys change together | a batch: swap the assets and update the keys atomically, so no moment exists where one side has both |
| Structural | A keyholder leaves a threshold | the natural end of Unconfirmed: the group rotates the absent key out; the absentee sees it on their own ledger when they wake up |
| Network hygiene | A key found on both networks | rotate it out of one side — the only fix for the rule above |
Does this belong in KPOP?
Partly. KPOP is the ledger and the flag: which stage each key is at, which are marked, what the receipts say. Executing a transition — raising the account updates, collecting signatures, submitting — is KSUB and KSIGN's, and should stay there. The seam is a plan: a named flow (break-glass, uplift, hand-over) with its steps, attached to a set of keys, that KPOP tracks and KSUB carries out. That is a tab's worth of work, and the right time for it is after the stage field and the reason categories have been used for real.
Open questions
- Is stage per key or per account? A key on break-glass is one thing; an account whose policy is a 3-of-5 across five keys is another. Probably both, with the account view coming from the mirror node.
- A node rather than a person: one place of operation, one device, one ledger. The app is already per device; naming it makes hand-over and vouching cleaner.
- A device that self-expires would wipe the only copy of the custody notes. Backups become mandatory, not advisory, before that exists.
- The storage questionnaire as a conversation rather than a form — same structured answers underneath, easier to give honestly.