Article 7
This article explains the technical implementation of SafeClaw's multi-user system — how user isolation works, how access control is enforced, and how the three Binance account types are routed.
━━━ THE CORE CHALLENGE ━━━
A single-user AI agent is relatively simple to secure. A public multi-user agent handling real financial API keys is a fundamentally different problem.
The requirements:
1. User A's API key must be invisible to User B
2. User A's trade history must be invisible to User B
3. User A's DCA plan must not affect User B's
4. A compromised session for User A must not expose User B
5. The bot must route each user's API calls to the correct Binance environment
SafeClaw solves all five.
━━━ SESSION ISOLATION ARCHITECTURE ━━━
OpenClaw's session system is configured with:
dmScope: "per-channel-peer"
This means: every unique Telegram user ID gets its own isolated session context.
Technically, what this means:
• Each user's messages are processed in a separate session namespace
• Session data (stored in sessions.json) is keyed by Telegram user ID
• No user's session can read from another user's session
• The AI agent's context for each user contains only that user's data
Session data stored per user:
• binance_account_type (live/demo/testnet)
• binance_live_key, binance_live_secret
• binance_demo_key, binance_demo_secret
• binance_testnet_key, binance_testnet_secret
• binance_square_key
• currency, payment_methods, risk_profile
• dca_asset, dca_amount, dca_interval, dca_history
• simulation_history, evaluation_scores
None of this data is accessible to other users.
━━━ THE THREE-ACCOUNT ACCESS CONTROL SYSTEM ━━━
SafeClaw supports three distinct Binance account types per user. The api-router skill handles routing:
REAL ACCOUNT (Production)
Command: /updatekey [KEY] [SECRET]
Validation endpoint: https://api.binance.com/api/v3/account
Trading endpoint: https://api.binance.com
Futures endpoint: https://fapi.binance.com
Use case: Live DCA, real Earn monitoring
Security: Withdrawal permission = instant reject
IP restriction: Users told to restrict to server IP
DEMO ACCOUNT (Practice)
Command: /updatekey-demo [KEY] [SECRET]
Validation endpoint: https://demo-api.binance.com/api/v3/account
Trading endpoint: https://demo-api.binance.com
Futures endpoint: https://demo-fapi.binance.com
Use case: Academy simulation, strategy testing
Balance: 5,000 USDT provided by Binance
Security: No real funds, no withdrawal risk
TESTNET (Development)
Command: /updatekey-testnet [KEY] [SECRET]
Validation endpoint: https://testnet.binance.vision/api/v3/account
Trading endpoint: https://testnet.binance.vision
Use case: Developers building on Binance, API testing
Balance: Testnet funds from testnet.binance.vision
━━━ API KEY VALIDATION FLOW ━━━
Every key submitted goes through this exact process:
1. Format validation
Key length: must be 64 characters
Character set: alphanumeric only
If invalid: "Invalid key format. Please check and retry."
2. Live API call
GET {correct_endpoint}/api/v3/account
With HMAC SHA256 signed timestamp
Timeout: 10 seconds
3. Permission inspection
Parse .permissions array from response
If "WITHDRAWALS" present → reject
If "TRANSFER" present → reject
If "SPOT" absent → warn user (may not be able to trade)
If canTrade = false → warn user
4. Storage
On success: stored in user's session memory
Account type flag set: "live" / "demo" / "testnet"
User notified with account label
5. Security prompt
"✅ [Account type] connected."
"⚠️ Please DELETE your /updatekey message from chat now."
━━━ ROUTING LOGIC ━━━
Every skill that executes a Binance API call reads from the api-router skill:
api-router reads: binance_account_type from session
Returns: BASE_URL, FUTURES_URL, USER_KEY, USER_SECRET, ACCOUNT_LABEL
Skills that use api-router:
• smartdca (every DCA execution)
• safeclaw-academy (every simulation)
• yield-monitor (every Earn query)
• profile (balance display)
• guardianclaw (when executing approved trades)
Skills that do NOT need api-router (public APIs):
• p2p-safefinder (P2P API is public)
• briefing (price data is public)
• square-content-engine (news/trends are public)
━━━ WHAT HAPPENS WHEN NO KEY IS SET ━━━
If a user tries to run /dca run or /simulate without a configured key:
"⚠️ No Binance account connected.
To use this feature:
• /updatekey — Real Binance account
• /updatekey-demo — Practice account (RECOMMENDED)
• /updatekey-testnet — Developer testnet
P2P search and market briefings work without an API key."
The bot never falls back to server-level credentials. If no user key is configured, the feature is unavailable for that user.
━━━ CONCURRENT USER HANDLING ━━━
OpenClaw's configuration:
agents.defaults.maxConcurrent: 4
agents.defaults.subagents.maxConcurrent: 8
This means:
• Up to 4 main agent executions run in parallel
• Up to 8 sub-agent operations per main agent
• Additional requests are queued — no dropped messages
On t3.small (2 vCPU, 2GB RAM), this comfortably handles dozens of concurrent users. The main bottleneck is OpenRouter API rate limits, not server resources.
━━━ FUTURE EXPANSION ━━━
Multi-instance scaling:
• Redis session store enables multiple OpenClaw instances to share state
• Load balancer distributes Telegram webhook traffic
• Each instance handles a subset of users with identical capabilities
Per-user model selection:
• Premium users could route to Claude Sonnet for higher accuracy
• Free tier routes to free fallback models
• Model selection stored in user session
User tiers:
• Free: P2P, Briefing, Learn
• Standard: + DCA, Guard, Academy
• Premium: + Yield, Content Engine, Priority routing
Quick Links:
Article 1 Article 2 Article 3 Article 4 Article 5 Article 6 Article 8Source: https://github.com/bnbnepalbinanceangel/SafeClaw
#AIBinance #SafeClaw #MultiUser #AccessControl #OpenClaw