TradeMemory Protocol

TradeMemory recuerda lo que costó. Es un sistema de memoria y freno de código abierto, local-first, para agentes de trading con IA: incorpora tus ejecuciones, encuentra dónde tu propio historial pierde dinero, pone esas operaciones perdedoras frente a tu agente antes de la siguiente orden, y puede rechazar una orden que rompa las reglas que tú estableciste, antes de que llegue al bróker.

Los brókers ahora permiten que los agentes de IA operen a través de MCP, con diferentes salvaguardas: Webull y tastytrade establecen límites de tamaño o poder de compra, Interactive Brokers solo permite que el agente redacte una orden para que tú la envíes, y Robinhood y Public no establecen ningún tope que puedas imponer a un agente externo (StockBrokers, 2026-09-30). Los topes son números fijos. Ninguno de ellos analiza cómo te fueron tus propias operaciones pasadas.

Comienza con tu propio historial

pip install tradememory-protocol

# Hyperliquid: public fills, no key needed
tradememory sync hyperliquid --address 0xYourAddress

# Alpaca: read-only calls with your own keys, kept in a local file
tradememory sync alpaca --env-file ~/.secrets/alpaca.env

Cada operación cerrada se almacena en memoria una vez; ejecutarlo de nuevo solo guarda operaciones nuevas. Luego imprime dónde tu historial pierde dinero. El formato, con números ilustrativos:

After 2 losses in a row (20 trades):
  5 of them (25%) were 1.5x your usual size or more.
  All 20 won 60% and made -$1,500.
  The 5 sized-up trades won 20% and made -$1,700.

Median hold: winners 1.5h, losers 9.0h.

Estas son estadísticas descriptivas de tus propias operaciones pasadas, no consejos sobre la siguiente. La API de Hyperliquid solo sirve las ejecuciones recientes de una dirección, no todo su historial, así que cuanto antes se sincronice, más historial se conserva. Otros lugares: los scripts de sincronización de MT5 y Binance spot están en scripts/, y cualquier agente puede registrar una operación con remember_trade.

Antes de la siguiente orden

recall_memories(order="losses_first") pone cada operación perdedora por delante del resto, las pérdidas más grandes en condiciones similares primero, con su tamaño y P&L. Además de las operaciones más recientes del símbolo, busca las operaciones perdedoras recientes del símbolo, para que una pérdida más antigua no quede desplazada. El servidor indica a los agentes conectados que lo llamen antes de proponer una operación. El orden predeterminado clasifica los mejores resultados más arriba (por múltiplo R, cuando se registró uno) y mantiene al menos un 20% de pérdidas en la lista.

Conecta tu agente

pip install tradememory-protocol

Añade a Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "tradememory": {
      "command": "uvx",
      "args": ["tradememory-protocol"]
    }
  }
}

Luego dile a Claude: "Registra mi largo de AAPL a $195 — ganancias superaron expectativas, compra institucional, alta confianza."

# Claude Code
claude mcp add tradememory -- uvx tradememory-protocol

# From source
git clone https://github.com/mnemox-ai/tradememory-protocol.git
cd tradememory-protocol && pip install -e . && python -m tradememory

# Docker
docker compose up -d

Guía completa: Getting Started (Trader Track + Developer Track)

Pon un freno delante de tu bróker (vista previa)

El extra proxy ejecuta TradeMemory entre tu agente y el servidor MCP de tu bróker (Alpaca hoy). Cada herramienta se reenvía sin cambios excepto las que colocan órdenes, que Mnemox Control evalúa contra una política que tú posees antes de que lleguen al bróker. Cada evaluación, permitida o rechazada, se registra y se encadena en el registro de auditoría. Una orden permitida regresa con tus operaciones perdedoras de condiciones similares primero, y tradememory sync alpaca luego completa cómo terminó cada operación reenviada, en R cuando la entrada llevaba un stop. El agente que ya tienes sigue funcionando; solo cambia una línea de su configuración MCP.

pip install "tradememory-protocol[proxy]"   # Python 3.12+
tradememory proxy init --account-id <your Alpaca account id> --symbols AAPL,MSFT
tradememory proxy doctor --env-file ~/.secrets/alpaca-paper.env   # checks the live tool names and the account id
tradememory proxy config                                           # prints the MCP client entry that replaces the direct Alpaca one

Rechazado por defecto: símbolos fuera de tu lista, órdenes por encima de tus límites nocionales y de posición, entradas sin un stop de bracket, cualquier orden nueva después de tu límite de pérdida diaria o de drawdown, cancelar el stop protector de una posición abierta, cualquier herramienta que el freno no haya clasificado, y todo mientras tengas tradememory proxy halt FULL_HALT en ejecución. Nunca bloqueado: cerrar una posición. Las órdenes en o por encima de approval_notional esperan a tradememory proxy approve <intent_id> --terms <fingerprint>, que aprueba exactamente los términos que leíste; el agente reintenta con el mismo client_order_id y los mismos términos, y el proxy lo reenvía como máximo una vez. evaluate_order devuelve la misma decisión sin colocar nada, para pre-chequeos y para capas de asesoría en otros frameworks. Cualquier cosa que el freno no pueda evaluar (un feed de cotizaciones muerto, un activo desconocido, un tipo de orden que la política no cubre) se rechaza, no se pasa por alto.

Estado: probado de extremo a extremo contra un simulacro con estado del servidor MCP de Alpaca (tests/proxy/), y ejecutado contra una cuenta de papel real de Alpaca el 2026-10-01: tres rechazos (símbolo no en la lista, entrada sin stop, nocional por encima del límite), una orden de bracket de una acción permitida que llegó al bróker, y un reintento con el mismo client_order_id que se respondió desde el registro sin una segunda orden. Las opciones, el reemplazo de órdenes, las órdenes stop-limit y trailing se rechazan en lugar de evaluarse. Tus claves del bróker van solo al proceso del bróker que inicia el proxy; TradeMemory nunca las almacena.

Guía con los resultados reales: docs/recipes/alpaca-brake.md.

Tres formas en que se usa

Cómo funciona

1. Recordar — Antes de operar, recupera operaciones pasadas ponderadas por calidad de resultado, similitud de contexto, actualidad, confianza y estado emocional (OWM Framework)
2. Registrar — Después de operar, una llamada a remember_trade escribe en cinco capas de memoria: episódica, semántica, procedimental, afectiva y registros de operaciones
3. Reflexionar — Revisiones diarias/semanales/mensuales detectan deriva conductual, deterioro de estrategia y errores de trading
4. Auditar — Cada decisión se hashea con SHA-256 en su creación y se encadena a la anterior. Exporta en cualquier momento para revisión

Herramientas MCP

Obtén ayuda para conectar

¿Ejecutas un agente contra un bróker, o quieres que tu historial se sincronice y se lea? Abre un issue de integración de freno o reserva 30 minutos. La ayuda de configuración es gratuita, y las personas que la usan deciden qué se construye después.

Registro de auditoría

Cada decisión de trading que toma tu agente — incluidas las decisiones de no operar — se registra como un Registro de Decisión de Trading (TDR). Los hashes de contenido SHA-256 por registro se vinculan en un libro de auditoría encadenado hacia adelante; cada día UTC se resume con una raíz de Merkle que a su vez se encadena entre días. Manipular cualquier registro histórico invalida cada enlace posterior.

Las reglas que requieren registros de decisión vinculan a las firmas de inversión, no a los usuarios minoristas. Bajo la Ley de IA de la UE, las obligaciones de registro de alto riesgo del Anexo III se pospusieron al 2 de diciembre de 2027, y el informe de supervisión de ESMA de febrero de 2026 sobre trading algorítmico establece que el trading algorítmico basado en IA está actualmente excluido del alcance de alto riesgo. La tabla muestra qué características de TradeMemory se corresponden con esos textos si y cuando te apliquen. No es una afirmación de cumplimiento.

# Verify a single record hasn't been tampered with
verify_audit_hash(trade_id="MT5-7047640363")
# → {"verified": true, "chain_entry": {"sequence_num": 42, ...}}

# Walk the entire chain (or a slice) end-to-end
verify_audit_chain(from_seq=1, to_seq=None)
# → {"verified": true, "checked_count": 1284, "first_break_at": null}

# Daily Merkle root — single 32-byte anchor over every TDR for that day
get_daily_root(date="2026-05-14")
# → {"verified": true, "root_hash": "a05544...", "record_count": 18}

# Bulk export
GET /audit/export?strategy=VolBreakout&start=2026-03-01&format=jsonl

Las raíces diarias se sellan de tiempo por una autoridad RFC 3161 por defecto desde 0.5.3. No construido: firmar registros con una clave privada, anclar a un registro público, probar que nada se omitió. Ver LIMITATIONS.md.

Seguridad

• Servidor de memoria (predeterminado). Nunca coloca órdenes y nunca pide claves de bróker. Solo registra y recuerda, en un archivo SQLite local.
• Sincronización. tradememory sync hyperliquid lee datos públicos sin clave. tradememory sync alpaca hace llamadas de solo lectura con claves de un archivo en tu máquina. Las operaciones sincronizadas permanecen en tu base de datos local.
• Freno (extra proxy). Reenvía las órdenes que tu política permite al servidor MCP de tu bróker. Tus claves del bróker se pasan solo al proceso del bróker que inicia el proxy; TradeMemory nunca las almacena.
• Llamadas salientes. Sellado de tiempo RFC 3161 de las raíces de auditoría diarias, un hash de 32 bytes sin datos de operaciones (activado por defecto; TRADEMEMORY_TSA=off lo desactiva). tradememory sync llama al lugar que nombres. Las herramientas de evolución leen datos públicos de mercado de Binance (api.binance.com) cuando un agente las llama, y la evolución llama a la API de Anthropic solo si configuras ANTHROPIC_API_KEY. Replay llama a DeepSeek por defecto (o Anthropic), y solo con la clave de ese proveedor configurada. Si instalas sentence-transformers para recordación híbrida, descarga su modelo de Hugging Face en el primer uso. Los scripts de sincronización de MT5 y Binance en scripts/ leen sus credenciales de tu entorno, y el de MT5 publica resúmenes de operaciones (símbolo, precios, P&L) a un webhook de Discord solo si configuras DISCORD_WEBHOOK_URL.
• Evidente contra manipulación, no a prueba de manipulación. Cada registro se hashea y se vincula al anterior, con raíces de Merkle diarias. Cambiar un registro rompe la cadena; alguien que pueda reescribir toda la base de datos puede reconstruirla.

Estado de la investigación

El framework OWM de TradeMemory se basa en la ciencia cognitiva (Tulving 1972) y el aprendizaje por refuerzo (Schaul et al. 2015). Estado actual:

• Puntuación de cinco factores OWM: implementada y probada (ver la insignia de CI)
• Validación estadística: DSR, MBL implementados (Bailey-de Prado 2014)
• Registro de auditoría: TDR a prueba de manipulación SHA-256
• Motor de evolución: fase de investigación (la generación de estrategias funciona, tasa de aprobación del gate estadístico bajo optimización)
• Recordación híbrida: modo solo-OWM activo, fusión vectorial disponible cuando se configuran embeddings
• Validación empírica: en curso (n=14 operaciones, objetivo n>=100 para significancia estadística; en n=14 los intervalos de confianza son demasiado amplios para concluir nada - ver validation/final_verdict.md)

Documentación

Contribuciones

Consulte la Guía de contribución · Política de seguridad

MIT, consulte LICENCIA. La instalación opcional proxy incluye Mnemox Control, cuyo motor es AGPL-3.0-only (hay disponible una licencia comercial); TradeMemory en sí permanece bajo MIT. Solo para fines educativos y de investigación. No es asesoramiento financiero.