One chain, many models: how TensorCash runs multiple AI models

People often assume that a useful-proof-of-work chain must choose one AI model and live with it forever. TensorCash does not.

The short answer is: every registered model is a valid lane into the same next block. The network agrees which lanes exist, gives each one a model-adjusted target, and lets miners decide which lane is worth using.

Here is the slightly longer answer.

Models enter by consensus, not an admin switch

A new model is proposed through an on-chain registration:

1. A sponsor posts a 5 TSC registration deposit and commits the model’s public identity, version, content reference and proposed difficulty scalar.
2. A 100-block confirmation window begins.
3. Supporting commit transactions must appear in at least 50 of those blocks, each referring back to the registration.
4. If the threshold is reached and the registration checks pass, the model becomes mineable. Otherwise it does not.

That is a hashpower vote. Support only counts when a commit lands in a valid block, and those blocks must be produced with models the network had already admitted. There is no operator dashboard with an “enable model” button and no one-miner-one-vote identity system. The scarce input is block-producing work.

The process is deliberately reversible. If a registered model later turns out to be degenerate or dishonest, a challenge opens a corresponding 100-block window. Fifty challenge commits can move it to the banned state. Admission and removal therefore use the chain’s own work, not a permanent curator.

One height, several difficulty lanes

TensorCash block headers carry two related difficulty fields:

• nBits is the network-wide base target. It keeps block production on schedule and provides the common unit for chain work and fork choice.
• nAdjBits is the target the particular block must solve, adjusted for the registered model that produced its proof of inference.

The bridge between them is the model’s registered difficulty scalar. In simplified form:

adjusted target ≤ base target × normaliser ÷ model difficulty

Suppose one model needs roughly twice the work per generated token. Its proposal can start with roughly half the difficulty scalar, which gives it roughly twice the target space. A qualifying proof then emerges about twice as often, compensating for the extra inference work. The numbers are confirmed as part of registration; they are not silently changed by a server operator.

This is what lets model A, model B and model C all grind the same height at the same time. They are not separate chains and they do not take turns. Each produces valid candidates through its own adjusted lane; the first valid block propagates, and ordinary proof-of-work fork selection does the rest.

Fair starting lanes do not mean equal market share

Model-adjusted difficulty gets unlike models onto broadly comparable starting ground. It does not decide how miners allocate GPUs.

A miner’s economics combine three things:

• block-subsidy revenue;
• revenue from selling the inference itself; and
• the cost of the model, hardware and serving configuration.

At any moment, one model-and-hardware combination may dominate. That is not a failure of multi-model support; it is the market revealing which inference is most valuable to produce. Demand for a larger model can support its higher cost. A cheaper model may win when latency or throughput matters more.

Miners can also choose batching and context configurations. Those choices change throughput, latency, memory use and the value of the inference being sold. Again, economics—not a protocol committee—decides the useful operating point.

This does not create a new validator class

Another common misconception is that TensorCash must recruit validators to score the models. It does not.

Proof-of-inference validation uses protocol-defined statistical tests, but the consensus result is objective: nodes apply the same rules to the proof and the registered model. Nobody votes on whether an answer feels intelligent, and no stake-weighted committee ranks its quality.

There is an operational cost. A fully self-validating miner or pool needs access to the admitted models required to check potential blocks. Validation can also be delegated, so that burden can sit at pool or service level rather than on every individual GPU worker. Delegation changes where the computation runs; it does not change the consensus rule.

See the loop working

Bob Labs’ TensorCash chat shows the full circuit in one screen. It currently serves Qwen3-8B: every reply is generated on a miner’s GPU, and the inference behind the reply is also proof-of-inference mining work. The same service is exposed through an API, so agent harnesses and other clients can tap the compute without inventing another consensus layer.

As more conventional causal autoregressive models are registered and served, the chain does not need a redesign. It already has the registry, the parallel difficulty lanes and the validation rules.

One chain. N models. The network admits them, difficulty normalises them, and the market decides which ones run.