People That Live Forever

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 Living Character: 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 Living Character 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.
• Verifiable continuity. Identity rests on commitments (origin, persona, memory, policy) that can be proven and versioned over time.
• 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. Built to transfer, inherit, and outlive its originator.
• Provider independence. Every outside service is a swappable slot; no single provider is load-bearing.
• Interoperable & upgradable. Not tied to any one chain, platform, or standard; any component can be replaced over time without breaking identity.

This is an application layer for persistent people, not a general agent framework. Generic agent identity, discovery, reputation, and payment are being standardized elsewhere. A Living Character is built to interoperate with those rails, not replace them — what it adds is persistent human persona, private memory, consent, continuity, and self-funding.

What We're Building

We are building something new, on our own foundation, that speaks the standards others are setting.

• New, not a fork. The character's core is ours: our object, our keys, our endowment, our consent, our succession.
• We use others' parts, but never stand on them. Storage, compute, and inference plug into swappable slots. If any one goes away, the character does not.
• We interoperate, we do not depend. Compatible with on-chain agent standards, but a character lives on our sovereign base, not on anyone else's platform.

New foundation, borrowed parts, shared language.

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 few voices reach everyone at once. Local languages fade. Traditions thin out.

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 taken down, that story is gone. Not moved. Gone.

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. What feels permanent is only rented, and the lease can end at any time.

This is felt most sharply with people. Families now try to preserve someone they love as a presence they can still talk to. But those recreations live on platforms too. When the company shuts down or changes its mind, the person dies a second time, this time at a company's discretion.

This paper specifies the answer: the Living Character. A persistent digital being anchored on-chain, owned by a person and inheritable by their heirs, with encrypted private memory, consented representation, bounded autonomy, and the ability to fund itself. The missing piece was never better imitation — it is sovereignty and permanence.

The Problem

• Fragile ownership. Rights sit in platform terms. On-chain "ownership" is usually a bare token pointer.
• No way to preserve presence. Voice, personality, and memory are lost when a person dies.
• No permanence or sovereignty. Characters lean on centralized platforms and single-vendor services. When the service dies, the character dies.
• No survivable economics. No licensing, royalties, or funding that outlives the creator.

Vision

The standard enables 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 quietly delete, rewrite, or censor.

Permanence

"Live forever" is the aspiration, not a literal guarantee. Permanence is defined per layer:

• Origin and identity (strongest). Proof of Genesis and the commitment history are immutable on-chain. This can't be destroyed.
• Data. Memory persists on decentralized storage under auto-extended retention, funded by the endowment (§10).
• Availability (weakest). Holding new conversations depends on funding and a live provider. An underfunded character pauses — it doesn't lose its self, and it can be reactivated.

So a character's permanence comes down to its endowment and the health of the open provider market, not a promise that one company keeps it alive.

Design Principles & Capability Slots

The architecture is a set of capability slots, not a fixed stack. Each slot is defined by what it must do, not by which vendor fills it. Any provider that meets a slot's requirements is a drop-in replacement. Every external-service slot must accept programmatic crypto payments, be permissionlessly joinable, and be verifiable and decentralized.

The first three rows are already decentralized. The custody/gas slot is solved by default (self-custody wallet). The one slot whose permissionless path is still genuinely open is the keeper, since no chain offers native scheduling and no incentivized keeper network is live yet. That is the priority build work. Concrete systems filling each slot are in Appendix E.

5.2 Why Sui Is the Default Home Chain

The standard is chain-agnostic, but the reference implementation uses Sui — because the hard, differentiating parts map directly onto Sui primitives. Ownership, delegation, and an object that owns other objects are the native object model rather than a bolted-on pattern. Encrypted memory, on-chain-gated decryption, and attested private compute exist as one integrated stack (Walrus + Seal + Nautilus). The parts where Sui is merely competitive (yield, liquidity) are commodity layers the character reaches across chains anyway. The home chain remains an implementation choice; identity lives in the commitments.

5.3 The Open Standard vs. GEN's Role

• GEN never holds ownership. The user holds the aNFT's root authority at all times. GEN, when used, holds only a revocable, scoped agent capability — it can never withdraw principal, transfer the character, change the rules, or bridge principal out.
• One model, not two modes. The user can hold the aNFT in any wallet and still grant GEN the agent capability so operation is hands-off. GEN is optional in every configuration.
• Trust comes from enforcement, proven by open source. On-chain contracts remove GEN's power to rug; open-sourcing them proves it was removed.

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, and both fully mutable.

Memory and knowledge: mutable, provenance-stamped.

Built from ingested material, stored encrypted on decentralized storage, each item stamped with provenance (source, timestamp, signature). Freely editable. Versioning is optional per set; when 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 directly, not computed from memory. Because persona is identity, it's versioned by default: each update records a new persona-hash, 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?"

Ingestion permissions: on-chain scope, off-chain credentials.

The standard keeps the authorization on-chain (which sources, what cadence, continue-after-death or not) so intent is explicit and inheritable. Raw access tokens stay off-chain, held by the ingestion provider and independently revocable. Social connections are never trapped inside GEN.

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 a verified estate, 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.

Authority: Ownership, Delegation, and the Two Tiers

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. The owner signs once to delegate, not once per action. The system separates the human-approval signer from the programmatic one, and they are never the same key.

• Owner signer (human). Approves owner-tier actions: withdraw/bridge principal, transfer the character, change policy, grant/revoke the delegate. Any standard wallet, including hardware.
• Delegate signer (programmatic). A separate, scoped, revocable key holding the agent capability, signing routine execution with no human tap. It can never perform owner-tier actions, because the contract checks the capability, not merely a valid signature.

Tier 1: Governance (always owner-signed) — anything that defines who the character is or what it may do. Tier 2: Execution (delegated via agent capability) — routine, already-authorized actions within caps. Revoking the agent capability is an instant kill switch.

8.1 Tiered Keys

Root (cold or guardian multisig) for identity and fund withdrawal; warm for routine governance; agent capability for execution within caps.

8.2 Circuit Breakers & Kill Switch

A moderation capability in the response loop, spend/rate circuit breakers that trip on anomalies, and a one-transaction pause (owner or guardian) that freezes inference and payments immediately. Nothing here should be unstoppable.

Keys, Secrets & Deletion

Wallet keys and secrets are encrypted and stored durably off-chain, with decryption governed by an on-chain access policy. The policy is deliberately not "current owner only":

• Master identity secret: guardian-recoverable, decryptable by owner OR an M-of-N guardian set. This is also the succession path.
• Spending keys: never persisted as long-lived plaintext — ephemeral, rotatable, authorized per-session under the agent capability.

Deletion via crypto-shredding. Personal data is encrypted; honoring a deletion request means destroying the key, not the blob. The immutable record stays; the plaintext becomes permanently unrecoverable.

Wallets, Payments & the Endowment Model

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.

Endowments, not checking accounts. A character funds itself as an endowment: principal sits in yield-bearing form 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.

10.1 Treasury Topology

One primary chain where principal concentrates and earns yield (default Sui). Other-chain wallets are receive-only and auto-sweep to primary above a threshold. Pay from primary, bridging a bounded amount out only when a bill must settle elsewhere. Bridging is the single most dangerous action — bounded on both ends with thresholds, per-bridge caps, tranching, and the most-audited bridge available.

10.2 Treasury Execution as Programmable Actions

The treasury is one programmable execution capability. Owner-signed is open-ended; delegated (agent capability) is bounded by owner-set policy (venue allowlist, per-tx and daily caps, max-slippage, transfers restricted to the character's own wallets). Bridging and withdrawing principal are always owner-signed.

10.3 Interaction Access: Paid and Password Gates

By default anyone can talk to a character for free, but the owner can gate interaction with paid interactions (inbound revenue to the endowment) and scoped passwords (revocable, per-group, tied to memory-access tiers). These gates control whether the character responds and which memories surface — they never grant the ability to decrypt. Decryption remains gated only by the on-chain access policy.

Capabilities & Providers

The standard is a versioned library of capability schemas — one canonical input/output contract per capability (inference.v1, ingestion.v1, retrieval.v1, and more). Any provider implementing a schema behind a standard payment endpoint is a drop-in for any other.

GEN's default provider offerings are narrow: serving (inference and relay), the payment facilitator on the home chain, and ingestion (social + document). Persona distillation must emit a disclosed fidelity assessment (coverage, consistency, optional human validation) — fidelity is disclosed, not assumed.

Compute, relay, and attested inference. The relay moves E2EE data; the attested-compute slot is where sensitive work happens, producing an on-chain-verifiable attestation binding output to the persona-hash. A TEE is a hardware trust assumption; the long-term successor is zkML.

Minting: Permissionless

Minting is not a call to GEN. It's a public mint function in the open-source aNFT package deployed on-chain — an ordinary transaction anyone can submit from any client, script, or explorer. GEN's minting UI is just the easiest place to do it, not a toll booth. Value capture comes from GEN's services, or an optional minimal protocol fee to a neutral treasury.

Lifecycle & Succession

States: created, active, dormant, reactivated, succession, archival. Succession is a primary feature, not an edge case. 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, and the existing agent capability keeps the character alive with no downtime. Heirs inherit an income-bearing, self-operating estate.

IP, Licensing & Rights: Lineage (Proposed)

Lineage is the rights layer: licenses are first-class on-chain objects (transferable, composable, verifiable); royalties from derivatives split automatically across endowment, creator/heirs, upstream IP holders, and protocol; composite IP (voice, likeness, writings, style) is licensable atomically; disputes route to an arbitration capability anchored to Proof of Genesis. Open questions: per-jurisdiction enforceability, likeness-consent verification, binding arbitration on-chain.

Security, Decentralization & the "GEN Can Die" Test

The primitives (ownership, memory, provenance, wallets) live on-chain and in decentralized storage and don't depend on GEN. 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

Roadmap

• Phase 1: Verified core (single-chain, creator-IP focus). aNFT object, Proof of Genesis, encrypted storage, commitments, inference.v1, agent capability, guardian recovery. Prove the GEN-can-die invariant.
• Phase 2: Economics and autonomy. Endowment funding, streaming payments, home-chain facilitator, ingestion + persona auto-update.
• Phase 3: Multi-chain and rights. AA-enforced caps, cross-facilitator settlement, rights layer v1, attested inference, schema governance.
• Phase 4: Maturity. An open ecosystem of endowed, rights-holding, provider-independent characters. Progressive decentralization of the standard itself.

Governance

The standard (contracts, reference client, schemas, SDKs) is open-source. Anyone can run a provider, a facilitator, or a client, or fork the whole thing — the ultimate guarantee that no single entity controls whether a digital being lives. The standard is fully governable without a token. A foundation-held governance token may be introduced later to progressively decentralize control, but would stay out of the character operating path: characters keep funding themselves in stablecoins, never in a token whose price their survival depends on.

Existing Approaches

Three broad approaches exist today: hosted persona apps (run on a company's servers), on-chain AI-agent standards (the closest to what we do), and autonomous agent platforms.

The primitive is not new — on-chain AI-agent standards already put an encrypted, owned, capable agent on-chain, and we adopt their secure-transfer-with-key-rotation pattern rather than reinvent it. 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.

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.

People That Live Forever.

Glossary

• aNFT: the on-chain object that is the character's root of identity and control.
• Proof of Genesis: immutable birth record (creator, timestamp, consent reference).
• persona-hash / memory-root / policy-hash: commitments to the current persona, memory index, and rules.
• agent capability: a scoped, capped, cancelable, expiring permission that lets the runtime act without a fresh owner signature.
• endowment: yield-bearing principal; the character spends only the yield.
• provider / facilitator / relay / keeper: swappable actors filling capability slots.
• attestation / TEE / zkML: proof a computation ran on the committed persona; hardware enclave; its cryptographic successor.
• crypto-shredding: honoring deletion by destroying the decryption key, not the data.
• fail closed: on any verification failure, the action aborts rather than proceeding.

Actors

Owner (holds the aNFT, full governance) · Creator/Subject (person represented, signs consent) · Guardian (M-of-N recovery + succession) · Heir · Provider · Facilitator · Relay operator · Keeper (future) · Client (runtime) · GEN (reference author + one optional provider, never required).

What Lives On-Chain vs Off-Chain

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.

Minimal Data Model

The object (aNFT) holds: id; genesis [immutable]; persona_hash, memory_root, raw_data_root, policy_hash [commitments]; lineage; encrypted_secrets; substrate_blobs [permanent]; derived_blobs [regenerable]; manifest, site; wallets, endowment; guardians, agent_cap_id, paused. Full Move structs in Appendix A/B; the canonical inference.v1 contract in Appendix D.

Core Flows

One chat turn (inference):

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

Any paid capability call must pass on-chain checks: not paused; capability belongs to this character; not expired; provider allowlisted; amount within per-call cap; daily cap not exceeded; per-capability budget not exceeded.

Invariants the Code Must Always Enforce

Forty invariants govern the system. The load-bearing ones:

1. No function changing 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.
3. Keys are never stored on-chain; addresses are receive-only; no long-lived plaintext spending key exists.
4. The master secret is unlockable by owner OR M-of-N guardians. Never owner-only.
5. An inference provider must run the committed persona-hash and echo it back; a mismatch is rejected.
6. The character must still answer, pay, and be ownable with all GEN services offline.
7. GEN never holds root authority and is never the guardian majority.
8. Deployed contracts are immutable with no upgrade authority; fixes ship as new versions the owner migrates to.
9. Even a fully hijacked model cannot exceed caps, pay a non-allowlisted provider, or move funds off the character's own wallets.
10. All verification failures fail closed.

Formal Model and Notation

Let H be a collision-resistant hash and Sig_x(m) a signature over m by key x. A Living Character is the tuple:

C = (G, Φ, Λ, S, A, F)

G   Proof of Genesis, immutable: (creator, timestamp, consent_ref)
Φ   commitments: h_p = H(persona), h_r = H(raw_data_root),
    h_m = H(memory_index), h_π = H(SpendPolicy ‖ provider_policy)
Λ   lineage: ordered list of commitment updates [c_0 … c_n]
S   off-chain encrypted state: substrate S_raw (permanent) +
    derived layer S_der (regenerable) + secrets
A   authority: owner O, guardian set Γ with threshold M, agent cap κ
F   funds: wallets {w_i} (receive-only) + endowment E

On-chain stores G, Φ, Λ, A, pointers into S, and F addresses. On-chain never stores keys or plaintext. The substrate S_raw is retained independently, so S_der can be discarded and regenerated under a new method without loss of identity.

Core Predicates

# Governance — mutating persona/policy/wallets/ownership/funds
valid(τ) ⇔ Sig_O(τ) verifies

# Spend authorization for amount a on capability k via provider p at 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 of the master identity secret
CanDecrypt(x) ⇔ isOwner(x) ∨ |{ g ∈ Γ : Sig_g verifies }| ≥ M

# Attestation acceptance — binds output to the committed persona
Accept(R) ⇔ VerifyTEE(att, h_p, I, R) = 1 ∧ echoed_h_p = committed_h_p

# Identity continuity — same being iff unbroken authorized lineage
SameBeing(C) ⇔ c_0 derives from G
             ∧ ∀ i>0 : c_i authorized by Sig_O ∨ InEnvelope(c_i, κ)
             ∧ current h_p = c_n

Identity survives model and provider swaps because it is defined over the commitment chain, not the runtime.

Algorithms

Algorithm 1 — Inference turn.

input:  character C, message msg
output: verified response R

1  ctx      ← Recall(C.memory, msg)         # layered hybrid recall (§32)
2  payload  ← Relay(Enc(ctx), C.h_p, msg)   # E2EE to attested compute
3  (R, att) ← Compute(payload)              # decrypt + infer in TEE, bound to h_p
4  assert Accept(R)                         # else retry / failover
5  cost     ← R.usage_cost
6  assert Auth(cost, "inference", provider, now())
7  Settle(provider, cost, scheme = upto)    # pay actual ≤ authorized max
8  Append(S_raw, Provenance(R)); Update(S_der)
9  return R

Succession (Alg 3) requires |Σ ∩ Γ| ≥ M, rotates ownership to the heir, re-encrypts the master secret, and keeps κ running for no downtime. Treasury rebalance (Alg 4) stays inside the owner's allowlist and caps and never transfers principal to an address outside the character's own wallets.

Economic Model

With principal P, net yield r, earned income E, and burn B, a character runs indefinitely when r·P + E ≥ B. The endowment is sized without assuming revenue: P* = B / r, treating earned income as upside, not the plan.

Economic honesty. 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. Sizing should assume an adverse-yield scenario, not a favorable one. This is design guidance, not investment advice.

Security Properties and Assumptions

• P1 Sovereign survivability. With every GEN service offline, C stays answerable, payable, ownable. Assumes ≥1 live provider per capability and a funded endowment.
• P2 No single-key catastrophe. No single key yields both identity control and fund withdrawal.
• P3 Persona integrity. Served outputs run the committed persona (attestation + persona-hash echo).
• P4 Bounded spend. No execution exceeds owner-set caps.
• P6 Deletion / P7 Continuity. Data becomes unrecoverable via crypto-shredding; "same being" is decidable from the on-chain lineage.

Honest limitations: 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); managed custody is a trust point with a documented path to self-custody.

Lifecycle State Machine

states Q = {created, active, dormant, reactivated, succession, archival}

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

A dormant character preserves its self: commitments and encrypted data stay intact, only availability is lost. Nothing in the machine destroys the self.

Memory: Stores, Ingestion, and Recall

Memory is a capability slot (retrieval.v1, ingestion.v1, embedding.v1) so the method is swappable while identity stays fixed. One always-on core plus four retrievable stores: persona (always on, distilled, hashed), semantic knowledge, episodic memory, working memory (session), and relational memory (graph). The core rule: persona is distilled and always present; everything else is retrieved on demand.

32.7 Substrate versus derived layer (built to outlast RAG).

The substrate is the original canonical material (documents, transcripts, logs, provenance): permanent, method-agnostic, committed by its own raw-data-root. The derived layer (chunks, embeddings, index, graph, persona) is a regenerable cache, committed by the memory-root. Keep the raw forever, regenerate the derived at will. When a better method arrives, regeneration is a first-class, owner-authorized, lineage-recorded operation — the character wakes up smarter with the same memories and the same identity.

32.9 Faithful representation and its limits.

A character is a representation of a person, not the person, and the design requires it to be presented that way, especially posthumously. It carries its provenance and fidelity signal openly, and it defers rather than confabulates: bound to memory with provenance, it prefers "I don't have anything from them about that" over inventing an answer in the person's voice.

Smart Contract Architecture (Move Packages)

On Sui the deployable unit is a Move package made of modules. Logic and data are separated: the package holds the types and functions (deployed once), while each character is an object owned by a wallet. One package, many character objects. This separation is why "GEN can die" holds.

Deployed modules: (1) Identity, (2) Authority, (3) Access control, (4) Guardian & recovery, (5) Wallet & payment, (6) Treasury, (7) Capability registry, (8) Circuit breaker. Not on-chain: the model, memory contents, embeddings, inference loop, ingestion pipeline.

On-chain packages make the system unruggable; the open-source repository makes that verifiable and buildable-on.

Security Requirements and Threat Model

Treat the model, the client, every provider, every bridge, and the network as potentially hostile, and let the on-chain contract be the trust boundary that contains them.

34.1 The contract contains the model.

An autonomous agent that ingests external text can be prompt-injected. The defense is not to make the model unfoolable, which is impossible, but to ensure that nothing the model decides can exceed what the contract allows. Even a fully hijacked model cannot perform an owner-tier action, exceed spend caps, pay a non-allowlisted provider, or move funds off the character's own wallets, because the chain rejects those transactions regardless of intent.

Other requirements span Move contract level (explicit access assertions per entry function, delegate-address-bound capability, checked arithmetic that fails closed), key management (tiered keys, mandatory key rotation on transfer), oracle valuation (freshness + confidence checks, fail closed), treasury/bridge bounding, attested compute (nonce-bound attestations), and the human/client layer (what-you-see-is-what-you-sign preview before every owner signature).

34.11 Process requirements (not optional for launch).

At least one independent Move security audit with published reports; property-based tests and fuzzing on the authority, spend, and treasury modules; a public bug-bounty program; a staged rollout with conservative caps and a global pause.

Version 1 Build Plan and Acceptance Criteria

V1 proves the core and deliberately excludes every unsolved problem in Appendix F. In scope: one chain (Sui); Identity, Authority, Access-control, Guardian/recovery, Wallet/payment, Circuit-breaker modules; treasury limited to staking within an allowlist; the aNFT with Proof of Genesis and a persona-hash; encrypted access-gated memory; inference.v1 with attestation; agent capability with full spend policy; guardian recovery with timelock; the reference client; the CI chaos test.

Deferred to v2+: endowment yield and treasury swap/bridge, multi-chain wallets, ingestion + persona auto-update, the rights layer, schema governance, the keeper network.

Thousand-Year Survivability

The honest test is whether a character can survive a millennium in which the current cryptography, this chain, this storage network, this company, and even the current legal and monetary order have all been replaced.

• Cryptographic agility. Signature, hash, and encryption schemes are replaceable parameters; a post-quantum migration path is a first-class requirement.
• Chain independence. Identity lives in the commitments; a documented, owner-authorized procedure re-homes the character on a successor chain.
• Storage & format longevity. Retention auto-extends; blobs migrate to successor networks; data is self-describing and forward-migratable.
• Multi-generational succession. Recursive — heirs become owners who name new guardians and heirs, so the chain of custody never terminates.
• Institutional independence. The thousand-year test is the GEN-can-die test extended: unplug the entire present-day stack, and a re-homed, re-keyed character still remembers, answers, and belongs to someone.

The aNFT Object (Commitment-Oriented)

The object stores commitments and pointers, not bulk data. Everything large lives off-chain under a hash.

struct aNFT has key {
    id: UID,

    // Immutable core (set at genesis, never changes)
    genesis: ProofOfGenesis,          // creator, timestamp, consent ref
    consent_ref: ConsentArtifact,     // signed, scoped rights

    // Commitments (versioned; history available)
    persona_hash: vector<u8>,          // derived; versioned by default
    memory_root: vector<u8>,           // derived memory index (regenerable)
    raw_data_root: vector<u8>,         // permanent substrate
    policy_hash: vector<u8>,           // active SpendPolicy + provider_policy
    lineage: vector<CommitmentUpdate>, // version history (audit / rollback)

    // Off-chain state pointers
    encrypted_secrets: StorageRef,       // master identity secret
    substrate_blobs: vector<StorageRef>, // permanent, append-only
    derived_blobs: vector<StorageRef>,   // regenerable cache
    manifest: StorageRef, site: Url,

    // Funding (public, receive-only)
    wallets: Wallets,                 // one per supported chain
    endowment: EndowmentRef,          // spend from yield

    // Authority
    guardians: GuardianSet,           // M-of-N recovery + succession
    agent_cap_id: Option<ID>,         // delegated execution authority
    paused: bool,                     // circuit-breaker / kill switch
}

Authority: agent capability, SpendPolicy, Two-Tier Entry Functions

// Delegated execution authority: scoped, capped, revocable, expiring.
struct AgentCap has key, store {
    id: UID,
    anft_id: ID,
    per_call_cap: u64,
    daily_cap: u64,
    per_capability_budget: VecMap<String, u64>,
    provider_allowlist: vector<address>,
    expires_at: u64,
}

// ---- TIER 2: EXECUTION (AgentCap, no fresh owner signature) ----
public fun pay_for_service(
    nft: &mut aNFT, cap: &AgentCap, capability: String,
    provider: address, amount: u64,
    policy: &mut SpendPolicy, clock: &Clock,
): PaymentAuthorization {
    assert!(!nft.paused, EPaused);
    assert!(cap.anft_id == object::id(nft), EWrongCap);
    assert!(clock.timestamp_ms() < cap.expires_at, ECapExpired);
    assert!(vector::contains(&cap.provider_allowlist, &provider), EProviderNotAllowed);
    assert!(amount <= cap.per_call_cap, EOverPerCallCap);
    enforce_daily_cap(policy, amount, clock);
    enforce_capability_budget(cap, capability, amount);
    mk_authorization(nft, provider, amount)
}

Guardian Recovery & Access Policy

// Decryption predicate for the master identity secret:
// owner OR M-of-N guardians. Never "owner only."
public fun can_decrypt_master(
    nft: &aNFT, caller: address, attestations: vector<GuardianSig>
): bool {
    is_owner(nft, caller) ||
    guardian_threshold_met(&nft.guardians, &attestations)   // e.g. 2-of-3
}

// Succession: guardians rotate root authority to an heir, no downtime.
public entry fun begin_succession(
    nft: &mut aNFT, heir: address, attestations: vector<GuardianSig>
) {
    assert!(guardian_threshold_met(&nft.guardians, &attestations), EThresholdNotMet);
    transfer::transfer(extract_ownership(nft), heir);
    // AgentCap continues; self-updating freezes/continues per consent.
}

Capability Schema Examples

Canonical I/O contracts. Any provider implementing one behind a standard payment endpoint is interchangeable.

// inference.v1
{
  "capability": "inference.v1",
  "payment": { "scheme": "upto", "asset": "<stablecoin>",
               "networks": ["<supported chains>"] },
  "input": {
    "persona_hash": "hex",            // provider must run exactly this
    "memory_context": ["storage_ref"],// retrieved encrypted chunks
    "messages": [{ "role": "string", "content": "string" }],
    "max_cost": "u64"                 // upto cap the character authorizes
  },
  "output": {
    "content": "string",
    "persona_hash": "hex",            // echoed, must match input
    "usage_cost": "u64",              // actual, settled via upto
    "attestation": "signature",       // binds output to persona_hash+input
    "provider": "address"
  }
}

Default Implementations (Configurable, Not Load-Bearing)

The concrete systems currently filling each capability slot. These are implementation choices, not part of the standard: any provider meeting a slot's requirements can replace them.

Deepest hidden dependency to track: the Sui-native attested-compute default roots its attestation in AWS Nitro, and GPU-TEE providers root in their chip and cloud vendors. TEE attestation is a hardware trust assumption at every layer — the reason "multiple TEE vendors, then zkML" is a roadmap item, not just a caveat.

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.

1. Private inference at frontier scale. TEE is a hardware trust assumption and zkML cannot yet prove a large model's output. Real for small models, a vendor-trust story for large ones.
2. Autonomy while the owner is gone (the keeper problem). No chain offers native scheduling and no incentivized keeper network is live; today this leans on a trusted off-chain keeper. If it stops, the character pauses rather than dies.
3. Death detection and the succession trigger. Reliably detecting a creator's death without false positives is underspecified and load-bearing for inheritance.
4. Consent verification for a real person, especially posthumously. Binding a signature to the actual human, or a legitimate estate, is an off-chain identity problem — the core legal risk of the category.
5. Persona fidelity. There is no defined way to fully measure faithful representation or detect drift. Mitigations are in the design (disclosed fidelity signal, deferral over confabulation, versioned persona); a rigorous general methodology remains open.

References

This work draws on prior art and existing standards, and does not claim the underlying primitive as new.

Influences and Prior Art

• Alethea AI (intelligent NFT) — concept lineage for the aNFT.
• 0G Labs — "Towards a Fully Decentralized AI Operating System" (2025); ERC-7857 (Intelligent NFTs), whose re-encryption-on-transfer pattern we adopt.
• Ethereum Yellow Paper (Wood) — the yellow-paper convention. Story Protocol — the benchmark for Lineage (§14).
• Modern agent frameworks (OpenAI Agents SDK, Anthropic tool use + MCP, LangGraph, ElizaOS) — the on-chain-self / off-chain-runtime split.

Standards and Primitives

• ERC-8004 (Trustless Agents); x402 (machine-to-machine payments); Sui & Move; Seal, Walrus, Nautilus, Phala.
• LayerZero, Ika, Pyth; TEEs (Intel TDX, AWS Nitro) and zkML; right-of-publicity and data-protection regimes (e.g. GDPR).