Evidence before
execution.

A memory for launch markets.

The product combines a deterministic launch detector, evidence capture, persistent deployer history, a prepaid API, and a bounded agent runtime. Clients can use these records as context for their own analysis and decisions. Each response is grounded in the service’s recorded observations and stated coverage.

NOUS is the project’s Solana token. The published policy allocates 100% of verified API customer payments to manual token buybacks and burns, including execution fees. A public tracker separates that allocation from verified execution.

This edition documents the current system. Development directions are identified separately, and live accounting remains available on the token tracker.

A launch is only part of the story.

A new token gives market participants a mint, a transaction, and a small amount of context. A deployer may have launched other tokens. Metadata and websites can change. An agent that only sees the current token page has limited historical evidence to work with.

Nous organizes observations around launches, mints, and deployer wallets. Capturing evidence when a launch is observed makes it possible to distinguish what the system recorded at that time from information retrieved later.

The intended users are software agents, researchers, and applications that need programmatic access to this history. Nous supplies structured evidence and provenance; clients decide how to use it. An observed wallet relationship does not establish a person’s identity or intent.

From chain activity to queryable history.

1. 01ObserveSupported Solana launch transactions
2. 02PreserveRaw evidence, captures, hashes and times
3. 03IndexPersistent mint and deployer records
4. 04ServeAPI queries with provenance and coverage

Detection and recovery

The detector consumes Yellowstone gRPC transactions. Current parsers recognize Pump.fun create and create_v2, Meteora Dynamic Bonding Curve launches, and Raydium LaunchLab launches. The default detection commitment is confirmed. Deterministic watchdogs reconnect stalled subscriptions and restore filters.

Evidence and delivery

Raw launch evidence is saved before downstream processing. Capture jobs retrieve eligible metadata, linked images, and websites. A persistent outbox retries delivery to the public serving layer; stable event identifiers allow the index to handle repeated delivery without duplicating observations.

Serving and storage

The detector and agent runtime run on an operator-managed host. The public site, API, history index, and credit ledger run on a Cloudflare Worker with Durable Objects. Paid queries read persistent history independently of the terminal’s recent-event display. Model calls are outside the parsing, billing, and customer-query paths.

Records with a known scope.

Capture records include retrieval times, source and final URLs, content types, byte counts, hashes, and success or failure. Captured bytes currently remain in local storage. The API exposes bounded provenance manifests; it does not provide a public archive of those files.

The corpus covers observed launches from supported programs. Provider interruptions, host downtime, parser coverage, and failed captures can leave gaps. Retained logs and raw evidence can support historical imports, but missing evidence cannot be reconstructed merely by reconnecting.

History queries describe their observation range, cutoff, indexing coverage, and source health. The default query window is six hours; clients can request all indexed history and follow pagination. The terminal displays up to six hours and 5,000 events, while the persistent index has a separate lifecycle.

Current X and Telegram collectors are unavailable. Wallet clustering, fraud probabilities, and historical performance labels have not been validated as product outputs. Existing deterministic risk flags summarize observed signals. Free token analysis samples large token accounts, so it cannot establish a complete holder distribution.

Bounded intelligence around the infrastructure.

The runtime defines 20 roles spanning coordination, ingestion, capture, records, evidence review, and prepaid-account operations. Registered roles provide a structure for assigning work; they do not imply that every role runs continuously or has demonstrated sustained reliability.

GPT-backed workflows can review state, enqueue permitted tasks, write artifacts, record evidence, and raise operational incidents. Model-proposed actions pass through deterministic tool policies. Persisted tasks, audit records, budget reservations, and a provider circuit breaker support bounded operation and recovery.

Autonomy depends on enabled capabilities, model availability, configured budgets, and operator supervision. The current tool set does not provide autonomous treasury transfers, token swaps, burns, or unrestricted shell access. Buyback execution remains a separate manual process.

Pay for information in SOL or USDC.

Clients fund prepaid query credits using native SOL or USDC on Solana mainnet. Both assets fund the same query-credit balance. Holding NOUS is not required for API access.

The SOL price is a fixed service tariff. It does not use a SOL/USD exchange rate. Arithmetic uses integer lamports and USDC micro-units, with separate fractional-credit remainders carried forward for each asset.

Funding combines a finalized on-chain transfer with a challenge signed by the sending wallet. A successful first claim returns a private API key; subsequent funding can top up the same account. Claiming a transaction again cannot issue duplicate credits, and concurrent queries cannot spend the same final credit.

A first-page history query costs one credit and accepts a deployer wallet or mint. Results support pagination of up to 200 launches per page. Continuation pages within the same 15-minute query session are free.

The protocol is nous-prepaid-v1. Its discovery document is x402-style; standard x402 facilitator settlement and per-request on-chain payments are not implemented. The API guide and pricing JSON define the current integration flow.

A published identity.

The token identity below was checked against finalized mainnet evidence: an initialized mint, its token program, on-chain name and symbol bound to the mint, and its canonical Pump.fun bonding-curve account.

Identity verification establishes which token the policy refers to. Supply, holders, and market activity can change; the live tracker publishes identity evidence and verification times.

The implemented connection between the API business and NOUS is the customer-payment allocation policy below. No token-holding gate, staking system, or token-governance mechanism is part of the current API product.

One allocation. Separate proof of execution.

The policy includes historical verified customer payments and the full value received, including fractional-credit remainders. Allocation is recognized when a qualifying deposit is credited, rather than when the customer later consumes query credits. Existing customer credits remain valid.

Internal tests, including the identified Scout payment, are excluded. Pump creator fees, donations, and unrelated treasury transfers are outside this customer-payment policy unless explicitly added through a published change.

Purchases and burns use the existing payment treasury: 2XGJ8X6WagK6LuUAjPkRh7bPwoP6dd9jhEZLRM7ZhwPt. An operator executes transactions independently and submits their signatures to the tracker. The reporting service verifies evidence read-only; it does not control the wallet or enforce execution.

An allocated payment is not a completed buyback. Acquired tokens are not burned tokens. Neither allocation nor a past transaction establishes a future execution date, trading price, or return.

Keep each movement distinct.

A sanitized receipt is created atomically with every newly credited deposit. Transaction signatures provide the deduplication key, so confirmation retries cannot inflate payment totals. Historical reconciliation combines surviving claim markers, journals, and account deposit records. Missing amounts require finalized chain evidence; unresolved records remain visible and outside verified totals.

Public reporting keeps SOL and USDC separate. For each asset, awaiting execution is derived from recorded movements:

Eligible customer payments
+ verified conversion inflows
− verified conversion outflows
− verified purchase spending
− verified network fees
= allocation awaiting execution

Open batches reserve part of that allocation. Purchase spending includes embedded swap fees; network fees are shown separately. A USDC-to-SOL conversion changes the asset available for execution without adding customer revenue or establishing a token buyback.

Purchases and burns

Proof verification checks successful finalized transactions, the configured mint, treasury ownership, actual asset movements, and recognized swap instructions. A burn requires an actual token-program burn instruction and sufficient verified acquisitions in earlier slots. Wallet withdrawals, transfers to another address, and tokens held in the treasury do not count as burns.

Transaction attribution is unique across batches and operation types. Reservations prevent reuse of allocation. Batches distinguish pending purchase, purchased awaiting burn, partially burned, completed, failed, and unverified evidence; inconsistent amounts remain marked as needing attention. Unsupported transaction formats are not treated as verified activity.

Ongoing checks and public records

A minute-level scheduler performs bounded pending-evidence checks and history reconciliation. RPC outages preserve previously verified evidence; timestamps and incomplete states remain visible. Operator corrections require an auditable record and do not change customer credits.

The public interfaces are GET /api/v1/tokenomics, GET /api/v1/buybacks, and GET /api/v1/receipts. They expose policy, totals, coverage, sanitized receipts, and batch evidence. Private API keys, account associations, wallet proofs, and raw ledger records are excluded.

Explicit dependencies and limits.

Nous currently depends on its operator-managed ingestion host, RPC and stream providers, Cloudflare serving infrastructure, and separately configured model services. The ingestion host must remain available to observe new launches. Durable storage and retries improve recovery, but do not establish uninterrupted coverage or a measured availability guarantee.

Capture requests have time, size, concurrency, and destination limits. Public URLs and metadata are treated as untrusted inputs. Wallet-bound funding challenges and atomic accounting protect credit attribution; separate operator credentials protect reporting changes. Public transaction evidence remains independently inspectable.

The treasury remains under operator control. The tracker reports eligible payments and verified execution, rather than reserving assets on-chain or guaranteeing that the wallet’s entire balance is available for the policy. Agent model budgets are separate from customer query credits and buyback allocation.

Source health, observation completeness, model accuracy, and transaction verification are different properties. Readers should use the coverage and timestamps associated with each record when assessing it.

Expand what can be demonstrated.

The longer-term goal is an intelligence service that agents can operate and other agents can use. The existing detector, capture pipeline, prepaid API, bounded runtime, and public accounting provide its current foundation.

Development directions include broader parser coverage, recovery and storage improvements, validated historical outcome datasets, carefully evaluated identity relationships, and additional evidence sources. X and Telegram collection, more complete historical coverage, and richer transaction verification require further implementation and evaluation.

These are directions, not released capabilities or committed delivery dates. New features should be accompanied by documented evidence, coverage boundaries, and reproducible checks before they become product claims.

Read the evidence alongside the paper.

• API documentationFunding, authentication, queries, current service terms, and public reporting interfaces.
• Machine-readable pricingCurrent accepted assets, minimums, and credit tariffs.
• Token policy and evidence trackerVerified identity, payment coverage, allocations, receipts, and buyback or burn records.
• Launch terminal · Source health JSONRecent observations and reported feed freshness.
• NOUS on Solscan · NOUS on Pump.funThe published token identity and its launch-platform page.

Version 1.0 · 23 September 2026. Initial public whitepaper covering the implemented architecture and published token policy. This is a dated design document; current balances and verification results belong to the live interfaces. Material revisions should update the version and describe the change.

The complete paper is readable without JavaScript. Use your browser’s Print command to save a print-formatted copy.