System Requirements Document for cryptocurrency-trading-ai

1. Introduction

NexTrade AI is a web-based cryptocurrency trading, AI automated strategy, and affiliate investment platform. It gives self-directed retail traders and quant-curious investors a single instrument-grade surface for live market execution, automated bot allocation, wallet custody of funds, and multi-level affiliate earnings — all rendered in a premium dark-mode aesthetic with high-density data visualization.

The product intent is to make the operator feel like they are running a machine rather than browsing a website: real-time Binance market data, live PnL, bot yields, order-book depth, and tiered commission reporting are presented as instrument readouts, ruled data rows, and circular gauges rather than friendly cards.

Audience. Two accepted human roles operate the platform:

• Trader / Investor (user) — the self-directed retail trader or quant-curious investor who signs up (optionally with a referral code), completes KYC, trades the live market, allocates capital to AI bots, manages deposits and withdrawals, and tracks affiliate earnings.
• Platform Administrator (admin) — the operator who supervises user accounts and KYC statuses, curates the AI bot / trading-strategy catalog, and reviews financial transactions and referral bonus records.

The platform is delivered as a first-party web application with application-owned identity, JWT-protected routes, a Supabase/PostgreSQL relational backend with Row-Level Security, Binance market-data integration, a crypto payment gateway, and scheduled background automation for bot yield and commission processing.

2. System Overview

NexTrade AI is a single first-party web application composed of an anonymous public entry surface, a dual-mode identity access surface, six authenticated trader destinations, and three administrator destinations. All authenticated destinations are protected by JWT session tokens and role-based access control limited to the user and admin roles.

Current delivery. The current release delivers:

• Anonymous landing surface explaining NexTrade AI, its trading and investment capabilities, and its intended users.
• Dual-mode authentication (LoginSignUp) with Sign In / Create Account tabs, Google and Apple ID SSO, password recovery, and optional referral code capture at enrollment.
• Mandatory KYC verification with unverified, pending, and verified states.
• Live Binance market data via public REST and WebSocket feeds for BTC/USDT, ETH/USDT, SOL/USDT, and BNB/USDT, with historical candlestick rendering.
• Market and limit order execution with real-time PnL computation and a 0.1% protocol execution fee on closed trades.
• AI trading bot catalog with performance metrics and flexible allocation investment.
• Wallet balances, single-use crypto deposit address generation with QR codes, and withdrawal requests.
• Three-tier affiliate commission engine (7% / 3% / 1%) triggered on deposits and bot daily yields.
• Daily scheduled bot yield processing with TRADING_PROFIT registration and downstream commission propagation.
• Administrator supervision of users, KYC statuses, bot catalog, and financial records.

Actors and ownership. Human interaction is owned by first-party pages. Binance owns market data and, when the user enables it, automated execution on the user's own exchange account. The crypto payment gateway (Web3 Wallet Connect, NOWPayments, or Binance Pay API) owns deposit address generation and blockchain confirmation. Scheduled edge functions and database triggers own background yield and commission computation; these are system processes with no direct human interaction surface.

Narrow exclusions. No capabilities beyond those stated in the authoritative requirements are in scope. The platform does not add adjacent account-management, social, or portfolio-advisory features. Red #FF3B30 is a data state only and is never used as a brand or decorative colour. Automated API execution on user exchange accounts occurs only when the user explicitly enables it.

2a. Product Interpretation and Delivery Boundary

NexTrade AI is delivered as a first-party web application. Identity is application-owned: users self-enroll through the /login surface, and returning users verify through the same surface before reaching protected work. The anonymous Landing surface is the public entry point and explains the product before authentication; it does not expose protected state.

Protected destinations — /dashboard, /market, /ai-trading, /wallet, /affiliate, /settings, and the administrator destinations Users, Bot Management, and Transactions — require a valid JWT session token and are role-restricted. KYC verification is mandatory for profile completion and gates required platform participation.

Two external systems own work that NexTrade AI does not: Binance owns public market data feeds and, when enabled by the user, automated execution against the user's own exchange account; the crypto payment gateway owns deposit address generation and blockchain confirmation. Background automation — daily bot yield processing and the referral commission trigger — runs as scheduled edge functions and database triggers without a human interaction surface.

Everything described in this document is current. No future-horizon capabilities are defined.

2b. Page Content and Component Coverage

Landing

• Information / state: Anonymous public entry. Product identity, the three-line value proposition (trade, automate, compound), and a live readout strip of four market figures (BTC/USDT, ETH/USDT, SOL/USDT, BNB/USDT) streamed from Binance. No protected state is exposed.
• Primary actions: Navigate to /login via the emerald filled "Create Account" CTA; navigate to /login via the hairline-outlined "Sign In" secondary.
• Supporting actions: None beyond the two entry CTAs.
• Domain entities: Market ticker values (symbol, price, delta) sourced from Binance public feeds.
• Component responsibilities: 60/40 split composition — left column carries the stacked headline and the full-bleed ruled readout strip; right column carries a full-height instrument panel with a circular gauge ring that sweeps to 100% on load with an amber tick. The headline block bleeds off the left viewport edge at 1280px.
• States: Loading — readout strip cells show placeholder rules until the first ticker frame arrives. Empty — if the ticker stream is unavailable, cells render a muted "—" with a schematic line-art bezel. Success — live figures flash green on uptick and red on downtick. Error — a muted inline notice states that live market data is unavailable; the CTAs remain fully usable. Recovery — the stream reconnects automatically and cells resume flashing.
• Responsive: At 375px the panel stacks below the headline, the readout strip becomes a horizontally scrollable ticker, and the headline drops to 44px with a full-width CTA.

/login

• Information / state: Dual-mode auth component (LoginSignUp) with switchable "Sign In" / "Create Account" tabs driven by active tab state. Sign In fields: Email, Password, "Forgot Password?" trigger, "Sign In to NexTrade AI" primary submit. Create Account fields: Full Name, Email, Password, Confirm Password, optional Referral Code, "Create Account" primary submit. Third-party SSO buttons for Google and Apple ID.
• Primary actions: Submit sign-in credentials; submit account creation; trigger password recovery; authenticate via Google or Apple ID.
• Supporting actions: Switch tabs; enter an optional referral code at enrollment.
• Domain entities: profiles (full_name, email, avatar_url, kyc_status, referral_code, referred_by, created_at); auth session token.
• Component responsibilities: Tab state controller; form validation; SSO button group; referral code capture that binds referred_by on the new profile; session issuance on success.
• States: Loading — submit buttons enter a disabled pending state during credential verification. Empty — pristine forms with placeholder guidance. Success — session issued and the user is routed to /dashboard; a new account is routed to profile completion and KYC. Error — inline field-level errors for invalid credentials, mismatched passwords, duplicate email, or invalid referral code; SSO failures surface a retry affordance. Recovery — "Forgot Password?" initiates recovery; failed submissions preserve entered values.
• Access: Anonymous. This surface owns both first-use identity establishment and returning verification.

/dashboard

• Information / state: Total Portfolio Balance, Net PnL card, Active AI Strategy cards, Recent Transactions table. Readout strip leads the page.
• Primary actions: Review portfolio balance and net PnL; open an active AI strategy; review recent transactions.
• Supporting actions: Navigate to /ai-trading, /market, /wallet, /affiliate, or /settings via the rail.
• Domain entities: wallets (available_balance, locked_balance, asset); investments (invested_amount, current_profit, status, started_at); ai_bots (name, risk_level, expected_daily_roi); transactions (type, amount, asset, status, created_at).
• Component responsibilities: Portfolio balance display at extreme type contrast with a delta chip; Net PnL card; active strategy cards with bot performance arcs; recent transactions ruled table.
• States: Loading — readout strip and cards show skeleton rules. Empty — no active strategies renders a schematic line-art empty state with a route to /ai-trading; no transactions renders an empty ruled table. Success — balances, PnL, strategy cards, and transactions render with tabular numerals. Error — a muted inline notice with a retry control; partial data renders where available. Recovery — retry refetches; the page remains navigable.

/market

• Information / state: Embedded live candle chart, Order Book, Real-Time Trade Stream, Market/Limit Buy & Sell Execution Panel. Symbol selection across BTC/USDT, ETH/USDT, SOL/USDT, BNB/USDT.
• Primary actions: Place a MARKET or LIMIT BUY or SELL order; select a symbol.
• Supporting actions: Inspect order-book depth; watch the real-time trade stream; read the live candle chart.
• Domain entities: trades (symbol, side, type, entry_price, exit_price, quantity, pnl, status, created_at); Binance klines and ticker streams.
• Component responsibilities: Candlestick bay rendering GET /api/v3/klines; order-book depth bars with slow vertical drift; trade stream; execution panel with side, type, price, and quantity inputs; live price cells that flash on tick.
• States: Loading — chart bay and order book show schematic placeholders. Empty — no open orders renders an empty ruled table. Success — chart, book, stream, and execution panel are live; a placed order appears in the open-orders list with status OPEN. Error — order rejection (insufficient balance, invalid price, invalid quantity) surfaces an inline error and preserves inputs; a market-data outage shows a muted notice while the execution panel remains available. Recovery — the stream reconnects; the user can correct and resubmit.

/ai-trading

• Information / state: Catalog of available trading bots with performance metrics (name, risk_level, min_investment, expected_daily_roi, active_users_count, is_active). "Invest Now" modal with flexible allocation input.
• Primary actions: Open the "Invest Now" modal for a bot; submit a flexible allocation amount.
• Supporting actions: Compare bots by risk level, minimum investment, and expected daily ROI; review active users count.
• Domain entities: ai_bots / trading_strategies; investments (invested_amount, current_profit, status, started_at); wallets (available_balance).
• Component responsibilities: Bot spec sheet rows with ROI arcs; allocation input with minimum-investment validation; investment creation that debits the wallet and creates an investments record with status active.
• States: Loading — spec rows show skeleton rules. Empty — no active bots renders a schematic empty state. Success — the investment is created and the bot's active users count increments; the user's active strategy appears on /dashboard. Error — allocation below min_investment or above available balance surfaces an inline error and preserves the entered amount. Recovery — the user corrects the amount and resubmits.

/wallet

• Information / state: Asset balance breakdown (available and locked balances per asset), Deposit modal with single-use crypto QR code generation, Withdrawal request form, transaction status.
• Primary actions: Generate a single-use deposit address and QR code; submit a withdrawal request.
• Supporting actions: Select a network (TRC20, BEP20, ERC20); review transaction history and status.
• Domain entities: wallets (asset, available_balance, locked_balance, updated_at); transactions (type, amount, asset, tx_hash, status, created_at).
• Component responsibilities: Asset ledger ruled rows; deposit modal that requests a single-use address from the crypto payment gateway and renders its QR code; withdrawal form that creates a WITHDRAWAL transaction with status PENDING; webhook-driven balance refresh on blockchain confirmation.
• States: Loading — ledger rows show skeleton rules. Empty — a zero-balance ledger renders with a prompt to deposit. Success — a confirmed deposit auto-credits available_balance and the transaction moves to COMPLETED; a withdrawal request appears as PENDING. Error — address generation failure or withdrawal rejection surfaces an inline error with a retry. Recovery — the user regenerates a single-use address or corrects the withdrawal request.

/affiliate

• Information / state: Unique referral link sharing widget, total team volume counter, Tier 1/2/3 breakdown table with active team count and bonus earnings. Three-concentric-ring diagram where each tier's arc length is its share of team volume.
• Primary actions: Copy and share the unique referral link.
• Supporting actions: Review tier-by-tier active team counts and bonus earnings; read total team volume.
• Domain entities: profiles (referral_code, referred_by); referrals_and_bonuses (referrer_id, referee_id, level, bonus_amount, source_transaction_id, created_at); transactions (type = REFERRAL_BONUS).
• Component responsibilities: Referral link widget bound to the user's referral_code; team volume counter; tier breakdown table; concentric ring diagram with a slow amber tick looping the active ring.
• States: Loading — rings and table show skeleton rules. Empty — no referrals renders a schematic network-node line-art empty state with the sharing widget still active. Success — tiers populate with active counts and bonus earnings as commissions accrue. Error — a muted inline notice with retry. Recovery — retry refetches; the sharing widget remains usable.

/settings

• Information / state: KYC document upload portal with unverified / pending / verified status, Binance API key management with AES-256 encrypted storage, Security 2FA setup. Profile fields: full_name, email, avatar_url.
• Primary actions: Upload KYC documents; save Binance API keys; enable 2FA.
• Supporting actions: Update profile fields; review current KYC status.
• Domain entities: profiles (full_name, email, avatar_url, kyc_status); encrypted Binance API key material.
• Component responsibilities: KYC upload portal that moves kyc_status from unverified to pending on submission; API key form that encrypts with AES-256 before storage and exposes an enable toggle for automated execution; 2FA setup panel.
• States: Loading — panels show skeleton rules. Empty — an unverified profile shows the upload prompt. Success — KYC submission sets pending; an administrator decision moves it to verified; API keys save with a confirmation; 2FA enables with a confirmation. Error — upload failure, invalid key format, or 2FA setup failure surfaces an inline error. Recovery — the user retries the upload or re-enters the key.

Users

• Information / state: Administrative list of user accounts with KYC statuses (unverified, pending, verified), profile fields, and referral relationships.
• Primary actions: Review user accounts; act on a pending KYC status.
• Supporting actions: Filter and search the user list; inspect a user's referral lineage.
• Domain entities: profiles (id, full_name, email, avatar_url, kyc_status, referral_code, referred_by, created_at).
• Component responsibilities: Ruled user table; KYC status control; user detail panel.
• States: Loading — table shows skeleton rows. Empty — no users renders an empty ruled table. Success — the table renders with current KYC statuses; a status change persists and is reflected for the affected user. Error — a muted inline notice with retry. Recovery — retry refetches.
• Access: Role-restricted to admin.

Bot Management

• Information / state: Administrative oversight of the AI bot and trading-strategy catalog: name, risk_level, min_investment, expected_daily_roi, active_users_count, is_active.
• Primary actions: Review the bot catalog; toggle is_active.
• Supporting actions: Inspect a bot's active user count and configured ROI.
• Domain entities: ai_bots / trading_strategies.
• Component responsibilities: Bot spec sheet table; active toggle; catalog detail panel.
• States: Loading — spec rows show skeleton rules. Empty — no bots renders an empty ruled table. Success — the catalog renders; an is_active change persists and removes the bot from the trader-facing catalog when deactivated. Error — a muted inline notice with retry. Recovery — retry refetches.
• Access: Role-restricted to admin.

Transactions

• Information / state: Administrative review and control of financial transactions, referral bonuses, and related records: type (DEPOSIT, WITHDRAWAL, TRADING_PROFIT, REFERRAL_BONUS, LEVEL_BONUS), amount, asset, tx_hash, status (PENDING, COMPLETED, FAILED), created_at, plus referrals_and_bonuses records.
• Primary actions: Review transactions; act on a PENDING or FAILED transaction.
• Supporting actions: Filter by type, status, asset, or user; trace a bonus to its source_transaction_id.
• Domain entities: transactions; referrals_and_bonuses.
• Component responsibilities: Ruled transaction table; status control; bonus lineage panel.
• States: Loading — table shows skeleton rows. Empty — no transactions renders an empty ruled table. Success — the table renders with current statuses; a status change persists and is reflected in the affected user's wallet and history. Error — a muted inline notice with retry. Recovery — retry refetches.
• Access: Role-restricted to admin.

3. Functional Requirements

Authentication and Identity

FR-1 — Dual-mode authentication surface (explicit) As a Trader / Investor or Platform Administrator, I should reach a dual-mode auth component (LoginSignUp) with switchable "Sign In" and "Create Account" tabs driven by active tab state, so that I can either verify an existing session or establish a new one from a single surface.

• Trigger: Navigation to /login.
• Observable result: The active tab's form renders; switching tabs transitions visibility smoothly.
• Access: Anonymous.
• Failure/recovery: If the surface fails to load, the user can reload; no protected state is exposed.
• Continuation: Successful sign-in routes to /dashboard; successful account creation routes to profile completion and KYC.

FR-2 — Sign In form (explicit) As a Trader / Investor or Platform Administrator, I should sign in with Email and Password using the "Sign In to NexTrade AI" primary submit, with a "Forgot Password?" trigger available, so that I can resume my protected work.

• Input: Email, Password.
• Observable result: A JWT session token is issued and the user reaches /dashboard.
• Access: Anonymous entry; protected state remains unavailable until identity is established.
• Failure/recovery: Invalid credentials surface an inline error and preserve entered values; "Forgot Password?" initiates recovery.
• Continuation: The user proceeds to their protected destinations.

FR-3 — Create Account form (explicit) As a Trader / Investor, I should create an account with Full Name, Email, Password, Confirm Password, an optional Referral Code, and the "Create Account" primary submit, so that I can begin using the platform.

• Input: Full Name, Email, Password, Confirm Password, optional Referral Code.
• Observable result: A profiles record is created with a unique referral_code; when a Referral Code is supplied, referred_by is bound to the referring profile.
• Access: Anonymous.
• Failure/recovery: Mismatched passwords, duplicate email, or an invalid referral code surface inline errors and preserve entered values.
• Continuation: The new user proceeds to profile completion and KYC.

FR-4 — Third-party SSO (explicit) As a Trader / Investor or Platform Administrator, I should authenticate with Google or Apple ID via the SSO option buttons, so that I can establish or resume a session without a password.

• Observable result: A session is issued and a profiles record exists or is created.
• Access: Anonymous.
• Failure/recovery: An SSO failure surfaces a retry affordance.
• Continuation: The user proceeds to their protected destinations.

FR-5 — JWT-protected secure routes (explicit) As a Trader / Investor or Platform Administrator, I should have every secure route require a valid JWT session token, so that protected state is never reachable without an established identity.

• Observable result: Requests without a valid token are rejected and redirected to /login.
• Failure/recovery: An expired or invalid token returns the user to /login to re-verify.
• Continuation: After re-verification the user returns to the requested destination.

FR-6 — Role-Based Access Control (explicit) As a Platform Administrator, I should have access governed by RBAC with exactly the roles user and admin, so that administrative destinations are reachable only by administrators.

• Observable result: user-role sessions reach trader destinations; admin-role sessions reach Users, Bot Management, and Transactions.
• Failure/recovery: A session without the required role is denied access to the restricted destination.
• Continuation: The user continues within their permitted destinations.

FR-7 — Mandatory KYC verification status (explicit) As a Trader / Investor, I should have a mandatory KYC verification status with the states unverified, pending, and verified, so that my profile completion reflects my verification standing.

• Observable result: kyc_status is unverified on creation, moves to pending on document submission, and to verified on administrative approval.
• Failure/recovery: A rejected or failed submission returns the status to unverified with an inline error.
• Continuation: The user resubmits or proceeds once verified.

Database Schema and Row-Level Security

FR-8 — Supabase/PostgreSQL relational schema with RLS (explicit) As a Platform Administrator, I should have the relational schema created in Supabase/PostgreSQL with full Row-Level Security enabled on all tables, so that each row is accessible only to its rightful owner.

• Observable result: All seven tables exist with RLS enabled and policies enforced.
• Failure/recovery: A policy violation returns no rows rather than leaking data.
• Continuation: Authorized reads and writes proceed normally.

FR-9 — profiles table (explicit) As a Platform Administrator, I should have a profiles table with id (uuid, Primary Key, refs auth.users), full_name (text), email (text, unique), avatar_url (text), kyc_status (enum: unverified, pending, verified), referral_code (text, unique), referred_by (uuid, refs profiles.id), and created_at (timestamp), so that user identity, verification, and referral lineage are durably recorded.

FR-10 — wallets table (explicit) As a Platform Administrator, I should have a wallets table with id (uuid, Primary Key), user_id (uuid, refs profiles.id), asset (text, e.g., 'USDT', 'BTC', 'ETH'), available_balance (numeric, default 0.00), locked_balance (numeric, default 0.00), and updated_at (timestamp), so that per-asset balances are durably recorded.

FR-11 — ai_bots / trading_strategies table (explicit) As a Platform Administrator, I should have an ai_bots / trading_strategies table with id (uuid, Primary Key), name (text, e.g., 'Alpha Momentum Grid', 'Quant Scalper AI'), risk_level (enum: Low, Medium, High), min_investment (numeric), expected_daily_roi (numeric, percentage), active_users_count (integer), and is_active (boolean), so that the bot catalog is durably recorded.

FR-12 — investments table (explicit) As a Platform Administrator, I should have an investments table with id (uuid, Primary Key), user_id (uuid, refs profiles.id), bot_id (uuid, refs ai_bots.id), invested_amount (numeric), current_profit (numeric), status (enum: active, paused, closed), and started_at (timestamp), so that each user's bot allocations are durably recorded.

FR-13 — trades table (explicit) As a Platform Administrator, I should have a trades table with id (uuid, Primary Key), user_id (uuid, refs profiles.id), symbol (text, e.g., 'BTCUSDT'), side (enum: BUY, SELL), type (enum: MARKET, LIMIT), entry_price (numeric), exit_price (numeric, nullable), quantity (numeric), pnl (numeric), status (enum: OPEN, CLOSED, CANCELLED), and created_at (timestamp), so that every order and its outcome are durably recorded.

FR-14 — transactions table (explicit) As a Platform Administrator, I should have a transactions table with id (uuid, Primary Key), user_id (uuid, refs profiles.id), type (enum: DEPOSIT, WITHDRAWAL, TRADING_PROFIT, REFERRAL_BONUS, LEVEL_BONUS), amount (numeric), asset (text), tx_hash (text, nullable), status (enum: PENDING, COMPLETED, FAILED), and created_at (timestamp), so that every financial movement is durably recorded.

FR-15 — referrals_and_bonuses table (explicit) As a Platform Administrator, I should have a referrals_and_bonuses table with id (uuid, Primary Key), referrer_id (uuid, refs profiles.id), referee_id (uuid, refs profiles.id), level (integer, e.g., 1, 2, 3), bonus_amount (numeric), source_transaction_id (uuid, refs transactions.id), and created_at (timestamp), so that every tiered bonus is durably recorded and traceable to its source.

External Integrations and Real-Time Data

FR-16 — Binance public REST and WebSocket connection (explicit) As a Trader / Investor, I should have the platform connect to the Binance Public REST API and WebSockets at wss://stream.binance.com:9443/ws, so that market data is live and authoritative.

• Observable result: Live ticker and kline data populate the market surfaces.
• Failure/recovery: A dropped connection reconnects automatically; a sustained outage surfaces a muted notice.
• Continuation: Live data resumes without user action.

FR-17 — Real-time ticker stream (explicit) As a Trader / Investor, I should receive a real-time ticker stream (<symbol>@ticker) for live price updates on BTC/USDT, ETH/USDT, SOL/USDT, and BNB/USDT, so that I can act on current prices.

• Observable result: Price cells update on each tick and flash green on uptick and red on downtick.
• Failure/recovery: The stream reconnects; cells hold their last value with a muted indicator.
• Continuation: Updates resume automatically.

FR-18 — Historical candlestick data (explicit) As a Trader / Investor, I should have historical candlestick data fetched via GET /api/v3/klines to render lightweight TradingView charts, so that I can read price structure before executing.

• Observable result: The candle chart renders the requested symbol and interval.
• Failure/recovery: A fetch failure shows a schematic placeholder with a retry.
• Continuation: The chart renders once the fetch succeeds.

FR-19 — Secure Binance API key storage (explicit) As a Trader / Investor, I should have my private Binance API keys stored AES-256 encrypted in my settings for automated API execution on my exchange account if enabled, so that automation is possible without exposing my keys.

• Input: Private API key material entered on /settings.
• Observable result: Keys are stored encrypted; an enable toggle governs whether automated execution runs.
• Failure/recovery: An invalid key format surfaces an inline error and nothing is stored.
• Continuation: The user corrects the key or leaves automation disabled.

FR-20 — Crypto payment gateway deposit address generation (explicit) As a Trader / Investor, I should have deposit addresses generated through Web3 Wallet Connect (or NOWPayments / Binance Pay API) on TRC20, BEP20, or ERC20, so that I can fund my wallet.

• Input: Network selection on /wallet.
• Observable result: A single-use deposit address and its QR code are rendered.
• Failure/recovery: Address generation failure surfaces an inline error with a retry.
• Continuation: The user regenerates a single-use address.

FR-21 — Deposit webhook auto-credit (explicit) As a Trader / Investor, I should have my wallets.available_balance auto-credited by a direct deposit webhook handler upon receiving blockchain confirmations, so that my funds appear without manual intervention.

• Observable result: A DEPOSIT transaction is created and moves to COMPLETED; available_balance increases.
• Failure/recovery: An unconfirmed or failed deposit leaves the transaction PENDING or FAILED and the balance unchanged.
• Continuation: The user sees the credited balance on /wallet and /dashboard.

Business Logic and Automated Calculations

FR-22 — Real-time PnL computation (explicit) As a Trader / Investor, I should have edge functions compute real-time Profit and Loss using Unrealized PnL = (Current Price − Entry Price) × Quantity for BUY positions, so that my open exposure is always current.

• Observable result: Unrealized PnL renders on /dashboard and /market and updates with live prices.
• Failure/recovery: A price-feed gap holds the last computed value with a muted indicator.
• Continuation: Computation resumes when prices resume.

FR-23 — Protocol execution fee (explicit) As a Trader / Investor, I should have a 0.1% protocol execution fee automatically deducted on closed trades, so that net returns are accurate.

• Observable result: The closed trade's net return reflects the 0.1% deduction.
• Failure/recovery: A fee-computation failure leaves the trade unclosed rather than mispriced.
• Continuation: The trade closes correctly once computation succeeds.

FR-24 — Three-tier affiliate commission engine (explicit) As a Trader / Investor, I should have multi-level referral rewards distributed automatically whenever a user deposits or earns trading yield, so that my referral earnings accrue without manual claims.

• Observable result: Level 1 earns 7%, Level 2 earns 3%, and Level 3 earns 1% on deposits and bot daily yields.
• Failure/recovery: A missing parent in the tree simply ends propagation at that level.
• Continuation: Accrued bonuses appear on /affiliate and in the referrer's USDT wallet.

FR-25 — Referral commission database trigger (explicit) As a Trader / Investor, I should have a database trigger function that, upon any yield generation or completed deposit, automatically computes Level 1–3 parents, creates the corresponding transactions record with type = REFERRAL_BONUS, and credits the referrer's USDT wallet, so that commissions are never missed.

• Observable result: A REFERRAL_BONUS transaction and a referrals_and_bonuses record exist for each eligible level, and the referrer's USDT available_balance increases.
• Failure/recovery: A trigger failure rolls back the originating transaction rather than crediting partially.
• Continuation: The referrer sees the bonus on /affiliate and /wallet.

FR-26 — Daily bot execution schedule (explicit) As a Trader / Investor, I should have a daily cron job / scheduled edge function process my active investments, so that my bot allocations produce yield on schedule.

• Observable result: Each active investment is processed once per day.
• Failure/recovery: A failed run leaves balances unchanged and retries on the next schedule.
• Continuation: Processing resumes on the next scheduled run.

FR-27 — Daily yield credit and TRADING_PROFIT registration (explicit) As a Trader / Investor, I should have the daily job calculate my daily percentage yield based on the bot's configured ROI range, credit my wallet with the yield, and register a TRADING_PROFIT transaction, so that my returns are visible and auditable.

• Observable result: investments.current_profit increases, the wallet balance increases, and a TRADING_PROFIT transaction exists.
• Failure/recovery: A failed credit leaves the investment unchanged and retries on the next run.
• Continuation: The user sees the yield on /dashboard and /wallet.

FR-28 — Daily yield triggers referral commissions (explicit) As a Trader / Investor, I should have daily bot processing trigger referral commission calculations up the 3-tier tree, so that my referrers earn on my bot yields.

• Observable result: REFERRAL_BONUS transactions are created for eligible Level 1–3 referrers.
• Failure/recovery: A failed propagation retries with the next processing run.
• Continuation: Referrers see the bonuses on /affiliate.

Navigation and Trader Destinations

FR-29 — Navbar / Sidebar (explicit) As a Trader / Investor or Platform Administrator, I should have a Navbar / Sidebar containing the Logo, Live Market Ticker, Navigation Links (Dashboard, AI Trading, Market, Wallet, Affiliate, Settings), Profile Avatar dropdown, Dark Mode toggle, and Logout, so that I can move between destinations and control my session.

• Observable result: The rail renders on desktop and collapses to a bottom bar at 375px; the active item carries a 2px emerald edge marker.
• Failure/recovery: A failed ticker load leaves navigation fully usable.
• Continuation: The user navigates or logs out.

FR-30 — Main Overview Dashboard (explicit) As a Trader / Investor, I should see Total Portfolio Balance, a Net PnL card, Active AI Strategy cards, and a Recent Transactions table on /dashboard, so that I can assess my position at a glance.

• Observable result: All four elements render with current values.
• Failure/recovery: Partial data renders where available with a muted notice and retry.
• Continuation: The user drills into a strategy, the market, or the wallet.

FR-31 — Live Market & Trading (explicit) As a Trader / Investor, I should have an embedded live candle chart, Order Book, Real-Time Trade Stream, and a Market/Limit Buy & Sell Execution Panel on /market, so that I can read the market and execute orders.

• Input: Symbol, side (BUY/SELL), type (MARKET/LIMIT), price, quantity.
• Observable result: A trades record is created with status OPEN; the order appears in the open-orders list.
• Failure/recovery: Rejections (insufficient balance, invalid price or quantity) surface inline errors and preserve inputs.
• Continuation: The user monitors the position and its PnL.

FR-32 — AI Trading Bots (explicit) As a Trader / Investor, I should see a catalog of available trading bots with performance metrics and an "Invest Now" modal with a flexible allocation input on /ai-trading, so that I can allocate capital to a strategy.

• Input: Selected bot, allocation amount.
• Observable result: An investments record is created with status active; the wallet is debited; the bot's active_users_count increments.
• Failure/recovery: An allocation below min_investment or above available balance surfaces an inline error and preserves the amount.
• Continuation: The active strategy appears on /dashboard.

FR-33 — Wallet & Funds (explicit) As a Trader / Investor, I should see an asset balance breakdown, a Deposit modal with single-use crypto QR code generation, and a Withdrawal request form on /wallet, so that I can move funds in and out.

• Input: Network selection for deposit; asset, amount, and destination for withdrawal.
• Observable result: A single-use deposit address and QR code render; a withdrawal creates a WITHDRAWAL transaction with status PENDING.
• Failure/recovery: Address generation failure or withdrawal rejection surfaces an inline error with a retry.
• Continuation: The user tracks status in the transaction history.

FR-34 — Multi-Level Affiliate Dashboard (explicit) As a Trader / Investor, I should see a unique referral link sharing widget, a total team volume counter, and a Tier 1/2/3 breakdown table with active team count and bonus earnings on /affiliate, so that I can grow and monitor my referral network.

• Observable result: The sharing widget exposes the user's referral_code link; tiers populate with active counts and bonus earnings.
• Failure/recovery: A muted inline notice with retry on load failure; the sharing widget remains usable.
• Continuation: The user shares the link and monitors accrual.

FR-35 — User Profile & Security Settings (explicit) As a Trader / Investor, I should have a KYC document upload portal, Binance API key management, and Security 2FA setup on /settings, so that I can complete verification and secure my account.

• Input: KYC documents; Binance API key material; 2FA setup confirmation.
• Observable result: kyc_status moves to pending; API keys are stored AES-256 encrypted; 2FA is enabled.
• Failure/recovery: Upload failure, invalid key format, or 2FA setup failure surfaces an inline error.
• Continuation: The user retries or proceeds once verified.

Administrator Destinations

FR-36 — Administrative user supervision (required_inference) As a Platform Administrator, I should review user accounts and their KYC statuses on Users, so that verification decisions are made and recorded.

• Observable result: The user table renders with current kyc_status values; a status change persists and is reflected for the affected user.
• Access: Role-restricted to admin.
• Failure/recovery: A muted inline notice with retry on load failure.
• Continuation: The administrator continues reviewing or moves to another destination.

FR-37 — Administrative bot catalog oversight (required_inference) As a Platform Administrator, I should review and control the AI bot and trading-strategy catalog on Bot Management, so that only intended strategies are offered to traders.

• Observable result: The catalog renders; toggling is_active persists and removes a deactivated bot from the trader-facing catalog.
• Access: Role-restricted to admin.
• Failure/recovery: A muted inline notice with retry on load failure.
• Continuation: The administrator continues curating the catalog.

FR-38 — Administrative transaction review (required_inference) As a Platform Administrator, I should review and control financial transactions, referral bonuses, and related records on Transactions, so that financial activity remains correct and controlled.

• Observable result: The transaction table renders with current statuses; a status change persists and is reflected in the affected user's wallet and history.
• Access: Role-restricted to admin.
• Failure/recovery: A muted inline notice with retry on load failure.
• Continuation: The administrator continues reviewing or traces a bonus to its source transaction.

4. User Personas

Trader / Investor (user)

Product context. The Trader / Investor is a self-directed retail trader or quant-curious investor operating in a high-stakes, always-on market. They arrive either through a referral link or directly, and they expect the platform to behave like an instrument: live prices, current PnL, and bot yields that update without a page refresh.

Primary goal. Grow capital through a combination of manual market execution and automated bot allocation, while compounding referral earnings from the people they bring onto the platform.

Distinct accepted responsibilities.

• Establish identity: create an account (optionally with a referral code that binds referred_by), or sign in to resume; authenticate via Google or Apple ID if preferred.
• Complete profile and mandatory KYC verification, moving kyc_status from unverified to pending and awaiting verified.
• Read the portfolio: Total Portfolio Balance, Net PnL, Active AI Strategy cards, and Recent Transactions on /dashboard.
• Execute manually: read the live candle chart, order book, and trade stream on /market, then place MARKET or LIMIT BUY or SELL orders.
• Allocate to automation: compare bots by risk level, minimum investment, and expected daily ROI on /ai-trading, then invest a flexible amount.
• Move funds: generate a single-use deposit address and QR code, and submit withdrawal requests on /wallet.
• Grow the network: share the unique referral link and monitor Tier 1/2/3 active counts and bonus earnings on /affiliate.
• Secure the account: upload KYC documents, store Binance API keys AES-256 encrypted, and enable 2FA on /settings.

Relevant inputs and decisions. Which symbol to trade and at what price; whether to use a market or limit order; which bot matches their risk appetite and how much to allocate; which network (TRC20, BEP20, ERC20) to deposit on; whether to enable automated API execution on their own exchange account; whether to share their referral link.

Interactions with other accepted participants. The Trader / Investor is the counterparty of the Platform Administrator, who reviews their KYC status and financial records. They are also the referrer or referee in the three-tier tree: their deposits and bot yields generate bonuses for their Level 1–3 referrers, and their own referral link generates bonuses for them from their referees' activity.

Observable success. Balances, positions, bot investments, and referral bonuses are accurately reflected; live market data drives their decisions; KYC reaches verified; deposits auto-credit on blockchain confirmation; daily bot yields appear as TRADING_PROFIT transactions; tiered bonuses appear as REFERRAL_BONUS transactions.

Platform Administrator (admin)

Product context. The Platform Administrator operates the machine behind the market. They do not trade; they keep the platform's users, strategies, and money correct. Their work is supervisory and exception-driven — most of the time the system runs itself, and the administrator intervenes when a KYC submission needs a decision, a bot needs to be retired, or a transaction needs review.

Primary goal. Keep the platform's user base verified, its bot catalog intentional, and its financial records accurate, so that trading, yield, and commission activity remains correct and controlled.

Distinct accepted responsibilities.

• Supervise users: review accounts and their kyc_status values on Users, and act on pending verifications.
• Curate the catalog: review bot name, risk level, minimum investment, expected daily ROI, and active user count on Bot Management, and toggle is_active.
• Review money: inspect DEPOSIT, WITHDRAWAL, TRADING_PROFIT, REFERRAL_BONUS, and LEVEL_BONUS transactions on Transactions, act on PENDING or FAILED records, and trace a bonus to its source_transaction_id.

Relevant inputs and decisions. Whether a KYC submission is approved; whether a bot should remain active; whether a pending or failed transaction should be resolved.

Interactions with other accepted participants. The Platform Administrator acts on the Trader / Investor's account state: approving KYC unblocks the trader's participation, deactivating a bot removes it from the trader-facing catalog, and resolving a transaction changes what the trader sees in their wallet and history.

Observable success. KYC statuses are current and correct; the trader-facing bot catalog contains only intended strategies; transaction records reconcile with wallet balances and referral bonus lineage.

5. Core User Flows

Flow 1 — New trader enrolls and completes KYC

1. The Trader / Investor arrives at the anonymous Landing surface and reads the product proposition and the live readout strip of BTC/USDT, ETH/USDT, SOL/USDT, and BNB/USDT figures.
2. They select the emerald "Create Account" CTA and land on /login with the "Create Account" tab active.
3. They enter Full Name, Email, Password, and Confirm Password, and — if they arrived through a referral link — the optional Referral Code.
4. They submit "Create Account". A profiles record is created with a unique referral_code; because a Referral Code was supplied, referred_by is bound to the referring profile, placing them in that referrer's Level 1 tier.
5. Failure/recovery: If the passwords do not match, the email already exists, or the referral code is invalid, an inline error appears and their entered values are preserved. They correct the field and resubmit.
6. On success, a JWT session token is issued and they are routed to profile completion and KYC.
7. They open /settings and upload KYC documents through the KYC document upload portal. kyc_status moves from unverified to pending.
8. Failure/recovery: If the upload fails, an inline error appears and the status remains unverified; they retry the upload.
9. The Platform Administrator reviews the submission on Users and approves it. kyc_status becomes verified.
10. Continuation: The Trader / Investor now has a verified profile and proceeds to fund their wallet (Flow 3) or trade (Flow 4).

Flow 2 — Returning trader signs in

1. The Trader / Investor navigates to /login and the "Sign In" tab is active.
2. They enter Email and Password and submit "Sign In to NexTrade AI".
3. Failure/recovery: If the credentials are invalid, an inline error appears and their entered values are preserved. If they cannot recall the password, they use the "Forgot Password?" trigger to initiate recovery.
4. On success, a JWT session token is issued and they reach /dashboard.
5. Continuation: They review Total Portfolio Balance, Net PnL, Active AI Strategy cards, and Recent Transactions, then choose their next destination.

Flow 3 — Trader funds their wallet and withdraws

1. From /dashboard, the Trader / Investor opens /wallet and reviews the asset balance breakdown of available and locked balances per asset.
2. They open the Deposit modal and select a network — TRC20, BEP20, or ERC20.
3. The crypto payment gateway generates a single-use deposit address, which renders with its QR code.
4. Failure/recovery: If address generation fails, an inline error appears with a retry; they regenerate a single-use address.
5. They send funds to the address. On receiving blockchain confirmations, the direct deposit webhook handler auto-credits wallets.available_balance and the DEPOSIT transaction moves to COMPLETED.
6. Participant effect: Because a deposit completed, the referral commission trigger computes the Level 1–3 parents of the depositor, creates REFERRAL_BONUS transactions, and credits each referrer's USDT wallet — 7% to Level 1, 3% to Level 2, and 1% to Level 3. Each referrer sees the bonus on /affiliate and /wallet.
7. Later, the Trader / Investor submits a Withdrawal request form with asset, amount, and destination. A WITHDRAWAL transaction is created with status PENDING.
8. Failure/recovery: If the withdrawal is rejected, an inline error appears and they correct the request.
9. Continuation: They track the withdrawal's status in the transaction history on /wallet.

Flow 4 — Trader executes a manual trade

1. From the rail, the Trader / Investor opens /market and selects a symbol from BTC/USDT, ETH/USDT, SOL/USDT, or BNB/USDT.
2. They read the embedded live candle chart (rendered from GET /api/v3/klines), the Order Book depth, and the Real-Time Trade Stream. Price cells flash green on uptick and red on downtick.
3. They open the Market/Limit Buy & Sell Execution Panel and choose side (BUY or SELL), type (MARKET or LIMIT), and quantity — plus a price if the type is LIMIT.
4. They submit the order. A trades record is created with status OPEN, and the order appears in the open-orders list.
5. Failure/recovery: If the order is rejected for insufficient balance, an invalid price, or an invalid quantity, an inline error appears and their inputs are preserved. They correct the order and resubmit.
6. The edge functions compute real-time Unrealized PnL as (Current Price − Entry Price) × Quantity for BUY positions, and the figure updates on /market and /dashboard.
7. When the position closes, the 0.1% protocol execution fee is automatically deducted and the net return is recorded.
8. Continuation: The Trader / Investor reviews the outcome in Recent Transactions on /dashboard.

Flow 5 — Trader allocates capital to an AI bot

1. From the rail, the Trader / Investor opens /ai-trading and reviews the catalog of available trading bots with their performance metrics — name, risk level, minimum investment, expected daily ROI, and active users count.
2. They compare bots and select one whose risk level and expected daily ROI match their appetite.
3. They open the "Invest Now" modal and enter a flexible allocation amount.
4. Failure/recovery: If the amount is below the bot's min_investment or above their available balance, an inline error appears and the entered amount is preserved. They correct it and resubmit.
5. On submission, an investments record is created with status active, the wallet is debited, and the bot's active_users_count increments.
6. Continuation: The active strategy appears as an Active AI Strategy card on /dashboard.

Flow 6 — Daily bot yield accrues and propagates commissions

1. The daily cron job / scheduled edge function runs and processes all active investments.
2. For each active investment, it calculates the daily percentage yield based on the bot's configured ROI range.
3. It credits the Trader / Investor's wallet with the yield, increases investments.current_profit, and registers a TRADING_PROFIT transaction.
4. Failure/recovery: If a credit fails, the investment is left unchanged and the run retries on the next schedule.
5. The yield generation triggers the referral commission calculation up the 3-tier tree: the database trigger computes the Level 1–3 parents, creates REFERRAL_BONUS transactions, and credits each referrer's USDT wallet — 7% to Level 1, 3% to Level 2, and 1% to Level 3.
6. Participant effect: Each referrer sees the accrued bonus on /affiliate in their Tier 1/2/3 breakdown table and in their USDT wallet on /wallet.
7. Continuation: The Trader / Investor sees the yield reflected in Total Portfolio Balance and Recent Transactions on /dashboard.

Flow 7 — Trader grows and monitors the affiliate network

1. From the rail, the Trader / Investor opens /affiliate and sees the unique referral link sharing widget, the total team volume counter, and the Tier 1/2/3 breakdown table with active team count and bonus earnings.
2. They copy their unique referral link from the sharing widget and share it.
3. A new person enrolls through that link (Flow 1, step 3–4), binding referred_by to this Trader / Investor and placing them in Level 1.
4. As that referee and their downstream referees deposit or earn bot yields, the commission engine credits this Trader / Investor at 7% (Level 1), 3% (Level 2), and 1% (Level 3).
5. Failure/recovery: If the affiliate data fails to load, a muted inline notice appears with a retry; the sharing widget remains usable so they can keep recruiting.
6. Continuation: They monitor the three-concentric-ring diagram, where each tier's arc length is its share of team volume, and the tier breakdown table as earnings accrue.

Flow 8 — Trader secures the account and enables automation

1. From the rail, the Trader / Investor opens /settings.
2. They review their profile fields — full name, email, avatar — and update them as needed.
3. They enter their private Binance API keys in the Binance API key management panel. The keys are stored AES-256 encrypted.
4. Failure/recovery: If the key format is invalid, an inline error appears and nothing is stored. They correct the key.
5. They choose whether to enable automated API execution on their own exchange account. Automated execution occurs only if they enable it.
6. They open the Security 2FA setup panel and enable two-factor authentication.
7. Failure/recovery: If 2FA setup fails, an inline error appears and they retry.
8. Continuation: Their account is secured and, if enabled, automation runs against their own exchange account.

Flow 9 — Administrator supervises users, bots, and transactions

1. The Platform Administrator signs in through /login and reaches their role-restricted destinations.
2. They open Users and review the user accounts and their KYC statuses. A submission is pending.
3. They inspect the submission and approve it. kyc_status becomes verified, and the affected Trader / Investor can now complete their profile and participate.
4. Failure/recovery: If the user list fails to load, a muted inline notice appears with a retry.
5. They open Bot Management and review the AI bot and trading-strategy catalog — name, risk level, minimum investment, expected daily ROI, and active users count.
6. They toggle is_active on a bot that should no longer be offered. The change persists and the bot is removed from the trader-facing catalog on /ai-trading.
7. They open Transactions and review financial transactions across DEPOSIT, WITHDRAWAL, TRADING_PROFIT, REFERRAL_BONUS, and LEVEL_BONUS types.
8. They act on a PENDING or FAILED transaction. The status change persists and is reflected in the affected user's wallet and history.
9. They trace a REFERRAL_BONUS record to its source_transaction_id to confirm the bonus lineage.
10. Continuation: The administrator continues monitoring, or returns to Users or Bot Management as new exceptions arise.

6. Visuals Colors and Theme

Muse: MARQ by Garmin — luxury instrument aesthetic. The interface is a precision instrument, not a dashboard: dark titanium, one amber signal, gauges that read like a watch bezel. Trust is earned through instrumentation, not rounded friendliness.

Headline direction: Precision instrument, not a dashboard.

Colour tokens (dark mode)

Usage rules. The ground is never pure black — it stays a machined charcoal. Emerald #00C076 is the functional signal and is never used as decoration. Amber #F0A93B is the single hot highlight, reserved for live/streaming states, the "AI is running" pulse, and one hero-level number. Red #FF3B30 is strictly a data state and is never a brand or decorative colour. No gradients as backgrounds; a gradient appears only as a thin luminous edge on bezels.

Typography

• Headings and display numerals: Saira Condensed, 600–700 weight, tight 0.96 leading; uppercase for micro-labels at 0.14em tracking.
• Body: Barlow, 400/500 — humanist enough to stay legible in dense tables.
• Scale: 1.333 modular on a 4pt baseline — 11 / 13 / 16 / 21 / 28 / 40 / 56 / 72 / 96 / 128.
• Numerals: Always tabular-nums with slashed zeroes. PnL figures use Saira Condensed 600 so a column of numbers aligns like a ruled dial.
• Extreme contrast: Portfolio balance is set at clamp(72px, 12vw, 128px) in Saira Condensed 700, with its label at 11px uppercase Barlow 500 in #6B7681 above it and a delta chip beside it.

Shape language

Instrument geometry. Panels are 10px-radius rounded rectangles with a 1px #232A31 bezel and a 1px inset top highlight reading as a machined edge. No pills, no blobs. Circular gauges are the recurring motif — stroke-width 6, emerald arc on a #232A31 track, with a small amber tick at the current value. Buttons are 8px-radius rectangles with hard 1px borders, never filled slabs; the primary CTA is the only filled emerald shape on any screen. Horizontal ruled data rows (1px #1B2228) replace card grids wherever data is tabular.

Spacing rhythm

Strict 12-column grid, 24px gutters, 32px page padding at 1280px and 16px at 375px. A fixed 240px left instrument rail on desktop, collapsing to a bottom 5-item bar at 375px. Every page opens with a full-width readout strip — a single ruled row of 4–6 labelled values separated by 1px vertical rules, spanning the viewport edge to edge with no card behind it.

Imagery style

The interface is the imagery. Where a visual is needed it is diagrammatic and engineered: topographic contour lines drawn in #1B2228 behind the market chart bay, a macro titanium-brushed texture (SVG turbulence at 4% opacity) on the auth panel, thin radial tick marks around gauge rings, and schematic line-art for empty states (a bezel, a candlestick grid, a network node tree for the affiliate tree). No stock photography of people, no 3D coins, no neon glows, no illustration for its own sake. The one permitted photographic moment is a single full-bleed macro crop of a brushed-metal surface behind the login card, darkened to 8% luminance.

7. Signature Design Concept

The cut instrument face. The public entry is a 60/40 split, not a centred hero.

Left 60%. On #0B0E11, a stacked three-line headline in Saira Condensed 700 set flush-left at clamp(44px, 9vw, 104px):

• TRADE in #E8EAED
• AUTOMATE in #00C076
• COMPOUND in #E8EAED

Below it sits a single ruled readout strip of four live figures — BTC/USDT, ETH/USDT, SOL/USDT, BNB/USDT — that streams in from the left edge and runs under the headline, its cells flashing green on uptick and red on downtick. Below that, one emerald filled CTA ("Create Account") and one hairline-outlined secondary ("Sign In"). The headline block bleeds off the left viewport edge at 1280px so the composition reads as a cut instrument face rather than a marketing hero.

Right 40%. A full-height #141A20 instrument panel with a 1px bezel containing the tabbed Sign In / Create Account form, topped by a circular gauge ring that sweeps to 100% on load with an amber tick — the only glowing element on the page. Behind the panel, a single full-bleed macro crop of brushed metal darkened to 8% luminance supplies the one permitted photographic moment.

Responsive behaviour. At 375px the panel stacks below the headline, the readout strip becomes a horizontally scrollable ticker, and the headline drops to 44px with the CTA full-width. All readable text and controls stay whole inside the viewport and their container at 375px, 768px, and 1280px; the bleed gesture is carried by the headline block and the readout strip, never by cropping a label or a control.

Scope. This concept recomposes only accepted content, states, and controls — the product proposition, the live Binance ticker figures, the dual-mode auth form, and the two entry CTAs. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: dimensional_css

Landing Hero Motion Brief

Focal subject. The live readout strip of four market figures (BTC/USDT, ETH/USDT, SOL/USDT, BNB/USDT) streaming in from the left edge beneath the stacked headline, paired with the circular gauge ring on the right instrument panel.

Input → transformation → outcome thesis. Live Binance ticker frames arrive over the WebSocket → each readout cell's value updates and its background flashes rgba(0,192,118,0.14) on uptick or rgba(255,59,48,0.14) on downtick for 220ms with no easing curve beyond cubic-bezier(0.2,0,0,1) → the visitor reads a live, moving market before they have an account, and the gauge ring on the right sweeps to 100% over 700ms with an amber tick settling at its value.

Motion vocabulary. Precise and mechanical, at MARQ's cinematic ceiling but used with discipline. Scroll reveals are 12px translate-up with opacity, 320ms, staggered 60ms across readout-strip cells. Gauge arcs sweep to their value on mount over 700ms. The one continuous loop is the "AI running" indicator: a 2px amber tick that travels the circumference of an active bot's ring every 4s, plus a slow 0.4px/step vertical drift on the order-book depth bars. No parallax on data, no bounce, no particles.

Composed first frame. At rest, the headline sits flush-left with "AUTOMATE" in emerald, the readout strip holds four labelled figures separated by 1px vertical rules, the emerald "Create Account" CTA is the only filled shape, and the right panel's gauge ring rests at 0% on its #232A31 track with the amber tick at the origin.

Reduced-motion state. With prefers-reduced-motion, the readout strip stops streaming and shows whole items wrapped into rows or in a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling; the gauge ring renders at its final value without sweeping; the amber tick holds still; scroll reveals render at final position with no translate.

9. Non-Functional Requirements

NFR-1 — Row-Level Security on all tables (explicit) All seven tables must have full Row-Level Security enabled. Rationale: the source states RLS must be enabled on all database tables; user financial and identity data must not leak across accounts.

NFR-2 — JWT session tokens on secure routes (explicit) Every secure route must require a valid JWT session token. Rationale: the source states secure routes require JWT session tokens.

NFR-3 — AES-256 encryption of private Binance API keys (explicit) Private Binance API keys must be stored AES-256 encrypted. Rationale: the source states secure private API key storage (AES-256 encrypted) in user settings.

NFR-4 — Single-use deposit addresses (explicit) Deposit addresses must be single-use and generated per deposit via the crypto payment gateway. Rationale: the source states deposit addresses are single-use and generated per deposit.

NFR-5 — Fixed protocol execution fee (explicit) A 0.1% protocol execution fee must be deducted on closed trades. Rationale: the source states the fee is automatically deducted on closed trades.

NFR-6 — Fixed referral commission rates (explicit) Referral commission rates are fixed at 7% (Level 1), 3% (Level 2), and 1% (Level 3) on deposits and bot daily yields. Rationale: the source states these rates explicitly.

NFR-7 — Conditional automated API execution (explicit) Automated API execution on user exchange accounts must occur only if enabled by the user. Rationale: the source states automated API execution occurs on user exchange accounts if enabled.

NFR-8 — Role set limited to user and admin (explicit) RBAC roles are limited to user and admin. Rationale: the source states the roles are user and admin.

NFR-9 — Mandatory KYC for profile completion (explicit) KYC verification is mandatory for profile completion. Rationale: the source states profile completion and mandatory KYC verification status.

NFR-10 — Live market data fidelity (explicit) Market data must be sourced from the Binance Public REST API and WebSocket at wss://stream.binance.com:9443/ws, with the ticker stream (<symbol>@ticker) covering BTC/USDT, ETH/USDT, SOL/USDT, and BNB/USDT, and historical candles fetched via GET /api/v3/klines. Rationale: the source specifies these endpoints and symbols exactly.

NFR-11 — Readable text and controls at every viewport (explicit) Headlines, wordmarks, labels, numbers, cards' text, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Moving and scrollable content may cross the viewport or container edge by design and must show whole items under prefers-reduced-motion. Rationale: the creative direction states this rule and gives it precedence over cropping gestures for readable text and controls.

NFR-12 — Dark-mode-only presentation (explicit) The interface must present the premium dark-mode aesthetic with background #0B0E11, primary emerald #00C076, warning red #FF3B30, and subtle gray muted elements, with high-density data visualizations. Rationale: the source states this aesthetic as a requirement.

10. Tech Stack

Frontend (explicit where stated, otherwise default)

• Web application with a dual-mode auth component (LoginSignUp), a fixed left instrument rail, and the seven trader-facing destinations plus three administrator destinations.
• Lightweight TradingView charts for candlestick rendering (explicit).
• Google and Apple ID SSO (explicit).

Backend and data (explicit)

• Supabase / PostgreSQL as the relational store, with the seven tables defined in FR-9 through FR-15 and full Row-Level Security enabled (explicit).
• Supabase Auth for auth.users identity, JWT session tokens, and RBAC roles user and admin (explicit).
• Edge functions for real-time PnL computation and the daily bot execution schedule (explicit).
• Database trigger functions for the three-tier referral commission engine (explicit).
• Scheduled cron job / edge function for daily processing of active investments (explicit).

External integrations (explicit)

• Binance Public REST API and WebSocket at wss://stream.binance.com:9443/ws for ticker streams and GET /api/v3/klines for historical candles.
• Crypto payment gateway — Web3 Wallet Connect, or NOWPayments, or Binance Pay API — for deposit address generation on TRC20, BEP20, and ERC20, with a direct deposit webhook handler.

Presentation defaults (Default — not specified by user)

• React for the web frontend.
• Docker / docker-compose for local and deployment packaging.

11. Assumptions and Constraints

Constraints (binding).

1. RBAC roles are limited to user and admin.
2. Secure routes require JWT session tokens.
3. KYC verification is mandatory for profile completion.
4. Row-Level Security must be enabled on all database tables.
5. Private Binance API keys must be stored AES-256 encrypted.
6. Deposit addresses are single-use and generated per deposit via the crypto payment gateway.
7. A 0.1% protocol execution fee is deducted on closed trades.
8. Referral commission rates are fixed at 7% (Level 1), 3% (Level 2), and 1% (Level 3) on deposits and bot daily yields.
9. Automated API execution on user exchange accounts occurs only if enabled by the user.
10. Red #FF3B30 is a data state only and is never used as a brand or decorative colour.
11. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Assumptions (narrow, labeled).

1. [Assumption] The admin role is provisioned by deployment or platform bootstrap rather than through the public /login enrollment form, since the source defines no administrator self-enrollment path.
2. [Assumption] A user's USDT wallet is the credit target for referral bonuses, per the source's statement that the trigger credits the referrer's USDT wallet.
3. [Assumption] The daily cron job runs once per calendar day per active investment.
4. [Assumption] KYC document review is performed by the Platform Administrator on Users; the source states KYC status is a toggle with unverified, pending, and verified states but does not name the reviewing surface.
5. [Assumption] The three administrator destinations (Users, Bot Management, Transactions) are reachable from the same authenticated shell as the trader destinations, gated by the admin role.
6. [Assumption] Where the source offers alternatives — Web3 Wallet Connect, NOWPayments, or Binance Pay API — one is selected at implementation time; the requirement is satisfied by any of them.
7. [Default — not specified by user] React is used for the web frontend, and Docker / docker-compose for packaging.

Explicit exclusions.

• No capabilities beyond those stated in the authoritative requirements are in scope.
• No adjacent account-management, social, or portfolio-advisory features.
• No parallax on data, no bounce, no particles, no 3D spinning coins, no neon glow blooms, no stock photography of people or trading floors.
• No rounded pill buttons, blob shapes, soft drop shadows, hover-lift card grids, or rounded-corner glassmorphism panels with blur.

12. Glossary

NexTrade AI — The web-based cryptocurrency trading, AI automated strategy, and affiliate investment platform defined by this document.

LoginSignUp — The dual-mode authentication component with switchable "Sign In" and "Create Account" tabs driven by active tab state.

RBAC — Role-Based Access Control. NexTrade AI's roles are limited to user and admin.

JWT session token — The signed token issued on successful authentication that secures every protected route.

KYC — Know Your Customer. The mandatory identity verification with states unverified, pending, and verified.

RLS — Row-Level Security. Enabled on all seven database tables so each row is accessible only to its rightful owner.

profiles — The user identity table: id, full_name, email, avatar_url, kyc_status, referral_code, referred_by, created_at.

wallets — The per-asset balance table: id, user_id, asset, available_balance, locked_balance, updated_at.

ai_bots / trading_strategies — The bot catalog table: id, name, risk_level, min_investment, expected_daily_roi, active_users_count, is_active.

investments — The user-to-bot allocation table: id, user_id, bot_id, invested_amount, current_profit, status, started_at.

trades — The order table: id, user_id, symbol, side, type, entry_price, exit_price, quantity, pnl, status, created_at.

transactions — The financial movement table: id, user_id, type, amount, asset, tx_hash, status, created_at.

referrals_and_bonuses — The tiered bonus table: id, referrer_id, referee_id, level, bonus_amount, source_transaction_id, created_at.

Unrealized PnL — (Current Price − Entry Price) × Quantity, computed for BUY positions.

Protocol execution fee — The 0.1% fee automatically deducted on closed trades.

Level 1 / Level 2 / Level 3 — The three affiliate tiers: direct referral (7%), indirect referral (3%), and sub-referral (1%) on deposits and bot daily yields.

REFERRAL_BONUS — The transactions.type value created by the commission trigger when a deposit completes or a yield is generated.

TRADING_PROFIT — The transactions.type value registered when the daily bot job credits a user's wallet with yield.

Readout strip — The full-bleed ruled row of 4–6 labelled live figures at the top of every page, separated by 1px vertical rules with no card behind it.

Instrument rail — The fixed 240px left navigation rail on desktop, collapsing to a bottom 5-item bar at 375px, with a 2px emerald edge marker on the active item.