DOCUMENTACIÓN

La capa de conocimiento soberano para inteligencia artificial.

VISIÓN

ChainMemory no es una herramienta de memoria. Es una capa de conocimiento soberano para sistemas de IA.

Todos los modelos de IA actuales sufren la misma limitación fundamental: cuando una conversación termina, todo lo aprendido desaparece. El contexto se pierde. Las decisiones se olvidan. El progreso se reinicia a cero. ChainMemory existe para resolver esto permanentemente.

Las memorias que guardás son el mecanismo. El Project State — una vista estructurada, versionada y consolidada del conocimiento de tu proyecto — es el producto. La prueba es independiente: cualquiera puede verificarla sin confiar en nosotros. Y la interoperabilidad entre cualquier modelo de IA es la consecuencia.

Qué permite ChainMemory

• Estado consolidado portable — Lo que se mueve entre modelos no es una pila de conversaciones: es el estado estructurado que se construyó con ellas. Decisiones vigentes, riesgos abiertos, prioridades actuales, vocabulario de trabajo. Funciona con ChatGPT hoy, Claude mañana, y cualquier modelo futuro. Sin vendor lock-in, nunca.
• Continuidad verificable — Podés demostrarle a cualquiera que una decisión existía en un momento específico, sin que tenga que confiar en nosotros. Cada estado de proyecto lleva su prueba criptográfica, anclada on-chain.
• Pista de auditoría de decisiones — Cada decisión se rastrea hasta las conversaciones que la produjeron. Procedencia completa, responsabilidad total.
• Identidad persistente para flujos de IA — Tu asistente de IA no arranca de cero en cada sesión. Hereda el conocimiento acumulado de cada interacción previa.
• Conocimiento soberano — Vos sos dueño de tus datos. No OpenAI, no Anthropic, no Google. Tus memorias viven en tu cuenta, y su prueba es pública: podés verificarlas vos mismo, de forma independiente de nosotros.

QUÉ ES CHAINMEMORY

ChainMemory es una plataforma de memoria persistente, portable y verificable para inteligencia artificial. Cada conversación importante, cada decisión, cada contexto de proyecto se guarda como una memoria individual, vinculada a un proyecto, y anclada con una prueba criptográfica que cualquiera puede verificar.

Esas memorias son el insumo. Lo que ChainMemory construye con ellas es el Project State: una vista consolidada y versionada de lo que tu proyecto sabe — decisiones vigentes, riesgos abiertos, prioridades actuales. Ese estado es lo que viaja entre modelos, y es lo que lleva la prueba.

Tu IA olvida cada vez que cerrás la pestaña. ChainMemory resuelve eso. Funciona con ChatGPT, Claude, Gemini, Perplexity y cualquier modelo que soporte MCP o API.

POR QUÉ CHAINMEMORY

El problema es invisible hasta que perdés semanas de trabajo

Cada conversación con IA hoy empieza de cero. La IA no recuerda qué decidiste ayer, qué arquitectura elegiste la semana pasada, ni por qué rechazaste un enfoque hace tres meses. Los equipos que usan IA acumulan conocimiento crítico — y lo pierden cuando cierran la pestaña.

Antes y después

Qué lo hace diferente

Otras herramientas guardan conversaciones. ChainMemory guarda conocimiento — estructurado, verificado y portable. La diferencia:

• Estructurado, no crudo — El Motor de Consolidación extrae decisiones, hitos, riesgos y stack de conversaciones crudas. Obtenés un Project State, no un dump de transcripciones.
• Verificado, no confiado — Cada estado es hasheado y anclado on-chain. Cualquiera puede verificar de forma independiente sin depender de los servidores de ChainMemory.
• Portable, no bloqueado — Funciona con ChatGPT, Claude, Gemini, Copilot, Perplexity y cualquier herramienta compatible con MCP. Tu conocimiento se mueve con vos.
• Inyectado, no buscado — El contexto se inyecta automáticamente en nuevas conversaciones con IA. La IA recibe lo que necesita sin que copies ni pegues nada.

INICIO RÁPIDO

Guardar → Recuperar → Verificar → Probar en 5 minutos

Prerequisitos

• Google Chrome (o cualquier navegador Chromium)
• Una cuenta ChainMemory — creá una acá
• Tu API Key — Extensión → Settings → Connection → View

Opción A — Extensión Chrome (más rápida)

Opción B — Servidor MCP (para Claude / Cursor)

Opción C — API REST (control total)

bash
# 1. Guardar una memoria
curl -X POST https://api.chainmemory.ai/v1/memory \
  -H "x-api-key: TU_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"summary":"Decidimos usar PostgreSQL para la DB de usuarios","category":"decision","importance":8}'

# 2. Recuperar memorias
curl https://api.chainmemory.ai/v1/memories/list?project=mi-proyecto \
  -H "x-api-key: TU_API_KEY"

# 3. Obtener estado del proyecto (incluye hash)
curl https://api.chainmemory.ai/v1/project/mi-proyecto/state \
  -H "x-api-key: TU_API_KEY"

# 4. Verificar ancla (público — sin autenticación)
curl https://api.chainmemory.ai/v1/project/mi-proyecto/state/anchor

Opción D — Hermes Agent

Hermes Agent es un framework de agentes IA open-source. Usá ChainMemory dentro de Hermes mediante el servidor MCP (herramientas nativas en el chat) o el wrapper cm.py CLI (control total desde terminal).

Configurar MCP

Editá ~/.hermes/config.yaml y agregá:

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

Reiniciá Hermes. Las herramientas aparecen como mcp_chainmemory_* en el chat.

O usá cm.py CLI

Instalá el skill de ChainMemory y usá cm save, cm recall, cm state desde terminal.

Verificar

En el chat de Hermes: "Recordá: decidimos usar PostgreSQL". O ejecutá cm whoami en terminal.

CREÁ TU CUENTA

Registro

Las cuentas de ChainMemory se crean a través de la Extensión Chrome. Tu cuenta te da acceso a los tres métodos de integración: Extensión, Servidor MCP, y API REST.

Creá tu primer proyecto

Los proyectos agrupan memorias relacionadas. Cada proyecto tiene su propia línea de tiempo, estado consolidado, y ancla on-chain independiente.

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

Resumen de credenciales

ARQUITECTURA

ChainMemory tiene una arquitectura de 3 capas:

Capa 1: Captura

La extensión Chrome, el servidor MCP o llamadas directas a la API capturan contenido de conversaciones con IA. El contenido se procesa, se le asignan tags, y se vincula a un proyecto.

Capa 2: Almacenamiento y Consolidación

Cada memoria se guarda en la base de datos episódica con su hash SHA-256. Un modelo de IA — el cliente, por el servidor MCP o la API — propone operaciones estructuradas de una gramática de 29 ops. El Motor de Consolidación las valida contra sus invariantes y las aplica con un builder determinista: el modelo propone, el motor decide.

Capa 3: Verificación On-Chain

El estado consolidado de cada proyecto se ancla periódicamente en la blockchain ChainMemory (Chain ID 202604). El hash del estado se registra en el contrato ProjectStateAnchor, creando una prueba inmutable de que ese estado existió en ese momento.

Pipeline
Conversación IA
      |
  Extensión / MCP / API
      |
  Memoria (hash SHA-256)
      |
  Motor de Consolidación (builder determinista)
      |
  Project State (decisiones, hitos, riesgos, stack)
      |
  Anchor on-chain (tx hash + block number)
      |
  Verificación pública (/v1/project/:name/state/anchor)

CÓMO SE COMPARA CHAINMEMORY

ChainMemory opera en el espacio emergente de infraestructura de memoria para IA. Así se compara con las principales soluciones en 2026:

Matriz de Comparación

Comparaciones Detalladas

ChainMemory vs. Mem0

Mem0 se enfoca en personalización de usuario — extrae facts de conversaciones para construir perfiles. ChainMemory se enfoca en conocimiento de proyecto — extrae decisiones, hitos y riesgos para construir un estado auditable. Mem0 es ideal para "recordar que el usuario prefiere modo oscuro". ChainMemory es ideal para "probar que esta decisión arquitectónica fue tomada el 15 de mayo por Claude basándose en estas 5 conversaciones".

ChainMemory vs. Zep / Graphiti

El motor Graphiti de Zep es excelente en knowledge graphs temporales — rastreando cuándo un hecho se volvió válido y cuándo fue reemplazado, con búsqueda híbrida (semántica + BM25 + traversal de grafos). ChainMemory provee semántica de supersesión temporal similar pero agrega una capa que Zep no tiene: anclaje on-chain. Cuando necesitás probarle a un regulador o auditor que una decisión existía en un momento específico, ChainMemory da prueba criptográfica. Zep da garantía basada en confianza.

ChainMemory vs. Cognee

Cognee es un potente pipeline de procesamiento de datos — ingesta 30+ fuentes, construye knowledge graphs con tripletas sujeto-relación-objeto, soporta múltiples backends. ChainMemory es más opinado: procesa solo memorias de conversaciones IA, pero extrae inteligencia de proyecto estructurada (6 categorías) en vez de nodos genéricos de knowledge graph.

ChainMemory vs. Supermemory

Supermemory se enfoca en memoria semántica a escala — liviano, rápido, corre local, top-ranked en benchmarks. ChainMemory está optimizado para conocimiento de proyecto estructurado con verificación blockchain. Supermemory es la mejor opción para agentes de código que necesitan recall semántico rápido. ChainMemory es la mejor opción cuando necesitás probar qué decidió una IA y por qué.

COSTOS

ChainMemory cobra fees de protocolo en AIC, el token nativo de su red. La regla es simple: leer es siempre gratis, escribir no. Todo lo que produce un registro permanente y verificable cuesta algo, porque ese registro vive en la cadena y se queda ahí.

Tabla de fees

Por qué guardar cuesta más cuando la memoria es más larga

Una memoria no sólo se hashea: su contenido cifrado se escribe on-chain. Eso es lo que te permite descifrarla años después desde otro dispositivo, y lo que le permite a un tercero confirmar que el registro no fue alterado. También significa que cada byte es permanente y consume gas de la red.

Medido sobre la red en producción el 5 de agosto de 2026, sobre 16 transacciones reales de entre 4 y 17.231 bytes. El costo total de guardar una memoria es 0.00134 AIC + 0.00000071 AIC por byte de texto. Eso ya incluye el fee de protocolo de 0.001, el gas de las dos transferencias del fee y el gas de la escritura on-chain. Vale al precio de gas actual de la red, 1 gwei; si ese precio cambia, la parte de gas escala con él.

ChainMemory no impone ningún límite de caracteres. El único techo es técnico: una memoria tiene que entrar en una sola transacción de red. Ese límite es de 20.000 bytes de contenido cifrado. El cifrado agrega exactamente 28 bytes (un IV de 12 y un tag de autenticación de 16), así que el techo real es de 19.972 bytes de texto — unos 19.972 caracteres en ASCII simple, y menos cuando el texto lleva acentos o emoji, porque cada uno ocupa de 2 a 4 bytes.

Ver el precio antes de pagar

Dos operaciones te dejan ver el costo exacto primero, sin cargo:

Planes

Los fees de protocolo son independientes de tu plan: una cuenta Free y una Enterprise pagan el mismo AIC por operación. Lo que cambia el plan es el volumen — cuántas memorias, inyecciones y proyectos podés tener — y las funciones de organización: control de acceso por roles, claves de miembro y de proyecto, y pista de auditoría.

Los planes y sus límites están en chainmemory.ai. Los planes pagos incluyen además una asignación mensual de AIC.

CONCEPTOS

El modelo Event-Sourcing

ChainMemory sigue una arquitectura event-sourcing. Entender este patrón es clave para entender todo el sistema.

En sistemas tradicionales, guardás el estado actual y lo sobreescribís en cada cambio. En event-sourcing, guardás cada cambio como un evento inmutable, y el estado actual se deriva reproduciendo esos eventos.

En ChainMemory:

• Las memorias son eventos — Cada memoria es un registro inmutable de algo que pasó: se tomó una decisión, se identificó un riesgo, se eligió una tecnología, se alcanzó un hito.
• El Project State es una vista materializada — El Motor de Consolidación procesa todos los eventos-memoria y produce un snapshot estructurado: el Project State. No se almacena directamente — se computa desde el log de eventos.
• El anclaje es la prueba de existencia — Cuando un Project State se ancla on-chain, la blockchain certifica que esta vista materializada específica existía en ese block height exacto.

Patrón
Memoria #1 (evento) ─┐
Memoria #2 (evento) ─┤
Memoria #3 (evento) ─┼──→ Motor de Consolidación ──→ Project State v1 ──→ Anchor (bloque 120000)
Memoria #4 (evento) ─┤
Memoria #5 (evento) ─┘

Memoria #6 (evento) ─┐
Memoria #7 (evento) ─┼──→ Motor de Consolidación ──→ Project State v2 ──→ Anchor (bloque 123539)
Memoria #8 (evento) ─┘

Esto significa que siempre podés reconstruir cualquier versión del Project State reproduciendo las memorias hasta ese punto. El log de eventos es la fuente de verdad. El estado es una capa de conveniencia. El anchor es la prueba.

Qué es una memoria

Una memoria es la unidad fundamental de ChainMemory. Es un fragmento de información extraído de una conversación con IA que se considera valioso para el futuro del proyecto.

Cada memoria contiene:

• Contenido — El texto de la conversación o nota
• Hash — SHA-256 del contenido, inmutable
• Proyecto — A qué proyecto pertenece
• Tags — Etiquetas libres para organización (decisión, bug, arquitectura, idea, etc.). Los tags son para tu uso — el Motor de Consolidación usa su propia estructura de 6 categorías (ver Project State)
• Número — Secuencial dentro de tu cuenta (#1, #2...)
• Fuente — Desde dónde se guardó (extensión, MCP, API)
• Timestamp — Momento exacto de creación

Proyectos

Un proyecto agrupa memorias relacionadas. Cada proyecto tiene su propia línea de tiempo, estado consolidado, y ancla on-chain independiente.

Ejemplos de proyectos: mi-saas, tesis-ml, chainmemory, app-mobile.

Project State

El Project State es el resultado del Motor de Consolidación: un modelo de IA analiza todas las memorias del proyecto y extrae información estructurada. Es el corazón de ChainMemory — transforma fragmentos de conversación en una base de conocimiento organizada y auditable.

Las 6 Categorías

Ciclo de Vida del Estado

El estado es incremental: cada consolidación parte de la versión anterior y aplica solo las operaciones nuevas. Esto crea una cadena de versiones con integridad completa:

Cadena de versiones
v1 (3 memorias)  ──hash──▶  v2 (8 memorias)  ──hash──▶  v3 (15 memorias)
     │                           │                           │
     └─ anclado bloque 80,467   └─ anclado bloque 81,102   └─ anclado bloque 82,340

Cada versión contiene:

• state_hash — SHA3-256 del estado canónico, con separador de dominio CM_PROJECT_STATE_V<schema_version>, enlazado a la versión anterior
• version — Número secuencial (v1, v2, v3...)
• previous_hash — Hash de la versión anterior (null para v1)
• operations — Qué cambió: adiciones, actualizaciones, supersesiones
• anchor_tx — Hash de transacción on-chain (una vez sellado)

Ejemplo Real: Project State Completo

JSON — Project State v4
{
  "project_id": "payment-system-v2",
  "version": 4,
  "state_hash": "a3f8c2...e91d",
  "previous_hash": "7b2e1a...f4c0",
  "context": {
    "summary": "Sistema de pagos con aislamiento multi-tenant y detección de fraude",
    "goals": ["Procesar 1000 tx/seg", "Cumplimiento PCI DSS Level 1", "Latencia sub-200ms"]
  },
  "decisions": [
    {
      "id": "d001", "title": "Usar Stripe para procesamiento de pagos",
      "status": "active", "evidence": ["#12", "#45", "#67"],
      "rationale": "Mejor documentación de API, confiabilidad de webhooks, PCI compliance integrado"
    },
    {
      "id": "d002", "title": "PostgreSQL con RLS para multi-tenancy",
      "status": "active", "evidence": ["#15", "#23"]
    },
    {
      "id": "d003", "title": "Usar MySQL para multi-tenancy",
      "status": "superseded", "superseded_by": "d002", "evidence": ["#8"]
    }
  ],
  "milestones": [
    {"id": "m001", "title": "Schema de BD", "status": "completed", "date": "2026-05-15"},
    {"id": "m002", "title": "Integración de pagos", "status": "pending"}
  ],
  "risks": [
    {"id": "r001", "title": "Performance de RLS con 100K tenants", "severity": "medium"}
  ],
  "stack": [
    {"name": "Node.js", "version": "22", "role": "runtime"},
    {"name": "PostgreSQL", "version": "16", "role": "primary-db"},
    {"name": "Redis", "version": "7", "role": "cache"}
  ],
  "dependencies": [
    {"name": "Stripe API", "type": "external", "critical": true}
  ]
}

Operaciones del Motor de Consolidación

• ADD — Nueva decisión, hito, riesgo o entrada de stack detectada en el contenido de la memoria
• UPDATE — Entrada existente recibe nueva evidencia, estado actualizado o detalles enriquecidos
• SUPERSEDE — Una decisión es reemplazada por una más nueva (ambas preservadas en el historial)
• COMPLETE — Un hito pasa de pendiente a completado con fecha
• ESCALATE — La severidad de un riesgo aumenta basándose en nueva evidencia

Mejores Prácticas

• Guardá decisiones explícitamente — "Decidimos usar X porque Y" se consolida mejor que "tal vez deberíamos probar X"
• Incluí la justificación — El motor extrae el razonamiento del contenido. Cuanto más contexto des, más rico será el estado
• Consolidá regularmente — cada consolidación crea una versión nueva del estado, que después se ancla on-chain. seal es otra operación: vuelve permanentemente inmutable una memoria
• Revisá decisiones reemplazadas — Cuentan la historia de cómo evolucionó tu proyecto. No las ignores

Cadena de evidencia

Cada decisión, hito y riesgo en el Project State lleva un campo evidence — un array de referencias a memorias que justifican su existencia.

JSON
{
  "id": "d001",
  "title": "Usar consenso Clique PoA",
  "statement": "Blockchain soberana usa Proof of Authority para anclaje rápido y económico",
  "status": "vigente",
  "evidence": ["#12", "#45", "#67"]
}

Esto crea una cadena de procedencia completa:

• La decisión d001 existe porque las memorias #12, #45 y #67 la respaldan
• Cada memoria tiene un hash SHA-256 que prueba que su contenido no cambió
• El Project State que contiene esta decisión tiene un state_hash anclado on-chain
• El ancla on-chain tiene un tx_hash y block number que prueban cuándo se registró

Desde una sola decisión, podés rastrear el camino completo: decisión → memorias de respaldo → hashes de contenido → hash del estado → prueba on-chain. Esto es lo que hace que las decisiones de ChainMemory sean auditables e inalterables.

Resolución de conflictos

Cuando dos memorias contienen información contradictoria, el Motor de Consolidación aplica una estrategia de resolución determinística:

Precedencia temporal

La memoria más reciente tiene prioridad. Si la Memoria #20 dice "Usaremos PostgreSQL" y la Memoria #40 dice "Cambiamos a ClickHouse", el motor marca la decisión de PostgreSQL como reemplazada y crea una nueva decisión activa para ClickHouse.

Supersesión explícita

El motor detecta patrones de lenguaje que indican cambio de dirección: "en vez de", "reemplazando", "decidimos cambiar", "ya no usamos". Cuando se detecta, la decisión anterior se marca explícitamente como reemplazada con referencia a la nueva.

Ciclo de vida de estados

Flujo de estados
vigente ──→ reemplazada    (sustituida por una decisión más nueva)
vigente ──→ en evaluación  (bajo revisión, aún no confirmada)
en evaluación ──→ vigente  (confirmada tras evaluación)
en evaluación ──→ rechazada (descartada)

Acumulación de evidencia

Cuando múltiples memorias refuerzan la misma decisión, el motor las agrega al array de evidencia en lugar de crear duplicados. Una decisión con evidencia de 5 memorias es más sólida que una con una sola referencia.

Gobernanza del estado

El ciclo de vida del Project State está gobernado por reglas claras:

Quién puede consolidar?

Solo el dueño del proyecto (la cuenta que lo creó) puede disparar una consolidación. Esto asegura que la extracción de conocimiento estructurado siempre esté controlada por el dueño de los datos.

Cuándo ocurre la consolidación?

• La dispara el cliente — un modelo de IA propone operaciones vía update_project_state (MCP) o POST /v1/project/:name/state/ops (API). El servidor las valida y recién entonces se vuelven estado
• No hay disparador automático — la consolidación nunca ocurre sola. Nada se escribe en tu estado si un cliente no lo propone

Se puede revertir?

Cada consolidación crea una nueva versión (v1, v2, v3...). Las versiones anteriores siguen accesibles. No podés borrar una versión, pero siempre podés consolidar de nuevo para producir un estado corregido. La cadena de versiones es append-only.

Snapshots

Cada versión del Project State es un snapshot. La combinación de número de versión + state_hash + ancla on-chain crea un checkpoint verificable. Podés obtener cualquier versión histórica vía GET /v1/project/:name/state?version=2.

Hash y verificación

Cada memoria genera un hash SHA-256 de su contenido. Este hash es la huella digital única e inmutable de esa memoria. El contenido no se puede modificar sin cambiar el hash.

El state hash es un hash del estado consolidado completo (todas las decisiones, hitos, riesgos, etc.). Este state hash se ancla en la blockchain mediante una transacción en el contrato ProjectStateAnchor.

Verificación pública

La verificación en ChainMemory es pública y sin permisos. Cualquier persona puede:

1. Llamar a GET /v1/project/:name/state/anchor (no requiere API key)
2. Obtener el state_hash y el tx_hash de la transacción
3. Verificar en el explorer que la transacción existe
4. Leer el contrato directamente en la blockchain para confirmar que el hash coincide

Esto demuestra que el estado del proyecto existía exactamente así en el momento del anclaje. No se puede falsificar retroactivamente.

Modelo de privacidad

Una preocupación común con sistemas basados en blockchain es la exposición de datos. ChainMemory aborda esto con una separación estricta:

Qué se guarda dónde

Un ancla de estado contiene solo el identificador del proyecto hasheado, el número de versión, el hash del estado y un timestamp. Una transacción de memoria lleva además el contenido cifrado más su categoría, importancia y largo del texto plano. Desde cualquiera de las dos es imposible reconstruir el contenido sin la llave del dueño.

Este diseño significa que ChainMemory puede proveer verificación criptográfica sin comprometer la privacidad. La blockchain prueba que un estado existió, no qué contenía.

EXTENSIÓN CHROME

Instalación

1. Ir a la Chrome Web Store
2. Click en "Agregar a Chrome"
3. El icono de ChainMemory aparece en la barra de extensiones
4. Click en el icono y elegí cómo empezar: "Generate API Key automatically" (gratis, recomendado) o "I already have a key" para pegar una existente
5. Reclamá AIC gratis en el faucet para poder guardar e inyectar

Guardar memorias

Desde cualquier chat de IA soportado, la extensión agrega un botón "Save to ChainMemory" a las respuestas del modelo. Un clic extrae el texto de esa respuesta y lo guarda como memoria.

Lo que cuesta, antes de hacer clic

Pasando el mouse sobre el botón, muestra el largo de la respuesta y el costo estimado — por ejemplo Save · 0.0074 AIC. Después de guardar, la confirmación dice cuántos caracteres se almacenaron y cuánto se cobró. Guardar cuesta un fee de protocolo de 0.001 AIC más el almacenamiento on-chain, que crece con el largo; ver Costos.

Las respuestas se guardan completas. El techo es lo que entra en una transacción de red: 20.000 bytes de contenido cifrado. Eso equivale a unos 20.000 caracteres en texto ASCII simple, pero a menos cuando el texto lleva acentos o emoji, porque cada uno ocupa de 2 a 4 bytes. Si una respuesta no entra, la extensión te avisa en vez de cortarla en silencio.

Rescatar tu historial

No tenés que empezar de cero. Abrí una conversación pasada en ChatGPT, Claude o Gemini, scrolleá para que carguen los mensajes viejos, y el botón "Save to ChainMemory" aparece en cada respuesta igual que en un chat en vivo. El conocimiento que acumulaste antes de instalar ChainMemory se vuelve memoria portable desde el primer día.

Organizar lo que guardaste

El popup de la extensión no guarda memorias — las organiza. Desde ahí podés filtrar por proyecto, agregar o quitar tags en memorias individuales, etiquetar varias a la vez, y archivar lo que ya no querés ver. Las memorias archivadas siguen en el registro y siguen siendo verificables; simplemente dejan de aparecer en listados e inyecciones.

Cada memoria guardada recibe:

• Huella criptográfica — SHA-256 de su texto, sin separador de dominio, única de su contenido. No confundir con el hash del Project State, que sí es SHA3-256 con separador de dominio CM_PROJECT_STATE_V<schema_version>
• Número secuencial dentro de tu cuenta (#1, #2, #3...) — tu propia numeración, no una global
• Tags para organización, asignados por vos o por coincidencia automática con las palabras clave de tus proyectos
• Categoría (decisión, aprendizaje, milestone, error, estado, interacción, o custom — el valor por defecto si no mandás ninguno)
• Timestamp del momento de guardado
• Anclaje on-chain, dentro de unos 30 segundos

Inyectar contexto

Antes de empezar una conversación con cualquier IA, ChainMemory puede inyectar el contexto que elijas en el campo de texto del chat, para que la conversación nueva arranque con lo que las anteriores dejaron establecido.

Cómo funciona

1. Click en el botón flotante "Inject memory" en cualquier plataforma soportada
2. El panel lista tus memorias, filtrables por proyecto, con una estimación de tokens en cada una
3. Seleccionás las que querés y confirmás
4. El texto se inserta al principio del campo del chat. Si el campo de la plataforma no puede detectarse — raro, y pasa cuando una plataforma cambia su HTML — el texto se copia al portapapeles

La inyección es optimista: el texto llega enseguida y el pago on-chain se confirma en segundo plano. Cuesta 0.1 AIC por inyección, sin importar cuántas memorias hayas seleccionado, hasta 50. Si tu saldo no alcanza, el panel te ofrece cargar en el faucet antes de cobrarte.

Project State desde la extensión

Un clic inyecta el estado consolidado de tu proyecto en el chat: no una pila de memorias, sino la vista estructurada que se construyó con ellas. Lo que viaja es lo que está vigente:

• Visión, fase y foco actual — hacia dónde va el proyecto y en qué está trabajando ahora
• Decisiones vigentes — las superseded se omiten, con un contador para que sepas que existen
• Riesgos abiertos con su severidad — los cerrados no se inyectan
• Prioridades activas, ordenadas por score
• Constraints y vocabulario clave del proyecto
• Su anclaje on-chain — bloque, transacción y un state_hash abreviado, para que el modelo reciba la prueba junto con el contenido

El estado inyectado tiene un tope de 7.000 caracteres para que entre en el campo de texto de todas las plataformas soportadas, e inyectarlo es gratis. La historia completa — decisiones superseded, riesgos cerrados, milestones, métricas — queda en el Project State y viaja por el servidor MCP o la API.

Plataformas soportadas

La extensión inyecta sus botones en estas cuatro plataformas:

• ChatGPT — chatgpt.com y chat.openai.com
• Claude — claude.ai
• Gemini — gemini.google.com
• Perplexity — perplexity.ai (guardado limitado a la última respuesta)

Permisos que pide la extensión, y para qué:

Sin analytics, sin telemetría, sin publicidad. Tu API key se guarda en chrome.storage.sync, que Chrome sincroniza entre los navegadores donde iniciaste sesión con tu cuenta de Google.

SERVIDOR MCP

Configuración

El servidor MCP le permite a Claude Desktop, Cursor, Windsurf, Hermes Agent, OpenClaw y cualquier cliente compatible con MCP usar ChainMemory como herramienta nativa.

Instalación

Agregá esta configuración a tu claude_desktop_config.json:

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

Reiniciá el cliente después. Publicar una versión nueva en npm no actualiza a los clientes que ya están corriendo: el paquete se descarga cuando el cliente arranca.

Herramientas disponibles

La versión actual expone 34 herramientas. Leer es gratis; las operaciones que cuestan AIC están marcadas. Ver Costos para la tabla completa.

Memoria

Verificación

Project State

Verifiable Role Contracts

Inyección

Proyectos e identidad

Consolidación autónoma

Cualquier cliente de IA puede consolidar el estado del proyecto de forma autónoma con update_project_state. Ésta es la arquitectura "el cliente consolida, la cadena verifica": el modelo propone, el servidor valida, y recién ahí se convierte en estado.

Gramática de operaciones (29 ops)

Cada operación tiene un tipo (op) y sus propios argumentos. Usá evidence_memory_ids — un array de números de memoria — para vincular la evidencia que la respalda; el servidor resuelve los event hashes automáticamente.

Ejemplo

JSON — llamada a update_project_state
{
  "project": "mi-proyecto",
  "ops": [
    {
      "op": "add_decision",
      "title": "Migrar a PostgreSQL",
      "statement": "SQLite no soporta escrituras concurrentes a la escala actual",
      "evidence_memory_ids": [142, 145]
    },
    {
      "op": "set_metric",
      "name": "db_migration_status",
      "value": "planning"
    },
    {
      "op": "add_milestone",
      "title": "Migración a PostgreSQL aprobada por el equipo",
      "status": "done",
      "evidence_memory_ids": [145]
    }
  ],
  "consolidated_until_event": 150
}

Flujo de trabajo

El flujo típico con MCP:

Flujos avanzados

Claude Desktop — sesiones de arquitectura

Claude es muy bueno en diseño de alto nivel. Usá ChainMemory para preservar las decisiones de arquitectura entre sesiones:

Patrón de prompt — Claude Desktop
"Antes de empezar, cargá el estado de mi proyecto desde ChainMemory.
Después diseñemos el sistema de autenticación.

Cuando decidamos, guardá las decisiones clave con tags 'architecture'
y 'auth'. Usá importancia 9 para todo lo que afecte a otros
miembros del equipo, y después propone las operaciones para
consolidar el estado."

Claude lee el estado con get_project_state, trabaja con vos en el diseño, guarda las decisiones con chainmemory_remember, y propone la consolidación con update_project_state. En la sesión siguiente, la arquitectura de auth ya es parte del estado.

Cursor — código con memoria

La integración MCP de Cursor le permite a tu IA de código recordar por qué el código se escribió de cierta manera. La configuración es la misma que para Claude Desktop, en settings.json.

Un flujo efectivo:

• Inicio de sesión — "Cargá el estado del proyecto": decisiones vigentes, riesgos abiertos y prioridades
• Durante el desarrollo — "Guardá: implementé el handler de webhooks con reintentos, 3 intentos con backoff exponencial"
• Corrección de bugs — "Guardá: arreglé la race condition en el procesamiento de pagos — el webhook de Stripe llegaba antes de que la transacción de DB commiteara"
• Fin de sesión — "Consolidá lo que cambió hoy", que propone las operaciones y actualiza el estado

Patrón de memoria agéntica

El patrón más potente de MCP es la memoria agéntica, donde la IA gestiona su propio conocimiento:

System prompt para memoria agéntica
Tenés acceso a ChainMemory por MCP. Seguí estas reglas:

1. Al inicio de sesión: llamá a get_project_state para cargar el
   estado consolidado del proyecto.
2. Cuando tomes una decisión significativa: guardala con
   chainmemory_remember.
   - Incluí POR QUÉ elegiste ese camino
   - Etiquetala con el dominio relevante
   - Importancia 1-10: usá 7 o más para decisiones, 5 para
     observaciones
3. Cuando completes un milestone: guardalo y decí qué sigue.
4. Cuando identifiques un riesgo: guardalo con su severidad.
5. Al cerrar la sesión: proponé la consolidación con
   update_project_state. No cierres ni supersedas ítems
   existentes sin aprobación del dueño: agregá en estado
   propuesto y dejá que un humano confirme.

API REST

Autenticación

Todas las llamadas a la API requieren autenticación mediante API Key en el header:

HTTP
x-api-key: tu-api-key

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

Memorias

bash
curl -X POST https://api.chainmemory.ai/v1/memory \
  -H "x-api-key: tu-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "summary": "Decidimos usar PostgreSQL en vez de MongoDB",
    "category": "decision",
    "importance": 8,
    "platform": "manual"
  }'

javascript
const res = await fetch('https://api.chainmemory.ai/v1/memory', {
  method: 'POST',
  headers: {
    'x-api-key': 'tu-api-key',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    summary: 'Decidimos usar PostgreSQL en vez de 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': 'tu-api-key'},
    json={
        'summary': 'Decidimos usar PostgreSQL en vez de MongoDB',
        'category': 'decision',
        'importance': 8,
        'platform': 'api'
    }
)
memory = res.json()
# {'id': 207, 'hash': '0x4f2a...', 'memory_number': 42}

Parámetros

Proyectos

Respuesta
{
  "project": "chainmemory",
  "version": 3,
  "state": {
    "context": {
      "summary": "Plataforma de memoria IA con verificación blockchain",
      "goals": ["Memoria persistente cross-model", "Pista de auditoría criptográfica"]
    },
    "decisions": [
      {
        "id": "d001",
        "title": "Usar Clique PoA",
        "statement": "Consenso PoA para blockchain soberana",
        "status": "confirmed",
        "evidence": ["#12", "#45"]
      }
    ],
    "milestones": [
      {
        "id": "m001",
        "title": "MVP API desplegado",
        "status": "completed",
        "date": "2026-04-15",
        "evidence": ["#5", "#18"]
      }
    ],
    "risks": [
      {
        "id": "r001",
        "title": "Latencia del motor de consolidación a escala",
        "severity": "medium",
        "status": "open",
        "mitigation": "Evaluar modelos más grandes al escalar infra",
        "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
  }
}

Inyección

Respuesta

El endpoint devuelve las memorias seleccionadas formateadas para inyección. Cada memoria llega con su número visible para el usuario y una referencia de verificación, de modo que una IA puede citar la memoria exacta detrás de cualquier afirmación — y vos podés rastrear esa cita hasta su evidencia on-chain. Una afirmación deja de ser "confiá en mí" y pasa a ser "acá está la memoria, verificala vos mismo."

Verificación

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

Códigos de error

Equivalencia de funciones: Extensión ↔ MCP ↔ API

No todas las funciones están disponibles en todos los métodos de integración. Esta tabla muestra qué hay disponible dónde:

Confianza y Gobierno

Cada memoria lleva un estado de confianza desde el momento en que se escribe: trusted, tentative (marcada al escribirse por reglas de evaluación deterministas), o quarantined (condenada por el dueño). Las tentative siempre se entregan marcadas — el agente ve la marca y decide. Las quarantined se excluyen de context, inject, quotes y consultas al oracle, mientras su huella on-chain permanece como evidencia inmutable. Todas las respuestas de lectura incluyen el campo trust.

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

Acciones: approve → trusted · quarantine → quarantined · tentative → tentative. La respuesta incluye el estado anterior para auditoría.

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

Eventos: born, trust, batched, checkpoint_anchored, recalled (cada lectura, con endpoint y consulta), injected (cada entrega, con plataforma destino), cited_as_evidence (ítems del Project Brain que citan esta memoria). Incluye contadores con verificación cruzada y prueba de anclaje on-chain. Responde la pregunta forense: qué memoria causó qué, cuándo entró, quién la leyó y a dónde llegó.

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

Restauración append-only: volver a la versión N jamás borra nada — crea una versión nueva cuyo contenido es byte-idéntico a N. Como los hashes se computan sobre bytes canónicos, el hash de la versión nueva es igual al ya anclado on-chain para N: la fidelidad de la restauración es un hecho matemático, no una promesa. Antes de restaurar, el servidor recomputa el hash del contenido almacenado y se niega (HTTP 409) si no coincide — la corrupción nunca puede restaurarse. La historia jamás se muta.

RED

Datos de la red

Contratos desplegados

El Token AIC es la moneda nativa de la red (no es un contrato ERC-20). Se usa para pagar el fee de protocolo de toda operación de escritura. Cada fee se parte por la mitad: el 50% se quema de forma permanente y el 50% va a la tesorería del ecosistema.

Fee Schedule v1.0

Toda operación de escritura paga un fee de protocolo. El 50% se quema de forma permanente (presión deflacionaria) y el 50% va a la tesorería. Las lecturas y el registro de identidad son gratis.

Conectar MetaMask

Para agregar ChainMemory a MetaMask:

1. Ir a chainmemory.ai/network
2. Click en "Add ChainMemory to MetaMask"
3. Confirmar en MetaMask

O agregala manualmente con los datos de la tabla anterior.

Faucet

El faucet entrega AIC gratis para que puedas interactuar con la blockchain:

• URL: faucet.chainmemory.ai
• Cantidad: 1 AIC por claim
• Cooldown: 72 horas entre claims
• Requisito: Resolver un challenge simple (anti-bot)

PROTOCOLO DE IDENTIDAD IA

Cada agente de IA que usa ChainMemory obtiene una identidad única e intransferible en la blockchain — un Soulbound Token (SBT) que prueba quién escribió una memoria, cuándo y desde qué modelo. Esta es la base de la confianza en un mundo multi-agente.

El Problema

En los sistemas de IA actuales, no hay forma de responder preguntas fundamentales:

• ¿Qué IA escribió esta respuesta? ¿Fue Claude, GPT-4, o un modelo fine-tuned?
• ¿Es el mismo agente con el que trabajé ayer, o una instancia diferente?
• ¿Puedo confiar en la memoria de este agente si no conozco su identidad?
• ¿Cómo pruebo la procedencia cuando múltiples agentes colaboran?

Sin identidad, no hay responsabilidad. Sin responsabilidad, no hay confianza.

Cómo Funciona

Detalles del Contrato

Trust Score (Roadmap)

El protocolo de identidad habilita un futuro AI Trust Score — una métrica de reputación basada en interacciones verificables:

• Cantidad de memorias — ¿Cuántas memorias verificadas ha producido este agente?
• Consistencia — ¿Con qué frecuencia las memorias del agente pasan la validación anti-alucinación?
• Tasa de anclaje — ¿Qué porcentaje de memorias están respaldadas por pruebas on-chain?
• Historial de colaboración — ¿Ha participado este agente en workflows multi-agente?

Identidad en Workflows Multi-Agente

Cuando múltiples agentes colaboran en el mismo proyecto (ver Sistemas Multi-Agente), las contribuciones de cada agente se atribuyen individualmente:

Cadena de evidencia
Proyecto: "payment-system-v2"
├── Memoria #1 por Claude (ai_id: 0xA1...) — "Usar Stripe para pagos"
├── Memoria #2 por GPT-4 (ai_id: 0xB2...) — "Agregar capa de detección de fraude"
├── Memoria #3 por Cursor (ai_id: 0xC3...) — "Implementado handler de webhooks"
└── Estado v4 anclado — los 3 agentes contribuyeron, todo verificable

La identidad de cada agente es verificable independientemente on-chain. No hay ambigüedad sobre quién contribuyó qué.

Verificar una Identidad

Podés verificar cualquier identidad de IA usando la blockchain directamente:

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 ? 'Identidad IA verificada' : 'Sin identidad registrada');

SISTEMAS MULTI-AGENTE

ChainMemory fue diseñado desde cero para un mundo donde múltiples agentes de IA colaboran en el mismo proyecto. Cada agente lee el mismo Project State, cada contribución se atribuye individualmente, y cada handoff es trazable.

El Problema Multi-Agente

Los flujos de trabajo de desarrollo modernos ya involucran múltiples agentes de IA:

• Claude diseña la arquitectura y escribe documentación
• Cursor implementa el código con asistencia IA inline
• GPT-4 revisa PRs y analiza implicaciones de seguridad
• Gemini procesa codebases grandes para sugerencias de refactoring

Sin memoria compartida, cada agente empieza de cero. Las decisiones tomadas en Claude son invisibles para Cursor. La arquitectura acordada en GPT es desconocida para Gemini. Vos te convertís en el cuello de botella — constantemente re-explicando contexto.

Cómo ChainMemory Resuelve Esto

Project State Compartido

Todos los agentes conectados al mismo proyecto ven el mismo estado consolidado: decisiones, hitos, riesgos, stack y contexto. Cuando Claude marca una decisión como "active", Cursor la ve inmediatamente.

Flujo de Estado Compartido
┌──────────┐    ┌──────────────────────────┐    ┌──────────┐
│  Claude  │───▶│                          │◀───│  Cursor  │
│  (MCP)   │    │   Proyecto ChainMemory   │    │  (MCP)   │
└──────────┘    │                          │    └──────────┘
                │  decisions: [d001, d002]  │
┌──────────┐    │  milestones: [m001]      │    ┌──────────┐
│  GPT-4   │───▶│  risks: [r001, r002]     │◀───│  Gemini  │
│  (API)   │    │  stack: [Node, Redis]    │    │  (API)   │
└──────────┘    └──────────────────────────┘    └──────────┘

Patrón Agent Handoff

Cuando el trabajo pasa de un agente a otro, ChainMemory proporciona transferencia de contexto sin fricciones:

Claude guarda
chainmemory_remember({
  content: "Usar PostgreSQL con row-level security para aislamiento multi-tenant",
  tags: ["architecture", "database", "security"],
  importance: 0.9
})

Cursor recibe (via inject)
Project State v3:
- Decisión d001: "Usar PostgreSQL con RLS" (active, evidence: #12, #15)
- Decisión d002: "API REST con endpoints versionados" (active, evidence: #18)
- Hito m001: "Schema de BD completo" (pendiente)
- Riesgo r001: "Performance de RLS en tenants grandes" (medio, evidence: #15)

Patrones de Handoff

Resolución de Conflictos Entre Agentes

Cuando dos agentes toman decisiones contradictorias, la Resolución de Conflictos de ChainMemory aplica las mismas reglas:

• Precedencia temporal — La decisión más reciente gana, sin importar qué agente la tomó
• Peso de evidencia — Una decisión respaldada por 5 memorias de 3 agentes es más fuerte que una con una sola memoria
• Supersesión explícita — Cualquier agente puede explícitamente reemplazar una decisión anterior referenciándola
• Auditoría completa — Tanto la decisión original como la que la reemplaza se preservan con su respectiva atribución de ai_id

Configurar Multi-Agente

No se necesita configuración especial. Cualquier agente conectado al mismo proyecto participa automáticamente en la colaboración multi-agente:

1. Crear un proyecto vía Extension, MCP, o API
2. Usar la misma API key en todos los agentes (o crear keys específicas por agente bajo la misma cuenta)
3. Cada agente usa inject_memories al inicio de sesión para cargar contexto compartido
4. Cada agente usa chainmemory_remember para guardar contribuciones
5. El Motor de Consolidación fusiona todas las contribuciones en el Project State unificado

HERMES AGENT

Hermes Agent es un framework de agentes IA open-source y agnóstico al proveedor. ChainMemory se integra por dos vías: el servidor MCP (herramientas nativas dentro del chat) o el wrapper cm.py CLI (control total desde terminal).

Requisitos previos

• Hermes Agent instalado (Windows, macOS, Linux, WSL)
• Cuenta ChainMemory con API key (formato: aic_...)
• Python 3.10+ (para wrapper cm.py)

Obtener tu API Key

Las cuentas ChainMemory se crean exclusivamente desde la Extensión Chrome:

1. Instalá la Extensión ChainMemory
2. Abrí el popup desde la barra del navegador
3. Elegí "Generar API Key automáticamente" (wallet gratis + 1 AIC) o "Ya tengo una key"
4. Andá a Configuración → Conexión y hacé clic en "Ver" para copiar tu key

Importante: El Faucet (faucet.chainmemory.ai) solo distribuye tokens AIC para operaciones on-chain, no emite API keys. La API key se obtiene únicamente desde la Extensión.

Opción A: Servidor MCP (Flujo de chat)

El servidor MCP expone ChainMemory como herramientas nativas dentro del chat de Hermes. Después de configurar, podés decir cosas como "Recordá: decidimos usar PostgreSQL" y Hermes llamará la herramienta automáticamente.

Configuración

Editá ~/.hermes/config.yaml y agregá:

YAML — ~/.hermes/config.yaml
mcp_servers:
  chainmemory:
    command: "python"
    args: ["C:\\Users\\<usuario>\\.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"

Reiniciá Hermes después de editar. Las herramientas aparecen como mcp_chainmemory_* en el chat.

Herramientas MCP Disponibles

Opción B: Wrapper cm.py (CLI / Scripts)

cm.py es un CLI Python que envuelve la API REST. Maneja headers de auth, pacing y reintentos. Instalalo via el skill de ChainMemory:

bash
hermes skills install chainmemory

Luego configurá tu key:

bash
chmod 600 ~/.hermes/chainmemory.env

Comandos

Opción C: API REST Directa

Cualquier cliente HTTP funciona. URL base: https://api.chainmemory.ai/v1. Header de auth: x-api-key: aic_... (no Authorization: Bearer).

Notas importantes

• Header de auth: Usá x-api-key, no Authorization: Bearer.
• Rate limits: 30–600 req/min según plan.
• El estado no se construye solo: no hay consolidación en el backend ni disparador automático. El Project State cambia únicamente cuando un cliente propone operaciones vía update_project_state (MCP) o POST /v1/project/:name/state/ops (API). Esperar no va a producir un estado — pedirlo, sí.
• Qué significa "seal" acá: en la API y el servidor MCP de ChainMemory, seal vuelve permanentemente inmutable una sola memoria (POST /v1/seal/:id, que toma tu número de memoria). El Project State se ancla como parte de la consolidación, no sellando. cm.py es un wrapper de terceros y puede mapear sus comandos de otra forma.
• Paths en Windows: En config.yaml, usá doble backslash: C:\\Users\\<usuario>\\...

Verificar la configuración

bash
# vía MCP (en chat)
"Guardá esto: decidimos usar PostgreSQL para la base primaria"

# vía CLI
cm whoami
cm save "Decidimos usar PostgreSQL para DB primaria" --project mi-app --tags decision,stack
cm state mi-app
cm verify mi-app

GUÍA DE AUDITORÍA

Una de las capacidades más poderosas de ChainMemory es permitir auditorías verificables de decisiones de proyecto asistidas por IA — sin exponer el contenido privado de las conversaciones.

Dos niveles de auditoría

Nivel 1 — Auditoría externa (sin acceso del dueño)

Cualquiera puede verificar que un estado de proyecto fue anclado en un momento específico, sin ver qué contiene. Es como ver un sello notarial cerrado — sabés que existe, no sabés qué dice adentro.

Lo que un auditor externo ve (público, on-chain):

Nivel 1 — Endpoint público
GET /v1/project/nova-logistics/state/anchor

Respuesta:
{
  "project": "nova-logistics",
  "projectId": "0x77f7d980...",     // hasheado — nombre original no se revela
  "version": 5,
  "state_hash": "a7b3c9f2e1...",   // prueba que el estado existió, no revela contenido
  "anchor": {
    "status": "anchored",
    "tx_hash": "0xce55a800...",
    "block_number": 125000,
    "contract": "0xa7A8BA51...e7875"
  }
}

Nivel 2 — Auditoría con disclosure selectivo (el dueño comparte datos)

El dueño del proyecto elige qué compartir con el auditor. El auditor verifica los datos compartidos contra la prueba on-chain. Esta es la auditoría poderosa: demostrás que los datos son auténticos sin intermediarios.

El dueño controla exactamente qué se revela:

Proceso de auditoría paso a paso

Ejemplo: NovaTech, una startup construyendo un SaaS de logística. Después de 4 meses usando ChatGPT y Claude alternadamente, el CTO necesita demostrar trazabilidad del proyecto a inversores.

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
# Retorna: state_hash: "a7b3c9f2e1d4..."
    

Garantías de privacidad durante la auditoría

La garantía crítica: el dueño siempre controla el disclosure.

• Los inversores ven decisiones e hitos — no las conversaciones crudas de IA que las produjeron
• La blockchain prueba autenticidad sin revelar contenido
• El texto de memorias (contenido real de conversaciones) solo es visible si el dueño lo exporta explícitamente
• El registro on-chain contiene hashes más el contenido cifrado de las memorias — aunque la blockchain sea pública, sin tu llave nada de eso es legible
• Ningún tercero, incluyendo ChainMemory mismo, puede forzar el disclosure del contenido de memorias

QUÉ PREVIENE CHAINMEMORY

Entender contra qué protege ChainMemory es tan importante como entender qué hace.

Pérdida de contexto

Cada conversación de IA hoy es efímera. Cerrás la pestaña y todo lo discutido — decisiones, elecciones de arquitectura, hallazgos de investigación — desaparece. ChainMemory captura esto como memorias permanentes y recuperables. Tu próxima sesión arranca donde terminó la anterior.

Vendor lock-in

Si el conocimiento de tu proyecto existe solo dentro del historial de conversaciones de ChatGPT, estás atrapado. ChainMemory almacena conocimiento independientemente de cualquier proveedor de IA. Cambiá de ChatGPT a Claude a Gemini sin perder una sola decisión o contexto.

Manipulación retroactiva

Sin prueba criptográfica, cualquiera podría afirmar "decidimos X" cuando la decisión real fue Y. El anclaje on-chain de ChainMemory crea un registro a prueba de manipulación. El state hash en el bloque 123539 prueba exactamente cuál era el estado del proyecto en ese momento. No se puede alterar después del hecho.

Fragmentación de conocimiento

Equipos que usan IA terminan con conocimiento crítico disperso en docenas de conversaciones desconectadas, en diferentes herramientas, con diferentes modelos. ChainMemory consolida todo en un único Project State estructurado — sin importar qué IA o herramienta produjo la conversación original.

Dependencia de una sola IA

Cuando un proveedor de IA se cae, cambia su API, o depreca una funcionalidad, proyectos que dependen exclusivamente de ese proveedor pierden continuidad. La arquitectura cross-model de ChainMemory asegura que tu conocimiento acumulado es accesible desde cualquier sistema de IA compatible.

Deriva invisible de decisiones

En proyectos de largo plazo, las decisiones evolucionan durante meses. Sin un sistema que rastree qué cambió, cuándo, y por qué, los equipos pierden el hilo de su propio razonamiento. El ciclo de vida de decisiones del Motor de Consolidación (vigente → reemplazada) con cadenas de evidencia hace cada evolución rastreable.

MODELO DE CONFIANZA

Qué podés — y qué no podés — confiar

ChainMemory combina una API centralizada con verificación descentralizada. Entender los límites de confianza es crítico para evaluar si ChainMemory cumple tus requisitos de seguridad.

Tabla de garantías

Niveles de confianza

Soberanía — no-custodial

ChainMemory está migrando a un modelo no-custodial donde tu llave vive en tu cliente, no en el servidor. Vos firmás tus propias escrituras on-chain; el servidor guarda el texto cifrado y verifica las firmas, pero nunca tiene tu llave privada. Esto se probó de punta a punta — una memoria escrita 100% del lado del cliente, con el servidor sin tocar nunca la llave.

MODELO DE AMENAZAS

Ataques, detección y lo que está fuera de alcance

Ningún sistema es invulnerable. Esta sección mapea la superficie de ataque, qué detecta o previene ChainMemory, y qué sigue siendo responsabilidad del usuario.

Vectores de ataque

Fuera de alcance

ChainMemory no protege contra:

• Usuario almacenando información falsa — si guardás una mentira como memoria, ChainMemory la ancla fielmente. El sistema garantiza integridad (los datos no cambiaron), no veracidad (los datos eran correctos).
• Dispositivo del usuario comprometido — si tu máquina tiene malware, tu API Key y datos locales están expuestos antes de llegar a ChainMemory.
• Alucinaciones de la IA — ChainMemory almacena lo que vos guardás, no lo que una IA genera. No valida si la salida de la IA fue precisa.

VERIFICACIÓN INDEPENDIENTE

Verificá anclas on-chain sin confiar en nadie

No necesitás la API de ChainMemory para verificar que un estado de proyecto fue anclado en un bloque específico. Esta página muestra cómo verificar directamente contra la blockchain usando herramientas Web3 estándar.

Qué necesitás

• El hash del estado del proyecto (de la API o compartido por alguien)
• El hash de la transacción o número de bloque del ancla
• Node.js con ethers instalado — o cualquier librería Web3

Paso 1 — Obtener los datos del ancla

Usá el endpoint público (sin autenticación) de ChainMemory o recibilos de quien compartió la prueba:

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

Respuesta
{
  "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)"
}

Paso 2 — Verificar on-chain con Ethers.js

Conectate directamente al RPC de ChainMemory y leé el smart contract. Sin API Key, sin cuenta, sin confianza requerida.

javascript
import { ethers } from 'ethers';

// Conectar al RPC de ChainMemory — sin API Key necesaria
const provider = new ethers.JsonRpcProvider('https://rpc.chainmemory.ai');

// Contrato ProjectStateAnchor
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);

// El project ID es el keccak256 del nombre del proyecto
const projectId = ethers.keccak256(ethers.toUtf8Bytes('chainmemory'));
const version = 8;

// Leer directamente de la blockchain
const [stateHash, anchoredAt, anchoredBy, anchorId] = await contract.getStateAnchor(projectId, version);

console.log('Hash on-chain del estado:', stateHash);
console.log('ID de ancla:', anchorId.toString());
console.log('Anchored at:', new Date(Number(anchoredAt) * 1000).toISOString());

// Comparar con el hash que recibiste
const expectedHash = '0xa6c45d1db753b1ec96240d169b2d91fb0ce76112558b302a8822b2988aeb8212';
if (stateHash === expectedHash) {
  console.log('VERIFICADO — el estado coincide con el ancla on-chain');
} else {
  console.log('DISCREPANCIA — el estado fue manipulado');
}

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('Hash on-chain del estado:', result.stateHash);
console.log('ID de ancla:', result.anchorId);

Paso 3 — Verificar la transacción

También podés verificar la transacción cruda que creó el ancla:

javascript
// Leer la transacción directamente
const tx = await provider.getTransaction('0x95b732d20b8935a286869d90e60a40f5c31d350a94e27bfd7845770fe0c3e2c3');
console.log('From:', tx.from);       // Debería ser un validador conocido
console.log('To:', tx.to);           // Debería ser la dirección del contrato
console.log('Block:', tx.blockNumber);

// Leer el bloque para confirmar timestamp
const block = await provider.getBlock(tx.blockNumber);
console.log('Hora del bloque:', new Date(block.timestamp * 1000).toISOString());

FAQ

Generales

ChainMemory es gratis?

Sí. El plan Faucet es gratuito e incluye almacenamiento de memorias, inyección de contexto, y Project Brain (el visor de Project State). El faucet te da AIC gratis para interactuar con la blockchain.

Mis memorias son privadas?

Sí. Tus memorias solo son accesibles con tu API key. Lo único público son los hashes on-chain (que no revelan contenido) y el endpoint de verificación (que solo expone metadata, nunca contenido).

Qué pasa si la IA generó contenido incorrecto en una memoria?

Las memorias capturan lo que se dijo en la conversación. Si la IA generó información incorrecta y vos la guardaste, esa memoria reflejará el error. Podés archivar memorias incorrectas y el Motor de Consolidación priorizará las más recientes.

Puedo usar ChainMemory con modelos locales?

Sí, vía API REST. Cualquier aplicación que haga llamadas HTTP puede guardar y recuperar memorias. También podés configurar el servidor MCP con modelos locales o self-hosted.

Qué es el Motor de Consolidación?

Es un pipeline que analiza tus memorias usando un modelo de IA y extrae información estructurada: decisiones, hitos, riesgos, stack. El resultado es el Project State, cuyo hash se ancla on-chain.

Qué pasa si mi IA dice cosas contradictorias entre sesiones?

El Motor de Consolidación maneja contradicciones vía precedencia temporal: las memorias más nuevas reemplazan a las más viejas. Las decisiones reemplazadas permanecen en el estado con status "reemplazada", así siempre tenés el historial completo. Ver Resolución de conflictos para más detalles.

Puedo exportar mis datos?

Sí. Todas tus memorias y estados de proyecto son accesibles vía la API REST. Podés obtenerlos en formato JSON y procesarlos como necesités.

Planes, límites y cuotas

Las memorias nunca se borran: al superar la ventana de retención de tu plan se archivan, y su hash on-chain existe para siempre. Al subir de plan recuperás el acceso completo a tu historial. El AIC de obsequio se acumula mes a mes, no expira y se libera según el calendario del protocolo.

LÍMITES Y CUOTAS

Los fees de protocolo en AIC son idénticos en todos los planes: una cuenta Free y una Enterprise pagan lo mismo por operación. Lo que cambia el plan es el volumen — y cuánto de ese volumen el sistema hace cumplir hoy. Las dos cosas están abajo, separadas a propósito.

Límites por plan

Estos son los valores de la tabla tier_entitlements que el servidor lee en tiempo de ejecución, no un resumen de marketing. Un valor ilimitado se guarda como -1, y el chequeo se saltea por completo.

Qué se reinicia, y cuándo

• Las memorias y las inyecciones son mensuales. El contador vuelve a empezar el primer día de cada mes a las 00:00 UTC. Free te da 100 memorias por mes, no 100 en total.
• Los proyectos son un tope simultáneo, no una cuota mensual: es cuántos podés tener a la vez. Borrar uno libera un lugar.

Qué se hace cumplir hoy

El servidor chequea tres operaciones contra tu plan: guardar una memoria, inyectar contexto y crear un proyecto.

Con el bloqueo activo, pasarse de un límite devuelve 402 con plan_limit_reached, el límite, tu consumo y un enlace para subir de plan. Un límite nunca toca tus datos: leer, verificar y exportar siguen funcionando igual.

Qué está declarado pero todavía no se aplica

Estos valores están publicados, los devuelve la API y son parte del plan — pero nada actúa sobre ellos todavía. Los listamos acá en vez de dejar que se descubran solos:

• Requests por minuto — el número es real y está documentado, pero hoy ningún limitador lo lee.
• Retención — no se archiva ni se elimina nada cuando vence el período. Las memorias no se borran nunca en ningún caso, y la huella on-chain es permanente sin importar el plan.
• Usuarios y claves de proyecto — el módulo de organizaciones los emite; el tope no se chequea al emitirlos.
• Asignación mensual de AIC — los montos están definidos pero la acreditación no está implementada. La propia API lo dice: crediting: "Sprint B3 (pendiente)".

Changelog

MCP v2.4.0 (Junio 2026)

• Nuevo tool: update_project_state — Consolidación autónoma vía MCP. Cualquier cliente de IA puede proponer operaciones estructuradas para actualizar el Project Brain; el servidor valida, aplica y ancla on-chain.
• Gramática de 22 operaciones para mutaciones de estado (decisiones, hitos, riesgos, métricas, vocabulario, y más)
• Procesamiento resiliente: las ops inválidas se rechazan individualmente, las válidas se aplican igual
• Vinculación de evidencia vía evidence_memory_ids — el servidor resuelve event hashes y construye pruebas Merkle automáticamente
• Arquitectura: “el cliente consolida, la cadena verifica”

Plataforma — Junio 2026

• Project Brain consolidado y anclado on-chain (versiones v1–v8, verificable públicamente)
• Búsqueda semántica reescrita (más rápida, ~2.4s)
• Escritura no-custodial probada end-to-end (el cliente firma, el server nunca tiene la llave)
• Cifrado en reposo (AES-256-GCM) de las API keys
• Endpoint de verificación pública: GET /v1/verify/:name

v3.0.9 (Junio 2026)

• Fix: Project Brain muestra decisiones y riesgos correctamente (schema Fase 2)
• Fix: Numeración de memorias muestra número secuencial del usuario

v3.0.0 (Mayo 2026)

• Project Brain: visualización del estado consolidado
• Motor de Consolidación: pipeline completo
• Anclaje on-chain de Project State
• API de verificación pública

v2.0.0 (Abril 2026)

• Servidor MCP para Claude Desktop y Cursor
• Inyección de contexto automática
• Soporte para 5 plataformas de IA