Artículo 7
Este artículo explica la implementación técnica del sistema multiusuario de SafeClaw: cómo funciona el aislamiento de usuarios, cómo se aplica el control de acceso y cómo se dirigen los tres tipos de cuentas de Binance.
━━━ EL DESAFÍO CENTRAL ━━━
Un agente de IA de un solo usuario es relativamente simple de asegurar. Un agente público de múltiples usuarios que maneja claves API financieras reales es un problema fundamentalmente diferente.
Los requisitos:
1. La clave API del Usuario A debe ser invisible para el Usuario B
2. El historial de operaciones del Usuario A debe ser invisible para el Usuario B
3. El plan DCA del Usuario A no debe afectar al Usuario B
4. Una sesión comprometida para el Usuario A no debe exponer al Usuario B
5. El bot debe enrutear las llamadas API de cada usuario al entorno de Binance correcto
SafeClaw resuelve los cinco.
━━━ ARQUITECTURA DE AISLAMIENTO DE SESIONES ━━━
El sistema de sesiones de OpenClaw está configurado con:
dmScope: "por-canal-par"
Esto significa: cada ID de usuario único de Telegram obtiene su propio contexto de sesión aislada.
Técnicamente, lo que esto significa:
• Los mensajes de cada usuario se procesan en un espacio de nombres de sesión separado
• Los datos de sesión (almacenados en sessions.json) se identifican por ID de usuario de Telegram
• La sesión de ningún usuario puede leer de la sesión de otro usuario
• El contexto del agente de IA para cada usuario contiene solo los datos de ese usuario
Datos de sesión almacenados por usuario:
• tipo_cuenta_binance (en vivo/demo/testnet)
• binance_live_key, binance_live_secret
• binance_demo_key, binance_demo_secret
• binance_testnet_key, binance_testnet_secret
• binance_square_key
• moneda, métodos_de_pago, perfil_de_riesgo
• dca_asset, dca_amount, dca_interval, dca_history
• simulation_history, evaluation_scores
Ninguno de estos datos es accesible para otros usuarios.
━━━ EL SISTEMA DE CONTROL DE ACCESO DE TRES CUENTAS ━━━
SafeClaw admite tres tipos de cuentas de Binance distintas por usuario. La habilidad del enrutador de API maneja el enrutamiento:
CUENTA REAL (Producción)
Comando: /updatekey [KEY] [SECRET]
Endpoint de validación: https://api.binance.com/api/v3/account
Endpoint de trading: https://api.binance.com
Endpoint de futuros: https://fapi.binance.com
Caso de uso: DCA en vivo, monitoreo real de Earn
Seguridad: Permiso de retiro = rechazo instantáneo
Restricción de IP: A los usuarios se les indica restringir a la IP del servidor
CUENTA DEMO (Práctica)
Comando: /updatekey-demo [KEY] [SECRET]
Endpoint de validación: https://demo-api.binance.com/api/v3/account
Endpoint de trading: https://demo-api.binance.com
Endpoint de futuros: https://demo-fapi.binance.com
Caso de uso: simulación de Academia, pruebas de estrategia
Balance: 5,000 USDT proporcionados por Binance
Seguridad: Sin fondos reales, sin riesgo de retiro
TESTNET (Desarrollo)
Comando: /updatekey-testnet [KEY] [SECRET]
Endpoint de validación: https://testnet.binance.vision/api/v3/account
Endpoint de trading: https://testnet.binance.vision
Caso de uso: Desarrolladores creando en Binance, pruebas de API
Balance: Fondos de testnet de testnet.binance.vision
━━━ FLUJO DE VALIDACIÓN DE CLAVE API ━━━
Cada clave presentada pasa por este proceso exacto:
1. Validación de formato
Longitud de la clave: debe tener 64 caracteres
Conjunto de caracteres: solo alfanumérico
Si es inválido: "Formato de clave inválido. Por favor, verifica y vuelve a intentar."
2. Llamada API en vivo
GET {correct_endpoint}/api/v3/account
Con marca de tiempo firmada HMAC SHA256
Tiempo de espera: 10 segundos
3. Inspección de permisos
Analiza el array .permissions de la respuesta
Si "WITHDRAWALS" presente → rechazar
Si "TRANSFER" presente → rechazar
Si "SPOT" ausente → advertir al usuario (puede que no pueda comerciar)
Si canTrade = false → advertir al usuario
4. Almacenamiento
En caso de éxito: almacenado en la memoria de sesión del usuario
Bandera de tipo de cuenta establecida: "en vivo" / "demo" / "testnet"
Usuario notificado con la etiqueta de cuenta
5. Solicitud de seguridad
"✅ [Tipo de cuenta] conectado."
"⚠️ Por favor, ELIMINA tu mensaje /updatekey del chat ahora."
━━━ LÓGICA DE ENRUTAMIENTO ━━━
Cada habilidad que ejecuta una llamada API de Binance lee de la habilidad del enrutador de API:
el enrutador de API lee: tipo_cuenta_binance de la sesión
Devuelve: BASE_URL, FUTURES_URL, USER_KEY, USER_SECRET, ACCOUNT_LABEL
Habilidades que usan el enrutador de API:
• smartdca (cada ejecución de DCA)
• safeclaw-academy (cada simulación)
• yield-monitor (cada consulta de Earn)
• profile (visualización de saldo)
• guardianclaw (al ejecutar operaciones aprobadas)
Habilidades que NO necesitan el enrutador de API (APIs públicas):
• p2p-safefinder (la API P2P es pública)
• briefing (los datos de precios son públicos)
• square-content-engine (noticias/tendencias son públicas)
━━━ ¿QUÉ SUCEDE CUANDO NO SE ESTABLECE CLAVE? ━━━
Si un usuario intenta ejecutar /dca run o /simulate sin una clave configurada:
"⚠️ No hay cuenta de Binance conectada.
Para usar esta función:
• /updatekey — Cuenta de Binance real
• /updatekey-demo — Cuenta de práctica (RECOMENDADA)
• /updatekey-testnet — Testnet para desarrolladores
La búsqueda P2P y las actualizaciones de mercado funcionan sin una clave API."
El bot nunca recurre a las credenciales a nivel de servidor. Si no se configura la clave de usuario, la función no está disponible para ese usuario.
━━━ MANEJO DE USUARIOS CONCURRENTES ━━━
Configuración de OpenClaw:
agents.defaults.maxConcurrent: 4
agents.defaults.subagents.maxConcurrent: 8
Esto significa:
• Hasta 4 ejecuciones de agentes principales se ejecutan en paralelo
• Hasta 8 operaciones de subagente por agente principal
• Solicitudes adicionales son encoladas — no se pierden mensajes
En t3.small (2 vCPU, 2GB RAM), esto maneja cómodamente docenas de usuarios concurrentes. El principal cuello de botella son los límites de tasa de la API de OpenRouter, no los recursos del servidor.
━━━ EXPANSIÓN FUTURA ━━━
Escalado de múltiples instancias:
• El almacenamiento de sesiones de Redis permite que múltiples instancias de OpenClaw compartan estado
• El balanceador de carga distribuye el tráfico del webhook de Telegram
• Cada instancia maneja un subconjunto de usuarios con capacidades idénticas
Selección de modelo por usuario:
• Los usuarios premium podrían ser dirigidos a Claude Sonnet para mayor precisión
• La categoría gratuita se dirige a modelos de respaldo gratuitos
• La selección de modelos se almacena en la sesión del usuario
Categorías de usuarios:
• Gratuito: P2P, Briefing, Aprender
• Estándar: + DCA, Guard, Academia
• Premium: + Yield, Motor de contenido, Enrutamiento prioritario
Enlaces rápidos:
Artículo 1 Artículo 2 Artículo 3 Artículo 4 Artículo 5 Artículo 6 Artículo 8
Fuente: https://github.com/bnbnepalbinanceangel/SafeClaw
#AIBinance #SafeClaw #MultiUser #AccessControl #OpenClaw