TensorCash
محفظة TSCانضمّ

اختر لغة

For miners and verifiers

Verifiers

A verifier checks that the proof in a block matches the promised model. The verifier software is open source, and anyone can run one [1][2]. The protocol does not pay verifiers. Nodes and pools run one to check blocks for themselves.

Hardware and software

The quick check and the smell test run on an ordinary processor. The full check runs the model again over the 256 tokens of the window, so it needs a GPU with the model loaded, plus CUDA and PyTorch, the standard software for running models on NVIDIA GPUs [1][3]. The verifier runs in Docker [1].

Setting up a verifier

Setting up a verifier takes four steps. The full commands are in the official guide [1].

  1. Choose how to run it

    Own verifier
    What it isThe node runs its own verifier on the same machine.
    Node setting-validationapi=real
    Needs a GPUYes, for the full check

    In both cases, the node always runs the cheap checks itself, such as signatures, proof of work, the model registry and the quick and smell checks [4]. A node or exchange can also share one verifier service with others [3].

  2. Start the verifier

    The verifier is reached over HTTP on port 9000. It does not start without an access key for the operator (OPERATOR_API_KEY). Who else may use it, and how often, is set with VERIFY_AUTH_ENABLED, VERIFY_API_KEYS and VERIFY_RATE_LIMIT_PER_MIN [1].

    deployments/docker-compose/core-validation-api/

  3. Connect the node

    Start the node with the setting from step 1. With its own verifier, the node sends proofs over a local connection, and the results are signed so they cannot be altered on the way [4][5].

  4. Check that it works

    The verifier answers on /health. Submitted checks can be followed on /v1/verify/status/<hash_id>, and anyone can see the result on /v1/public/status/<hash_id> without a key [1][6].

    RouteWhat it does
    /v1/verify/quickQuick check
    /v1/verify/quick-smellQuick check and smell test
    /v1/verify/fullFull check, with a rerun of the model
    /v1/verify/challenge/requestChecks submitted for a challenge
    /v1/verify/status/<hash_id>Status of a submitted check
    /v1/public/status/<hash_id>Public status, without a key
    /healthHealth check

    Requests are sent in a fixed binary format, described on the Schemas page of the API reference [7].

How the results are used

A proof that fails the quick check stops at the node that received it. The smell test keeps implausible proofs from spreading through the network. A block that fails the full check is not rejected outright, but counts for zero work, so it is unlikely to stay in the chain [3][12]. The verification whitepaper still describes RED as a rejection. The node that runs today counts the block for zero work instead [12]. In tests, honest proofs came out 97.3% GREEN, 2.7% AMBER and 0% RED [8].

VerdictMeaningThe block
GREENThe proof cannot be told apart from an honest run of the promised model.Accepted
AMBERUnusual, but not enough for RED.Not accepted on this verdict alone. The node can run the full check again.
REDThe proof does not fit the promised model.Counts for zero work

Challenging a model

Some problems only show up after a model has been registered, for example a model that does less computation than it claimed. These can be raised with a challenge [3].

  • Every model is registered with a deposit before it can be used for mining [9].
  • To challenge it, someone points to a block mined with that model and locks a deposit of their own. This schedules a verdict 100 blocks later [3].
  • During those 100 blocks, miners can include commits that support the challenge. With 50 commits, the challenge succeeds. The model is banned, its deposit is burned, and the challenged block no longer counts towards the work behind the chain [3].
  • Without enough commits, the model stays registered and the challenger loses their deposit [3].

A challenge can be posted from the AI Models tab in the wallet [10]. The same flow is available in RPC [11].

CommandWhat it does
createmodeldepositLocks the deposit to register a model
createmodelcommitAdds a commit that supports a registration or challenge
getmodelregistrationstatusShows where a registration stands
createchallengedepositLocks the deposit to challenge a model
createmodelreclaim / createmodelburnReclaims or burns a model deposit

References

  1. [1]TensorCash blog, How to run a verifier, 27 June 2026.tensorcash.org/blog/how-to-run-a-verifier/
  2. [2]TensorCash website, Get involved.tensorcash.org/build/
  3. [3]Inference Verification: Mathematical Specification.tensorcash.org/whitepapers/Verification_Whitepaper-modern.pdf
  4. [4]TensorCash blog, How to run a node, 27 June 2026.tensorcash.org/blog/how-to-run-a-node/
  5. [5]TensorCash source code.git.tensorcash.org/tensorcash/tensorcash
  6. [6]TensorCash docs, Verifier REST.tensorcash.org/docs/verifier/api
  7. [7]TensorCash docs, Schemas.tensorcash.org/docs/schemas
  8. [8]TensorCash mainnet announcement on Bitcointalk, 17 July 2026.bitcointalk.org/index.php?topic=5588724.0
  9. [9]TensorCash blog, One chain, many models: how TensorCash runs multiple AI models, 14 August 2026.tensorcash.org/blog/how-tensorcash-runs-multiple-models/
  10. [10]TensorCash blog, How to run the wallet, 27 June 2026.tensorcash.org/blog/how-to-run-the-wallet/
  11. [11]TensorCash docs, JSON-RPC, model.tensorcash.org/docs/rpc/model
  12. [12]TensorCash blog, Trust in action: how verification caught an fp8 miner, 23 July 2026.tensorcash.org/blog/catching-a-quantized-miner/