# FairDraw Gateway - Technical Overview and Functional Audit

Date: 2026-05-26  
Scope: static investor site audit (content integrity, architecture, frontend behavior, deployment)

## 1) Executive Summary

The repository delivers a static investor-facing site for FairDraw Gateway.
The current messaging is aligned to infrastructure positioning:

- FairDraw is presented as verifiable prize campaign infrastructure.
- The site distinguishes Live, Beta, and Roadmap capabilities.
- Product claims avoid unsupported statements (for example fixed fee promises or explorer-as-live claims).

Current engineering profile:

- Zero-build static architecture.
- Single-page main artifact (`index.html`) with inline CSS and JavaScript.
- Additional static policy/docs pages.
- No runtime backend required for the website package itself.

## 2) Product Positioning Integrity (Current State)

### Canonical product statement

FairDraw Gateway is verifiable prize campaign infrastructure for brands, creators, and communities.

### Positioning boundaries

- Infrastructure for campaign operators, not a consumer lottery app.
- Not framed as a gambling operator.
- Verification layer focuses on snapshots, randomness, and portable proof artifacts.

### Implementation Truth Map

- Live
  - Merchant Dashboard surface (presentation + flow)
  - Embed/iframe campaign workflow
  - Chainlink VRF draw flow representation
  - FD-PROOF artifact package representation
- Beta
  - Campaign API facade (`/api/merchant/campaigns`)
  - Allowed origins and API key facade messaging
  - Payment mode surfaces
- Roadmap
  - ERC-1155 ticket standard
  - Public proof explorer domain
  - SDK/webhooks
  - Compliance modules
  - Governance/tokenized fairness options

## 3) Repository Structure (Observed)

Root static files include:

- `index.html` - main landing page (HTML/CSS/JS)
- `technical-docs.html` - docs hub page
- `TECHNICAL_OVERVIEW.md` - this file
- `ARCHITECTURE.md` - architecture summary
- `README.md` - deployment notes
- `privacy.html`, `terms.html`, `smart-contracts.html` - legal/technical pages
- `_headers`, `robots.txt`, `sitemap.xml` - hosting and SEO assets

## 4) Main Landing Information Architecture

`index.html` currently follows this narrative:

1. Hero (Gateway positioning + status)
2. Problem (trust gap in prize campaigns)
3. Solution (verifiable draw lifecycle)
4. Architecture (application/proof/randomness layers)
5. Product surfaces (merchant, draw/proof console, explorer roadmap)
6. Proof artifacts and verification section
7. Competitive positioning
8. Planned pricing model
9. Risk and regulatory positioning
10. Moat and defensibility
11. Roadmap (Gateway to Protocol)
12. Vision + CTA

This ordering matches the latest landing brief target flow.

## 5) Technical Implementation Details

### Frontend architecture

- Monolithic document architecture in `index.html`.
- CSS variables define design tokens and theme layers.
- Responsive behavior via media queries at key breakpoints.
- No external JavaScript framework.

### Interaction modules

- Hero canvas particle grid (`requestAnimationFrame`).
- Scroll-based reveal transitions (`IntersectionObserver`).
- Counter animation and chart reveal animations.
- Mobile navigation open/close handling.
- In-page draw simulation sandbox with step execution.

### Draw simulation module

The demo is explicitly simulation-mode and uses browser cryptography APIs:

- `crypto.subtle.digest('SHA-256', ...)` for deterministic values.
- Step progression: commit -> request -> fulfill -> winner derivation.
- Verification panel display.
- Local JSON export and copy link utility.

## 6) Content and Claim Hygiene Review

### Strengths

- Hero and metadata now reflect verifiable prize campaign infrastructure.
- Outdated time marker (`Q1 2026`) replaced by year-level status wording.
- Competitive table and business model wording are now roadmap-safe.
- Proof-focused section highlights artifact portability and verification path.

### Remaining operational caveat

- Main site remains a static representation and simulation layer.
  Product/backend endpoints referenced in copy are capability descriptions, not website runtime dependencies.

## 7) Security, SEO, and Deployment

### Hosting and deployment

- Designed for static deployment (Cloudflare Pages/Netlify/GitHub Pages compatible).
- No build command required.

### SEO essentials

- Canonical and social metadata present in `index.html`.
- `robots.txt` and `sitemap.xml` are available in repository root.

### Security headers

- `_headers` file provides static-hosting security/caching directives.
- CSP currently allows inline scripts/styles to support the monolithic page model.

## 8) Risks and Recommendations

### Current risks

- Monolithic `index.html` increases maintenance complexity and drift risk.
- Marketing/roadmap copy can drift again without a central status source.

### Recommended next actions

1. Add a single source-of-truth status table in docs (Live/Beta/Roadmap) and reference it during copy updates.
2. Split JS into a dedicated static file when feasible to simplify CSP hardening.
3. Add a lightweight regression checklist for section IDs/anchors and CTA routes.
4. Keep `ARCHITECTURE.md` and `technical-docs.html` synchronized after each landing copy revision.

## 9) Final Assessment

The investor site is technically sound as a static artifact and now aligned with the intended product truth model:

- ambitious direction,
- controlled claims,
- clear separation of current capabilities vs roadmap.

This is appropriate for a gateway-stage infrastructure narrative and reduces investor-facing overstatement risk.