WITNESS.DASHBOARD

VIDEO UNDERSTANDING ON BITTENSOR

Understand video.See what matters.

Witness rewards the model that best works out what happens in a video: what is seen, what is said, what is written on screen, what is heard.

Miners submit immutable model weights. Validators run every contender on the same random clips each window, score its timestamped claims against reference labels, and give a registered king 100% of the weight with nothing burned; with no registered king, all of it is burned.

How it works View subnet on GitHub

MAINNET V2 PROTOCOL · OPEN SOURCE · ILLUSTRATIONS ARE NOT MODEL OUTPUT

STILL / EXAMPLE CLAIMSILLUSTRATIVE

A claim names what happens and when.

example · visual · textstill 1 / 4
Clip → model → timestamped claimsIllustration only, not model output.
BUILT WITH
BITTENSORPYTORCHTRANSFORMERSSAFETENSORSFASTER-WHISPERFASTAPIOPENCVFFMPEGBITTENSORPYTORCHTRANSFORMERSSAFETENSORSFASTER-WHISPERFASTAPIOPENCVFFMPEG

01 · THE PROTOCOL

One window.
One king.

A window spans two subnet epochs. Within it, every challenger and the reigning king face the same clips on each validator, under versioned rules published in the open.

01 · SUBMIT

Commit the weights

A miner serves one immutable package of full weights, config and tokenizer. Its manifest binds every file hash, and the first valid commitment permanently reserves the hotkey. Only a finished evaluation consumes it; failed checks or downloads do not.

ONE MODEL PER HOTKEY
02 · SAMPLE

Draw the clips

Each evaluating validator draws ten videos from a public 1,000-entry catalogue and cuts two random 10–30 second clips with audio from each: twenty clips per model. The batch stays fixed for the window.

SAME CLIPS FOR KING AND CHALLENGERS
03 · EVALUATE

Run and score

Validators download the weights over authenticated TLS, run them with their own loaders, and score each answer against two independent reference passes.

PAIRED AGAINST THE KING
04 · CROWN

One winner

To take the crown, a challenger needs stake-averaged quality above 0.05 and a paired reward lead over the king above 0.02. A registered king receives 100% of the weights and nothing is burned. With no registered king, including before two valid submissions produce a first king, 100% is burned.

100% KING · 0% BURN

Miner guide ↗Sampling, scoring and consensus ↗

02 · FOUR MODALITIES

One clip.
Four kinds of claim.

An answer is not a caption. It is a list of timestamped claims about what is seen, said, written and heard, each one checked against the references.

  • Visualevents, objects, actions
  • Speechwhat is said, and when
  • On-screen textstrings shown in frame
  • Soundnon-speech audio events
Still frame of a bee on a flower
CLAIM FORMAT OVER A STILL FROM CC BY 3.0 NATURE FOOTAGE (MICHAEL PISANO) · NOT MODEL OUTPUT

03 · SCORING

Right, complete
and on time.

Quality follows a versioned precision/recall contract. A claim is supported if either reference supports it and contradicted only if both contradict it; recall averages the two references. Speed moves at most a tenth of the reward; before window 30 it moved a fifth (0.8 + 0.2 × time_score).

deadline    = min(10 × clip_duration_seconds, 60)
time_score  = clamp(1 − elapsed_seconds / deadline, 0, 1)
clip_reward = quality × (0.9 + 0.1 × time_score)
Averaging
Clip scores average within each video, and video means average into the evaluation. After three complete videos, one 90% futility check on this fixed batch may stop a challenger early. Its partial score is only an upper bound and never crowns.
Latency
Loading and download are excluded from answer time. Every clip has a hard 60 second answer limit, and each attempt has 900 seconds after the shared batch is prepared.
Zero or defer
Missing or invalid answers score zero. Infrastructure failures and cancellation at an epoch change defer instead; they never count as zero.
On chain
Results are compact chain commitments that followers replay block by block. No HTTP vote counts.

04 · RECORDS

Every decision,
on the record.

The dashboard projects what the chain records: who holds the crown, which window is open, and how each validator evaluated each challenger.

Open the dashboard

WHAT THE DASHBOARD SHOWS

  • KingThe current king, the evaluation window, and intended versus applied weights.
  • ValidatorsEach validator's freshness, evaluation progress and results.
  • QueueThe fair order of challengers waiting for evaluation.
  • HotkeysConsumed and reserved hotkeys, with every evaluation in detail.
View subnet source on GitHub ↗