Artigo 7
Este artigo explica a implementação técnica do sistema multiusuário do SafeClaw — como funciona a isolação de usuários, como o controle de acesso é aplicado e como os três tipos de conta Binance são roteados.
━━━ O DESAFIO CENTRAL ━━━
Um agente de IA de usuário único é relativamente simples de proteger. Um agente público de múltiplos usuários lidando com chaves de API financeiras reais é um problema fundamentalmente diferente.
Os requisitos:
1. A chave de API do Usuário A deve ser invisível para o Usuário B
2. O histórico de negociação do Usuário A deve ser invisível para o Usuário B
3. O plano DCA do Usuário A não deve afetar o Usuário B
4. Uma sessão comprometida para o Usuário A não deve expor o Usuário B
5. O bot deve encaminhar as chamadas de API de cada usuário para o ambiente correto da Binance
SafeClaw resolve todos os cinco.
━━━ ARQUITETURA DE ISOLAMENTO DE SESSÃO ━━━
O sistema de sessão do OpenClaw está configurado com:
dmScope: "per-channel-peer"
Isso significa: cada ID de usuário único do Telegram recebe seu próprio contexto de sessão isolado.
Tecnicamente, o que isso significa:
• As mensagens de cada usuário são processadas em um namespace de sessão separado
• Os dados da sessão (armazenados em sessions.json) são indexados pelo ID do usuário do Telegram
• A sessão de nenhum usuário pode ler a partir da sessão de outro usuário
• O contexto do agente de IA para cada usuário contém apenas os dados daquele usuário
Dados da sessão armazenados por usuário:
• tipo_de_conta_binance (live/demo/testnet)
• chave_live_binance, segredo_live_binance
• chave_demo_binance, segredo_demo_binance
• chave_testnet_binance, segredo_testnet_binance
• chave_square_binance
• moeda, métodos_de_pagamento, perfil_de_risco
• ativo_dca, valor_dca, intervalo_dca, histórico_dca
• histórico_de_simulação, pontuações_de_avaliação
Nenhum desses dados é acessível a outros usuários.
━━━ O SISTEMA DE CONTROLE DE ACESSO TRÊS-CONTA ━━━
SafeClaw suporta três tipos distintos de conta Binance por usuário. A habilidade do api-router lida com o roteamento:
CONTA REAL (Produção)
Comando: /updatekey [KEY] [SECRET]
Endpoint de validação: https://api.binance.com/api/v3/account
Endpoint de negociação: https://api.binance.com
Endpoint de futuros: https://fapi.binance.com
Caso de uso: DCA ao vivo, monitoramento real de Earn
Segurança: Permissão de retirada = rejeição instantânea
Restrição de IP: usuários instruídos a restringir ao IP do servidor
CONTA DEMO (Prática)
Comando: /updatekey-demo [KEY] [SECRET]
Endpoint de validação: https://demo-api.binance.com/api/v3/account
Endpoint de negociação: https://demo-api.binance.com
Endpoint de futuros: https://demo-fapi.binance.com
Caso de uso: simulação da Academia, teste de estratégia
Saldo: 5.000 USDT fornecido pela Binance
Segurança: Sem fundos reais, sem risco de retirada
TESTNET (Desenvolvimento)
Comando: /updatekey-testnet [KEY] [SECRET]
Endpoint de validação: https://testnet.binance.vision/api/v3/account
Endpoint de negociação: https://testnet.binance.vision
Caso de uso: desenvolvedores construindo no Binance, teste de API
Saldo: Fundos de testnet do testnet.binance.vision
━━━ FLUXO DE VALIDAÇÃO DE CHAVE DA API ━━━
Cada chave enviada passa por este exato processo:
1. Validação de formato
Comprimento da chave: deve ter 64 caracteres
Conjunto de caracteres: apenas alfanuméricos
Se inválido: "Formato de chave inválido. Por favor, verifique e tente novamente."
2. Chamada API ao vivo
GET {correct_endpoint}/api/v3/account
Com timestamp assinado HMAC SHA256
Tempo limite: 10 segundos
3. Inspeção de permissões
Analise o array .permissions da resposta
Se "WITHDRAWALS" presente → rejeitar
Se "TRANSFER" presente → rejeitar
Se "SPOT" ausente → avisar usuário (pode não ser capaz de negociar)
Se canTrade = false → avisar usuário
4. Armazenamento
Em caso de sucesso: armazenado na memória da sessão do usuário
Flag do tipo de conta definido: "live" / "demo" / "testnet"
Usuário notificado com rótulo de conta
5. Prompt de segurança
"✅ [Tipo de conta] conectado."
"⚠️ Por favor, EXCLUA sua mensagem /updatekey do chat agora."
━━━ LÓGICA DE ROTEAMENTO ━━━
Cada habilidade que executa uma chamada da API da Binance lê da habilidade do api-router:
api-router lê: tipo_de_conta_binance da sessão
Retorna: BASE_URL, FUTURES_URL, USER_KEY, USER_SECRET, ACCOUNT_LABEL
Habilidades que usam api-router:
• smartdca (cada execução de DCA)
• safeclaw-academy (cada simulação)
• yield-monitor (cada consulta sobre Earn)
• profile (exibição de saldo)
• guardianclaw (ao executar negociações aprovadas)
Habilidades que NÃO precisam de api-router (APIs públicas):
• p2p-safefinder (API P2P é pública)
• briefing (dados de preço são públicos)
• square-content-engine (notícias/tendências são públicas)
━━━ O QUE ACONTECE QUANDO NENHUMA CHAVE ESTÁ CONFIGURADA ━━━
Se um usuário tentar executar /dca run ou /simulate sem uma chave configurada:
"⚠️ Nenhuma conta Binance conectada.
Para usar este recurso:
• /updatekey — Conta Binance real
• /updatekey-demo — Conta de prática (RECOMENDADO)
• /updatekey-testnet — Testnet de desenvolvedor
A pesquisa P2P e os briefings de mercado funcionam sem uma chave API."
O bot nunca recorre a credenciais em nível de servidor. Se nenhuma chave de usuário estiver configurada, o recurso está indisponível para esse usuário.
━━━ MANUSEIO DE USUÁRIOS CONCORRENTES ━━━
A configuração do OpenClaw:
agents.defaults.maxConcurrent: 4
agents.defaults.subagents.maxConcurrent: 8
Isso significa:
• Até 4 execuções de agentes principais podem rodar em paralelo
• Até 8 operações de sub-agente por agente principal
• Solicitações adicionais são enfileiradas — sem mensagens perdidas
Em t3.small (2 vCPU, 2GB RAM), isso lida confortavelmente com dezenas de usuários concorrentes. O principal gargalo são os limites de taxa da API do OpenRouter, não os recursos do servidor.
━━━ EXPANSÃO FUTURA ━━━
Escalonamento de múltiplas instâncias:
• O armazenamento de sessão Redis permite que várias instâncias do OpenClaw compartilhem estado
• O balanceador de carga distribui o tráfego do webhook do Telegram
• Cada instância lida com um subconjunto de usuários com capacidades idênticas
Seleção de modelo por usuário:
• Usuários premium podem ser direcionados ao Claude Sonnet para maior precisão
• O nível gratuito direciona para modelos de fallback gratuitos
• A seleção de modelo é armazenada na sessão do usuário
Níveis de usuários:
• Gratuito: P2P, Briefing, Aprender
• Padrão: + DCA, Guard, Academia
• Premium: + Yield, Content Engine, Roteamento prioritário
Links rápidos:
Artigo 1 Artigo 2 Artigo 3 Artigo 4 Artigo 5 Artigo 6 Artigo 8
Fonte: https://github.com/bnbnepalbinanceangel/SafeClaw
#AIBinance #SafeClaw #MultiUser #AccessControl #OpenClaw