Oracle & Randomness

CashPop selects each Round's question from a reservoir of >100,000 pre-curated questions. The selection must be:

1. Unpredictable before the Round starts (so no insider can pre-coordinate a chosen answer).
2. Auditable after the Round ends (so any third party can re-verify the selection).
3. Manipulation-resistant against any single oracle's compromise.

The seed construction

The question seed for Round t is:

$${\sigma }_t=H({\sigma }_{t-1}\parallel r_t^{\text{DRAND}}\parallel r_t^{\text{TON-VRF}})$$

Where:

• σ_{t-1} is the previous Round's seed (provides causal chaining).
• r^{DRAND}_t is the latest beacon output from the DRAND public randomness network (League of Entropy: Cloudflare, Protocol Labs, EPFL, etc.).
• r^{TON-VRF}_t is a TON-native VRF output from a permissionless validator set.

The seed selects the question via:

$$q_t=\mathcal{Q}[{\sigma }_t\mathrm{mod}|\mathcal{Q}|]$$

Why hybrid DRAND + TON-VRF

A single randomness source has a single point of compromise. By combining two independently-administered sources via concatenation and hash:

• An adversary controlling DRAND alone cannot bias the seed.
• An adversary controlling TON-VRF alone cannot bias the seed.
• An adversary would need to compromise both simultaneously for a Round's worth of beacon (a vanishingly low probability for two independent threshold-secured systems).

DRAND uses BLS threshold signatures across 10+ public validators with rotating drand-keys. TON-VRF uses TON's elected validator set's threshold signature. The two systems share no operators, no infrastructure, no software supply chain.

DRAND beacon details

• Beacon frequency: every 3 seconds (League of Entropy mainnet).
• Beacon size: 32 bytes.
• Verification: BLS12-381 signature, public key published; anyone can verify a beacon offline.
• Lookback: CashPop uses the most recent beacon with timestamp ≥ Round start.

TON-VRF details

• Implementation: derived from validator's BLS signature on Round start hash.
• Verification: BLS signature against published validator pubkey rotation.
• Lookback: the VRF output corresponding to the master-chain block at Round start.

Question reservoir generation pipeline

LLM ensemble {L1, L2, L3, ...} generate candidates
              ↓
Adversarial debiasing (linguistic priming removal)
              ↓
Calibration pretest (synthetic-population simulator estimates response distribution ρ̂)
              ↓
Filter: |ρ̂ - 0.5| > τ → discard
              ↓
Human-in-loop quality review (sampled 1% of candidates)
              ↓
Hash and commit to reservoir merkle tree
              ↓
Reservoir batch published on-chain (committed monthly)

The monthly reservoir publication means the question pool is publicly auditable: anyone can verify that question q_t selected on date d was indeed part of the reservoir committed before d.

Why adversarial debiasing

Naively-generated questions tend to carry priming patterns from the LLM's training data — Western-cultural assumptions, gender-coded language, age-implicit references. We rewrite candidates to remove such priming (techniques from Bolukbasi et al., 2016; Caliskan et al., 2017). The goal is questions whose response distribution depends on the population being polled, not on how the question is phrased.

Why calibration pretest

The Beauty Contest game is most informative when the strategic uncertainty is highest — i.e., when the population's expected response is closest to 50/50. We discard low-entropy questions (where most populations would obviously go one way) because they make the game trivial. The threshold τ is in the range [0.05, 0.15] depending on game mode.

Failure modes and graceful degradation

Failure	Detection	Response
DRAND beacon timeout	DRAND health check (every 30s)	Pause Rounds, alert ops
TON-VRF validator timeout	TON masterchain monitor	Pause Rounds, alert ops
Reservoir desync	Merkle root mismatch	Halt Round; manual re-sync from canonical store
LLM pipeline poisoning	Statistical anomaly detection on calibration distributions	Quarantine batch; human review

The system fails safe: in any oracle failure, Rounds pause, no settlement occurs, no rewards are paid. Escrowed funds are recoverable to users by emergency multisig vote.

Verifiability checklist for skeptics

A third-party auditor at any time can:

1. Fetch the on-chain seed history.
2. Fetch the published reservoir Merkle root for that month.
3. Fetch the corresponding DRAND beacon and TON-VRF output for that Round timestamp.
4. Re-compute σ_t = H(σ_{t-1} ‖ DRAND ‖ TON-VRF) and verify it matches the on-chain commit.
5. Re-compute q_t = Reservoir[σ_t mod |Q|] and verify it matches the question delivered.

If any step fails, the Round is void and a dispute is filed.