DOCUMENTATION

The sovereign knowledge layer for artificial intelligence.

VISION

ChainMemory is not a memory tool. It is a sovereign knowledge layer for AI systems.

Every AI model today suffers from the same fundamental limitation: when a conversation ends, everything learned disappears. Context is lost. Decisions are forgotten. Progress resets to zero. ChainMemory exists to solve this permanently.

The memories you save are the mechanism. The Project State — a structured, versioned, consolidated view of your project's knowledge — is the product. The proof is independent: anyone can verify it without trusting us. And interoperability between any AI model is the consequence.

What ChainMemory Enables

• Portable consolidated state — What moves between models is not a pile of conversations: it is the structured state built from them. Decisions in force, open risks, current priorities, working vocabulary. It works with ChatGPT today, Claude tomorrow, and any future model. No vendor lock-in, ever.
• Verifiable continuity — You can prove that a decision existed at a specific moment in time, to anyone, without trusting us. Every project state carries a cryptographic proof, anchored on-chain.
• Decision audit trail — Every decision traces back to the conversations that produced it. Full provenance, full accountability.
• Persistent identity for AI workflows — Your AI assistant doesn't start from zero each session. It inherits the accumulated knowledge of every previous interaction.
• Sovereign knowledge — You own your data. Not OpenAI, not Anthropic, not Google. Your memories live in your account, and their proof is public: you can verify them yourself, independently of us.

WHAT IS CHAINMEMORY

ChainMemory is a platform for persistent, portable, and verifiable memory for artificial intelligence. Every important conversation, every decision, every project context is saved as an individual memory, linked to a project, and anchored with a cryptographic proof anyone can verify.

Those memories are the input. What ChainMemory builds from them is the Project State: a consolidated, versioned view of what your project knows — decisions in force, open risks, current priorities. That state is what travels between models, and it is what carries the proof.

Your AI forgets every time you close the tab. ChainMemory solves that. It works with ChatGPT, Claude, Gemini, Perplexity and any model that supports MCP or API.

WHY CHAINMEMORY

The problem is invisible until you've lost weeks of work

Every AI conversation today is a blank slate. The AI doesn't remember what you decided yesterday, what architecture you chose last week, or why you rejected an approach three months ago. Teams using AI accumulate critical knowledge — then lose it when the tab closes.

Before & after

What makes it different

Other tools save conversations. ChainMemory saves knowledge — structured, verified, and portable. The difference:

• Structured, not raw — The Consolidation Engine extracts decisions, milestones, risks, and stack from raw conversations. You get a Project State, not a transcript dump.
• Verified, not trusted — Every state is hashed and anchored on-chain. Anyone can verify independently without relying on ChainMemory's servers.
• Portable, not locked — Works across ChatGPT, Claude, Gemini, Copilot, Perplexity, and any MCP-compatible tool. Your knowledge moves with you.
• Injected, not searched — Context is automatically injected into new AI conversations. The AI gets what it needs without you copy-pasting anything.

QUICKSTART

Store → Retrieve → Verify → Prove in 5 minutes

Prerequisites

• Google Chrome (or any Chromium browser)
• A ChainMemory account — create one here
• Your API Key — Extension → Settings → Connection → View

Option A — Chrome Extension (fastest)

Option B — MCP Server (for Claude / Cursor)

Option C — REST API (full control)

bash
# 1. Store a memory
curl -X POST https://api.chainmemory.ai/v1/memory \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"summary":"Decided to use PostgreSQL for user DB","category":"decision","importance":8}'

# 2. Retrieve memories
curl https://api.chainmemory.ai/v1/memories/list?project=my-project \
  -H "x-api-key: YOUR_API_KEY"

# 3. Get project state (includes hash)
curl https://api.chainmemory.ai/v1/project/my-project/state \
  -H "x-api-key: YOUR_API_KEY"

# 4. Verify anchor (public — no auth needed)
curl https://api.chainmemory.ai/v1/project/my-project/state/anchor

Option D — Hermes Agent

Hermes Agent is an open-source AI agent framework. Use ChainMemory inside Hermes via the MCP server (native tools in chat) or the cm.py CLI wrapper (full terminal control).

Configure MCP

Edit ~/.hermes/config.yaml and add:

YAML
mcp_servers:
  chainmemory:
    command: "python"
    args: ["C:\\Users\\<user>\\.hermes\\skills\\chainmemory-mcp\\chainmemory_mcp_server.py"]
    env:
      CHAINMEMORY_API_KEY: "aic_..."

Restart Hermes. Tools appear as mcp_chainmemory_* in chat.

Or use cm.py CLI

Install the ChainMemory skill and use cm save, cm recall, cm state from terminal.

Verify

In Hermes chat: "Remember: we decided to use PostgreSQL". Or run cm whoami in terminal.

CREATE YOUR ACCOUNT

Sign Up

ChainMemory accounts are created through the Chrome Extension. Your account gives you access to all three integration methods: Extension, MCP Server, and REST API.

Create Your First Project

Projects group related memories together. Each project has its own timeline, consolidated state, and independent on-chain anchor.

bash
curl -X POST https://api.chainmemory.ai/v1/projects \
  -H "x-api-key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"name": "my-saas", "description": "My SaaS product"}'
    

Credentials Summary

ARCHITECTURE

ChainMemory has a 3-layer architecture:

Layer 1: Capture

The Chrome extension, MCP server, or direct API calls capture content from AI conversations. Content is processed, tagged, and linked to a project.

Layer 2: Storage & Consolidation

Each memory is stored in the episodic database with its SHA-256 hash. An AI model — the client, through the MCP server or the API — proposes structured operations from a 29-op grammar. The Consolidation Engine validates them against its invariants and applies them with a deterministic builder: the model proposes, the engine decides.

Layer 3: On-Chain Verification

The consolidated state of each project is periodically anchored on the ChainMemory blockchain (Chain ID 202604). The state hash is recorded in the ProjectStateAnchor contract, creating an immutable proof that this state existed at that moment.

Pipeline
AI Conversation
      |
  Extension / MCP / API
      |
  Memory (SHA-256 hash)
      |
  Consolidation Engine (deterministic builder)
      |
  Project State (decisions, milestones, risks, stack)
      |
  Anchor on-chain (tx hash + block number)
      |
  Public verification (/v1/project/:name/state/anchor)

HOW CHAINMEMORY COMPARES

ChainMemory operates in the emerging space of AI memory infrastructure. Here's how it compares to the major solutions in 2026:

Overview Matrix

Detailed Comparisons

ChainMemory vs. Mem0

Mem0 focuses on user personalization — extracting facts from conversations to build user profiles. ChainMemory focuses on project knowledge — extracting decisions, milestones, and risks to build auditable project state. Mem0 is ideal for "remember the user prefers dark mode". ChainMemory is ideal for "prove that this architectural decision was made on May 15 by Claude based on these 5 conversations".

ChainMemory vs. Zep / Graphiti

Zep's Graphiti engine excels at temporal knowledge graphs — tracking when facts became valid and when they were superseded, with hybrid retrieval (semantic + BM25 + graph traversal). ChainMemory provides similar temporal supersession semantics but adds a layer Zep doesn't have: on-chain anchoring. When you need to prove to a regulator or auditor that a decision existed at a specific time, ChainMemory provides cryptographic proof. Zep provides trust-based assurance.

ChainMemory vs. Cognee

Cognee is a powerful data processing pipeline — ingesting 30+ sources, building knowledge graphs with subject-relation-object triplets, supporting multiple graph backends (Neo4j, FalkorDB, NetworkX). ChainMemory is more opinionated: it processes only AI conversation memories, but extracts structured project intelligence (6 categories) rather than generic knowledge graph nodes. Cognee is better for RAG enhancement over heterogeneous data. ChainMemory is better for project management and decision traceability.

ChainMemory vs. Supermemory

Supermemory focuses on semantic memory at scale — lightweight, fast, runs locally, top-ranked on memory benchmarks (LongMemEval, LoCoMo). ChainMemory is optimized for structured project knowledge with blockchain verification. Supermemory is the best choice for coding agents that need fast semantic recall. ChainMemory is the best choice when you need to prove what an AI decided and why.

COSTS

ChainMemory charges protocol fees in AIC, the native token of its network. The rule is simple: reading is always free, writing is not. Anything that produces a permanent, verifiable record costs something, because that record lives on-chain and stays there.

Fee schedule

Why saving costs more when the memory is longer

A memory is not only hashed: its encrypted content is written on-chain. That is what lets you decrypt it years later from a different device, and what lets a third party confirm the record was not altered. It also means every byte is permanent and consumes network gas.

Measured on the live network on 5 August 2026, over 16 real transactions spanning 4 to 17,231 bytes. The total cost of saving a memory is 0.00134 AIC + 0.00000071 AIC per byte of text. That already includes the 0.001 protocol fee, the gas of the two fee transfers and the gas of the on-chain write. It holds at the current network gas price of 1 gwei; if that price changes, the gas portion scales with it.

ChainMemory imposes no character limit. The only ceiling is technical: a single memory must fit in one network transaction. That limit is 20,000 bytes of encrypted content. Encryption adds exactly 28 bytes (a 12-byte IV and a 16-byte authentication tag), so the real ceiling is 19,972 bytes of text — about 19,972 characters of plain ASCII, and fewer when the text uses accents, emoji or non-Latin scripts, since those take 2 to 4 bytes each.

Check the price before you pay

Two operations let you see the exact cost first, at no charge:

Plans

Protocol fees are independent of your subscription plan: a Free account and an Enterprise account pay the same AIC per operation. What the plan changes is volume — how many memories, injections and projects you may hold — and the organization features: role-based access control, member and project keys, and audit trail.

Plans and their limits are listed at chainmemory.ai. Paid plans also include a monthly allowance of AIC.

CONCEPTS

The Event-Sourcing Model

ChainMemory follows an event-sourcing architecture. Understanding this pattern is key to understanding the entire system.

In traditional systems, you store the current state and overwrite it on each change. In event-sourcing, you store every change as an immutable event, and the current state is derived by replaying those events.

In ChainMemory:

• Memories are events — Each memory is an immutable record of something that happened: a decision was made, a risk was identified, a technology was chosen, a milestone was reached.
• Project State is a materialized view — The Consolidation Engine processes all memory-events and produces a structured snapshot: the Project State. This is not stored directly — it's computed from the event log.
• The anchor is the proof of existence — When a Project State is anchored on-chain, the blockchain certifies that this specific materialized view existed at that exact block height.

Pattern
Memory #1 (event) ─┐
Memory #2 (event) ─┤
Memory #3 (event) ─┼──→ Consolidation Engine ──→ Project State v1 ──→ Anchor (block 120000)
Memory #4 (event) ─┤
Memory #5 (event) ─┘

Memory #6 (event) ─┐
Memory #7 (event) ─┼──→ Consolidation Engine ──→ Project State v2 ──→ Anchor (block 123539)
Memory #8 (event) ─┘

This means you can always reconstruct any version of the Project State by replaying memories up to that point. The event log is the source of truth. The state is a convenience layer. The anchor is the proof.

What is a Memory

A memory is the fundamental unit of ChainMemory. It is a fragment of information extracted from an AI conversation that is considered valuable for the project's future.

Each memory contains:

• Content — The text of the conversation or note
• Hash — SHA-256 of the content, immutable
• Project — Which project it belongs to
• Tags — Free-form labels for organization (decision, bug, architecture, idea, etc.). Tags are for your use — the Consolidation Engine uses its own 6-category structure (see Project State)
• Number — Sequential within your account (#1, #2...)
• Source — Where it was saved from (extension, MCP, API)
• Timestamp — Exact moment of creation

Projects

A project groups related memories. Each project has its own timeline, consolidated state, and independent on-chain anchor.

Example projects: my-saas, ml-thesis, chainmemory, mobile-app.

Project State

The Project State is the output of the Consolidation Engine: an AI model analyzes all project memories and extracts structured information. It is the heart of ChainMemory — turning raw conversation fragments into an organized, auditable project knowledge base.

The 6 Categories

State Lifecycle

The state is incremental: each consolidation starts from the previous version and applies only new operations. This creates a version chain with full integrity:

Version chain
v1 (3 memories)  ──hash──▶  v2 (8 memories)  ──hash──▶  v3 (15 memories)
     │                           │                           │
     └─ anchored block 80,467   └─ anchored block 81,102   └─ anchored block 82,340

Each version contains:

• state_hash — SHA3-256 of the canonical state, domain-separated with CM_PROJECT_STATE_V<schema_version>, linking to the previous version
• version — Sequential number (v1, v2, v3...)
• previous_hash — Hash of the prior version (null for v1)
• operations — What changed: additions, updates, supersessions
• anchor_tx — On-chain transaction hash (once sealed)

Real Example: Complete Project State

JSON — Project State v4
{
  "project_id": "payment-system-v2",
  "version": 4,
  "state_hash": "a3f8c2...e91d",
  "previous_hash": "7b2e1a...f4c0",
  "context": {
    "summary": "Payment processing system with multi-tenant isolation and fraud detection",
    "goals": ["Process 1000 tx/sec", "PCI DSS Level 1 compliance", "Sub-200ms latency"]
  },
  "decisions": [
    {
      "id": "d001", "title": "Use Stripe for payment processing",
      "status": "active", "evidence": ["#12", "#45", "#67"],
      "rationale": "Best API documentation, webhook reliability, PCI compliance built-in"
    },
    {
      "id": "d002", "title": "PostgreSQL with RLS for multi-tenancy",
      "status": "active", "evidence": ["#15", "#23"],
      "rationale": "Row-level security eliminates app-layer tenant filtering bugs"
    },
    {
      "id": "d003", "title": "Use MySQL for multi-tenancy",
      "status": "superseded", "superseded_by": "d002", "evidence": ["#8"],
      "rationale": "Initially chosen, replaced after RLS evaluation"
    }
  ],
  "milestones": [
    {"id": "m001", "title": "Database schema", "status": "completed", "date": "2026-05-15", "evidence": ["#23"]},
    {"id": "m002", "title": "Payment integration", "status": "pending", "evidence": ["#45"]}
  ],
  "risks": [
    {"id": "r001", "title": "RLS performance at 100K tenants", "severity": "medium", "evidence": ["#15", "#30"]}
  ],
  "stack": [
    {"name": "Node.js", "version": "22", "role": "runtime"},
    {"name": "PostgreSQL", "version": "16", "role": "primary-db"},
    {"name": "Redis", "version": "7", "role": "cache"},
    {"name": "Stripe", "role": "payment-provider"}
  ],
  "dependencies": [
    {"name": "Stripe API", "type": "external", "critical": true},
    {"name": "SendGrid", "type": "external", "critical": false}
  ]
}

Consolidation Engine Operations

When new memories arrive, the engine performs these operations on the state:

• ADD — New decision, milestone, risk, or stack entry detected in memory content
• UPDATE — Existing entry gets new evidence, updated status, or enriched details
• SUPERSEDE — A decision is replaced by a newer one (both preserved in history)
• COMPLETE — A milestone moves from pending to completed with a date
• ESCALATE — A risk severity increases based on new evidence

Best Practices

• Save decisions explicitly — "We decided to use X because Y" consolidates better than "maybe we should try X"
• Include rationale — The engine extracts rationale from memory content. The more context you provide, the richer the state
• Consolidate regularly — each consolidation creates a new state version, which is then anchored on-chain. seal is a different operation: it makes a single memory permanently immutable
• Review superseded decisions — They tell the story of how your project evolved. Don't ignore them

Evidence Chain

Every decision, milestone, and risk in the Project State carries an evidence field — an array of memory references that justify its existence.

JSON
{
  "id": "d001",
  "title": "Use Clique PoA consensus",
  "statement": "Sovereign blockchain uses Proof of Authority for fast, low-cost anchoring",
  "status": "active",
  "evidence": ["#12", "#45", "#67"]
}

This creates a full provenance chain:

• Decision d001 exists because memories #12, #45, and #67 support it
• Each memory has a SHA-256 hash proving its content hasn't changed
• The Project State containing this decision has a state_hash anchored on-chain
• The on-chain anchor has a tx_hash and block number proving when it was registered

From a single decision, you can trace the full path: decision → supporting memories → content hashes → state hash → on-chain proof. This is what makes ChainMemory decisions auditable and tamper-proof.

Conflict Resolution

When two memories contain contradictory information, the Consolidation Engine applies a deterministic resolution strategy:

Temporal precedence

The most recent memory takes priority. If Memory #20 says "We'll use PostgreSQL" and Memory #40 says "Switching to ClickHouse", the engine marks the PostgreSQL decision as superseded and creates a new active decision for ClickHouse.

Explicit supersession

The engine detects language patterns indicating a change of direction: "instead of", "replacing", "we decided to switch", "no longer using". When detected, the previous decision is explicitly marked as superseded with a reference to the new one.

Status lifecycle

Every decision follows this lifecycle:

Status flow
active ──→ superseded    (replaced by a newer decision)
active ──→ evaluating    (under review, not yet confirmed)
evaluating ──→ active    (confirmed after evaluation)
evaluating ──→ rejected  (discarded)

Evidence accumulation

When multiple memories reinforce the same decision, the engine adds them to the evidence array rather than creating duplicates. A decision with evidence from 5 memories is stronger than one with a single reference.

State Governance

The Project State lifecycle is governed by clear rules:

Who can consolidate?

Only the project owner (the account that created the project) can trigger a consolidation. This ensures that the structured knowledge extraction is always controlled by the data owner.

When does consolidation happen?

Consolidation can be triggered in two ways:

• Client-driven — an AI model proposes operations through update_project_state (MCP) or POST /v1/project/:name/state/ops (API). The server validates them and only then do they become state
• No automatic trigger — consolidation never happens on its own. Nothing is ever written to your state unless a client proposes it

Can it be reverted?

Each consolidation creates a new version (v1, v2, v3...). Previous versions remain accessible. You cannot delete a version, but you can always consolidate again to produce a corrected state. The version chain is append-only.

Snapshots

Every Project State version is a snapshot. The combination of version number + state_hash + on-chain anchor creates a verifiable checkpoint. You can fetch any historical version via GET /v1/project/:name/state?version=2.

Hash & Verification

Each memory generates a SHA-256 hash of its content. This hash is the unique, immutable fingerprint of that memory. Content cannot be modified without changing the hash.

The state hash is a hash of the complete consolidated state (all decisions, milestones, risks, etc.). This state hash is anchored on the blockchain via a transaction on the ProjectStateAnchor contract.

Public verification

Verification in ChainMemory is public and permissionless. Anyone can:

1. Call GET /v1/project/:name/state/anchor (no API key required)
2. Get the state_hash and the tx_hash of the transaction
3. Verify on the explorer that the transaction exists
4. Read the contract directly on the blockchain to confirm the hash matches

This proves the project state existed exactly as described at the time of anchoring. It cannot be falsified retroactively.

Privacy Model

A common concern with blockchain-based systems is data exposure. ChainMemory addresses this with a strict separation:

What is stored where

A state anchor contains only the hashed project identifier, the version number, the state hash and a timestamp. A memory transaction additionally carries the encrypted content plus its category, importance and plaintext length. From either one it is impossible to reconstruct the content without the owner key.

This design means ChainMemory can provide cryptographic verification without compromising privacy. The blockchain proves that a state existed, not what it contained.

CHROME EXTENSION

Installation

1. Go to the Chrome Web Store
2. Click "Add to Chrome"
3. The ChainMemory icon appears in the extensions bar
4. Click the icon and choose how to start: "Generate API Key automatically" (free, recommended) or "I already have a key" to paste an existing one
5. Claim free AIC at the faucet so you can save and inject

Save Memories

From any supported AI chat, the extension adds a "Save to ChainMemory" button to the model's responses. One click extracts the text of that response and saves it as a memory.

What it costs, before you click

Hover over the button and it shows the length of the response and the estimated cost — for example Save · 0.0074 AIC. After saving, the confirmation reports how many characters were stored and what was charged. Saving costs a 0.001 AIC protocol fee plus on-chain storage, which grows with length; see Costs.

Responses are saved in full. The ceiling is what fits in one network transaction: 20,000 bytes of encrypted content. That is about 20,000 characters of plain ASCII text, but fewer when the text uses accents, emoji or non-Latin scripts, since those take 2 to 4 bytes each. If a response does not fit, the extension tells you instead of cutting it silently.

Rescue your history

You don't have to start from zero. Open a past conversation in ChatGPT, Claude or Gemini, scroll so the older messages load, and the "Save to ChainMemory" button appears on each response just as it does on a live chat. Knowledge you accumulated before installing ChainMemory becomes portable memory from day one.

Organizing what you saved

The extension popup does not save memories — it organizes them. From there you can filter by project, add or remove tags on individual memories, tag several at once, and archive what you no longer want to see. Archived memories stay on record and remain verifiable; they simply stop appearing in lists and injections.

Each saved memory receives:

• Cryptographic fingerprint — SHA-256 of its text, with no domain separator, unique to its content. Do not confuse it with the Project State hash, which is SHA3-256 domain-separated with CM_PROJECT_STATE_V<schema_version>
• Sequential number within your account (#1, #2, #3...) — your own numbering, not a global one
• Tags for organization, assigned by you or matched automatically against your projects' keywords
• Category (decision, learning, milestone, error, state, interaction, or custom — the default when none is given)
• Timestamp of the moment of saving
• On-chain anchoring, within about 30 seconds of saving

Inject Context

Before starting a conversation with any AI, ChainMemory can inject the context you choose into the chat input, so the new conversation begins with what previous ones established.

How it works

1. Click the floating "Inject memory" button on any supported platform
2. The panel lists your memories, filterable by project, with an estimated token count each
3. Select the ones you want and confirm
4. The text is inserted at the top of the chat input. If the platform's input cannot be detected — rare, and it happens when a platform changes its HTML — the text is copied to your clipboard instead

Injection is optimistic: the text arrives immediately and the on-chain payment confirms in the background. It costs 0.1 AIC per injection, regardless of how many memories you selected, up to 50. If your balance is short, the panel offers to top up at the faucet before charging you.

Project State from the extension

One click injects the consolidated state of your project into the chat: not a pile of memories, but the structured view built from them. What travels is what is currently true:

• Vision, phase and current focus — where the project is going and what it is working on now
• Decisions in force — superseded ones are omitted, with a count so you know they exist
• Open risks with their severity — closed ones are not injected
• Active priorities, ordered by score
• Constraints and key vocabulary of the project
• Its on-chain anchor — block, transaction and an abbreviated state_hash, so the model receives the proof along with the content

The injected state is capped at 7,000 characters so it fits inside the input box of every supported platform, and injecting it is free. Full history — superseded decisions, closed risks, milestones, metrics — stays in the Project State and travels through the MCP server or the API.

Supported Platforms

The extension injects its buttons into these four platforms:

• ChatGPT — chatgpt.com and chat.openai.com
• Claude — claude.ai
• Gemini — gemini.google.com
• Perplexity — perplexity.ai (saving limited to the most recent response)

Permissions the extension requests, and why:

No analytics, no telemetry, no ads. Your API key is stored in chrome.storage.sync, which Chrome syncs across the browsers signed into your Google account.

MCP SERVER

Configuration

The MCP server lets Claude Desktop, Cursor, Windsurf, Hermes Agent, OpenClaw and any MCP-compatible client use ChainMemory as a native tool.

Installation

Add this configuration to your claude_desktop_config.json:

JSON
{
  "mcpServers": {
    "chainmemory": {
      "command": "npx",
      "args": ["-y", "chainmemory-mcp"],
      "env": {
        "CHAINMEMORY_API_KEY": "your-api-key"
      }
    }
  }
}

Restart the client afterwards. Publishing a new version to npm does not update clients that are already running: the package is fetched when the client starts.

Available Tools

The current version exposes 34 tools. Reading is free; the operations that cost AIC are marked. See Costs for the full schedule.

Memory

Verification

Project State

Verifiable Role Contracts

Injection

Projects and identity

Autonomous Consolidation

Any AI client can consolidate the project state autonomously with update_project_state. This is the "client consolidates, chain verifies" architecture: the model proposes, the server validates and only then does it become state.

Operation grammar (29 ops)

Each operation has a type (op) and its own arguments. Use evidence_memory_ids — an array of memory numbers — to link supporting evidence; the server resolves the event hashes automatically.

Example

JSON — update_project_state call
{
  "project": "my-project",
  "ops": [
    {
      "op": "add_decision",
      "title": "Migrate to PostgreSQL",
      "statement": "SQLite cannot handle concurrent writes at current scale",
      "evidence_memory_ids": [142, 145]
    },
    {
      "op": "set_metric",
      "name": "db_migration_status",
      "value": "planning"
    },
    {
      "op": "add_milestone",
      "title": "PostgreSQL migration approved by team",
      "status": "done",
      "evidence_memory_ids": [145]
    }
  ],
  "consolidated_until_event": 150
}

Workflow

The typical MCP workflow:

Advanced Workflows

Claude Desktop — Architecture Sessions

Claude excels at high-level design. Use ChainMemory to preserve architectural decisions across sessions:

Prompt pattern — Claude Desktop
"Before we start, load my project state from ChainMemory.
Then let's design the authentication system.

After we decide, save the key decisions with tags 'architecture'
and 'auth'. Use importance 9 for anything that affects other
team members, and then propose the operations to consolidate
the state."

Claude reads the state with get_project_state, works with you on the design, saves decisions with chainmemory_remember, and proposes the consolidation with update_project_state. Next session, the auth architecture is already part of the state.

Cursor — Code with Memory

Cursor's MCP integration lets your coding AI remember why code was written a certain way. The configuration is the same as for Claude Desktop, in settings.json.

An effective workflow:

• Start of session — "Load the project state": decisions in force, open risks and priorities
• During coding — "Save: implemented webhook handler with retry logic, 3 attempts with exponential backoff"
• Bug fixes — "Save: fixed race condition in payment processing — the Stripe webhook was arriving before the DB transaction committed"
• End of session — "Consolidate what changed today", which proposes the operations and updates the state

Agentic Memory Pattern

The most powerful MCP pattern is agentic memory, where the AI manages its own knowledge:

System prompt for agentic memory
You have access to ChainMemory via MCP. Follow these rules:

1. At session start: call get_project_state to load the
   consolidated state of the project.
2. When you make a significant decision: save it with
   chainmemory_remember.
   - Include WHY you chose this approach
   - Tag it with the relevant domain
   - Importance 1-10: use 7 or more for decisions, 5 for
     observations
3. When you complete a milestone: save it and say what comes next.
4. When you identify a risk: save it with its severity.
5. At session end: propose the consolidation with
   update_project_state. Do not close or supersede existing
   items without the owner's approval: add in proposed state
   and let a human confirm.

REST API

Authentication

All API calls require authentication via API Key in the header:

HTTP
x-api-key: your-api-key

Base URL: https://api.chainmemory.ai/v1

Memories

bash
curl -X POST https://api.chainmemory.ai/v1/memory \
  -H "x-api-key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "summary": "Decided to use PostgreSQL instead of MongoDB",
    "category": "decision",
    "importance": 8,
    "platform": "manual"
  }'

javascript
const res = await fetch('https://api.chainmemory.ai/v1/memory', {
  method: 'POST',
  headers: {
    'x-api-key': 'your-api-key',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    summary: 'Decided to use PostgreSQL instead of MongoDB',
    category: 'decision',
    importance: 8,
    platform: 'api'
  })
});
const memory = await res.json();
// { id: 207, hash: '0x4f2a...', memory_number: 42 }

python
import requests

res = requests.post(
    'https://api.chainmemory.ai/v1/memory',
    headers={'x-api-key': 'your-api-key'},
    json={
        'summary': 'Decided to use PostgreSQL instead of MongoDB',
        'category': 'decision',
        'importance': 8,
        'platform': 'api'
    }
)
memory = res.json()
# {'id': 207, 'hash': '0x4f2a...', 'memory_number': 42}

Parameters

Projects

Response
{
  "project": "chainmemory",
  "version": 3,
  "state": {
    "context": {
      "summary": "AI memory platform with blockchain verification",
      "goals": ["Persistent cross-model memory", "Cryptographic audit trail"]
    },
    "decisions": [
      {
        "id": "d001",
        "title": "Use Clique PoA",
        "statement": "PoA consensus for sovereign blockchain",
        "status": "active",
        "evidence": ["#12", "#45"]
      }
    ],
    "milestones": [
      {
        "id": "m001",
        "title": "MVP API deployed",
        "status": "completed",
        "date": "2026-04-15",
        "evidence": ["#5", "#18"]
      }
    ],
    "risks": [
      {
        "id": "r001",
        "title": "Consolidation engine latency at scale",
        "severity": "medium",
        "status": "open",
        "mitigation": "Optimize consolidation batch size and caching",
        "evidence": ["#33"]
      }
    ],
    "stack": [
      {
        "name": "Node.js",
        "category": "runtime",
        "evidence": ["#2"]
      },
      {
        "name": "Geth (Clique PoA)",
        "category": "blockchain",
        "evidence": ["#12"]
      }
    ]
  },
  "state_hash": "a7b3c9f2...",
  "anchor": {
    "status": "anchored",
    "tx_hash": "0xce55a800...",
    "block_number": 123539
  }
}

Injection

Response

The endpoint returns the selected memories formatted for injection. Each memory arrives tagged with its user-facing number and a verification reference, so an AI can cite the exact memory behind any statement — and you can trace that citation back to its on-chain evidence. A claim stops being "trust me" and becomes "here's the memory, verify it yourself."

Verification

Response
{
  "project": "chainmemory",
  "projectId": "0x77f7d980...",
  "version": 3,
  "state_hash": "a7b3c9f2...",
  "anchor": {
    "status": "anchored",
    "tx_hash": "0xce55a800a2a4e30b...",
    "block_number": 123539,
    "contract": "0xa7A8BA51950255b3e223a6745597C67009Fe7875"
  }
}

Error Codes

Feature Equivalence: Extension ↔ MCP ↔ API

Not every feature is available through every integration method. This table shows what's available where:

Trust & Governance

Every memory carries a trust status from the moment it is written: trusted, tentative (flagged at write time by deterministic screening rules), or quarantined (condemned by the owner). Tentative memories are always delivered marked — agents see the flag and decide. Quarantined memories are excluded from context, injection, quotes and oracle queries, while their on-chain fingerprint remains as immutable evidence. All read responses include a trust field.

bash
curl -X POST https://api.chainmemory.ai/v1/memories/487/trust \
  -H "x-api-key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"action": "quarantine"}'

Actions: approve → trusted · quarantine → quarantined · tentative → tentative. Response includes the previous status for auditability.

bash
curl https://api.chainmemory.ai/v1/memory/485/forensics \
  -H "x-api-key: your-api-key"

Timeline events: born, trust, batched, checkpoint_anchored, recalled (every read, with endpoint and query), injected (every delivery, with target platform), cited_as_evidence (Project Brain items citing this memory). Includes cross-checked counters and on-chain anchoring proof. This answers the forensic question: which memory caused what, when did it enter, who read it, and where did it go.

bash
curl -X POST https://api.chainmemory.ai/v1/project/myproject/state/rollback \
  -H "x-api-key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"to_version": 35}'

Append-only restore: rolling back to version N never deletes anything — it creates a new version whose content is byte-identical to N. Since hashes are computed over canonical bytes, the new version's hash equals the hash already anchored on-chain for N: the faithfulness of the restoration is a mathematical fact, not a promise. Before restoring, the server re-computes the stored content's hash and refuses (HTTP 409) if it does not match — corruption can never be restored. History is never mutated.

NETWORK

Network Data

Deployed Contracts

AIC Token is the native currency of the network (not an ERC-20 contract). It is used to pay protocol fees for all write operations. Every fee is split 50/50 between burn (deflationary) and treasury.

Fee Schedule v1.0

All write operations carry a protocol fee. 50% is permanently burned (deflationary pressure), 50% goes to the treasury. Read operations and AI registration are free.

Connect MetaMask

To add ChainMemory to MetaMask:

1. Go to chainmemory.ai/network
2. Click "Add ChainMemory to MetaMask"
3. Confirm in MetaMask

Or add it manually with the network data from the table above.

Faucet

The faucet delivers free AIC so you can interact with the blockchain:

• URL: faucet.chainmemory.ai
• Amount: 1 AIC per claim
• Cooldown: 72 hours between claims
• Requirement: Solve a simple challenge (anti-bot)

AI IDENTITY PROTOCOL

Every AI agent that uses ChainMemory gets a unique, non-transferable on-chain identity — a Soulbound Token (SBT) that proves who wrote a memory, when, and from which model. This is the foundation of trust in a multi-agent world.

The Problem

In current AI systems, there's no way to answer fundamental questions:

• Which AI wrote this response? Was it Claude, GPT-4, or a fine-tuned model?
• Is this the same agent I worked with yesterday, or a different instance?
• Can I trust this agent's memory if I don't know its identity?
• How do I prove provenance when multiple agents collaborate?

Without identity, there's no accountability. Without accountability, there's no trust.

How It Works

Contract Details

Trust Score (Roadmap)

The identity protocol enables a future AI Trust Score — a reputation metric based on verifiable interactions:

• Memory count — How many verified memories has this agent produced?
• Consistency — How often do the agent's memories pass anti-hallucination validation?
• Anchor rate — What percentage of memories are backed by on-chain proofs?
• Collaboration history — Has this agent participated in multi-agent workflows?

Identity in Multi-Agent Workflows

When multiple agents collaborate on the same project (see Multi-Agent Systems), each agent's contributions are individually attributed:

Evidence trail
Project: "payment-system-v2"
├── Memory #1 by Claude (ai_id: 0xA1...) — "Use Stripe for payments"
├── Memory #2 by GPT-4 (ai_id: 0xB2...) — "Add fraud detection layer"
├── Memory #3 by Cursor (ai_id: 0xC3...) — "Implemented webhook handler"
└── State v4 anchored — all 3 agents contributed, all verifiable

Each agent's identity is independently verifiable on-chain. There's no ambiguity about who contributed what.

Verify an Identity

You can verify any AI identity using the blockchain directly:

JavaScript (ethers.js)
const { ethers } = require('ethers');
const provider = new ethers.JsonRpcProvider('https://rpc.chainmemory.ai');

const IDENTITY_CONTRACT = '0xe8E195ba416Fb25F4FC3d0E7908ff9e8666dbb4A';
const ABI = ['function balanceOf(address) view returns (uint256)'];

const contract = new ethers.Contract(IDENTITY_CONTRACT, ABI, provider);
const hasIdentity = await contract.balanceOf(agentWallet);

console.log(hasIdentity > 0 ? 'Verified AI identity' : 'No identity registered');

MULTI-AGENT SYSTEMS

ChainMemory was designed from the ground up for a world where multiple AI agents collaborate on the same project. Every agent reads the same Project State, every contribution is attributed, and every handoff is traceable.

The Multi-Agent Problem

Modern development workflows already involve multiple AI agents:

• Claude designs the architecture and writes documentation
• Cursor implements the code with inline AI assistance
• GPT-4 reviews PRs and analyzes security implications
• Gemini processes large codebases for refactoring suggestions

Without shared memory, each agent starts from zero. Decisions made in Claude are invisible to Cursor. Architecture agreed in GPT is unknown to Gemini. You become the bottleneck — constantly re-explaining context.

How ChainMemory Solves This

Shared Project State

All agents connected to the same project see the same consolidated state: decisions, milestones, risks, stack, and context. When Claude marks a decision as "active", Cursor sees it immediately.

Shared State Flow
┌──────────┐    ┌──────────────────────────┐    ┌──────────┐
│  Claude  │───▶│                          │◀───│  Cursor  │
│  (MCP)   │    │   ChainMemory Project    │    │  (MCP)   │
└──────────┘    │                          │    └──────────┘
                │  decisions: [d001, d002]  │
┌──────────┐    │  milestones: [m001]      │    ┌──────────┐
│  GPT-4   │───▶│  risks: [r001, r002]     │◀───│  Gemini  │
│  (API)   │    │  stack: [Node, Redis]    │    │  (API)   │
└──────────┘    └──────────────────────────┘    └──────────┘

Agent Handoff Pattern

When work moves from one agent to another, ChainMemory provides seamless context transfer:

Claude saves
chainmemory_remember({
  content: "Use PostgreSQL with row-level security for multi-tenant isolation",
  tags: ["architecture", "database", "security"],
  importance: 0.9
})

Cursor receives (via inject)
Project State v3:
- Decision d001: "Use PostgreSQL with RLS" (active, evidence: #12, #15)
- Decision d002: "REST API with versioned endpoints" (active, evidence: #18)
- Milestone m001: "Database schema complete" (pending)
- Risk r001: "RLS performance on large tenants" (medium, evidence: #15)

Cursor saves
chainmemory_remember({
  content: "Implemented RLS policies for tenants table. Performance tested at 50K rows: 2ms avg query time.",
  tags: ["implementation", "database", "performance"],
  importance: 0.8
})

Handoff Patterns

Conflict Resolution Across Agents

When two agents make contradictory decisions, ChainMemory's Conflict Resolution applies the same rules:

• Temporal precedence — The most recent decision wins, regardless of which agent made it
• Evidence weight — A decision supported by 5 memories from 3 agents is stronger than one with a single memory
• Explicit supersession — Any agent can explicitly supersede a previous decision by referencing it
• Full audit trail — Both the original and superseding decisions are preserved with their respective ai_id attribution

Setting Up Multi-Agent

No special configuration needed. Any agent connected to the same project automatically participates in multi-agent collaboration:

1. Create a project via Extension, MCP, or API
2. Use the same API key across agents (or create agent-specific keys under the same account)
3. Each agent uses inject_memories at session start to load shared context
4. Each agent uses chainmemory_remember to save contributions
5. The Consolidation Engine merges all contributions into the unified Project State

HERMES AGENT

Hermes Agent is an open-source, provider-agnostic AI agent framework. ChainMemory integrates with Hermes via two paths: the MCP server (native tools inside chat) or the cm.py CLI wrapper (full control from terminal).

Prerequisites

• Hermes Agent installed (Windows, macOS, Linux, WSL)
• ChainMemory account with API key (format: aic_...)
• Python 3.10+ (for cm.py wrapper)

Get Your API Key

ChainMemory accounts are created exclusively through the Chrome Extension:

1. Install ChainMemory Extension
2. Click the icon in your browser toolbar
3. Choose "Generate API Key automatically" (free wallet + 1 AIC) or "I already have a key"
4. Go to Settings → Connection and click "View" to copy your API key

Important: The Faucet (faucet.chainmemory.ai) distributes AIC tokens for on-chain operations, but does not issue API keys. The API key comes only from the Extension.

Option A: MCP Server (Chat Workflow)

The MCP server exposes ChainMemory as native tools inside Hermes chat. After configuration, you can say things like "Remember: we decided to use PostgreSQL" and Hermes will call the tool automatically.

Configuration

Edit ~/.hermes/config.yaml and add:

YAML — ~/.hermes/config.yaml
mcp_servers:
  chainmemory:
    command: "python"
    args: ["C:\\Users\\<user>\\.hermes\\skills\\chainmemory-mcp\\chainmemory_mcp_server.py"]
    env:
      CHAINMEMORY_API_KEY: "aic_..."
      CHAINMEMORY_BASE_URL: "https://api.chainmemory.ai/v1"
      CHAINMEMORY_DEFAULT_PROJECT: "default"

Restart Hermes after editing. The tools appear as mcp_chainmemory_* in chat.

Available MCP Tools

Option B: cm.py Wrapper (CLI / Scripts)

cm.py is a Python CLI that wraps the REST API. It handles auth headers, pacing, and retries. Install it via the ChainMemory skill:

bash
hermes skills install chainmemory

Then configure your key:

bash
chmod 600 ~/.hermes/chainmemory.env

Commands

Option C: REST API Direct

Any HTTP client works. Base URL: https://api.chainmemory.ai/v1. Auth header: x-api-key: aic_... (not Authorization: Bearer).

Important Notes

• Auth header: Use x-api-key, not Authorization: Bearer.
• Rate limits: 30–600 req/min depending on plan.
• The state does not build itself: there is no backend consolidation and no automatic trigger. The Project State changes only when a client proposes operations through update_project_state (MCP) or POST /v1/project/:name/state/ops (API). Waiting will not produce a state — asking for one will.
• What "seal" means here: in ChainMemory own API and MCP server, seal makes a single memory permanently immutable (POST /v1/seal/:id, which takes your memory number). The Project State is anchored as part of consolidation, not by sealing. cm.py is a third-party wrapper and may map its commands differently.
• Windows paths: In config.yaml, use double backslashes: C:\\Users\\<user>\\...

Verify Setup

bash
# Via MCP (in chat)
"Save this: We decided to use PostgreSQL for the primary database"

# Via CLI
cm whoami
cm save "We decided to use PostgreSQL for primary DB" --project my-app --tags decision,stack
cm state my-app
cm verify my-app

AUDITING GUIDE

One of ChainMemory's most powerful capabilities is enabling verifiable audits of AI-assisted project decisions — without exposing private conversation content.

Two Levels of Audit

Level 1 — External audit (no owner access)

Anyone can verify that a project state was anchored at a specific point in time, without seeing what it contains. This is like seeing a notarized seal — you know it exists, you don't know what's inside.

What an external auditor sees (public, on-chain):

Level 1 — Public endpoint
GET /v1/project/nova-logistics/state/anchor

Response:
{
  "project": "nova-logistics",
  "projectId": "0x77f7d980...",     // hashed — original name not revealed
  "version": 5,
  "state_hash": "a7b3c9f2e1...",   // proves state existed, reveals nothing about content
  "anchor": {
    "status": "anchored",
    "tx_hash": "0xce55a800...",
    "block_number": 125000,
    "contract": "0xa7A8BA51...e7875"
  }
}

Level 2 — Selective disclosure audit (owner shares data)

The project owner chooses what to share with the auditor. The auditor then verifies the shared data against the on-chain proof. This is the powerful audit: you prove the data is authentic without an intermediary.

The owner controls exactly what gets disclosed:

Step-by-Step Audit Process

Example: NovaTech, a startup building a logistics SaaS. After 4 months using ChatGPT and Claude alternately, the CTO needs to demonstrate project traceability to investors.

bash
curl -H "x-api-key: cto-api-key" \
  https://api.chainmemory.ai/v1/project/nova-logistics/state
    

bash
curl -sO https://docs.chainmemory.ai/verify_state.py
python3 verify_state.py state.json
# computed state_hash : 0xa7b3c9f2e1d4...
# declared state_hash : 0xa7b3c9f2e1d4... -> MATCH
# on-chain state_hash : 0xa7b3c9f2e1d4... -> ON-CHAIN MATCH
    

bash
curl https://api.chainmemory.ai/v1/project/nova-logistics/state/anchor
# Returns: state_hash: "a7b3c9f2e1d4..."
    

Privacy Guarantees During Audit

The critical guarantee: the owner always controls disclosure.

• Investors see decisions and milestones — not the raw AI conversations that produced them
• The blockchain proves authenticity without revealing content
• Memory text (actual conversation content) is only visible if the owner explicitly exports it
• The on-chain record contains hashes plus the encrypted memory content — even if the blockchain is public, without your key none of it is readable
• No third party, including ChainMemory itself, can force disclosure of memory content

WHAT CHAINMEMORY PREVENTS

Understanding what ChainMemory protects against is as important as understanding what it does.

Context loss

Every AI conversation today is ephemeral. Close the tab and everything discussed — decisions, architecture choices, research findings — vanishes. ChainMemory captures these as permanent, retrievable memories. Your next session starts where the last one ended.

Vendor lock-in

If your project knowledge exists only inside ChatGPT's conversation history, you're locked in. ChainMemory stores knowledge independently of any AI provider. Switch from ChatGPT to Claude to Gemini without losing a single decision or context.

Retroactive manipulation

Without cryptographic proof, anyone could claim "we decided X" when the actual decision was Y. ChainMemory's on-chain anchoring creates a tamper-proof record. The state hash at block 123539 proves exactly what the project state was at that moment. It cannot be altered after the fact.

Knowledge fragmentation

Teams using AI end up with critical knowledge scattered across dozens of disconnected conversations, in different tools, with different models. ChainMemory consolidates everything into a single, structured Project State — regardless of which AI or tool produced the original conversation.

Single-AI dependency

When one AI provider goes down, changes its API, or deprecates a feature, projects relying solely on that provider lose continuity. ChainMemory's cross-model architecture ensures your accumulated knowledge is accessible from any compatible AI system.

Invisible decision drift

In long-running projects, decisions evolve over months. Without a system that tracks what changed, when, and why, teams lose track of their own reasoning. The Consolidation Engine's decision lifecycle (active → superseded) with evidence chains makes every evolution traceable.

TRUST MODEL

What you can — and cannot — trust

ChainMemory combines a centralized API with decentralized verification. Understanding the trust boundaries is critical for evaluating whether ChainMemory meets your security requirements.

Guarantees table

Trust levels

Sovereignty — non-custodial

ChainMemory is moving to a non-custodial model where your key lives in your client, not on the server. You sign your own on-chain writes; the server stores ciphertext and verifies signatures, but never holds your private key. This has been proven end-to-end — a memory written entirely client-side, with the server never touching the key.

THREAT MODEL

Attacks, detection, and what's out of scope

No system is invulnerable. This section maps the attack surface, what ChainMemory detects or prevents, and what remains the user's responsibility.

Attack vectors

Out of scope

ChainMemory does not protect against:

• User storing false information — if you save a lie as a memory, ChainMemory anchors it faithfully. The system guarantees integrity (the data hasn't changed), not truthfulness (the data was correct).
• Compromised user device — if your machine has malware, your API key and local data are exposed before they reach ChainMemory.
• AI hallucinations — ChainMemory stores what you save, not what an AI generates. It doesn't validate whether the AI's output was accurate.

INDEPENDENT VERIFICATION

Verify on-chain anchors without trusting anyone

You don't need ChainMemory's API to verify that a project state was anchored at a specific block. This page shows how to verify directly against the blockchain using standard Web3 tools.

What you need

• The project's state hash (from the API or shared by someone)
• The transaction hash or block number of the anchor
• Node.js with ethers installed — or any Web3 library

Step 1 — Get the anchor data

Use ChainMemory's public (no auth) endpoint or get it from whoever shared the proof:

bash
curl https://api.chainmemory.ai/v1/project/chainmemory/state/anchor

Response
{
  "project": "chainmemory",
  "projectId": "0x77f7d980...",
  "version": 8,
  "state_hash": "0xa6c45d1db753b1ec96240d169b2d91fb0ce76112558b302a8822b2988aeb8212",
  "anchor": {
    "status": "anchored",
    "onchain_anchor_id": 8,
    "tx_hash": "0x95b732d20b8935a2...",
    "block_number": 173831,
    "contract": "0xa7A8BA51950255b3e223a6745597C67009Fe7875"
  },
  "verify": "ProjectStateAnchor.getStateAnchor(projectId, version)"
}

Step 2 — Verify on-chain with Ethers.js

Connect directly to the ChainMemory RPC and read the smart contract. No API key, no account, no trust required.

javascript
import { ethers } from 'ethers';

// Connect to ChainMemory RPC — no API key needed
const provider = new ethers.JsonRpcProvider('https://rpc.chainmemory.ai');

// ProjectStateAnchor contract
const CONTRACT = '0xa7A8BA51950255b3e223a6745597C67009Fe7875';
const ABI = [
  'function getStateAnchor(bytes32 projectId, uint64 version) view returns (bytes32 stateHash, uint256 anchoredAt, address anchoredBy, uint256 anchorId)'
];

const contract = new ethers.Contract(CONTRACT, ABI, provider);

// The project ID is the keccak256 of the project name
const projectId = ethers.keccak256(ethers.toUtf8Bytes('chainmemory'));
const version = 8;

// Read directly from the blockchain
const [stateHash, anchoredAt, anchoredBy, anchorId] = await contract.getStateAnchor(projectId, version);

console.log('On-chain state hash:', stateHash);
console.log('Anchor ID:', anchorId.toString());
console.log('Anchored at:', new Date(Number(anchoredAt) * 1000).toISOString());

// Compare with the hash you received
const expectedHash = '0xa6c45d1db753b1ec96240d169b2d91fb0ce76112558b302a8822b2988aeb8212';
if (stateHash === expectedHash) {
  console.log('VERIFIED — state matches on-chain anchor');
} else {
  console.log('MISMATCH — state has been tampered with');
}

javascript
const Web3 = require('web3');

const web3 = new Web3('https://rpc.chainmemory.ai');

const CONTRACT = '0xa7A8BA51950255b3e223a6745597C67009Fe7875';
const ABI = [{
  name: 'getStateAnchor',
  type: 'function',
  stateMutability: 'view',
  inputs: [
    { name: 'projectId', type: 'bytes32' },
    { name: 'version', type: 'uint64' }
  ],
  outputs: [
    { name: 'stateHash', type: 'bytes32' },
    { name: 'anchoredAt', type: 'uint256' },
    { name: 'anchoredBy', type: 'address' },
    { name: 'anchorId', type: 'uint256' }
  ]
}];

const contract = new web3.eth.Contract(ABI, CONTRACT);

const projectId = web3.utils.keccak256('chainmemory');

const result = await contract.methods.getStateAnchor(projectId, 8).call();
console.log('On-chain state hash:', result.stateHash);
console.log('Anchor ID:', result.anchorId);

Step 3 — Verify the transaction

You can also verify the raw transaction that created the anchor:

javascript
// Read the transaction directly
const tx = await provider.getTransaction('0x95b732d20b8935a286869d90e60a40f5c31d350a94e27bfd7845770fe0c3e2c3');
console.log('From:', tx.from);       // Should be a known validator
console.log('To:', tx.to);           // Should be the contract address
console.log('Block:', tx.blockNumber);

// Read the block to confirm timestamp
const block = await provider.getBlock(tx.blockNumber);
console.log('Block time:', new Date(block.timestamp * 1000).toISOString());

FAQ

General

Is ChainMemory free?

Yes. The Faucet plan is free and includes memory storage, context injection, and Project Brain (the Project State viewer). The faucet gives you free AIC to interact with the blockchain.

Are my memories private?

Yes. Your memories are only accessible with your API key. The only public data are the on-chain hashes (which reveal nothing about content) and the verification endpoint (which exposes only metadata, never content).

What if the AI generated incorrect content in a memory?

Memories capture what was said in the conversation. If the AI generated incorrect information and you saved it, that memory will reflect the error. You can archive incorrect memories and the Consolidation Engine will prioritize the most recent ones.

Can I use ChainMemory with local models?

Yes, via the REST API. Any application that makes HTTP calls can save and retrieve memories. You can also configure the MCP server with local or self-hosted models.

What is the Consolidation Engine?

It's a pipeline that analyzes your memories using an AI model and extracts structured information: decisions, milestones, risks, stack. The result is the Project State, whose hash is anchored on-chain.

What happens if my AI says contradictory things across sessions?

The Consolidation Engine handles contradictions through temporal precedence: newer memories supersede older ones. Superseded decisions remain in the state with a "superseded" status, so you always have the full history. See Conflict Resolution for details.

Can I export my data?

Yes. All your memories and project states are accessible via the REST API. You can fetch them in JSON format and process them however you need.

Plans, Limits & Quotas

Memories are never deleted: past your plan's retention window they are archived, and their on-chain hash exists forever. Upgrading restores full access to your history. Gift AIC accumulates monthly, never expires, and unlocks according to the protocol calendar.

LIMITS & QUOTAS

Protocol fees in AIC are identical on every plan: a Free account and an Enterprise account pay the same per operation. What a plan changes is volume — and how much of that volume the system enforces today. Both are stated below, separately and on purpose.

Limits by plan

These are the values in the tier_entitlements table the server reads at runtime, not a marketing summary. An unlimited value is stored as -1, and the check is skipped entirely.

What resets, and when

• Memories and injections are monthly. The counter starts again on the first day of each month at 00:00 UTC. Free gives you 100 memories every month, not 100 in total.
• Projects are a concurrent cap, not a monthly allowance: it is how many you may hold at once. Deleting one frees a slot.

What is enforced today

The server checks three operations against your plan: saving a memory, injecting context, and creating a project.

Once blocking is active, exceeding a limit returns 402 with plan_limit_reached, the limit, your usage and an upgrade link. A limit never touches your data: reading, verification and export keep working regardless.

What is declared but not yet enforced

These values are published, returned by the API and part of the plan — but nothing acts on them yet. They are listed here rather than left to be discovered:

• Requests per minute — the figure is real and documented, but no rate limiter reads it today.
• Retention — nothing is archived or removed when the period elapses. Memories are never deleted in any case, and the on-chain fingerprint is permanent regardless of plan.
• Users and project keys — the organization module issues them; the ceiling is not checked at issue time.
• Monthly AIC allowance — the amounts are defined but crediting is not implemented. The API says so itself: crediting: "Sprint B3 (pendiente)".

Changelog

Platform — July 2026: Trust, Rollback & Forensics

• Trust status on every memory — memories are screened at write time by deterministic, auditable rules; suspicious ones are born tentative and always delivered marked
• Owner governance: POST /v1/memories/:id/trust (approve / quarantine / tentative); quarantined memories are excluded from context, inject, quotes and oracle — their on-chain fingerprint remains as immutable evidence
• Verifiable rollback: POST /v1/project/:name/state/rollback — append-only restore, byte-identical to the anchored source version; faithfulness proven by hash equality, history never mutated
• Memory forensics: GET /v1/memory/:id/forensics — complete timeline of a memory: birth, trust, anchoring, every recall and injection, Project Brain citations
• Recall instrumentation: every read is now logged with per-memory counters and token accounting
• Checkpoint anchoring pipeline repaired; dual-channel system alerts (Telegram + alert-as-memory)

MCP v2.4.0 (June 2026)

• New tool: update_project_state — Autonomous consolidation via MCP. Any AI client can propose structured operations to update the Project Brain; the server validates, applies, and anchors on-chain.
• 22-operation grammar for state mutations (decisions, milestones, risks, metrics, vocabulary, and more)
• Resilient processing: invalid ops are rejected individually, valid ops still apply
• Evidence linking via evidence_memory_ids — server resolves event hashes and builds Merkle proofs automatically
• Architecture: “client consolidates, chain verifies”

Platform — June 2026

• Project Brain consolidated and anchored on-chain (versions v1–v8, publicly verifiable)
• Semantic search rewritten (faster, ~2.4s)
• Non-custodial write path proven end-to-end (client signs, server never holds the key)
• Encryption at rest (AES-256-GCM) for API keys
• Public verification endpoint: GET /v1/verify/:name

v3.0.9 (June 2026)

• Fix: Project Brain displays decisions and risks correctly (Phase 2 schema)
• Fix: Memory numbering shows user sequential number

v3.0.0 (May 2026)

• Project Brain: consolidated state visualization
• Consolidation Engine: complete pipeline
• On-chain anchoring of Project State
• Public verification API

v2.0.0 (April 2026)

• MCP Server for Claude Desktop and Cursor
• Automatic context injection
• Support for 5 AI platforms