Targon: how the mechanism works

This is the sharpest case in this batch of deep-dives: a real GPU-rental business, real cryptographic hardware verification, and — measured at this course's snapshot — a payout of nothing.

Targon rents out GPU compute that has been hardware-sealed with Trusted Execution Environment (TEE) technology, so that a workload running on a rented GPU stays private even from whoever owns the machine it runs on. The subnet's own materials describe hardware-enforced memory encryption, secure boot, GPU-level isolated execution, and remote attestation as its core security features. [source] [source]

At this course's snapshot, Targon holds 8103 @ 8878789 token holders — 2 @ 8878789 highest of any subnet this course tracks — while its measured emission share is 0.0% @ 8878789, rank 29 @ 8878789. 7 @ 8878789 miners are active out of 256 @ 8878789 registered keys, judged by a committee of 6 @ 8878789 validators. A large, long-standing holder base and a measured zero payout, at the same time, is the pairing this lesson tries to explain.

How a miner gets paid

A miner does not compete on one shared score. It bids GPU capacity into a per-hardware-type auction — one per GPU model, such as TDX-VM-NVIDIA-H200 or TDX-VM-NVIDIA-B200 — and each auction publishes a target card count, a target price per card, a payment cap per card, and a minimum cluster size a miner must clear before it can participate at all. [source] [source] While an auction sits below its target card count, every verified card earns up to the payment cap; once enough cards come online the pool spreads across them and the effective per-card rate settles down toward the target price. [source] Any part of the pool an auction does not claim is not handed to other miners — the subnet's own materials say plainly that emissions not allocated to an auction are burned. [source]

The verification problem

Paying by declared card count only works if a miner cannot simply declare cards it does not have. Targon's answer is remote hardware attestation, and it runs on every card before that card counts toward anything. A validator asks each of a miner's nodes directly for a signed attestation quote, then forwards that quote to a separate verification service — the subnet's own materials call it "Tower" — which checks it and returns a plain valid-or-invalid answer. [source] [source] [source] [source] A node also carries its own hardware identifier, and the validator refuses two nodes claiming the same one — the one obvious way to double-count a single physical machine across two miner registrations. [source] [source]

Unverified The quote a node returns carries its own claimed card list alongside the cryptographic attestation data, and this course's pinned source shows the validator trusting that card list once Tower has said the quote itself is genuine — it does not show, because Tower's own code is not part of this pinned corpus, whether the number of cards is itself something the hardware quote cryptographically commits to, or whether it is a self-reported field alongside a proof that only covers the hardware's authenticity in general. This course cannot confirm which one it is from the source available to it, and that difference is exactly the gap between "we proved a genuine confidential GPU is behind this" and "we proved a genuine confidential GPU is behind this, and there are exactly this many of them."

Why they built it this way

The subnet's own stated reasoning for verifying hardware at all is the confidential-compute pitch itself: memory encryption, secure boot, and remote attestation exist to make a rented workload verifiably private, which only means anything if the hardware behind it is provably real. [source] That reasoning covers *why hardware gets attested*. It does not extend, in anything this course's pinned source states directly, to *why pay is organised as a set of separate per-hardware-model auctions* rather than one shared queue — this course did not find that design choice explained in the subnet's own materials, so it says that plainly rather than inventing a rationale for it.

What a miner is actually optimising

The stated goal is secure, verifiable, confidential compute. [source] What the weight-setting code actually pays for is narrower: verified card count inside a specific hardware auction, capped at that auction's maximum price, and nothing else — nothing in that calculation touches what a renter's workload needed, how much of the card's capacity was used, or how long a job ran. [source] [source] A miner reading this code correctly is optimising to clear an auction's minimum cluster size, stay attested, and fill an auction that still sits under its card target — not to serve any particular quality of confidential compute once it is in.

Do validators do anything besides validate?

Not by running a second business of their own, as far as this course's pinned source shows — no billing logic, no customer-facing endpoint, and no inference execution appear in the validator code itself. But a validator here does not independently decide two things a judge normally would: what counts as genuine hardware, and what an auction is currently worth. Both come from Tower, at a single URL — https://tower.targon.com — compiled into the validator as a constant. [source] Every interval, the validator asks that same service for the current auction targets, prices, caps, and burn-key split, and uses whatever it returns. [source] The installer that provisions a mining node is built the same way: it "validates hardware against tower.targon.com," and that endpoint "is pinned inside the signed installer and cannot be pointed elsewhere." [source] A validator here is a genuine, independent judge of whether a specific node's attestation checks out — but the rules it is judging by, and the service that tells it whether hardware is real, both live behind one address this subnet's own team runs, not behind anything a validator computes or verifies on its own. Manifold Inc, the organisation behind Targon, also publishes Hone (netuid 5, elsewhere in this batch) under the same account. [source] [source]

Why it earns

Cross-subnet emission runs on one formula, the same for every subnet: each one's share is its own moving-average alpha price, discounted by a miner-burn penalty, against the same figure summed across every other subnet. [source] [source]

share_i = p_i × (1 − b_i) / Σ_j p_j × (1 − b_j)

[source] [source] Mechanism quality has no other route into that number — it can only move a subnet's share by first moving its price relative to every other subnet's. Targon's auction-and-attestation design is real, running code, checkable against this source. What it is not, on the evidence this course can cite, is an explanation for Targon's current standing: its measured share is 0.0% @ 8878789, and this lesson's evidence traces that number back to relative price, never to mechanism quality directly. Targon's alpha trades at 0.05509598 @ 8878789 TAO, down -2.572375969475591 @ 8878789% over the trailing week; 8103 @ 8878789 wallets still hold it. A large legacy holder base does nothing on its own to restore a share once relative price has moved on — that is what the formula above says, on its own terms.

What to copy, what to avoid

Copying: burning an auction's unclaimed pool instead of handing it to whoever else happens to be present is a genuine defence against a thin field capturing pay it did not earn. [source] Re-verifying hardware every interval, and refusing a duplicate node identifier outright, closes an obvious double-counting attack for the sliver of the system it covers. [source] [source]

Avoiding: routing both "what counts as real hardware" and "what an auction currently pays" through one hardcoded address run by the subnet's own owner is a single point of trust sitting underneath an otherwise cryptographic design — and it is worth noticing precisely because the rest of the system is built to a much higher standard. A large legacy holder base is also not a reserve of future emission: Targon holds the 2 @ 8878789-highest holder count this course tracks while earning a measured 0.0% @ 8878789 share.

if auc.MinClusterSize != 0 && auc.MinClusterSize > len(*c.VerifiedNodes[uid][n.IP].GPUCards) {
    c.MinerErrors[uid][n.IP] = fmt.Sprintf("Node reporting %d cards, %d required", ...)
    continue
}
cards := 1
if auc.MinClusterSize != 0 {
    cards = len(*c.VerifiedNodes[uid][n.IP].GPUCards)
}

pool := aucInfo.TargetPrice * aucInfo.TargetCards
perMiner := min(pool/nodes, aucInfo.MaxPrice)
minerIncentive := (float64(perMiner) * 1.2 * float64(bid.Count)) / (*c.EmissionPool * 100)