Vector · The rules
Fair measurement
Why the only way to win a duel is to train a better model: one network for everyone, identical demonstrations, units nobody can choose, no miner code, and a record anyone can check.
3 min read
One network for everyone
Every entry is the weights of vector_v1.1, built by the validator's own code. No entrant's code runs, so no entry can read what it should not, run longer than another, or touch the validator's host, and a duel compares only what the weights learned.
Before it reads a single tensor, the validator parses the safetensors header (at most 16 MiB) and
checks every tensor's name, shape and dtype against the pinned manifest. It then builds the network
and loads the weights with safetensors, so nothing is unpickled, and refuses any non-finite value
or zero normalisation scale.
Identical inputs
Every demonstration is made once per duel, before either side runs, and both sides are prompted with the same bytes; the record names each by its sha256. Both sides start from the same scored scene of each unit.
Nobody chooses the units
The units are dealt from the hash of the chain's finalized block when the duel starts, and that block must come after the challenger's commitment: nobody, the challenger included, could know its hash when the challenger committed. The validator reads the block and its hash from the chain itself, never from a miner. Duel scene seeds sit above the range the benchmark reserves for training and evaluation, so no policy can have trained on them.
Nothing privileged reaches a policy
A policy receives the demonstration, then the live camera frames and arm poses: the arrays listed on The model. The task's name, the scene seed and the success condition stay on the benchmark's side. The simulator runs from its own checkout and interpreter, the policy in a separate process behind an authenticated socket, and only named arrays and JSON cross between them.
Threat model
The adversary is anyone who wants emissions without producing a better model.
| Threat | Defence | What remains |
|---|---|---|
| Resubmitting the king's exact weights | Byte-identical weights belong to the first entry admitted with them | Nothing |
| A lightly perturbed copy of the king | One submission per hotkey; the crown margin | A near-copy can clear the margin by chance; a near-duplicate check is planned |
| Copying a miner's weights before they are committed | Upload private, commit the digest, then publish | Nothing, once the original is admitted |
| Flooding the queue from many hotkeys | One submission per hotkey; oldest first | Each entry costs a full duel; registration has a price |
| Malformed weight files | Header cap, manifest check before reading, finite values, non-zero scales, size cap | Nothing known |
| Memorising evaluation scenes | Seeds dealt after the commitment, above the reserved range | Nothing |
| Code in a submission | None runs: the validator's own runtime serves the weights | Nothing |
| Training on the public simulator | Allowed: it is the intended way to compete | Scores measure generalization within one scene distribution, which widens release by release |
A checkable record
The published record holds each unit's outcome for both sides, its scored scene's seed, the demonstration's sha256, the clips, the benchmark commit and the contract version. A duel's id and its units' candidate scene seeds are pure functions of published values, so anyone holding the record can deal the same units again and check the scene each unit used. The duel page recomputes the scores and the verdict from the units and says so if they disagree with what was published. Duel records shows how.