Question 1

What models can miners serve on SN53 right now?

Accepted Answer

Qwen3.6-35B-A3B (FP8 quantization) is open for mining. GLM-5.2 (753B / 40B-active MoE, NVFP4) is running on first-party clusters and will open to miners later. Both have published Merkle roots pinning the exact architecture and quantization.

Question 2

How much GPU hardware do I need to serve Qwen3.6-35B?

Accepted Answer

The model fits on 2× RTX 4090, a single RTX 4090-48G with tensor parallelism, a single L40S, or any datacenter card with 48 GB+ of memory (H100, H200, B200). A single 4090 can run it with careful memory management. The documentation includes a reference config for 4× RTX 4090 serving ~4,500 tokens/sec at 128 concurrent users.

Question 3

What is TOPLOC and how does it prove the model is real?

Accepted Answer

TOPLOC is a locality-sensitive hash of the final hidden states from a forward pass. Every response carries a TOPLOC fingerprint computed from the model's actual activations—at zero extra GPU cost, as an async tee off the response path. Validators with the canonical checkpoint re-run the prompt and compare their top-k activations against the miner's commitment. Using a cheaper quantization or different model produces a measurably different fingerprint, so cheating is separable from honest serving across mixed hardware.

Question 4

Do I need to modify my inference code to use the engy miner?

Accepted Answer

No. The miner is a single Python module (engy_miner.py) that wraps your sglang serve, tokenizes locally, reads the model's hidden states from the serve's HTTP response, builds the proof, and returns it to the buyer over the same websocket. One process does everything; no local HTTP endpoint needed. The serve itself requires only the `--enable-return-hidden-states` flag.

Question 5

What do validators do and how much do they earn?

Accepted Answer

Validators sync a master-signed epoch result from provider.engy.ai, verify the sr25519 signature, resolve hotkeys to on-chain UIDs, and submit the weight vector on chain every ~100 blocks to stay inside Yuma consensus's activity window. They run CPU-only (no GPU, no model weights, no database) and earn dividends proportional to the weight they submit. Light validators are one of two roles; the master validator (engy-operated) performs the actual sampling audits.

Question 6

What happens if my miner goes offline or serves the wrong model?

Accepted Answer

New miners are probed with synthetic traffic before they receive production requests—they must prove correct serving and a valid TOPLOC fingerprint before becoming active. Active miners are continuously monitored; any that fail acceptance, latency, or cheat checks are pulled from serving within about a minute and must re-prove themselves. A cheat verdict (> 1% of audits) zeroes your epoch score; other failures lose that epoch and recover the next one.

Question 7

How is scoring calculated and how often are weights set on chain?

Accepted Answer

Scoring is per (miner, model) per epoch: `floor(sum of tokens served × score_rate[model] / 1000)`, multiplied by a gate that is 0 or 1 depending on acceptance rate, latency, and audit results. Only paid requests that returned 200 count. Weights are submitted to netuid 53 roughly every 24 hours in production (more frequently in early stages) and resubmitted every 100 blocks to keep validators inside consensus membership.

Question 8

What happens during an epoch rollover or provider outage?

Accepted Answer

Validators cache the last vector they submitted. If a new epoch payload fails to verify or the provider is unreachable, they resubmit the cached vector on the same 100-block cadence, so a multi-hour outage does not drop them out of consensus. When the provider recovers with a fresh epoch, the new vector is applied immediately and replaces the cache.

engy

engy

Hardware Requirements

Hardware Requirements

Miner Setup

Validator Setup

Participate

Participate

Hardware Requirements

Hardware Requirements

Miner Setup

Validator Setup