Skip to content
Attune
All pages

Vector · The rules

What you submit

The weights of one pinned architecture in a Hugging Face repository, committed on chain, and nothing else: no code of yours ever runs.

3 min read

The weights of one architecture

A submission is model.safetensors holding the weights of vector_v1.1: exactly its tensors, by name, shape and dtype (the manifest's digest is d652e1c440ff…). The validator builds the network itself and loads your weights into it. No code, config or pickle of yours is read or run.

Everything else is yours: the data, the training, how long you train, and the normalisation statistics stored in the weights. The network, its inputs and its outputs are drawn on The model.

The repository

A Hugging Face model repository at a full commit sha, holding model.safetensors, stored with Git LFS, and optionally README.md and .gitattributes. Any other file gets the submission refused, and so does a file over 8 GiB.

Weights byte-identical to an entry already admitted are refused as a duplicate. The queue runs oldest commitment first, so the first entry admitted with a set of weights is the earliest one, as long as its repository is public when its turn comes. Commit before you make the repository public, and make it public right after.

The commitment

Your hotkey's commitment names the repository, the revision and the sha256 of your model.safetensors:

text
vector:<owner>/<repo>@<commit>.<digest>

<commit> and <digest> are the revision's 20 bytes and the file's sha256 in unpadded base64url, so the whole string fits the chain's 128 bytes with a repository id of up to 49 characters; the miner's tools build it for you. If the file at that revision does not hash to the digest you committed, the submission is refused.

One submission per hotkey

Each hotkey makes one submission. The validator queues a commitment as soon as it reads it from the chain, and from then on anything else that hotkey commits is refused: while your entry waits, during its duel, and after it, whatever became of it. The repository is looked up when your entry's turn comes; if it is refused then (other files, a digest that does not match, a duplicate) or cannot be seen (deleted, still private, or the Hub not answering), the entry is dropped and the next one duels. Run check before you submit: a second attempt needs a new hotkey.

Submitting, step by step

Install the miner's tools and set your Hugging Face token:

bash
pip install "robotensor[vector]"
export HF_TOKEN=...

Put your model.safetensors in a directory and check its header and tensors against the pinned architecture:

bash
robotensor miner check --dir submission/

Then submit. submit checks the weights again, uploads them to a new private repository, commits the repository, the revision and the weights' sha256 on chain for your hotkey, and only then makes the repository public. Use a new repository: an existing one keeps its visibility, and a public one would show your weights before they are committed.

bash
robotensor miner submit --dir submission/ --repo <you>/vector-mine \
    --network finney --netuid <netuid> --wallet.name miner --wallet.hotkey default

To commit by hand instead (after upload, which prints the revision and the digest), run robotensor miner commit --repo <you>/vector-mine --revision <sha> --digest <sha256> with the same chain and wallet options. Check that your commitment landed:

bash
robotensor miner status --hotkey <ss58> --network finney --netuid <netuid>

Time limits

Your policy runs on the validator's GPU, with limits:

Per-unit limits

Policy start-up
600 s
One action chunk
60 s
Policy time per unit
1,200 s
One unit
1,800 s

Rendered from spec.json at build time — the same file the orchestrator reads.

A unit that runs out of time is a failure for your side, not a void. Every entry is the same network doing the same work per prediction, so no set of weights is slower than another: the limits guard against a unit that hangs, not against your model.

What you submit · Docs · Attune