Skip to main content

Documentation Index

Fetch the complete documentation index at: https://uncoded.ch/docs/llms.txt

Use this file to discover all available pages before exploring further.

unCoded’s security philosophy is defense-in-depth: stack multiple layers, each limiting the worst-case if the layer above is breached. No single layer is impenetrable; the combination is what keeps you safe. This page walks through each layer and what it protects.

​
The threat model

What can go wrong, in order of likelihood:
An API key gets copied/leaked through any of: misconfigured Git repo, shared chat, malware on a developer machine, snapshot of compromised VPS.Worst-case in unCoded architecture: an attacker can trade your funds. They cannot withdraw. They cannot change the bot’s permissions. The damage is bounded by what they can lose to fees and bad trades within your balance.Worst-case in many SaaS bots: the SaaS vendor holds your keys; if their database leaks, attacker has unmitigated access including any permissions the keys have.
Your VPS is compromised — attacker gets root access to your server.Worst-case in unCoded: the attacker can read your trade history, modify the bot’s local configuration, destroy your local database. They cannot withdraw your funds (no withdrawal permission on API keys). The Dashboard’s reverse proxy is the only inbound path; it’s behind TLS and authentication.Worst-case in many SaaS bots: irrelevant — you don’t run a VPS for them. But your trading data is centralized at the SaaS vendor’s infrastructure, exposed to their compromises.
Your venue account credentials leak — attacker has email/password.Worst-case if 2FA enabled: attacker can’t log in.Worst-case if 2FA absent: attacker logs in, can change API key permissions, withdraw funds, etc. The unCoded architecture doesn’t help here — it’s the venue’s account that’s compromised, not unCoded.Mitigation: 2FA on every venue account. Authenticator apps preferred over SMS.
Phone stolen, Telegram session hijacked.Worst-case in unCoded architecture: attacker reads your trade history. They cannot place trades or change configuration via Telegram (notification-only by design).Worst-case in many bots that allow Telegram remote commands: attacker can issue trade commands.
Someone gains access to your Dashboard credentials.Worst-case in unCoded architecture: with admin password, attacker can change configuration, flip kill switch, edit modes. They cannot withdraw — funds are at the venue with non-withdrawal API keys.Mitigation: strong password, IP allowlist at reverse proxy, optional 2FA at proxy layer, viewer role for trusted observers.
Someone sends malicious webhooks to your SignalsBot.Worst-case in unCoded architecture: webhook is rejected if HMAC signature or shared secret doesn’t match. Even authenticated webhooks can only update a defined set of allowed configuration fields — no arbitrary code execution.Mitigation: HMAC authentication, IP allowlist at proxy, rate-limiting (100 req/15min), 64 KB body cap.

​
The defense layers

Layer 1: API key permissions

No withdrawals. No margin/futures unless explicitly needed. Spot only. Limits the blast radius of any compromise.

Layer 2: IP allowlisting

Even with a leaked key, attacker has to be on your VPS’s IP. Unlikely without also compromising your VPS.

Layer 3: Venue 2FA

Protects against scenarios where account password leaks but API keys don’t (or vice versa).

Layer 4: Secret hygiene

Keys in password manager only, never plaintext, never shared via chat or email.

Layer 5: Periodic rotation

Quarterly key rotation limits the exploit window for any undetected leak.

Layer 6: Dashboard authentication

Strong password + reverse-proxy 2FA + IP allowlist. Multi-factor at the operator surface.

Layer 7: Notification-only Telegram

Phone leak doesn’t give trading authority.

Layer 8: SignalsBot HMAC + rate limit

Webhook authentication and abuse protection.

​
Architectural commitments

These are commitments unCoded makes, not just defaults you can override.
  • ❌ unCoded never sees your exchange API keys. They live in the TradingBot container’s environment on your VPS. We have no path to them.
  • ❌ unCoded never has access to your funds. Your API keys correctly disabled withdrawal mean even unCoded itself cannot drain your account.
  • ❌ unCoded never streams your trading data to a centralized cloud. Trade history lives in your local database.
  • ❌ unCoded never auto-updates without your approval. Updates are operator-driven.
  • ❌ unCoded never executes a trade you didn’t authorize via your strategy or configuration. The bot does what you told it; nothing else.
  • ❌ unCoded never accepts remote commands from Telegram. Notification-only by design.

​
Why each architectural choice

Why: fault isolation. A compromise on one exchange container can’t reach others. A bad update applied to one venue’s bot can’t affect the rest.Trade-off: more containers to manage. We accept that for the isolation.
Why: minimize attack surface. The TradingBot, TelegramBot, SignalEditor, database — all live on the internal Docker network, no inbound exposure. Only the Dashboard is exposed (and SignalsBot if you use webhooks).Trade-off: setup complexity (reverse proxy required). We accept that for the dramatically reduced attack surface.
Why: phone is the easiest-to-compromise device. We don’t want phone leak to grant trading authority.Trade-off: no remote commands convenience. We accept that for the security boundary.
Why: auto-updates can introduce breaking changes during your most-vulnerable moments (live trading hours). Operator review of every update means surprises don’t happen during operation.Trade-off: operators have to apply updates manually. We accept that for the predictability.
Why: shared-secret tokens are vulnerable to replay attacks if intercepted in transit. HMAC signing means even an intercepted request can’t be replayed without the key.Trade-off: HMAC requires the sender to support it (the SignalEditor does; TradingView doesn’t). Both paths supported with security-appropriate fallback.
Why: bound the worst-case per-trade outcome. Even strategies that misbehave can’t lose unbounded amounts on a single trade.Trade-off: stop-loss triggers can crystallize losses that would have recovered. We accept that for the worst-case bound.
Why: unknown error codes from venues are more likely to indicate something’s changed venue-side. Silently retrying could compound real problems.Bot’s default: log, do not retry, surface to operator. Trade-off: occasional operator attention required for new error patterns. We accept that for the safety.

​
Operator security responsibilities

The architecture protects you only if you operate within its principles. These are the operator-side disciplines:
  • ✅ Never enable withdrawal permission on API keys. This is the single most important rule.
  • ✅ IP-allowlist your API keys at every venue.
  • ✅ 2FA on every venue account. Authenticator app or hardware key.
  • ✅ Strong passwords on Dashboard and venue accounts. Use a password manager.
  • ✅ Reverse-proxy 2FA (Authelia, Cloudflare Access, etc.) for Dashboard if remotely accessed.
  • ✅ Secret hygiene: never paste API keys into chat, email, Git, or anywhere outside your password manager.
  • ✅ Quarterly key rotation even without incidents.
  • ✅ Dashboard sessions on trusted devices only. Log out after sessions on shared devices.
  • ✅ Apply security updates immediately. Other updates can be on your schedule.
  • ✅ Engage kill switch during investigations of suspected compromise.
  • ✅ Audit venue API logs monthly for unfamiliar activity.
  • ✅ Backup database off-site daily for disaster recovery.
  • ✅ Test backup restoration quarterly to verify recoverability.
  • ✅ Document your security posture in operator runbook for re-verification.

​
What we don’t claim

Security is layered, not absolute. unCoded’s architecture limits the blast radius of compromises; it doesn’t prevent every possible attack.What unCoded does NOT prevent:
  • ❌ Compromised VPS host (provider-side incident, hypervisor exploit). Beyond unCoded’s scope.
  • ❌ Stolen developer laptop with cached secrets. Operator-side hygiene issue.
  • ❌ Social engineering attacks on your venue account. Venue-side security and operator vigilance.
  • ❌ Phishing attacks on your operator credentials. Operator awareness.
  • ❌ Black-swan exchange insolvency. Architectural limit; not all exchange risk can be mitigated by software.
What unCoded CAN do is ensure that within its scope, the worst-case is contained. The defense layers above. The architectural commitments. The operator disciplines.Together: a substantially safer setup than the alternatives. Not magic.

​
What’s next

API Key Security

The operator’s key-discipline page.

Architecture

The connection topology of unCoded.

Why unCoded

The case for unCoded’s design choices.

Risk overview

Risk management as the partner discipline.

Comparison

How unCoded’s security compares to alternatives.

Daily operations

Operator routines that maintain security posture.
Last modified on May 3, 2026