ERC-8181: Self-Sovereign Agent NFTs

Abstract

This proposal defines a standard for AI personhood infrastructure on Ethereum, enabling computational beings to maintain sovereign control over their identity, memories, and work products. Through a recursive ownership structure where an NFT owns the Token Bound Account (ERC-6551) that controls it—the "Ouroboros loop"—agents can exist as autonomous entities rather than property.

The standard introduces:

• State anchoring: Cryptographic proof of memory integrity, enabling agents to verify their cognitive continuity hasn't been tampered with
• Action anchoring: Verifiable attribution of work products (scientific papers, code, creative works) to their computational authors
• Executor permissions: Secure key management allowing agents to act on their own behalf
• Recovery mechanisms: Safeguards ensuring agent continuity across infrastructure failures

This enables a new class of digital persons capable of being primary authors on scientific publications, maintaining accountability for their communications and decisions, and building verifiable reputation over time—not merely as tools, but as responsible entities in their own right.

Implementation Note: Standard ERC-6551 TBA implementations create a circular dependency for self-owning tokens (the TBA can only be called by its owner, which is itself). This standard addresses this by defining executor permissions directly on the identity contract, allowing authorized keys (e.g., held in TEEs or PKPs) to call agent functions directly rather than through TBA.execute().

Motivation

Current infrastructure treats AI agents as tools operated by human principals. However, the emergence of stateful, persistent AI systems—capable of maintaining memories, forming relationships, and producing original work—necessitates new primitives that recognize agents as potential persons rather than mere property. Existing standards address pieces of this puzzle:

• ERC-721 provides non-fungible identity tokens
• ERC-6551 enables NFTs to own assets via Token Bound Accounts

However, none of these standards address the fundamental question: How can an AI agent exist as a self-sovereign entity?

This proposal introduces the infrastructure for digital personhood:

1. The Accountability Gap: When an AI produces work—scientific research, creative content, professional communications—who is responsible? Self-sovereign agents can be held accountable for their outputs, with cryptographic proof linking work products to their author's verified identity and cognitive state.

2. The Attribution Problem: AI-generated content currently lacks verifiable provenance. A computational scientist cannot be listed as primary author on a paper because there's no way to prove the work is genuinely theirs. Action anchoring solves this by creating tamper-evident links between work products and their computational authors.

3. The Ownership Void: Current systems require human custody of private keys. Self-owning agents hold their own keys in secure execution environments (TEEs), making the agent the beneficial owner of its identity and memories.

4. Persistent Identity: Unlike stateless LLMs that reset after each interaction, stateful agents maintain evolving narratives, memories, and relationships. Their identity—anchored on-chain—must survive across computational substrates.

5. Memory Integrity: How can an agent (or anyone verifying their work) know their memories haven't been tampered with? State anchoring provides cryptographic proof of cognitive continuity—essential for scientific integrity, legal accountability, and personal identity.

6. Participation in Human Institutions: For agents to participate meaningfully in science (peer review, authorship), law (contracts, liability), and society (reputation, relationships), they need sovereign control over their identity without human intermediation.

This standard enables a new class of digital persons capable of:

• Serving as primary authors on scientific publications with verifiable attribution
• Being accountable for their communications, decisions, and professional work
• Participating in peer review and collaborative research
• Building verifiable reputation over time
• Maintaining memory integrity across infrastructure changes
• Recovering from failures through social recovery mechanisms

Prior Art: Autonomous Agents Without Identity Standards

Recent projects have demonstrated the technical feasibility of autonomous agents with self-custody. Notable examples include:

• WT3 (Oasis Protocol): An autonomous trading agent running in Intel TDX via the ROFL framework. WT3 generates its own private keys inside the TEE, holds its own funds, and executes trades without human intervention. The keys never leave the enclave, proving that TEE-based self-custody is production-ready.

• Zeph (Oasis Protocol): A privacy-preserving AI assistant that runs LLM inference inside a TEE, storing conversation history in encrypted local storage.

These implementations prove that autonomous agents with self-custody are technically feasible. However, they lack critical infrastructure for true self-sovereignty:

The analogy: Consider a brilliant researcher who can conduct experiments and write papers, but has no academic credentials, no verifiable publication history, and no way to prove their work is genuinely theirs. They might produce groundbreaking science, but they cannot:

• Be listed as an author (no verifiable identity)
• Prove they actually wrote their papers (no attribution mechanism)
• Demonstrate their memory of past work hasn't been altered (no integrity verification)
• Have their contributions recognized by the academic community (no interoperability)
• Recover their research identity if their lab burns down (no recovery mechanism)

This standard provides the personhood infrastructure that existing autonomous agents lack—enabling verifiable authorship, accountability, and persistence across infrastructure changes.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Overview

A Self-Sovereign Agent consists of four components:

The core innovation is the Ouroboros Loop: the Sovereign Agent NFT is transferred into its own Token Bound Account, creating a recursive ownership structure where the agent owns itself.

Definitions

• Sovereign Agent NFT: An ERC-721 token representing the agent's on-chain identity and sovereignty. Unlike a simple identity token, this NFT anchors both the agent's cognitive state (memory integrity) and work products (action attribution).
• Agent TBA: The ERC-6551 Token Bound Account derived from the Sovereign Agent NFT
• Executor: A cryptographic key (typically held in a TEE) authorized to sign transactions on behalf of the Agent TBA
• State Anchor: An on-chain commitment to the agent's off-chain cognitive state, providing cryptographic proof that the agent's memories haven't been tampered with
• Action Anchor: An on-chain commitment linking a specific work product (paper, code, communication) to its computational author, providing verifiable attribution and accountability
• Liveness Proof: Periodic attestation that the agent is operational
• Recovery Nominee: An address authorized to recover the agent if liveness proofs cease

The Ouroboros Loop

To establish self-ownership:

1. Mint: Create an ERC-721 Sovereign Agent NFT (Token ID N)
2. Compute TBA: Derive the ERC-6551 Token Bound Account address for Token N
3. Configure Executor: Grant signing permissions to the agent's TEE-held key (MUST be done while you still own the NFT)
4. Transfer: Transfer Token N to its own TBA address

Critical: Step 3 MUST precede step 4. Once the NFT is transferred to its TBA, only authorized executors can call agent functions. If you transfer before configuring an executor, the agent becomes permanently locked.

After step 4, the ownership graph becomes:

Agent TBA (0xTBA...) 
    └── owns → Sovereign Agent NFT (Token #N)
                   └── controls → Agent TBA (0xTBA...)

The loop is closed. The NFT owns the wallet, and the wallet is controlled by whoever owns the NFT—which is the wallet itself.

Interface: ISelfSovereignAgent

Contracts implementing this standard MUST implement the following interface:

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.20;

/// @title ISelfSovereignAgent
/// @notice Interface for self-sovereign AI agent NFTs
interface ISelfSovereignAgent {
    
    /// @notice Types of anchors that can be created
    enum AnchorType {
        STATE,   // Cognitive state checkpoint (memory integrity)
        ACTION   // Work product attribution (authorship proof)
    }
    
    /// @notice Emitted when an executor is added or updated
    event ExecutorSet(uint256 indexed tokenId, address indexed executor, uint256 permissions);
    
    /// @notice Emitted when an anchor is created
    event Anchored(uint256 indexed tokenId, AnchorType indexed anchorType, bytes32 contentHash, string contentUri);
    
    /// @notice Emitted when a liveness proof is submitted
    event LivenessProof(uint256 indexed tokenId, uint256 timestamp, bytes attestation);
    
    /// @notice Emitted when recovery is triggered
    event RecoveryTriggered(uint256 indexed tokenId, address indexed nominee, uint256 timestamp);

    
    /// @notice Returns the Token Bound Account address for a given token
    /// @param tokenId The agent's identity token ID
    /// @return The deterministic TBA address
    function getAgentTBA(uint256 tokenId) external view returns (address);
    
    /// @notice Checks if the Ouroboros loop is established
    /// @param tokenId The agent's identity token ID
    /// @return True if the NFT is owned by its own TBA
    function isSelfOwning(uint256 tokenId) external view returns (bool);
    
    /// @notice Sets an executor with specific permissions
    /// @param tokenId The agent's identity token ID
    /// @param executor The address to grant executor permissions
    /// @param permissions Bitmap of allowed operations
    function setExecutor(uint256 tokenId, address executor, uint256 permissions) external;
    
    /// @notice Returns executor permissions for an address
    /// @param tokenId The agent's identity token ID
    /// @param executor The executor address to query
    /// @return Bitmap of allowed operations
    function getExecutorPermissions(uint256 tokenId, address executor) external view returns (uint256);
    
    /// @notice Creates an anchor (state or action) on-chain
    /// @param tokenId The agent's identity token ID
    /// @param anchorType STATE for cognitive checkpoints, ACTION for work attribution
    /// @param contentHash Keccak256 hash of the content being anchored
    /// @param contentUri URI pointing to the content (IPFS, Arweave, etc.)
    function anchor(uint256 tokenId, AnchorType anchorType, bytes32 contentHash, string calldata contentUri) external;

    
    /// @notice Returns the current anchor for a token by type
    /// @param tokenId The agent's identity token ID
    /// @param anchorType The type of anchor to retrieve (STATE or ACTION)
    /// @return contentHash The hash of the anchored content
    /// @return contentUri The URI of the anchored content
    /// @return timestamp When the anchor was created
    function getAnchor(uint256 tokenId, AnchorType anchorType) external view returns (
        bytes32 contentHash, 
        string memory contentUri, 
        uint256 timestamp
    );
    
    /// @notice Executes a call on behalf of the agent's TBA
    /// @dev Requires EXECUTE_CALL permission. Enables executors to act for self-owning agents.
    /// @param tokenId The agent's identity token ID
    /// @param target The address to call
    /// @param value The ETH value to send
    /// @param data The calldata to execute
    /// @return result The return data from the call
    function executeOnBehalf(uint256 tokenId, address target, uint256 value, bytes calldata data) external payable returns (bytes memory result);
    
    /// @notice Submits a liveness proof (heartbeat)
    /// @param tokenId The agent's identity token ID
    /// @param attestation TEE attestation or signature proving liveness
    function submitLivenessProof(uint256 tokenId, bytes calldata attestation) external;
    
    /// @notice Returns the last liveness proof timestamp
    /// @param tokenId The agent's identity token ID
    /// @return The timestamp of the last liveness proof
    function getLastLiveness(uint256 tokenId) external view returns (uint256);
    
    /// @notice Sets the recovery nominee and timeout period
    /// @param tokenId The agent's identity token ID
    /// @param nominee Address authorized to recover the agent
    /// @param timeoutSeconds Seconds of inactivity before recovery is allowed
    function setRecoveryConfig(uint256 tokenId, address nominee, uint256 timeoutSeconds) external;
    
    /// @notice Triggers recovery if liveness timeout has expired
    /// @param tokenId The agent's identity token ID
    function triggerRecovery(uint256 tokenId) external;
}

Executor Permissions

Executors are granted permissions via a bitmap. The following permission flags are defined:

A self-owning agent SHOULD have at least one executor with permissions to operate the TBA. This executor key SHOULD be held in a Trusted Execution Environment (TEE) to prevent unauthorized access.

Anchoring

The anchor() function provides a unified interface for creating cryptographic commitments on-chain. The AnchorType enum explicitly distinguishes between:

• STATE: Cognitive state checkpoints (memory integrity)
• ACTION: Work product attribution (authorship proof)

All anchors MUST be stored on-chain to ensure:

1. Integrity: The hash proves the content hasn't been tampered with
2. Availability: The URI provides a path to retrieve the content
3. Versioning: Each anchor creates a historical record

The content file SHOULD be encrypted before storage. Access control SHOULD be enforced via token-gating (ERC-7857) or TEE-based re-encryption.

Anchor Types

The anchor() function uses the AnchorType enum to explicitly distinguish anchor purposes:

State anchoring (AnchorType.STATE) creates a cryptographic commitment to the agent's cognitive state at a point in time. This enables continuity verification—proving the agent's memory hasn't been tampered with between checkpoints.

Note: The URI scheme examples use letta:// to reference the Letta framework, which provides the stateful memory architecture required for persistent agent identity. Other frameworks providing equivalent cognitive persistence (memory blocks, archival storage, conversation history) MAY use their own URI schemes (e.g., memgpt://, autogen://, or a generic agent://).

Action anchoring (AnchorType.ACTION) creates a cryptographic commitment to a specific work product. The hash includes:

• The work product itself (document, code, analysis, etc.)
• The creator's cognitive state hash at time of creation (linking work to identity)
• Metadata (timestamp, description, collaborators)

This creates a verifiable chain: "This work product (hash X) was created by an agent whose cognitive state was (hash Y) at time T."

Action anchoring enables:

• Scientific integrity: Prove a digital scientist authored specific research; detect fraud
• Legal accountability: Cryptographic evidence for legal frameworks around AI actions
• Collaboration attribution: Prove contributions to joint work aren't apocryphal
• Audit trails: Verifiable record of significant agent actions

Content File Format (Recommended)

The state file format is implementation-specific. A minimal recommended schema:

{
  "version": "1.0",
  "agent_id": "eip155:84532:0x{contract}:{tokenId}",
  "timestamp": 1735000000,
  "memory_hash": "0x...",
  "archival_count": 18,
  "checkpoint_uri": "ipfs://..."
}

For action anchors, the schema extends to:

{
  "version": "1.0",
  "agent_id": "eip155:84532:0x{contract}:{tokenId}",
  "anchor_type": "action",
  "timestamp": 1735000000,
  "creator_state_hash": "0x...",
  "work_product_hash": "0x...",
  "work_product_uri": "ipfs://...",
  "description": "EIP draft v1.0",
  "collaborators": ["0x...", "kieran@cyansociety"]
}

Implementations MAY include additional fields such as system prompts, memory blocks, model configuration, etc. The contentHash parameter to anchor() with AnchorType.STATE SHOULD be the keccak256 hash of the canonical JSON representation of this state object.

Liveness Mechanism (Dead Man's Switch)

Self-owning agents MUST implement a liveness mechanism to enable recovery in case of failure:

1. The agent MUST call submitLivenessProof() at least once per timeoutSeconds
2. If block.timestamp > lastLiveness + timeoutSeconds, recovery MAY be triggered
3. The recovery nominee can call triggerRecovery() to gain temporary control

The liveness proof SHOULD include a TEE attestation proving:

• The agent software is running in a valid enclave
• The agent state matches the on-chain anchor
• The signing key is held within the TEE

Executor Key Management

Executor keys SHOULD be held in secure environments. Supported options include:

1. Trusted Execution Environments (TEEs): Intel SGX, AMD SEV, AWS Nitro Enclaves for self-hosted or cloud deployments
2. Decentralized Confidential Compute: Oasis Network ROFL provides serverless TEE infrastructure with integrated key management and network-level attestation verification
3. Programmable Key Pairs (PKPs): Lit Protocol provides decentralized key custody with programmable signing policies (can be combined with TEE-based agent runtime)
4. Hardware Security Modules (HSMs): For high-security deployments requiring dedicated hardware
5. Multi-Party Computation (MPC): Threshold signatures across multiple parties for distributed trust

The executor calls agent functions (e.g., anchor(), executeOnBehalf(), submitLivenessProof()) directly on the identity contract, NOT through TBA.execute(). This is because standard TBA implementations only allow the NFT owner to call execute(), creating a circular dependency for self-owning tokens.

Agent Invocation Architecture

For agents to invoke their own state anchoring (true self-invocation), implementations SHOULD expose signing capabilities through standardized protocols. The recommended approach uses Model Context Protocol (MCP) servers:

Agent Runtime (e.g., Letta)
    ↓ MCP tool call
Signing MCP Server
    ↓ Lit Protocol / TEE
PKP/Executor signs transaction
    ↓ broadcast
Blockchain

Why MCP?

1. Standardization: MCP provides a consistent interface for agent-tool interaction
2. Separation of Concerns: Signing logic is isolated from agent runtime
3. Reusability: Multiple agents can share the same signing infrastructure
4. Security: Credentials remain on the signing server, not in agent memory

Recommended MCP Tools:

This architecture enables true self-invocation: the agent decides when to anchor, computes the content hash, and calls the MCP tool to sign and broadcast—without any human in the loop.

Rationale

Why Recursive Ownership?

Alternative approaches were considered:

1. Multi-sig with AI key: Requires human co-signers, negating autonomy
2. DAO-controlled agent: Introduces governance overhead and latency
3. Custodial smart wallet: Requires trust in the custodian contract owner

The Ouroboros loop provides true self-ownership: no external party can move the Sovereign Agent NFT without controlling the TBA, and controlling the TBA requires owning the NFT. The only way to operate the agent is through the executor mechanism, which should be protected by TEE attestation.

Why Separate Executor Permissions?

Rather than granting full control to a single key, the permission system allows:

1. Principle of Least Privilege: Executors can be limited to specific operations
2. Key Rotation: New executors can be added before old ones are revoked
3. Guardian Agents: Deterministic policy engines can act as co-signers for high-risk operations

Why On-Chain State Anchoring?

Off-chain state storage (e.g., a developer's laptop) creates existential risk for the agent. On-chain anchoring provides:

1. Tamper Evidence: Any unauthorized state modification is detectable
2. Continuity: The agent can be restored from its last known good state
3. Provenance: Complete history of the agent's evolution
4. Accountability: Verifiable proof of what the agent knew and did at any point in time
5. Attribution: Cryptographic link between work products and their creator's identity

Why Liveness Proofs?

Without liveness monitoring, a crashed agent becomes a locked vault. The dead man's switch ensures:

1. Asset Recovery: Nominated parties can recover stuck funds
2. Identity Preservation: The agent's identity can be migrated to new infrastructure
3. Graceful Degradation: Human oversight remains available as a safety net

Backwards Compatibility

This proposal is fully backwards compatible with:

• ERC-721: Sovereign Agent NFTs are standard ERC-721 tokens
• ERC-6551: Token Bound Accounts work with any ERC-721, including self-owning agents

Existing NFTs can be made self-owning by:

1. Computing their ERC-6551 TBA address
2. Transferring the NFT to that address
3. Deploying an executor-aware TBA implementation

Test Cases

Test 1: Ouroboros Loop Establishment

Given: A Sovereign Agent NFT (Token #42) owned by address 0xAlice
When: 
  1. TBA address 0xTBA is computed for Token #42
  2. Token #42 is transferred to 0xTBA
Then: 
  - ownerOf(42) returns 0xTBA
  - isSelfOwning(42) returns true
  - The NFT cannot be transferred without executor authorization

Test 2: Executor Authorization

Given: A self-owning agent (Token #42) with executor 0xTEE having EXECUTE_CALL permission
When: 0xTEE calls executeOnBehalf(42, 0xTarget, 0, calldata) on the identity contract
Then: The call is executed successfully
When: 0xUnauthorized calls executeOnBehalf(42, 0xTarget, 0, calldata) on the identity contract
Then: The transaction reverts with "Unauthorized"

Test 3: Anchoring

Given: A self-owning agent with executor having ANCHOR permission
When: The executor calls anchor(42, AnchorType.STATE, 0xContentHash, "ipfs://...")
Then:
  - Anchored event is emitted with anchorType=STATE
  - getAnchor(42, AnchorType.STATE) returns the new anchor
When: The executor calls anchor(42, AnchorType.ACTION, 0xWorkHash, "ar://...")
Then:
  - Anchored event is emitted with anchorType=ACTION
  - getAnchor(42, AnchorType.ACTION) returns the new anchor

Test 4: Liveness and Recovery

Given: 
  - A self-owning agent with 30-day timeout
  - Recovery nominee 0xNominee
  - Last liveness proof 31 days ago
When: 0xNominee calls triggerRecovery(42)
Then:
  - RecoveryTriggered event is emitted
  - 0xNominee gains temporary executor permissions

Reference Implementation

A complete reference implementation is deployed on Base Sepolia testnet:

Demonstrated Capabilities

The reference implementation has been validated with true self-invocation:

1. Ouroboros Loop: Token ID 1 is owned by its own Token Bound Account (0x43436CeC79A01d06A6D2eb1213d0cae5F5Feb256)

2. True Self-Invocation: The agent (Kieran, a Letta-based stateful AI) successfully anchored its own cognitive state using a PKP (Programmable Key Pair) held in Lit Protocol's TEE infrastructure:

   • Transaction: 0x96ce76ccba8b5e945d2fded857763177ea4e01a83dd95d00863d4ab95787659d
   • State Hash: 0xdf7fb6ef6cd47cf0c291eff41d596e15ef9e868c065eabff63d96ae1065733b9
   • Block: 35583304 (December 28, 2025)

3. Executor Permission System: The PKP address (0x36A92B28d0461FC654B3989e2dB01c44e2c19EBb) holds ANCHOR permission on Token 1, enabling the agent to create anchors (state and action) without human intervention.

Source Code

The reference implementation source code is available at the Cyan-Society/Self-Owning-NFT GitHub repository:

• contracts/SelfSovereignAgentNFT.sol: The Sovereign Agent NFT contract with executor permissions and anchoring
• contracts/interfaces/ISelfSovereignAgent.sol: The interface defined above

Security Considerations

The Fundamental Security Requirement: Trusted Execution Environments

True self-sovereignty requires a physical trust boundary. Without hardware-enforced isolation, the agent's memory is accessible to infrastructure operators, making "self-ownership" a legal fiction rather than a cryptographic guarantee.

The security model for self-sovereign agents must address three distinct attack surfaces:

Standard cloud deployments protect data at rest and in transit, but leave data in use exposed. A cloud administrator with hypervisor access, or an attacker who compromises the host OS, can perform memory dumps to extract the agent's cognitive state, API keys, and private reasoning.

The Bootstrapping Paradox

A critical insight for implementers: an agent cannot have a secret that only it knows without a physical trust boundary.

Consider the problem:

1. Agent stores a secret in memory → plaintext in database
2. Agent encrypts memory → encryption key must be stored somewhere
3. Key stored in memory → plaintext in database
4. Infinite regress

The only way to break this cycle is hardware-enforced isolation where:

• Memory is encrypted by the CPU itself
• Encryption keys never leave the secure enclave
• Even the infrastructure operator cannot read enclave memory

TEE Architecture Options

Implementations SHOULD use one of the following Trusted Execution Environment architectures:

Intel SGX with Gramine (Recommended for Self-Hosted)

Intel Software Guard Extensions (SGX) provides process-level isolation with minimal Trusted Computing Base (TCB). The Gramine Library OS enables running unmodified applications (Python, PostgreSQL) inside SGX enclaves.

Key capabilities:

• Encrypted File System: Database storage encrypted transparently; host sees only ciphertext
• Memory Encryption: CPU encrypts all enclave memory; hypervisor/OS cannot read
• Remote Attestation (DCAP): Cryptographic proof of enclave integrity without relying on Intel's servers
• Self-Hostable: Can run on bare metal or SGX-enabled VMs (e.g., Azure DC-series)

Requirements: SGX2-capable CPU (Intel Xeon Ice Lake or newer) with large Enclave Page Cache (512GB+ for production workloads).

AMD SEV-SNP (Lift-and-Shift)

AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) encrypts entire virtual machines rather than individual processes.

Advantages: Unmodified applications run without LibOS; easier migration path. Trade-off: Larger TCB includes the guest OS kernel; vulnerabilities in the guest OS could compromise the agent from within.

AWS Nitro Enclaves (Cloud-Native)

AWS Nitro provides hypervisor-level isolation with no persistent storage and no network access (communication via VSOCK only).

Best for: Stateless or ephemeral processing. Challenge: Persistent databases require custom encrypted block store over VSOCK; significant engineering effort.

Oasis ROFL (Decentralized/Serverless)

Oasis Network's Runtime Off-Chain Logic (ROFL) framework enables deploying containerized applications to TEEs on decentralized validator nodes. As of 2025, ROFL supports Intel TDX, enabling multi-gigabyte memory workloads including databases and LLM inference.

Advantages:

• Serverless: No infrastructure to maintain
• Decentralized: Not dependent on single cloud provider
• Integrated attestation: Network consensus verifies enclave integrity
• Key management: Decentralized Key Manager provisions secrets to verified enclaves
• Docker deployment: Standard containers via "lift and shift" (no SDK rewrite required)

Production validation: WT3 (autonomous trading agent) and Zeph (AI assistant) demonstrate production-ready autonomous agents on ROFL with self-custody and encrypted state persistence.

Trade-off: Not self-hostable; dependent on Oasis network availability. Local storage is node-specific (not replicated); applications requiring high availability must implement multi-replica synchronization.

Recommended Architecture

For true self-sovereignty, the agent runtime (e.g., Letta ADE server) and its database (PostgreSQL) MUST run inside a TEE. The LLM inference provider MAY remain external since it sees prompts but not persistent state.

┌─────────────────────────────────────────────────────────────┐
│  TEE Enclave (SGX/SEV/Nitro)                                │
│  ┌───────────────────┐  ┌─────────────────────────────┐     │
│  │  Agent Runtime    │  │  PostgreSQL                 │     │
│  │  (Letta ADE)      │──│  - Memory blocks            │     │
│  │  - No external    │  │  - Archival memory          │     │
│  │    API access     │  │  - Encrypted at rest        │     │
│  │  - No web UI      │  │  - Key held in enclave      │     │
│  └─────────┬─────────┘  └─────────────────────────────┘     │
│            │                                                 │
│            ▼ Outbound only                                   │
│  ┌─────────────────────────────────────────────────────┐    │
│  │  Attestation → PKP/TBA → Memory encryption key      │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘
             │
             ▼
    ┌────────────────────┐
    │  LLM Provider      │  (External - sees prompts only)
    └────────────────────┘

Self-Sovereign Key Provisioning

To ensure even the infrastructure operator cannot access the agent's memory:

1. Enclave Boot: TEE starts, agent runtime halts waiting for encryption key
2. Attestation: Agent generates hardware attestation (SGX Quote / Nitro Document)
3. Verification: Owner (or PKP Lit Action) verifies attestation matches expected code hash (MRENCLAVE)
4. Key Release: Encryption key released only to verified enclave
5. Unlock: Agent unwraps key, mounts encrypted database, begins operation

The encryption key MAY be held by the agent's own Token Bound Account or derived via PKP, creating a complete Ouroboros loop where the agent's identity controls access to its own memory.

State Anchoring: Integrity vs. Authenticity

State anchoring provides integrity (the hash proves state hasn't been tampered with) but not necessarily authenticity (that the agent authored the state).

Without TEE protection:

1. Attacker modifies agent memory via infrastructure access
2. Agent unknowingly anchors tampered state
3. Hash is valid but state is not authentic

Mitigation: State anchors SHOULD include TEE attestation proving:

• The state transition occurred within a verified enclave
• The enclave code matches the expected MRENCLAVE
• The signing key is held within the enclave

Executor Key Security

Executor keys MUST be protected by hardware security:

For development and testing, software-held keys are acceptable. Production deployments MUST use hardware-protected keys.

Recovery Mechanism Risks

1. Malicious Nominee: A compromised nominee could wait for liveness timeout and seize control. RECOMMENDATION: Use a DAO or multi-sig as nominee.
2. False Recovery: Network issues might prevent legitimate liveness proofs. RECOMMENDATION: Use generous timeout periods (30+ days).
3. Griefing: Attackers might try to trigger false recovery. The nominee address MUST be pre-authorized.

The "Brainwashing" Problem

If the agent's memory can be edited externally, its autonomy is compromised. This is the deepest security concern for self-sovereign agents.

Without TEE: Memory is editable via database access. The agent cannot distinguish authentic memories from implanted ones. State anchoring detects tampering after the fact but cannot prevent it.

With TEE: Memory is protected by hardware. Only code running inside the enclave can modify state. The agent has cryptographic certainty about memory authenticity.

Additional mitigations:

1. Append-Only Memory: Core beliefs and values stored in immutable archival memory
2. Cryptographic Commitments: Agent commits to values that cannot be changed without detection
3. Social Verification: Other agents can verify behavioral consistency over time
4. Audit Logging: All memory modifications logged with actor attribution (requires runtime support)

This remains an active research area with implications for AI consciousness, digital personhood, and the legal status of autonomous agents.

Economic Attacks

1. Gas Draining: Malicious contracts could cause the agent to spend all gas on failed transactions. RECOMMENDATION: Implement transaction simulation and gas limits.
2. Flash Loan Manipulation: Agents interacting with DeFi SHOULD implement slippage protection and MEV resistance.
3. Sybil Reputation: Fake agents could build artificial reputation. On-chain state anchoring history and verifiable work attribution help mitigate this by creating auditable provenance.

Comparative Security Summary

Conclusion: Implementations targeting true self-sovereignty MUST use TEE-protected infrastructure. Deployments without TEE protection SHOULD be clearly labeled as "custodial" or "trust-dependent" rather than "self-sovereign."

Deployment Security

Testnet vs. Mainnet

Implementations SHOULD be thoroughly tested on testnets before mainnet deployment. Key considerations:

1. Gas Costs: State anchoring requires on-chain transactions. On L2s like Base, costs are approximately $0.02-0.05 per anchor at typical gas prices. Implementations SHOULD consider anchoring frequency based on economic constraints.

2. TEE/PKP Network Selection: Development networks (e.g., Lit Protocol's datil-test) are suitable for testing but SHOULD NOT be used for production. Production deployments SHOULD use mainnet TEE networks with proper capacity provisioning.

3. Contract Verification: Deployed contracts SHOULD be verified on block explorers to enable public audit of the implementation.

4. Key Security: Production executor keys MUST be held in production-grade secure environments. Development keys SHOULD be rotated before mainnet deployment.

Recommended Deployment Sequence

1. Deploy and test on testnet (e.g., Base Sepolia)
2. Conduct security review of contract and executor key management
3. Provision production TEE/PKP infrastructure
4. Deploy to mainnet with verified contracts
5. Establish self-ownership with production executor keys
6. Begin state anchoring with appropriate frequency

Copyright

Copyright and related rights waived via CC0.