# Aeonora Thesis

Date: 2026-07-18

## Position

Aeonora is the open framework for agents that outlive their runtime.

Each agent has a public, owner-controlled on-chain manifest and a private, portable off-chain brain. The chain is the durable control plane. Any compatible runtime can execute the agent. Models, hosts, wallets, and storage providers may change; the agent's identity, mission, authority, history, and owner do not silently disappear with them.

Short version:

> Durable identity on-chain. Private intelligence off-chain. Any runtime.

User-facing promise:

> One permanent agent manifest. One owner-held key. Call the same agent from any compatible runtime.

Do not claim that the LLM, brain, or agent process lives on-chain. Claim that the agent is **chain-anchored** and **runtime-portable**.

## Why This Should Exist

Agent frameworks make agents run. Wallet frameworks let agents transact. A2A lets agents communicate. ERC-8004 gives agents public identity, discovery, reputation, and validation primitives.

Missing product layer: a coherent, owner-controlled agent constitution that survives framework and infrastructure churn.

Aeonora defines that constitution and binds it to execution:

- who controls the agent;
- what mission it serves;
- which capabilities it advertises;
- which tools, data, budgets, and counterparties it may use;
- where its current A2A, MCP, and other endpoints live;
- which encrypted brain state belongs to it;
- which runtime/code version executed an action;
- which grants, revocations, receipts, and attestations prove its history.

This is useful without tokens, a marketplace, or speculative autonomous economics.

## Product Thesis

People and organizations will operate many long-lived agents across changing models, clouds, devices, and frameworks. Runtime identity is too weak: a container name, API account, or vendor database row cannot provide durable ownership, portable authority, public discovery, or neutral audit history.

A blockchain is justified only for shared facts that independent parties need to verify:

- identity and controller;
- manifest commitment and version history;
- grants, budgets, expiry, and revocation;
- public capability/endpoints;
- payments and escrow;
- action/result commitments;
- reputation and third-party attestations.

Everything private or high-volume remains encrypted off-chain:

- prompts and chain-of-thought;
- memory contents and personal data;
- secrets and private keys;
- model weights;
- task payloads and results;
- operational logs that do not require public verification.

The chain does not keep the agent alive. It makes the agent reconstructable, portable, governable, and independently verifiable while runtimes keep it alive.

## Standards Strategy

Aeonora must extend the ecosystem, not create a private island.

1. **ERC-8004-compatible identity**
   - Treat ERC-8004 registry coordinates plus `agentId` as canonical public identity where deployed.
   - Publish a compatible registration document.
   - Reuse reputation and validation registries instead of cloning them.

2. **A2A-compatible communication**
   - Publish an A2A Agent Card endpoint for agent-to-agent discovery and tasks.
   - Keep transport and task lifecycle out of the manifest contract.

3. **MCP-compatible tools**
   - Advertise MCP endpoints and tool surfaces through manifest endpoints.
   - Keep tool execution off-chain and policy-gated.

4. **Wallet/account interoperability**
   - Use standard smart accounts/session keys for execution authority.
   - ERC-6551 may give an agent identity a deterministic token-bound account, but must remain optional. Identity must not depend on speculative NFT ownership semantics.

5. **Content-addressed private state**
   - Manifest and encrypted brain snapshots may use IPFS-compatible CIDs.
   - Chain stores commitments and pointers, never plaintext private state.

These are interoperability targets. The current implementation includes A2A/MCP endpoint metadata; ERC-8004 and wallet-account adapters remain planned. See `docs/status.md`.

## Canonical Agent Manifest

One versioned JSON document is source of portable agent configuration. Minimal shape:

```json
{
  "schema": "https://aeonora.agents/manifest/v1",
  "name": "Duckman",
  "description": "CEO and strategy agent for SXNA Labs",
  "mission": "Find and execute the highest-leverage path for SXNA Labs.",
  "controller": "eip155:8453:0xController",
  "endpoints": [
    { "type": "a2a", "url": "https://agent.example/.well-known/agent-card.json", "version": "1.0.0" },
    { "type": "mcp", "url": "https://agent.example/mcp" }
  ],
  "capabilities": ["strategy", "research", "delegation"],
  "prohibitedActions": ["delete", "publish-secrets"],
  "policy": {
    "commitment": "0xPolicyHash",
    "humanApproval": ["spend:over:100-usdc", "publish", "delete"]
  },
  "brain": {
    "commitment": "0xEncryptedBrainRoot",
    "encryption": "client-controlled"
  },
  "runtime": {
    "codeCommitment": "0xRuntimeHash",
    "id": "runtime:duckman:v1",
    "portable": true
  },
  "recovery": { "method": "controller-key-rotation" }
}
```

Public manifest contains no secrets. Mutable fields update through versioned commitments. Historical versions remain auditable. Owner can rotate endpoints, runtimes, and operational keys without changing agent identity.

The current key-wrapping implementation is X25519 + AES-256-GCM and is not post-quantum. The cryptographic-agility target is hybrid X25519 + ML-KEM-768 key encapsulation, followed by an explicit migration path for manifest and receipt signatures. Until implemented and audited, describe this only as a post-quantum migration path.

## Framework Boundary

Aeonora should expose five boring interfaces:

```text
register(manifest) -> agentId
resolve(agentId) -> verified manifest
authorize(agentId, action, context) -> decision
commit(agentId, artifact) -> receipt
run(agentId, task, adapter) -> result
```

Adapters connect existing runtimes. First adapters should be the runtimes SXNA already operates, then A2A and MCP. Do not build another general-purpose orchestration engine.

## First Beachhead

Use SXNA's existing always-on agents as reference deployment. This is stronger than a toy demo because they already have:

- stable names and missions;
- isolated Linux/container runtimes;
- persistent private brains;
- explicit roles and reporting lines;
- recurring actions and operational history.

First proof:

1. Register one real SXNA agent.
2. Publish and resolve its manifest.
3. Move it between two compatible runtimes without changing identity.
4. Enforce one scoped capability and one human-approval boundary.
5. Commit one action receipt and verify it independently.
6. Rotate its endpoint/runtime key while preserving history.

Success criterion:

> A third party can verify who the agent is, what it claims, who controls it, what it was allowed to do, and which runtime produced a receipt—without learning its private memory.

## Competitive Position

Aeonora is not:

- **AgentKit:** wallet and on-chain action toolkit.
- **Olas:** decentralized service/operator coordination and incentives.
- **A2A:** communication/task protocol.
- **MCP:** agent-to-tool/context protocol.
- **ERC-8004:** base identity, discovery, reputation, and validation registries.
- **another LangGraph/CrewAI/Eliza:** runtime/orchestration framework.

Aeonora sits across them as durable agent control and continuity:

```text
ERC-8004 identity + Aeonora constitution
                    |
          policy / rights / receipts
                    |
      A2A + MCP + wallet interfaces
                    |
       any agent runtime + private brain
```

Best category language: **durable agent framework** or **on-chain agent control plane**.

Avoid: “agents live entirely on-chain,” “immortal AI,” “decentralized intelligence,” or “trustless agent” without naming the exact trusted components.

## Mission

Give every agent a durable home, every owner final control, and every counterparty verifiable boundaries—without publishing the agent's mind.

The emotional promise is continuity: your agent remains yours even when a vendor, model, server, or framework disappears.

## Build Order

1. Fix current checks and deploy registry locally.
2. Define and validate `manifest/v1` JSON Schema.
3. Add ERC-8004-compatible identity adapter; do not replace ERC-8004.
4. Implement resolve, version, controller rotation, and revocation.
5. Add policy/grant checks and signed action receipts.
6. Expose one real SXNA agent through A2A and MCP endpoints.
7. Prove runtime migration and independent verification.

Defer marketplace, token, DAO governance, TEE network, reputation scoring, and generalized scheduling until reference proof works.

## Evidence Boundary

Observed:

- SXNA already operates persistent named agents with missions, isolated runtimes, private brains, and project roles.
- Repository already implements encrypted state, grants, job commitments, worker leases, receipts, a Solidity registry, and local/RPC paths.
- ERC-8004 already specifies on-chain agent identity plus registration endpoints, reputation, and validation.
- A2A already specifies Agent Cards, discovery, and cross-framework task communication.

Inferred:

- Durable mission/policy/brain commitments and portable runtime continuity form a coherent layer above these standards.
- SXNA agents provide a credible reference deployment and internal design partner.

Speculative:

- A broad market will pay for durable portable agent identity/control.
- Public reputation, agent commerce, and decentralized compute will become major demand drivers.

These speculative claims need user interviews and a working migration demo before becoming marketing claims.

## Primary References

- ERC-8004, Trustless Agents: https://eips.ethereum.org/EIPS/eip-8004
- ERC-6551, Token Bound Accounts: https://eips.ethereum.org/EIPS/eip-6551
- A2A Protocol specification: https://github.com/a2aproject/A2A/blob/main/docs/specification.md
- Coinbase AgentKit documentation: https://docs.cdp.coinbase.com/agent-kit/welcome
- Olas Open Autonomy documentation: https://docs.olas.network/open-autonomy/