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/protocol.ts`	Built-in TRIDENT holder policy, without user registration or allocation
`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 verified credit-read access
`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 current holder API initializes a deterministic TRIDENT access policy automatically. Verified holders issue a key at /api/keys/create; /api/protocol/run and /v1/chat/completions use the same gateway. Atomic reservations account for outstanding requests, settlements since the provider observation and any separate legacy allocations. No fabricated balance is credited to the built-in policy. Legacy deposit administration remains separate from the holder flow.

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 access policy is bound to a configured chain and contract address, not just 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. The inference credential, or an optional management key for the same account, observes credit capacity when permitted. 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.