Articolo 7
Questo articolo spiega l'implementazione tecnica del sistema multi-utente di SafeClaw — come funziona l'isolamento degli utenti, come viene applicato il controllo degli accessi e come i tre tipi di account Binance sono indirizzati.
━━━ LA SFIDA CENTRALE ━━━
Un agente AI a utente singolo è relativamente semplice da proteggere. Un agente pubblico multi-utente che gestisce chiavi API finanziarie reali è un problema fondamentalmente diverso.
I requisiti:
1. La chiave API dell'utente A deve essere invisibile all'utente B
2. La cronologia delle operazioni dell'utente A deve essere invisibile all'utente B
3. Il piano DCA dell'Utente A non deve influenzare l'Utente B
4. Una sessione compromessa per l'Utente A non deve esporre l'Utente B
5. Il bot deve instradare le chiamate API di ogni utente verso il corretto ambiente Binance
SafeClaw risolve tutti e cinque.
━━━ ARCHITETTURA DI ISOLAMENTO DELLA SESSIONE ━━━
Il sistema di sessione di OpenClaw è configurato con:
dmScope: "per-canale-peer"
Questo significa: ogni ID utente Telegram unico ottiene il proprio contesto di sessione isolato.
Tecnicamente, cosa significa questo:
• I messaggi di ciascun utente sono elaborati in uno spazio dei nomi di sessione separato
• I dati della sessione (memorizzati in sessions.json) sono indicizzati per ID utente Telegram
• Nessuna sessione dell'utente può leggere dalla sessione di un altro utente
• Il contesto dell'agente AI per ogni utente contiene solo i dati di quell'utente
Dati della sessione memorizzati per utente:
• tipo_account_binance (live/demo/testnet)
• chiave_live_binance, segreto_live_binance
• chiave_demo_binance, segreto_demo_binance
• chiave_testnet_binance, segreto_testnet_binance
• chiave_square_binance
• valuta, metodi_di_pagamento, profilo_di_rischio
• dca_asset, dca_amount, dca_interval, dca_history
• simulazione_history, evaluation_scores
Nessuno di questi dati è accessibile ad altri utenti.
━━━ IL SISTEMA DI CONTROLLO DELL'ACCESSO A TRE ACCOUNT ━━━
SafeClaw supporta tre distinti tipi di account Binance per utente. L'abilità api-router gestisce l'instradamento:
ACCOUNT REALE (Produzione)
Comando: /updatekey [KEY] [SECRET]
Endpoint di validazione: https://api.binance.com/api/v3/account
Endpoint di trading: https://api.binance.com
Endpoint futures: https://fapi.binance.com
Caso d'uso: DCA live, monitoraggio reale degli utili
Sicurezza: Permesso di prelievo = rifiuto immediato
Restrizione IP: Gli utenti devono essere avvisati di limitare all'IP del server
ACCOUNT DEMO (Pratica)
Comando: /updatekey-demo [KEY] [SECRET]
Endpoint di validazione: https://demo-api.binance.com/api/v3/account
Endpoint di trading: https://demo-api.binance.com
Endpoint futures: https://demo-fapi.binance.com
Caso d'uso: simulazione accademica, testing delle strategie
Saldo: 5.000 USDT forniti da Binance
Sicurezza: nessun fondo reale, nessun rischio di prelievo
TESTNET (Sviluppo)
Comando: /updatekey-testnet [KEY] [SECRET]
Endpoint di validazione: https://testnet.binance.vision/api/v3/account
Endpoint di trading: https://testnet.binance.vision
Caso d'uso: sviluppatori che costruiscono su Binance, testing API
Saldo: fondi di testnet da testnet.binance.vision
━━━ FLUSSO DI VALIDAZIONE DELLA CHIAVE API ━━━
Ogni chiave inviata passa attraverso questo esatto processo:
1. Validazione del formato
Lunghezza della chiave: deve essere di 64 caratteri
Set di caratteri: solo alfanumerico
Se non valido: "Formato della chiave non valido. Controlla e riprova."
2. Chiamata API in tempo reale
GET {correct_endpoint}/api/v3/account
Con timestamp firmato HMAC SHA256
Timeout: 10 secondi
3. Ispezione dei permessi
Analizza l'array .permissions dalla risposta
Se "WITHDRAWALS" presente → rifiuta
Se "TRANSFER" presente → rifiuta
Se "SPOT" assente → avvisa l'utente (potrebbe non essere in grado di fare trading)
Se canTrade = false → avvisa l'utente
4. Memorizzazione
In caso di successo: memorizzato nella memoria della sessione dell'utente
Flag del tipo di account impostato: "live" / "demo" / "testnet"
Utente avvisato con etichetta dell'account
5. Messaggio di sicurezza
"✅ [Tipo di account] connesso."
"⚠️ Per favore ELIMINA il tuo messaggio /updatekey dalla chat ora."
━━━ LOGICA DI INSTRADAMENTO ━━━
Ogni abilità che esegue una chiamata API Binance legge dall'abilità api-router:
api-router legge: tipo_account_binance dalla sessione
Restituisce: BASE_URL, FUTURES_URL, USER_KEY, USER_SECRET, ACCOUNT_LABEL
Abilità che utilizzano api-router:
• smartdca (ogni esecuzione DCA)
• safeclaw-academy (ogni simulazione)
• yield-monitor (ogni query di Earn)
• profile (visualizzazione saldo)
• guardianclaw (quando esegue operazioni approvate)
Abilità che NON necessitano di api-router (API pubbliche):
• p2p-safefinder (API P2P è pubblica)
• briefing (i dati dei prezzi sono pubblici)
• square-content-engine (notizie/tendenze sono pubbliche)
━━━ COSA SUCCEDE QUANDO NESSUNA CHIAVE È IMPOSTATA ━━━
Se un utente cerca di eseguire /dca run o /simulate senza una chiave configurata:
"⚠️ Nessun account Binance connesso.
Per utilizzare questa funzionalità:
• /updatekey — Account Binance reale
• /updatekey-demo — Account di pratica (RACCOMANDATO)
• /updatekey-testnet — Testnet per sviluppatori
La ricerca P2P e i briefing di mercato funzionano senza una chiave API."
Il bot non torna mai a credenziali a livello di server. Se nessuna chiave utente è configurata, la funzionalità non è disponibile per quell'utente.
━━━ GESTIONE DEGLI UTENTI CONCURENTI ━━━
Configurazione di OpenClaw:
agents.defaults.maxConcurrent: 4
agents.defaults.subagents.maxConcurrent: 8
Questo significa:
• Fino a 4 esecuzioni principali dell'agente funzionano in parallelo
• Fino a 8 operazioni di sub-agente per agente principale
• Richieste aggiuntive sono in coda — nessun messaggio perso
Su t3.small (2 vCPU, 2GB RAM), questo gestisce comodamente dozzine di utenti concorrenti. Il principale collo di bottiglia sono i limiti di frequenza API di OpenRouter, non le risorse del server.
━━━ ESPANSIONE FUTURA ━━━
Scaling multiistanza:
• Il deposito delle sessioni Redis consente a più istanze di OpenClaw di condividere lo stato
• Il bilanciatore di carico distribuisce il traffico del webhook di Telegram
• Ogni istanza gestisce un sottoinsieme di utenti con capacità identiche
Selezione del modello per utente:
• Gli utenti premium potrebbero essere indirizzati a Claude Sonnet per una maggiore accuratezza
• Il livello gratuito indirizza verso modelli di fallback gratuiti
• Selezione del modello memorizzata nella sessione utente
Livelli utente:
• Gratuito: P2P, Briefing, Impara
• Standard: + DCA, Guard, Accademia
• Premium: + Yield, Content Engine, Routing prioritario
Link rapidi:
Articolo 1 Articolo 2 Articolo 3 Articolo 4 Articolo 5 Articolo 6 Articolo 8
Fonte: https://github.com/bnbnepalbinanceangel/SafeClaw
#AIBinance #SafeClaw #MultiUser #AccessControl #OpenClaw