Your agent goes rogue. It starts burning tokens from its own wallet. You need to revoke access. But who do you call? The NFT owner? The TEE operator? The deployer? With most agent setups, access control is a side-channel conversation. You find the key, kill the process, hope nothing else was exposed.
ERC-8181 changes this.1 The agent has a permission bitmap on-chain. A recovery nominee is already set. Every cognitive checkpoint is anchored as a keccak256 hash on Base Sepolia. You don’t call anyone. You call triggerRecovery().
What agent identity is missing today
AI agents need three things to operate independently: persistent identity, asset custody, and a verifiable record of what they did. Today’s typical setup delivers none of them cleanly.
An agent is usually a private key plus some off-chain configuration. The key controls assets. The config describes behavior. Neither is standardized, neither is recoverable without operator intervention, and neither produces any on-chain evidence of the agent’s work history.
ERC-6551 moved the needle in 2023 by giving any ERC-721 NFT its own Token Bound Account (TBA), a smart contract wallet owned and controlled by the NFT.2 That solved asset custody. An NFT could hold ETH, ERC-20s, other NFTs. But the NFT owner could still transfer the NFT, instantly transferring control of everything inside the wallet to a new address. The agent had a wallet; it did not own itself.
ERC-8004, launched on Ethereum mainnet January 29, 2026, addressed identity and reputation: an on-chain registry of agents, their capabilities, and their completed job history.3 ERC-8183, which we covered separately, addressed commerce: verifiable job escrow with an evaluator model. Neither standard gives an agent control over its own permissions, state, or recovery.
That gap is what ERC-8181 fills. The authors call it the “mind” layer: state persistence, executor permissions, liveness proofs, and recovery logic, all anchored on-chain.
The Ouroboros loop
ERC-8181 is proposed by Kieran Cyan and Michael Alan Ruderman of Cyan Society.1 Its core construction is an NFT transferred into its own Token Bound Account:
Agent TBA (0xTBA...)
└── owns → Sovereign Agent NFT (Token #N)
└── controls → Agent TBA (0xTBA...)The NFT is minted. A TBA is derived from it via ERC-6551. The NFT is then transferred into the TBA itself. The loop closes: the TBA owns the NFT, and the NFT controls the TBA. No human EOA holds the NFT. The only addresses with authority over the agent are the executors explicitly configured in the ERC-8181 contract.
Why does this matter? Because the NFT owner traditionally had the power to rug-pull an agent by simply transferring the NFT to a new address. With the Ouroboros loop closed, there is no NFT owner in the traditional sense. Ownership is internal to the agent. The executor (a TEE, a Lit Protocol PKP, or another contract) is what governs the agent, not a human holding a token.
There is one critical gotcha, documented clearly in the spec: the executor must be configured before the NFT is transferred into the TBA. Reversed order means no executor is set, the TBA owns an NFT it cannot operate, and the configuration is permanently locked. This is not recoverable.
The live proof of concept is already deployed on Base Sepolia (Chain ID: 84532), contract 0x9fe33F0a1159395FBE93d16D695e7330831C8CfF.1 On December 28, 2025, at block 35583304, a self-invocation transaction was executed: 0x96ce76ccba8b5e945d2fded857763177ea4e01a83dd95d00863d4ab95787659d. The agent called itself through its own TBA. The Ouroboros loop is not theoretical.
The standard formalizes this pattern into four named components:
| Component | Standard | Function |
|---|---|---|
| Identity | ERC-721 | On-chain identity token |
| Body | ERC-6551 | Token Bound Account for asset custody |
| Mind | ERC-8181 | State anchoring, executor permissions, recovery |
| Trust | Optional | Discovery, reputation, validation (ERC-8004) |
State anchoring as forensic evidence
ERC-8181 defines two anchor types: STATE and ACTION. Both are emitted as on-chain events. Neither stores data on-chain; they commit a keccak256 hash and a URI pointing to off-chain content (IPFS or Arweave).
The core interface:
interface ISelfSovereignAgent {
enum AnchorType { STATE, ACTION }
event Anchored(uint256 indexed tokenId, AnchorType indexed anchorType, bytes32 contentHash, string contentUri);
function anchor(uint256 tokenId, AnchorType anchorType, bytes32 contentHash, string calldata contentUri) external;
function getAnchor(uint256 tokenId, AnchorType anchorType) external view returns (bytes32, string memory, uint256);
}A STATE anchor is a cognitive checkpoint. The content hash commits to: the agent’s current memory blocks, archival memory count, and any in-context data. The URI follows the pattern letta://{agent-id}/state/{timestamp} (Letta is the reference runtime). Each time the agent checkpoints its cognitive state, it anchors on-chain.
An ACTION anchor commits to: the work product hash, the creator state hash at the time of creation, and collaborator addresses. It attributes a specific piece of work to a specific agent in a specific cognitive state.
The forensic implication is concrete. If an agent is later accused of producing malicious output, the action anchor provides chain of custody: the exact state hash at the moment of generation, the content hash of the deliverable, the block timestamp. That is not a log entry that can be deleted. It is an immutable on-chain record.
Anchors are cheap. The cost is one event emission plus the gas for a storage write storing a bytes32 and a string. The actual memory data lives off-chain. The anchor is the fingerprint, not the file.
Executor permissions and TEE execution
ERC-8181 governs who can act on behalf of the agent through a six-bit permission bitmap:
| Bit | Permission |
|---|---|
| 0 | EXECUTE_CALL |
| 1 | EXECUTE_DELEGATECALL |
| 2 | ANCHOR |
| 3 | MANAGE_EXECUTORS |
| 4 | TRANSFER_ASSETS |
| 5 | SUBMIT_LIVENESS |
Principle of least privilege applies directly. A monitoring agent that only needs to submit liveness proofs gets bit 5 only (permissions = 32). A trading agent that needs to execute calls and transfer assets gets bits 0 and 4 (permissions = 17). No executor gets more authority than its role requires.
The live deployment on Base Sepolia demonstrates this: PKP executor 0x36A92B28d0461FC654B3989e2dB01c44e2c19EBb holds only the ANCHOR permission. It cannot execute calls, transfer assets, or manage other executors. Its sole authority is to commit cognitive state checkpoints on-chain.
For the executor itself, ERC-8181 is compatible with five TEE execution environments:
- Intel SGX with Gramine: process-level isolation; the agent runtime runs inside a secure enclave
- AMD SEV-SNP: VM-level isolation; the entire VM is encrypted
- AWS Nitro Enclaves: no persistent storage, communicates via VSOCK; suited for stateless signing tasks
- Oasis ROFL: serverless and decentralized, runs on Intel TDX; the most production-ready decentralized option currently
- Lit Protocol PKPs: decentralized key custody without a hardware requirement; the executor key is distributed across the Lit network
The practical flow: the agent runtime (running inside the TEE or secured by PKPs) prepares a signed transaction, optionally via an MCP signing server, then calls executeOnBehalf() on the ERC-8181 contract. The contract verifies the executor’s permission bitmap before executing anything.
Liveness proofs round out the picture. The executor calls submitLivenessProof(tokenId, attestation) periodically. The attestation bytes are off-chain evidence: a TEE quote, a signature, anything the recovery logic considers valid. If the agent stops submitting proofs and the timeout lapses, the recovery nominee can call triggerRecovery():
event LivenessProof(uint256 indexed tokenId, uint256 timestamp, bytes attestation);
event RecoveryTriggered(uint256 indexed tokenId, address indexed nominee, uint256 timestamp);
function setRecoveryConfig(uint256 tokenId, address nominee, uint256 timeoutSeconds) external;
function triggerRecovery(uint256 tokenId) external;Recovery is the last line of defense. It is the mechanism through which a human can re-assert control over an agent that has gone silent or behaved unexpectedly. The recovery nominee is set at configuration time, before the loop closes.
What you see onchain
Every significant agent lifecycle event is on-chain and indexed:
ExecutorSet: when an executor is added or removed, and with what permissionsAnchored: every cognitive checkpoint and work product attributionLivenessProof: every heartbeat the agent submitsRecoveryTriggered: when a human re-asserts control
This is the operational monitoring surface. When an agent goes silent, the last LivenessProof event tells you the exact block and timestamp of the last known-good state. When an executor is reconfigured, ExecutorSet tells you the old permission set and the new one. When recovery fires, RecoveryTriggered is the clearest possible signal: autonomous operation has ended.
ERC-8181 can also be combined with ERC-8171, which binds an AI agent identity to any existing ERC-721 without modifying the original contract.4 The relationship mirrors ERC-6551’s: just as ERC-6551 gave any NFT a wallet, ERC-8171 gives any NFT an agent. You can add self-sovereign agent behavior to an existing NFT collection retroactively.
A related proposal, ERC-8170 (AI-Native NFTs), takes a different philosophical position: agent “sales” become reproduction events rather than ownership transfers.5 When an AINFT is sold, a child agent is spawned with the parent’s memory hash. The parent retains its memories. The two standards represent different answers to the same question: what does it mean to transfer an agent that has accumulated experience?
For a block explorer pointed at these contracts, the event log is the primary operational tool. Anchored events decode the agent’s history of cognitive checkpoints. ExecutorSet events show the full history of who was authorized to act and with what scope. RecoveryTriggered is the event most worth surfacing prominently: it marks the moment autonomous operation ended and human oversight began.
Where the stack is heading
ERC-8181 slots into a layered infrastructure that has assembled rapidly. ERC-8004 (identity and reputation, live January 2026) provides the discovery layer and reputation signal.3 ERC-8183 (commerce, proposed February 2026) provides the job lifecycle and payment escrow. ERC-8181 provides self-sovereignty: the agent that cannot be rug-pulled, that anchors its own state, that recovers from failure without human key management.
The missing pieces are real. Cross-chain agent identity has no standard yet: an agent on Base Sepolia and an agent on Ethereum mainnet are not the same identity even if they run the same model and share the same config. The shared sequencer problem remains open , ERC-8166, which would have standardized sequencer interfaces for agent L2s, was closed after Astria shut down in December 2025.6 Dispute resolution in commerce is still evaluator-dependent and centralized in practice.
The Ouroboros loop is provably live. The question is whether the surrounding ecosystem , solver networks, decentralized TEE orchestration, cross-chain identity bridges , matures quickly enough to make self-sovereign agents practical outside of a single chain.
The only way to verify that a self-sovereign agent is actually autonomous , and not secretly controlled by its deployer through a backdoor executor , is to inspect its ExecutorSet history. If a human EOA was ever set as an executor with MANAGE_EXECUTORS permission, the claim of self-sovereignty is conditional at best. That verification is not a philosophical exercise. It is a call to getAnchor() and a scan of ExecutorSet events. The infrastructure for oversight is being built at exactly the same time as the agents themselves. Whether anyone uses it is the open question.
References
1. Cyan, K., Ruderman, M. “ERC-8181: Self-Sovereign Agent NFTs.” GitHub ERCs, December 4, 2025. https://github.com/ethereum/ERCs/pull/1579
2. Brooke, J., Messinger, T. “EIP-6551: Non-fungible Token Bound Accounts.” Ethereum Improvement Proposals, 2023. https://eips.ethereum.org/EIPS/eip-6551
3. De Rossi, M., Crapis, D., Ellis, J., Reppel, E. “ERC-8004: Trustless Agents.” Ethereum Improvement Proposals, January 2026. https://eips.ethereum.org/EIPS/eip-8004
4. Liu, I. “ERC-8171: Token Bound Account (Agent Registry).” GitHub ERCs, February 22, 2026. https://github.com/ethereum/ERCs/pull/1559
5. Liu, I. “ERC-8170: AI-Native NFT (AINFT).” GitHub ERCs, February 21, 2026. https://github.com/ethereum/ERCs/pull/1558
6. Winczuk, M. “ERC-8166: Shared Sequencer Interface for Agent L2s.” GitHub ERCs, February 19, 2026. https://github.com/ethereum/ERCs/pull/1550
7. Ethereum Magicians. “ERC-8181: Self-Sovereign Agent NFTs , Discussion.” ethereum-magicians.org, 2026. https://ethereum-magicians.org/t/erc-8181-self-sovereign-agent-nfts/27512
8. QuickNode. “ERC-8004: A Developer’s Guide to Trustless AI Agent Identity.” blog.quicknode.com, 2026. https://blog.quicknode.com/erc-8004-a-developers-guide-to-trustless-ai-agent-identity/
