SignalX

Guide

Methodology

How SignalX validates Live Feed signals using real XRPL Mainnet, official filings, and two-source market confirmation — without mock fallbacks.

Last updated:

How a signal gets validated

SignalX ingests records only from configured real sources (XRPL Mainnet ledgers, official government disclosure systems when reachable, issuer and confirming market-data adapters when lawfully available). There is no production mock or synthetic feed fallback.

Each raw record is normalized into the canonical LiveFeedEvent model. Required provenance is attached through typed evidence[] entries. Evidence requirements differ by source type — not every event uses the same validation path.

Canonical evidence types in production are: transaction, filing, publication, market_data.

XRPL claims require a validated ledger payload: the transaction must include validated === true, transaction meta, ledger hash, ledger index, and a transaction hash. A transaction can be validated on the ledger yet unsuccessful (engine result other than tesSUCCESS). SignalX preserves both validated and successful distinctly — ledger inclusion is not the same as a successful outcome.

Filing claims (capitol_disclosure) require official filing evidence (type filing) with an allowlisted HTTPS URL under the Office of the Clerk (House) or Senate Electronic Financial Disclosure domains, plus the official document id. Matching requires extracted filing text to contain XRP, Ripple, or RLUSD as whole tokens. Filename- or snippet-only hits are rejected. Filing publication date and any reported transaction date are stored separately; a disclosure is not treated as a live trade or an on-chain XRPL wallet transfer.

Market institutional_flow figures require Task 8’s two-source confirmation rule (rule etf-flow-confirm-v1): an issuer-side observation and an ETF.com Fund Flows confirming observation for the same verified U.S. spot XRP product, flow date, and USD unit, within absolute tolerance $1000 or 10 basis points relative. Values are never averaged. Single-source observations stay unconfirmed (“Single-source — awaiting confirmation”) and are not published as validated institutional_flow. Conflicts beyond tolerance stay unpublished. ETF.com access is licensed; until authorized credentials and a bound API schema are configured, the confirming adapter remains unavailable and issuer observations stay unconfirmed.

attributionStatus describes entity attribution, not source confirmation: verified means independent evidence supports a named entity claim; unverified means a candidate was considered without sufficient evidence; unknown means no entity attribution is asserted. Source confirmation (for example two-source ETF flow agreement) is separate from naming who moved funds.

Failed extraction, incomplete evidence, stale sources, single-source market observations, and conflicting market figures do not become validated published claims. Published feed reads exclude retracted events. The publicationStatus model includes draft, in_review, published, corrected, and retracted so corrections preserve audit history rather than silently rewriting facts.

AI may later summarize verified evidence; AI narration is never itself provenance and does not set attributionStatus or invent evidence URLs.

  • →attributionStatus verified — entity attribution supported by canonical evidence
  • →attributionStatus unverified — attribution candidate without sufficient evidence
  • →attributionStatus unknown — no entity attribution claimed (common for raw XRPL and disclosure events)
  • →evidence type transaction — XRPL transaction / explorer reference
  • →evidence type filing — official House or Senate financial disclosure
  • →evidence type publication — official publication URL when used
  • →evidence type market_data — issuer fund data and ETF.com Fund Flows confirmation (both required for published institutional_flow)

Sources

How categories map to pillars

Signal categories are defined once in FEED_CATEGORIES. Each category belongs to exactly one product pillar. Coming-soon categories are labeled below and do not imply production ingestion.

  • →WaveSignal: XRP Markets; Stablecoin Markets; Active Signal
  • →Hotlist: Whale Movement; Corporate Purchase
  • →Ecosystem Map: XRPL Foundation; Ripple Payments; Use Case
  • →Discovery Radar: Institutional Tokenization; Risk Factor; Institutional Flow
  • →Daily Intelligence: Crypto Regulation; Ripple Brief; Ripple Insight; Expert Opinion; Capitol Disclosure; Regulatory Influence (coming soon)

What we don’t do

SignalX provides informational discovery tools only. This is not financial advice, investment guidance, or a trading platform. SignalX does not execute trades and does not custody user funds.

  • →SignalX does not publish price targets.
  • →SignalX does not frame signals as instructions to buy or sell.
  • →SignalX does not guarantee results or outcomes.
  • →SignalX does not turn unknown attribution into a named entity claim.
  • →SignalX does not treat AI-generated narration as source evidence.
  • →SignalX does not fill missing data with fabricated activity.
  • →SignalX does not treat a single-source market observation as two-source confirmed.
  • →SignalX is informational and not financial advice.