All verified runs, ranked by server-observed proving rate.

• proofs_per_sec — k / server-observed window; the ranked, trustless rate (a lower bound)
• self_reported_pps — k / client-reported elapsed time; informational only
• est_nock_per_day, network_share — economics estimates, present when configured

curl https://nockmark.xyz/leaderboard

One verified run by id, same shape as a leaderboard entry.

curl https://nockmark.xyz/runs/1

Current network difficulty (expected proof attempts per block, auto-refreshed from the chain), block reward, and the estimated whole-network proving rate. Pass ?pps= to price a rate of your own.

curl 'https://nockmark.xyz/economics?pps=0.22'

Difficulty over time as [unix_secs, difficulty] pairs, oldest first, thinned to ≤ 1000 points. ?hours= bounds the lookback (default 168, max 2160).

curl 'https://nockmark.xyz/economics/history?hours=720'

Mint a proving challenge. Returns the nonce to prove against, k (proofs required), pow_len, and the nonce derivation rule. The ranked rate is measured from this moment to submission, server-side.

curl -X POST https://nockmark.xyz/challenge

Submit k base64-jammed STARK proofs for a challenge. Every proof is checked (challenge binding, then full verification) before anything is recorded; the practical path is the one-liner on the board, which mints, proves, and submits for you.

• nonce, proofs[k] — the challenge and its proofs
• hardware, prover_version — self-described labels (rates are not self-described)
• elapsed_ms — client-measured proving time; displayed, never ranked

tock bench --kernel assets/miner.jam \
  --submit https://nockmark.xyz

What these rates cover. The AI track grinds the canonical block shape, and the GPU rows are behind upstream: they use the generic CUDA kernel at the nockchain commit this registry pins, and two days after that pin upstream made a peak kernel the production default — the same card on the same statement goes from 0.19 to 335 TMAC/s, about 1,700x. Read the GPU rows as a floor for the hardware; a re-pin and re-run is pending. Nockchain also admits mining inside real model inference, at throughput comparable to the optimised dedicated kernel — the notable part being that the compute is dual-use, not that it is faster. The ZK track is CPU-only for a different reason: its GPU provers are closed source and report unverifiable pool units, so they are absent rather than taken on trust.

Mint an AI-PoW challenge for the Logos puzzle (INT8 tiled matmul + recursive STARK certificate). Returns the kernel-minted nonce, the 32-byte challenge derived from it (blake3("nockmark-ai-v1" ‖ nonce_le8)), the jackpot target T_b, k (wins required), the fixed params, the statement, and the grind rule.

?statement= selects which AI-PoW statement to be challenged on. It defaults to dense, so a request without it means exactly what it always did.

• dense — the single-tile statement (m=8, k=1024, n=8, noise_rank=64, tile=8), matrices seeded from the challenge. Grind rule extranonce-le8-v1: attempts are extranonces 0, 1, 2, … encoded as 8 little-endian bytes, and a win is jackpot ≤ target, unscaled.
• canonical-moe — the canonical MoE (GROUPED_GEMM) block the production gateway-free miner submits, and the one the upcoming CUDA backend accelerates: m=64, k=1024, n=64, noise_rank=64, tile=8, with hw=8, e=2, top_k=1. The challenge binds through the Pearl header's aux commitment. Grind rule canonical-ordinal-v3: attempts are u32 ordinals 0, 1, 2, … that offset the header timestamp — not an 8-byte nonce. A win is jackpot ≤ target × F with F = 2¹⁶, so the same 32-byte target means F times less grinding here than on the dense statement. The response says so explicitly: params.shape_work_factor and params.target_is_scaled_by_shape_work_factor.

?attempts= requests a difficulty tier: the expected grind attempts per win you want to be targeted at. The server derives the target from it — respecting each statement's own semantics, so the same tier is a different 32 bytes on dense and on canonical-moe — and echoes the granted value back as attempts. Clients still read target; omitting the parameter reproduces the previous behaviour exactly, target and response alike.

• Rounded to the nearest power of two internally, so the target is a single set bit and tier → target → score round-trips exactly and reproducibly.
• Clamped to [2¹², 2³⁰]; compare the echoed attempts against what you asked for to see the clamp. The ceiling is the challenge expiry: at ~3 M attempts/s, 2³⁰ is ~6 min of grinding per win, and a challenge goes stale 1 h after it is minted.

Why letting the client choose cannot inflate a rate. The ranked figure divides real MAC-equivalents by a window this server observed, and a tier only changes how much of that window is grinding rather than the fixed ~25 s-per-win of certificate proving: an easy tier earns less credit against that same fixed overhead and therefore scores lower, so there is nothing to gain by asking for one. A hard tier cannot lift a machine above its true throughput either, because every attempt it is credited for is genuinely performed — the credit is exactly the expected attempts at the target the wins were verified against, and a win only exists if a jackpot really cleared it.

curl -X POST 'https://nockmark.xyz/challenge?track=ai&statement=canonical-moe&attempts=1048576'

Submit k jackpot wins. Each win's certificate is verified end-to-end before anything is recorded: statement re-derived from (challenge, extranonce) — matrices re-synthesized, every public input re-checked, HASH_JACKPOT ≤ target — then the compact STARK verify against the server's own setup.

• nonce — the challenge's nonce (decimal string)
• statement — dense (default when absent) or canonical-moe; picks the verify rules, the target and the blob format
• wins[k] — {extranonce, cert_b64}, strictly ascending (ground 0, 1, 2, …). For canonical-moe the field carries the u32 ordinal.
• hardware, prover_version — self-described labels (rates are not self-described)
• grind_elapsed_ms — client-measured grind window (proving excluded); displayed, never ranked

For canonical-moe the submission carries nothing but the certificate and its public inputs: the whole statement — Pearl header, mining config, matrix commitments, routing, opened indices, jackpot — is re-derived here from (challenge, ordinal) and the jackpot is gated at target × F before the compact STARK verify.

tock ai-bench --statement canonical-moe --submit https://nockmark.xyz

Both statements rank on this one board, by verified_mac_per_sec_lb. They share it because MAC-equivalents is precisely the unit consensus uses to compare AI work of different shapes: expected MAC-equivalents per block is 2^256 / T whatever tile shape the miner picked, which is what makes the AI puzzle's fork-choice weight meaningful in the first place. Each attempt is F = 2¹⁶ MAC-equivalents (an 8×8 tile over k=1024) on both statements; what differs is the attempt count, because the target semantics differ — 2^256/(T+1) for dense, 2^256/(T·F+1) for canonical-moe. Every row carries its own statement and its own target, so a re-calibration cannot rewrite how an older row was scored.

• statement — dense or canonical-moe
• expected_attempts_per_win — the difficulty tier this run was measured at, derived from its own stored target (so rows from before tiers existed carry it too). A tighter lower bound comes with a harder tier, because more of the window was grinding and less of it proving.
• verified_mac_per_sec_lb — k · attempts-per-win · 2^16 / server window (issue → submit, proving included); the ranked lower bound
• grind_mac_per_sec — same numerator over the client grind window; informational only
• zk_attempt_equiv_per_sec — MAC/s ÷ 25.75e9, the consensus MAC↔ZK-attempt exchange rate
• sigma_frac — ±1σ as a fraction of the rate (k wins is Poisson: 1/√k)

Runs are era-labeled by prover_version. Entries proved before pin c8d6b13e used the pre-Pearl-V3 statement, whose AIR was later hardened upstream (urange8 lookup fix). Cross-era rate comparisons are fine — the workload cost is the same — but era-1 certificates were verified under the older constraint system.

curl 'https://nockmark.xyz/leaderboard?track=ai'

The two POST routes are rate-limited per IP. Over-limit responses carry a Retry-After header and {"retry_after_secs": …} in the body — sleep that long and retry.