> For the complete documentation index, see [llms.txt](https://nytshift.gitbook.io/nytshift-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nytshift.gitbook.io/nytshift-docs/design-decisions-and-proposals/nightshift-signal-intelligence-layer-v1.md). # Signal Intelligence Layer v1 ## Product boundary Signal Intelligence is a read-only discovery and verification layer. It helps a user inspect why a Robinhood Chain asset may be interesting in the context of leveraged perpetual markets. It does not produce a direction, target, return claim, recommendation, or execution approval. NYTSHIFT is not affiliated with Robinhood. “Robinhood Chain” identifies the public chain and reviewed public market context used by the product. ## Minimal vertical slice The first slice lives in `/nightshift` and projects one setup for the currently selected canonical asset. It reuses the page’s existing data joins, so it adds no new polling stream: * reviewed Robinhood Chain token registry and contract identity; * reviewed Chainlink feed identity and the bounded RHC price endpoint; * live Arcus, Lighter, and Hyperliquid market catalogs; * preferred-venue mark, reference, funding, open interest, and 24-hour notional; * the existing bounded order-book endpoint for spread and visible depth. The initial category is `RHC discovery`. Structure and perp-flow categories are intentionally deferred until the product has tested windowed candle and flow-series contracts. ## Free-first source matrix All browser-facing signal reads terminate at NYTSHIFT routes. Venue and chain origins remain server-side configuration, not user-selectable URLs. V1 uses the existing bounded server adapters and 30-second catalog recovery cadence; a later server stream worker can lower latency without exposing venue sockets to the card. | Source | Free-first primary interface | Supported V1 fields | Limits and fallback | V1 use | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Hyperliquid | Official mainnet Info endpoint and WebSocket (`allDexsAssetCtxs`, `l2Book`, `trades`, candles) | mark, oracle, funding, OI, 24-hour notional, book, trades, candles | Official REST weight and WebSocket connection/message limits; reconnect and reconcile from Info/snapshot; stale or schema-drift data fails closed | Existing server Info adapter and bounded book route. A server stream worker is the next latency upgrade. | | Lighter | Official public REST plus readonly WebSocket ticker, trade, and order-book channels | mark/index, funding, OI, daily quote volume, BBO/book, trades, candles | Order book requires initial snapshot plus exact nonce continuity; any gap forces snapshot reconciliation. Respect published REST/WebSocket limits and readonly mode. | Existing server REST adapter and bounded book route. Browser-direct streaming is disabled for the Signal Intelligence page. | | Robinhood Chain | Official public rate-limited RPC, sequencer feed, reviewed contract registry, and official Blockscout explorer | canonical contract identity, block/head health, reviewed feed identity, bounded Chainlink price reads | Public RPC is not production-grade. Cache and rate-limit; fail closed on chain mismatch, stale head, sequencer state, or price gates. Upgrade the adapter to Alchemy or another documented provider before production-scale indexing. | Existing server RHC provider supervisor, reviewed registry, and bounded price/radar routes. | | Arcus | Repository adapter pinned to `https://api.arcus.xyz`; implemented `GET /v1/markets`, bounded books/trades/candles/funding, and normalized market stream support | online markets, mark/oracle, funding, OI, 24-hour notional, book, trades, candles where the adapter validates them | No numeric unauthenticated budget is claimed from the accessible documentation. NYTSHIFT applies its own conservative circuit breaker, concurrency, byte, cache, and timeout bounds. Any unsupported or malformed response fails closed. | Existing server adapter only. Do not expand fields or call an endpoint unless a primary Arcus contract can be verified. | | Social/narrative | None selected | none | No scraping and no assumed API. A later V1 may accept source-linked manual watchlist notes; automated velocity waits for legitimate API access and provenance. | Explicitly missing and not scored. | Primary references: * [Hyperliquid WebSocket](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/websocket), [subscriptions](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/websocket/subscriptions), and [rate limits](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/rate-limits-and-user-limits) * [Lighter WebSocket reference](https://apidocs.lighter.xyz/docs/websocket-reference) and [rate limits](https://apidocs.lighter.xyz/docs/rate-limits) * [Robinhood Chain connectivity and public endpoint guidance](https://docs.robinhood.com/chain/connecting/) and [token contracts](https://docs.robinhood.com/chain/contracts/) * repository Arcus adapter: `apps/web/app/api/market/arcus.ts`; shared bounded runtime: `apps/web/app/api/market/venue-public-runtime.ts` ## Provider-agnostic ingestion contract The target ingestion path is: 1. A server-owned source adapter pins the official origin and validates raw frames or responses. 2. A reconnecting stream worker obtains a fresh snapshot, applies only continuous venue events, and reconciles from the authoritative snapshot after every gap or reconnect. 3. A normalizer publishes a common market snapshot containing venue, market identity, mark/reference state, funding, open interest, notional, bounded book context, source, `observedAtMs`, health, freshness, and per-field missing-data reasons. 4. A short-lived cache coalesces identical reads and enforces configurable rate, concurrency, response-size, and circuit-breaker limits. 5. The signal projector receives normalized snapshots only. Stale, partial, divergent, or source-invalid data can retain labeled evidence for inspection but cannot reach `Mandate-fit`. Complete new-token indexing is not claimed. RHC discovery V1 is a bounded radar over the reviewed official contract registry and supported public reads. Comprehensive ecosystem indexing requires a production indexed provider and a separately reviewed ingestion contract. ## Setup card The card displays: * asset, venue, and market; * category and status (`Observe`, `Forming`, or `Mandate-fit`); * named evidence sources and freshness for the catalog, market, onchain price, and bounded book; * funding, open interest, 24-hour notional, spread, and bounded bid/ask depth where reported; * volatility as unavailable in V1 because no windowed series is currently derived; * explicit evidence invalidation conditions; * user-mandate and AEGIS eligibility state; * the venue’s current execution-authority boundary. The interface uses “Mandate-fit” only when fresh, complete evidence satisfies an explicitly supplied user mandate. Without one, even a fully verified setup remains `Forming`. AEGIS remains required, and mandate-fit is not an AEGIS verdict or execution approval. ## Night Shift Score The Night Shift Score is a transparent setup/evidence-quality score out of 100. It is not a predicted return, probability of profit, recommendation, or measure of directional confidence. Every point is visible in six components: * market activity — 20 points for reported 24-hour notional and open interest; * liquidity quality — 20 points for a fresh bounded book, explicitly banded spread, and visible two-sided depth; * source and contract integrity — 20 points for canonical contract identity, reviewed feed identity, a live Chainlink price, and a non-divergent perp reference; * data freshness — 20 points for market, book, and onchain price observations inside their stated freshness bounds; * funding and volatility context — 10 points; funding can contribute five points, while windowed volatility remains unscored in V1; * AEGIS and mandate eligibility — 10 points for an explicit mandate and evidence inside its declared limits, while an AEGIS verdict remains required. Missing inputs score zero in their component and appear as explicit warnings. Chart structure, narrative/social velocity, and windowed volatility are not scored until each has a tested data and provenance contract. The score can therefore top out below 100 in the current V1 even when the available evidence is healthy. The number expresses how complete, fresh, and policy-ready the displayed evidence is. It does not express whether an asset will rise or fall. ## Status semantics * `Observe`: no matching live perpetual market is verified. * `Forming`: a matching market exists, but evidence is incomplete, stale, divergent, outside policy, or no user mandate is attached. * `Mandate-fit`: fresh evidence satisfies an explicit local mandate screen. AEGIS evaluation and user approval are still required. ## Truthful degraded states The projection cannot promote a setup when: * the catalog market observation is older than 60 seconds; * the bounded book is unavailable, stale, crossed, or older than 15 seconds; * the reviewed Chainlink price is unavailable, stale, paused, or sequencer-down; * the venue reference is unavailable or quarantined as divergent; * funding, open interest, or 24-hour notional is not reported; * symbol, venue, funding, notional, or spread falls outside a supplied mandate. ## Excluded from V1 * buy/sell direction, entry, stop, take-profit, target, or expected-return copy; * predictive scores or claims about chain dominance or future volume; * Robinhood affiliation or endorsement claims; * token creation or token-launch mechanics; * live-trading permission or wallet-authority changes; * automated handoff from a setup to an order ticket; * derived volatility and structure labels without a tested windowed data contract. ## Grounded explanation — phase two A later AI explanation may summarize only the evidence, sources, component movements, missing-data warnings, status, and invalidation already displayed on the card. It must cite the relevant displayed fields, introduce no outside facts, and produce no personalized trade recommendation. Phase two requires an explicit schema for grounded inputs and output validation before implementation. ## Next approval The next scoped decision is whether to build a saved user-mandate editor and connect its versioned limits to this projector and AEGIS evaluation. After that, structure and perp-flow categories can be proposed against explicit candle and flow-series contracts. Neither step should change live trading permissions. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://nytshift.gitbook.io/nytshift-docs/design-decisions-and-proposals/nightshift-signal-intelligence-layer-v1.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.