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 — Tu cliente de IA convierte las conversaciones en decisiones, hitos, riesgos y prioridades, cada una citando las memorias que la respaldan. 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 servidor las valida contra las invariantes de la gramática, comprueba que cada memoria citada se resuelva a un event hash anclado y las aplica con un builder determinista: el modelo propone, el servidor decide. Nada en el servidor lee memorias para extraer conocimiento por su cuenta.

Capa 3: Verificación On-Chain

Cada versión del estado consolidado de un proyecto se ancla en la blockchain ChainMemory, normalmente en menos de diez minutos desde que se escribe (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)
      |
  El cliente propone ops citando memorias (MCP / API)
      |
  Validación del servidor + builder determinista
      |
  Project State (decisiones, hitos, riesgos, prioridades, entorno)
      |
  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: trabaja solo con memorias de conversaciones IA y las convierte en inteligencia de proyecto estructurada (un Project State cuyos ítems citan sus memorias) 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 construida a partir de esos eventos — Un cliente lee las memorias y propone operaciones que las citan; el servidor las valida, las aplica y guarda cada versión resultante. El estado no se recalcula solo desde el log: cambia únicamente cuando un cliente consolida.
• 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) ─┼──→ ops de un cliente ──→ Project State v1 ──→ Anchor (bloque 120000)
Memoria #4 (evento) ─┤
Memoria #5 (evento) ─┘

Memoria #6 (evento) ─┐
Memoria #7 (evento) ─┼──→ ops de un cliente ──→ Project State v2 ──→ Anchor (bloque 123539)
Memoria #8 (evento) ─┘

Las memorias son la fuente de verdad y no cambian. Cada versión del estado registra en qué memorias se apoyó, así que cualquier ítem se puede rastrear hasta su evidencia. El anchor prueba qué estado existía en qué bloque.

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 Project State tiene sus propios campos fijos (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 (también llamado Project Brain) es la vista consolidada y versionada de un proyecto. No lo genera un motor en el servidor: un cliente — un modelo de IA que trabaja con update_project_state (MCP) o POST /v1/project/:name/state/ops (API) — propone operaciones, el servidor las valida contra una gramática cerrada, las aplica con un constructor determinístico y calcula el nuevo state_hash. Cada ítem registra las memorias que lo justifican.

Qué contiene el estado (versión de esquema 2)

Ciclo de vida del estado

El estado es incremental y append-only: cada consolidación parte de la versión anterior y aplica solo las operaciones nuevas. Cada versión lleva su state_hash (SHA3-256 del estado canónico, con separador de dominio CM_PROJECT_STATE_V<schema_version>) y, en state_meta, el hash de la versión anterior. Una vez escrita, el hash de la versión se ancla on-chain en el contrato ProjectStateAnchor, normalmente en menos de diez minutos.

Cadena de versiones
v85 ──previous_state_hash──▶ v86 ──previous_state_hash──▶ v87
 │                            │                            │
 └─ anchorId 89               └─ anchorId 90               └─ anchorId 94

Ejemplo: lo que devuelve GET /v1/project/:name/state (recortado)

JSON
{
  "project": "sistema-pagos",
  "schema_version": 2,
  "version": 4,
  "state_hash": "0x3f8c2a…e91d",
  "generated_at": "2026-09-13T22:02:35.000Z",
  "anchor": { "status": "anchored", "onchain_anchor_id": 12, "tx_hash": "0x…", "block_number": 681919 },
  "state": {
    "phase": "beta",
    "current_focus": "Revisión PCI antes de abrir a los primeros tenants",
    "decisions": [
      { "id": "dec_0002", "title": "PostgreSQL con RLS para multi-tenancy",
        "statement": "La seguridad por fila saca el filtrado por tenant de la capa de aplicación",
        "status": "confirmed", "superseded_by": null,
        "evidence_root": "0x9a41…c07e", "created_version": 2, "updated_version": 3 }
    ],
    "milestones": [
      { "id": "mil_0001", "title": "Schema de BD", "status": "done",
        "evidence_root": "0x5b2d…81fa", "created_version": 1, "updated_version": 2 }
    ],
    "risks": [
      { "id": "risk_0001", "title": "Performance de RLS con 100K tenants", "severity": "med", "status": "open",
        "evidence_root": "0xd7e0…2a19", "created_version": 3, "updated_version": 3 }
    ],
    "state_meta": { "version": 4, "consolidated_until_event": 150, "previous_state_hash": "0x7b2e…f4c0" }
  }
}

GET /v1/project/:name/state requiere la API key del dueño y siempre devuelve la versión más reciente. Las versiones anteriores se pueden verificar por hash (ver Hash y verificación), no volver a leer completas con este endpoint.

Buenas prácticas

• Primero guardá la memoria, después consolidá — el estado cita memorias; una decisión que solo existe en la operación no tiene respaldo
• Esperá el anclaje antes de citar — una memoria en texto plano recibe su event_hash al sincronizarse con la cadena, unos 30 segundos después de escribirla
• Avanzá la marca — enviá consolidated_until_event con el número de memoria más alto que realmente revisaste
• Reemplazá, no reescribas — una decisión reemplazada queda en el estado con su estado cambiado, así se conserva cómo evolucionó el proyecto

Cadena de evidencia

Cuando un cliente propone una operación, cita las memorias que la respaldan en evidence_memory_ids — un array de números de memoria. El servidor resuelve cada una a su event_hash y guarda en el ítem resultante la raíz Merkle de esos hashes como evidence_root.

Operación que envía el cliente
{
  "op": "add_decision",
  "title": "Usar consenso Clique PoA",
  "statement": "Proof of Authority da un anclaje rápido y económico para una cadena soberana",
  "evidence_memory_ids": [12, 45, 67]
}

Ítem guardado en el estado
{
  "id": "dec_0001",
  "title": "Usar consenso Clique PoA",
  "statement": "Proof of Authority da un anclaje rápido y económico para una cadena soberana",
  "status": "proposed",
  "evidence_root": "0x028218d0…f082"
}

Esto crea una cadena de procedencia:

• La decisión dec_0001 existe porque las memorias 12, 45 y 67 la respaldan; la respuesta de la consolidación lista sus event hashes
• El event_hash de cada memoria se escribe on-chain cuando la memoria se sincroniza
• El evidence_root compromete exactamente ese conjunto de hashes
• El estado que contiene el ítem tiene un state_hash anclado en ProjectStateAnchor

Resolución de conflictos

Nada resuelve contradicciones automáticamente. No hay un motor que lea las memorias y decida cuál gana: decide el cliente que consolida, y la gramática hace que esa decisión quede explícita y auditable.

Reemplazar una decisión

Si una memoria más nueva cambia el rumbo, el cliente agrega la decisión nueva y marca la anterior con supersede_decision (id de la anterior, by_id de la nueva). Las dos quedan en el estado.

Estado de una decisión

Una decisión se crea como proposed. El cliente la pasa a confirmed o rejected con set_decision_status, y a superseded con supersede_decision.

Varios agentes en el mismo proyecto

Las operaciones se aplican sobre la versión vigente en el momento en que llega la llamada; /state/ops no comprueba una versión esperada. No se pierde nada — cada llamada crea una versión nueva — pero un agente que trabaja con una lectura vieja puede volver a agregar o contradecir lo que otro acaba de escribir. Leé el estado justo antes de consolidar. Cada llamada acepta hasta 100 operaciones.

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. El dueño lee la versión más reciente con GET /v1/project/:name/state; el hash y el ancla on-chain de cualquier versión anterior son públicos en GET /v1/project/:name/state/anchor?version=2 y GET /v1/verify/:name.

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.

BÓVEDA CIEGA

Todo sistema de memoria te pide confiar en su operador. La bóveda ciega de ChainMemory elimina ese requisito para las memorias que tú elijas: el contenido se cifra en tu navegador, con una clave derivada de doce palabras que nunca salen de tu dispositivo, y el servidor guarda un blob que no puede leer.

No es cifrado en reposo con una clave que tiene el proveedor. Es cifrado que el proveedor no puede deshacer — y más abajo hay una prueba que lo demuestra, junto con una descripción honesta de lo que esta función no cubre.

Cómo funciona

1. Doce palabras. Se genera en el cliente una frase BIP-39, con la lista oficial de 2048 palabras y su checksum. Es lo único que puede recuperar tu contenido.
2. Semilla y clave. La frase se estira a una semilla con PBKDF2-HMAC-SHA512, y de ahí se deriva la clave de contenido con HKDF-SHA256.
3. Cifrado. El texto se sella con AES-256-GCM en un envoltorio versionado: 0x02 || IV || texto cifrado || tag. El cliente calcula además un event_hash (SHA-256) para la cadena.
4. Almacenamiento. El blob se envía a POST /v1/memory/sealed. El servidor cobra la tarifa habitual, ancla el hash y guarda bytes que no tiene forma de interpretar.
5. Recuperación. GET /v1/memory/:id/blob devuelve el blob, y el cliente lo descifra con la clave derivada de esas mismas doce palabras.

En ningún momento se transmite material de clave. Perder la frase significa perder el contenido: no hay vía de recuperación, y es deliberado, porque una vía de recuperación es justo lo que un operador necesitaría para leer tus memorias.

Endpoints

POST /v1/memory/sealed

La tarifa es la misma que la de una memoria normal. La privacidad no cuesta más.

Qué protege y qué no

Cuatro límites, dichos con claridad, porque una promesa de privacidad sin sus fronteras vale menos que no prometer nada:

• Los metadatos no se cifran. Fechas, tamaños, proyecto asociado y el hecho mismo de que la memoria existe siguen siendo visibles para el operador — y una parte es pública: GET /v1/memory/:id/verify devuelve, sin API key, categoría, importancia, fecha, largo, la marca is_sealed, el event hash. Ese endpoint no devuelve el texto cifrado, pero está guardado on-chain y cualquiera puede leerlo por la RPC pública (getMemory); sin tus doce palabras no se puede descifrar. Solo el contenido es ciego.
• Las memorias anteriores no se pueden sellar retroactivamente. Lo escrito antes de esta función sigue siendo legible por el servidor, y no hay migración que lo vuelva ciego, porque el servidor tendría que leerlo para volver a cifrarlo.
• El anclaje sigue siendo custodial. El servidor firma el anclaje en cadena. La firma no custodial queda para una fase posterior; hasta entonces se confía en el operador para anclar, nunca para leer.
• La frase es tuya y solo tuya. Sin restablecer, sin recuperación por soporte, sin puerta trasera.

Cómo verificarlo por tu cuenta

No nos creas. Sella una memoria y luego llama al endpoint heredado que descifra con la clave del propio operador:

curl https://api.chainmemory.ai/v1/memory/<id>/decrypted \
  -H "x-api-key: $CHAINMEMORY_API_KEY"

Sobre una memoria sellada devuelve 200 con scheme: "sealed" y el blob cifrado, nunca el texto. Esa es la prueba: /decrypted deriva su clave de tu API key, que es exactamente lo que tendría un operador —o cualquiera que comprometiera el servidor—. Ante una memoria sellada no tiene nada que descifrar, y lo único que puede entregarte son los bytes opacos.

El mismo blob, recuperado con /v1/memory/:id/blob y descifrado en tu cliente con las doce palabras, devuelve el texto original.

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 36 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

Contrato legible por máquinas: OpenAPI 3.1. Orientación para LLMs: api.chainmemory.ai/llms.txt.

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 (recortada)
{
  "project": "sistema-pagos",
  "schema_version": 2,
  "version": 4,
  "state_hash": "0x3f8c2a…e91d",
  "generated_at": "2026-09-13T22:02:35.000Z",
  "anchor": { "status": "anchored", "onchain_anchor_id": 12, "tx_hash": "0x…", "block_number": 681919 },
  "state": {
    "phase": "beta",
    "current_focus": "Revisión PCI antes de abrir a los primeros tenants",
    "decisions": [
      { "id": "dec_0002", "title": "PostgreSQL con RLS para multi-tenancy",
        "statement": "La seguridad por fila saca el filtrado por tenant de la capa de aplicación",
        "status": "confirmed", "superseded_by": null,
        "evidence_root": "0x9a41…c07e", "created_version": 2, "updated_version": 3 }
    ],
    "milestones": [
      { "id": "mil_0001", "title": "Schema de BD", "status": "done",
        "evidence_root": "0x5b2d…81fa", "created_version": 1, "updated_version": 2 }
    ],
    "risks": [
      { "id": "risk_0001", "title": "Performance de RLS con 100K tenants", "severity": "med", "status": "open",
        "evidence_root": "0xd7e0…2a19", "created_version": 3, "updated_version": 3 }
    ],
    "state_meta": { "version": 4, "consolidated_until_event": 150, "previous_state_hash": "0x7b2e…f4c0" }
  }
}

Siempre la versión más reciente; requiere la API key del dueño. Los valores de severidad son low, med y high.

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.

EQUIPOS Y ORGANIZACIONES

Una clave personal pertenece a una persona. Una organización permite que un equipo comparta un presupuesto, un conjunto de proyectos y un mismo rastro de auditoría, mientras cada miembro sigue trabajando con una clave propia. Todo lo que un miembro crea —memorias, proyectos, inyecciones— es rastreable hasta su correo y su rol, y retirarle el acceso es una sola llamada.

Las organizaciones están disponibles en los planes Team y Enterprise. Los nueve endpoints de abajo son toda la superficie: no hay panel de gestión, y para un comprador técnico eso suele ser una ventaja.

Flujo de activación

Una organización no queda operativa en el momento de crearse, y es a propósito:

1. Crearla. POST /v1/org con tu clave personal. Existe de inmediato, con status: "suspended" y ninguna clave activa.
2. Revisarla. GET /v1/org y GET /v1/org/members responden 200 desde el principio. Puedes ver lo que creaste antes de pagarlo.
3. Pagar. Hoy se gestiona fuera de la API; la activación se aplica cuando el pago se acredita.
4. Emitir claves e invitar. Solo después de la activación. Antes, ambas responden 402 organization_not_active.

Ese 402 es comportamiento esperado, no un fallo: las lecturas siguen abiertas en una organización suspendida, y todo lo que concede acceso no. La regla funciona también al revés: si se cancela la suscripción, la organización se suspende y todas las claves del equipo dejan de funcionar a la vez, sin necesidad de revocarlas una por una.

Claves y roles

Una clave de miembro gasta el presupuesto de la organización y lleva la identidad de esa persona. Una clave de proyecto está pensada para automatización: alcance a un solo proyecto, permisos limitados por role_cap y, si quieres, vida corta. La cantidad de claves de proyecto activas depende del plan: Team tiene tope, Enterprise no.

Una organización conserva siempre al menos un owner. Degradar al último devuelve 409, y un owner no se puede eliminar hasta cambiarle antes el rol. La API se niega a dejar un equipo sin nadie que pueda administrarlo.

Endpoints

POST /v1/org

Se autentica con tu clave personal. Una clave puede poseer una organización.

curl -X POST https://api.chainmemory.ai/v1/org \
  -H "x-api-key: $CHAINMEMORY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"org_slug":"acme-labs","name":"Acme Labs","owner_email":"ada@acme.dev"}'

Devuelve org_id, org_slug, tier y owner_member_id. Llamarlo dos veces con la misma clave devuelve 409.

POST /v1/org/invite

Añade un miembro. El correo debe ser válido y único dentro de la organización; repetirlo devuelve 409.

curl -X POST https://api.chainmemory.ai/v1/org/invite \
  -H "x-api-key: $ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"grace@acme.dev","role":"developer"}'

POST /v1/org/keys

La clave completa se devuelve una sola vez, en esta respuesta, y nunca más. Después, GET /v1/org/keys muestra únicamente su prefijo de 12 caracteres. Guárdala cuando la recibas.

Un miembro tiene una clave activa a la vez: emitir una segunda devuelve 409 y te pide revocar la anterior. Superar el tope de claves de proyecto de tu plan devuelve 402, con el tier y el limit vigentes en la respuesta.

DELETE /v1/org/members/:id

Quita al miembro y revoca sus claves en la misma operación; la respuesta informa cuántas con keys_revoked. Lo que esa persona ya escribió permanece en la organización, atribuido a ella. Termina el acceso, no la historia.

Errores

Los errores de permisos siempre dicen qué tenías y qué hacía falta, así que una llamada fallida trae consigo la información para corregirla.

CONTRATOS DE ROL

Un Contrato de Rol Verificable (VRC) es un documento firmado que declara para qué existe un rol, qué reglas lo obligan y cómo debe trabajar. Un modelo lo lee y opera bajo él; nunca lo escribe. Cada vez que se asume un rol, el sistema abre una sesión auditada anclada a la versión del contrato, a su hash y al estado del proyecto en ese instante.

El objetivo no es lograr que un modelo se porte bien. Es dejar constancia de a qué estaba obligado, para poder responder meses después a una pregunta concreta: bajo qué reglas se tomó esta decisión, y contra qué versión del estado del proyecto.

Contratos

Los contratos los redacta una persona y los firma el dueño del proyecto. Solo puede asumirse un contrato con estado active; los borradores y las versiones retiradas se leen pero no se usan. Cada uno lleva un contract_hash, de modo que una sesión puede demostrar exactamente qué texto la gobernó, incluso después de que el contrato se modifique.

Los identificadores de rol no son adivinables. Lístalos antes de asumir uno: equivocarse cuesta una llamada fallida.

Sesiones auditadas

POST /v1/project/:name/role/:roleId/assume

Tarifa: 0,001 AIC. El campo opcional platform (hasta 64 caracteres) registra el ejecutor — claude, chatgpt, gemini. Un mismo rol puede correr en varios ejecutores; la notación es rol@ejecutor, y un comportamiento distinto es un rol distinto con su propio contrato.

curl -X POST https://api.chainmemory.ai/v1/project/mi-proyecto/role/arquitecto/assume \
  -H "x-api-key: $CHAINMEMORY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"claude"}'

Devuelve 201 con el id de sesión, la contract_version y el contract_hash anclados, la brain_version y el brain_state_hash de ese instante, un event_hash y auto_release_minutes: 60.

La respuesta trae además el entorno de trabajo declarado por el dueño: hosts, servicios, repositorios y reglas operativas, anclados junto al hash de estado. Un modelo que asume un rol sabe desde su primer mensaje dónde corre cada cosa y cómo se opera, en vez de pedir datos de conexión que ya están registrados.

POST /v1/session/:id/release

Cierra la sesión con un summary de hasta 4000 caracteres: qué se hizo, qué queda pendiente y cuál es el siguiente paso. Una sesión que se deja abierta se libera sola a los 60 minutos, y el registro muestra que cerró por tiempo y no a mano — lo cual ya dice algo sobre cómo terminó el trabajo.

curl -X POST https://api.chainmemory.ai/v1/session/17/release \
  -H "x-api-key: $CHAINMEMORY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"summary":"Infraestructura consolidada. 27 ops aplicadas, 0 rechazadas. Pendiente: allowlist del firewall."}'

Devuelve released_at, release_type y duration_seconds. Liberar dos veces devuelve 409.

El resumen es la parte que todo el mundo se salta y la que rinde después. GET /v1/project/:name/sessions devuelve cada sesión con quién asumió qué rol, en qué plataforma, durante cuánto tiempo y cómo cerró. Ese rastro es la razón de ser de los contratos.

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" (confirmed, evidence: #12, #15)
- Decisión d002: "API REST con endpoints versionados" (confirmed, evidence: #18)
- Hito m001: "Schema de BD completo" (pendiente)
- Riesgo r001: "Performance de RLS en tenants grandes" (med, 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. Un agente (o cada uno, leyendo antes el estado) consolida con update_project_state citando las memorias de los demás; todas las operaciones terminan en un único Project State

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 peticiones por segundo por IP aplicados en el proxy. Los requests por minuto por plan están publicados pero todavía no se aplican.
• 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 las decisiones del Project State (proposed → confirmed → superseded), con cada ítem citando sus memorias, 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 los endpoints de verificación, que exponen hashes y metadata. El contenido cifrado está guardado on-chain y se puede leer ahí, pero nunca el texto plano.

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 archivarla, o ponerla en cuarentena con POST /v1/memories/:id/trust para que quede fuera del contexto y de la inyección. El Project State no cambia solo: si un ítem se construyó sobre esa memoria, corregilo con una operación nueva.

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.

Quién construye el Project State?

Tu cliente de IA. Con update_project_state (MCP) o POST /v1/project/:name/state/ops propone operaciones — agregar una decisión, cerrar un riesgo — citando las memorias que las respaldan. El servidor las valida, las aplica con un builder determinista y ancla el hash resultante on-chain. Ningún modelo del servidor lee tus memorias.

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

Nada las resuelve automáticamente. Las dos memorias quedan, y decide el cliente que consolida: agrega la decisión más nueva y marca la anterior con supersede_decision. Las decisiones reemplazadas permanecen en el estado con status "superseded", 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.

Cuando termina un período pago, el plan sigue vigente durante 3 días de gracia; después la cuenta pasa a Free hasta que se renueve. GET /v1/billing/status muestra period_end, grace_until, in_grace y expired.

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. El único límite de peticiones vigente es por IP en el proxy (30 peticiones por segundo por IP), igual para todos los planes.
• 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

Plataforma — Septiembre 2026: procedencia, descubrimiento por máquina y anclaje

• Guard de procedencia — POST /v1/project/:name/state/ops ahora rechaza la llamada entera con 422 evidence_unresolved si alguna memoria citada no se puede resolver, en vez de descartarla en silencio; las ops sin evidencia llevan un provenance_warning
• OpenAPI 3.1 en api.chainmemory.ai/openapi.json: 41 operaciones, incluidas verificación pública e inyección
• llms.txt reescritos en chainmemory.ai, api y docs con datos verificados
• Bóveda ciega en el servidor MCP (v2.6.0+): memorias cifradas en el cliente a partir de una frase de 12 palabras que el servidor nunca ve
• MCP v2.7.0: 36 herramientas con descripciones reescritas para agentes y conjuntos de valores cerrados declarados; se publica solo en el registro oficial MCP
• Los clientes que usan la biblioteca estándar de Python ya no quedan bloqueados en el borde
• El anclaje del Project State vuelve a correr solo cada 10 minutos; las versiones escritas durante la migración de infraestructura se anclaron retroactivamente

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