COMPETITION PORTAL

AggieQuant // Portal

This is the structure around the competition product: public pages, trader workspaces, leaderboards, and an admin console for running markets and resolving contracts cleanly.

Open Guest Lobby Open Trader Workspace Open Admin Console

Why A Portal

The exchange should live inside a competition system

The website explains the club. The portal should run the product: who is signed in, who can trade, which competition is active, who can resolve markets, and what appears on the leaderboard.

Open competition hub

Guest

Public Lobby

Leaderboard, competition schedule, active markets, rules, and a clean way for visitors to observe without trading permissions.

Trader

Member Workspace

Competition enrollment, team context, portfolio status, recent fills, and a direct route into the member competition surfaces.

Admin

Control Console

Competition creation, market locking, resolution, user roles, audit logs, and the operational surface for running fair events.

01// PORTAL_MAP

01

Public Lobby

Competition overview, rules, public standings, and active market summaries.

  • Competition cards
  • Public leaderboard
  • Announcements
02

Trader Workspace

Authenticated member home for joining competitions and checking trading status.

  • Join competition
  • Portfolio + fills
  • Team standings
03

Trading Floor

The market interface layer itself. For now the public exchange demo is offline, so the surrounding portal pages are the visible system.

  • Order book
  • Market + limit orders
  • Open orders + fills
04

Admin Console

Operational controls for running competitions and resolving contracts transparently.

  • Role management
  • Market resolution
  • Audit logging

02// AUTH_MODEL

Guest Access

Guests should be able to observe without creating risk.

  • No trade permissions
  • Public standings + rules only
  • Optional guest handle for sandbox demos

Trader Login

Members should have one durable identity tied to competitions and fills.

  • Email magic link or TAMU/Google SSO
  • Role stored server-side as `member` or `trader`
  • Competition enrollment records in Postgres

Admin Login

Admin should not be a separate fake site. It should be the same identity system with stronger checks.

  • Role-based access control
  • MFA required
  • Audit log for all admin actions

Recommended v1 auth

Email-first with role checks

Use one auth system for everyone. Start with email magic links for the least friction, then add TAMU/Google SSO once the user base is stable.

Admin security

MFA plus audit trails

Admin pages should require a verified account with an `admin` role, and every market pause, role change, or resolution should write to an audit table.

What not to do

No client-only admin mode

Do not ship ΓÇ£admin loginΓÇ¥ as a hidden front-end password. Permissions need to be enforced in API routes and stored server-side.

03// BACKEND_SHAPE

Users

Identity record plus role metadata.

  • `id`
  • `email`
  • `display_name`
  • `role`

Competitions

Container for rounds, dates, rules, and enrollment.

  • `name`
  • `status`
  • `start_at` / `end_at`
  • `virtual_cash`

Markets

Each contract with resolution details and lifecycle state.

  • `competition_id`
  • `question`
  • `resolution_rule`
  • `market_status`

Orders + Fills

Trading history tied to a user and a competition.

  • `orders`
  • `trades`
  • `positions`
  • `leaderboard_snapshots`

Admin Actions

Operational trace for fairness and debugging.

  • `audit_logs`
  • `resolution_events`
  • `role_changes`
  • `market_halts`

Entry Flow

How users move through the system.

  • Guest -> observe
  • Trader -> sign in -> join
  • Admin -> role check -> MFA -> console