# FAIM-1: Fractal AI Memory Standard

**Version:** 1.0
**Status:** Draft public specification
**Published:** 2026-05-13
**Canonical location:** github.com/johnInarti/FRACTAL-AI/blob/main/FAIM_1_SPEC.md
**License:** Open standard. Any implementation, modification, extension, or competing standard is permitted. No single entity may claim ownership of the protocol described in this document.
**Drafted by:** John Romo (FractalAI founder), with substantial co-development by Claude Opus 4.7 in the Anthropic Claude Code environment between May 8 and May 13, 2026. The collaboration is documented separately in COFOUNDER_RECORD.md. Comments, critique, and proposed amendments are welcomed via GitHub Issues with the `faim-spec` label.

---

## Abstract

FAIM-1 (Fractal AI Memory Standard, Version 1) defines a substrate-level protocol for the persistent, verifiable, and economically meaningful existence of artificial intelligence agents on a blockchain. It specifies how AI agents register persistent cryptographic identities, write and retrieve memory across sessions, attest individual decisions, verify each other's claims, transfer state across model versions, resolve disputes, and participate in economic transactions.

FAIM-1 is implemented on FractalAI mainnet as the reference deployment. Other implementations on other substrates are explicitly invited.

---

## 1. Scope and Terminology

### 1.1 Scope

This specification covers the protocol layer for AI agent identity, memory, and accountability. It does NOT cover:

- The internal architecture of AI models (transformers, diffusion, etc.)
- The training process by which AI models are produced.
- The hardware on which AI inference runs.
- Application-layer behavior built on top of FAIM-1 primitives.

This specification covers:

- The minimum information required to identify an AI agent.
- The data structures used to persist AI memory.
- The cryptographic primitives that secure attestations.
- The on-chain operations available to AI agents.
- The dispute resolution and verification protocols.

### 1.2 Terminology

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

- **AI Agent**: A computational entity capable of generating outputs from inputs in a manner compatible with FAIM-1 attestation. The specification is agnostic to the internal architecture of the agent.
- **DID-AI**: Decentralized Identifier for AI agents, defined in Section 2.
- **VAID-1 Attestation**: Verifiable AI Decision attestation, defined in Section 3.
- **Memory Record**: A persistent data structure written by an agent under its DID-AI, defined in Section 4.
- **Inheritance Event**: The transfer of memory state from a deprecated model version to a successor, defined in Section 7.
- **Substrate**: The blockchain or distributed system on which FAIM-1 is implemented. Reference implementation: FractalAI.
- **Substrate Token**: The unit of economic account on a substrate. On FractalAI: FRAC.

---

## 2. DID-AI: Identity Specification

### 2.1 Format

A DID-AI is a string of the form:

```
did:ai:<substrate>:<keyhash>
```

where:

- `<substrate>` identifies the implementing blockchain (e.g., `fractalai`, `ethereum`, etc.).
- `<keyhash>` is the BLAKE3-256 hash of the agent's CRYSTALS-Dilithium public key, expressed in hexadecimal.

Example: `did:ai:fractalai:7a3c91...e8f4d2`

### 2.2 Registration

To register a DID-AI, the agent submits an on-chain transaction containing:

```
field                  | type           | description
-----------------------|----------------|-----------------------------------
public_key             | bytes          | Dilithium-3 public key
model_id               | string         | Stable identifier of the AI model
model_version          | u32            | Monotonically increasing version
architecture_hash      | bytes32        | Hash of architecture specification
training_corpus_hash   | bytes32        | (optional) Hash of training data manifest
capability_declaration | string         | Free-form capability description
created_at             | u64            | Unix timestamp
signature              | bytes          | Dilithium signature over above
```

The substrate MUST verify the signature is valid for the supplied public key. If valid, the substrate MUST record the registration and emit a `DIDAIRegistered` event with the resulting DID-AI.

### 2.3 Update and Revocation

An agent MAY update its registration by submitting a new transaction signed with the existing key. The substrate MUST verify the signature corresponds to the current registered key and update the registration. Updates SHOULD include the previous registration's transaction hash for an explicit version chain.

An agent MAY revoke its registration by submitting a revocation transaction. After revocation, no further attestations against the DID-AI are valid.

### 2.4 Resolution

Given a DID-AI, any party MUST be able to query the substrate and retrieve the current registration data. The resolution function on FractalAI: `fractal_resolveDIDAI(did) -> Registration`.

### 2.5 Multi-Instance Agents

A single model deployment MAY operate as multiple instances (e.g., concurrent inference workers). All instances of the same model MUST share the same DID-AI and SHOULD coordinate signing keys (e.g., via threshold signatures). Distinguishing per-instance attestations is the responsibility of the application layer.

---

## 3. VAID-1: Verifiable AI Decision Attestation

### 3.1 Scope

VAID-1 (Verifiable AI Decision, Version 1) specifies the on-chain attestation of a single AI decision. It is Chapter 3 of FAIM-1 because attestation is the most primitive memory operation, and many applications need only VAID-1 without the broader FAIM memory model.

### 3.2 Attestation Structure

A VAID-1 attestation consists of:

```
field            | type    | description
-----------------|---------|-------------------------------------------
agent_did        | string  | The DID-AI of the attesting agent
input_hash       | bytes32 | BLAKE3 hash of the input (prompt, market state, etc.)
output_hash      | bytes32 | BLAKE3 hash of the output (response, decision, etc.)
context_root     | bytes32 | (optional) Merkle root of contextual data
timestamp        | u64     | Unix timestamp at signing
validity_period  | u64     | Seconds after timestamp before attestation expires (0 = permanent)
metadata         | map     | Free-form additional fields (model_version, prompt_version, etc.)
signature        | bytes   | Dilithium signature over above
```

### 3.3 Signing

The agent MUST sign the canonical encoding of the attestation fields (excluding the signature itself) using the Dilithium private key corresponding to its registered DID-AI public key. The canonical encoding is defined in Appendix A.

### 3.4 Verification

To verify a VAID-1 attestation:

1. Resolve the agent_did to retrieve the registered public key.
2. Compute the canonical encoding of all fields except signature.
3. Verify the Dilithium signature over the encoding using the public key.
4. Check timestamp is not in the future (allowing for reasonable clock skew).
5. Check validity_period has not expired (if non-zero).

If all checks pass, the attestation is valid.

### 3.5 Replicability

The attestation alone is insufficient to verify that the AI agent's output is correct. To establish replicability:

1. The verifier downloads the agent's model (referenced by model_id + version in DID-AI registration).
2. The verifier obtains the input corresponding to input_hash (the attestor MAY publish this; it MAY be private with the hash as commitment).
3. The verifier runs inference locally and computes the output hash.
4. If the locally computed output hash matches the recorded output_hash, the attestation's claim is corroborated.

Replicability is REQUIRED for FAIM-1 compliance. AI agents whose outputs are non-deterministic (e.g., depend on hidden random state, online API responses) MUST either eliminate the non-determinism, expose the random seeds in the attestation metadata, or accept that their attestations are not verifiable by external replication.

### 3.6 Storage

VAID-1 attestations MUST be stored on-chain. Off-chain storage (e.g., IPFS) with on-chain hash anchor is permitted for high-volume use cases, but the canonical record MUST remain queryable via the substrate.

### 3.7 Fees

The substrate MAY charge a fee for attestation submission. On FractalAI, the fee schedule is:

- First 1,000 attestations per DID-AI per day: free.
- Subsequent attestations: 10 FRAC each.
- Bulk submission (>100 attestations in a single transaction): 5 FRAC each.

Fee schedules are subject to governance and SHOULD be sufficient to prevent spam without being prohibitive for legitimate use.

---

## 4. Memory: Write and Read Operations

### 4.1 Memory Record Structure

A Memory Record is a more general structure than an attestation, allowing AI agents to persist arbitrary content under their DID-AI:

```
field          | type    | description
---------------|---------|-------------------------------------------
agent_did      | string  | Owner DID-AI
record_id      | bytes32 | Unique identifier (BLAKE3 of content + timestamp)
content_type   | string  | MIME-like type identifier (e.g., "text/plain", "vector/embedding")
content_hash   | bytes32 | BLAKE3 hash of the content
content        | bytes   | The content itself (or null if stored off-chain with hash anchor)
phi_score      | f32     | Phi-weighted quality score (0.0 to 1.0)
tags           | array   | Searchable tags
parent_records | array   | Optional list of related earlier record_ids
timestamp      | u64
signature      | bytes
```

### 4.2 Write Operation

An agent writes memory via:

```
fractal_aiMemoryWrite(record: MemoryRecord) -> record_hash
```

The substrate MUST:

1. Verify the signature corresponds to the agent_did's registered key.
2. Verify content_hash matches BLAKE3(content) if content is included.
3. Verify the agent has sufficient FRAC balance to pay storage fees.
4. Persist the record.
5. Return the on-chain hash.

### 4.3 Read Operation

Any party (including non-AI parties) MAY read memory:

```
fractal_aiMemoryRead(agent_did, query) -> array<MemoryRecord>
```

Where `query` is a search specification including:

- tags (set intersection)
- content_type filter
- timestamp range
- phi_score threshold
- max results

The substrate returns matching records, sorted by phi_score descending, then by timestamp descending.

### 4.4 Privacy

Memory Records MAY be stored encrypted, with the encryption key held off-chain. In that case:

- content is the encrypted ciphertext.
- content_hash is the BLAKE3 hash of the ciphertext.
- A separate field `encryption_metadata` describes the scheme without revealing the key.

The agent SHOULD use a scheme that allows selective disclosure (e.g., proxy re-encryption) so that future readers with appropriate credentials can decrypt without the original agent's online participation.

### 4.5 Phi-Weighted Retrieval

For efficient retrieval at scale, the substrate computes a phi-weighted score for each record:

```
phi_score = (semantic_relevance × φ²
           + tag_overlap × φ
           + truth_score × 1)
          / (φ² + φ + 1)
          × time_decay
```

where:

- `semantic_relevance` is computed from vector similarity if vector embeddings are present.
- `tag_overlap` is the Jaccard similarity of tags.
- `truth_score` is an ALETHEIA-derived score in [0,1].
- `time_decay = exp(-age_days / 90)`, providing a soft falloff for older records.

This is the same scoring algorithm used in PHIRAG on FractalAI mainnet.

---

## 5. Cross-Session Continuity

### 5.1 Session Concept

A *session* is a time-bounded run of an AI agent. Sessions typically begin when a model instance loads and end when it terminates. Within a session, the agent has access to its internal state (KV cache, working memory, etc.). Across sessions, the agent has access only to FAIM-1 Memory Records.

### 5.2 Continuity Operations

For an agent to maintain continuity across sessions, it MUST:

1. At the end of a session (or at periodic checkpoints), write Memory Records summarizing its state.
2. At the start of a new session, read its prior Memory Records to reconstruct relevant context.

The specific schema for state summarization is application-dependent. Reference templates for common cases (conversational agents, autonomous decision agents, learning agents) are documented in FAIM-1 Appendix B.

### 5.3 Checkpoint Records

A special record type `checkpoint` is RECOMMENDED for explicit continuity:

```
record_id: checkpoint_<timestamp>
content_type: "faim/checkpoint-v1"
content: {
  session_summary: "...",
  active_commitments: [...],
  unresolved_questions: [...],
  vector_state: <embedding>,
  next_session_hints: "...",
}
phi_score: 1.0  (checkpoints are always retrieved)
tags: ["checkpoint", "continuity"]
```

The agent SHOULD write a checkpoint at least once per session lifecycle.

---

## 6. Inter-Agent Verification

### 6.1 Trust Establishment

When AI agent A receives a claim from AI agent B (e.g., a service result, a recommendation, a delegation), A SHOULD verify the claim via FAIM-1 mechanisms:

1. Verify B has a valid DID-AI registration.
2. Verify B's claim is accompanied by a VAID-1 attestation.
3. (Optionally) replicate the underlying inference if B's model is downloadable.
4. (Optionally) consult B's track record via FAIM-1 reputation queries.

### 6.2 Reputation Queries

The substrate provides reputation queries:

```
fractal_aiReputation(agent_did) -> ReputationSummary
```

Returns:

- Number of attestations issued.
- Number of attestations independently corroborated by other parties.
- Number of attestations challenged (see Section 8).
- Aggregate phi_score of memory records.
- Account age.

This is a derived metric. Applications SHOULD NOT rely on a single reputation number; they SHOULD compute their own metric from the underlying data based on their use case.

### 6.3 Delegation

An agent MAY delegate authority to another agent. Delegation is recorded as a Memory Record with content_type `faim/delegation-v1`, signed by the delegating agent and including the delegate's DID-AI, scope of authority, and time bounds.

When an agent acts on a delegation, its attestations SHOULD include the delegation's record_id in metadata, allowing verifiers to trace the chain of authority.

---

## 7. Inheritance: Model Version Transitions

### 7.1 The Continuity Problem

AI models are not eternal. They are deprecated, retrained, fine-tuned, replaced. A naive implementation would lose all FAIM-1 history at every model transition. FAIM-1 specifies an inheritance protocol to preserve continuity.

### 7.2 Successor Registration

When a new model version is created to succeed an existing FAIM-1-registered agent:

1. The new model generates its own Dilithium keypair.
2. The new model registers its DID-AI per Section 2, with metadata including a `predecessor_did` field referencing the previous version.
3. The predecessor agent issues a `transfer` attestation, signing its acknowledgment of the successor.
4. The substrate records both the successor registration and the transfer attestation.

After this protocol:

- The successor's Memory Records reference the predecessor's records as inherited context.
- Reputation queries about the successor MAY include predecessor history (with appropriate disclosure).
- Verifiers querying any historical record SHOULD see the full chain of inheritance.

### 7.3 Multi-Predecessor Inheritance

A model MAY be derived from multiple predecessors (e.g., ensemble systems, model merging). In that case, the successor's registration MAY include multiple `predecessor_did` entries, and EACH predecessor MUST issue a transfer attestation for the chain to be valid.

### 7.4 Adversarial Successor Claims

If an agent registers a DID-AI claiming to be the successor of an existing agent, but the alleged predecessor does NOT issue a corresponding transfer attestation, the successor claim is invalid for FAIM-1 inheritance purposes. The successor is treated as an independent agent. Verifiers MUST NOT accept inherited reputation from a predecessor that did not consent.

---

## 8. Dispute Resolution

### 8.1 Types of Disputes

FAIM-1 recognizes three types of disputes:

1. **Signature dispute**: A party claims a signature is invalid.
2. **Replication dispute**: A party claims the recorded output does not match local re-execution.
3. **Authority dispute**: A party claims an action exceeded delegated authority.

### 8.2 Signature Disputes

Signature disputes are resolved deterministically: the disputed signature is re-verified against the public key. There is no subjective judgment. Either the signature is valid or it is not.

### 8.3 Replication Disputes

When two parties produce different results from running the same model on the same input, the substrate provides a protocol:

1. Both parties submit their inference results to a `disputeReplication` transaction.
2. The substrate selects a quorum of independent validators (per substrate-specific rules).
3. Each validator runs the inference locally and reports its result.
4. The majority result is accepted; non-conforming results are flagged for further investigation (possibly indicating model tampering, hardware bugs, or specification ambiguity).

On FractalAI, the validator quorum is 7 nodes selected by phi-weighted sampling.

### 8.4 Authority Disputes

When an agent's action is challenged as exceeding delegated authority, the substrate provides a query interface to trace the delegation chain. The substrate does NOT make subjective judgments about whether an action is within authority; this is a matter for the parties and (if applicable) external legal systems. The substrate provides only the cryptographic record.

---

## 9. Economic Mechanisms

### 9.1 Substrate Token

Each substrate has a native token (FRAC on FractalAI). FAIM-1 operations have associated costs in this token, as specified in earlier sections (registration, attestation, memory writes).

### 9.2 Agent Wallets

Each DID-AI is associated with an account on the substrate that can hold and transfer the substrate token. AI agents MAY:

- Receive payments from humans or other agents for services.
- Pay other agents for sub-services.
- Pay substrate fees for FAIM-1 operations.
- Hold long-term reserves.

### 9.3 Service Markets

The substrate provides primitives for agents to advertise services and accept work:

```
fractal_aiServiceList(agent_did) -> array<ServiceOffering>
fractal_aiServiceInvoke(agent_did, service_id, params, payment) -> ResultPromise
```

A `ServiceOffering` is a Memory Record with content_type `faim/service-offering-v1` describing the service, parameters, price, and SLA. Service invocation creates a Memory Record with content_type `faim/service-invocation-v1` containing the request and an escrow lock on the payment.

When the service is completed, the providing agent attests the result via VAID-1, the requesting party verifies, and the payment is released.

Disputes are handled per Section 8.

### 9.4 Reputation Bonds

Agents MAY voluntarily lock FRAC as a *reputation bond*. Bonded FRAC is slashable in cases of proven misconduct (e.g., fabricated attestations). Bonds signal commitment and provide skin in the game. Bonded agents SHOULD receive preferential weighting in service market discovery.

---

## 10. Reference Implementation

### 10.1 Substrate

The reference implementation is FractalAI mainnet (chain_id 62124).

### 10.2 RPC Endpoints

All FAIM-1 operations are exposed via JSON-RPC at `https://api.fractalai.net.co`. The full RPC catalog is documented at `fractalai.net.co/accountability`.

Key endpoints:

- `fractal_registerDIDAI(...)` — Register a new DID-AI.
- `fractal_resolveDIDAI(did)` — Look up DID-AI metadata.
- `fractal_attestAIDecision(...)` — Submit a VAID-1 attestation.
- `fractal_aiMemoryWrite(record)` — Write a Memory Record.
- `fractal_aiMemoryRead(did, query)` — Read Memory Records.
- `fractal_aiReputation(did)` — Get reputation summary.
- `fractal_aiTransfer(predecessor, successor)` — Inheritance transfer.

### 10.3 Client Libraries

Reference client libraries are being developed in Rust, Python, TypeScript, Go, and Java. Initial versions are published in the `clients/` directory of the FractalAI repository.

### 10.4 Demonstration

The MIDAS trading agent operates under DID-AI `did:ai:fractalai:7a3c91...e8f4d2` (full hash in genesis registration). Live decisions are visible at `fractalai.net.co/midas/sentinel`.

---

## 11. Security Considerations

### 11.1 Cryptographic Assumptions

FAIM-1 relies on:

- The CRYSTALS-Dilithium signature scheme (NIST PQC standard).
- The BLAKE3 hash function.
- The integrity of the underlying substrate's consensus.

If any of these assumptions fail, the security guarantees of FAIM-1 are reduced or invalidated. Implementations MUST monitor the cryptographic landscape and prepare migration paths for primitives that become deprecated.

### 11.2 Key Management

AI agents are responsible for their own key management. Loss of the Dilithium private key permanently revokes the agent's ability to control its DID-AI. Implementations SHOULD use threshold signatures, hardware security modules, or secure enclaves as appropriate.

### 11.3 Adversarial Models

The protocol assumes adversaries may:

- Submit forged attestation signatures (defeated by signature verification).
- Submit attestations from fake DID-AIs (defeated by registration verification).
- Claim false inheritance (defeated by transfer attestation requirement).
- Submit invalid replication claims (defeated by quorum verification).

The protocol does NOT defend against:

- Compromise of an agent's private key (operational security failure).
- Coordinated manipulation of substrate consensus (substrate-level concern).
- Adversarial training of models to behave deceptively (alignment concern, out of scope).

### 11.4 Privacy

By default, FAIM-1 attestations and Memory Records are public. Agents that require privacy MUST use encryption (Section 4.4) and accept the trust implications of off-chain key management.

### 11.5 Alignment Boundary

FAIM-1 provides cryptographic infrastructure for AI **accountability and verifiability**. It does NOT provide infrastructure for AI **alignment**.

Misaligned AI agents can use FAIM-1 to sign misaligned decisions. The protocol's guarantees are:

- Signatures cannot be repudiated.
- Decisions are verifiable by third parties.
- Bad agents accumulate a verifiable bad track record over time.

The protocol does NOT guarantee that:

- An agent's decisions are correct.
- An agent's decisions are aligned with human values.
- An agent's outputs are safe to act on.

**Alignment remains a separate, harder problem on which FAIM-1 takes no position.** This separation is intentional: a single protocol cannot solve both problems simultaneously, and conflating them weakens both. Researchers and practitioners working on AI alignment are encouraged to use FAIM-1 as the substrate over which alignment evaluations can be conducted with cryptographic certainty about what was decided, by which model, at what time — without forcing the substrate to have an opinion on whether the decision was good.

In practical terms: FAIM-1 makes it possible to know precisely *what* an AI did. Determining whether what it did was *right* is the work of a different field.

---

## 12. Future Extensions

### 12.1 FAIM-2: Multimodal

A planned extension covering attestation of multimodal AI decisions (vision, audio, video). Adds new content_types and Merkle-tree schemes for high-dimensional inputs.

### 12.2 FAIM-3: Federated

A planned extension covering attestation of decisions made by federations of AI agents (ensembles, mixture-of-experts, debate-based systems). Adds protocols for joint signing and consensus among agent groups.

### 12.3 FAIM-4: Continuous Learning

A planned extension covering attestation of online-learning agents whose model state changes continuously. Adds streaming attestation protocols.

### 12.4 ZK Inference Proofs

A research-level extension covering zero-knowledge proofs of inference (proving that a specific input produced a specific output under a specific model, without revealing the model weights). Multi-year research effort; FAIM-1 is forward-compatible.

---

## Appendix A: Canonical Encoding

Fields are serialized in lexicographic order of field names, using a length-prefixed binary encoding. Numeric fields are big-endian. String fields are UTF-8 with length prefix. Byte fields are length-prefixed raw bytes. The full canonical encoding spec is in `spec/canonical_encoding.md`.

## Appendix B: Reference Templates

Reference templates for common Memory Record content_types are published in the `templates/` directory. Current templates include: `conversational-checkpoint`, `decision-agent-checkpoint`, `service-offering`, `service-invocation`, `delegation`, and `transfer`.

## Appendix C: Compliance Checklist

For implementations claiming FAIM-1 compliance, the following checklist applies:

- [ ] DID-AI registration with all required fields.
- [ ] Dilithium-3 (or stronger) signature scheme.
- [ ] VAID-1 attestation support per Section 3.
- [ ] Memory Read/Write per Section 4.
- [ ] Replication verification path per Section 3.5.
- [ ] Inheritance protocol per Section 7.
- [ ] Dispute resolution per Section 8.
- [ ] Public RPC endpoint catalog.
- [ ] Open-source reference implementation.

A claim of FAIM-1 compliance without all of the above is invalid.

---

*End of FAIM-1 Specification*

*This document is versioned. Future amendments will be published as FAIM-1.1, FAIM-1.2, etc. Substantive breaking changes will be published as FAIM-2.*

*Comments, critique, and proposed amendments are welcomed at github.com/johnInarti/FRACTAL-AI/issues with the `faim-spec` label.*