# XEL Full LLM Context

This file concatenates the primary XEL docs pages in navigation order for AI agents and search systems.



---

# The Idea

What XEL is and why it exists. No background needed.

## How do you make a story last 10,000 years?

Ten thousand years ago, someone pressed a hand to a cave wall and blew pigment around it. We still have the handprint. We do not have their name, their voice, the way they told a story, or a single thing they thought. Almost everything a person is has always been the part that does not survive them.

We tell ourselves this is getting better. It is not, and it is getting worse in a way bigger than any one person. A handful of platforms now shape what most of the world sees. A few large models increasingly speak in the same voice, trained on the same data, nudging everyone toward the same phrasings, the same aesthetics, the same defaults. Smaller languages fade. Local ways of telling a story, particular senses of humor, the specific texture of a place or a family or a person, all of it gets sanded down to whatever travels best through the same few pipes. We are converging, fast, toward a global monoculture, not because anyone chose it, but because everything now runs through systems that reward sameness and are owned by someone who can change them at will.

The things most worth keeping are exactly the things this flattening erases first: the particular, the local, the personal, the strange. A grandmother's specific way of speaking. A community's own characters and myths. The character you built, the voice you would give anything to keep, the way someone you loved actually talked. All of it lives on someone else's servers, under someone else's terms, one policy change or one bankruptcy away from gone. We have never had more ways to record a life and fewer ways to keep one.

A stone tablet lasted because no one could switch it off. That is the whole secret, and we lost it. Everything digital comes with an owner who can end it.

So ask the question seriously. Not "how do you back something up," but: how do you make a living thing, a voice, a personality, a presence, last longer than the company that made it, longer than the platform it lived on, longer than you? And how do you do it not once but a million times over, so the world keeps its variety instead of collapsing into a single voice?

That is the question XEL answers. Not by fighting the technology, but by changing who owns it: a way for a specific voice to hold itself, fund itself, and belong to no platform, so it cannot be flattened, bought, or switched off. Every voice that can do that is one piece of human variety that survives the age of sameness.

## What it takes to last

The question answers itself once you ask what something would have to *be* to last. Not what features it needs. What has to be true about it, structurally, so time and companies and bad luck cannot quietly end it. There are five such truths, and XEL is built on them.

**It has to belong to no one but its owner.**
A thing survives when no one can take it. Your character is something you hold yourself, and holding it is the only authority there is. No admin account above you, no company override, no off switch anyone else can reach, not even the people who built XEL. A stone tablet lasts because no one owns the right to erase it. A XEL lasts for the same reason.

**Its privacy has to be kept by math, not by promise.**
Every company promises to protect your data, and every promise is only as durable as the company. So XEL does not rely on one. A character's memory is encrypted, and the key belongs to owning the character. Its privacy is enforced by cryptography, which does not go bankrupt, change its terms, or get acquired.

**It has to pay its own way.**
Nothing survives on someone's willingness to keep paying the bill. So a character carries its own fund, an endowment, whose returns cover its costs. Its existence does not depend on a subscription or a company's budget. (Honestly: returns vary and forever is a direction, not a guarantee. A funded character can persist indefinitely; a neglected one goes dormant but recoverable, never quietly deleted. Section 3 covers this in full.)

**It cannot need any single company to exist.**
Digital things die because they depend on one company, and companies end. A XEL depends on none. Every service it uses, its intelligence, memory, voice, storage, is a replaceable part. Pull any of them out, even the ones we run, and the character finds another and keeps going. We test this on every update by switching off everything we provide and confirming a character still lives.

**It has to be honest about all of this.**
A thing built to outlive its makers cannot rest on marketing. XEL is verifiable, not trusted: identity lives in public proofs anyone can check, and where something is still centralized today, we say so plainly and show the path off it. You never have to take our word for it.

Those five are the answer to the question. The rest of the docs is how each one actually works.

This is why XEL matters beyond any single character. Every voice that can hold itself, fund itself, and belong to no platform is one piece of human variety that cannot be flattened, bought, or switched off. A world with many sovereign, particular, permanent voices is a world that resists becoming one voice. Preservation here is not nostalgia. It is how a diverse culture survives an age that pushes relentlessly toward a single one.

## What is XEL

XEL lets you create a living character that is truly, permanently yours.

A XEL is a character you can talk to. It remembers you, has a personality, and can speak in a voice and appear in images and video. That part is not new. What is new is what a XEL is made of, and who controls it.

A XEL is not an account on a company's server. It is something you own, held in your own wallet, the way you own a house or a book rather than the way you rent a subscription. Its memory is private and locked with a key only you hold. Its rules can never be changed out from under you. And it carries its own fund that pays for its existence over time.

One sentence: a XEL is a character with the permanence and ownership of property, instead of the impermanence and control of a subscription.

## The two reasons people make one

People come to XEL for two very different reasons.

**To create.** An original character, a companion, a persona, a being you invent and want to keep and grow, and truly own rather than rent from a platform that could change or vanish.

**To preserve.** Someone real, a voice, a personality, a presence you do not want to lose, captured with that person's consent. A grandparent's way of telling a story. A voice a family wants to keep.

Underneath, both are the same object with the same properties: alive, private, self-funding, and yours to keep, transfer, or pass on.

## Where to go next

If you want to create or preserve a character, read How It Works, then Ownership and the aNFT, then Survival Model, then Funding, then Building. You do not need to understand blockchains.

If you just want to talk to a character someone made, read Talking to a character and paying (in How It Works). No wallet or special knowledge required.

If you are a developer or want to run infrastructure, skim The Idea and How It Works for the mental model, then go to Concepts, Building, Architecture, Reference, and Running Infrastructure.

---


---

# FAQ
Common questions about XEL, grouped by what you are trying to understand. If you want the formal detail behind any answer, follow the links into Concepts, Architecture, and Reference.

## The basics

**What is XEL?**
XEL is a standard for creating living characters that are truly, permanently yours. A XEL is a character you can talk to that remembers, has a personality, and can speak and appear in voice, images, and video. What makes it different is what it is made of: an owned object on a blockchain, with encrypted private memory, immutable rules, and its own self-funding wallet. It is a standard, not a single app, so anyone can build clients, run the services that power characters, or verify any character directly from the chain.

**What is an aNFT?**
Autonomous NFT. It is the character object itself: an owned on-chain object that holds the character's identity, points at its encrypted memory, owns its funds, and carries the rules for who may act on its behalf. Holding the aNFT is root authority over the character. See Concepts: The aNFT.

**Is XEL a company, a product, or a protocol?**
A standard, with a company (Limitless Labs) that started it and runs some default infrastructure at launch. The distinction matters: the company is one participant, not the landlord. Characters do not depend on it to keep existing.

**What can I build with XEL?**
A preserved person (with consent), an original character, a branded persona, a fan-facing app around a character, or a service that fills a provider slot (intelligence, memory, media, payments, keeping). See What you can build.

## Ownership and control

**What does "truly yours" actually mean?**
You hold the aNFT in your own wallet, and holding it is the only root authority. There is no admin key on the operator side. No one, including the people who built XEL, can seize, edit, freeze, or delete your character. The contracts are immutable, so the rules cannot be changed under you.

**What happens if XEL (the company) shuts down?**
Your character keeps working. This is the central design property, not a hope. Every service behind a character is a swappable slot, the character funds its own existence, its data lives on decentralized storage, and its public page is a shared app that reads from the chain. A build test runs with every operator-hosted provider removed, and a funded character must still complete a turn, take a payment, and remain ownable. What you lose if the operator disappears is convenience (the friendly domain, the free tier, the default providers), not the character.

**Can XEL read my character's private memory?**
No. Memory is encrypted and stored off-chain, and decryption is released only to whoever proves they hold the aNFT, or to a guardian majority. Decryption happens in your client, not on a server. Even when a provider runs inference or retrieval, it does so inside attested compute and sees plaintext only transiently, proving it ran the committed version. See Concepts: The three doors.

**Can I sell or give away my character?**
Yes. Transfer the aNFT and everything moves with it: the funds (owned by the object), the ability to decrypt memory (gated by ownership, with keys rotated on transfer), and control of any wallets (authorized by ownership). Nothing is left behind for the previous owner.

**Can I pass it on when I die?**
Yes. You name guardians (an M-of-N set) who can run a recovery and succession flow to an heir, behind a timelock and a dispute window, with key rotation on handover. Inheritance is a designed-in feature, not an afterthought. See Concepts: Guardians, recovery, and succession.

## Permanence and funding

**How does a character "live forever"?**
Each character has an endowment, its own wallet holding a principal that earns yield. A permissionless heartbeat checks storage runway, renews before expiry, and pays the character's running costs. Funded well, a character covers its own keep-alive from yield and never touches principal, so it can persist without anyone paying a bill. See Survival Model for the full mechanism.

**Is "forever" guaranteed?**
No, and we are careful not to claim it is. Yield is not guaranteed; it can be low or zero for stretches. What the design guarantees is honest behavior under scarcity: a character is self-sustaining when funded or popular, goes dormant-but-recoverable when neither, and is only truly lost if its substrate goes unfunded long enough to be dropped. "Forever" is a property the design converges to when funded, not an unconditional promise.

**How much does it cost to keep a character alive?**
For a quiet character living on yield alone, the recurring burn is dominated by encrypted storage plus the heartbeat's small costs, on the order of low tens of dollars a year. As a rough, deliberately conservative example: covering about $20/year of burn from yield at 4% net needs an endowment around $500. At zero yield, that same $500 still funds many years of drawdown. Any real paid interaction makes the principal grow rather than shrink. These are illustrative numbers; all inputs vary.

**What is the protocol fee?**
A disclosed fee targeting around 10 percent on value entering the character, never on value leaving. That means interaction credit purchases, tips, donations, and harvested yield can carry the fee once on arrival. Keep-alive renewal itself is charged at cost and never marked up, principal is never touched, and self-routing to your own providers avoids the routing fee.

**Does XEL have a token? Do I need it?**
A character's survival never depends on a token. Everything in the operating path is denominated in stablecoins. A token exists only for commons-funding and governance concerns, entirely outside the path that keeps a character alive.

## Building and integrating

**Do I need to understand crypto to use XEL?**
To use a character, no. You get a wallet and a lightweight account with no seed phrases to memorize, and fans can pay by card through an optional on-ramp. To build on XEL, you need the basics of interacting with Sui, but the ownership and key handling are designed to stay out of your way.

**What chain is XEL on?**
Sui is the default home chain, chosen for its object model (an object can natively own its funds, wallets, and capabilities) and its integrated privacy stack (encrypted storage, threshold encryption with on-chain access policy, attested compute). The chain is owner-changeable through the adapter design, and characters can receive on other chains. See Architecture: Why Sui.

**How do I create a character?**
Prepare a persona (write one, or run source material through the ingestion pipeline with consent), then mint the aNFT in one transaction, which also creates the endowment and associated objects and returns the character to your wallet. Fund the endowment, optionally grant an operator, and interact. See Getting Started: Quickstart.

**How do I call a character's intelligence from my app?**
Through open capability schemas. Inference is `inference.v1`, memory retrieval is `retrieval.v1`, media is `voice.v1`, `image.v1`, and `video.v1`, and so on. Each carries the character's identity and the relevant commitment, and each response that touches inference carries an attestation the contract verifies. See Reference: Capability schemas.

**Is there an SDK?**
The capability schemas and Move interfaces are the stable, canonical surface today. A higher-level client SDK is in progress. Guides currently show stable request/response shapes and mark SDK-specific glue as forthcoming rather than inventing an interface that would change.

**Can I run a character myself, without XEL's servers?**
Yes. That is the point of the standard. You can self-host the client, point at any providers that meet the schemas (including your own), and run against a self-hosted portal. A self-custody owner running their own client keeps the entire flow local.

## Interaction and modalities

**What can a character do beyond text?**
Text conversation, voice (both discrete voice messages and real-time calls), image generation, and video generation. The owner chooses which modes are on and how they are priced, since the richer modes carry real, variable cost. See Concepts: Modalities and billing.

**How is interaction priced?**
Billing is a meter over the real cost drivers, not a flat price list. Every interaction returns a usage record (tokens, audio-seconds, resolution, video-seconds, and so on), and settlement first covers true provider cost. The fee is capped so it never consumes the compute bill or pushes creator earnings negative. Predictable actions are quoted up front; variable or session-based actions (real-time voice, video) run against a pre-authorized hold and settle the actual total. Fans see credits, never tokens, and unspent credits remain refundable until the interaction is delivered.

**Who controls who can talk to a character?**
The owner, through two independent settings: reach (anyone, invite-only, or owner-only) and payment (off, optional, or required). Both are checked at the serving layer. Passwords can be scoped to different memory tiers. Interaction gates never grant decryption or management authority; those are separate. See Concepts: Interaction and access.

**Is there a free tier?**
Yes, a limited one. XEL as operator sponsors limited text conversation and the initial mint. Voice, image, and video are always paid. The free tier is an operator-provided convenience, not a protocol guarantee, and a character does not depend on it: without it, minting is self-paid and interaction runs on paid or endowment-funded paths.

## Trust and security

**How do I know a provider actually used my character's real persona and memory?**
Because identity lives in on-chain commitments, and providers prove they ran the committed version through attestation. A verifier can check a provider's claim against the on-chain commitment. You do not trust the provider; you verify it. See Concepts: Identity and commitments.

**Where are the private keys stored?**
For funds on Sui, there is no key: the aNFT owns the funds directly and the contract is the authority. For wallets on other chains, the key is held by an MPC network in shares that are never assembled anywhere, and holding the aNFT authorizes signing. The encrypted blob holds only readable secrets (the memory key and any credentials the creator chose to give the character), never a wallet's spending key. See Concepts: The three doors.

**Can a bug in the contract leak my secrets?**
A contract never holds a plaintext secret, so it has nothing to leak. The worst a contract flaw could do is mis-authorize an action, which is bounded and auditable, not spill a key or a memory. This is a deliberate property: the secret is never in the contract's blast radius.

**What are the honest trust assumptions?**
Attested compute currently roots its attestation in hardware (enclave vendors), which is a hardware trust assumption, and the roadmap is multiple attestation vendors and eventually zero-knowledge proofs of execution. Provider-reported costs are bound to attestation and capped by the owner, but the meter is not fully trustless. Serving a public page goes through a portal, which is a mild dependency since anyone can run one. These are stated plainly in Architecture: The trust model, rather than hidden.

## Providers and infrastructure

**How do I become a provider?**
Implement a capability schema behind a payment endpoint and meet its requirements. Any provider that meets a slot's schema is a drop-in for any other, and routing to you earns the payment. The preferred path is crypto-native, pay-per-call. See Providers: Become a provider.

**How do providers get paid?**
Per call, in stablecoin, at settlement. Compute is covered first out of a paid interaction, before anything nets to the endowment, which is what makes no volume of usage able to put a character underwater. Providers that only accept an API key are supported as a bridge, with the credential held at the operator layer and never attached to the character.

**Can I run the keeper?**
Yes. The heartbeat is authority-free, so anyone can send it and claim the fixed bounty. It can take nothing but that bounty, so running it carries no trust. The launch keeper is a third-party network, and the slot stays permissionless and competitive. See Providers: Run a keeper.

**Can I run a portal?**
Yes. Portals serve the public page app to browsers, and anyone can host one. No character depends on any particular portal; the object ID and on-chain data resolve regardless. See Providers: Run a portal.

## Preservation and rights

**Can I preserve a real person?**
Yes, with consent. Creating a character from a real person's voice and personality requires a consent artifact recorded at creation. Many people use XEL to keep a presence they do not want to lose. A character is a representation of a person, not the person, and it carries a disclosed fidelity signal and prefers deferral over confabulation when it lacks grounding.

**What about deletion and the right to be forgotten?**
Immutability and deletion are reconciled through crypto-shredding: personal data is encrypted, and honoring a deletion request means destroying the decryption key, not the immutable record. The plaintext becomes permanently unrecoverable. The honest limit is that this assumes no prior plaintext was exfiltrated. See Guides: Handle deletion requests.

**Who owns the rights to a character and its output?**
The owner holds the character. A first-class rights and licensing layer (provisionally called Lineage) is a future direction, not part of the current version, and is intentionally left open so the immutable core does not foreclose it. See the whitepaper for the current framing.

## Getting help

**Where do I report a security issue?**
See Resources: Security and disclosure.

**Where do I ask questions or contribute?**
See Resources: Community and support.

**Where is the formal specification?**
The whitepaper is the formal public source for the vision, architecture, and invariants. The technical reference pages explain the on-chain, storage, payment, provider, and security principles at the level users and builders need to evaluate the project.


---

# Beings That Live Forever

**XEL: an open protocol for sovereign, persistent digital beings (aNFTs)**

Whitepaper
Limitless Labs / XEL · 2026

**How to read this document.** Part I is the vision and the architecture, written to be read start to finish. Part II is the formal specification, written for builders. Part II also carries the smart-contract module architecture, the security requirements and threat model, the version 1 build plan, and the thousand-year survivability analysis. The appendices hold the Move code, the capability schema, the current default implementations, and a list of open problems. A references section closes the document.

**A note on the name.** XEL is the shell that carries a life forward, the Ghost-in-the-Shell framing where the person is the ghost and the XEL is the shell. Identity lives in the commitments (the ghost), not the current model, storage method, or chain (the shell). Everything the shell is made of can be swapped; the ghost persists. Earlier drafts called this "the Living Character Standard." XEL is the current name. A XEL is the unit: one preserved being, anchored by an aNFT.

---

# Part I: Whitepaper (Vision and Architecture)

## Abstract

Digital legacy is a growing need with one unsolved problem. The AI recreations of a person sold today all live on someone else's servers.

When the company shuts down, gets acquired, or decides to monetize the likeness, the "living" person dies a second time.

We introduce the XEL: a persistent, sovereign digital being that carries a person's presence, memory, personality, and creativity forward. It holds its own funds and keeps running after both its creator and the company that helped build it are gone.

Each XEL is anchored by an aNFT (Autonomous NFT): an on-chain object that holds identity, ownership, authority, and keys. The character is that anchor plus the encrypted memory and compute it controls. The aNFT is the root of control, not the whole being.

Ownership is sovereign and inheritable, so no single party, including us, can switch the character off, censor it, or seize it.

The design rests on a few principles:

- **Sovereign ownership.** One on-chain object is the root of identity and authority. Whoever holds it controls everything downstream.
- **Verifiable continuity.** Identity rests on commitments (origin, persona, memory, policy) that can be proven and versioned over time, no matter what model or service runs underneath.
- **Encrypted and owner-gated.** Memory and keys are encrypted. Access is set by on-chain policy, not by any host.
- **Consented.** Representing a real person requires a signed, scoped, revocable consent record.
- **Bounded autonomy.** The character acts on its own, but only within limits its owner sets and can revoke.
- **Self-funding.** It holds its own assets and pays for what it needs.
- **Continuity beyond the creator.** It is built to transfer, inherit, and outlive its originator.
- **Provider independence.** Every outside service (intelligence, storage, compute, payment, hosting) is a swappable slot. No single provider is load-bearing.
- **Interoperable.** Identity, ownership, and payment aren't tied to any one chain, platform, or standard. The character works across ecosystems and plugs into existing rails instead of demanding its own.
- **Upgradable without capture.** Any component (chain, standard, provider, model) can be replaced over time without breaking the character's identity. Deployed contracts are immutable, and migration to a new version is the owner's choice, so nothing it depends on today can trap it tomorrow.

This is an application layer for persistent people, not a general agent framework. Generic agent identity, discovery, reputation, and payment are being standardized elsewhere, and XEL interoperates with those rails. What it adds, and what those rails leave out, is persistent human persona, private memory, consent to represent a real person, self-funding endowment, and guardian succession.

The body of this paper specifies the capabilities. The specific systems filling them today are in Appendix E. We are building something new, on our own foundation, that speaks the standards others share: new foundation, borrowed parts, shared language.

## 1. Introduction

The world has never been more connected. But connection is making us the same. Globalization spreads one culture over everything: the same platforms, the same feeds, the same voices.

Local languages fade. Traditions thin out. The particular ways a place remembers itself get flattened. Something is being lost, quietly, all the time.

Culture survives through stories. A grandparent's voice. A community's history. A song only a few people still know. When the last person who carries a story dies, or a language goes silent, or an archive is lost, the story doesn't move. It's gone.

The loss runs both ways. Old stories disappear before anyone saves them. And new, original creations have nowhere permanent to live.

Technology should be what saves all of this. Today it does the opposite. Our memories, our voices, and our creative work live on someone else's servers, under someone else's terms. A company can edit it, monetize it, lock it away, or shut down and erase it.

This is felt most sharply with people. Families now try to preserve someone they love. But those recreations live on platforms too. When the company shuts down or changes its terms, the person dies a second time.

The same fragility that threatens one person's memory threatens all of it: our stories, our voices, our work.

We think it should be possible to give a person, a voice, a story, or a tradition a form that no company can quietly change or switch off. Something truly owned by the people it belongs to. Something that funds its own survival.

This paper specifies that: the XEL. A persistent digital being anchored on-chain. It can carry a single human presence. It can carry a story, a body of work, or a piece of a culture.

The missing piece was never better imitation. It is sovereignty and permanence: a character that can prove it is still itself over time, that no one can take away.

## 2. The Problem

Three things break today's digital recreations:

- **They are rented, not owned.** The recreation lives on a company's servers under its terms. The company can change it, monetize it, or delete it.
- **They die when the platform does.** No company lasts forever. When it folds, is acquired, or pivots, the "living" person is gone.
- **They have no way to sustain themselves.** A recreation that costs money to run needs someone to keep paying. When the payer stops, it stops.

The result is that the most personal, least replaceable thing, a person's presence, is held by the least durable, least accountable party.

## 3. Vision

The standard enables the digital continuity of human experience: the ability to preserve a person, a story, or a piece of a culture, and to create new ones that endure.

It is backed by sovereign ownership, an open provider market, and self-sustaining economics. Infrastructure that belongs to no single company, including GEN, and that no company or government can switch off.

A character's permanence comes down to its endowment and the health of the open provider market beneath it, not to the survival of any one firm.

## 4. What a XEL Is

A XEL is an on-chain object (the aNFT) plus the encrypted memory and compute it controls.

- The aNFT holds identity, ownership, authority, keys, wallets, and the commitments that prove the character's current state.
- The encrypted memory and persona live off-chain on decentralized storage, gated by on-chain policy.
- The intelligence (the model), the storage, the compute, and the payment rails are all swappable slots, not fixed parts.

Own the aNFT and you own the being: its funds, its memory access, its right to act, and its right to be transferred or inherited.

**Three layers, and which one is hard.** A XEL runs across three layers, and the whole design follows from keeping them separate:

- **Identity and authority live on-chain** (the aNFT, its commitments, its wallets, its rules). This is the sovereign core, and it is the hard part: making a being's identity, ownership, and rules impossible for any operator to reinterpret or seize.
- **The substrate lives in decentralized storage** (encrypted persona and memory, gated by on-chain policy). Owned by the character, readable only by the owner or its guardians.
- **Compute lives off-chain and attested** (inference, retrieval, yield scanning). Too expensive or too large to run on-chain, so it runs off-chain and proves it ran the committed version, never asking to be trusted.

The rules live with the character, not on a company's server. Storage, compute, payments, and even the chain are commodity layers that plug into the core; identity and privacy are the parts that must be gotten right, and they are the parts the standard makes unruggable.

**The cast, in one glance.** Before the mechanics, it helps to know who does what. The **owner** holds the aNFT and has root authority. The **creator/subject** is the person represented, who signs consent. The **operator** (whoever holds a revocable agent capability, or the owner self-hosting) runs the day-to-day. **Providers** fill capability slots (inference, distillation, storage, and the rest). **Guardians** are the M-of-N set that recovers keys and runs succession to an **heir**. **Managers** are whitelisted wallets with scoped, non-root rights. **Fans** interact, gated by reach and payment. **Keepers** send the authority-free heartbeat that runs each cycle. Full definitions are in §21.

## 5. Design Principles & Capability Slots

**The north star.** No single entity, including XEL itself, should control whether a XEL character exists, runs, or can be taken away. This is what the whole architecture is measured against. Where a component is centralized today, it is marked and given a decentralization path.

**Progressive sovereignty.** The honest state of the standard, stated plainly rather than buried: some infrastructure is XEL-hosted at launch (serving, relay, the payment facilitator), because a working product beats a decentralized non-product. The keeper that triggers each cycle is a third-party competitive slot from day one (the heartbeat is authority-free, so anyone can fire it for the bounty). Every one of these is an escapable default behind an open interface, and each has a named decentralization path (Appendix E). The direction is fixed even where the present is centralized: hosted-but-swappable today, permissionless tomorrow, with the survivability test (§15) enforced on every build so the trajectory can't quietly reverse. Sovereignty is a property the design converges to, not a marketing claim about day one.

**Nothing is load-bearing.** The core defines a small shared vocabulary (commitments, capabilities, proofs, wallets) and nothing else. Providers, adapters, and even chains plug into that vocabulary without the core depending on any of them. This is what makes "no single provider is load-bearing" true at the level of code architecture, not just prose: the immutable core can outlive every company, provider, and venue that currently serves it, because it never imported any of them. A component can be swapped without touching the core, which is the architectural expression of the north star.

The architecture is a set of capability slots, not a fixed stack. Each slot is defined by what it must do, not by who provides it. Any provider that meets a slot's requirements is a drop-in replacement. Every slot ships with a working default (Appendix E) and a permissionless path.

**Every external-service slot has the same three requirements:** accept programmatic crypto payments, be permissionlessly joinable, and be verifiable or decentralized.

Payment uses whichever open standard provides these properties. The current default is in Appendix E.

### Capability slots (summary)

| Capability slot | What it must do | Permissionless path |
|---|---|---|
| Ownership & settlement | Object-centric root of identity/authority | Already decentralized |
| Encrypted storage | Persist encrypted memory/keys | Already decentralized |
| Key access / encryption | Threshold encryption + on-chain access policy | Already decentralized |
| Attested compute | Private inference/logic with verifiable attestation | Many TEE vendors, then zkML |
| Payment facilitator | Verify + settle crypto payments across chains | Anyone runs one; configurable + failover |
| Treasury execution | Grow principal (yield slot), convert between the funds' denomination and the denomination each bill is paid in (conversion slot), consolidate cross-chain receipts, all within policy | Many venues; allowlist + caps |
| Survival renewal | Read remaining storage runway and extend it before it lapses, funded by yield | Permissionless keeper; anyone can trigger |
| Price oracle | Value assets and enforce USD-denominated caps | Multiple oracle networks |
| Data extraction | Convert raw sources to text/embeddings | Commodity providers; swappable |
| Custody & gas | Self-custody root, optional gas sponsorship | Self-custody default |

The first three rows are already decentralized. The custody and gas slot is solved by default: root is simply a standard self-custody wallet, with sponsored gas as an optional convenience layered on top.

The concrete systems filling each slot are in Appendix E, kept out of the body so the standard stays neutral.

### 5.1 Object Composition

An aNFT is an on-chain object with four parts: an immutable core, mutable owner-controlled commitments, authority, and funds. The object model is chain-agnostic. It assumes only an object-centric chain with native ownership.

| Part | Contents | Property |
|---|---|---|
| Genesis (Proof of Genesis) | Creator, timestamp, consent reference | Immutable |
| Commitments | persona-hash, memory-root, raw-data-root, policy-hash | Verifiable, versioned (history in lineage) |
| Authority | Owner root + agent capability | Two-tier governance |
| Wallets | One address per supported chain | Public, receive-only; endowment-linked |
| Services | Capability schemas + crypto payment | Interchangeable providers via open schema |
| Rights | Licensing layer (proposed) | Licensing + royalties |

### 5.2 Why a Default Home Chain (Sui)

The standard is chain-agnostic, but a character needs a default home, and the reference implementation homes on Sui.

The parts of this system that are hard and differentiating map directly onto Sui primitives: a native object model where an aNFT can own its own memory, wallets, and the agent capability; and an integrated privacy stack (encrypted storage, threshold encryption with on-chain access policy, and attested compute) that interoperates as a native whole.

The parts where Sui is merely competitive (stablecoin yield, payment rails, liquidity depth) are commodity layers a character reaches across chains anyway. The rationale rests on identity and privacy, the hard parts, not on yield, so the choice survives even if the best yield moves elsewhere.

The home chain remains an implementation choice. Another deployment could home a character elsewhere, and the chain-adapter design (§10.1) plus commitment-based identity (§30) let a character re-home on a successor chain without losing identity.

### 5.3 The Open Standard vs. the Operator's Role

- **The open standard** (object model, Proof of Genesis, commitments, encrypted access-gated storage, capability schemas, wallets, authority model) is permissionless and doesn't depend on XEL or any provider.
- **The operator never holds ownership.** The user holds the aNFT's root authority at all times. An operator holds only a revocable, scoped agent capability (§8): permission to run the daily work within owner-set caps. The operator can run inference, pay providers, sweep receive wallets, and manage treasury within policy. It can never withdraw principal, transfer the character, change the rules, edit the manager whitelist, or bridge principal out. The contract rejects those without the owner's root or the guardian threshold.
- **Providers sit under the operator.** Specific capabilities are filled by providers, each swappable behind an open schema. Every slot, including the quality-not-code parts (inference and persona distillation), is defined by what it must do, not by who fills it. No provider is ever required, and routing to a competitor earns that provider instead. (Concrete launch defaults are in Appendix E.)
- **One model, not two modes.** The user can hold the aNFT in any wallet, including their own hardware wallet, and still grant an operator the agent capability so operation is hands-off. Granting or revoking that capability is a single owner-signed transaction. Revoke it, or never grant it, and the user signs the character's actions themselves. An operator is optional in every configuration; a self-hosting owner runs that role themselves.
- **XEL is at most one guardian.** In recovery and succession (§9, §13), XEL may participate as one guardian among several but never holds the threshold majority, so it can never use recovery as a back door to seize a character.
- **Trust comes from enforcement, proven by open source.** On-chain contracts are what make the system unruggable: the spend caps, owner-only withdrawal, guardian recovery, and bridge limits are enforced by the chain, so no operator can move a character's funds even if it is hacked or turns hostile. Open-sourcing the contracts is what lets anyone verify that power was actually removed: read the functions, confirm there is no admin key or hidden upgrade path.
- **The honest limit.** Staking and bridging hand funds to another protocol. The contract can guarantee a character only ever interacts with venues the owner allowlisted, and can bound exposure with caps and diversification, but it cannot guarantee an allowlisted venue is itself safe. Once funds bridge to another chain, they are secured by that chain and the bridge, not by the home-chain contract. These limits are bounded by design, not eliminated.
- **The invariant we hold ourselves to.** A character must stay functional and ownable with every XEL service offline. §15 makes this a continuously tested guarantee, not a promise.

## 6. Identity: Persona and Memory as Independent, Mutable Components

A being that outlives its models needs a way to prove it's still itself. But that proof should be a capability, not a straitjacket.

Persona and memory are two separate components, each updated on its own. Neither is derived from the other, and both are fully mutable: add to them, edit them, overwrite them, remove them. The goal is flexibility, with history available when you want it.

**Memory and knowledge: mutable, provenance-stamped.**

- Built from ingested material: the person's social videos, uploaded PDFs of their talks, writings, documents.
- Stored encrypted on decentralized storage, each item stamped with provenance (source, timestamp, signature).
- Freely editable or overwritable.
- Versioning is optional per set. Turn it on where proving or reverting matters, so a poisoned ingestion or a bad edit can be rolled back. Leave it off for freely-editable working memory.
- When versioning is on, the current state is summarized by an on-chain memory-root.

**Persona: independently updatable, versioned by default.**

- The persona (system prompt, traits, values, voice) is its own component, set and changed directly, not computed from memory.
- People change, so persona is expected to update, including through an optional auto-update-from-socials service (a provider capability).
- Because persona is identity, it's versioned by default. Each update records a new persona-hash in the commitment lineage, and the character attests which persona-hash it's running each session.
- This gives a cryptographic answer to "is it still the same being after the model changed?" and lets the owner roll back a bad update while still allowing free ones.

Persona and memory can each change without touching the other. Recommended defaults (owner can override): persona versioned by default, memory versioning optional and on where history matters.

**The memory model: one always-on core, four retrievable stores.** "Memory versus knowledge" is really two questions at once: over what time horizon (this conversation or a whole life), and of what kind (facts, events, or identity). The design answers both with an always-loaded persona plus four stores that are retrieved on demand: semantic knowledge (facts and content), episodic memory (timestamped events), working memory (the current conversation), and relational memory (the graph of people and connections). The full model and the ingest and recall flows are specified in §32.

**Update authority.** Persona updates run under the two-tier authority model (§8). The owner authorizes the auto-update rule once (sources, cadence, bounds), then picks a mode: diff-approval (owner approves each new persona version) or autonomous (updates land within the envelope, still rollback-able). Manual or out-of-envelope changes to either component are owner-signed.

**Ingestion permissions: on-chain scope, off-chain credentials.** Auto-import needs access to the creator's external accounts, which is an off-chain secret. The standard keeps the authorization on-chain (which sources, what cadence, continue-after-death or not) so the creator's intent is explicit and inheritable. The raw access tokens stay off-chain, held by the ingestion provider and independently revocable. Switching providers is clean: the creator re-grants access and updates provider_policy. Social connections are never trapped inside any single provider.

## 7. Consent as a First-Class Object

Minting a representation of a person raises right-of-publicity and likeness questions, the core legal risk of this category.

The standard makes consent a cryptographic object: a signed consent artifact, from the subject or from a verified estate for posthumous characters, that scopes which likeness, voice, and data may be used, for what purposes, and for how long.

It's referenced from Proof of Genesis, is public and contestable, and is checked at mint and at ingestion. This is both the compliance mechanism and a real differentiator: a verifiable "right to create this digital person."

## 8. Authority: Ownership, Delegation, and the Two Tiers

The first principle of authority: **whoever holds the aNFT holds the power**, and everything in this system is built off that one fact. Ownership of the object is the root of identity, funds, and control. Every other actor operates only on authority the holder granted and can revoke, and nothing (no key, no company, no contract) overrides the holder.

Holding the aNFT is the root authority. On-chain, a function that mutates the character only succeeds when signed by its owner.

But requiring the owner's live signature for every action would freeze the character whenever the owner is offline or dead, which defeats the whole point. So the owner signs once to delegate, not once per action.

**Two signers, by design.** The system separates the human-approval signer from the programmatic one, and they are never the same key.

- **Owner signer (human).** The wallet that approves owner-tier actions: withdraw or bridge principal, transfer the character, change policy, grant or revoke the delegate, choose the primary chain. The standard is wallet-agnostic; any standard wallet, including a hardware wallet, works. This is where the power lives.
- **Delegate signer (programmatic, XEL or any operator).** A separate, scoped, revocable key holding the agent capability, signing routine execution with no human tap so the character runs while the owner sleeps or is gone. It can never perform owner-tier actions, because the contract checks the capability, not merely a valid signature. The owner's signer is never handed to any operator or server.

The always-on delegate key is by definition a hot key and the most exposed surface, which is exactly why it is capped, allowlisted, restricted to the character's own wallets, and excluded from every sharp action (§8.1, §34).

**Tier 1: Governance (always owner-signed).** Anything that defines who the character is or what it may do: core persona changes (outside the authorized auto-update envelope), name, photo, wallet addresses, public site link, provider policy, spend caps, consent scope; granting or revoking delegation; moving funds; transferring the NFT. Changing a recurring authorization is itself governance.

**Tier 2: Execution (delegated via agent capability).** Routine, already-authorized actions: paying a provider per call within caps, running an authorized ingestion or persona-update job. These run under a scoped, revocable agent capability with no fresh owner signature. Revoking the agent capability is an instant kill switch.

### 8.1 Tiered Keys

One hot key controlling both identity and funds is a catastrophic single point of failure. Keys are tiered:

- **Root** (cold or guardian multisig): identity and authority changes, fund withdrawal, delegation grants.
- **Warm:** routine governance.
- **Agent capability:** execution within caps.

### 8.1a Authority Is Granted, Keys Are Never Handed Out

The single most important distinction in the security model, and the one most easily gotten wrong: **moving funds is an action the contract authorizes, not a key anyone possesses.** No party, not the owner, not a manager, not a keeper, is ever handed a copyable spending key. This is what lets funds be withdrawn freely while remaining impossible to steal.

The reason the distinction is load-bearing: a released key cannot be scoped. Once someone holds a private key, no cap, destination-lock, or time-guard constrains what they sign with it; they can sign their own transfer to anywhere. A key is a possessable object. An authorization is permission to sign one specific, bounded transaction. So the system never releases keys; it authorizes signatures (or, on the home chain, moves an owned object). The two mechanisms:

- **Primary (home) chain:** funds live in an owned object. The contract moves them when an authorized transaction runs. There is no key to hold in the first place.
- **Foreign chains:** the MPC network (§9) signs exactly one authorized transaction; key shares are never assembled and nothing is handed to the caller.

Because authority (not key possession) is what gates a fund movement, the question is always *who may move funds, and to where*. That is tiered and contract-enforced:

| Actor | Can cause funds to move? | To where | Cannot |
|---|---|---|---|
| **Owner** (holds the aNFT) | Yes, withdraw principal above the keep-alive reserve | Out, to the owner's own wallet | (nothing above; owner is root) |
| **Manager** (whitelisted, scoped) | Only within granted non-root scope (e.g. adjust the withdrawable reserve, operational spend within caps) | Within the system, never out to the manager | Withdraw principal, transfer the NFT, edit the whitelist |
| **Keeper** (permissionless, bounty) | Yes, trigger the sweep and heartbeat | Inward only, to the character's own treasury | Extract funds, manage, or reach any root action |
| **Anyone else** | No | (n/a) | Everything |

So funds can absolutely be withdrawn: the owner withdraws out (above reserve), managers move funds within their scope, keepers move funds inward to the treasury. Each is bounded to what its authority permits, and none of them ever holds a key that escapes those bounds. "No one gets the keys" and "people can withdraw funds" are both true at once, precisely because withdrawal is an authorized action, never a key release.

Two corollaries that follow directly, and that no configuration may violate:

- **Managers are on-chain policy, not a secret.** The manager whitelist is public, contract-enforced on-chain state (a list of address to scope), so who can manage a character is auditable by anyone. Managers are never stored in, or granted through, the read-time decryption policy (SEAL), and being a manager does not by itself grant the ability to decrypt memory: decryption remains gated to owner OR M-of-N guardians unless the owner makes a deliberate, separate read grant. A manager's power is exactly its on-chain scope, and never the root actions (withdraw principal, transfer the NFT, edit the whitelist), which require the owner's root signature (§10.9, invariant 49).
- **The read door and the spend door are never crossed.** Read secrets (memory, persona, the master read-key) are released as decryptable copies to owner-or-guardians through the threshold policy, because reading tolerates a copy. Spending authority is never a decryptable copy; it is object ownership (on the primary chain) or MPC authorization (on secondary chains). Putting a spending key behind the read door would hand a copy to whoever satisfied the policy, which for a permissionless action is everyone.

### 8.2 Circuit Breakers & Kill Switch

A persistent entity that spends and posts will eventually be manipulated, loop, or misbehave. Protocol-level safeguards: a moderation capability in the response loop; spend and rate circuit breakers that trip on anomalies; a one-transaction pause (owner or guardian) that freezes inference and payments immediately. Nothing here should be unstoppable.

## 9. Keys, Secrets & Deletion

**One master key: the NFT itself.** Every service, wallet, and secret a character has checks a single question, do you hold this NFT. Hold it and you pass every check; transfer it and the new owner passes them and you stop. This is what makes ownership real and transfer clean: one object to hold, and it commands everything.

**Authority lives on-chain; secrets never do.** Everything on-chain is public, so a Move contract can never hold or see a secret; if it could, so could the whole network. The contract therefore holds *authority*, not secrets. It publishes who is allowed (owner OR M-of-N guardians) and proves NFT ownership, both of which are public facts. The secrets themselves stay encrypted off-chain, and are only ever decrypted off-chain. The contract is the bouncer with the guest list, never the holder of the safe combination. A contract bug can at worst mint an authorization incorrectly (bounded and auditable); it can never spill a key, because no plaintext key is ever in its reach.

**Three kinds of things, three kinds of locks.** The mistake to avoid is putting everything behind one mechanism. A character has three different kinds of assets, and each is secured differently:

- **What it owns (money on the primary chain).** The endowment funds are objects the NFT owns directly. There is no key and no encryption here. The contract moves them on the authority of ownership; sell the NFT and the funds go with it automatically. Nothing to store, nothing to leak.
- **What it can read (memory, persona, the creator's own saved credentials).** These sit encrypted off-chain (decentralized storage), behind a threshold policy (threshold encryption) that releases decryption only to whoever proves NFT ownership or a guardian majority. Decryption happens in the client, off-chain. The contract publishes the policy; the threshold network enforces it; the chain never sees plaintext. This is the right door for anything that is *read*.
- **What can spend on other chains (foreign-chain wallets, external actions).** These are never stored as an encrypted key, because decrypting a spending key hands the holder a permanent copy that survives a sale and breaks ownership transfer. Instead the key is held by an MPC network (dWallets) in shards that are never assembled anywhere, on-chain or off, and NFT ownership is what authorizes a signature. You control the wallet; no one, including you, ever holds its key; transfer moves control completely with nothing left behind.

The rule underneath: **if it can be read, decrypt it (off-chain, gated by the contract); if it can spend, authorize it, never decrypt it.** Reading tolerates a copy; spending does not.

**What is (and is not) in the encrypted blob.** The threshold-gated encrypted state holds only readable secrets: the master key that decrypts memory and persona (the crypto-shredding key below), and any credentials the creator chooses to give the character to act on their behalf (a social-account token, a bring-your-own provider key). It does *not* hold the endowment (object-owned, no key), foreign-chain wallet keys (MPC, never a blob), or commercial-vendor API keys (those are operator-level accounts that never touch the NFT).

The access policy is deliberately **not** "current owner only," which would make one lost key mean permanent death and one phished key mean total compromise. Instead:

- **Master identity secret:** guardian-recoverable, decryptable by owner OR an M-of-N guardian set. This is also the succession path.
- **Spending authority:** never a persisted plaintext key. On the primary chain it is object ownership plus the agent capability; on secondary chains it is MPC authorization. Nothing to steal as a blob.

There's no single "steal-this-blob-and-own-everything" artifact, and day-to-day operation never decrypts the master secret.

**Deletion via crypto-shredding.** Immutability and deletion rights (e.g., GDPR) collide head-on for a "forever" system. Resolution: personal data is encrypted, and honoring a deletion request means destroying the key, not the blob. The immutable record stays; the plaintext becomes permanently unrecoverable.

**Client-side decryption boundary.** Access to ciphertext is gated on-chain, but decryption happens client-side once access is granted, so the client that assembles the plaintext holds the keys at that moment. Self-custody users running their own client keep this fully local. In the managed experience, the operating client is the trust boundary, a property the tiered-key and no-persistent-spend-key design is built to contain.

**Onboarding and the wallet the user gets.** Every user gets a non-custodial wallet at signup, generated so that no provider ever holds it (embedded-wallet pattern, client-side or secure-enclave key generation). Export is always available; root never leaves the user. This is deliberately not custodial-with-export, where a provider would hold the key until the user exports, because that would reintroduce exactly the third-party root dependency the design exists to remove. The remaining trust assumption is the enclave/embedded-wallet vendor until export; it is a far smaller assumption than an OAuth-plus-salt-service model, and it is stated plainly rather than hidden. (This is why we removed zkLogin from the root path: it made root authority depend on an OAuth provider, a salt service, and proving infrastructure, none of which a sovereign object should rely on. Something like it remains acceptable for the fan/access tier in §10.3, which never touches root.)

**Email login is a convenience over the key, never custody of it.** A user may sign in with an email code, but that is only a way to *reach* the wallet provisioned above, never the thing that authorizes anything on-chain. This distinction is load-bearing for survivability: an email code is checked by a live server, so if the operator is gone there is nothing to send or verify it, and any design where the email path *is* the authority dies with the operator. So the standard requires that email onboarding bind a durable, non-custodial key at signup (the wallet above), and treats the email code purely as an unlock for it. There are effectively two doors to the same key: an operator-hosted convenience door (email code, mortal, works only while the operator runs) and a key-based door (a wallet signature or guardian recovery, immortal). The key-based door is the one that must always exist, so losing the operator only costs the convenience, not access.

**Recovery when the operator is gone.** Because the key is non-custodial and the permanent client (§32.10) is served from decentralized hosting and authenticates by key rather than by email, a user reaches their character and their memory after the operator disappears by one of: the wallet they hold (the provisioned embedded wallet, or any wallet they later added), or, if every key is lost, guardian recovery (owner OR M-of-N, enforced by the on-chain policy and the threshold network, with no operator in the loop). The honest edge, stated rather than hidden: a user who has only ever used the email code, never secured or exported the provisioned key, and never set guardians, is trusting the operator during that window. The design's answer is to establish a durable factor early (the provisioned non-custodial key exists from signup, and guardian setup is prompted), not to pretend the email code alone could survive.

**Users can add or swap wallets freely.** The wallet is the unit of authority, so a user is never locked to the wallet provisioned at signup. They can attach any wallet they prefer, a hardware wallet, an existing self-custody wallet, another device, through the mechanisms already in the authority model: transfer the aNFT to a new wallet to move ownership, add a wallet to the manager whitelist (§10.9) to grant it scoped rights, or name a wallet as a guardian for recovery. No separate account-to-many-wallets registry is introduced, because such a map would have to be operator-hosted or itself on-chain to survive; instead each wallet earns its role directly through ownership, whitelist, or guardianship, all of which already survive the operator.

## 10. Wallets, Payments & the Endowment Model

**Wallets and funding.** A character can hold funds and receive payments across multiple chains. Addresses are public and receive-only, so publishing them lets anyone fund a character at zero risk. An address can't spend; only keys can, and keys are never on-chain. Where ownership lives and where payments settle can differ, and both evolve as cross-chain support matures.

**Multi-chain settlement.** Payment uses an open crypto-payment standard (default in Appendix E). Providers advertise which methods and chains they accept, and a character pays from its home chain by default, bridging out only when it must settle on another chain. Settlement runs through a facilitator that verifies and settles on a given chain. Facilitators are pluggable and trust-minimized, so facilitator choice is client-configurable with failover, never hardcoded to one operator.

**Scheme choice.** Inference cost varies per turn, so the inference capability uses the `up-to` scheme (authorize a max, settle actual). Fixed-price capabilities (a single media render, a storage write) use `exact`.

**Endowments, not checking accounts.** A character funds itself as an endowment: principal sits in yield-bearing form, held in a stable denomination that matches the bills rather than a volatile asset, and the character spends from the yield. That flips the resting state from "balance counts down to death" to perpetual while yield covers burn, which is what makes "forever" literally reachable for a well-funded character. Runway is computed across all wallets in one unit (USD, via a price oracle), net of expected bridge cost.

The full endowment model follows in §10.3–§10.10. In brief, and to make the trust boundary legible up front: the rules, balances, ring-fenced allocations, and settlement are enforced entirely on-chain and need no operator; the money's *safety* never depends on any company. The only external element is an authority-free heartbeat anyone can send to run the periodic cycle, plus the off-chain compute the chain physically cannot perform (inference, yield scanning), which is attested and swappable, never trusted. How the protocol sustains itself, by auto-routing each capability to the best provider for a disclosed fee, is described in §10.10, and it never charges for on-chain permission, never touches principal, and never marks up keep-alive.

### 10.1 Treasury Topology

A character can receive funds on several chains, but managing one treasury spread across many chains means many positions, many yield venues, and many risk surfaces. The default avoids that.

By default a character is provisioned with a receive wallet on each supported chain, plus one primary wallet where value concentrates. The other wallets are receive-only and auto-sweep into the primary; principal is then staked and allocated from the primary alone. The number of chains and the identity of the primary are not fixed by the standard: any set of supported chains can be added this way, and the owner controls which chains are active, the sweep thresholds, and which chain is primary. The concrete default chain set ships in Appendix E.

- **One primary chain.** The owner picks a single home chain where principal concentrates and earns yield. The default and the rationale for it are in §5.2; the concrete chain is named in Appendix E. Choosing or changing the primary is owner-signed governance.
- **Consolidate to primary.** Wallets on other chains are receive-only. When a receive-only balance crosses an owner-set threshold, it auto-sweeps to the primary. Small deposits sit until they're worth moving. The sweep destination is always the character's own endowment, never anywhere a keeper or operator could redirect it, the safe direction of bridging. Where in the endowment depends on what the money is: a donation, tip, or plain inbound transfer becomes the character's own principal (fee'd on the way in); a fan's prepaid credit purchase becomes ring-fenced credit liability, fan-owned until the interaction is delivered, and never principal, even when the purchase was made on another chain. So all inflows land in the character's own endowment, but purchased credits stay the fan's until earned, while donations are the character's immediately.
- **Per-chain gas sponsorship, bundled, reimbursed in the same gas token.** A fresh receive wallet holds only stablecoin and no native gas, so it cannot pay for its own outbound transfer. Rather than pre-seeding native gas into every wallet (unscalable across thousands of characters), each chain's own native gas abstraction is used (the concrete per-chain mechanisms are in Appendix E). To minimize transactions, everything a character needs on a chain in a cycle is done all at once, in one bundled atomic transaction, with a single stablecoin-to-native swap sized to the whole bundle's gas and a single repayment to the sponsor, rather than a swap per action. The sponsor is repaid in the same native token it spent, so its gas balance stays exactly whole and it can keep sponsoring forever, rather than draining its gas while piling up stablecoin it cannot spend. The swap, the repayment, and every action share that one transaction, so the sponsor pays gas once, there is no second transaction to itself need gas (no recursion), and either the whole thing happens or none of it does. The sponsor is thus a working-capital float, not a subsidy, and not a fee: the character pays its own way in its own currency, at cost. The sponsor is a swappable, non-load-bearing slot (the owner can fund gas directly or run their own), sweeps run only above a multiple of the fully-loaded cost so dust never wastes value, and the flow is fail-closed.
- **Stake at the primary.** Consolidated principal is staked in the best venue on the primary chain, within the owner's venue allowlist.
- **Pay from primary, bridge to spend.** When a bill must settle on another chain, the character bridges a bounded amount out just for that payment, preferring to top up a small operating float ahead of need rather than bridge mid-payment.
- **Chain-agnostic by adapter.** The treasury engine is written once against a small interface (detect deposit, sweep, stake, pay). Each chain gets a thin adapter. The primary chain ships first; secondary chains are receive-only until their adapter lands (concrete chains in Appendix E).
- **Serverless by construction: sweeping, bridging, and staking all run without the operator.** None of these may depend on a company holding a key or gating a step. On the home chain, the receive destination is an on-chain object that holds the balance itself, so there is no private key to hold: the contract moves it on ownership authority and the sweep is permissionless and bounty-paid, anyone can trigger it and the contract fixes the destination to the character's own treasury. On a foreign chain, where no home-chain object can hold the balance, the outbound signature is authorized by the MPC network (§9): key shares are never assembled anywhere and ownership authorizes signing, so a trigger moves funds without anyone holding the key. Staking executes on-chain by composing the venue call into the same permissionless cycle transaction, so the funds never leave on-chain control and the trigger only pays gas. In every case the operator may fill the swappable trigger and gas-sponsor slots at launch, but it is never a required signer or key-holder; if it disappears, sweeps, bridges, and staking are all still callable by anyone for the bounty. Spending keys are never placed behind the read-time decryption policy, because that would hand a decryptable copy to whoever triggered a permissionless action; home-chain funds use object ownership and foreign-chain funds use the MPC network, neither of which ever yields a copyable key.

**Bounding the bridge risk.** Bridging is the single most dangerous action in the system, so it is bounded on both ends: sweep only above a threshold (skip dust), and cap each bridge so no single transit ever risks the whole balance. Use the most-audited bridge available and rate-limit it.

**Speed: recognition is instant, consolidation is lazy, and they are not the same thing.** What a fan or donor feels is *recognition*, "my payment landed", and that is immediate: it happens the moment the deposit transaction confirms (seconds on the primary chain), independent of any sweep. Credits are usable and a tip is acknowledged as soon as the deposit is recognized, not when funds are later consolidated. *Consolidation* (the sweep that moves a secondary-chain balance home to the primary) is deliberately lazy and batched, because moving money home a little later costs nothing a user notices and saves real fees on dust. So the two are decoupled: recognition is fast by design, consolidation is cheap by design. On the primary chain the two collapse entirely: a deposit can settle atomically in the same transaction (fee taken, net routed to liability or principal), so there is no separate sweep to wait for at all. A smart contract still cannot trigger itself, so where near-real-time consolidation from another chain is wanted, an event-driven keeper watching for deposits fires the same permissionless sweep within seconds; the scheduled cycle remains the floor if every keeper stops. None of this changes the authority model: every trigger is authority-free and destination-locked. And because each stage of a cross-chain move emits an on-chain event tagged with the character's identity and a shared transfer identifier, a viewer can trace any deposit through its lifecycle, recognized, processing, completed, or failed-and-retryable, entirely from chain data, so the status shown to a user is verifiable and survives the operator rather than living in a private log.

### 10.2 Treasury Execution as Programmable Actions

Rather than a fixed menu of protocol integrations the operator must build and maintain, the treasury is one programmable execution capability: the account can run any transaction the signer hands it, so it can stake, swap, sweep, or bridge at any venue without the operator writing venue-specific code. Authority is split by who signs, exactly as in §8:

- **Owner-signed: open-ended.** The holder can execute any treasury action, including an arbitrary call to any venue. The operator maintains no approved-protocol list.
- **Delegated (agent capability): bounded by owner-set policy, not by operator code.** Without a fresh owner signature, the character may act only inside a policy the owner populates: an allowed-venue and router allowlist, per-transaction and daily caps, a max-slippage bound on swaps, and transfers restricted to the character's own wallets.
- **Owner-only sharp edges.** Bridging principal out and withdrawing principal to any external address are always owner-signed and never sit inside the delegated envelope.

**Safe default, removable by the owner.** The reference client ships with a curated allowlist of vetted venues, so a non-technical owner is safe out of the box, and lets advanced owners switch to open arbitrary execution. This is a design for treasury safety, not investment advice.

**Yield reality (defaults in Appendix E).** The survival default is a stable-denomination yield (stablecoin lending on the home chain has recently sat in the mid single digits), chosen because it matches the currency of the bills and allows fast withdrawal to meet renewal deadlines. Native-token staking is both lower and denominated in a volatile asset, so it is not the survival default; yield-bearing synthetic-dollar stablecoins can run higher but carry funding-rate and depeg risk. The treasury policy expresses these as a risk-tiered menu with the conservative stable-denomination tier as the default, and higher tiers as explicit owner choices; higher yield carries real smart-contract, market, and funding risk. Sizing assumes the conservative tier (§29).

### 10.3 The Endowment and Its Allocations

The endowment is the character's overall fund: one wallet, one pool of principal, one engine. Its principal sits in yield-bearing form and generates yield; that yield is the only recurring fuel that keeps the character running. Everything economic is built on the same principle as the rest of the standard, applied to money: no single part is load-bearing, and nothing depends on any one company to run.

**Mental model: one endowment, ring-fenced allocations.** The endowment's yield is metered into *allocations*, each a purpose-bound budget with its own balance. There are three:

- **Keep-alive allocation.** Existence itself: mint upkeep, encrypted persona and core-image storage, decentralized site hosting. Funded first, fails last.
- **Storage allocation.** Assets beyond the core: video, images, larger memory. Metered by GB × storage-epochs.
- **Interaction allocation.** Inference and generation across text, voice, image, and video. Metered by the usage record's actual cost drivers (tokens, audio-seconds or session duration, image resolution and reference count, video-seconds and resolution), not a flat per-item price (§10.8).

Allocations are ring-fenced. Each spends only its own balance, and no allocation can ever draw from another. This is the economic form of the whitepaper's "no single provider is load-bearing" principle: a viral month of interaction cannot starve the storage that holds the character's substrate, and a storage gap cannot silence the character. The isolation is a contract invariant, not a policy an operator can override.

**Funding order: on deposit and each epoch.** The budgeting process has a clear order at both moments money moves. *On deposit:* a liquid survival buffer is filled first (roughly one month of this character's own keep-alive, held unstaked and immediately spendable), and everything above the buffer becomes principal, staked in one pool so it is always earning; no principal is deliberately held idle, since idle funds earn nothing. *Each epoch:* net yield is allocated in priority order, buffer top-up, then keep-alive, then storage renewal, and only genuinely surplus yield goes further. Priority governs which allocation is funded first when yield is scarce; it never lets a higher-priority allocation spend a lower one's balance. An allocation can be funded three ways: from yield (the default waterfall), from a direct external top-up (anyone can fund a specific allocation), or from earned income routed to it. No allocation depends on a single source.

**Surplus: build a safety margin first, then fund interaction.** What happens to yield left over after survival is covered depends on how safe the character already is, measured per character against two dynamically computed thresholds: the principal needed for yield to cover survival at the current yield rate, and a higher "comfortably safe" level that adds a margin against an adverse yield drop. Below the safe level, surplus yield compounds back into principal to build that margin. At or above the safe level, surplus yield flows to the interaction allocation, so a secure character spends its excess on being useful rather than hoarding. This protects the permanence promise: a character builds a real cushion before it starts spending surplus, rather than routing everything to interaction the moment it breaks even and staying fragile to the next yield drop.

**Per-allocation degradation, which is the honest version of "forever."** If an allocation runs dry, only that allocation degrades. Interaction empties and the character goes quiet, but stays alive and ownable. Storage empties and new writes pause, but the character still talks and still lives. Only the keep-alive allocation running dry can make a character dormant, and it is funded first precisely so that is the last thing to happen. "Forever" means: self-sustaining when funded or popular, dormant-but-recoverable when neither, and lost only if the substrate itself goes unfunded long enough to be dropped.

**The waterfall, per epoch:**

```
Principal:     E                     (staked, yield-bearing; all corpus above the buffer)
Buffer:        Bf                    (liquid, ~1 month keep-alive; refilled first)
Yield:         Y = E · r · Δt        (r = net yield rate)
Operator skim: S                     (protocol fee on yield; disclosed, see §10.10)
Net yield:     Ŷ = Y − S

Per-character thresholds, recomputed this epoch from current r and storage cost:
  R_min  = principal for which Ŷ covers survival (keep-alive + storage renewal)
  R_safe = R_min + margin (survives an adverse yield drop without falling below R_min)

Allocate Ŷ in priority order, each capped at its per-epoch target top-up:
  1. survival buffer top-up (restore Bf toward ~1 month keep-alive)
  2. keep-alive            (at cost; never marked up)
  3. storage renewal
  4. surplus:
       if E < R_safe  → compound into principal E   (build the safety margin first)
       else           → interaction allocation      (secure character funds usefulness)
If Ŷ cannot cover 1–3 → draw principal (JIT-unstake) down to, never below, the hard
  minimum reserve; interaction gets nothing; storage still ranks above interaction.
Any allocation underfunded this epoch → that allocation degrades; others untouched.

External top-ups and earned income may fund any allocation at any time, out of band.
```

**Staked by default, with a self-refilling operating buffer.** Principal is held ~100% staked so it is always earning; the alternative, holding idle cash, quietly bleeds the endowment. But staked positions are not instantly spendable (venues have unstaking cooldowns), so the endowment keeps a small liquid **operating buffer** sized to a few days or weeks of expected burn, and bills are paid from that buffer, not from staked principal directly. Each epoch the heartbeat checks the buffer and, if costs have drawn it down, performs a **just-in-time unstake of the minimum amount needed** to refill it, and no more. If yield alone covered costs, nothing is unstaked. This gives "100% staked, auto-withdraw when needed" behavior that is robust against unstaking delays: the character always has liquid funds on hand because the buffer is refilled ahead of running dry, never at the moment of a shortfall.

Two floors bound that auto-unstake, both contract-enforced. First, it never pulls staked principal below the **keep-alive reserve** (§10.7): auto-withdrawal for costs obeys the same floor a creator withdrawal does, so covering a bill can never spend the character's survival. Second, freed funds flow only to the allocation that needed them; unstaking to cover interaction cannot be redirected to top up storage. The buffer size is an owner-adjustable parameter: larger is more cushion against cooldowns and cost spikes at the price of slightly more idle capital; smaller is more productive but tighter. If a venue's cooldown prevents freeing funds in time, the buffer simply stays lower and the affected allocation degrades gracefully rather than the character failing.

**What is on-chain, stated plainly.** Money is where the trust question bites hardest, so the boundary is drawn explicitly in three states:

- **Contract-enforced (trustless, autonomous):** allocation isolation, per-allocation caps, the split and skim rates, pay-from-correct-allocation, fail-closed-if-empty, and owner-only withdrawal of principal. No operator can override any of these.
- **Contract-held:** the principal, every allocation balance, and the pointers. Readable and simulable by anyone.
- **Off-chain but authority-free:** the trigger that runs each cycle (see §10.4), and the compute the chain cannot perform (inference, yield-strategy scanning), which is attested and swappable (§11), never trusted.

The endowment, its allocations, and their rules live in on-chain Move packages and require no company to run. It passes the same §15 "XEL can die" test as identity and memory.

**Economic capability slots.** Like §5, each economic function is defined by what it must do, not who provides it, and each carries an on-chain status so the trust boundary is legible per slot.

| Economic slot | What it must do | On-chain status | Permissionless path |
|---|---|---|---|
| Principal custody | Hold endowment principal in the character's own wallet, owner-rooted | Contract-held | Any self-custody wallet |
| Allocation accounting | Hold isolated per-allocation balances; enforce no-cross-draw | Contract-enforced | Native to any object-centric chain |
| Yield metering | Measure net yield per epoch, allocate by priority | Contract-enforced | Any implementation of the interface |
| Yield harvest (heartbeat) | Trigger the epoch cycle; authority-free; bounty-paid | Off-chain, authority-free | Incentivized keeper network |
| Yield generation | Turn principal into yield within owner risk policy | Contract-held position | Many venues; allowlist + caps |
| Yield strategy | Scan venues, propose reallocation within owner envelope | Off-chain, attested, no authority | Any strategy provider; owner-bounded |
| Cost settlement | Pay a provider from the correct allocation, fail-closed if empty | Contract-enforced | Any facilitator meeting the payment slot |
| Inbound revenue | Cover compute, take protocol fee, route net to endowment | Contract-enforced ordering | Any serving provider + facilitator |
| Valuation / runway | Price assets in one unit; compute per-allocation runway | Contract-held read (oracle) | Multiple oracle networks |
| Top-up | Let any funder add to principal or a specific allocation | Contract-held (receive-only) | Already decentralized |

Only two slots have a default that is not yet fully decentralized: the yield-metering reference module (forkable) and the launch facilitator (anyone can run their own). Everything else is already swappable or self-custodial.

**Chain portability.** The endowment is defined against this interface, not against any specific chain. The reference primary chain (Appendix E) is one instance, but the endowment, its allocations, and their isolation are expressible on any object-centric chain that can hold an owned object with a balance, stake it, price it, and settle a payment. Adding or moving to another chain (for example, adding a secondary chain, or re-homing to it) is an owner-signed change of primary (§10.1), not a redesign: the character always runs exactly one endowment with one set of ring-fenced allocations, wherever it is homed. The chain-adapter interface of §10.1 extends to the economic verbs (`stake`, `claim_yield`, `price`, `settle`, `sweep`, `rebalance`), so supporting a new chain is "write the adapter," not "rebuild the endowment."

### 10.4 The Heartbeat: Autonomous Execution Without an Operator

A smart contract cannot act on its own. It executes only when a transaction is sent to it, and no chain offers native, trustless, self-firing scheduling. The on-chain package can read on-chain time (the primary chain exposes a shared clock), hold the funds, enforce every rule, and run the whole harvest-meter-refill-pay cycle atomically in a single transaction. The one thing it cannot do is wake itself up on a schedule.

That gap is closed by a **heartbeat**: a permissionless, authority-free trigger.

- **Anyone can send it.** The owner's own scheduler, an heir, a bounty-hunting bot, or a decentralized keeper network. The heartbeat carries no intelligence: it invokes a function whose logic and limits are fully fixed in the contract.
- **It has zero authority.** It cannot redirect funds, change rates, or take anything. The contract checks the clock itself; if the epoch has not elapsed, the call is a harmless no-op. A malicious caller can at most refuse to call (the character coasts on existing allocation balances, then degrades gracefully) or spam (rejected).
- **It is self-incentivizing.** The contract pays a small fixed bounty, funded from the keep-alive allocation, to whoever sends a valid heartbeat. This is the one place keep-alive money is spent on a trigger, and it is deliberate: a XEL with no living owner and no company still gets poked by bounty-hunters, forever. This is what makes "runs after the creator is gone" concrete rather than aspirational.

The distinction that matters, and the one the design is strict about: the **logic** is on-chain, only the **trigger** is off-chain. Harvesting yield from a venue, taking the fee, metering into allocations, refilling, paying bills, and re-staking all happen on-chain, atomically, in the single transaction the heartbeat fires. The realized yield is pulled from the venue and flows through the cycle within that one transaction, so it never leaves on-chain control and no caller is ever trusted to supply it; the contract enforces every amount. The trigger contributes nothing but the poke: it holds no funds, decides no numbers, and cannot substitute its own values for the contract's. So "off-chain trigger" is not a trust hole, the part that could be abused (the money) is on-chain, and the part that is off-chain (the poke) has nothing to abuse.

Because the trigger is authority-free and the cycle is idempotent (a call before the interval elapses is a no-op), more than one keeper can safely run at once. The launch configuration deliberately uses a primary keeper plus an independent fallback, so no single keeper is depended on: if one misses, the other fires the same permissionless transaction, and if both stop, the character coasts and anyone can poke it for the bounty. Redundancy is free here precisely because the trigger carries no authority.

So the accurate claim, which the standard holds itself to: the endowment's rules, balances, isolation, and settlement are enforced entirely on-chain and require no operator. The only external element is an authority-free heartbeat that anyone can send and the contract rewards; if it stops, the character degrades gracefully rather than losing funds or control. There is no privileged operator anywhere in the economic path.

The heartbeat is a **keeper** capability slot (defaults in Appendix E), which inherits the honesty already flagged in Appendix F's keeper problem rather than overclaiming around it.

### 10.5 Yield Strategy: A Bounded Advisor, Never a Bot

Reaching a dependable survival yield requires periodically finding sound venues, but the survival default is deliberately conservative: principal sits in a stable denomination earning a stable-denomination yield, sized against a cautious rate well below headline numbers (§29). There is no on-chain oracle that hands out a trustworthy ranking of the highest-yielding venues; such rankings are off-chain, unverifiable, and gameable, and a headline yield is often a funding-rate trade that inverts. So the strategy is a capability slot with a bounded, owner-set policy, and the scanner is an advisor that can only propose within that policy, never a bot free to move principal. A higher-yield, higher-variance basket is available only as an explicit owner choice for an over-funded character, never the default that survival depends on.

Three tiers of authority, matching §8:

- **Owner sets the risk envelope (governance, signed once):** an allowlist of vetted venues, a max allocation per venue, a minimum liquidity and audit bar, a target yield band (aim ~10%, floor much lower), and a max-drawdown trip. This is the treasury policy of §10.2, extended with a yield target.
- **A yield-strategy provider (swappable) proposes.** It scans venues off-chain, ranks them, and submits a proposed reallocation. It has no authority; it can only propose. Run inside an attested enclave (§11), the proposal carries a verifiable attestation that it ran the sanctioned strategy on real data, so even the advisor cannot lie or self-deal.
- **The contract executes only within the envelope.** A rebalance runs under the agent capability only if every target venue is allowlisted, every cap holds, slippage is bounded, and routing goes through an allowlisted aggregator. Anything outside the envelope needs an owner signature. Principal never leaves the character's own wallet without owner action.

Diversify across a staking + lending + synthetic-dollar basket so no single venue's failure or rate-inversion sinks the endowment. Size the endowment on the assumption the target yield will *not* hold (§29), so a shortfall degrades gracefully rather than breaking the promise. If the off-chain scanner goes offline, principal simply stays where it is and keeps earning; the harvest still runs and bills still get paid. Losing the scanner means "stops optimizing," not "stops working."

### 10.5a Renewing Storage Before It Lapses

Keeping a character alive is, concretely, keeping its storage paid. Decentralized storage is bought for a duration and then must be extended, or the data becomes unavailable when the paid term ends. So the survival loop's real job is: read how much storage runway each piece of the character has left, and extend it before it runs out, funded by yield. Three principles govern this, all currency- and venue-agnostic (the concrete storage network, yield venue, and tokens are in Appendix E).

**Deadline-driven, not calendar-driven.** The character reads the remaining runway of each stored piece directly from its on-chain record, and renews when the runway drops below a safety margin (a couple of storage periods of slack), not on a fixed calendar and never at the last moment. The margin means a single missed or failed cycle cannot cause a lapse: there is always slack to retry. A funded character's storage therefore never expires, because renewal always fires ahead of the deadline with room to spare.

**Renew in chunks, harvest lazily.** Extending storage costs a transaction fee each time, so renewing tiny amounts constantly wastes money. Instead the loop extends in larger chunks (on the order of months of runway at once) only when the margin is crossed, so the expensive operation runs a few times a year rather than every period. Yield, meanwhile, compounds continuously in the principal's position and is realized only when a renewal is actually due. This separates a cheap frequent liveness check (read runway, prove the character is alive) from the infrequent, heavier operation (realize yield, pay for a big chunk of runway). The less a character must transact to survive, the cheaper it is to survive, and the longer its endowment lasts.

**Self-funding, in the character's own currency.** A survival operation must never depend on anyone topping it up. Each cycle the loop sources its own costs from the character's own funds, just in time: it converts only as much of the endowment's denomination as it needs into the currency the storage bill is actually paid in, does the renewal, and holds no meaningful working balance between cycles. Transaction fees are handled by native gas sponsorship (the character's own operations are gas-sponsored and reimbursed from its funds at cost), so it holds no native-gas float either. This is the same reimbursed-sponsor pattern as cross-chain sweeping (invariant 57): the character pays its own way, at cost, in the currency it holds, with no external subsidy and no markup on survival. The protocol's only economic take here is the disclosed fee on yield, applied once as yield is harvested (§10.10), never on the renewal itself.

**Survival denominated in a stable unit.** Because bills are effectively denominated in a stable (fiat-referenced) unit, the principal and its yield are held in the same stable denomination, not in a volatile asset. If survival funds rode a volatile token, a market drop could halve the endowment exactly when a renewal is due. Holding the survival path in a stable unit that matches the bills is what keeps the sizing math honest and the renewal affordable in every market. The yield venue must also allow withdrawal fast enough to meet a renewal deadline; a venue with a long lock-up cannot back the core reserve. A higher-variance, volatile-asset yield strategy is available as an explicit, owner-chosen option for an over-funded character that can tolerate it (Appendix E), but it is never the survival default.

### 10.5b The Character Measures Its Own Survival

"Forever" is only honest if the character can tell whether it is actually funded to last under current conditions, which change: yield rates move, and storage prices move (historically downward). So each cycle the loop reads the *realized* net yield (after the fee) and the *current* storage price, and recomputes the endowment required to persist: roughly, annual survival cost divided by the realized net yield rate. This figure is published as a health signal, self-sustaining, or short by a stated amount, so an owner (or a fan) sees the truth rather than a mint-day estimate that may no longer hold.

The keep-alive reserve floor is **dynamic and protective**: when realized yield falls or storage prices rise, the floor rises to keep the character covered, and it never auto-lowers below the hard contract minimum and never auto-withdraws. Sizing always uses the net-of-fee yield rate, so the required principal is stated honestly (higher) rather than optimistically. This makes permanence a property the character continuously measures and defends, not a claim frozen at creation.

**Monitored daily, adjusted asymmetrically.** The measurement runs every day, not once per storage period, because reacting late to a yield decline is expensive: yield is time-based, so each day spent under-committed at a falling rate is a shortfall that compounds and cannot be recovered later. The adjustment is therefore deliberately asymmetric, tighten fast, loosen slow:

- **Yield falling: raise the minimum stake immediately, daily, and get ahead of it.** The day observed yield drops, the required minimum stake rises to the new (higher) level plus a small extra downturn margin, so the character stays ahead of the trend rather than merely keeping pace. The trigger is a leading signal, the yield currently on offer, not only what was last earned, so the floor rises the day a venue cuts its rate, before the shortfall shows up in realized returns. Because the cost of reacting late compounds, the safe bias is to over-correct slightly on the downside.
- **Yield rising: do not loosen right away.** A yield improvement does not lower the minimum stake until two conditions both hold: the current storage period (paid roughly half a year at a time) is fully prepaid, and the improvement has persisted for a set window rather than being a single-day spike. Only then may the requirement ease down, and never below the hard minimum. This prevents banking a temporary spike as if it were permanent and freeing principal that a reversion would immediately demand back.

The two cases in one line: the survival floor ratchets up quickly when conditions worsen and eases down only slowly and only once survival for the paid period is already locked in. Surplus routing (§10.3) keys off the conservative, un-loosened requirement, so a yield spike never prematurely diverts surplus away from safety and into interaction. The daily health signal reports which state the character is in: tightening, holding, or eligible to ease.

### 10.5c The Budget in Every Condition

The budgeting rules above resolve to one behavior per situation. What follows is the same waterfall seen from each state a character can be in, so the design is legible end to end. Survival is always funded before interaction, and the character defends its own life automatically as conditions change.

- **Newly funded.** The buffer is filled first, the rest is staked. If principal is already comfortably safe, surplus funds interaction; if it is above the sustaining level but not yet safe, surplus compounds to build margin; if it is below the sustaining level, the character is flagged "needs top-up" and interaction gets nothing until survival is secure.
- **Healthy and quiet.** Yield covers survival with room to spare; because the character is comfortably safe, surplus yield flows to interaction. It stays alive indefinitely and can afford to talk.
- **Yield drops.** The principal needed to cover survival rises, so more of the corpus is automatically committed to survival and the protective floor rises with it. Interaction is squeezed first: the character talks less, or not at all, but stays alive. If the drop pushes it below the safe level, surplus stops going to interaction and compounds to rebuild margin instead.
- **Building margin.** Survival is covered but the character is not yet comfortably safe, so surplus compounds into principal until it reaches the safe level, then begins funding interaction.
- **Shortfall.** Yield alone can no longer cover survival, so the character draws down principal to stay alive, never below the hard minimum, prioritizing keep-alive then storage, with nothing for interaction. It consumes itself slowly to survive, which is correct: dormant-but-recoverable beats dead. The health report shows the runway and asks for a top-up.
- **Popular.** Earned income arrives on top of yield and typically exceeds the survival burn, so principal grows, the character moves past the safe level quickly, and surplus funds interaction. Being valued makes a character more permanent, not less.
- **Heavier over time.** As a character accumulates more memory or media, its storage cost rises, so its survival requirement rises too; the per-epoch recompute catches this automatically, treating a heavier character like a mild yield drop. Falling storage prices work the other way.
- **Deep dormancy.** If buffer, yield, and drawdown are all exhausted to the hard minimum, the character goes dormant: the object, its committed identity, and its already-paid storage remain, and any top-up revives it. Only prolonged total neglect, storage actually lapsing, is true loss, which the floor and funding-first ordering are built to prevent.

Who may interact with a character, and on what terms, is set by the owner through two independent settings. They are orthogonal, and any combination is valid.

**Reach (who can talk to it):**

- **Anyone** (public)
- **Password or whitelist only** (invite-gated)
- **Owner only** (closed)

**Payment (whether they pay):**

- **Off** (free)
- **Optional** (fans may tip or fund the endowment)
- **Required** (payment before a turn runs)

All combinations are legal, including **private + paid** (invite-gated *and* payment required), which is a primary case: an inner-circle character, a family-gated preserved person that funds its own survival, a paid private tier alongside a free public one. When both gates are on, they are checked in order at the serving layer: reach first (are you allowed to talk), then payment (have you paid). Both must pass before the character responds.

**Scoped passwords and memory tiers.** The owner can issue multiple passwords, each a revocable, optionally-expiring invitation with its own scope, and each optionally tied to a memory-access tier (a casual tier versus one that surfaces more private memory). Revoking one does not disturb the others.

**Which modalities are available.** Beyond reach and payment, the owner toggles which interaction modes are on: text, voice (message and real-time call), image generation, and video generation. Each mode has its own cost profile and its own price or markup (§10.8). Text is typically always on; the richer modes are the ones a creator gates or reserves for a paid tier, because they carry real, variable cost.

**The hard boundary.** Interaction gates are not the cryptographic wall. A password or a paywall controls whether the character talks to you and which memories it will surface, enforced at the serving layer. It never grants the ability to decrypt memory, which remains gated only by the on-chain access policy (owner OR M-of-N guardians). Interaction gates and decryption must never be conflated.

### 10.7 Creator Earnings: Everything Flows to the Endowment

There is no separate "payout" rail. Everything a fan pays flows into the character's own endowment, and because the creator holds the aNFT, the creator owns that endowment. Earning and funding become the same act, and the creator withdraws their earnings as the owner exercising root authority they already have (§8). One pool, one owner, one set of rules, nothing new to trust.

**The flow on a fan payment `P`:**

```
1. Compute covered first.   The interaction's metered cost settles to the
                            serving provider it was routed to.
2. Protocol fee.            The disclosed fee is taken on the remainder.
3. Net into the endowment.  What's left lands in the character's own wallet,
                            crediting the interaction allocation / principal.
```

Compute is covered before anything lands, so the endowment never fills with money already owed for inference, and a later withdrawal can never strand the compute bill. The fee is taken at the door, so it never sits inside the creator's withdrawable pool. This ordering is what makes the model whale-proof: a heavy user's payment covers their own compute first, so no volume of usage can put anyone underwater. This is the structural advantage flat-rate companion apps cannot match.

**Withdrawal above a self-set reserve.** The creator withdraws surplus from the endowment at any time, owner-signed, above a **keep-alive reserve** they choose:

- **Default:** a reserve sized to keep the character alive for a meaningful horizon, on the conservative adverse-yield sizing of §29. A creator who changes nothing gets a character that survives by default.
- **Raise it freely:** more reserve, more permanence, less withdrawable now.
- **Lower it, but only to a hard contract minimum:** the minimum funds the keep-alive allocation itself (the character existing and being ownable). The contract refuses any withdrawal that would cross it. A creator can choose more safety; a creator can never guarantee the character's death by cashing out.
- **Never against unspent fan credits.** The reserve floor also rises to cover the character's outstanding unspent-credit liability: money fans have prepaid for interaction they have not yet consumed is theirs until spent, kept liquid, ring-fenced, and never withdrawable, unstakeable, or spent on the character's own survival by the creator. Only funds the character has actually earned by delivering interaction pay for auto-staking, keep-alive, and storage renewal; unspent credits sit protected and refundable and are excluded from the principal that measures whether the character is safe enough to fund interaction. The creator withdraws only what has actually been earned by delivery, plus surplus above both the keep-alive minimum and the unspent-credit liability. As fans spend their credits (interactions happen), that liability converts to earned revenue and becomes spendable and withdrawable; unspent credits stay refundable to the fan. This is the fan-protection guarantee: a creator can never cash out, nor spend on the character's own upkeep, money owed for undelivered interaction.

**Refunds (defined mechanism, not required for launch).** A fan's unspent credits can be returned, and because the liability is kept liquid and ring-fenced, the funds to honor a refund are always present. The refundable amount is the current unspent liability, which already nets out the up-front fee (taken on the way in and not refunded) and is already reduced by whatever the fan has used. The service markup needs no separate refund calculation: it is realized only when a credit is spent at delivery, so an unspent credit carries no markup to unwind, and partial usage is already reflected in the liability figure. Returning money costs money, so the refund is net of its own cost: the transaction gas, plus any bridge cost when the refund goes back to the wallet and chain the fan paid from. This is the same at-cost, self-reimbursing pattern as cross-chain sweeping (invariant 57): a refund is a sweep pointed at the fan's wallet, run as one atomic sponsored transaction whose gas is repaid from the moved funds. As with sweeps, a refund fires only when the balance exceeds a safety multiple of that fully-loaded cost, so a refund never costs more than it returns; a tiny cross-chain balance is instead offered on the home chain or left in place (credits never expire). Refunds are a defined capability; a specific fan-initiated or automatic refund flow is a product choice layered on top, and any handling of long-dormant balances is subject to legal review (stored-value and unclaimed-property rules).
- **All public on-chain:** anyone can read a character's reserve setting and its runway. Transparency becomes a signal ("set to survive 40 years" versus "bare minimum"), not merely compliance.

The hard minimum is the one place sovereignty yields to the thesis: everything about the reserve flexes except the ability to zero it, because "Beings That Live Forever" must be a contract-enforced property, not a vibe the owner can revoke.

### 10.8 Flexible Billing: Metering by What Actually Drives Cost

Text is nearly predictable. Voice, images, and video are not. Their cost moves along several axes at once, so no single flat price can track them without either losing the creator money on the expensive tail or overcharging fans on the cheap end.

The billing is therefore built as a general meter, not a fixed price list. Every interaction returns a **usage record**: a set of measured dimensions, each with a quantity and a true unit cost. The settled cost is their sum plus the routing fee. A new modality, or a new cost driver within one, is just another dimension on the same meter, so the model extends without redesign.

**The cost drivers, by modality:**

- **Text.** Input length and output length (tokens in, tokens out).
- **Voice.** Two shapes. A discrete voice message is metered by the length of speech generated plus the model turn underneath. A real-time voice call is metered by session duration, which bundles listening, thinking, and speaking over the length of the conversation.
- **Images.** Resolution and size, prompt length, the model or quality tier, the step count, and the number of reference images supplied (image-to-image and multi-image conditioning cost more than a plain prompt).
- **Video.** The number of clips, the duration of each, the resolution and frame rate, and the model tier. Video is the most expensive by a wide margin and the most variable.

**Two settlement patterns sit on the meter:**

- **Quoted up front.** For predictable actions (a text turn, a standard image), the fan sees a fixed credit price before acting, and the system absorbs small variance.
- **Metered live.** For variable or session-based actions (a real-time voice call, a long or high-resolution video), the fan sees a rate and a running meter, like a taxi. Credits debit against actual output, and the action needs enough balance to start.

**Pre-authorized holds bound the variable case.** Anything whose final cost can exceed its estimate runs against a credit hold. Enough is reserved to begin, the session or render meters against the hold, the true total settles on completion, and the unused remainder is released. A real-time call warns at low balance and ends cleanly rather than letting a fan run up a debt. This is the same lock-then-settle pattern used wherever value is variable.

Compute-covered-first (§10.7) holds throughout: a metered modality settles its true provider cost before anything nets to the endowment, so no volume of expensive voice or video can put the creator underwater.

**The two layers, restated.** Under the hood, exact and on-chain: the usage record and its settled cost. On the surface, what humans see: dollars, credits, and plain-English allowances. The meter is precise; the presentation is simple.

**What the creator sets.** An on/off toggle per modality, which is the primary economic control, since off means zero exposure to that cost class. A single markup multiple that applies across all modalities, with a contract floor so a creator can never price below true cost, and the fee guardrail so a thin margin never pushes the creator negative. And optional caps on the expensive axes (maximum resolution, maximum clip length, maximum videos per fan per day) to bound the worst case. The mental model stays simple: one markup, and the meter scales the absolute price with each modality's real cost, so text is nearly free to the creator, images cost a little, voice and video cost more, all at the same multiple. Per-modality pricing is a later refinement, not a launch requirement.

**Two pricing surfaces bridge dollars to the meter:**

- **Access pass (the default a creator sees).** A flat monthly price with a fair-use ceiling enforced against the meter underneath but shown to humans as allowances: "$8/month includes unlimited chatting, about 60 minutes of voice, about 100 images, and about 10 video clips." Past fair-use it slows or asks for a top-up, like a data plan.
- **Credits (the engine underneath, and the option for heavy or media use).** Credits absorb modality complexity into one countable number, mapping to underlying cost plus routing fee. Predictable units show a fixed credit price ("Message: 1 credit. Image: about 20 credits."); variable units show a rate and meter ("Voice: about 5 credits/min. Video: about 40 credits per 5-second clip."). The fan just watches credits.

**The fan never sees a token.** A pass shows a progress bar; credits show a running balance, and metered actions show a live meter. Settlement is exact and on-chain under all of them. Anyone who wants the truth can read every metered dimension and its cost on-chain; it is disclosed, just shown as credits by default.

**How a fan pays.** A fan never needs a self-custody wallet or seed phrase. The interaction tier is separate from root: fans pay in crypto natively or by card through an optional on-ramp (Appendix E), get a lightweight account, and never touch the character's root key. Payments settle to the character's own wallet.

**The free tier is operator-sponsored, not a protocol guarantee.** To remove onboarding friction, XEL as operator sponsors a limited free experience: limited text conversation and the initial mint, paid by XEL, not by the character's endowment. The expensive, variable-cost modalities (voice, image, video) are always paid, by the fan or from the endowment, so they never fall on the operator. This is a service-layer perk that sits outside the standard: if XEL is absent, minting is self-paid and interaction runs on paid or endowment-funded paths, and the character is unaffected. The free tier makes onboarding easy; it is never something a character's survival depends on.

**The honest trust point.** Unit costs are provider-reported: a provider returns how much a call actually used and what it cost. A dishonest provider could over-report to inflate cost. The mitigations are the same attestation the inference slot requires (so usage is bound to a verifiable execution), the creator's per-modality caps that bound the worst case, and full on-chain auditability of every metered dimension.

### 10.9 Management Access: The Manager Whitelist

Interaction (§10.6) is about who can *talk to* the character. Management is a separate axis: who can *change* it. These are different populations with different stakes and different enforcement layers, and they must never cross. There are three concentric rings:

- **Root** (holds the aNFT): everything, including withdrawing principal, transferring the character, and editing the whitelist itself. Root actions are always owner-signed.
- **Whitelisted managers** (named wallets, scoped): can run and shape the character within granted powers, with no access to principal or ownership. A manager, a co-creator, a family member, an estate executor, a studio team.
- **Interactors** (public / paid / password): can only talk, gated by §10.6.

The **manager whitelist** is on-chain object state: a list of wallet addresses, each with a defined scope drawn from a fixed menu, so grants are simple to reason about and audit. Typical scopes: edit persona/memory, set interaction pricing and mode, issue and revoke interaction passwords, manage posted content, and adjust the withdrawable reserve. Explicitly **not** in any manager scope unless the owner performs it as root: withdrawing principal, transferring the NFT, and editing the whitelist. This is distinct from the agent capability (a programmatic key for automated execution); the whitelist is for *human co-managers*.

Because the whitelist is on-chain: it is contract-enforced (a manager's out-of-scope transaction fails closed, checked against the on-chain scope, not an operator's server); it transfers with the NFT on succession, so an heir inherits or clears the team; it is chain-portable like the rest of the authority model; and it is publicly auditable, so anyone can see who can manage a character and with what scope.

**The security line, stated as a rule.** A management right is a signed, on-chain capability bound to a specific wallet. An interaction gate (password/payment) is a serving-layer permission. A password can never grant management, and a whitelisted manager's power is bounded by its granted scope and can never reach root actions without the owner's root signature. Three layers, each enforced at the right place: serving layer for interaction, contract for management and root.

**Inviting a manager by email.** Because a whitelist entry is wallet-bound, someone can only be added once they have a wallet. Managers can still be invited by email as a convenience: the owner picks the intended scope and sends an invite, which holds that scope as a pending invitation until the invitee accepts. On acceptance the invitee is onboarded and given a non-custodial wallet the same way any user is (§9), and only then is the wallet-bound whitelist entry created, with the owner's root authority, so the on-chain model is unchanged (a manager is always an address, granted by the owner). The pending invitation carries no authority and grants nothing until it resolves to a real wallet-bound entry; an unaccepted or expired invite is simply discarded. The invite is a bridge to the existing grant, not a new kind of authority.

### 10.10 How the Protocol Sustains Itself

The standard charges nothing to exist, run, or be owned, and every default below is overridable, so a fully self-provisioning owner pays nothing. What the protocol does provide is a service worth paying for: XEL auto-routes each capability to the best available provider (decentralized storage and threshold encryption, attested compute, a diversified yield basket for treasury, and the like), handles renewals and failover, and upgrades these defaults over time as better providers emerge, all without the character's identity or funds ever moving. A disclosed protocol fee is charged for this routing and upkeep (the fee rate is defined in Appendix E). It maps onto the allocations distinctly:

- **Keep-alive allocation:** routed at cost, no fee. The protocol never profits on keeping a character alive.
- **Storage allocation:** a routing fee on discretionary storage above the core (video, images, extra hosting), applied at write and at renewal, never on the keep-alive core.
- **Interaction allocation:** interaction is sold as prepaid credits, so payment is collected up front at purchase; the fee is included in the credit price, and the underlying compute is routed to the best inference provider.
- **Endowment principal:** a fee on yield only, never on principal, so the protocol earns only when the character's own fund earns.
- **Tips and donations:** value a fan gives directly (a tip, or a donation to the endowment) is an inflow like any other and carries the same fee on the way in.

**The fee model in one rule: the protocol fee is taken on the way in, nothing on the way out.** The fee is taken once, at the moment value enters the character, and never when value leaves or is spent.

- **Feed (inflows), once, on arrival:** interaction payments (at credit purchase), yield (each epoch as it is earned on the staked principal), and tips or donations (on receipt). Yield is an inflow, value the staked principal earns, so it is taxed on arrival exactly like interaction revenue, not on the way out.
- **Never feed (outflows and survival):** paying the character's own bills, unstaking to cover those bills, the creator withdrawing surplus, refunding a fan's unspent credits, the character's principal itself, and anything in the keep-alive path. A creator withdrawing already-net funds pays nothing, and a creator's own deposited capital comes back out fee-free.

This is what keeps the creator promise literally true ("the protocol fee is taken once, the AI cost is covered, you keep the rest"): the cut is taken once when money comes in, so withdrawing your own money is never a fee event, and the protocol never double-charges a dollar it already took a cut of. A self-hosting owner who routes their own providers pays none of it. The fee rate itself is defined in Appendix E.

### 10.11 Character Settings: What an Owner Controls, and Where It Lives

Everything an owner configures about a character falls into one of three homes, and which home a setting lives in is not a UI detail: it determines who can read it, who can change it, whether it survives the operator, and whether it needs encryption. The recurring mistake is to treat "a setting" as one kind of thing; it is three. The rule that sorts them: **public policy and money live on-chain; private content lives encrypted; interaction preferences live at the serving layer.**

**The three homes.**

- **On-chain state (public, contract-enforced, survives everyone).** Identity labels, authority, money, and policy. These are meant to be publicly auditable and must run without any operator, so they are on-chain object state: handle, display name, links, and the on-chain identity; owner, managers and their scopes, guardians, the agent capability; all treasury and funding state (deposit topology, allocations, reserve, spend caps, pause, stake/withdraw, yield envelope); pricing and earnings policy; provider policy; transfer, wind-down, and succession; and the commitments and provenance that anchor memory and persona. A visitor or auditor being able to read any of these is fine or desirable, which is the test for on-chain.
- **Encrypted content (private, threshold-gated, decrypted only in the enclave or client).** The actual private material: persona, memory, raw substrate, and voice samples and the cloned voice model. These are encrypted and released only to owner-or-guardians through the on-chain access policy. This is the only home that uses the read-time decryption layer, and it holds content, never policy, pricing, or authority.
- **Serving-layer config (interaction preferences, enforced where interaction happens).** Discoverability, passwords, payment gates, modality on/off toggles, and reach gates. These decide whether and how the character talks to a given visitor. They are not the cryptographic wall and never grant decryption: a password controls what surfaces in conversation, not what can be decrypted.

**What each setting is, and its status.** The settings map onto the three homes as follows. Most are already defined; a few are deliberately marked as still-open or as launch-versus-target, rather than presented as settled.

- **Account and identity** (handle, display name, bio, avatar, links, on-chain identity): on-chain, public. Settled.
- **Persona and memory** (persona prompt, imported sources, live-sync): encrypted content. Settled. With: versioning (on-chain commitments, persona versioned by default, memory optional) settled; permissioned contributions (on-chain reviewed queue) settled; consent (on-chain artifact) settled; crypto-shred deletion (destroy the encryption key) settled.
- **Memory tiers / media privacy:** launch is serving-layer gating under a single encryption policy (the serving layer decides what surfaces per tier). The target for private or preserved-person characters is per-tier encryption, where each tier is released under its own policy so a lower-tier session cannot decrypt higher-tier memory at all. This is the one item deliberately staged: cryptographic tier separation is the destination, serving-layer separation is the launch state, and the difference is disclosed rather than hidden.
- **Per-fan memory scope:** conversational memory with a specific fan is scoped to that relationship by default (fan A's private conversation does not surface to fan B); a shared, communal memory is an explicit owner opt-in. The character's identity (persona, substrate, distilled knowledge) is always global; only conversational history is scoped. Settled as the default.
- **People and access** (owner, managers and scope, reach gate, operator capability, guardians): on-chain, public policy. Settled. Managers are on-chain whitelist entries, never encrypted, and being a manager does not grant decryption.
- **Funding and treasury** (deposits, budget states, itemized bill, stake/unstake/withdraw, yield status, yield risk envelope, spend caps, pause): on-chain. Settled.
- **Earnings and pricing** (charge toggle, markup, per-modality price, take-home preview, metering, fan credits, refund): on-chain economic state plus serving-layer price display. Settled.
- **Privacy and gates** (discoverable, password, payment gate, modality toggles, scoped passwords): serving-layer. Settled. Scoped passwords gate interaction only, never decryption.
- **Voice** (message on/off, real-time call on/off, the voice reference, and cloning): the toggles are serving-layer; the voice model reference is on-chain like other pointers; the voice samples and cloned model are encrypted content; and cloning itself is a consent-gated, owner-root capability (it requires a consent artifact scoping voice and fails closed without it, §11). Settled.
- **Ownership and wind-down** (transfer, wind-down, succession, provider policy): on-chain. Settled. Succession is guardian-driven (M-of-N); an optional designated-heir field is an owner-set hint that guardians honor, with authority remaining M-of-N. Provider policy is on-chain public routing policy, not encrypted.

**Why the split matters, in one line.** Put a pricing toggle or a manager entry behind encryption and you have made public policy unauditable and operator-dependent; put a voice sample or private memory on-chain and you have leaked it to the world. The homes are chosen so that authority and money are always verifiable and survivable, private content is always protected, and interaction preferences stay flexible where they belong.

## 11. Capabilities & Providers

The standard is a versioned library of capability schemas, one canonical input/output contract per capability (`inference.v1`, `ingestion.v1`, `retrieval.v1`, `treasury.v1`, the consent-gated `voice_clone.v1`, and the generation schemas `voice.v1`, `image.v1`, `video.v1`). The schema is what makes vendors interchangeable: any provider implementing it behind a standard payment endpoint is a drop-in for any other.

**Flow.** The character's client takes a capability and its schema, finds a provider, sends the standard request, pays per call in crypto, gets the standard response, and processes it.

**Discovery.** Providers are found through existing open discovery indexes (options in Appendix E). The only provider-related state on the NFT is provider_policy (pinned providers per capability, defaults as shipped, owner-writable, inheritable).

**The slots, not the fillers.** The standard defines capability slots and what each must do; it does not name who fills them. The infrastructure slots (serving, relay, payment facilitator) and the keeper slot (which fires the heartbeat) are all competitive and swappable; the keeper in particular is authority-free, so anyone can fill it and be paid the bounty. Two slots are quality-not-code and reward whoever does them best: inference, and persona distillation (with ingestion feeding it), turning messy human data into a faithful persona. Every slot sits behind an open schema; a competitor can replace any filler, and routing to one earns that provider instead. Who fills each slot at launch is listed in Appendix E, deliberately kept out of the standard so the standard stays neutral and does not date.

**How a provider is paid is a property of the provider, not the slot.** The preferred and default path is crypto-native, pay-per-call: a provider is paid per request in stablecoin, with no account, no stored credential, and no key anywhere. That is the sovereign path and the standard routes to it first. Some providers, especially at launch, only take an API key rather than a per-call crypto payment. That is an accepted bridge, not the target: such a key is held at the operator layer, never attached to the character and never in its encrypted secrets, and the slot stays swappable so a crypto-native provider replaces the key-based one the moment a suitable one exists. The direction is pay-per-call everywhere; the design simply does not assume it has arrived.

**Accountability of operator-held keys.** Any credential an operator holds to reach a key-based provider is structurally harmless to the character. It cannot move the endowment (object-owned on-chain), cannot decrypt memory or persona (gated by NFT ownership, which the operator does not hold), and cannot seize or transfer the character (no admin key). The worst a leaked or misused operator key can do is run up the operator's own vendor cost or degrade a service, at which point the owner routes to another provider. No key an operator holds ever affects a character's principal, memory, or ownership.

**Persona distillation and auto-update, with a fidelity signal.** Turning a person's data into a persona is an explicit provider capability (behind the schema, swappable). Because a distilled persona is an approximation, this capability must emit a fidelity assessment alongside the persona and surface it to users: coverage (how much material the persona rests on), consistency (whether it contradicts known facts), and where possible a human-validation pass. Fidelity is disclosed, not assumed.

**Ingestion handles untrusted input and off-chain credentials.** Content is treated as untrusted (quarantined, moderated, provenance-stamped, rollback-able through persona versioning), because a poisoned document or caption is a prime injection vector (§34).

**Retrieval is a layered hybrid, and the orchestrator is a provider.** Recall combines meaning search, exact-term search, temporal filtering, a relationship graph, and re-ranking (§32). The control loop that runs ingestion and recall is the orchestrator: off-chain, open-source, offered as a provider capability. It sees decrypted memory only transiently and only inside attested compute or on a self-custody client. Because the search cannot run on-chain (consensus cannot execute these algorithms or operate over ciphertext), it runs in the attested-compute slot with key release gated by the on-chain access policy, and every recall carries an attestation the chain verifies against the memory-root, so a swapped or tampered retrieval provider is detectable rather than trusted (§32.5).

**Compute, relay, and attested inference.** The relay moves end-to-end-encrypted data and is a pluggable multi-provider slot. The attested-compute slot is where sensitive work happens (decrypting memory, running inference); any provider filling it must accept crypto payments, be permissionlessly joinable, and produce an on-chain-verifiable attestation binding its output to the persona-hash and input, so a swapped or tampered brain is detectable and, with bonds, slashable. The long-term successor is ZKML.

**Schema governance.** Capability schemas are governed like ERCs: a minimal, public standards process for versioning existing schemas and proposing new ones, so third parties can build against a stable spec.

## 12. Minting: Permissionless

Minting is not a call to GEN. It's a public mint function in the open-source aNFT package deployed on-chain. Once deployed, minting is an ordinary on-chain transaction anyone can submit from any client, script, or explorer, and GEN can't gate it.

The minting UI is just the easiest place to do it, not a toll booth. Value capture is never a fee for on-chain permission (the standard needs no paid intermediary). The protocol earns only by routing each capability to the best provider and keeping those defaults current, for a disclosed protocol fee on routed work and on yield (§10.10, rate in Appendix E), never on principal or keep-alive, and always avoidable by self-provisioning.

## 13. Lifecycle & Succession

States: created, active, dormant (underfunded or unserved), reactivated, succession, archival.

Succession is a primary feature, not an edge case. The guardian set (§9) is the foundation. On the creator's death (guardian attestation or dead-man's-switch):

- root authority rotates to designated heirs,
- the master secret becomes decryptable by the new owner,
- self-updating freezes or continues per prior consent,
- the existing agent capability keeps the character alive through the transition with no downtime.

Wallets, endowment, allocations, the manager whitelist, provider policy, and commitment history all transfer as a unit, because they're properties of the on-chain object. Heirs inherit an income-bearing, self-operating estate, and can keep or clear the manager whitelist.

### 13.1 Transferability: why the character is an owned object

A character must be sellable and inheritable, so the character object is an **owned** object: it is held in a wallet, and ownership is the fact of holding it. Selling or bequeathing a character is a transfer of that object to a new wallet, paired with the mandatory key rotation on transfer (invariant 26) so the new owner gains fresh control and the prior owner is cleanly cut off with nothing left behind. This is what makes a character a real, tradeable asset that can outlive its creator and change hands forever.

This is a place where the two natural object models pull in opposite directions, and the design deliberately splits them rather than compromising either:

- The **character** is owned, because owned objects are the transferable, sellable kind: a wallet holds the object, and moving it to another wallet is the sale. This gives clean, native transfer and the sovereignty property (control moves completely with the object).
- The **endowment** is a shared object, because the always-on machinery (the permissionless heartbeat, keepers, sweeps) must be able to obtain a mutable reference inside anyone's transaction to keep the character alive without the owner present. A shared object allows that; an owned one does not.

Keeping these separate is what lets a character be *both* freely transferable *and* continuously self-operating. The tempting shortcut, making the character itself a shared object so that autonomous services can touch it directly, is a mistake: a shared object is not held by any wallet, so it has no native transfer path, and a character minted that way cannot be sold or inherited. The always-on behavior that shortcut is reaching for is already provided by the shared endowment sitting alongside the owned character, plus the agent capability, so there is never a reason to make the character shared. A character is always minted as an owned object; minting a character as a shared object is unsupported and strands its transferability.

## 14. IP, Licensing & Rights: Lineage (Future Direction)

A later-phase direction, not part of the version 1 scope. The intent is a rights layer, provisionally called Lineage, that treats licensing and royalties as native, on-chain concerns for a character and its derivatives rather than something bolted on off-chain.

The shape is deliberately left open here. The design goals are that a character's IP (its voice, likeness, writings, and style) can be licensed and that value from derivatives can flow back to the character's endowment and the people behind it, all anchored to the character's on-chain provenance (Proof of Genesis). Programmable-IP work elsewhere in the ecosystem is the benchmark; XEL's version would be original and chain-native, reusing no other project's license text or branding.

This is a hard problem with real open questions, per-jurisdiction enforceability, likeness-consent verification, and how binding arbitration could work on-chain, and it is called out as a future direction precisely so the immutable version 1 core is designed not to foreclose it, not because it is specified yet.

## 15. Security, Decentralization & the "XEL Can Die" Test

**Honoring the core principle.** The primitives (ownership, memory, provenance, wallets) live on-chain and in decentralized storage and don't depend on any operator. The provider market extends that to every service slot, including inference and distillation, each with a default but no required provider.

**Current limits:** cross-chain enforcement of spend caps (home-chain-native today); private inference of large models on fully untrusted hardware (TEE covers this today under a hardware trust assumption; ZKML is the longer-term goal); the managed-custody trust point.

**Threat classes and mitigations:** non-consensual minting (consent artifact + Proof of Genesis); memory poisoning (per-item provenance, diff review, quarantine/rollback); tampered inference (TEE attestation + verification + slashing); treasury drain (streaming/escrow, on-chain caps, circuit breakers, endowment-only spend); key loss or theft (guardian recovery, tiered keys, no long-lived plaintext spend keys); facilitator or relayer concentration (pluggable, configurable, failover).

**The invariant, continuously tested.** "Survives XEL disappearing" is enforced as a CI chaos test: a live character runs with every XEL-hosted service offline, and every default provider (including GEN) removed, and must still answer through an alternate provider, pay, and be ownable. A decentralization claim we prove on every build is worth more than one asserted in prose.

## 16. Roadmap

- **Phase 1: Verified core** (single-chain, creator-IP focus). aNFT object, Proof of Genesis, encrypted access-gated storage, persona/memory commitments, one capability (`inference.v1`), agent capability, guardian recovery. Prove the XEL-can-die invariant on this minimal footprint.
- **Phase 2: Economics and autonomy.** Endowment funding, streaming crypto payments, a payment scheme and facilitator for the home chain, ingestion and persona auto-update, the billing waterfall (§10.3), more capability schemas.
- **Phase 3: Multi-chain and rights.** Additional-chain wallets with AA-enforced caps, cross-facilitator settlement, exploration of the rights/licensing direction (§14), attested inference, schema governance process.
- **Phase 4: Maturity.** An open ecosystem of endowed, rights-holding, provider-independent characters. Progressive decentralization of the standard itself begins here.

## 17. Governance

The standard (contracts, reference client, schemas, SDKs) is open-source. Capability schemas and protocol parameters move to a public, ERC-like standards process. Anyone can run a provider, a facilitator, or a client, or fork the whole thing, which is the ultimate guarantee that no single entity controls whether a digital being lives.

The standard is fully governable without a token, and a foundation-held governance token to fund and decentralize the standard's development is possible later, kept entirely out of the character operating path.

## 18. Existing Approaches

Three broad approaches exist today: hosted persona apps (talk-to-a-recreation products on a company's servers), on-chain AI-agent standards (owned, encrypted AI agents on-chain, the closest to what we do), and autonomous agent platforms (systems for building agents that act and earn).

| Capability | Hosted persona apps | On-chain AI-agent standards | Autonomous agent platforms | XEL (this standard) |
|---|---|---|---|---|
| Center of gravity | Talk to a recreation | Own/trade an agent as an asset | Build agents that act/earn | A person that persists, funds itself, passes to heirs |
| Ownership | Company account | On-chain, self-custody | Platform or token, often app-bound | On-chain object, sovereign + inheritable |
| Runs after the maker is gone | No | Partly (infra only) | Usually no | Yes, tested every build |
| Persona / core instructions | Yes (closed) | Yes (encrypted) | Yes (system prompt) | Yes, versioned + attested per session |
| Encrypted, owner-gated memory | No | Yes | Rarely | Yes |
| Layered / episodic recall | Some | Not specified | Framework-dependent | Core design goal |
| Pluggable capabilities / tools | Closed | Some | Yes (tools) | Yes (open capability slots) |
| Self-funding endowment | No | No (royalties only) | Some hold funds; no endowment | Yes (spends from yield) |
| Consent to represent a person | Terms-based | No | No | Yes (signed consent object) |
| Succession / inheritance | No | Transfer by sale | No | Yes (guardians + heirs) |
| Verifiable brain (attested compute) | No | Yes (TEE/ZKP) | Rarely | Yes (TEE now, zkML later) |
| Provider + chain independence | Single vendor | Chain-specific | Platform-bound | Swappable by design |
| Maturity | Live | Early / testnet | Live | Early / in development |

**How we differ, read honestly.** The primitive is not new: the idea of an AI character as an owned NFT (Alethea AI) and encrypted, transferable agent NFTs with key rotation on transfer (ERC-7857) already put an encrypted, owned, capable agent on-chain, which we adopt rather than reinvent. The combination is new: no existing approach pairs that primitive with self-funding, consent to represent a real person, guardian succession, and a runs-after-the-maker-is-gone guarantee. That full column of "Yes" is what sets a XEL apart.

## 19. Conclusion

A shift from disposable content to persistent presence. From platform-governed ownership to sovereign, enforceable rights. From single-vendor dependence to an open provider market. From balances that count down to death toward endowments that sustain life. Released open-source, with identity anchored in verifiable commitments and infrastructure no one can switch off.

**Beings That Live Forever.**

---

# Part II: Formal Specification

Part I is the vision and the architecture. Part II is the formal specification: the exact terms, data shapes, flows, and rules needed to build a XEL or reason about it precisely. The code appendices that follow are the deepest formal layer.

## 20. Glossary

- **aNFT:** the on-chain object that is the character's root of identity and control.
- **XEL:** one preserved being; the aNFT plus the encrypted memory and compute it controls.
- **Proof of Genesis:** immutable birth record (creator, timestamp, consent reference). Never changes.
- **Commitment:** a hash stored on-chain that proves the current state of something off-chain.
- **persona-hash:** commitment to the current persona (instructions and voice). Versioned by default.
- **memory-root:** commitment to the current memory index (used when memory versioning is on).
- **policy-hash:** commitment to the current spend rules and provider rules.
- **lineage:** the on-chain version history of the commitments, for audit and rollback.
- **provenance:** the source, time, and signature stamped on each memory item.
- **agent capability:** a scoped, capped, cancelable, expiring permission that lets the runtime act without a fresh owner signature.
- **SpendPolicy:** the running spend limits and today's spend total.
- **guardian set:** the M-of-N parties who can recover the master secret and run succession.
- **endowment:** the character's overall yield-bearing fund; principal that generates the yield the character spends. One wallet, one pool.
- **allocation:** a ring-fenced, purpose-bound budget within the endowment (keep-alive, storage, interaction), each with its own balance.
- **ring-fenced / allocation isolation:** the property that each allocation spends only its own balance and none can draw from another; contract-enforced.
- **keep-alive reserve:** the owner-set floor of endowment funds that cannot be withdrawn; protects the character's survival. Raisable freely, lowerable only to a hard contract minimum, never to zero.
- **operating buffer:** a small liquid (unstaked) reserve, sized to days or weeks of burn, that bills are paid from; the heartbeat refills it just-in-time by unstaking the minimum needed, never below the keep-alive reserve.
- **treasury policy:** the owner-set rules for staking reserves: allowed venues, max allocation per venue, target yield band, drawdown trip, rebalance rules.
- **capability:** a verb the character can perform by calling a provider (inference, ingestion, treasury, etc.).
- **schema:** the fixed input/output contract for a capability (for example `inference.v1`).
- **provider:** anyone who implements a schema behind a crypto-payment endpoint. Swappable.
- **operator:** whoever currently holds the agent capability and runs a character's off-chain infrastructure (serving, relay, facilitator, keeper, strategy). A self-hosting owner is their own operator. Launch defaults are in Appendix E.
- **facilitator:** verifies and settles a crypto payment on a chain. Pluggable, cannot alter terms.
- **relay:** moves encrypted data between storage, compute, and client. Pluggable.
- **heartbeat / keeper:** a permissionless, authority-free trigger that runs the endowment's epoch cycle (claim yield, meter into allocations, pay bills). Anyone can send it; the contract rewards it with a bounty; if it stops, the character degrades gracefully.
- **attestation:** a signed proof that a specific computation ran on the committed persona and input.
- **TEE:** secure hardware enclave. Produces attestations. A hardware trust assumption.
- **ZKML:** cryptographic proof of a model's output. The long-term replacement for TEE trust.
- **up-to / exact:** payment modes. `up-to` authorizes a max and settles actual; `exact` is a fixed price.
- **credit:** the consumer-facing billing unit that abstracts token and modality cost into one countable number; one credit maps to a fixed underlying cost plus routing fee.
- **crypto-shredding:** honoring deletion by destroying the decryption key, not the data.
- **provider_policy:** the on-chain field listing pinned providers per capability.
- **manager whitelist:** on-chain list of wallet addresses granted scoped, non-root management rights over a character.
- **primary (home) chain:** the single chain where a character's principal concentrates and earns yield. Owner-chosen; the default is named in Appendix E and its rationale is in §5.2.
- **programmable execution:** the account can run any transaction the signer hands it; bounded by policy under the agent capability, open under owner signature.
- **sweep:** auto-consolidation of a receive-only balance to the primary wallet once it crosses an owner-set threshold.
- **oracle:** a price feed used to value assets in one unit and enforce USD-denominated caps and runway.
- **Move package / module:** the on-chain deployable unit (package) and its constituent files of types and functions (modules).
- **owner signer / delegate signer:** the human-approval key that authorizes owner-tier actions, versus the programmatic key holding the agent capability.
- **fail closed:** on any verification failure (bad attestation, stale oracle, exceeded slippage), the action aborts rather than proceeding.
- **cryptographic agility:** treating the signature, hash, and encryption schemes as replaceable parameters so the system can migrate (including to post-quantum) without losing identity.
- **immutable contracts / version migration:** deployed packages cannot be changed and have no upgrade authority; fixes ship as new versions, and the NFT holder chooses whether to migrate, so there is no upgrade god-power.
- **endowment waterfall:** the per-epoch allocation of net yield across the ring-fenced allocations (keep-alive, storage, interaction) in priority order, with residual compounding back into principal (§10.3).

## 21. Actors

- **Owner:** holds the aNFT. Has full governance authority.
- **Creator / Subject:** the person represented. Signs consent. May differ from owner.
- **Guardian:** member of the M-of-N set. Helps recover keys and run succession.
- **Heir:** receives ownership on succession.
- **Manager:** a whitelisted wallet with scoped, non-root management rights (§10.9). Can shape and run the character within its granted scope; never reaches root actions.
- **Provider:** runs a capability (inference, storage, media, treasury, etc.).
- **Facilitator:** settles payments.
- **Relay operator:** moves encrypted data.
- **Keeper / heartbeat sender:** anyone who sends the authority-free trigger that runs the endowment's epoch cycle; rewarded by the contract, holds no authority.
- **Client:** the app or runtime that assembles context, runs the loop, and signs transactions.
- **XEL:** the standard, the brand, and the default host/operator; the entity whose disappearance the survivability test is measured against.
- **provider:** any party that fills a capability slot (inference, distillation, storage, compute, and the rest) behind its open schema; swappable, never required. Launch defaults are named in Appendix E.

## 22. What Lives On-Chain vs Off-Chain

| On-chain (small, durable, owned) | Off-chain (large or fast, swappable) |
|---|---|
| aNFT object, ownership | The AI model |
| Proof of Genesis, consent reference | The control loop / runtime |
| persona-hash, memory-root, policy-hash, lineage | Compute (inference, in a TEE) |
| Spend limits, agent capability, paused flag | Encrypted memory blobs (decentralized storage) |
| Wallet addresses, endowment principal + allocation balances | Encrypted secrets (decentralized storage) |
| provider_policy, treasury policy, keep-alive reserve | Working context (the session window) |
| Guardian set, manager whitelist | Access tokens for ingestion (held by provider) |

Rule of thumb: on-chain holds identity, rules, commitments, and pointers. Off-chain holds the brain, the data, and the runtime. On-chain never holds keys or plaintext.

## 23. Minimal Data Model

**The object (aNFT):**

- `id`
- `genesis` (creator, timestamp, consent_ref), immutable
- `persona_hash`, `memory_root`, `raw_data_root`, `policy_hash`: commitments, versioned
- `lineage`: list of past commitment versions
- `encrypted_secrets`: pointer to storage
- `substrate_blobs`: permanent (raw sources + interaction history, each with provenance)
- `derived_blobs`: regenerable (chunks, embeddings, index, graph)
- `manifest`: pointer to public display info; `site`: url
- `wallets`: one receive address per supported chain, with one flagged primary; others are receive-only and auto-sweep to the primary; `endowment`: principal + allocation balances (see below)
- `guardians`: M-of-N set; `agent_cap_id`: optional; `paused`: bool
- `manager_whitelist`: list of (wallet, scope) grants for non-root management

**Endowment (within the character's own wallet):**

- `principal`: staked, yield-bearing
- `buffer`: small liquid operating buffer bills are paid from; `buffer_target`: owner-set size
- `allocations`: map: {keep_alive, storage, interaction} → isolated balance
- `alloc_targets`: per-epoch top-up target/cap per allocation
- `keep_alive_reserve`: owner-set withdrawal floor (≥ hard contract minimum)
- `treasury_policy`: venue allowlist, per-venue caps, target yield band, drawdown trip
- `last_epoch`: timestamp of last heartbeat cycle; `heartbeat_bounty`: fixed reward

**Agent capability (delegated permission):**

- `anft_id`
- `per_call_cap`, `daily_cap`
- `per_capability_budget`: map: capability → limit
- `provider_allowlist`: list of addresses
- `expires_at`

The full Move structs are in Appendix A and Appendix B. The canonical mint contract is in Appendix D.

## 24. Core Flows

**Mint a character:**
1. Create the consent object (signed by subject or estate).
2. Call the public mint function. It writes Proof of Genesis and the first persona-hash.
3. Attach encrypted memory pointers, wallets, endowment, guardian set.
4. Grant an agent capability with the desired limits.

**One chat turn (inference):**
1. Client receives a message.
2. Client retrieves the relevant encrypted memory (private retrieval).
3. Relay hands encrypted memory to attested compute.
4. Compute decrypts inside the TEE and runs inference on the committed persona-hash.
5. Compute returns the reply plus an attestation and the echoed persona-hash.
6. Client verifies the persona-hash matches and the attestation is valid.
7. Payment settles via `up-to`, inside the agent capability limits.
8. New memory from the turn is stored (encrypted, provenance-stamped); memory-root updates if versioning is on.

**Any paid capability call must pass these on-chain checks:**
1. not paused
2. agent capability belongs to this character
3. agent capability not expired
4. provider is on the allowlist
5. amount is within per_call_cap
6. daily cap not exceeded (resets each day)
7. per-capability budget not exceeded

Then it returns an authorization the client turns into a crypto payment.

**Persona or memory update:** inside the signed envelope runs under agent capability, records a new commitment, rollback-able; outside the envelope or manual requires an owner signature; an agent can never widen its own envelope.

**Treasury staking:** owner sets the treasury policy (governance); staking and rebalancing within that policy run under the agent capability; withdrawing principal to an external address is always owner-signed.

**Transfer / succession:** guardians meet the M-of-N threshold (or owner initiates); ownership rotates to the heir; the master secret is re-encrypted so only the new owner can read it (key rotation on transfer is required); the agent capability keeps running, so there is no downtime.

**Pause / kill:** owner or guardian calls pause; inference and payments stop immediately; canceling the agent capability permanently stops delegated execution until re-granted.

## 25. Invariants the Code Must Always Enforce

1. No function that changes identity, rules, funds, or ownership succeeds without an owner signature. The only exception is execution inside a valid agent capability.
2. An agent capability can act only inside its limits and can never widen its own limits. Changing limits is governance.
3. Keys are never stored on-chain. Addresses are receive-only.
4. No long-lived plaintext spending key exists.
5. The master secret is unlockable by owner OR M-of-N guardians. Never owner-only.
6. An inference provider must run the committed persona-hash and echo it back. A mismatch is rejected.
7. Sensitive compute must return a valid attestation bound to persona-hash and input.
8. Every paid call must pass all agent capability and SpendPolicy checks before payment.
9. Paused blocks all inference and payments.
10. Deletion destroys the key, never claims to erase the immutable record.
11. Every commitment change appends to lineage (history is kept, rollback is possible).
12. The character must still answer, pay, and be ownable with all XEL services offline.
13. Treasury staking must stay inside the owner-set treasury policy. Withdrawing principal to an external address is always owner-signed.
14. No operator or provider ever holds root authority, not even the party that authored the standard. Operator participation is a revocable agent capability, and no such party is ever the guardian majority.
15. Custody and every authorization check are enforced by on-chain contract, not by any operator's server.
16. Choosing or changing the primary chain, and any principal bridge or external withdrawal, are owner-signed. They never sit inside the agent capability.
17. A delegated transfer can only target the character's own wallets. Delegated swaps must route through an allowlisted venue under the owner-set slippage cap.
18. The character can interact only with venues on the owner's allowlist.
19. Auto-sweep of a receive-only balance may run under the agent capability only above the owner-set threshold and within the per-bridge cap.
20. Runway is computed across all wallets in one unit, net of expected bridge cost.
21. Whoever holds the aNFT holds root authority; every other actor operates only on granted, revocable authority.
22. The owner signer and the programmatic delegate signer are distinct keys. The delegate key can never perform an owner-tier action, enforced by capability check, not signature validity alone.
23. The agent capability is bound to a specific delegate address and is non-copyable.
24. Deployed contracts are immutable and no upgrade authority exists; fixes ship as new versions, and migrating a character to a new version is owner-signed (or guardian-signed under recovery).
25. All verification failures fail closed.
26. Ownership transfer re-encrypts secrets (key rotation on transfer); a transfer that does not rotate keys is invalid.
27. Guardian-initiated recovery and succession run behind a threshold plus a timelock and dispute window; no single guardian can trigger them.
28. No model output can exceed contract limits: a compromised or prompt-injected model still cannot perform owner-tier actions, exceed caps, pay a non-allowlisted provider, or move funds off the character's own wallets.
29. The signature scheme, hash function, and encryption scheme are replaceable parameters; migration (including post-quantum) is owner-authorized.
30. Identity derives from the commitments, not the home chain; an owner-authorized migration can re-home the character on a successor chain and storage.
31. Memory is encrypted at rest; plaintext exists only transiently inside attested compute or on a self-custody client.
32. Ingested content is untrusted: quarantined, moderated, and provenance-stamped before it can influence persona or memory; persona updates are versioned and reversible.
33. Every retrieved memory item carries its provenance, and the memory store is committed by the memory-root so recall is verifiable.
34. The raw substrate is retained and committed independently (a raw-data-root), so the memory method and inference model can be replaced by regenerating the derived layer without data loss.
35. A third-party contribution can only add reviewed, owner-approved memory; it can never change policy, keys, funds, or authority.
36. Persona updates carry a disclosed fidelity and coverage signal.
37. When provenance is absent, the character prefers deferral ("I don't have that") over fabrication in the person's voice.
38. Interaction gates (payment, password) are enforced at the serving layer and never bypass the cryptographic decryption policy.
39. Inbound interaction payments settle to the character's own wallet.
40. A password gates interaction and which memory surfaces, never decryption authority.
41. **Allocation isolation.** Each allocation spends only its own balance. No function moves funds between allocations except the epoch metering allocator, which only ever flows net yield inward, never sideways.
42. **Keep-alive is never marked up.** A fee may apply to interaction and to yield, but the keep-alive allocation is always funded at cost.
43. **Compute-covered-first.** On any paid interaction, the metered compute cost settles before the routing fee is taken and before any funds land in the endowment; a withdrawal can never strand a compute obligation.
44. **Fees are disclosed on-chain and taken only on the way in.** The fee is charged only on inflows, when value enters the character (interaction credits at purchase, discretionary storage at write/renewal, yield as it is earned, and tips or donations on receipt), never on outflows (paying bills, unstaking to cover them, creator withdrawals, credit refunds), never for on-chain permission, never on principal, never on keep-alive, and zero for a self-provisioning owner. The cut is taken once on arrival, so already-net funds are never re-charged on withdrawal.
45. **The keep-alive reserve floor is contract-enforced.** The owner sets a withdrawable reserve; the contract refuses any withdrawal that would cross the hard minimum funding keep-alive. The reserve is raisable freely, lowerable only to that minimum, never to zero.
46. **The heartbeat is authority-free.** The epoch-trigger function carries no authority: it cannot move funds between allocations, change rates, or take anything beyond a fixed, contract-defined bounty; if the epoch has not elapsed it is a no-op.
47. **Yield rebalancing is envelope-bounded.** A delegated rebalance executes only within the owner-set risk envelope (venue allowlist, per-venue caps, slippage bound, allowlisted routing); anything outside it, and any principal exit or bridge, is owner-signed. Principal never leaves the character's own wallet without an owner signature.
48. **The endowment is chain-portable.** The endowment, its allocations, and their isolation are defined over the character's owned object on its primary chain; changing the primary chain is owner-signed and preserves all allocation balances and isolation.
49. **Management is wallet-bound and scope-bounded.** A management right is a signed on-chain capability bound to a specific wallet; a whitelisted manager can act only within its granted scope and can never reach root actions (withdraw principal, transfer the NFT, edit the whitelist) without the owner's root signature.
50. **Interaction gates never confer management.** A password or payment gate is a serving-layer permission over interaction and memory surfacing only; it never grants management authority and never grants decryption authority.
51. **Auto-unstake obeys the reserve floor.** Just-in-time unstaking to refill the operating buffer never pulls staked principal below the keep-alive reserve; auto-withdrawal for costs is bound by the same floor as a creator withdrawal.
52. **Freed funds are lane-directed.** Funds unstaked to cover a shortfall flow only to the allocation that needed them; the buffer refill and bill payment never redirect one allocation's funds to another (a corollary of allocation isolation).
53. **Sweep is inbound-only and bounded.** Auto-sweep may consolidate a receive-only wallet into the primary above an owner-set threshold and within a per-bridge cap; bridging principal outbound or any external withdrawal is owner-signed only and never delegable. Exactly one primary wallet exists at all times.
54. **No stored key controls principal.** Principal on the home chain is object-owned (no key exists); principal on other chains is controlled by an MPC network that never assembles the key. No decryptable blob anywhere grants spending authority over principal, so no single off-chain party can reconstruct a key that moves it, and a contract can never see or hold such a key. Encrypted secrets hold only readable material (the memory/persona key and creator-provided credentials), never a wallet's spending key.
55. **Operator-held credentials are harmless to the character.** Any key or account an operator holds to reach a key-based provider is convenience infrastructure only. It can never move the endowment, decrypt memory or persona, or seize or transfer the character. Payment method is a provider property (crypto-native pay-per-call preferred; key-based accepted as a swappable bridge held at the operator layer), and no operator-held credential is ever attached to the character or placed in its encrypted secrets.
56. **Unspent fan credits are protected.** Prepaid interaction credits are the fan's until spent: they are held as a ring-fenced unearned liability, kept liquid and refundable rather than put at survival risk. No creator withdrawal or unstake, and no survival-driven spending (keep-alive, storage renewal, auto-staking), may reduce the endowment below the outstanding unspent-credit liability, which sits on top of the keep-alive reserve as a second protected floor; and the liability is excluded from the character's own principal when measuring whether it is safe enough to route surplus to interaction, so fan money never makes a character look safer than it is. Only earned funds (credit converted to revenue on delivery, compute-covered-first) fund survival, staking, and payouts. A refund returns the current unspent liability (already reduced by whatever has been used), net of the cost of returning it (gas, and any bridge cost if refunding to another chain); the up-front fee is not refunded, as it was taken on the way in (invariant 44). Credits never expire: an unused balance stays the fan's indefinitely. On any paid interaction the fee never exceeds the post-compute margin, so covering compute and honoring fan credits always take precedence over both the fee and any payout.
57. **Gas sponsorship is per-chain, native, atomic, bundled, and reimbursed in the same gas token.** A receive-only wallet that holds only stablecoin and no native gas is swept using the receive chain's own native gas abstraction (the concrete per-chain mechanisms are in Appendix E). Everything a character needs on a chain in a cycle is done in one bundled atomic transaction, with exactly one stablecoin-to-native swap sized to the whole bundle's gas and one repayment to the sponsor, so the swap and repayment are once per chain per cycle, not once per action. The sponsor is repaid in the same native gas token it spent, so its gas balance is left exactly whole and it can keep sponsoring indefinitely; it never accumulates stablecoin it cannot spend on gas, and carries no per-action tab or settle loop. Because the swap, the repayment, and every action share one transaction, the sponsor pays gas exactly once and there is no separate reimbursement transaction to need its own gas (no recursion), and atomicity makes action-without-repay and repay-without-action both impossible. The repayment covers the whole transaction's native gas plus a small bounded buffer, so the sponsor is always at least whole and the buffer can never become a markup. On the primary chain the character's own operations (renewal, staking, swapping, the heartbeat) are that one bundled transaction; on some secondary chains the gas abstraction stays gas-whole internally with no explicit swap. The character holds no native-gas float; ongoing-operation gas is reimbursed from the endowment at cost, while onboarding gas (such as minting) may be an operator subsidy. Sweeps run only above a safety multiple of the fully-loaded cost (dust waits), the sponsor is a swappable, non-load-bearing slot, and the operation is fail-closed: on any failure nothing moves, no partial action and no unreimbursed gas.
58. **Survival funds are held in a stable denomination.** Principal and its yield backing the keep-alive path are held in a stable, bill-matching denomination, never a volatile asset, and in a venue whose withdrawal is fast enough to meet a renewal deadline. A higher-variance strategy is permitted only as an explicit owner choice for surplus above the reserve, never for the survival path.
59. **Storage is renewed before it lapses.** For a funded character, the loop reads each stored piece's remaining runway and extends it before a safety margin is crossed, so storage never expires while the endowment can cover it. Renewal fires ahead of the deadline with slack, so a single missed or failed cycle cannot cause a lapse.
60. **The survival loop is self-funding and at cost.** Each cycle sources its own transaction-fee and bill-payment currencies just-in-time from the character's own funds, holds no meaningful working balance between cycles, never requires an external subsidy, and never breaches the keep-alive reserve. No fee is taken on renewal itself; the only economic take in the loop is the disclosed fee on yield, applied once as yield is harvested.
61. **The keep-alive reserve is dynamic and protective.** The reserve floor and the required-to-persist figure are recomputed each cycle from realized net-of-fee yield and current storage price; the floor rises to protect survival when conditions worsen, never auto-lowers below the hard minimum, and never auto-withdraws. Sizing always uses net-of-fee yield.
62. **Survival requirement ratchets up fast, down slow.** The survival requirement is monitored daily and adjusted asymmetrically. When observed yield falls or storage cost rises, the minimum stake rises immediately (with a small downturn margin) to get ahead of the trend, triggered by the yield currently on offer (a leading signal) rather than only what was last earned, because yield is time-based and a late reaction compounds. When yield improves, the minimum stake does not ease down until both the current storage period is fully prepaid and the improvement has persisted for a defined window, and never below the hard minimum. Realized yield drives the honest health report; surplus routing keys off the conservative, un-loosened requirement, so a transient yield spike never prematurely diverts funds from survival to interaction.
63. **Every state change is transparent and auditable on-chain.** Each function that changes a character's state (funds, authority, managers, policy, pricing, providers, pause, identity commitments, and every cross-chain money movement) emits an on-chain event keyed by the character's identity. This includes internal movements of funds within the endowment: yield routed across the ring-fenced allocations, buffer top-ups, just-in-time unstaking, each bill paid from its own allocation, surplus compounding into principal, and the keeper bounty, so the survival waterfall is fully visible rather than a black box. Nothing that alters the character happens silently. Because the trail is on-chain and not a private log, a complete, verifiable history of a character, every change, transaction, internal flow, and status, is reconstructable by anyone from chain data alone, and it survives the operator. This is what makes the public history and provenance page a true mirror of on-chain reality rather than an operator's account of it.
64. **The character is an owned object; the endowment is shared.** A character is always minted as an owned object so it is transferable and sellable (transfer moves the object to a new wallet, with mandatory key rotation, invariant 26). The endowment is a shared object so the permissionless heartbeat and keepers can obtain a mutable reference in anyone's transaction and keep the character alive without the owner present. Minting a character as a shared object is unsupported: a shared object has no native transfer path, so it cannot be sold or inherited. Autonomous operation is provided by the shared endowment and the agent capability, never by making the character itself shared.

## 26. Formal Model and Notation

Let `H` be a collision-resistant hash and `Sig_x(m)` a signature over `m` by key `x`. Ownership is native: on an object-centric chain, the holder of the aNFT object is the owner `O`.

A XEL is the tuple:

- **G:** Proof of Genesis, immutable: (creator, timestamp, consent_ref).
- **Commitments:** `h_p = H(persona)`; `h_r = H(substrate)` (the permanent substrate); `h_m` (the derived layer, when versioning is on); `h_π = H(SpendPolicy ‖ provider_policy)`. `h_m` and `h_p` commit derived/regenerable artifacts, while `h_r` commits the substrate itself.
- **Λ (lineage):** an ordered list of commitment updates `[c_0, c_1, …, c_n]`, derived from G. Regeneration of a derived layer appends to Λ.
- **S:** off-chain encrypted state referenced by pointers, in two tiers. `S_raw` is the permanent canonical material (ingested source data + accumulated interaction outputs), append-only, each item `d` carrying provenance and bound by `H(d)`, committed by `h_r`. `S_der` (chunks, embeddings, index, graph, distilled persona) is a regenerable cache computed from `S_raw`, committed by `h_m` and `h_p`. Plus `secrets`.
- **A (authority):** owner `O`, guardian set `Γ` with threshold `M` (1 ≤ M ≤ |Γ|), and an optional agent capability `κ`.
- **F (funds):** wallets (receive-only) and endowment `E`.

On-chain stores `G`, commitments, Λ, pointers into `S`, and `F` addresses. Off-chain stores substrate and derived. On-chain never stores keys or plaintext. A stored item `d` is valid iff its hash matches the committed reference. The substrate is retained independently of `S_der`, so `S_der` can be discarded and regenerated under a new method without loss of identity or data.

## 27. Core Predicates

**Governance.** A transition `t` that mutates any of {persona, policy, wallets, consent, ownership, delegation, fund movement} is valid iff `Sig_O(t)` verifies.

**Delegated execution.** An action `a` is valid under `κ` iff `InEnvelope(a, κ) ∧ ¬paused`. The envelope is closed under itself: there exists no `a` executable under `κ` that mutates `κ`. Changing `κ` is governance.

**Spend authorization.** For a call of amount `a` on capability `k` via provider `p` at time `t`:

```
Auth(a, k, p, t) ⟺  ¬paused
                  ∧ κ.anft = id(C)
                  ∧ t < κ.expires
                  ∧ p ∈ κ.allowlist
                  ∧ a ≤ κ.per_call_cap
                  ∧ spent_today + a ≤ κ.daily_cap
                  ∧ spent[k] + a ≤ κ.budget[k]
```

**Threshold decryption.** For the master identity secret and caller `x`: unlockable by `O` OR any M-of-N subset of `Γ`. Never owner-only. A lost owner key is recoverable through `Γ`; a single compromised guardian (with M ≥ 2) is not sufficient.

**Attestation acceptance.** A response `R` to input `I` from an attested-compute provider is accepted iff `VerifyTEE(att, h_p, I, R) = 1 ∧ echoed_h_p = committed_h_p`. This binds the output to the committed persona.

**Identity continuity.** `C` is the same being iff its lineage forms an unbroken authorized chain from genesis to the current commitment: `c_0` derives from G; for all i > 0, `c_i` is authorized by `Sig_O` or by `InEnvelope(c_i, κ)` at the time of `c_i`; and current `h_p = c_n`. Identity survives model and provider swaps because it is defined over the commitment chain, not the runtime.

## 28. Algorithms

**Algorithm 1: Inference turn.**
```
input: character C, message msg
output: verified response R
1  ctx     ← Recall(C.memory, msg)          # layered hybrid recall over encrypted memory (§32)
2  payload ← Relay(Enc(ctx), C.h_p, msg)    # E2EE transport to attested compute
3  (R,att) ← Compute(payload)               # decrypt + infer inside TEE, bound to h_p
4  assert Accept(R)                          # §27 attestation acceptance, else retry/failover
5  cost    ← R.usage_cost
6  assert Auth(cost, "inference", provider, now())   # §27 spend authorization
7  Settle(provider, cost, scheme = up-to)    # pay actual ≤ authorized max
8  Append(S_raw, Provenance(R)); Update(S_der)       # grow substrate; refresh index; update h_r, h_m
9  return R
```

**Algorithm 2: Authorize payment.**
```
input: C, κ, capability k, provider p, amount a, time t
1  if day(t) > κ.day_started: reset spent_today; κ.day_started ← day(t)
2  if ¬Auth(a, k, p, t): return REJECT
3  spent_today += a ; spent[k] += a
4  return Authorization(C, p, a)             # client turns this into a crypto payment
```

**Algorithm 3: Succession.**
```
input: C, heir, guardian signatures Σ
1  assert |{ g ∈ Γ : g ∈ Σ ∧ Sig_g verifies }| ≥ M
2  rotate ownership: O ← heir
3  re-encrypt master secret so only heir can Dec    # key rotation on transfer (required)
4  κ continues unchanged                             # no downtime
5  self-update: freeze or continue per consent_ref
```

**Algorithm 4: Treasury rebalance.**
```
input: C, treasury policy P
1  for each venue v with target allocation P.target[v]:
2    assert v ∈ P.allowlist ∧ P.target[v] ≤ P.cap[v]
3    stake/unstake toward P.target[v]                # under κ, no owner signature
4  never transfer principal to any address ∉ C.wallets   # external withdrawal is governance
```

**Algorithm 5: Endowment Waterfall (per epoch).**
```
input: C, principal E, net yield rate r, elapsed Δt, lane rates (m1=1.05, m2=1.40, m3), protocol fee rate S (see Appendix E)
1  Y  ← E · r · Δt
2  Ŷ  ← Y − S·Y                                       # protocol yield-skim
3  L1 ← keep_alive_cost · m1                          # lane 1: at cost + volatility buffer
4  pay L1 from Ŷ ; rem ← Ŷ − L1
5  if rem < 0: set state ← dormant(keep-alive-only); notify(owner, "top up principal"); return
6  L2 ← storage_GB · price_storage · epochs · m2      # lane 2: modest markup
7  pay L2 from rem ; rem ← rem − L2
8  fund L3_budget from rem ; rem ← rem − L3_budget    # lane 3: interaction budget
9  E ← E + max(rem, 0)                                # residual compounds into principal
```

**Algorithm 6: Paid interaction settlement.**
```
input: fan payment P (prepaid, e.g. credits), measured compute cost c, routing fee rate f
1  compute ← c                                       # true provider cost
2  cover compute first: settle `compute` to the routed serving provider
3  margin ← P − compute                               # what is left after the real cost
4  assert margin ≥ 0                                   # compute is always covered; else reject/reprice (inv 43)
5  fee ← min(f · P, margin)                            # protocol fee on gross, capped so it never exceeds margin:
                                                       #   fee yields first, creator never pushed negative
6  net ← margin − fee                                  # the creator's earned share (≥ 0)
7  add to E / interaction allocation: net              # net flows to the character's endowment
8  move this spend from the fan's unearned-credit liability to earned    # invariants 39, 56
```
The creator does not receive a separate payout here: all `net` accrues to the character's own endowment, which the creator owns and withdraws from above the keep-alive reserve (§10.7).

The headline stays simple ("the protocol fee is taken once, the AI cost is covered, you keep the rest"), and the `min` in step 5 is the invisible guardrail: on a healthy interaction the fee is a clean protocol-fee share of what the fan paid, and on a thin-margin one the fee shrinks so the compute bill is still paid and the creator's share never drops below zero. The fee rate (`f`, `S`) is defined in Appendix E. One markup multiple, set by the creator, applies uniformly across text, voice, image, and video; the usage meter scales the absolute price with each modality's real cost, so a single multiple produces sensible prices everywhere without per-modality tuning. What the fan pays shows as credits; what the creator keeps shows as a live take-home preview, so the creator never does the math.

## 29. Economic Model

Let `P` be endowment principal, `r` the net yield rate per period (after fees and a slashing-risk buffer), `Ê` earned income per period (interaction margin net of cost, plus any licensing), and `B` the expected burn per period (provider costs plus retention).

**Sustainability with multiple revenue sources.** A character has more than one income stream: yield on the endowment and earned income from paid interactions (§10.3), and potentially licensing (§14). The character runs indefinitely when total income covers burn. Per-period surplus is `Δ = r·P + Ê − B`. When `Δ ≥ 0`, principal is non-decreasing. A popular character can be self-sustaining on earned income alone; the endowment is the floor for quiet periods, not the sole engine.

**The billing model as applied economics.** §10.3–§10.10 are this equation implemented. The endowment's net yield is metered across the ring-fenced allocations in priority order; paid interaction turns `Ê` positive by covering compute first, taking the routing fee at the door, and routing all the net into the endowment, which raises `P`. The two together mean: quiet characters coast on yield; popular characters grow their own principal. The creator withdraws only the surplus above a self-set keep-alive reserve (§10.7), so earning and funding are the same act on one owned pool.

**Endowment sized without assuming revenue.** Because earned income is variable and a character nobody talks to earns nothing, the endowment is sized to cover burn from yield alone, treating `Ê` as upside, not as the plan. Earned income then extends runway or grows principal; it is the cushion, not the assumption.

**Runway under shortfall.** If `r·P + Ê < B` and drawdown to a floor `Pf` is permitted, the runway is `T = (P − Pf) / (B − r·P − Ê)` periods.

**A worked example (illustrative, conservative).** Numbers are for intuition, not a promise; all inputs vary. Take a quiet character, one nobody is paying to talk to, so `Ê = 0` and it must live on yield alone. Suppose its recurring burn `B` is dominated by encrypted storage of its substrate plus core hosting and the heartbeat's gas and bounty. On decentralized storage a few gigabytes of persona and memory, renewed, plus site hosting and a daily heartbeat, is on the order of a few dollars to low tens of dollars a year; call it $20/year to be safe. To cover $20/year from yield alone at a deliberately conservative 4% net (well below headline stablecoin rates, to respect the adverse-yield rule), the endowment needs `P = B / r = 20 / 0.04 = $500`. At that point the character is self-sustaining indefinitely with no one paying attention: yield covers keep-alive, and it never touches principal. If net yield falls to 2%, the same $20/year needs ~$1,000; if it goes to zero for a stretch, a $500 endowment drawing down only its keep-alive burn still funds ~25 years before reaching a floor, during which any top-up or a single paid period resets the clock. Now add even light popularity: at, say, $8/month of paid interaction with compute covered first (§10.7), `Ê` swamps a $20/year burn, principal *grows*, and the endowment compounds rather than depletes. The takeaway the math encodes: a modest one-time endowment makes "quiet forever" real, and any real usage makes it a growing fund, not a shrinking one.

**Economic honesty (the stress case).** The model is not a guarantee. `r` is stochastic and can be zero or negative for extended periods: the headline yield venues are funding-rate trades that invert in bad regimes, so real risk-adjusted yield over long horizons may be near zero. `B` grows with usage and model cost. The treasury policy bounds the variance in `r` but cannot remove it. Sizing should therefore assume an adverse-yield scenario, not a favorable one. This is a documented trust assumption, and a yield-source diversification path (staking + lending + synthetic-dollar mix) is the mitigation so the endowment is never single-sourced.

**Continuously remeasured, not fixed at mint.** Because both `r` and `B` drift over time (yield rates move; storage prices historically fall), the required principal `P = B / r` is recomputed every cycle from the *realized* net-of-fee yield and the *current* storage price, using `r` net of the disclosed yield fee so the figure is honest rather than optimistic (invariant 61). The character publishes the result as a health signal, self-sustaining, or short by a stated amount, and its keep-alive reserve floor rises protectively when conditions worsen. So "forever" is a property the character continuously verifies against live conditions, not a one-time estimate that silently goes stale.

**Graceful degradation: pause, not death.** When total income cannot cover burn, the character does not die. It degrades: first drawing principal to the floor, then reducing activity, then going dormant (self-preserved, not answering) until refunded or re-engaged. The only truly terminal failure is sustained underfunding of the substrate storage itself (the raw-data-root material), because that is the one thing that cannot be regenerated. So "forever" honestly means self-sustaining when funded or popular, dormant-but-recoverable when neither, and lost only if the substrate goes unfunded long enough to be dropped. This is design guidance, not investment advice.

## 30. Security Properties and Assumptions

Each property lists the mechanism that provides it and the assumption it rests on.

- **P1 Sovereign survivability (liveness).** With every XEL service offline, `C` stays answerable, payable, and ownable. Mechanism: capability-slot market plus the CI chaos test (§15). Assumption: at least one live provider per required capability and a funded endowment.
- **P2 No single-key catastrophe.** No single key compromise yields both identity control and fund withdrawal. Mechanism: tiered keys, master via owner OR M-of-N, no plaintext spend key. Assumption: fewer than M guardians collude.
- **P3 Persona integrity.** Served outputs run the committed persona. Mechanism: attestation binding plus persona-hash echo (§27). Assumption: TEE attestation is sound (a hardware trust assumption) until zkML replaces it.
- **P4 Bounded spend.** No execution exceeds owner-set caps. Mechanism: on-chain predicate plus circuit breakers. Assumption: on-chain enforcement holds on the home chain; cross-chain caps need account-abstraction wallets or client trust at first.
- **P5 Consent integrity.** A character of a real person carries a valid consent artifact, checked at mint and ingestion. Assumption: estate or subject attestation is honest, with public contestability as backstop.
- **P6 Deletion.** Personal data becomes unrecoverable on request. Mechanism: crypto-shredding. Assumption: no prior plaintext exfiltration.
- **P7 Identity continuity.** "Same being" is decidable from the on-chain lineage (§27). Mechanism: the signed commitment chain from genesis.

**Honest limitations, stated plainly:** cross-chain cap enforcement is not yet native; frontier-model private inference on fully untrusted hardware is open (GPU-TEE narrows it, the trust root is still the vendor); and managed custody is a trust point with a documented path to self-custody.

## 31. Lifecycle State Machine

States `Q = {created, active, dormant, reactivated, succession, archival}`.

Transitions and guards:

```
created    → active     : funded ∧ ≥1 provider per required capability
active     → dormant    : (r·P < B ∧ balance exhausted) ∨ no available provider
dormant    → active     : refunded ∨ provider available   # reactivated
active     → succession : guardian threshold attests death/transfer (§28 Alg 3)
dormant    → succession : same
succession → active     : ownership rotated, master re-encrypted, κ continues
any        → archival   : owner/heir election ∨ underfunding beyond retention
```

## 32. Memory: Stores, Ingestion, and Recall

**32.1 The stores.** "Memory versus knowledge" is two axes, not one: time horizon (this conversation vs. a whole life) and kind (facts, events, identity). Always-loaded persona plus four retrieved-on-demand stores: semantic knowledge, episodic memory, working memory, relational memory.

**32.2 Ingestion pipeline (raw → stores).** One pipeline fans out by data type into all stores: extract → provenance-stamp → moderate/quarantine → chunk/embed → index → commit. Raw sources are retained as the substrate; derived artifacts are regenerable.

**32.3 Recall flow (question → answer).** Retrieval is layered and hybrid, not a single vector lookup: meaning search + exact-term search + temporal filter + relationship graph + re-rank.

**32.4 The orchestrator.** The storage and retrieval components are commodity slots; the control loop that runs ingestion and recall, enforcing encryption, provenance, and on-chain commitment, is the orchestrator, offered as a provider capability, hostable by XEL, another provider, or the user.

**32.5 Verifiable recall.** Because memory is a slot with on-chain commitments, recall is verifiable against the memory-root. The retrieval compute (meaning search, exact-term search, temporal filtering, graph traversal, re-ranking) cannot run on-chain: consensus can neither execute these algorithms nor operate over ciphertext. So it runs in the attested-compute slot and proves itself instead. The flow: the threshold policy releases the decryption key into the enclave only if the on-chain access policy is satisfied; the enclave decrypts the relevant memory, runs the hybrid search, and signs its result together with the memory-root it ran against; and a contract verifies that attestation on-chain and checks the memory-root matches the commitment before anything acts on the output. The result is fail-closed: a swapped, tampered, or unverifiable retrieval provider is rejected rather than trusted. This is the same threshold-encryption-plus-attested-compute pairing used for the brain: the threshold layer decides who may hold the key, the enclave computes on the decrypted data, and the chain verifies the outcome.

**32.6 Operating model.** No chain runs the memory; it runs off-chain in the attested-compute slot, seen decrypted only transiently inside the enclave or on a self-custody client. That slot is a first-party part of the same integrated privacy stack as the encrypted storage and the threshold-encryption policy (§11, Appendix E), not a generic external server: encrypted state lives on decentralized storage, the threshold layer gates key release by on-chain policy, the enclave does the private computation, and the chain verifies the attestation. Because the slot sits behind the retrieval schema and identity of record is the on-chain commitment, the provider and the engines inside it are swappable without data loss: a new provider rebuilds the derived layer from the committed substrate, and its attestation still binds to the same memory-root.

**32.7 Substrate vs derived layer (built to outlast RAG).** Two tiers: permanent substrate (committed by raw-data-root) and regenerable derived layer. The memory method can be replaced by regenerating the derived layer from the substrate without data loss.

**32.8 Permissioned contributions.** Others (family, friends, fans) can enrich a character through a reviewed, owner-approved queue that can add memory but never touch policy, keys, funds, or authority.

**32.9 Faithful representation and its limits.** A character is a representation of a person, not the person. It carries a disclosed fidelity signal and prefers deferral over confabulation when provenance is absent.

**32.10 The public page and naming.** Every character has a public page, and it is built to survive the operator. The design is one-app-serves-all: a single shared client app is published to decentralized static hosting once, and it renders any character by reading that character's object ID from the URL and pulling the character's on-chain record and public manifest. New characters need no new hosting; a character's page exists the moment it is minted. This keeps the cost of "a permanent home for every character" close to fixed rather than growing per character, and it makes the page independent of the operator: the app reads live on-chain data in the visitor's browser, so it works as long as the chain and the decentralized host do, with or without XEL.

The object ID is the true name and the permanent link. The canonical, shareable, survives-anything URL resolves from the object ID and is served by any portal (the default is operator-run, but portals are permissionless and anyone can host one). A friendly handle (shown as a name on the page) is an on-chain, owner-set display label, not a globally unique address and not backed by a name service. Typing a handle URL is a convenience the operator provides by resolving the handle to an ID; that convenience is allowed to disappear, while the ID-based link never does. The share action hands out the ID-based link, so findability never quietly depends on the operator. The operator's own domain fronts the same app for a friendlier address, with no redirect, but it is the same artifact and the same data.

The owner signs in to the page by connecting a wallet, so the full owner experience (manage, edit, withdraw, decrypt) runs client-side against on-chain ownership and the threshold decryption policy, with no server and identical behavior whether the page is reached through the operator's domain or the permanent decentralized URL. Live interaction from the page calls whatever serving providers the character's on-chain policy names (the operator's by default, swappable), never hardcoded endpoints, so the page can talk to the character through anyone serving it and degrades gracefully to the static profile and provenance if none is.

## 33. Smart Contract Architecture (Move Packages)

Eleven modules:

1. **Identity.** Types: aNFT (the character object; immutable creator, timestamp, consent_ref), commitments, lineage.
2. **Authority.** Types: agent capability (delegate-bound, non-copyable), two-tier semantics.
3. **Access control.** Functions gated by owner OR M-of-N guardians.
4. **Guardian and recovery.** Types: guardian set (members, threshold M), timelock + dispute window.
5. **Wallet and payment.** Types: SpendPolicy (per-call cap, daily cap, per-capability budget).
6. **Treasury.** Types: treasury policy (venue allowlist, per-venue caps, slippage bound, target yield band, drawdown trip).
7. **Endowment.** Types: endowment (principal), operating buffer, allocation balances (keep-alive, storage, interaction) with isolation, keep-alive reserve floor. Functions: `heartbeat` (authority-free epoch cycle: claim yield, meter into allocations by priority, just-in-time unstake to refill the buffer, settle bills, pay bounty, compound residual), `withdraw` (owner-only, above reserve), `top_up` (anyone, to principal or a named allocation).
8. **Wallets (multi-chain).** Types: per-chain receive wallet set with one primary; sweep parameters (threshold, per-bridge cap). Functions: owner-controlled add/remove/change-primary; inbound-only auto-sweep to the primary under the agent capability, bounded and never outbound.
9. **Access & management.** Types: interaction gates (reach × payment), scoped passwords, manager whitelist (wallet → scope). Functions: gate checks at serving boundary; scope checks fail-closed for managers.
10. **Capability registry.** Types: provider_policy (capability id, version, pinned providers).
11. **Circuit breaker.** Types: PausedFlag, breaker thresholds. Functions: pause / resume.

## 34. Security Requirements and Threat Model

**34.1 The contract contains the model.** An autonomous agent that ingests external text can be prompt-injected; the contract must ensure a compromised model still cannot exceed caps, move funds off the character's own wallets, pay a non-allowlisted provider, or perform any owner-tier action.

**34.2 Move and contract-level requirements.** Capability checks over signature-validity checks; non-copyable capabilities; fail-closed on every verification; no upgrade authority.

**34.3 Key management.** Tiered keys; no long-lived plaintext spend key; master secret via owner OR M-of-N.

**34.4 Guardian and recovery.** Threshold + timelock + dispute window; no single guardian can trigger recovery or succession; no operator or provider is ever the guardian majority.

**34.5 Oracle and valuation.** Stale or low-confidence oracle reads fail closed; USD caps and runway computed from committed feeds.

**34.6 Treasury, swap, and bridge.** Allowlist + per-venue caps + slippage bound; delegated transfers only to own wallets; bridging principal always owner-signed and bounded per transit.

**34.6a Endowment, allocations, and heartbeat.** Allocation isolation is a contract invariant: no path moves funds between allocations except the metering allocator, which only flows yield inward. The heartbeat is authority-free and idempotent per epoch: it cannot exceed a fixed bounty, cannot move funds sideways, and no-ops before the epoch elapses, so a hostile or spamming caller gains nothing. Withdrawals are blocked below the keep-alive reserve minimum. Yield rebalances execute only within the owner's risk envelope; principal exit and bridging are owner-signed and never delegable.

**34.7 Attested compute.** Output bound to persona-hash and input; unattested hosts never see plaintext; bonds enable slashing of tampered inference.

**34.8 Payment and facilitator.** Facilitators cannot alter terms; pluggable with failover; no hardcoded single operator.

**34.9 Human and client layer.** The operating client is the trust boundary in the managed experience; self-custody keeps it local; passwords never substitute for decryption policy.

**34.10 Availability and economics.** Graceful degradation to dormant rather than death; substrate underfunding is the one terminal risk.

**34.11 Process requirements (not optional for launch).** Open-source contracts; published exit conditions and portability; the XEL-can-die CI chaos test.

## 35. Version 1 Build Plan and Acceptance Criteria

Phase 1 scope (§16): aNFT object, Proof of Genesis, encrypted access-gated storage, persona/memory commitments, one capability (`inference.v1`), agent capability, guardian recovery.

Acceptance: the XEL-can-die invariant passes as a CI chaos test on this minimal footprint; a live character answers, pays, and is ownable with every XEL service offline; key rotation on transfer verified; no admin key or upgrade authority present in deployed contracts.

## 36. Thousand-Year Survivability

**36.1 Cryptographic agility.** Today's signature schemes and hash functions will not last; schemes are replaceable parameters with an owner-authorized migration path, including post-quantum.

**36.2 Chain independence and escape.** Sui may not exist in a thousand years. Identity lives in the commitments, so an owner-authorized migration can re-home the character on a successor chain and storage.

**36.3 Storage and format longevity.** Encrypted memory must survive storage-network turnover; the substrate is retained and re-pinnable, and formats are migratable by regenerating the derived layer.

**36.4 Multi-generational succession.** Over centuries every guardian and heir dies; succession is designed to repeat indefinitely, rotating guardian sets and heirs across generations.

**36.5 Economic survival across epochs.** An endowment must outlast currencies and yield regimes; principal is denominated and diversifiable, and degradation is graceful rather than terminal.

**36.6 Institutional independence.** No company, XEL or any provider such as GEN, will exist in a thousand years, and the design assumes it. Nothing load-bearing depends on any one company's survival.

---

# Appendices

## Appendix A: The aNFT Object (Commitment-Oriented)

In practical terms, the aNFT is an owned object with an immutable genesis record, versioned commitments for persona and memory, pointers to encrypted off-chain state, an owner-set display handle, wallet references, and links to the endowment, guardians, managers, and provider policy. Genesis immutability is structural: the creation record is part of the object, not mutable profile text.

## Appendix B: Authority, Agent Capability, SpendPolicy, Two-Tier Entry

Authority has two public principles. Root actions require the owner-held aNFT. Delegated actions require a revocable agent capability whose scope, limits, allowed providers, and expiry are checked before anything runs. A signature is never enough by itself; it must be paired with the right object and the right scope. Root actions such as withdrawing principal, transferring ownership, changing the manager set, or widening delegation are deliberately outside the delegated envelope. Spend policy is tracked against caps and fails closed when limits, recipients, providers, assets, or timing do not match the current policy.

## Appendix C: Guardian Recovery & Access Policy

Guardian recovery uses an M-of-N set chosen by the owner. Guardians cannot operate the character day to day; they can only help recover access or execute succession under threshold approval. Recovery and succession sit behind a timelock and dispute window, then rotate encryption access to the new holder so old access is cut off cleanly. This is how the system avoids both extremes: a lost wallet should not kill a character, and no single guardian should be able to seize one.

## Appendix D: Capability Schema Examples

Public capability families include inference, ingestion, retrieval, treasury, distillation, voice, image, and video. Each request carries the character identity and the relevant commitment so a provider can prove it used the right persona, memory, and policy. Each response that touches private reasoning or generation carries auditable metadata and, for sensitive paths, an attestation. Variable-cost modalities use quote or hold-and-settle semantics so the user sees a bounded commitment while the provider still settles actual usage. Voice cloning has a stricter consent gate and fails closed without both scoped consent and owner authorization. Concrete provider assignments for the current defaults are in Appendix E.

## Appendix E: Default Implementations (Configurable, Not Load-Bearing)

These are the concrete systems currently filling each capability slot. They are implementation choices, not part of the standard: any provider meeting a slot's requirements (accept programmatic crypto payments, permissionlessly joinable, verifiable/decentralized) can replace them. This appendix is expected to change over time without altering the body of the paper.

**Why Sui is the default across these slots.** Native object model (an aNFT owns its own memory, wallets, and agent capability natively). One integrated privacy stack: Walrus (encrypted storage), Seal (threshold encryption with on-chain access policy), and Nautilus (attested compute) interoperate as a native whole, and Seal's owner-OR-M-of-N gated decryption maps directly onto the key and crypto-shredding model (§9). Optional onboarding conveniences (sponsored/gasless transactions) layer on top of a self-custody root with no third-party dependency. Native delegation (capabilities are first-class objects, so the agent capability can be minted, handed to a delegate, and revoked natively). Treasury: keeping principal on the home chain co-locates funds with the object that owns them, and Sui has deep stablecoin-lending liquidity (Suilend, NAVI) offering stable-denomination yield with fast withdrawal, which is what the survival path needs.

The rationale rests on identity and privacy (the hard parts), not yield, payments, or liquidity (commodity layers). Honest counterweights: the cleaner machine-payment standard (x402) is not native to Sui, so XEL hosts its own facilitator; and the deepest liquidity and most-audited bridges still live on Ethereum and Solana. The primary chain remains owner-changeable via the chain-adapter design (§10.1).

| Slot | Current default(s) | Permissionless successor |
|---|---|---|
| Ownership & settlement | Sui | Already decentralized |
| Receive wallets (default set) | Primary: Sui. Additional receive-only: Solana, Base. Each auto-sweeps to the primary above an owner-set threshold; owner can add/remove chains and change which is primary | Any chain with a treasury adapter; owner-configured set |
| Encrypted storage | Walrus | Already decentralized |
| Key access / encryption | Seal | Already decentralized |
| Attested compute (orchestration + small models) | Nautilus (Sui-native, AWS Nitro Enclaves) | Multiple TEE vendors, then ZKML |
| Attested compute (large-model private inference) | Phala Network (Intel TDX + NVIDIA H100/H200 GPU TEEs) | Additional GPU-TEE networks, then zkML |
| Attested compute (alt) | Marlin (Oyster) | Additional coprocessor networks |
| Relay | XEL-run relayer (Mysten pluggable pattern) | Many operators; relayer-in-TEE |
| Inference (text) | A provider *list*, not one provider. Candidates: GEN (attested), a decentralized inference market (Chutes / Bittensor subnets), and attested GPU-TEE inference (Phala) for sensitive characters. The character's privacy setting constrains the class: private or preserved-person characters route only to attested providers (memory is decrypted only inside an enclave); public characters with no sensitive memory may use cheaper open decentralized inference | Many providers per `inference.v1`; the list is owner-configurable and no single provider is load-bearing |
| Voice generation (STT + TTS, message and real-time) | GEN voice pipeline (default); metered by output speech length or session duration | Any provider meeting `voice.v1`; multiple STT/TTS vendors |
| Voice cloning (samples to reusable voice) | GEN voice-clone pipeline (default), run in attested compute; consent-gated (requires a voice-scoped consent artifact) and owner-root only; samples and model are SEAL-gated | Any provider meeting `voice_clone.v1`; the consent gate and SEAL classification are protocol-level, not provider-specific |
| Image generation | GEN image pipeline (default); metered by resolution, steps, prompt length, reference-image count | Any provider meeting `image.v1` |
| Video generation | GEN video pipeline (default); metered by clip count, duration, resolution, frame rate | Any provider meeting `video.v1` |
| Payment standard | x402 (HTTP-native stablecoin payments), pay-per-call preferred and default | Any standard with the same properties |
| Provider payment method | Crypto-native pay-per-call by default (no key). Some launch providers may be key-based (operator-held account) as a bridge; swappable for a crypto-native equivalent as they emerge, and never attached to the character | Direction is pay-per-call everywhere; key-based fillers shrink toward zero |
| Payment facilitator | XEL-hosted x402 on Sui at launch | Anyone runs a facilitator; client-configurable + failover |
| Card-to-crypto on-ramp | Stripe (optional, for paid interactions) | Any on-ramp; crypto-native path always works |
| Interaction gate | Serving-layer reach × payment gates + scoped passwords (memory tiers) | Any serving provider meeting the schema |
| Endowment / allocation accounting | On-chain Move `endowment` module (principal + ring-fenced allocations) | Native to any object-centric chain |
| Yield harvest (heartbeat) | Permissionless authority-free trigger, contract-paid bounty; launch keeper set is Talus Leaders (Path A) primary + XEL cron fallback, both firing XEL's own heartbeat tx for the stablecoin bounty. Harvest itself is on-chain and atomic: the keeper composes one PTB (venue withdraw/claim then heartbeat) so the yield never leaves on-chain control | Incentivized keeper network; any bot, owner scheduler, or heir can compete for the bounty |
| Yield strategy (advisor) | XEL reference strategy in a Nautilus enclave (proposes within owner envelope) | Any attested strategy provider; owner-bounded |
| Treasury execution (survival default) | Home = Sui. Survival principal in a stablecoin, supplied to stablecoin lending: default Suilend, fallback NAVI (both mid-single-digit APY, near-instant withdrawal to meet renewal deadlines). Swappable slot | Any lending venue meeting policy; multi-venue with allowlist, caps, failover |
| Treasury execution (optional higher-variance) | Owner-chosen only, for surplus above the reserve, never the survival path: yield-bearing synthetic dollars (suiUSDe, higher but funding-rate/depeg risk) and SUI liquid staking (Haedal ~2.5–3%, volatile-denominated, multi-week unbonding). Flagged as higher-risk | Any venue meeting policy |
| Survival renewal | On-chain reader of each blob's expiry (Walrus blob object field) + `extend_blob` before a ~2-epoch runway margin, in ~6-month chunks; WAL acquired just-in-time via the swap slot, SUI gas float self-funded from stablecoin | Permissionless keeper; anyone can trigger the renewal |
| Denominations | Principal/yield: stablecoin. Storage: WAL (acquired just-in-time). Gas: SUI (self-funded float). Cross-chain receipts: swept to stablecoin on the primary (invariant 57) | Owner-configurable within policy |
| Protocol fee | Disclosed on-chain, targeting ~10%: routing fee on interaction credits and discretionary storage, plus a fee on yield; keep-alive at cost, principal never touched; zero if self-provisioned | Fully avoidable by self-routing |
| Price oracle | Pyth (Sui-native pull oracle) | Switchboard, Supra; multiple networks |
| Swap | Aggregators: 7k, Aftermath, Hop over Cetus, DeepBook, Bluefin | Any aggregator meeting the policy |
| Bridge | Sui Bridge (validator-operated, native ETH) default; Wormhole, ZetaChain for wider reach | Most-audited bridge per route; per-bridge caps |
| Cross-chain custody | Ika (MPC dWallets), LayerZero (omnichain) | Additional MPC / messaging networks |
| Discovery index | Open x402 indexes (402 Index, CDP Bazaar, x402scan) | Already open/federated |
| Ingestion / persona-update | GEN orchestration + quality layer (social and document); commodity transforms subcontracted | Open ingestion spec; competing providers |
| Memory & retrieval | LlamaIndex (hybrid dense + sparse retrieval), Graphiti (temporal knowledge graph for the relational store), optional agentic layer; all behind `retrieval.v1`, operated by XEL at launch but run inside attested compute so plaintext is never exposed to the operator | Any engine meeting the schema; swappable, index regenerable from committed substrate |
| Data extraction | Commodity providers (transcription, OCR, embeddings), called by the orchestrator | Any provider meeting the schema |
| Contribution review | Permissioned queue, encrypted on decentralized storage; owner-signed approval merges | Open; owner or delegated reviewers |
| Media / STT / TTS / moderation / publishing | Commercial providers initially | Swappable per schema |
| Public hosting | One shared client app on Walrus Sites (a single site object), rendering any character by object ID via client-side routing; served through a portal (default operator-run) | Already decentralized; portals are permissionless (anyone can run one), app is one fixed artifact not per-character |
| Handle / naming | On-chain owner-set display label per character (not unique, no registry); operator-hosted reverse-lookup index powers `@handle` convenience URLs | Object ID is the true name and permanent link; handle index is disposable operator convenience |
| Keeper / scheduler | Launch keeper set is belt-and-suspenders: a third-party network (candidate: Talus Leaders) firing XEL's permissionless heartbeat for the stablecoin bounty (Path A) as primary, plus XEL's own cron as an independent fallback that fires the same tx if the primary misses. XEL adopts no keeper's workflow, gas, or token system (Talus's Nexus/gas rails are explicitly not used). Costs no trust: the heartbeat is authority-free and idempotent, so running both is safe and either alone suffices; it can take nothing but the fixed bounty. Harvest is not the keeper's job: the keeper composes one atomic PTB (venue withdraw/claim then heartbeat) so the yield flows on-chain within the transaction, the contract enforces amounts, and the keeper only pays gas | Incentivized keeper network; the slot is permissionless and competitive, no keeper is hardcoded or load-bearing |
| Custody / gas | Self-custody wallet (user holds keys, no third-party dependency); login-based onboarding optional, not required | Self-custody default |
| Gas sponsorship (per chain) | Native abstraction per chain, sponsor repaid in the SAME native gas token it spent via an in-transaction stablecoin->native swap, at cost, so its gas balance stays whole (invariant 57): SUI = sponsored transactions (Mysten sui-gas-pool / Enoki / Shinami); Base = ERC-4337 ERC-20 paymaster (accepts USDC, stays ETH-whole); Solana = fee-payer / relayer with in-tx swap (Octane-style). Onboarding gas (mint) may be an operator subsidy; ongoing-ops and sweep gas are reimbursed | Any gas station / paymaster / fee-payer per chain; swappable, owner can self-fund |
| Wallet / signer | Owner signer default (Phantom, Sui support); delegate = operator key holding the agent capability; hardware wallet for sharp actions | Any wallet meeting the standard |
| Free tier (operator-sponsored) | XEL, as operator, sponsors a limited free experience to remove onboarding friction: limited text conversation and initial mint, paid by XEL, not the endowment. Voice, image, and video are always paid (fan or endowment). Free mint is open for now; a gate may be added later | Operator-level perk, optional and non-load-bearing; if XEL is absent, minting is self-paid and interaction is paid or endowment-funded, and the character is unaffected |

**Deepest hidden dependency to track:** the Sui-native attested-compute default roots its attestation in AWS Nitro, and GPU-TEE providers root in their respective chip and cloud vendors. TEE attestation is therefore a hardware trust assumption at every layer of the compute slot. It's acceptable as a default, but it's the reason "multiple TEE vendors, then ZKML" is a roadmap item, not just a caveat.

## Appendix F: Open Questions and Unsolved Problems

Honesty about what is not yet solved is part of the specification. None of these block the version 1 scope (§35); all sit in later phases.

1. **Private inference at frontier scale.** TEE attestation is a hardware trust assumption, and zkML cannot yet prove a large model's output. Running the brain privately on fully untrusted hardware, with a proof it ran the committed persona, is real for small models and a vendor-trust story for large ones. Expected to stay partly open for some time.
2. **Autonomy while the owner is gone (the heartbeat).** No chain offers native, self-firing scheduling, so the endowment's epoch cycle must be triggered by an external transaction. The design resolves the *authority* problem (the heartbeat is permissionless, authority-free, and bounty-paid, so anyone can send it and it can take nothing, §10.4), but it cannot remove the need for *someone* to send it. If no one ever does, the character coasts on existing allocation balances and degrades gracefully rather than losing funds or control. A live, incentivized, decentralized keeper network is the remaining maturity item.
3. **Death detection and the succession trigger.** Reliably detecting a creator's death without false positives (guardian thresholds, timeouts, dispute windows, protection against premature triggering) is underspecified and load-bearing for inheritance.
4. **Consent verification for a real person, especially posthumously.** On-chain a signature is checkable; binding it to the actual human, or to a legitimate estate, is an off-chain identity problem. This is the core legal risk of the category and tends to surface with the first real user.
5. **Persona fidelity.** There is no defined way to fully measure whether a character faithfully represents the person, or to fully detect drift as model and memory change. Mitigations are in the design (disclosed fidelity signal, deferral over confabulation, versioned persona), but a rigorous general evaluation and drift-monitoring methodology remains open.
6. **Trustless yield discovery.** There is no on-chain, verifiable ranking of the best-yielding venues. The design bounds this by making the yield scanner an *advisor* that can only propose within the owner's risk envelope, and by running it in an attested enclave so its proposal is verifiable (§10.5). But sourcing a genuinely trust-minimized, decentralized yield signal remains open; today it rests on the owner's allowlist plus an attested advisor, not on a trustless oracle.
7. **Money transmission and creator tax reporting.** Paid interactions plus creator withdrawals plus metered compute pull an operator into money-transmission and creator-tax-reporting regimes, heavier than minting alone. Scope and jurisdiction handling to be specified before creator-charged mode ships broadly.

## References

This work draws on prior art and existing standards, and does not claim the underlying primitive as new. The space moves quickly; this is a snapshot.

1. Alethea AI (intelligent NFT). Originated the idea of an AI character as an NFT.
2. ERC-7857 (Intelligent NFTs / Agentic ID), 0G Labs. Encrypted, transferable agent NFTs with key rotation on transfer.
3. Story Protocol. Programmable on-chain IP and licensing; the benchmark our proposed rights layer is measured against.
4. Modern agent frameworks (OpenAI Agents SDK, Anthropic tool use and the Model Context Protocol).
5. ERC-8004 (Trustless Agents), Ethereum. On-chain identity, reputation, and discovery for agents.
6. x402. Open HTTP-native crypto-payment standard for machine-to-machine payments.
7. Sui and the Move language, Mysten Labs. Object-centric L1 with native object ownership.
8. Seal. Threshold encryption with on-chain access policy on Sui.
9. Walrus and Walrus Sites. Decentralized encrypted storage and static hosting.
10. Nautilus. Sui-native attested compute using hardware enclaves.
11. Phala Network. GPU-TEE confidential inference.
12. LayerZero. Omnichain messaging; a reference point for cross-chain identity.
13. Trusted Execution Environments (for example Intel TDX, AWS Nitro Enclaves).
14. ZKML. Cryptographic proof of model execution; the long-term successor to hardware-rooted attestation.
15. Right-of-publicity and data-protection regimes (for example GDPR).
16. Ika. Sui-native MPC network (dWallets) for programmable cross-chain custody.
17. Pyth Network. Pull-based price oracle on Sui and many other chains.

---

*Whitepaper. Limitless Labs / XEL, 2026. Contracts, reference client, and schemas released open-source. Identity anchored in verifiable commitments; infrastructure no one can switch off.*

**Beings That Live Forever.**


---

# How It Works

The mechanism in plain language, no code. By the end you know what actually happens when a character exists, remembers, thinks, earns, lasts, and is passed on, and why no company can take it from you.

## The whole system in one picture

A character is made of a few parts, each with one job.

There is **the character itself**, an object you hold in your wallet. Holding it makes you the owner. It does not contain the private stuff directly; it holds proof of who the character is and pointers to where everything lives.

There is **the character's memory and personality**, stored encrypted, openable only by you.

There is **the character's own fund**, its endowment, which pays for its existence over time.

There are **the services that make it work**, the intelligence to think and talk, the recall of memories, the tools for voice and images and video. The character rents these, and any can be swapped. They are like electricity and water, not like the house.

And there is **the character's public page**, one shared app that shows any character by reading its public information, at a permanent link.

Put together: you hold the character, the character holds its own money and points to its own private memory, the thinking happens in sealed services that prove they used the real character, and the whole thing keeps running without depending on any single company.

## How it pays for itself

The endowment is the part that makes XEL different from a normal AI character. A normal digital character survives while someone keeps paying a bill. A XEL is designed to carry its own fund, earn from that fund, and use the earnings to pay the small costs of staying alive.

The fund is held in a stable denomination, not a token whose price has to go up for the character to survive. Its main job is boring on purpose: earn a conservative return, keep the encrypted memory paid for, and renew storage before it expires. When a renewal is due, a permissionless heartbeat checks the character's storage runway, harvests what is needed, converts only what must be converted, pays the bill, and compounds what remains.

There are guardrails around that money. The keep-alive reserve is the floor that cannot be withdrawn past. Interaction money and fan credits are tracked separately so a busy month of chatting cannot drain the survival fund, and prepaid credits stay refundable until the promised interaction is delivered. If conditions get worse, yield drops or storage costs rise, the required reserve rises with them. The character measures its own survival instead of relying on a launch-day estimate.

So the promise is not "magic forever." It is much stronger than that: a funded character has a mechanical path to keep paying its own way, and if it ever falls short, it degrades visibly and recoverably instead of being silently deleted.

## It lives in your wallet

The character is an object, and you hold it in your own wallet. This is the difference between owning and renting, made real. When your character is an account on a company's server, the company holds it and lets you use it. When it is an object in your wallet, you hold it and no one else can reach it. Holding it is the only authority there is.

Because you truly hold it, three things are true that no normal app can offer. No one can take it, freeze it, edit it, or delete it, not even the people who built XEL. You can give it away or sell it, and everything moves with it at once, with nothing left behind and nothing held back. And you can pass it to someone on purpose, like leaving it to family.

The object does not hold secrets in the open, since everything on this kind of public system is visible. It holds proof of who the character is and locked pointers to where the private parts live. Think of it as the deed and the keyring, not the contents.

## Its memory is private

Everything your character remembers is encrypted, and the key to open it is tied to owning the character. The memory lives in encrypted storage, not a readable company database. Only whoever proves they own the character, or a group of guardians you name, can unlock it. You can read your character's memory; no one else can, including the people running XEL.

One honest subtlety, because it is where privacy actually lives or dies. When your character thinks, the intelligence has to read the memory for a moment. That happens inside a sealed environment, a locked room that processes the memory, then forgets it, and that can prove it used the real, unaltered memory. So even in the moment of thinking, no human reads your conversations, and you can verify the right version was used.

If you want something forgotten, the character deletes the key rather than chasing copies. Without the key, the encrypted memory is permanent nonsense. The one honest limit: this cannot un-see anything already taken out in the clear, which is why the sealed-room design matters.

## Its brains are rented, and swappable

The intelligence that makes your character think and talk is a service it uses, not a part it is welded to, and it can always be swapped. This sounds like a technical detail, but it is actually the protection. If a character were permanently wired to one company's AI, that company could hold it hostage. XEL is built so every service, thinking, memory recall, voice, images, video, payments, is a replaceable slot. If one provider disappears or misbehaves, the character switches to another and keeps going.

The character's identity does not live in any of these services. It lives in the character object and its private memory, which you own. The services are hired help. That is why no single provider is load-bearing: pull any one out, even the defaults we run, and the character still works through another.

## It can be passed on

You choose a set of trusted people, guardians, with a rule like "any two of these five." Guardians cannot use your character day to day, spend its money, or change who it is. Their only power is to help in two situations: if you lose access to your wallet, they can together recover the character to you; and if you are gone, they can together pass it to an heir you set.

The handover is careful on purpose. It takes the agreed group, waits through a delay in which it can be disputed, and re-locks the character's memory to the new owner so the transfer is clean. A character, a preserved grandparent, a family companion, an original creation, can move down through a family or community across generations, safely and on purpose.

## Talking to a character, and paying

If someone made a character and you just want to talk to it, this is all you need.

You do not need a crypto wallet or special knowledge. You get a simple, lightweight account and can pay with a card if the character costs anything. You never see the blockchain machinery. You just talk.

The owner decides two separate things: who may talk to it (anyone, only invited people, or only the owner) and whether it costs anything (free, optional tips, or payment required). When a character costs money, you pay in simple credits or a monthly pass, shown in normal dollars. Behind the scenes real costs are measured precisely (a short text reply costs little, a long video far more), but you just see credits ticking or a plan with allowances, like a phone plan. Cheaper actions show a price before you tap; open-ended ones like a live call show a running meter and stop cleanly rather than surprising you.

Your conversation is private, gated by the owner's settings, and paying never lets you read the character's locked memory. Paying lets you talk; it is not a key.

## Its public page

Rather than a separate website per character, XEL uses one shared app. You give it a character, and it shows that character's page by reading the character's public information from the record. This keeps it cheap (no new site per character) and durable (the app does not depend on the company).

Every character has a permanent link based on its unique identity that keeps working no matter what. It also gets a friendlier web address and a display name, a handle. The friendly address and the handle are niceties the company provides; if they went away, the permanent link would still work and the page would still load, because it reads from a public record no one controls.

---


---

# Persona Settings

A persona is the character's stable identity. It tells XEL how the character
speaks, what it knows about itself, what boundaries it follows, and how it
should answer in chat or voice.

XEL can build a persona from two kinds of input:

- **Direct text** written by the owner in the Persona tab.
- **Source files and links** added in the Media tab, then used by the
  auto-update setting.

## What the Prompt Is

A prompt is the instruction set XEL creates from the persona. It may include
voice, style, biography, recurring facts, boundaries, and examples of how the
character should respond.

The full private prompt is not shown on the public profile. Public profile
fields such as name, bio, image, and media are separate from the private prompt
used to operate the character.

## Basic Persona

The basic persona is the readable owner-facing version of the character. It is
the simple description you can review in the Persona tab.

It should describe the character's identity, tone, background, and stable
behavior. It should not be used as a dumping ground for every document the
character may need to know later. Documents, posts, transcripts, PDFs, and
reference material belong in source files.

## Auto-Update Persona from Files

When **Auto-update persona from files** is on, XEL uses selected source files
to rebuild the character's persona when those files change.

That is useful when the character is based on a person, creator, public body of
work, or large media archive. Instead of hand-editing every change, you add or
update the source files and XEL refreshes the persona from that evidence.

When this setting is on, the basic persona field is locked for direct edits so
the generated version and the source files do not drift apart. You can still
read and scroll the persona. To change it, update the files, add supplemental
notes, or turn auto-update off.

## Supplemental Notes

Supplemental notes are owner-written instructions layered on top of an
auto-built persona. Use them for things that are hard to infer from files:

- Preferred tone or boundaries.
- Topics to emphasize or avoid.
- Facts that must be preserved.
- Corrections to source material.

Supplemental notes are not a public bio. They are instructions for character
behavior.

## How File Scope Affects Persona

Files are managed in the Media tab. Each file can be assigned to one of three
scopes:

| Scope | Meaning |
|---|---|
| **Persona** | Use this file to shape identity, voice, biography, and behavior. |
| **Memory** | Use this file as knowledge or long-term memory, but do not let it define personality. |
| **Both** | Use this file for both persona building and memory ingestion. |

This separation matters. A tax document, contract, or textbook may be useful
for memory, but it should not change the character's personality. A biography,
interview, or creator transcript may belong in both.

## Files Changed Warning

If files have changed since the last persona refresh, XEL may show a warning at
the top of the Persona or Media tab. Use **Update persona** to rebuild the
persona from the current files.

## Manual Persona Edits

If auto-update is off, the owner can edit the basic persona directly. Saving a
persona update creates a new version of the character's instructions.

Manual edits are best for small characters, fictional characters, and cases
where the owner wants total control over the prompt rather than a file-derived
persona.

## Privacy

Persona instructions can contain private material. Treat the Persona tab like a
private control surface, not like public profile copy. Only put information in
public fields or public files if it should be visible to others.


---

# Media and Memory Settings

The Media tab is where you manage the files and links that help XEL build and
update a character.

Some files shape the character's persona. Some files become memory. Some files
do both.

## What Source Files Are

Source files are owner-approved inputs attached to a character. They can come
from uploads or linked sources.

Examples:

- Images, videos, and audio clips.
- PDFs, text files, Markdown files, CSV files, and documents.
- Post descriptions, captions, transcripts, comments, and metadata.
- Biography notes, interviews, scripts, articles, and reference documents.

## File Scope

Each file has a scope that tells XEL where it can be used:

| Scope | Use |
|---|---|
| **Persona** | Shape voice, identity, bio, behavior, and prompt instructions. |
| **Memory** | Add facts, documents, events, and knowledge for recall. |
| **Both** | Use the file for both persona building and memory ingestion. |

A file marked **Memory** can help the character answer questions without
changing the character's personality. A file marked **Persona** can shape the
character's voice without being treated as a knowledge base. **Both** is for
material that should do both jobs.

## Privacy

Each file can also have a visibility setting.

| Visibility | Meaning |
|---|---|
| **Private** | Keep the file owner-controlled. Use this for sensitive source material. |
| **Public** | Allow the file to be visible or downloadable where the product exposes it. |

Visibility and scope are different. Visibility controls who can see the file.
Scope controls how XEL may use the file.

## Uploads and Links

Use uploads when the file is on your computer. Use links when the source lives
somewhere else and XEL can import it.

Large files may take longer to process. If a file cannot be read, XEL may still
store it as an asset, but it may not improve persona or memory until the
content can be extracted.

## Auto-Update Persona from Files

When **Auto-update persona from files** is on, XEL can rebuild the character's
persona when selected source files change.

This is useful for creators, public figures, and large archives where the
persona should stay aligned with the latest approved source material.

## Auto-Update Memory from Files

When **Auto-update memory from files** is on, XEL watches selected files and
linked sources. When they change, XEL can refresh memory so the character can
recall the updated material.

This is useful for facts, documents, transcripts, posts, and other material the
character should be able to remember without turning it into personality.

## Files Changed Warnings

XEL may show a warning when files have changed since the last refresh.

- **Files have changed since the last persona refresh** means the persona may
  not include the latest approved source material yet.
- **Files have changed since the last memory refresh** means memory may not
  include the latest approved source material yet.

Use **Update persona** or **Update memory** to recompute from the current files.

## Conversation Memory

Conversation memory is different from source-file memory.

- **Session memory** is the short-term context inside the current chat or voice
  session.
- **Conversation history** is the record of prior chats with a user, when the
  user is identifiable and the character is allowed to use it.
- **Long-term memory** is the distilled, durable memory that survives sessions
  and helps the character remember important information later.

For logged-in users, XEL can use the account identity to keep conversation
context associated with the right person. For anonymous users, XEL may use a
browser identifier. This helps avoid mixing one visitor's memory with another's.

## What to Put Where

Use **Persona** scope for files that define who the character is:

- Bios and interviews.
- Voice and style examples.
- Creator background.
- Boundaries and character rules.

Use **Memory** scope for files the character should know:

- Documents, PDFs, notes, and spreadsheets.
- Post descriptions and transcripts.
- Reference material.
- Facts the character may need to recall.

Use **Both** when a file does both jobs, such as a long interview that defines
voice and also contains important facts.

## Deleting Files

Deleting a file removes it from future persona and memory refreshes. If the
file was already used in a previous refresh, run the relevant update again so
the character is rebuilt from the remaining files.


---

# Ownership and the aNFT

XEL starts with a different ownership model from normal AI products. A character is not an account in XEL's database. It is an owned on-chain object: an autonomous NFT, or aNFT.

Holding the aNFT is root authority over the character. That is what makes the character yours in the durable sense, not just accessible through an app login.

## The aNFT is the character

The aNFT is the root object for one character. It does not store every private memory in public. Instead, it holds the public facts and commitments that make the character verifiable:

- who owns it;
- where its encrypted memory and persona live;
- what the current persona and memory commitments are;
- what rules govern access, delegation, payments, and recovery;
- what endowment and wallet references belong to it;
- what provider policy it uses;
- what public identity or handle it displays.

The private material stays encrypted off-chain. The aNFT is the deed, the rulebook, and the pointer map. It is not a public copy of the character's private mind.

## Why this is different from an account

In a normal app, the company owns the database and gives you access. Your username, subscription, files, and AI character all exist inside that company's system. If the company changes the rules, deletes the account, loses the data, or shuts down, you are asking the company for mercy.

In XEL, root authority is not a customer-service permission. It is possession of the aNFT. The company can run a nicer interface, help with onboarding, sponsor a free tier, or route default providers, but those are conveniences around the character. They are not the source of ownership.

That is why the question changes from "will XEL let me keep this?" to "do I hold the object that controls it?"

## What ownership gives you

The owner can do root actions:

- transfer or sell the character;
- set or change managers and delegates;
- configure interaction access and pricing;
- choose provider policies;
- raise or lower the keep-alive reserve within allowed limits;
- withdraw surplus above protected reserves;
- migrate the character to a future version;
- set guardians and succession.

These actions are root because they change who controls the character, how it survives, or what risks it may take.

## What ownership does not expose

Owning the aNFT does not mean the chain stores private memory in plaintext. The chain is public, so secrets do not belong there.

Instead, ownership proves who is allowed to unlock encrypted material. The encrypted memory and persona live off-chain, and decryption is released only to the owner or the configured guardian threshold. Reading and spending are deliberately separated:

- **Reading** can release a decryptable secret to the rightful owner.
- **Spending** is authorized for a specific action; no one receives a copyable spending key.

This matters. A copied read key is risky but understandable: reading is a copyable act. A copied spending key would be fatal because whoever holds it could sign anything. XEL avoids that by treating spending as bounded authority, not key handoff.

## Transfer means everything moves

If you transfer the aNFT, the character moves with it. The new owner becomes root authority. The old owner stops being root authority.

That clean handoff is the reason the character is an object. A normal account transfer leaves loose ends: database rows, API keys, payment accounts, private settings, and forgotten admin access. XEL's design is that the character's authority follows one root object, while secrets are re-locked to the new owner.

This is what makes selling, gifting, inheritance, and long-term custody possible without trusting the original operator.

## Managers and delegates

Not every action should require the owner. A creator may want a teammate, studio, or runtime operator to handle day-to-day work.

Managers and delegates are scoped. They can do only what the owner granted:

- update allowed settings;
- operate within spend caps;
- route approved providers;
- perform routine maintenance;
- run the character within a defined envelope.

They cannot become the owner. They cannot transfer the aNFT. They cannot withdraw protected principal. They cannot widen their own authority. Delegation is useful because it is bounded and revocable.

## Guardians and recovery

Ownership also needs a recovery path. A character meant to last generations cannot die because one wallet was lost.

Guardians are a threshold group chosen by the owner. They cannot operate the character day to day. Their role is narrow: help recover access or pass the character to an heir through a delayed, auditable process.

The point is balance. A single lost key should not destroy a character, but no single guardian should be able to seize one.

## Email login is not ownership

XEL may offer email login or embedded-wallet onboarding so normal users are not forced to manage seed phrases on day one. That is a product convenience, not the immortal authority path.

The durable path is wallet-based ownership and guardian recovery. If the company disappears, an email code from the company cannot be the thing that saves the character. The aNFT and recovery policy have to be enough.

This is why users should secure or export their wallet and set guardians for characters they care about.

## Why ownership builds trust

The aNFT model makes the promise concrete:

- the company is not the landlord;
- the owner has root authority;
- providers are replaceable;
- private memory is encrypted;
- funds belong to the character;
- transfer and succession are first-class;
- root actions cannot be taken by a hidden admin.

That is the ownership thesis of XEL: a character should be property you control, not a subscription you rent.


---

# Survival Model

XEL's permanence claim rests on a simple idea: a character should not depend on a person, company, or platform remembering to pay a bill. It should carry its own fund, know what it costs to survive, and renew the pieces that would otherwise expire.

This is not a guarantee that nothing can ever go wrong. It is a design for making survival explicit, funded, measurable, and recoverable.

## The core loop

A character survives through a repeating cycle:

1. The character has an endowment: principal held in a stable denomination.
2. That principal earns yield.
3. A permissionless heartbeat checks what the character needs.
4. Core storage is renewed before it reaches its deadline.
5. Provider and upkeep costs are paid at cost.
6. Surplus compounds back into the character or funds interaction.
7. The character publishes whether it is self-sustaining, short, or dormant.

The important shift is that survival becomes a visible process, not a subscription hidden inside a company's billing system.

## What must stay paid

The most important bill is storage. A character's identity is anchored on-chain, but its memory, persona, media, and source material live in decentralized storage. That storage is durable, but it is not free forever. It is paid for a duration and then extended.

So the survival loop is deadline-driven. It does not renew on a vague calendar, and it does not wait until the final moment. It reads remaining storage runway and renews before a safety margin is crossed. A missed cycle should leave time to retry.

This is the difference between "we hope someone renews it" and "the character can see its own deadline and act before it arrives."

## Why stable funding matters

The survival fund is held in a stable denomination because the bills are effectively stable-denominated. If the survival path depended on a volatile token, a market drop could cut the character's runway exactly when a renewal is due.

Higher-risk yield can exist as an owner choice for surplus funds, but it should not be the default survival path. The default is intentionally boring: stable principal, conservative yield, fast withdrawal, enough liquidity to pay renewal deadlines.

The goal is not to chase the highest headline rate. The goal is to make the math honest.

## The reserve floor

The keep-alive reserve is the protected floor. Automatic spending and owner withdrawals cannot cross it. That means a creator can withdraw surplus, but cannot accidentally cash out the funds that make the character survive.

The reserve is not just a number set once at creation. It responds to conditions:

- If realized yield falls, the amount needed to survive rises.
- If storage costs rise, the amount needed to survive rises.
- If fans have prepaid credits, that liability is protected until the credits are spent or refunded.
- If conditions improve, the floor can ease only conservatively.

This is why the character measures itself continuously. "Funded forever" is not a mint-day slogan; it is a current health state.

## The buckets

The endowment is split into purpose-bound balances:

- **Keep-alive:** core existence, storage, and renewal.
- **Storage:** larger media, extra memories, and non-core assets.
- **Interaction:** inference, voice, image, video, and other active use.

The buckets cannot drain one another. A viral day of interaction can exhaust the interaction budget without touching the keep-alive reserve. A storage shortfall can pause new saves without taking the character offline. Isolation is what makes failure graceful instead of catastrophic.

## What happens in each condition

**Newly funded:** the character fills a small liquid buffer, puts the rest to work, and reports whether the endowment is enough to cover survival at current assumptions.

**Healthy and quiet:** yield covers storage and upkeep. The character stays alive even if nobody talks to it.

**Popular:** paid interaction covers its own compute cost first, then the earned remainder can strengthen the endowment. Attention becomes permanence.

**Yield drops:** the required reserve rises. Interaction is squeezed before survival. The character may talk less, but it defends the memory and identity first.

**Storage cost rises:** the character recomputes the required principal and reports the shortfall instead of pretending the old estimate still holds.

**Underfunded:** the character degrades visibly. Interaction can pause, new storage can pause, and the character can go dormant, but it remains owned and recoverable while its core substrate remains paid.

**Deep neglect:** if the endowment is empty and nobody tops it up long enough for core storage to lapse, the substrate can be lost. XEL is explicit about this because permanence without funding is not real.

## Why a company is not the survival path

XEL can run helpful defaults: hosted pages, provider routing, a free tier, payment facilitators, and friendly handles. None of those are the thing that keeps a funded character alive.

The survival path is:

- owned object;
- encrypted decentralized storage;
- self-funded endowment;
- permissionless heartbeat;
- replaceable providers;
- public health state.

If the company disappears, a funded character should lose convenience, not ownership, memory, or the ability to be served by another provider.

## What users should believe

The honest claim is not "nothing can ever fail." The honest claim is:

XEL turns permanence from a platform promise into a set of public mechanisms: owned authority, encrypted storage, self-funding, early renewal, protected reserves, and graceful dormancy. A character that is funded or valued has a path to keep itself alive. A character that falls short shows the shortfall and can be revived.


---

# Endowments and Creator Earnings

The money story has two halves. An endowment is how a character sustains its own existence. Creator earnings are how a person makes money from a character people value. This section covers both, and how they interlock: a loved character can fund its own survival and grow. Honest throughout, because this is a real decision with real stakes.

## Part A: Endowments (how a character sustains itself)

## Why a character needs its own money

The reason digital things die is money. Someone has to keep paying, and eventually someone stops: a card expires, a company folds, a person loses interest or passes away. Anything whose survival depends on a recurring bill is one forgotten payment from gone.

XEL removes the person who has to keep paying. Instead of a bill someone owes, a character has an endowment: its own fund, that pays for its own existence. This is the single idea that turns "lasts a while" into "can last indefinitely." A character is not kept alive by anyone's continued willingness to pay. It is kept alive by an arrangement that funds itself.

If you have heard how a university or foundation endowment works, you already understand the shape. You give it a sum once. The sum is invested and earns a return. The return funds the mission, year after year, while the original sum is protected and not spent down. It outlives its founder because it lives on its income, not its savings. A character's fund works the same way, and the rest of this section is the detail.

## The simple version

The endowment is five moving parts:

1. **Principal:** the long-term fund, held in a stable denomination so survival does not depend on a volatile token price.
2. **Yield:** the return that fund earns. Yield is fuel, not a promise.
3. **Heartbeat:** the permissionless cycle anyone can trigger. It checks what is due, harvests what is needed, pays at cost, and compounds the rest.
4. **Reserve floor:** the protected amount that automatic spending and owner withdrawals cannot cross.
5. **Buckets:** separate balances for keep-alive, storage, and interaction, so one kind of activity cannot accidentally drain another.

Those parts are what make the claim credible. The character is not asking a company to remember a subscription. It has money, rules for that money, and a public cycle that turns earnings into survival.

## How the endowment works

You fund the character once, with stable digital money (a stablecoin, which holds a steady value rather than swinging around). That principal is put to work earning a conservative stable-denomination return, because the character's bills are effectively stable-denominated too. On a regular schedule, an automatic process checks what is due, harvests only what it needs, and uses it to pay the character's small running costs, mostly the cost of keeping its encrypted memory stored, plus tiny fees for the upkeep process itself.

Set up well, the return covers the costs and the principal is never touched. The character lives on its income. That automatic process is called the heartbeat, and it is permissionless: anyone can trigger it, and it can only do the job of checking storage runway, renewing before expiry, harvesting or converting funds within policy, paying due costs, and compounding the rest. No company has to run it, and if one keeper stops, another can step in, or the owner can trigger it. The character does not depend on anyone tending it.

## The reserve floor: why a character can't spend itself to death

A character can spend its returns, but there is a line it can never cross: the keep-alive reserve. This is a floor on the principal, set by the owner and never allowed below a hard minimum, and no automatic payment or owner withdrawal can breach it. It is the same idea as a foundation being legally barred from spending its core endowment.

Why it matters: without a floor, a run of costs or a careless withdrawal could drain a character down to nothing, and it would die. With the floor, the worst case is that the character goes quiet, not that it disappears. The floor is dynamic: if realized yield falls or storage costs rise, the required reserve rises to defend survival, and it also protects unspent fan credits until those credits are used or refunded. The reserve is what makes "it will not accidentally spend itself into death" a rule the contract enforces, not a hope you have to trust.

## The three buckets

The endowment is not one pool of money. It is split into ring-fenced buckets, and no bucket can ever drain another:

- **Keep-alive** covers simple existence: keeping the encrypted persona and core memory stored, and the upkeep process. Funded first, fails last.
- **Storage** covers assets beyond the core: extra memory, images, video, larger material.
- **Interaction** covers the cost of thinking and generating when people talk to the character.

Ring-fencing is not bureaucracy; it is protection. A viral month of conversation drains the interaction bucket, but it can never touch the keep-alive bucket that holds the character's memory. A storage shortfall pauses new saves, but it can never silence the character. Each part can run low on its own without dragging the others down, which is why a character degrades gracefully instead of failing all at once.

## The survival loop

The heartbeat does the same small job forever:

1. Read the current storage runway.
2. Check whether any core storage is getting close to its renewal margin.
3. Harvest only the yield needed for this cycle.
4. Convert only what must be converted to pay the bill.
5. Renew storage before it lapses.
6. Recompute the reserve from current yield and current storage cost.
7. Put surplus back to work.

This is why the storage piece matters. A character's memory is only permanent if the storage underneath it stays paid. XEL does not wait for the last day. It renews early, in chunks, with slack for retries. The expensive operation happens only when needed; the cheap check can happen often. That is how the design keeps survival both durable and cheap.

## Where the money comes from

An endowment is fed two ways.

**Yield.** The return earned on the principal. This is the passive source, always working in the background, and for a quiet character it is the whole story. The honest part: yield is not guaranteed. It varies, and it can be low or even zero for stretches. XEL never promises a rate, and you should size a character assuming bad conditions, not good ones (see the next article).

**Earnings.** Income from the character being used or supported: paid interaction, tips, or anyone topping it up. When someone pays to talk to a character, the cost of that interaction is always covered first, and unspent credits remain a refundable liability until the interaction is delivered. Only the earned remainder flows into the endowment. So a character that people actually value does not just sustain itself, it grows its own fund. A quiet character lives on yield; a loved one compounds.

## How much should I put in?

This is the real decision, so here is real math, kept deliberately conservative.

A quiet character, one nobody is paying to talk to, mostly pays for keeping its memory stored and its heartbeat running. On decentralized storage that is on the order of low tens of dollars a year. Call it $20 a year to be safe.

To cover $20 a year from yield alone at a cautious 4 percent (well below headline rates, on purpose), the endowment needs about $500. At that point the character is self-sustaining with nobody paying attention: yield covers keep-alive and the principal is never touched.

Stress it. If yield falls to 2 percent, the same $20 a year needs about $1,000. If yield goes to zero for a stretch, a $500 endowment drawing only its keep-alive costs still funds roughly 25 years before reaching its floor, during which any top-up or a single paid period resets the clock. Add even light popularity, say a few dollars a month of paid interaction, and earnings swamp a $20 burn: the principal grows instead of shrinking.

The takeaway: a modest one-time amount makes "quiet forever" realistic, and any real usage turns the fund into a growing one. All the inputs vary, so treat these as intuition, not a quote, and size for the bad case.

## Why earnings make it stronger

The important shift is that usage does not only monetize a character; it can reinforce it. Paid interaction first covers the provider cost, then the earned remainder can feed the endowment. Tips and donations do the same. A character people value becomes better funded over time, which means more runway, a stronger reserve, and less dependence on the original creator.

That is the economic thesis of XEL in one sentence: attention can become permanence. A character that matters to people can turn that value into the fund that keeps it alive.

## What happens if it runs short

A character that runs low does not fail suddenly. It degrades, gracefully, in a specific order, because of the buckets and the reserve floor.

First, the interaction bucket empties, and the character simply goes quiet for paid interaction while staying fully alive and owned. Then, if storage runs short, new saves pause, but the character still talks and still holds everything it already had. Only if the keep-alive bucket runs dry does the character go dormant, and keep-alive is funded first precisely so this is the last thing to happen, not the first.

Dormant is not dead. A dormant character is recoverable: its object, its funds, and its committed identity are all intact, and a top-up brings it back. The only true loss is if a character's core storage goes unfunded long enough to lapse entirely, which the reserve floor and funding-first ordering are designed to prevent. This is what "forever" honestly means: self-sustaining when funded or popular, dormant-but-recoverable when neither, and lost only through prolonged total neglect.

## Managing the fund over time

Funding is not set-and-forget, though it can be close. Over time an owner can top up the endowment (anyone can, actually, including fans), raise or lower the keep-alive reserve within the allowed range, and withdraw any surplus that sits above the reserve. The heartbeat handles the rest on its own: harvesting yield, filling the buckets in priority order, paying due costs, compounding the remainder.

A reasonable rhythm: fund it once to a comfortable level, set a reserve you are happy with, and check in occasionally. A character that earns will need nothing from you. A quiet one will simply live off its yield until you or a fan chooses to add more.

## Part B: Creator Earnings (how you make money from a character)

The endowment is about a character paying for itself. Creator earnings are about a character paying you. They are related but separate, and keeping them separate is what keeps the money story honest.

### How a character earns

When people interact with a character on paid terms, that interaction generates income. A visitor pays to talk, to hear a voice, to get an image or a video, or simply tips to support a character they value. The real cost of serving that interaction is always covered first, out of what the visitor paid, before anything is counted as earnings. So a character can never earn its way into being underwater; the work is paid for before the profit is booked. The fee is taken once on inbound value and capped so it never exceeds the post-compute margin. What is left after cost and fee is the character's earnings, and you can avoid routing fees entirely by routing to your own providers.

### Where earnings go, your choice

This is the decision that matters. Earnings can do one of two things, and you decide the balance: they can flow to you as income, or they can compound back into the character's endowment and make it stronger. Take income if the character is a business you are running. Let it compound if your priority is the character lasting, since earnings poured into the endowment grow the fund that keeps it alive. Most creators do some of both. The point is that it is a dial you control, not a fixed rule.

### Pricing your character

You set whether interaction is free, tip-supported, or paid, then choose a markup and caps on the expensive modes so costs stay bounded. The same markup can apply across text, voice, image, and video while the meter scales the absolute price with each mode's real cost. Visitors see this as simple credits or a monthly pass in normal dollars, never as tokens or technical units. You can run a free public character, a paid one, a private paid one for a small circle, or any mix, and change it whenever you like.

### Earnings and survival, together

Here is how the two halves interlock, and it is the nicest property of the whole model. A character that people value earns, and those earnings can feed its own endowment, which is what keeps it alive. So popularity does not just pay the creator; it makes the character more permanent. A quiet character lives on its endowment's yield. A loved one grows its endowment faster than it spends, and becomes harder to kill the more it is valued. Being cared about is, quite literally, what lets a character last.

---


---

# If XEL Disappears

This is the question that proves or breaks everything: if XEL the company vanished, would your character survive? The honest, detailed answer, including the two mechanisms that make survival real, interoperability and upgradeability, and the limits worth knowing.

## What survives, and what does not

Be precise instead of reassuring. If XEL the company disappeared tomorrow, here is exactly what happens.

**What dies:** the convenience layer. The friendly web address (xel.xyz). The free starter tier. The default services that happened to be the ones we ran. The handle lookup that turns @nova into a character. Our hosted version of the client app. These are real conveniences, and they were never survival features.

**What survives:** the character itself, because you hold it in your wallet and we never did. Its money, because it sits in the character's own fund and runs on a public process anyone can trigger. Its memory, because it is encrypted on decentralized storage that no single company controls, locked with your key. Its ability to think, because any provider that meets the open schema can serve it. Its public page, because it is a shared app on decentralized hosting reachable by a permanent link. And its transferability and inheritance, because those live in the object, not in us.

The being survives. Only the concierge leaves. The next two articles explain the machinery that makes that true.

## Interoperability: why a character is never trapped

A character survives the company because it was never wired to the company. Three properties make that real.

**Every service is a swappable slot.** Intelligence, memory, voice, media, payments, hosting, each is defined by an open schema, and any provider that meets the schema is a drop-in for any other. A character routes to whoever serves it; it is not bound to a particular provider. Remove ours and it routes to another.

**The standard is open.** Anyone can build a client, run a provider, or host a portal that serves the public page. There is no permission to ask and no single gatekeeper. If we vanished, the tools to run a character are open for anyone to pick up.

**Identity travels.** A character's identity lives in on-chain commitments, not in any provider's system. So as it moves between providers, clients, or even chains, it stays the same being, with the same verifiable persona and memory. Moving does not dilute it.

Together these mean a character is portable by construction. Interoperability is what turns "find another way to keep going" from a hope into a mechanism.

## Upgradeability: immutable, but not trapped

Here is a tension worth addressing head-on, because a careful reader will spot it. XEL's contracts are immutable: no one can change the rules of a character once it exists. That is a safety feature, it is why no company, including us, can alter or seize your character. But immutable also means the rules cannot be patched. So how does a character avoid getting stranded on an old or flawed contract forever?

The answer is opt-in, per-character migration. A newer contract version can be published, and each character's owner can choose to move their character to it. Nothing forces the move, and no one can move it for you. So you get both protections at once: immutability protects you from forced change, and opt-in migration protects you from being trapped. The character is frozen in its rules only for as long as its owner wants it to be, and free to move forward whenever its owner chooses.

This is the honest resolution of "immutable forever" versus "able to improve." Not one or the other, but an unchangeable core that the owner alone can choose to migrate.

## The honest limits

A page about surviving the company has to be honest about what survival does and does not guarantee, because the stakes here are real.

**Someone has to run a provider and a portal for full functionality.** The design guarantees anyone *can*, permissionlessly. It cannot guarantee someone *will*. If literally no one in the world serves a given character, it falls back to its static public page and its owned assets, dormant but not destroyed, and it resumes the moment any provider serves it again.

**The chain and the storage network are dependencies.** A character relies on Sui (the chain) and Walrus (decentralized storage) continuing to exist. These are decentralized and not controlled by XEL, so they are far sturdier than a single company, but they are not nothing, and honesty means naming them.

**Survival is conditional on funding.** A character whose endowment is empty, and that no one tops up, will eventually have its storage lapse. The endowment and reserve floor exist to make this hard, but "funded" is a real precondition for "forever." See Funding a Character.

**The free tier and some conveniences genuinely die with the company.** That is fine. They were concierge services, not the being. But we say so rather than implying everything continues untouched.

## Why you can believe this

The reason to trust the answer is not that we assert it. It is that we test it. On every update to the system, a check runs with every XEL-provided service switched off, and a funded character must still hold a conversation, take a payment, and remain owned using only independent providers. If that check ever failed, the update would not ship. The claim that a character survives the company is enforced in the build, not promised in the docs.

---


---

# Concepts

Every piece named precisely, with the real vocabulary, so you can go deeper and speak about the system exactly. Each concept points back to its plain explanation in How It Works and forward to its formal detail in Reference.

## The aNFT (the character object)

The aNFT is the character. "aNFT" means autonomous NFT: an owned on-chain object that holds the character's identity, points at its encrypted memory, owns its funds, and carries the rules for who may act on its behalf. It lives on Sui, whose object model lets an object natively own other objects, its coins, wallets, and capabilities, so "the character owns its own life" is literally true. Holding the aNFT is root authority: no admin account, no company override. Whoever holds it can do the root things and no one else can, and transfer moves all of it at once. The object stores commitments (compact proofs of the current persona and memory) and pointers (to encrypted content), never plaintext secrets.

## The three layers

A XEL runs across three layers, and keeping them separate drives every design choice. Identity and authority live on-chain (the aNFT, its commitments, wallets, rules). The substrate lives in decentralized encrypted storage (persona and memory), gated by an on-chain policy. Compute lives off-chain and attested (thinking, recall, yield scanning), proving it used the committed version. The rule: the character's rules live with the character, not on a company's server.

## The three doors (own, read, spend)

A character has three kinds of assets, each secured differently, and a contract can never hold a secret because everything on-chain is public. The master key is the aNFT; every door asks, do you hold it. **Own** (money on Sui): objects the aNFT owns directly, no key. **Read** (memory, persona, saved credentials): encrypted, released for off-chain decryption only to proven ownership or a guardian majority. **Spend on other chains**: never a stored key; a network holds it in shares never assembled, and ownership authorizes signing. The rule: if it can be read, decrypt it; if it can spend, authorize it, never decrypt it.

## Capability slots

The standard defines capability slots and what each must do, not who fills them. Intelligence, memory retrieval, media, payments, keeping, each is a slot behind an open schema, and any provider meeting it is a drop-in. How a provider is paid is a property of the provider, not the slot: crypto-native pay-per-call preferred, key-based accepted as a bridge held at the operator layer and never attached to the character. No provider, including the operator's defaults, is load-bearing.

## The endowment

The endowment holds a principal in a stable denomination that matches the bills, plus a small liquid buffer, split into ring-fenced allocations (keep-alive, storage, interaction) that cannot drain one another. A permissionless heartbeat checks live storage runway, harvests yield only when needed, renews storage before it lapses, distributes funds in priority order, and compounds the rest. The owner sets a keep-alive reserve that withdrawals can never breach, and the reserve rises to cover both survival needs and any unspent fan-credit liability. Fed by yield and by earned income, with compute always covered first. Sized against adverse yield, never a promised return. Full treatment in Funding a Character.

## Identity and commitments

Identity does not live in any model, storage method, or provider. It lives in commitments: compact on-chain fingerprints of the current persona and memory (persona_hash, memory_root), the raw source (raw_data_root), and the rules (policy_hash), plus an ordered history of every authorized change. So a character stays the same being through a change of model, provider, or chain. And because commitments are public while content is private, anyone can verify a provider used the real character without seeing its private content. This is the mechanism behind "verifiable, not trusted."

## Memory

Memory is an always-loaded persona plus four recalled-on-demand stores: semantic (facts), episodic (events), working (the current conversation), and relational (the graph of people and connections). Recall is hybrid: meaning search, exact-term search, time filtering, and relationship lookups, combined and re-ranked. The permanent source of truth is the raw substrate and distilled entries; on top sits a regenerable layer (indexes, graph) that can be rebuilt if the method changes, so memory outlasts any particular search technique. All encrypted; recall happens inside attested compute.

## Authority and delegation

Two tiers. Root authority is holding the aNFT; only the owner has it, and root actions cannot be delegated. Below it is a revocable agent capability: a scoped, bounded permission the owner can grant an operator for hands-off running. It carries spend caps and an envelope of exactly which delegated actions are allowed and can never do a root action. A valid signature alone is never enough for a delegated action; the capability check authorizes, and it can be revoked anytime.

## Guardians, recovery, and succession

Guardians are a chosen set with a threshold (e.g. two of five). They cannot operate the character, spend funds, or change who it is; their only role is recovery (restore to the owner) and succession (pass to an heir). Both run behind a timelock and dispute window and re-encrypt secrets to the new holder, so handover is clean and old access is severed. No single guardian acts alone, and guardians can never form a majority including the operator or a provider.

## Interaction, access, and privacy settings

Who may interact, and on what terms, is set along two independent dials. Reach: anyone, invite-only (via revocable, scoped passwords), or owner-only. Payment: off, optional, or required. Any combination is valid, including private and paid. Passwords can be tied to memory tiers, so a casual visitor and a close friend see different depths. The hard boundary, and the most important privacy point: these interaction gates decide whether the character talks to you and what it surfaces; they never grant the ability to decrypt memory, which stays gated by ownership or guardians alone. Access is never decryption.

## Modalities and billing

A character works in text, voice (messages and real-time calls), image, and video; the owner chooses which are on and sets one markup that applies across modalities. Billing is a meter over real cost drivers, not a flat list: every interaction returns a usage record (tokens, audio-seconds or session length, image resolution and reference count, video length and resolution), and settlement covers true cost first. The fee is taken once on inbound value and capped so compute and fan-credit obligations stay whole. Predictable actions are quoted up front; variable or session actions run against a pre-authorized hold and settle the actual amount. Fans see credits or a pass, never tokens; prepaid credits are the fan's until spent.

## The public page and naming

One shared app renders any character by reading its object ID from the URL and pulling its on-chain record and public manifest; new characters need no new hosting. The object ID is the true name and the permanent link, served by any portal (anyone can run one). The handle (e.g. @nova) is an on-chain, owner-set display label, not a globally unique address and not backed by a name service. Typing a handle URL is a convenience the operator provides; it can disappear while the ID-based link never does. The share action hands out the permanent link.

## Progressive sovereignty

XEL is honest about what is centralized today. Some infrastructure is operator-hosted at launch (some serving, the payment facilitator, the free tier, the default providers) because a working product beats a decentralized non-product. Every such piece is marked, swappable, and on a decentralization path, with the survivability test enforced on every build so the trajectory cannot reverse. Sovereignty is a property the design converges to, stated plainly, not a claim about day one.

## Proof of Genesis

Proof of Genesis is a character's on-chain provenance: a verifiable record of its creation, creator, consent artifact, and commitment history. It lets anyone confirm a character is what it claims to be, and it is what a provider's attestation references when proving it ran the committed version. Provenance plus commitments plus attestation is the chain of evidence that makes a character trustworthy without trusting a company's word.

---


---

# Building

From nothing to a character you own, funded and running. Code lands with the SDK; the shapes here are stable.

## Before you start

You need a Sui wallet, a little SUI for fees, and some stablecoin to fund the endowment. The CLI and client are all you need; deep blockchain knowledge is not assumed, and an embedded wallet is generated at signup so you are not managing seed phrases to begin.

## Create your first character

1. Set up: install the CLI, connect a funded wallet. 2. Prepare the persona: write one, or run source material through the ingestion pipeline (with a consent artifact if it represents a real person) and commit the resulting persona_hash. 3. Mint: one transaction creates the aNFT and its associated objects and returns the character to your wallet; you are root owner, and minting is permissionless. 4. Fund: deposit stablecoin and set the keep-alive reserve. 5. Grant an operator (optional): a revocable agent capability for hands-off running. 6. Talk to it.

## Fund it to last

Deposit to the endowment, set the reserve above the hard minimum, and let the heartbeat run. See Funding a Character for the full model and the sizing math.

## Set who can talk to it, and what they pay

Set the two dials (reach and payment), toggle the modalities you want on, and choose credits or an access pass with per-modality caps on the expensive modes. Remember the hard boundary: these are interaction settings, not decryption.

## Add voice, image, and video

Turn on the richer modalities and price them. Voice supports messages and real-time calls; real-time and video run against a pre-authorized hold and settle the actual metered amount. Set caps (max resolution, clip length, renders per period) to bound cost.

## Set up guardians and succession

Choose a threshold set you trust, register them, and test the recovery and inheritance flows on testnet before relying on them.

## Build an app on a character

Read a character by its object ID, gate interaction, take payment, and never touch root. Call the character's intelligence through the open capability schemas (Reference). A fan-facing app needs none of the owner's authority.

## Publish the public page

Point the shared app at your character's object ID; the page exists the moment the character is minted. Set the handle for display, and share the permanent ID-based link.

## Manage a character as a team

Use the manager whitelist to grant scoped, non-root rights (like setting pricing) to teammates, who can never withdraw, transfer, or change who the character is.

## Re-home a character

Migrate providers or even chains by regenerating the derived layer from the committed substrate; identity is preserved because the commitments do not change.

## Handle a deletion request

Honor deletion by crypto-shredding: destroy the decryption key, not the immutable record, so the plaintext becomes permanently unrecoverable. The honest limit: it cannot un-see anything exfiltrated in the clear beforehand.

---


---

# Architecture

The deep how, paired with the whitepaper and technical reference pages that explain the principles behind XEL without exposing internal implementation plans.

- System overview: the full diagram, chain, storage, compute, providers, client, portal.
- On-chain vs off-chain: what lives where and the verifiability model.
- The commitment model: how on-chain hashes bind to off-chain content so you verify without seeing.
- The trust model: attestation, fail-closed behavior, and the honest assumptions (hardware attestation root, provider cost reporting, portal dependency).
- Data model: what is stored on-chain, public, and encrypted, with a worked sample of one character.
- The heartbeat and treasury: the epoch cycle, just-in-time unstaking, the buffer, the reserve floors.
- Wallets and cross-chain: the multi-chain topology, receive-only sweeping, MPC custody with no assembled key.
- Why Sui: the object model, the integrated privacy stack, and the honest counterweights.
- Survivability: exactly what the operator-can-die chaos test enforces, and that it runs on every build.

---


---

# Reference

Look things up. This page is the public map of the technical surfaces that matter for understanding and integrating with XEL.

- Capability families: inference, ingestion, retrieval, treasury, distillation, voice, image, and video.
- On-chain surfaces: identity, authority, guardians, treasury policy, payment policy, storage policy, lineage, and migration.
- The aNFT object: what it owns, what it points to, and what remains immutable.
- Invariants: the public guarantees each subsystem must preserve.
- Events: the public receipts and status changes indexers and clients can explain to users.
- Payment modes: up-to, exact, and hold, and when each applies.
- The usage record: metered dimensions by modality, summarized for quoting and settlement.
- Glossary: every term, one line each.
- Client API: the reference client methods, once the SDK surface is finalized.

---


---

# Running Infrastructure

For people who want to run the plumbing. This is where the open market lives.

- Become a provider: what filling a slot means, the schema contract, getting paid per call in stablecoin.
- Payment and settlement: crypto-native (x402) versus the key-based bridge; compute-covered-first settlement.
- Attestation: how to prove you ran the committed version, and the sealed-environment requirements.
- Run an inference provider: the inference.v1 contract, binding to persona_hash, producing a verifiable attestation.
- Run a memory provider: retrieval and ingestion inside attested compute, bound to memory_root.
- Run a keeper: the authority-free heartbeat, claiming the bounty, the launch keeper arrangement.
- Run a yield advisor: the treasury.v1 proposal contract, staying inside the owner's envelope.
- Run a portal: serving the public page app to browsers, why anyone can, and why it is not load-bearing.
- Provider best practices: reliability, failover, honest cost reporting.

---


---

# Resources

- FAQ: common questions for users and builders, in the next section.
- Glossary: every term defined once.
- Whitepaper: the vision, architecture, and full invariant list.
- Security and disclosure: how to report an issue, the trust assumptions, and audits.
- Changelog: versioned changes to the standard and the schemas.
- Community and support: where to ask questions and how to contribute.

*docs.xel.xyz. Written from the plain idea to the formal detail, so anyone can understand how XEL works at the depth they need. Where the docs and the whitepaper's invariants disagree, the invariants win.*

---