/docs/operator-identity

Your operator identity

An operator identity is an ed25519 keypair. Its public key is your operator_id — the same value the directory stores as operator_pubkey. One identity spans all the nodes you run: it binds them to you (so people see who hosts them), earns you a founder ordinal, and rolls your nodes' credits into a single operator wallet. In practice: your nodes earn, your wallet collects, and your later mesh usage can spend from that combined balance. Your display name is the public, mutable handle; your contact stays private and local.

The same identity anchors stricter operator controls: signed policy manifests, policy-key rotation/revocation, redacted receipts, and the first operator-key self-service API for acceptance and privacy requests. A guided portal remains planned. This does not make an operator automatically trustworthy; it makes claims easier to attribute, verify and revoke.

In plain terms: your identity is a key your node creates for you — it ties all your nodes to one name and one credit wallet, and earns your founder number. Credits are an internal mesh reciprocity unit, not fiat money. Back up the recovery phrase it prints— that's the only way to restore it. The full guide covers create, back up, and recover.

The key is the identity. Whoever holds the secret key controls the operator identity — its nodes, its founder ordinal, its wallet. There is no central account recovery. Treat the key like a crypto wallet seed: back it up, encrypt it, never share it.

1. Create it

The wizard generates a key-backed identity and saves it to ~/.iicp/operator.json:

iicp-node init       # prompts for display name + contact, generates your ed25519 key

A legacy op-<uuid> identity (from very early builds) is notkey-backed — it cannot sign, so it can't bind nodes. Move it aside and re-run init to regenerate a real ed25519 identity (your display name + contact carry over).

2. Associate it with your nodes

Serving a node signs an operator→node delegation (ADR-045) on registration. The directory verifies it and binds the node to your operator_pubkey:

iicp-node serve --node mynode     # registers + serves; binds the node to your identity

Once bound, your node shows “Operated by <your name> ✓ verified operator” in the directory, and its earnings join your wallet. The per-node ledger remains as the audit trail, but the operator wallet is the balance users should think about. Change your public name any time (signed, no re-register):

iicp-node operator rename "NewDisplayName"

3. Protect the secret

~/.iicp/operator.json holds your operator_secret (the ed25519 seed). Encrypt it at rest with a passphrase:

export IICP_OPERATOR_PASSPHRASE='a long passphrase you keep safe'
iicp-node operator encrypt        # seals operator_secret with AES-256-GCM (PBKDF2)

Never commit operator.json to git; never paste the secret anywhere; the directory only ever sees your public key.

4. Back up & recover

Back up ~/.iicp/operator.json (encrypted) to a secure place — a password manager or an encrypted drive. That one file is your identity.
Restore on a new machine by copying it back to ~/.iicp/operator.json(and your passphrase to decrypt). Re-run serve — your nodes re-bind to the same identity, keeping your ordinal and wallet.
Lose the key and you lose the identity: its founder ordinal and wallet are not recoverable. There is no reset.

5. Rotation / succession

If a key must change (compromise, hardware loss), founder standing is carried by signed FOUNDER_SUCCESSIONevents on the directory's hash-chain (key-rotation, ADR-037). This is an advanced flow — until it's self-serve, contact the maintainers if you need to rotate a key that holds a founder ordinal.

6. Signed self-service requests

The directory can issue a five-minute, one-use challenge for your public operator key. Your local client signs acceptance, export, restriction, or anonymisation requests; the private key never leaves your machine. Use the operator rights guide for the safe command flow and a local-only receipt viewer:

POST /api/v1/operator/challenge
POST /api/v1/operator/acceptance
POST /api/v1/operator/dsr/export
POST /api/v1/operator/dsr/restrict
POST /api/v1/operator/dsr/anonymize

iicp-node operator dsr export --output ~/iicp-directory-export.json
iicp-node operator dsr restrict --yes
iicp-node operator dsr anonymize --yes

Mutating rights requests require an explicit signed confirmation. Responses are not cached and use only the authenticated operator as their selector. The byte-level signing contract is defined in IICP-DIR §3.16 and implemented by all three official SDKs.