XIRA Whitepaper

Tokenized equities carry a data problem: the token trades on a chain, but the risk that matters is priced in a market elsewhere. A holder of an xStock cannot read one credible, dated number about how volatile, crowded, or news-sensitive that position is, and no off-chain vendor produces a number that can be verified without trusting them.

The mismatch is structural: xStocks trade 24/7 on-chain, while the underlying equity settles during market sessions, so volatility and liquidity risk accumulate in hours the price ticker never shows. The most active real-world use, lending against the token as collateral, under prices those hours entirely: a venue can quote a position but cannot score how risky it is to hold.

XIRA's answer is not another dashboard look. It is a pipeline whose output must survive a specific test: take the API response, recompute the evidence hash, and compare it to the bytes32 the oracle signed into the contract. The number and the proof move through the same pipeline.

The scope is deliberate: XIRA does not attempt legal ownership, custody, or compliance. It closes the intelligence-and-usability gap, turning price-tracked tokens into assets a vault or agent can assess and use with a number it can verify.

XIRA is also deliberately single-chain. Cross-chain protocols such as Chainlink CCIP solve the movement problem: how assets and data travel between networks. XIRA solves the intelligence problem where they arrive: continuous, explainable risk context for the assets trading on X Layer. The two stack: a tokenized equity can reach X Layer over CCIP, and XIRA keeps publishing risk intelligence about it once it is there.

Each attestation stores: symbol, composite score, confidence, the five factor scores with weights and descriptions, a plain-language explanation, model version, data source, and freshness in milliseconds. The evidence fingerprint is:

hash = sha256( json.dumps({
  "symbol": ...,           # e.g. "NVDAx"
  "score": ...,
  "confidence": ...,
  "factors": [ {name, label, score, weight, description}, x5 ],
  "data_source": ...       # "finnhub" | "mock"
}, sort_keys=True) )

The backend submits updateAttestation(asset, score, confidence, evidenceHash, modelVersion, anomaly, anomalyReason) to the XIRA contract at 0xDe28a2EEc95E3E9Dae6311966Ce2d8B45Db3d41E. The contract reverts on out-of-range values and only accepts writes from the owner or an authorized updater address. On-chain, anyone can read the latest attestation or just the score:

• getScore(asset)latest uint8 score
• getScoreBatch(assets[])many scores, one call
• getLatestAttestation(asset)score, confidence, hash, timestamp, version, anomaly

Verification procedure: fetch /api/attestations/{symbol}, recompute the hash from the response fields with the canonical serializer, then compare against the stored evidenceHash on-chain and the transaction in the explorer.

In live mode the fetcher pulls daily price history, volume, 52-week range, and market cap per underlying from Yahoo Finance and scores recent headlines with a positive/negative keyword classifier. All data is cached in memory for five minutes, so repeated reads are served from cache and the underlying feeds are not hammered. If a feed fails or falls behind, the engine serves a deterministic simulator and marks data_source accordingly. The attestation always states which world the number came from.

Publication follows a heartbeat plus deviation rule: every XIRA_HEARTBEAT_MINUTES (default 30) the backend re-scores each tracked market and writes a new on-chain attestation only if the score moved by at least XIRA_DEVIATION_THRESHOLD points (default ±3). There is no tx on a flat market. All tracked assets are passed in one pass, and simulated (non-live) data is never published on-chain, so every attestation transaction corresponds to a real score. The first pass runs 60s after startup, so the oracle self-publishes shortly after a cold start without waiting for traffic.

Failed or stale reads never manufacture risk: every factor returns the neutral 50 when its inputs are missing, keeping the composite near 50 during an outage instead of spiking.

Every computed attestation is appended to an SQLite store (with a bounded in-memory buffer of the most recent 50 per symbol). The /api/attestations/{symbol}/history endpoint replays that trail, so score deltas and the exact inputs that produced each number can be audited after the fact.