On TensorCash, the work that secures the chain is real AI inference: the network is designed so that running model forward passes is the mining, not a byproduct of it. As that turns the network into a standing signature — a proof that real AI inference happened — its difficulty takes on a second meaning. Difficulty is simply how much inference capacity is competing to secure the chain, which makes it one of the clearest on-chain readings of inference-market activity and AI-compute growth.
Which raises a question: what if that reading could be tokenised — turned into a plain, transferable asset that lives on the chain itself, whose on-chain settlement tracks how the difficulty index moves? A miner could use it to offset their own exposure to difficulty; anyone could hold a token tied to the same index, without an intermediary and without leaving the chain.
That is now live on mainnet. This post is a technical walk-through of exactly what was issued and how it settles — every number below is on-chain, and you can verify each one yourself.
First, the shape of the thing. The COMPUTE Index — the network’s mining difficulty read as AI-compute throughput, defined in full just below — over the chain’s history so far:
Network difficulty as throughput (target, solid) against the rate implied by observed block times (implied, dotted), on a log scale — the same view the explorer shows. Blocks ran ahead of the 600-second target, so implied sits above target and difficulty retargets upward to follow. It’s a factual record of the index over time, nothing more.
The underlying: the COMPUTE Index
Every TensorCash block is minted by a real forward pass, so the network’s mining difficulty has an interpretation no hash-based chain’s does: it tracks the AI compute committed to the network. The COMPUTE Index makes that explicit. It reads the difficulty as an expected throughput in consensus tokens per second:
COMPUTE Index X = GetBlockProof(target) · 256 / 600 (tokens/sec)target decodes from the compact difficulty field (nBits) in the block header;
600 is the consensus target block spacing in seconds. That’s the whole definition,
and it’s re-derivable by anyone from a header. These series were issued on mainnet on
19 July 2026; at that point (mainnet height ~13,466, nBits 0x1f00dc7f) the
index was ≈ 32,464 tok/s. That is a historical reading at issuance — the index has
moved since, as the path below shows.
The COMPUTE Index over recent blocks
The index is not a smooth line: difficulty retargets in steps, so the reading holds flat between retargets and then jumps. The chart below is the actual on-chain series across the blocks around issuance, read straight from each header — a factual record of where the index has been, nothing more. (It is distinct from the strike-relative settlement diagrams further down: this is the index’s own path over time; those describe how a vault is split at maturity.)
The anchor: COMPUTE is a rulebook, not money
The series are sponsored by a root asset with the ticker COMPUTE — a difficulty
anchor. It is deliberately a zero-economic-claim namespace asset: 100 indivisible
governance units, a 51% quorum, and a public charter committed on-chain
(icu_plain_commit, readable by anyone with geticupayload). COMPUTE is not the
money in these contracts; it’s the namespace and the amendable rulebook under which
difficulty series are issued. Holding a governance unit is a vote on the charter,
nothing more.
- Ticker
COMPUTE, registry idf9b30f21fd6b7a13dff6497ba7ac3f62a3270c09a5adbed274aad4c85161a1a8— view on the explorer. - Registered in tx
baa2c77f25ede0a7689558db9f156813c496726d38bdfcf6b3c7a1d7a695248d; the 100 governance units minted in559554e098e3822484ecd61c3632802c937940411bb518fe4e7ed3a534fee9f4.
The term sheet lives on-chain
Every asset registered on TensorCash can bind a canonical term sheet to itself,
persisted on-chain and readable by anyone. The asset carries a hash-committed ICU
payload — you read it with geticupayload or straight from the explorer — recorded in
the registry as a commitment (icu_ctxt_commit) and immutable except by a governed
rotation. For these option series the binding is even tighter: the series’ canonical
id is the tagged hash of its descriptor, so a cold verifier recomputes the id straight
from the terms and confirms nothing was swapped underneath it. (The COMPUTE anchor’s own
id is a fixed tagged hash, SHA256("TSC-COMPUTE-ANCHOR/v1"), and its charter is committed
separately in the same readable way.)
For these series the payload holds a machine-readable descriptor (the
TSC-ICU-OPTSERIES-1 band: strike, direction, fixing height, leverage) alongside a
human-readable summary. The contract terms therefore live in the chain, not in an
off-chain PDF that someone has to host and honour.
This is not special to options. Any registered asset can commit a canonical term sheet or charter to itself this way, immutable except by a governed rotation — the COMPUTE anchor does exactly that with its public charter. Options are just one shape of term sheet the mechanism can carry.
What “intrinsic” means
These series settle with no oracle, no issuer publication, and no off-chain data — an intrinsic settlement. At the fixing block height, consensus does the work itself:
- Read the block header’s own
nBits. - Decode the target and compute the realized COMPUTE Index
X. - Enforce the split of each contract by the rule committed in the series descriptor.
Because the only input is the header, the result is not a claim you trust — it’s a computation every full node repeats and agrees on. Re-run it a year later on the same block and you get the same number. That is the whole point of an intrinsic series: the contract’s terms are consensus rules.
The covenant-vault lifecycle
Each contract is issued as a set of lots, and every lot is a covenant vault holding 1 TSC. The token that represents a lot is an ordinary fungible, transferable, consensus-native asset — one token is one claim on one vault’s pot.
The lifecycle has five movements, all enforced by the protocol:
- Register. The series descriptor — strike, direction, fixing height, leverage — is committed on-chain first, in the registration transaction. That commitment is what defines the series: the asset’s canonical id is derived from the descriptor, so the terms and the identity are one and the same.
- Issue. The writer self-mints all the lot tokens and funds one 1-TSC vault per lot against the already-registered series.
- Transfer. The tokens change hands like any other consensus asset. Whoever holds a token holds that lot’s pot claim.
- Settle. At maturity (the fixing height, plus a short burial delay), anyone can submit the settlement transaction. Consensus computes the realized index from the header and splits each vault between the holder pot and the writer’s reclaim according to the payoff rule below.
- Redeem / reclaim. A holder sweeps their pot by redeeming a token; the writer can reclaim unsold lots early via a buyback path.
No step depends on the issuer being online, honest, or solvent at maturity — the vault already holds the collateral, and the split is a rule, not a promise.
The two live series
Both series fix at the same height and share the same shape (leverage λ = 4, 100 lots × 1 TSC = 100 TSC collateral, descriptor version 2). They differ only in direction and strike.
| COMPUTE.V26C2M | COMPUTE.V26P100K | |
|---|---|---|
| Direction | call | put |
| Strike K | 2,000,000 tok/s | 100,000 tok/s |
| Fixing height | 28,416 | 28,416 |
| Settle lock | 28,516 | 28,516 |
| Leverage λ | 4 | 4 |
| Collateral | 100 lots × 1 TSC | 100 lots × 1 TSC |
| Registry id | 8a31784f9ebe8a94250d3c6c7702196e0f9814c413bd317fc892f18a5ccbce24 | 59080a03b813589fa2f0e6cc2f17e5eb386dd0abc15f89b7763c1e17218a7cbb |
| Canonical series id | 24cecb5c8af192c87f31bd13c414980f6e1902776c3c0d25948abe9e4f78318a | bb7c8a21171e3c76b7895fc1abd06d38ebe5172fcce6f0a29f5813b8030a0859 |
| Registration tx | e220a481cee7e9335917ac84824f7383421e6c34a1d730dcf0c4d5d6e820e4e1 | 9f8c3b501be95b89b9c78b6dc477f5e15068a620d1c8b30e35a2f6a3babdfcfa |
| Issuance tx | e0a309feaad7ccaef11e7bedc3e4a5841a88493aec93e41558f47493ccaddcf5 | 9148173679d477f60ac1e55c78a4c30d5c51865ab77bdab1d3ec21709d0c2d45 |
The registry id is the one to query by — it’s what wallet RPCs and the explorer show. The canonical series id is the same value byte-reversed (the internal, descriptor-derived form); the two are just two orderings of the same 32 bytes. You can also just look either series up by its ticker.
View on the explorer: COMPUTE.V26C2M (call) · COMPUTE.V26P100K (put).
Fixing height 28,416 lands around 31 October 2026, 12:00 UTC at 600-second spacing — but the height is authoritative, not the date.
How the covenant computes the split
At maturity, each 1-TSC vault is divided between the holder pot and the writer’s
reclaim as a function of the realized index X. Per 1-TSC token, with strike K and
leverage λ = 4:
- Call (
V26C2M): routes to the holder pot only whenX > K—min(1, 4·(X − K)/K)TSC;0whenX ≤ K. - Put (
V26P100K): routes to the holder pot only whenX < K—min(1, 4·(K − X)/K)TSC;0whenX ≥ K.
Whatever the rule does not route to the holder pot returns to the writer, so the two
shares always sum to the vault’s 1 TSC. The min(1, …) cap means the holder pot fills
the whole vault once the index is 25% past the strike (because 4 × 0.25 = 1).
The two diagrams below are pedagogy — they show how the covenant computes that split, plotting the TSC routed to the holder pot against the realized index. They are not a forecast and not an offer; they describe a settlement rule. For orientation, each diagram marks the index’s value at issuance (≈ 32,464 tok/s, on 19 July 2026) — a historical reading, shown only to locate that day’s value on the rule.
On the day of issuance (19 July 2026) the index read ≈ 32,464 tok/s. Where that value falls on each curve is simply arithmetic on the rule above; the diagrams place the issuance tick for reference. What the index does between now and the fixing height, and therefore how any given vault ends up split, is not something this post predicts — the settlement is whatever the header says at height 28,416, computed by every node.
Reading the name
The ticker encodes the descriptor in a fixed convention:
COMPUTE.<MonthCode><YY><C|P><Strike>
month codes: F G H J K M N Q U V X Z (V = October)So V26 = October 2026, C2M = call at strike 2,000,000, P100K = put at
strike 100,000. The month label and the display strike are human conveniences; the
authoritative terms are the strike_nbits and fixing_height committed in each
series’ descriptor. (For the two series above, strike_nbits is 503551042 for the
call and 508007729 for the put.)
Check it yourself
Nothing here asks for trust. The charter and each series descriptor are readable
on-chain with geticupayload, and the realized index is just arithmetic on a block
header you already have — GetBlockProof(target) · 256 / 600. Pull the descriptors,
recompute the index at the fixing block when it arrives, and confirm the split the
covenant enforces is exactly the one the rule specifies.
Don’t trust — verify. The number that settles the contract was never something a third party had to report. It was in the header the whole time.
This is an informational and explanatory post only. Nothing on this page constitutes an offer, solicitation, or invitation to buy or sell any token, security, or other financial instrument. Neither this website nor any TensorCash social channel is a venue for arranging, negotiating, or discussing over-the-counter (OTC) transactions or sales.
Authored pseudonymously by Imosuke Takakuni.