Guide

Verifying blocks

A TensorCash node that delegates its Full check over HTTPS can use Boblabs Verification as its verifier, with nothing more than a URL and a key. Anything else (a wallet, an explorer, a script) can submit a block and poll for the verdict with two HTTP calls.

Pointing a node at the service

In bitcoin.conf:

validationapi=desktop
validatorhttpurl=https://api.verify.tensorcash.boblabs.eu
validatorapikey=tvk_…

or on the command line, -validationapi=desktop -validatorhttpurl=https://api.verify.tensorcash.boblabs.eu -validatorapikey=tvk_…. The node then submits every block it validates and polls for the result on its own; there is nothing else to configure. No trailing slash on the URL.

Several verifiers. validatorhttpurl takes a comma-separated, ordered list (primary first), and validatorapikeys one key per URL in the same order:

validatorhttpurl=https://verify.example.org,https://api.verify.tensorcash.boblabs.eu
validatorapikeys=key-for-example-org,tvk_…

Environment variables do the same for packaged and container deployments: VALIDATOR_HTTP_URL and VALIDATOR_API_KEY for one verifier, VALIDATOR_BASE_URLS and VALIDATOR_API_KEYS (comma-separated) for a list.

The API name has a publicly trusted certificate; the node's default trust store accepts it. Mainnet only: a testnet node must not be pointed here.

Submitting a block yourself

The body is the ValidationRequest FlatBuffer with a BlockValidation, as a node builds it for the block (schema shared-utils/fb-schemas/validation.fbs in the TensorCash repository). It must carry the block's height and ruleset. Send X-Verify-Result-Contract: scoped/1 so the reply is keyed by everything it was judged under.

curl -sS https://api.verify.tensorcash.boblabs.eu/v1/verify/full/request/submit \
  -H "Authorization: Bearer $TVK" \
  -H "Content-Type: application/octet-stream" \
  -H "X-Verify-Result-Contract: scoped/1" \
  --data-binary @block.bin

Reply	Meaning
`202`	Queued or running. `status_ref` is the path to poll; `retry_after_seconds` says when.
`200`	The result, at once. Blocks already on the chain are usually answered this way.

Poll until final is true:

curl -sS "https://api.verify.tensorcash.boblabs.eu$STATUS_REF" \
  -H "Authorization: Bearer $TVK"

{
  "status": "Full_Green",
  "verdict": "Full_Green",
  "final": true,
  "hash_id": "6f1c…e2a9",
  "verification_type": "full",
  "scope": {"network": "tensor-main", "operation": "Full", "height": 29301, "ruleset": 4, "…": "…"},
  "scope_key": "9a4e…02bd",
  "policy": {"ruleset": 4, "model_identifier": "Qwen/Qwen3-8B@9c92…", "detector": {"entry_digest": null, "state": "na"}},
  "execution": {"executed_at": 1791325410.8, "elapsed_ms": 10400, "cached": true}
}

A Quick check (CPU, seconds, no model replay) is the same two calls against /v1/verify/quick/request/submit; use it when you want a fast structural answer rather than the model verdict.

Statuses

Status	Meaning
`Full_Green`	The proof is valid: the model ran and the chain rules hold.
`Full_Red`	The proof failed.
`Full_Amber`	Completed without a decision either way; `details` says why. A node applies its own rules to an Amber.
`Quick_OK` / `Quick_Fail`	The CPU checks passed / failed.
`pending`	Not finished; poll `status_ref`.

A 202 with "state": "needs_reverify" and an outcome object means the last attempt produced no verdict (for instance no capable worker was connected). It is not a verdict: keep polling, the service retries on its own. Every string is listed in Statuses.

Updated 2026-10-07