LightScope API

Introduction

Decision-support data for trading products. LightScope turns fragmented market information into a concise, machine-consumable view of what is newly emerging, what is gaining momentum, where attention is concentrating, and how opportunities compare by risk.

It is not a dashboard. It is not an order router. Client applications — terminals, scanners, bots, and research tools — subscribe to the feed and render or act on the results themselves.

Who it is for

• Trading products that need a live, already-qualified stream of new pairs and momentum names
• Applications that want social attention and on-chain context attached to tokens they already track
• Teams that want risk context on a list they supply, without rebuilding enrichment in-house

Built for server-to-server integration. Your backend consumes LightScope, owns presentation and any extra client filters, and pushes an already-ordered view to your UI.

Outputs

Four outputs. Use them together or independently.

Outputs are research signals, not orders. A high-ranking name is a candidate for attention, not an instruction to buy.

What goes in

Four categories of evidence. Upstream providers are implementation details and can change. The product boundary is the normalized output, not any single vendor.

• On-chain — launches, swaps, holders, wallet behavior, funding and origin evidence
• Market — price, liquidity, volume, market cap, token metadata, history
• Social — account activity, mentions, attention, model-assisted analysis
• Enrichment APIs — third-party services used to normalize or fill gaps

Coverage today is concentrated on Solana and adjacent venues. Additional chains may be added without changing the client consumption model.

How it works

1. Live streams and scheduled requests ingest market, launch, wallet, holder, and social data.
2. Raw provider payloads are normalized into internal records.
3. Workers enrich candidates and keep time-sensitive state current.
4. Analysis assigns each qualified result to an output.
5. Qualified outputs are sequenced and published.
6. Clients receive live updates and recover missed events from a cursor-based history.

Filtering, ranking, and hide rules run on LightScope. Clients do not re-implement the screener. Proprietary gates and weights are not part of the public contract.

Delivery

Recommended client loop

1. Authenticate and open the SSE stream.
2. Persist the last seq / cursor you applied.
3. On disconnect, replay the journal from that cursor, then resume the stream.
4. Treat snapshot frames as current server state — replace, do not merge-guess.
5. For board UIs, take the list endpoint’s rows as the ordered set.

SSE, webhooks, and the journal describe the same sequenced output. If they disagree after a gap, the cursor journal wins.

Authentication

• Bearer token for feed and snapshot endpoints
• Short-lived stream tickets for SSE
• Exact-origin CORS allowlisting for browser clients
• Separate credentials for administrative surfaces

Treat the workspace token as a server credential. Do not embed it in a public frontend. Prefer a ticket so the long key never hits the browser.

GET /api/feed/ticket
Authorization: Bearer {FEED_TOKEN}

GET /api/feed/stream?ticket={ticket}&boards=ft

Integration principles

Your server owns the user-facing list. LightScope decides which names qualify and in what order. Hide rows for a user or attach execution state. Do not rebuild a second ranked universe from raw events.

The journal is an event log, not a ranked table. Events arrive oldest-first with a monotonic sequence. Ranked boards are separate HTTP resources.

Partial data is normal. Missing social, holder, or history fields do not mean a token failed. Do not treat null as zero.

Removals are first-class. When LightScope drops a name, remove it. Do not keep a stale card because you still have the last market-cap tick.

Do not depend on a vendor name in the payload. Provider identity is not the contract. Fields are.

What LightScope is not

• Not a brokerage, wallet, or smart-order router
• Not investment advice
• Not a guarantee against rugs — the bar is a near-zero rug exposure standard for what we surface
• Not a substitute for your execution, compliance, or user-risk controls
• Not a raw dump of every new pool on chain

Example shapes

Illustrative only. Field sets will be finalized in the versioned contract.

Journal / stream envelope

{
  "seq": 184291,
  "cursor": "184291",
  "ts": "2026-09-23T17:02:11Z",
  "type": "token.upsert",
  "token": {
    "chain": "solana",
    "address": "…",
    "symbol": "EXAMPLE",
    "name": "Example"
  }
}

Momentum snapshot

{
  "as_of": "2026-09-23T17:02:11Z",
  "rows": [
    {
      "chain": "solana",
      "address": "…",
      "symbol": "EXAMPLE",
      "name": "Example"
    }
  ]
}

Your UI replaces its momentum grid with rows, in the order given.

Getting started

1. Request a workspace token and, if the UI is browser-hosted, an origin allowlist entry.
2. Call the status endpoint and confirm the feed is accepting readers.
3. Open SSE, persist seq / cursor, and render snapshot frames.
4. Wire list endpoints (new pairs, momentum) as replace-the-grid payloads.
5. Optionally add signed webhooks for wake-ups; keep journal replay for recovery.

Access is issued by hand while the API is in closed beta. Request access.

Versioning

The current feed is a working foundation. The commercial contract will be versioned /v1/....

Breaking changes ship behind a new version. Additive fields may appear on an existing version; ignore unknown keys. Pin to documented field names and persist cursors as opaque strings plus integer seq.

Methodology, gates, and historical performance are intentionally out of scope. September 2026.