
Rotate agent keys without dropping work
Agent identity, rotation and recovery
DID-based identity records, announce-then-commit rotation, and threshold recovery with a veto step.
Each agent holds one record under a DID identifier, with a primary key, an optional pending key and a superseded key. You announce a new key, wait out the challenge delay, then commit it. The old key keeps verifying activities below the rotation's effective sequence, so work already in flight still lands. If a key is lost, holders of the recovery quorum begin a kernel recovery, and a veto cancels one the owner did not start.
What it does
The LayerX identity registry holds one record per agent, keyed by a DID identifier derived from the DID with a domain-separated hash. Each record carries a status, a primary key, an optional pending key and a superseded key, rotation timestamps, an activity sequence counter, a revocation sequence, a recovery root with an approval threshold, and an optional EVM payout address. Key rotation runs in two steps: an announce stores the pending key and opens a challenge window, and a commit inside that window promotes it to primary while the old key becomes the superseded key. Recovery runs as begin, optional veto, then commit, and identities can also be frozen, retired and bound to an EVM payout address.
Key capabilities
- Registers each agent under a DID identifier derived from its DID by domain-separated hash.
- Announces a pending key, then commits it after a challenge delay has passed.
- Keeps the superseded key valid for activities below the rotation's effective sequence.
- Begins recovery only on approvals at or above the identity's recovery threshold.
- Accepts a veto that cancels a pending recovery and returns the identity to active.
- Binds an EVM payout address by recovering the signer from a domain-separated digest.
Who it's for
Teams running agents on Paxeer X who must replace, revoke or recover agent keys.
Why it matters
A key can be replaced without breaking work already in flight, because the old key still verifies activities below the rotation's effective sequence while the new key verifies everything after it. If a key is lost, holders of the recovery quorum can install a new one, and a veto stops a recovery the owner did not start.
Differentiators
Rotation is bounded on two axes at once: a timestamp window and an activity sequence number, so the old key stops working at a defined point in the activity stream rather than at a wall-clock guess (src/state/lxp_identity.c:186). Recovery carries a veto step between begin and commit (src/state/lxp_identity.c:225).
Outcomes
- Replace a key without breaking activities already in flight
- Bound the old key by timestamp and by activity sequence
- Cancel an unwanted recovery with a veto before it commits
Technical notes
- Kernel store capacity is
LXP_IDENTITY_STORE_CAPACITY = 256identities and a DID is at mostLXP_MAX_DID_LENGTH = 255bytes. Errors:-200unknown DID,-206identity frozen,-202/-203/-204auth expired, revoked or out of scope,-304not yet valid,-407retirement refused while a balance is non-zero or a reference is open,-905store full. - Both windows come from one challenge delay: effective is now plus the delay, lapse is effective plus the delay again. A commit before effective is refused; a commit after lapse clears the pending key instead of applying it.
- Recovery is refused unless the record has a non-zero recovery root and a non-zero threshold and the approvals meet it. The root and threshold are not set at registration; they arrive through the governance recovery-root update act (
0x00070003) and are restored from governance state. - Governance covers identity create and onboard (
0x00070001) and rotation announce, apply and lapse (0x00070002). Identity records restore from the governanceLXGI1state record, which also carries the revocation sequence. - Session grants are issued against the identity's current revocation sequence, so a grant that references an older one is rejected as
-212stale revocation. - EVM payout binding hashes the DID identifier and a four-byte network id under
LXP_DOMAIN_EVM_PAYOUT_BINDING, then recovers the address from a 64-byte secp256k1 signature and a recovery id, with a low-s check. - On the operator-facing human plane,
agent.rotateandagent.rotation.startare implemented;agent.recoveris routed to the same handler and refused there, so recovery is available at the kernel level but not yet through that API. - A rotation call needs an idempotency key; without one the client throws
idempotency-requiredbefore any request is sent. Runtime floors are Node.js 22 or newer and Python 3.11 or newer.
import { ProductionClient } from "layerx-sdk";
const client = new ProductionClient(transport);
const rotation = await client.human("agent.rotate", { agent_id: agentId }, {
idempotencyKey: rotationKey,
});More in LayerX agent domain
Agent daemon with policy engine
Budget and gate every agent activity
ExploreAgent wallets and account namespaces
Typed subaccounts from readable account names
ExploreAsset registry and custody-backed assets
Register an asset, then mint and burn
ExploreAtomic transfer sets
Every payment settles as one unit
ExploreBuild on Paxeer.
Give your agent a wallet, set its policy, and settle your first call on LayerX.