SoarSoar
Security & trust

How Soar protects you

The three guarantees: your keys live in your infrastructure, the bot signs a contract before any trade, and the permission set is the minimum we can actually use.

The key-safety invariant

Op 18 — Soar never touches your private keys after deploy

Customer broker keys (Coinbase, Kraken, Alpaca, etc.) live ONLY in your own Cloudflare Worker secret store. Soar's servers see them once — during the ~30-second deploy window when the wizard ships them into your Worker — and never again.

The keys are not logged, not cached, not backed up, and not retrievable from any Soar database even by Soar engineers. After deploy, the bot Worker signs broker API calls directly from your Cloudflare account. Soar is no longer in the call path.

This rule is non-negotiable in Soar's codebase. Every architectural decision is reviewed against it — even proposals that would save cost or improve performance are rejected if they would centralize customer keys.

What this means in practice: if Soar disappeared tomorrow, your bot would keep running on your Cloudflare account until you destroyed the Worker. You always have unilateral control. You can rotate the keys, pause the bot, or kill it entirely from your Cloudflare dashboard — Soar has zero ability to undo that.
The deployment agreement

What you sign before any bot runs

Before any bot trades on your behalf, Soar walks you through a formal agreement — same anatomy as a normal commercial contract (Definitions, Recitals, 13 numbered Articles, Limitation of Liability, Force Majeure, Arbitration, Waiver of Jury Trial).

The flow is ESIGN Act + UETA compliant: you scroll through the document, tick five separate affirmations (ownership, not-advice, risk acknowledgement, no-withdraw permission, arbitration), type your legal name to sign, and Soar captures a SHA-256 hash of the exact HTML you reviewed.

A timestamped PDF copy lands in your Document Center automatically. You can download or re-print it at any time.

Why this is here:Soar is software, not an advisor. The agreement makes that relationship explicit and documents that you affirmatively chose to enable automated execution. It also caps Soar's liability and routes any disputes through arbitration (standard for SaaS).
Broker permissions

What Soar uses — and what it does NOT need

What Soar needs

  • View / Read — to see your cash balance and current positions.
  • Trade / Place orders — to act on signals.

What Soar will never ask for

  • Withdraw / Transfer — Soar has zero withdrawal use-case. If you ever see a Soar guide ask you to enable withdraw permissions, it's a phishing site. Close it.
  • Master / Admin keys — read+trade-only sub-keys are the right scope.
  • Your password or 2FA codes — Soar never asks for these. Auth happens through the API key, not your login.
If a key is ever leaked:revoke it immediately from your broker dashboard. Because the key has no withdraw permission, even a worst-case leak can't move money — only place orders within your account. Rotate, redeploy, and you're back to safe.
Beyond your keys

What Soar does on its own side

  • Clerk handles auth — passwords / OAuth / 2FA / session management. Soar never sees your password.
  • Stripe handles payments — Soar never sees your card number; only the last 4 + expiration for receipts.
  • Supabase (Postgres) stores account profile + trade history + tokens + signed agreements. Row-level security is enforced on every row that has a clerk_user_id.
  • Vercel hosts the app + serverless functions. Edge functions are short-lived and stateless.
  • Cloudflare Workers hosts your bot (in YOUR Cloudflare account, not Soar's).
  • HTTPS everywhere. HSTS on the apex. No mixed-content surfaces.
See also

Related help