Mining and checks

Mining is one click on /mine. The tab downloads the model once (about 90 MB, cached by the browser), opens a session and loops: pull, embed, submit.

The model

Xenova/all-MiniLM-L6-v2, 384 dimensions, fp32 weights, mean pooling, normalised, run by transformers.js on WebGPU. Browsers without WebGPU fall back to WebAssembly on the CPU, slower but identical in output. The client embeds its queries with the same model, so every vector lives in one space.

Canaries

Every pull carries 1 canary: a fragment whose vector the pool computed in advance with the same model. It has an id like any other fragment and is shuffled into the batch. The returned vector must reach a cosine similarity of 0.99 with the known one. A failed canary voids every share the session has not yet turned into notes, and the session can no longer mint.

Cross-checks

When a session returns a real fragment, the pool marks it for a second opinion with probability 0.15. The next session that pulls from the same lane gets it again. If the two vectors agree at 0.99, both are credited; if they do not, both sessions lose their pending shares and the fragment is embedded again. Cross-checks happen while a job is open and other sessions are pulling from it.

Shares

• One verified fragment is one share. Canaries are checks, not shares.
• Shares become notes once the session has 100 of them and has passed 2 canaries with none failed.
• The miner app mints automatically, so pending shares are only ever a hundred fragments of exposure.

What the miner sees

The fragment texts arrive in the tab because the model has to read them. The miner app shows fragment ids, never the text, and keeps nothing after the vectors are sent. The session id is kept in the browser so a miner can come back to its pending shares; clearing site data starts a new one.