GEIGER
Beta
Scoring methodology

How GEIGER scores a signal

Scores are deterministic, versioned and derived from measured market activity. Generated commentary is added afterwards and never changes the score, publication decision or recorded outcome.

View signal receipts →
Score range
0–100
Signal window
15 min
Recent baseline
6 hours
Outcome checks
+1h / +24h

Active base inputs

Current public rule version: v1.0.0

Published rules
InputWhat is measuredBase cap
Buyer expansionUnique buyers in the current window relative to the token's recent norm.30
Volume expansionTrading volume in the current window relative to the same token's baseline.25
Transaction burstTransaction count accelerating above its recent baseline.10
Social velocityA bounded contribution when measured mentions accelerate.10
Early movementA bounded alternative bonus when wallets move before social activity.8

Context adjustments

When the underlying data is available, bounded adjustments account for holder concentration, liquidity depth, developer posture and unusually concentrated early buying. Missing context remains missing; it is not replaced with an estimated value.

Comparison rule

A token is compared with its own recent activity, not ranked by size alone. The active version's publication threshold determines whether a scored candidate becomes a public signal.

Reading the score

A score expresses measured signal strength. It is not a price target or recommendation.

80–100Strong60–79Constructive40–59Developing0–39Weak signal

Outcome measurement

01

Signal recorded

The score, rule version, reasons, timestamp and reference price are stored together.

02

Checkpoints measured

When price data is available, the reference price is compared at +1 hour and +24 hours.

03

Outcome resolved

A move of at least +15% at either checkpoint is a Bullseye. If neither checkpoint reaches it, the result resolves as a Miss.

Pending means the required checkpoint has not resolved yet. Misses remain in the public record and count in the hit rate once decided.

Daily record integrity

Computed hashes and on-chain anchors are not the same claim.

Transaction required for on-chain proof

Computed daily hash

Stored by GEIGER

GEIGER groups that day's signal records and computes a Merkle root. A root stored without a transaction hash is an internal integrity record; by itself, it is not on-chain proof.

Anchored record

Public transaction

Only a row with a transaction hash has committed its root to Robinhood Chain. For those rows, the explorer transaction provides the independent reference used to check that the recorded batch has not changed.

On-chain anchoring may be paused. The Receipts page labels computed-only rows explicitly and provides an explorer link only when a transaction hash exists.

Versioned learning loop

Historical Bullseyes and Misses may be used by an in-house logistic-regression process to propose a new weight set. A proposal first runs as a challenger in shadow mode. It cannot promote itself: human approval is required before a new public version becomes active. Existing signals keep the version that produced them.

Rule changelog

Published versions and their recorded changes.

VersionChangesActivated
v1.0.0Initial rule set: baseline-relative volume/buyers/tx scoring, social velocity layer, early-signal bonus, 1h dedup per token.Initial
Scores and signals are informational, not financial advice. · GEIGER