SPECTRAL CHAINLHC

Scope

This page is the LHC profile of Spectral Chain. It fixes how the general primitives of Spectral Chain (Vol. No. IV) are instantiated for Light Hedron Collider: which bytes are recorded, which operator profiles judge them, what gets attested, and which chain does what.

Identifiers defined here use the prefix LHC-. Everything not stated here follows the Spectral Chain chapters unchanged, in particular the canonical serialization and digest rules of the Spectral Attestation Standard (SAS).

Except where marked LIVE, this page is a specification of planned work.

Determinism in the game

Spectral Chain rests on one invariant: identical canonical input bytes must give identical results on every conforming implementation. In LHC that invariant holds at two levels and deliberately not at a third:

The physics engine runs in floating point inside the browser, so two devices may diverge after many steps. LHC therefore certifies what the player did (the transcript) and what the game offered (seed and ammo order), never the floating-point outcome. Bit-exact score replay would need a deterministic physics build and stays an open item.

Canonical Behavior Transcript

The client records one CBT per challenge session, in the exact byte layout of QFC-ABP (QFC-CBT-V1): fixed-size big-endian records, no JSON, no floats, no absolute timestamps.

LIVE The recorder runs in the game today, locally: every game is recorded in memory and can be downloaded in Settings → Research as an LHC-CBT-PACK-1 file (transcript bytes in base64 plus the SHA-256 digest). Nothing is uploaded. Without a verifier the challenge_id is local, derived from the game seed: SHA-256("LHC-LOCAL-CHALLENGE-V1" || seed).

header  = "QFC-CBT-V1" || profile_id (u16) || profile_version (u16)
          || challenge_id (32 B) || session_start_ms (u64)
event   = type (u8) || delta_ms (u32) || x (u16) || y (u16)
CBT     = header || event_count (u32) || event_1 || … || event_n
digest  = SHA-256("QFC-CBT-DIGEST-V1" || CBT)

LHC event types

Sling coordinates are normalised to the game viewport, ring coordinates to the ring (centre = 32768), both scaled to 0…65535, so a transcript does not depend on screen size or layout. Session limits for LHC-SC-1: at least 120 events, at most 20 000 events, at most 15 minutes.

Privacy. A CBT contains no IP address, device identifier, browser fingerprint or account. The verifier keeps the transcript encrypted only until its audit window closes (see Auditability vs secrecy); after that only the attestation hash remains.

Anti-Bot Proof

QFC-ABP turns a CBT into PASS or FAIL through a versioned Operator–Observable–Predicate (OΦA) profile. LHC uses both reference profiles:

The verifier returns only PASS or FAIL, never observable values. On its own that is not enough: a fully public profile can be evaluated offline. LHC therefore seals the exact parameters per epoch and couples each session to its challenge, see Auditability vs secrecy.

What a PASS unlocks

• Submitting a score to the shared leaderboard.
• Eligibility to mint a Quansistor game pass.

Playing never requires a PASS. Offline play, custom games and the AI arena stay open to everyone.

Auditability vs secrecy

This is the main open problem of Anti-Bot Proof, and Spectral Chain itself pulls in both directions:

• QFC-ABP §9.7: “Threshold parameters SHOULD remain undisclosed.”
• QFC-ABP §11.5: profile changes “MUST publish updated acceptance bands”.
• Spectral Behavioral Gate §3.7: the gate “must not depend on secret parameters”.

If the profile is fully public, PASS / FAIL is a function anyone can evaluate at home. Returning “only PASS or FAIL” then protects nothing: an attacker never asks the server, he runs the predicate locally and submits only transcripts that pass. Challenge binding and commit-first stop replay of an old transcript, not search for a new one. If the profile is secret, the attack becomes harder, but the verifier turns into a black box that can PASS whomever it likes, which is exactly what Spectral Chain was built to avoid.

LHC resolves the tension with three mechanisms that work together. The idea: audit is delayed, not removed, and the part that stays secret is small, bounded and committed in advance.

1 · Sealed epochs

The profile is split into a public family and a secret epoch key.

• Public family: operators, the full pool of observables, and for every acceptance band an allowed range. Versioned and immutable, as Spectral Chain requires.
• Epoch key s_e: 32 random bytes held by the verifier for one epoch (for example 30 days).

C_e   = SHA-256("LHC-ABP-EPOCH-V1" || e || s_e)       // published on NEAR before epoch e starts
θ     = HKDF(s_e, challenge_id)                        // per-session parameters, secret during the epoch
θ     → which k of n observables, exact bands inside the public ranges,
        which windows of the transcript are scored
verdict = Predicate_family(CBT, θ) ∈ {PASS, FAIL}

During the epoch nobody outside the verifier knows θ, so the predicate cannot be run at home. When the epoch ends the verifier publishes s_e. Anyone checks it against C_e, recomputes θ for every challenge and re-runs every verdict. The verifier cannot change keys halfway (the commitment is on NEAR) and cannot pick bands outside the public ranges (they are part of the family).

2 · Challenge-coupled play

Sealed parameters stop offline grinding against the predicate. They do not stop a library of pre-recorded human movements. So the challenge also shapes the game: during an eligible session the aiming ring shows a few calibration markers, small targets in the ring whose positions and times are derived from challenge_id. Steering the knob to a marker takes a second and is part of normal play.

Because the ring is a fixed HUD element, its events are recorded in ring coordinates, and the verifier knows where each marker was without simulating any physics. A transcript must show a live, human-shaped response to targets that did not exist before the challenge. A recorded trace from another session does not fit.

3 · A narrow oracle

An attacker can still use the live verifier as an oracle. LHC keeps that channel as narrow as possible:

• one verdict per challenge, delivered only after the session ends, never during play;
• one bit per verdict: PASS or FAIL, no scores, no reasons;
• challenges are rate-limited per wallet, and mint challenges are issued only to players who bought the full version, a few per purchase;
• θ changes with every challenge, so a FAIL says little about the next session.

Audit and privacy

Delayed audit needs the transcripts to still exist when the key is revealed. The verifier keeps each CBT encrypted until the audit window closes (end of epoch plus 30 days), then deletes it. Every verdict is committed on NEAR as SHA-256(CBT_digest || challenge_id || verdict), and the player's client keeps its own copy of the CBT, so every player can check their own verdict after reveal and any disputed verdict can be recomputed in public (QFC-ABP Dispute Mode).

What remains open

• A live bot with a good model of human motion that solves the markers in real time can still pass. ABP raises its cost; it does not stop it.
• Revealed epochs are training data for the next epoch. Shorter epochs reveal more often; longer epochs keep the verifier trusted for longer. The right length is an experimental question.
• During the epoch the verifier is trusted with s_e. Hiding it from node operators (ICP vetKeys) or proving verdicts without revealing θ (QFC-ABP Optional ZK Mode) would shrink that trust further.

Experiment. LHC will measure the PASS rate of humans and of each adversary class under three regimes (public profile, sealed epochs, sealed epochs + markers) and publish the cost per PASS for each. Whether delayed audit buys enough is a result, not an assumption.

Protocol flow

1. Challenge. The verifier issues challenge_id = SHA-256("QFC-ABP-CHALLENGE-V1" || nonce || window) when the player starts an eligible game. The challenge also places the calibration markers in the aiming ring.
2. Collect. The client records the CBT bound to that challenge.
3. Commit. Commit-first mode: the client sends the CBT digest before any verification feedback exists, so a transcript cannot be swapped after the fact.
4. Verify. After the session ends, the verifier derives θ from the epoch key and the challenge, rebuilds the operator, evaluates the predicate and commits the verdict on NEAR.
5. Token. On PASS it signs ("QFC-ABP-TOKEN-V1" || attestation_hash || expiry). The NEAR contract checks signature, expiry and that the attestation hash is unused.

The client can be modified by anyone, so it never decides PASS. It only collects and commits; verification and token signing happen in the ICP tier.

AI arena as ABP-AI lab

QFC-ABP-AI treats bot detection as a governed training loop rather than a fixed filter. LHC already has the adversary side of that loop: the AI arena LIVE, where large language models write bots against the public spec LHC-BOT-1 and play identical seeded games.

Pointer mode

The high-level bot actions (sling, laser) are executed by the arena as straight, evenly timed drags. A transcript of such a bot shows our converter, not the bot, so it is no adversary for the trajectory profile. That is why the bot API has a second input mode LIVE:

{ type: 'pointer', path: [[dt_ms, x, y], …] }    // x, y in viewport units 0…1
first point = press (on the coin or inside the aiming ring), last point = release
2–600 points · dt 0–2000 ms · total ≤ 8000 ms

The bot draws the whole gesture itself: the pull of the sling, the stroke past the photon line and on into aiming, the drag of the knob. To make that possible without physics knowledge, the state gives every body two viewport points: aim (where it appears in the aiming ring) and release (where to let go of the sling to land on it), plus the control geometry in state.ui. Targeting stays easy; the motion is entirely the bot's.

The arena executes the path frame by frame and writes the bot's declared times and points into the transcript, so a bot benchmarked at 4× speed produces the same transcript as at real speed. Each game in a benchmark is tagged input: "api" or "pointer", and after the benchmark the transcripts can be downloaded as one pack.

Calibration markers (see Auditability vs secrecy) will be exposed to pointer bots the same way, as viewport points to reach. Human sessions enter the shared dataset only with explicit opt-in.

Profile changes follow the ABP-AI governance rules: training happens offline, new thresholds ship only as a new profile version after a freeze window, and old versions stay valid for audit. Runtime classification never learns on the fly.

Attestations (SAS)

Every certificate LHC produces is a SAS attestation: canonical JSON with sorted keys, a declared OΦA descriptor, an input commitment and a math digest over the canonical math payload. LHC uses three kinds:

Example pass certificate (illustrative values)

{
  "acceptance": 1,
  "attestation_type": "SCC",
  "input_commitment": "5e1c…",
  "math_digest": "a90f…",
  "observables": [0.6012, 0.1874],
  "ofa_descriptor": {
    "execution_model_id": "NEAR-CT-N32",
    "observable_id": "bulk-r+gap1",   "observable_version": "1",
    "operator_id": "SMRK-GUEGAP",     "operator_version": "4",
    "predicate_id": "GUE-band",       "predicate_version": "1"
  },
  "sas_version": "SAS-0.1"
}

The operator is the SMRK Hamiltonian of PoQS at the NEAR Confirmation Tier dimension N = 32: logarithmic diagonal, prime-shift couplings, Liouville modulation and golden-gauge phase, all derived from SHA-256(B). The observables are the bulk ratio ⟨r⟩ (GUE reference ≈ 0.5996) and the first-gap proxy Δ₁.

Seasons: QFC-VRF and CSS

The arena uses fixed public seeds today, which is right for a benchmark and wrong for a competition: a known seed can be practised. Public seasons will take their seed from QFC-VRF, threshold BLS randomness with spectral binding, so the seed is unpredictable before the season and auditable after it.

season_seed = SHA-256("LHC-SEASON-V1" || vrf_output || season_id)
game_seed_k = u32(SHA-256(season_seed || k))   // k = 1…n games of the season

With each season LHC publishes a CSS fairness certificate over the seed and the derived ammo order. CSS certifies structural silence: under the declared operator the sequence shows no structured invariants, so no hidden pattern favours anyone who knows the generator.

Tiers

Threat model

Test vectors

Before any tier goes live, LHC will publish test vectors next to the bot spec: sample CBTs with their digests, the expected PASS / FAIL for each profile version, and SAS attestations with their math digests. Any independent implementation must reproduce them byte for byte.