System architecture
Application boundaries, persistence, and the difference between current foundations and future execution.
In this chapter
Current components#
| Component | Responsibility |
|---|---|
| Next.js / React / TypeScript | Public waitlist, workspace, documentation, and HTTP route handlers. |
| Wallet verification | EIP-4361 messages, signature checks, one-time challenges, and sessions. |
| PostgreSQL | Accounts, session/challenge records, hashed API credentials, and supplier applications. |
| Redis-backed waitlist | Registration records, referral relationships, ranking, and protected export support. |
| nginx and Docker | HTTPS termination, routing, request limits, and isolated application runtime. |
| Provider adapter | A bounded operator-side integration boundary; not yet customer execution. |
| Robinhood Chain | Authentication context today; proposed funding/payout settlement later. |
Current identity and application flow#
Browser wallet
→ canonical HTTPS application
→ sign-in challenge and signature verification
→ PostgreSQL session/account
→ owner-scoped API keys and supplier application
Public registration form
→ waitlist API
→ durable Redis record and referral graphPersistent records#
| Record | Purpose | Not equivalent to… |
|---|---|---|
| Account | Normalized wallet identity and creation metadata. | A funded financial balance. |
| Challenge | Expected sign-in message, nonce, token hash, and expiry. | A reusable password or payment signature. |
| Session | Hashed token, account owner, expiry, and creation time. | A wallet private key. |
| API credential | Hashed secret, prefix, label, owner, dates, and revocation. | Proof of available inference capacity. |
| Supplier application | Declared endpoint, model, rights, retention, contact, and review status. | An approved, healthy provider or accrued earnings. |
| Waitlist entry | Contact/survey data and referral linkage. | An authenticated marketplace account or reward entitlement. |
Trust boundaries#
The server derives account ownership from a verified session, not from request parameters. API-key authentication checks persistent revocation state. Production storage errors must fail closed. Financial state must never fall back to process memory.
The application role has restricted database privileges and the database is not exposed as a public service. This reduces exposure but is not a complete security argument: compromised application credentials still matter, and financial signing authority should remain separate.
The legacy prototype is not a fallback#
Earlier code generated market activity, prices, provider availability, balances, and sample responses. That engine is no longer the authority for marketplace API routes. It must not be reconnected to make an unavailable production service look busy or functional.
The replacement favors accurate empty states and explicit unavailability. Future services should add genuine records and measurements, not reinterpret old demo data as economic activity.