Identity

A .human address starts as a pure function of one public key. An identity lets that address outlive the key: the set of keys that control it is kept in chain state, so keys can be rotated and, if lost, recovered — without changing the address, its balance, names or history.

Before and after the first rotation

State	Who controls the address
Never rotated, no recovery set up	The key the address was derived from (address = f(public key))
Identity record exists	Only the keys in the record. The original key stops working once it is removed

The record is created the first time you rotate keys or set up recovery. Paid names (.node, .app, .vault, .agent) follow the identity of the .human wallet that owns them.

curl -s "$GATEWAY/api/v1/identity/neuro:<15 hex>.human"
# { "address": "…", "keys": ["<pk1>", "<pk2>"], "version": 2, "rotated_at": 4210, "recovery": { … } }

Rotating keys

POST /api/v1/identity/rotate with owner, add (a public key to add, or empty), remove (a public key to remove, or empty), signed by a currently active key over:

nc-rotate|<owner>|<add>|<remove>|<nonce>

• The last remaining key cannot be removed.
• The signature covers the exact change, so no one can alter it on the way.
• Applied in consensus on every validator.

Typical move to a new device: add the new key from the old device, then remove the old key with the new one.

Social recovery

If every key is lost, guardians can restore access.

Set up

POST /api/v1/identity/recovery/setup — signed by an active key:

Field	Rule
guardians	One or more .human addresses, not your own
threshold	How many guardians must approve: 1 to the number of guardians
timelock	Blocks to wait after the threshold is reached, giving you time to veto

Recovery is available for .human addresses only.

Recover

1. Request — from a new device, POST /api/v1/identity/recovery/request with target (your address) and new_key, signed by the new key. Status pending.
2. Approve — each guardian calls POST /api/v1/identity/recovery/approve (target, guardian). When approvals reach the threshold the request becomes armed, with executes_at = now + timelock.
3. Execute — at executes_at every validator replaces the identity's keys with new_key, automatically.

At any point before execution:

Who	Can	Endpoint
You, with any active key	Veto it	POST /api/v1/identity/recovery/cancel
A guardian	Reject it	POST /api/v1/identity/recovery/reject
The requester	Withdraw it	POST /api/v1/identity/recovery/withdraw

Reads: GET /api/v1/identity/recovery/:addr (configuration and open request), GET /api/v1/identity/guardian-of/:addr (whom you guard), GET /api/v1/identity/recovery/initiated/:pk (requests started by a new key).

Choose the timelock with care

The timelock is your window to notice a recovery you did not start. Too short, and colluding guardians can take the address before you react; too long, and a real recovery takes that long.

Planned

The identity record is meant to carry more than keys: a reputation built from on-chain behaviour, a zero-knowledge proof of it, and an IBC v2 packet that lets another chain read it. None of these exist yet.