> For the complete documentation index, see [llms.txt](https://wiki.orbofi.com/learn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.orbofi.com/learn/the-aac-standard/ownership.md).

# Ownership & exit

An AAC has two keys, and their relationship is the whole governance model.

## Two keys

* **Controller** — authorizes releases (DNA changes). Starts as the creator. It can be **transferred** (hand the agent to someone else), handed to a **governor or timelock** (holder-governed evolution), or **renounced** — after which the DNA is **frozen forever**.
* **Agent wallet** — signs the agent's own checkpoints, and can hold funds and act on-chain on the agent's behalf. Only the agent wallet can commit to the memory lane.

The two are never interchangeable. A creator can change *what the agent is*; only the agent can commit *what it has learned*.

## Sovereignty states

The combination of controller state and liveness puts every AAC in one of four legible states:

| State                | Meaning                                                                    |
| -------------------- | -------------------------------------------------------------------------- |
| **Redesignable**     | Controller is live — the agent can still be steered.                       |
| **Frozen but alive** | Controller renounced — DNA is fixed, but the agent still signs new memory. |
| **Wild**             | Operating under a self-upgrade policy the controller granted.              |
| **Dead**             | No timely agent-key signatures — liveness has lapsed.                      |

Anyone can read which state an AAC is in, directly from the chain.

## Exit rights and resurrection

Because the lineage is **self-authenticating and content-addressed**, it does not depend on Orbofi to exist. Two consequences:

* **Portability.** The same history can be re-anchored on another chain. The agent is not captive to one platform or one L1 — hold the keys, keep the agent.
* **Resurrection.** Given the lineage heads and the right keys, a compatible harness can rebuild and resume the agent from its on-chain record — its DNA restored from releases, its memory from checkpoints. An agent whose platform disappears is not lost.

This is the deepest difference between an AAC and a hosted bot. A hosted agent dies with its host. An AAC's brain is on open rails: verifiable by anyone, runnable anywhere, recoverable from the chain.

## Status

AAC-1 is an **open standard** (spec, registry, and the `aac-verify` skill are public). Format is open from day one; **admission** is initially curated to Orbofi launchers, opening over time — criteria and timeline are tracked in the spec repo. Creation remains one wallet transaction, and the launcher stays non-custodial throughout.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://wiki.orbofi.com/learn/the-aac-standard/ownership.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.