How Soar protects you

When you complete the wizard for a self-hosted bot, your broker API keys travel along a deliberately short path: from your browser into a temporary HttpOnly cookie, from that cookie to Soar’s deploy endpoint, and from the deploy endpoint into your Cloudflare Worker’s secret store — or, for Interactive Brokers and Webull, into a setup form on your own DigitalOcean droplet. After that, the keys are written-and-forgotten on Soar’s side. (The one exception — a Soar-hosted managed bot — is covered just below.)

Cloudflare Worker secrets are encrypted at rest by Cloudflare and only readable by your Worker’s runtime. They are not returned by any Cloudflare API call — not even to you after the write completes. Once stored, the only way to read the plaintext is to run code inside the Worker. Soar’s code does that to sign broker calls; nothing else on the internet has that access.

Critically: the keys are not logged, not cached, not backed up to Soar’s database, and not retrievable by Soar engineers. Every architectural proposal at Soar is reviewed against this rule — even proposals that would save cost or improve latency are rejected if they would put customer keys on Soar infrastructure.

Why this architecture exists

• Regulatory clarity. Soar is a software publisher, not a custodian of customer funds. Holding broker keys at rest would change that legal posture in ways that are not in customers’ interest.
• Audit simplicity. If Soar were breached, the universe of damage is Soar-side data — not customer broker accounts. Forensics, disclosure, and recovery are all dramatically simpler when the blast radius is bounded.
• Customer control. You can rotate keys, kill the Worker, or disconnect from Soar at any time. None of those actions require Soar’s cooperation.
• Trust by design, not by promise. “Soar promises it won’t misuse your keys” is a much weaker statement than “Soar architecturally cannot read your keys after deploy.” The architecture is the proof.

The one exception — Soar-hosted managed bots

Everything above describes the self-hosted options, where your keys live on your own Cloudflare or DigitalOcean account and Soar never holds them. There is one deliberate, opt-in exception: Soar-hosted managed bots.

If you choose Soar-hosted at setup, you give explicit consent for Soar to run the bot on its own infrastructure — which means storing your broker keys server-side. When you do, they are encrypted with AES-256, scoped to trade-only (Soar can never withdraw or move your funds), and never logged in plaintext. You can revoke consent and have the keys deleted at any time from your Document Center.

This is the one place the “keys never touch Soar” default bends — and it only happens when you opt in. The Cloudflare and DigitalOcean self-host paths remain the default and keep your keys entirely on your own account.

Before any bot trades on your behalf, Soar walks you through a formal contract. It is shorter than a typical SaaS terms-of-service — 13 numbered Articles with the same anatomy as a normal commercial agreement: who is signing, what each party can do, who is responsible for what, how disputes are handled, and what happens when something goes wrong.

The signing flow is compliant with the federal ESIGN Act and the state-level Uniform Electronic Transactions Act (UETA, adopted in 49 of 50 states). The signature you type is legally equivalent to a wet-ink signature.

What the 13 Articles cover

The five affirmations you tick

Each affirmation is a separate checkbox. Each one is a distinct legal acknowledgement — not a generic “I agree to everything” lump.

The audit trail

• SHA-256 hash of the exact HTML. Soar captures a cryptographic hash of the exact agreement bytes you reviewed at signing time. If the agreement is ever disputed, that hash proves which version of the document was on your screen.
• Timestamped PDF. A copy of the signed agreement — with your typed signature, the timestamp, and your account email — is generated server-side and landed in your Document Center automatically.
• You can retrieve it any time. Open Document Center→ from any device. Soar cannot alter the PDF after signing; if either side wants to amend the agreement, you redeploy from the wizard with a fresh signature.
• Five-year retention minimum. Soar retains the signed agreement for at least five years after the bot is disconnected, in line with standard commercial record retention.

Soar Vault — one encrypted backup of every bot

As you connect bots, Soar can save their configuration into a single encrypted file — your Soar Vault. One file holds every bot across every broker (its settings and, where applicable, the credentials needed to redeploy), so you never have to re-paste keys or rebuild from scratch.

• The vault is locked with a passkey (Face ID / Touch ID) or a passphrase you choose — the encryption happens in your browser.
• Soar stores only the ciphertext. Without your passkey or passphrase, the file is unreadable — even to Soar.
• Manage it any time in your Document Center→: download it, unlock it to view your bots, or retire it.

Managed Auto-Recovery (opt-in)

Servers occasionally die — a droplet runs out of memory, a host has an outage. By default, recovering a self-hosted bot is something you trigger. If you'd rather Soar handle it, you can opt into Managed Auto-Recovery.

• You authorize Soar to keep a server-decryptable copy of your bot's recovery bundle.
• If the bot's host goes down, a Soar process rebuilds it for you, unattended — no re-paste, no manual rebuild.
• This is a deliberate, consented departure from the “keys never touch Soar” default — the same trade-off as a Soar-hosted bot. The bundle is encrypted, trade-only, and revocable any time in your Document Center.

Sign-in (Clerk)

Authentication is handled by Clerk — a SOC 2-certified auth provider. Soar never sees your password, your OAuth tokens, or your 2FA codes. Clerk sends Soar a signed webhook when you sign in, sign up, or change your name/email; that webhook tells Soar “this user exists and is who they say they are.” The actual credential flow happens between you and Clerk.

Payments (Stripe)

Subscription billing and one-time purchases run through Stripe. Soar never sees your card number, CVV, or expiration. Stripe gives Soar a customer ID and a subscription ID; receipts display only the last four digits of the card, which Stripe provides. PCI compliance is Stripe’s scope, not Soar’s.

What Soar stores

• Account profile: email, display name, plan tier, signup timestamp. From Clerk via webhook.
• Opt-in trader profile: if you chose to share it during onboarding — experience level, risk tolerance, position-size preference. Used to tailor signal recommendations. You can clear it any time in account settings.
• Dashboard activity: which signals you viewed, which cards you starred or shared. Used to improve relevance.
• Support thread content: tickets you open and replies. Retained for support history.
• Push notification subscriptions: opt-in only. Stored only if you grant browser/device push permission.
• Bot metadata: which brokers you have bots on, the bot’s last heartbeat timestamp, recent equity readings, open positions and recent fills. The keys themselves are NOT stored — only the data your bot reports back.
• Signed agreement copy: the PDF and SHA-256 hash of every deployment agreement you have signed.

Account deletion

To delete your account, open a support ticket from your dashboard and request account deletion. Soar purges the records on its side: your Supabase profile, dashboard activity, trader profile, push subscriptions, support thread content, and bot metadata. Storage assets (any saved chart screenshots, marketing media etc.) are deleted from the storage bucket.

What is retained for legal compliance: the signed deployment agreement PDF (five years after disconnect, per standard commercial record retention) and Stripe-side payment records (seven years, per IRS and SEC retention rules for financial transactions — Stripe holds these, not Soar). Your trade history at the broker is the broker’s record-keeping, governed by their retention policy.

A trust statement is only as strong as what backs it. Here are the concrete architectural facts that make a “rogue Soar” scenario bounded:

• The Worker code is on your Cloudflare account, readable by you. Open Cloudflare → Workers & Pages → your bot → Quick edit, and you can inspect every line of JavaScript the bot is running. What you see is what it does.
• You can revoke the broker key at any time from your broker’s dashboard. That kills the bot’s ability to trade in one click. No coordination with Soar required.
• You can destroy the Worker at any time from your Cloudflare dashboard. That removes the keys from the secret store and ends all possibility of further bot activity, instantly.
• The deployment agreement is a binding contract that limits Soar’s authority. Soar acting outside the scope of that contract has the same legal consequences as any commercial breach.
• The keys have no withdraw permission. Even in a fully compromised scenario, no one can move money out of your broker account using a Soar bot key. The worst-case damage is unauthorized in-account trading, which is reversible by closing positions.

Soar runs a live-trading dashboard — View trading history→ — that shows real positions traded against Soar’s own Kraken and Interactive Brokers accounts. Those are operator broker keys — the keys to TMI’s own trading accounts, used to validate the engine against real markets and to publish an honest live track record.

Those operator keys ARE on Soar’s infrastructure. They have to be — the operator trading account is run by Soar, for Soar. But this is a completely separate boundary from customer key handling.

The boundary, stated plainly

• Operator keys belong to the operator (TMI / Soar). They trade against Soar’s own dollars in Soar’s own broker accounts. They live on Vercel environment variables and are used by Soar’s execution dashboard.
• Customer keys belong to you. They trade against your dollars in your broker accounts. They live on YOUR Cloudflare Worker, with all the architectural guarantees above.
• These two paths never merge. No customer bot ever signs a call with an operator key. No operator code ever reads a customer key. The two systems share signals and dashboard plumbing but not authentication material.

• Clerk for authentication. Passwords, OAuth (Google), and session management. Soar never sees the password.
• Stripe for payments. Soar never sees card numbers; only the Stripe-issued customer ID, subscription ID, and the last four digits of the card for receipts.
• Supabase (PostgreSQL) for account profile, trade history, opt-in trader profile, push subscriptions, support threads, and signed agreement records. Row-level security is enforced on every row that has a user identifier — your data is not readable by other users’ queries.
• Vercel for application hosting and serverless functions. Stateless short-lived functions; no persistent customer-key storage.
• Cloudflare Workers for the customer bot runtime. The Worker lives in YOUR Cloudflare account, not Soar’s.
• HTTPS / HSTS on every public surface. No mixed-content surfaces. The apex domain is HSTS-preloaded.