Architecture

Deployment boundary

This is a Next.js application running on Node 24. It uses a shared PostgreSQL or Turso/libSQL database on Vercel and a local SQLite file during development. Client components render the interface and call server routes. Server credentials never enter the browser bundle. Wallet extensions sign user operations; no treasury private key is accepted.

The async database adapter uses write transactions and unique constraints for atomic receipt, reservation and settlement operations. Vercel requires DATABASE_URL (PostgreSQL/libSQL), or the existing TURSO_DATABASE_URL and TURSO_AUTH_TOKEN pair; the application rejects an ephemeral local database there. See the deployment guide.

Modules

Module	Responsibility
`lib/auth.ts`	Wallet challenges, signature checks, sessions and terms
`lib/openrouter.ts`	Model catalogue, price snapshots and native FX
`lib/service.ts`	Historic launch/pool adapters and legacy payment preparations; public creation routes retired
`lib/chains/robinhood.ts`	Exact receipt checks plus inactive factory/pool reference adapters
`lib/chains/solana.ts`	Existing Pump/PumpSwap programs and Solana verification
`lib/chains/pons.ts`	Pons records and legacy curve/router support
`lib/community/store.ts`	Community accounting, hashed keys and atomic budgets
`lib/community/chain.ts`	Token metadata and confirmed wallet holdings
`lib/community/provider.ts`	Provider capacity observation using a management key
`lib/community/gateway.ts`	Text inference, SSE forwarding and settlement
`lib/live-token.ts`	Configurable read-only token observatory and labelled indexed fallback
`lib/model-profile.ts`	Explainable catalogue-based pros and cons

HTTP surfaces

/api serves the application. Wallet-session mutations require the configured origin and applicable terms acceptance. /v1 serves bearer-key inference clients. Public model and observatory reads do not grant service credit or token authority.

The API separates preparation, signing/submission and confirmation. A client cannot credit itself by claiming a transaction succeeded. A community deposit and its provider allocation are distinct records. Administrative allocation and reconciliation are local commands, not public routes.

Persistence

Core tables store wallet challenges, sessions, launches, preparations, receipts, balances, ledger entries, requests and terms acceptance. Community tables add token rules, API-key hashes, shared usage, funding deposits and audit events. Market observations are public price records, separate from financial accounting.

The application never merges two communities simply because they share a ticker. Contract/mint address, chain and community identifier are the relevant keys. API secrets are not stored in plaintext. Personal details or founder profiles are not seeded into the app.

Provider trust

OpenRouter authenticates the operator's inference credential and bills its provider account. A separate management key observes credit capacity. The app trusts that response subject to short caching and conservative local reservations. There is no cryptographic proof that an external provider's ledger is complete or instantaneous.

Pons-indexed data is display-only and explicitly unverified against chain state. It cannot satisfy a holder check, receipt verification, deposit activation or pool preparation. A read-only fallback does not silently weaken financial checks.

Failure behavior

Bad origin, stale terms, invalid signatures, revoked keys, insufficient holdings, spent budgets and replayed receipts fail before the protected action. Provider uncertainty produces a held reservation. Remote catalogue failure can display a labelled stale read but does not permit stale transaction pricing.

Errors avoid returning credentials and sensitive upstream details. Operators must also configure hosting logs appropriately. Review Security and Verification for limitations.