01 / Identity & Authentication
Access to HyperSignal Reactor begins with a cryptographically verified identity chain. There is no username+password combination that a database breach could expose — authentication is delegated to OAuth 2.0 providers and verified independently at every API boundary.
OAuth 2.0 via Google
Members authenticate through Google's OAuth 2.0 flow. HSR never receives, stores, or processes your Google password. The OAuth handshake produces an identity assertion (an id_token) signed by Google's private key, which HSR validates against Google's public JWK (JSON Web Key) endpoint. This proves the user is who they claim to be without HSR ever handling a password.
HMAC-SHA256 Session Tokens
After identity is confirmed, HSR issues a proprietary session token. This is not a standard JWT — it is a minimal, purpose-built token structure signed with HMAC-SHA256 using a server-side secret. The token encodes the member's email and a Unix timestamp. The entire token structure is Base64URL encoded and signed:
base64url(email:timestamp) + "." + hmac_sha256(email:timestamp, SERVER_SECRET)
Every server-side function that handles sensitive data independently recalculates the expected HMAC and compares it using crypto.timingSafeEqual() — a constant-time comparison function that eliminates timing side-channel attacks. An attacker who intercepts a token cannot forge one without the server secret, and cannot extract the secret through response-time analysis.
Token Time-To-Live (TTL) & Replay Attack Prevention
Session tokens carry a hard expiry of 8 hours. Any request presenting a token older than 8 hours is rejected with a 401. For particularly sensitive operations — vault deposits, point redemptions, exchange key writes — a separate verifyToken is required. This short-lived token has a 5-minute TTL and binds to both the user's email and the server secret with an operation-specific HMAC context (:pwverify suffix), preventing the same token from being replayed across different operation types.
Membership Verification
Beyond identity, HSR verifies active membership on every login via the Whop API and a Supabase-backed manual access table. A valid Google identity is necessary but not sufficient — a matching active Whop subscription or explicit manual access grant is required. The dual verification ensures that cancelled memberships lose access within hours, not days.
crypto.timingSafeEqual() ensures token verification takes the same amount of time regardless of whether the comparison succeeds or fails, defeating timing oracle attacks.02 / Cryptographic Encryption Architecture
Every exchange API key stored in HyperSignal Reactor is encrypted before it touches a database. The encryption stack was designed so that a complete database breach would yield nothing actionable — no key, no nonce, and no plaintext would be recoverable without simultaneous access to the server-side master key stored exclusively in Netlify's encrypted environment variable vault.
AES-256-GCM: Authenticated Encryption
Advanced Encryption Standard in Galois/Counter Mode (AES-256-GCM) is the encryption algorithm used for all stored secrets. This is not basic AES-CBC — GCM mode adds authenticated encryption, which means every ciphertext includes a cryptographic authentication tag. If the ciphertext is modified in any way — even a single bit — decryption fails and the data is rejected. This protects against tampering, bitflip attacks, and chosen-ciphertext attacks simultaneously.
Why AES-256-GCM specifically? It is the standard used by TLS 1.3, Signal Protocol, and AWS server-side encryption. The "256" refers to the key length in bits — 2²⁵⁶ possible keys, rendering brute-force attacks computationally impossible with any foreseeable technology including quantum computers under current threat models.
scrypt Key Derivation Function (KDF)
The AES-256 key is never stored directly. Instead, a key derivation function called scrypt derives the 256-bit key at runtime from the server-side master secret. scrypt is a memory-hard KDF — it is deliberately expensive to compute and requires large amounts of RAM to run, making it resistant to GPU-accelerated and ASIC-based brute-force attacks. Even if an attacker obtains the ciphertext, they cannot brute-force the master secret without extraordinary computational resources.
Random Initialization Vectors (IV)
Every encryption operation generates a fresh 96-bit cryptographically random IV using crypto.randomBytes(12). This ensures that even if the same API key were encrypted twice with the same master key, the resulting ciphertexts would be completely different. The IV is prepended to the ciphertext and stored alongside it — it is not secret, but its randomness ensures semantic security (an observer cannot determine if two ciphertexts encrypt the same plaintext).
The Encryption Envelope
The stored blob for each exchange key follows a deterministic binary layout:
[12 bytes: IV] + [16 bytes: GCM Auth Tag] + [N bytes: Ciphertext]
At decryption time, the IV and auth tag are extracted from fixed byte offsets, the AES-GCM decipher is initialized, and the auth tag is set before any plaintext is produced. If the tag verification fails, the final() call throws — the plaintext is never returned to the caller. This means corrupted or tampered ciphertexts are rejected before any data is released.
In-Memory Decryption: Zero Persistence
Decrypted keys exist only as JavaScript objects in the serverless function's RAM during the 100–300ms lifetime of the request. They are never written to disk, never logged, never included in error messages, and never transmitted to any party other than the target exchange. When the function execution ends, the Node.js runtime is destroyed — there is no persistent memory to inspect.
03 / Serverless Zero-Surface Infrastructure
Traditional web servers present a persistent, always-on attack surface: open SSH ports, a running OS with exploitable services, a file system that persists between requests, and a process that retains memory across sessions. HyperSignal Reactor was designed to eliminate every one of these vectors.
Netlify Serverless Functions
All HSR business logic runs as serverless functions deployed on Netlify's infrastructure. There is no "HSR server" to compromise. Each function invocation spawns an isolated Node.js runtime container, handles one request, and is destroyed. There is no persistent process memory between requests, no SSH access, no file system writes that survive beyond the invocation, and no open ports to scan or probe.
Blast-Radius Containment
Each function is scoped to a single responsibility: kraken-bot handles Kraken trades, points-redeem handles points, verify-member handles authentication. A vulnerability in one function cannot affect another — functions share no memory, no state, and no file system. The principle of least privilege is enforced architecturally, not just by policy.
No Persistent Server = No Persistent Threat
Attackers cannot install persistent backdoors, rootkits, or credential harvesters on infrastructure that does not persist. Penetration tests that rely on lateral movement through a live server — pivoting from a web process to a database shell, for example — are structurally impossible in a properly isolated serverless environment.
OKX VPS Relay: OKX requires exchange API callers to use whitelisted IP addresses. Netlify's serverless functions run from dynamic IPs, which cannot be whitelisted. HSR routes all OKX traffic through a dedicated VPS with a fixed, whitelisted IP address. The relay validates each request against a PROXY_SECRET header before forwarding. This means OKX API calls from HSR are doubly authenticated: once at the Netlify function level (webhook token) and once at the VPS relay level (proxy secret).
Kalshi Perpetuals — Direct API, No IP Whitelist: Kalshi's exchange API does not require IP whitelisting, so HSR connects to it directly from Netlify's serverless infrastructure without any relay intermediary. Authentication uses RSA-PSS SHA-256 — an asymmetric cryptographic signature scheme meaningfully stronger than shared-secret HMAC. Every Kalshi API request is signed with a 2048-bit RSA private key stored exclusively in Netlify's encrypted environment vault. Kalshi validates the signature against the public key registered in the API portal, confirming that the request originated from HSR without ever transmitting a reusable credential. The signature binds the request to a millisecond-precision timestamp, preventing replay attacks even if traffic is intercepted.
04 / Exchange Key Vault
The most sensitive data HSR holds is exchange API keys — credentials that, if compromised, could authorize trades on a member's exchange account. The key vault was designed with a threat model that assumes database breach and must still yield nothing exploitable.
Per-User Key Isolation
Each member's API keys for each exchange are stored as a separate encrypted row in a dedicated user_exchange_keys table. There is no shared key pool — each encryption operation uses that user's row with a freshly generated IV. Compromising one user's ciphertext does not help an attacker decrypt any other user's keys.
API Key Permission Scoping
HSR instructs members to generate API keys with trade-only permissions — no withdrawal access, no address management, no account settings. Even in the worst-case scenario where a key is decrypted, the key cannot move funds out of the exchange. This is documented in the Exchange Connections setup guide and enforced by exchange-level permission controls.
Webhook Token Authentication
TradingView alert webhooks that trigger bot trades are authenticated with a shared secret token. The comparison is performed using constant-time equality to prevent timing attacks. The token is stored only in Netlify's environment variable store — it never appears in source code or logs.
Exchange Authentication Protocols
Different exchanges require different authentication mechanisms — HSR implements each natively, adapting to the exchange's security model rather than applying a one-size-fits-all approach:
- Kraken & eToro — HMAC-based request signing. Each request carries a signature computed from the request parameters and the API secret, binding the payload to the credential and preventing tampering in transit.
- OKX — HMAC-SHA256 combined with mandatory IP whitelisting enforced at the exchange level. HSR routes OKX calls through a fixed-IP VPS relay to satisfy the IP constraint while adding a second authentication gate via
PROXY_SECRETheader. - Kalshi Perpetuals — RSA-PSS SHA-256 asymmetric cryptography. Three headers accompany every request:
KALSHI-ACCESS-KEY(the Key ID),KALSHI-ACCESS-TIMESTAMP(milliseconds since epoch), andKALSHI-ACCESS-SIGNATURE(the RSA-PSS signature of the concatenated timestamp + HTTP method + request path). Kalshi validates the signature against the registered public key — the private key is never transmitted, never logged, and never leaves Netlify's encrypted environment store. The timestamp binding ensures requests cannot be replayed even if captured. No IP whitelisting is required; the cryptographic proof is sufficient.
Per-User Trade Rate Limiting
The manual trade endpoint enforces a per-user 3-second cooldown enforced by querying the bot_executions audit table in Supabase. Any user who submits two trade requests within 3 seconds receives a 429 response on the second request. This prevents automated abuse, rapid-fire duplicate orders, and runaway loop scenarios where a bug in client code could hammer the exchange API.
05 / Database Security & Row Level Security
HSR uses Supabase, a managed PostgreSQL database with fine-grained access control. The database architecture enforces the principle of least privilege at every level.
Dual Key Architecture
Supabase provides two categories of API keys: a publishable anon key and a service role key. The anon key is embedded in the client-side application (station.html) and used for read operations governed by RLS policies. The service role key bypasses RLS and is exclusively used server-side inside Netlify functions — it is never sent to a browser, never included in a response payload, and never appears in source code.
Row Level Security (RLS)
Row Level Security is a PostgreSQL feature that adds access control at the data row level, enforced by the database engine itself — not by application logic. RLS policies on HSR tables ensure that even if a client somehow obtained direct Supabase API access with the anon key, they could only read rows they own. User A cannot read User B's exchange keys, vault balance, or message inbox regardless of how the API is called.
Encryption at Rest
Supabase manages PostgreSQL on infrastructure with AES-256 encryption at rest. Even if raw database storage media were physically extracted, the data would be unreadable without the storage encryption keys, which are managed by the cloud provider's key management service.
06 / Financial Controls & Audit Integrity
HSR's points and vault system operates under financial-grade controls. Every balance change is server-authoritative, every operation is logged to an append-only ledger, and multiple layers of protection prevent double-spending, race conditions, and unauthorized manipulation.
Server-Authoritative State
The client (browser) never determines a user's point balance. Every balance displayed in the Trading Station is fetched fresh from Supabase at render time. The client cannot submit a "spend 0 points" payload and receive goods — the server re-validates the expected cost against a hardcoded catalogue at every redemption. Cost mismatch or insufficient balance results in immediate rejection.
Immutable Audit Ledger
Every point movement — earning, spending, vault deposit, vault withdrawal, admin adjustment — writes an immutable row to the points_ledger table. This table records the action type, amount, balance before, balance after, vault state before, vault state after, a human-readable note, a reference ID, and a timestamp. Rows are never deleted or updated — they are append-only. This creates a complete, tamper-evident audit trail of every point in the system.
Race Condition Protection (TOCTOU Defense)
Time-Of-Check-Time-Of-Use (TOCTOU) is a class of vulnerability where two concurrent requests both pass a validation check before either writes to the database, resulting in double-processing. HSR's vault deposit flow implements an explicit race-condition guard: after a successful vault INSERT, the server immediately re-queries the vault table for the current user within the 24-hour window. If more than one deposit is found, the most recent deposit is automatically rolled back and the user's points are refunded. This closes the TOCTOU window to the sub-millisecond interval between INSERT and the re-query.
Financial Operation Gates
BUY / SELL
signature check
enforced
in-memory only
to exchange
row written
to UI
All 6 security checkpoints execute in under 300ms. The key is decrypted in RAM and destroyed immediately after the exchange call.
07 / Network & Transport Security
Every byte of data between a member's browser and HSR infrastructure travels over encrypted channels, and every HTTP response carries headers that instruct browsers to enforce additional protections.
TLS 1.3 Everywhere
All HSR traffic is served over Transport Layer Security 1.3 — the current gold standard for in-transit encryption. TLS 1.3 eliminates deprecated cipher suites (RC4, 3DES, DH under 2048-bit), removes the RSA key exchange (which retroactively exposes past sessions if the private key is later compromised — TLS 1.3's ephemeral key exchange provides Perfect Forward Secrecy), and reduces the handshake from 2 round-trips to 1. This makes connections both faster and harder to attack.
HTTP Security Headers
HSR's Netlify deployment injects the following security headers on every response:
08 / Automated Surveillance & Monitoring
Security at HSR is not a posture maintained manually — it is an automated orchestra of scheduled jobs, event-driven logs, and real-time audit trails that runs around the clock without human intervention.
Execution Audit Trail
Every trade executed through HSR — whether from the manual BUY/SELL interface or from a TradingView webhook — is logged to the bot_executions table in Supabase. The log includes exchange, action, trading pair, percentage of balance used, execution volume, price at time of execution, the transaction ID returned by the exchange, the member's email, and a precise UTC timestamp. This log is used for the Account History view in the Trading Station and provides a verifiable paper trail for every automated action the system takes on a member's behalf.
Admin Audit Intelligence Panel
HSR's admin panel includes a real-time Error Diagnostics section, an Architecture layer status view, and a Customer Journey tracker. Any unusual pattern — a spike in failed session tokens, an anomalous rate of vault rejects, or an unexpected pattern in redemptions — is visible immediately to the admin without requiring external tooling.
09 / Legal Controls & Compliance Infrastructure
Security extends beyond code into legal accountability. HSR maintains a documented compliance trail for every member interaction that carries legal weight.
Terms Acceptance Logging
When a member signs into HSR and proceeds through access verification, the exact version of the Terms of Service they accepted is recorded in the terms_acceptance_log table in Supabase, along with the member's email, a UTC timestamp, and the acceptance method. This creates a legally defensible record of informed consent that persists indefinitely.
Automated Execution Disclosure
HSR's Terms of Service contain an explicit section (Section 5a) disclosing that bot-executed trades are fully automated with no human review between signal and live order. Members must accept these terms before accessing any trading functionality. This disclosure is not buried — it is displayed in a high-contrast warning box specifically designed to draw attention.
Financial Operation Receipts
Every bill credit redemption triggers a dual-email notification: one to the member confirming their redemption request and one to the admin with full redemption details. Both emails include the ledger ID linking to the immutable audit record. This creates an external paper trail outside the database for every financial operation that has real monetary value.
10 / What HyperSignal Reactor Never Does
Security promises are only meaningful when they include explicit prohibitions. These are not aspirational guidelines — they are enforced by architecture:
The Commitment: Security at HyperSignal Reactor is not a feature — it is the foundation. Every architectural decision, from choosing serverless functions over persistent servers to using AES-256-GCM over simpler encryption modes, was made with the assumption that any system component could be compromised, and designing so that a compromise of one component yields nothing that compromises the whole.