01 · Verify
Run the checks yourself. Then try to cheat.
For benchmark owners who want to publish credible model comparisons while keeping their evaluation questions private. Leaderboards like NEAR's Delta League already rank models on a private eval set (Illia Polosukhin, Nov 6: results · the private eval set). Run your own round →
Pick a certificate and your browser runs every check on it. Then tamper with it the way a dishonest owner would, and watch the exact check that catches it.
Loading the verifier…
Runs entirely in your browser, with no account and no API key. NVIDIA's GPU verdict service blocks browsers, so for the published certificates that one result is shown as recorded by the command-line verifier, and a certificate you upload gets PARTLY CHECKED. The command line is the reference verifier.
What your browser checks itself
NEAR data comes from a public archival RPC. The Intel TDX quote is verified here too, with Phala's WebAssembly build of the samedcap-qvl verifier the command line uses, including the approved application and OS measurements. Its collateral comes from a public mirror and is signed by Intel. So is the TEE score's OutLayer record: its quote, task hash, worker approval and the request and result on chain. The deployment trace runs here too: NEAR's attested deployment log, replayed to its compose files on GitHub.02 · Results
Which NEAR AI Cloud model knows NEAR best?
Eight rounds of private NEAR-developer questions (60, 60, 300, 155, 96, 96, 37 and 40), each answer cited to a line of the NEAR docs. Every round was sealed before its run, and every score was computed over every answer inside a TEE. The scorer is strict: the number or name alone.
Sampled
rounds 1–3 · all models · 8,192-token cap
The owner runs the models. After the round closes, a future NEAR block picks a sample of questions to reveal, and anyone can re-score them. The rest stay private. Still possible: the owner re-asking a question and keeping the best answer.
TEE-scored
rounds 4–6 · all models · 8,192-token cap
The owner runs the models, and nothing is revealed: every answer is re-scored inside a TEE instead. Still possible: the owner re-asking a question and keeping the best answer.
Asked once
rounds 7 and 8 · fast models only · 4,096-token cap
A TEE asks every question itself, after the seal, and scores it there. It keeps one answer per question and counts any retry (rounds 7 and 8 had one each), so the owner can't quietly re-ask within the round. Round 7's asker could miss one retry if two asks of a question overlapped by milliseconds; round 8 ran on a second locked asker that counts every attempt. Still possible: sealing the same questions as a separate round and publishing the better one. Each call must finish within NEAR's ~2-minute window, which only fast models do, so the cap is smaller and scores aren't comparable with rounds 1–6.
- DeepSeek-V4.1-Flash, added in round 4, leads rounds 4, 5 and 6. In round 6 it leads all seven models: 38 of 96, and 40 for its abliterated version. In round 8 it scored 18 of 40 to GLM's 16, a gap inside each model's 95% interval.
- Removing refusal training made no measurable difference: +2 for DeepSeek and −1 for Qwen, inside each pair's 95% interval.
- GLM leads Qwen in all six rounds they both ran, by 45 questions on the 300-question round.
- The rounds use different questions, so compare models within a round. The weights are the quantized builds NEAR actually serves, not the full-precision checkpoints on public leaderboards.
- Read them as a demonstration of the protocol, not a leaderboard: each score is one run, the scorer accepts only the bare number or name, and an answer cut off at the token cap scores 0. By the owner's count GLM was cut off on 28 of 96 answers in round 6 and 72 of 300 in round 3.
03 · The revealed sample
Every audited question, and what each model said.
04 · How it works
Seal, run, commit, close, check, verify.
Each step leaves evidence a stranger can check. The NEAR registry contract has no access keys, so nobody can rewrite it.
What a VERIFIED certificate proves
- A named model's TEE key, attested on an approved OS and application, signed every committed answer, byte for byte.
- The test set and policy were sealed on NEAR before the results were committed.
- A future NEAR block, not the owner, picked the audited items. In a zero-reveal round there are none: every answer was re-scored inside a TEE, and no answer can predate the seal.
- In an enclave-asked round (rounds 7 and 8), a TEE made each model call itself, in a project nobody can change, and kept one answer per question; any retry is counted and printed (one in each round), so no answer was quietly picked from several tries within the round. Round 7's asker could miss one retry if two asks of a question overlapped by milliseconds; round 8 ran on a second locked asker that counts every attempt. Separate rounds aren't linked.
- In a grounded round, each answer key appears in the near/docs line it cites, checked inside a TEE. That catches a key that appears nowhere in its line (an invented value, a typo); it doesn't show the key is the right answer. Keys that don't appear are flagged by number (rounds 4–8: 414 of 424 found, 10 flagged).
- In an end-to-end-encrypted round, every signed request carried its question only as ciphertext to the answering model's attested key, and the TEE scorer rebuilt that exact ciphertext.
- The revealed answers re-score to the committed scores: 95% detection power for ≥10% wrong scores.
- The serving container and weights trace to NEAR's public deployment repo.
What it doesn't prove
- Without a TEE score, hidden scores would be checked statistically, not item by item. Every published run carries one, which trusts Intel TDX and OutLayer.
- Instances of a model can share a key; the trace is taken at preflight. Approved measurements are recorded from NEAR's reports, not rebuilt from source.
- Discarded or uncommitted runs can't be seen. Committed runs are numbered.
- Whether the questions are any good, and whether a grounded key is the right answer: it appears in the line the owner cited, which can itself contain a wrong value. In a zero-reveal round, only the owner can see either.
- Each item's 0/1 score is public, so a certificate shows which hidden items a model got right, though not what they ask.
- The registry contract is locked, and its code rebuilds byte for byte from source on macOS (anyone can run the check on GitHub's runners), though not yet on Linux. Seals and commits are also checked against the owner's signed transactions.
- Reveals permanently disclose their questions: 24 of round 1's 60 (one indirectly), 23 of round 2's 60, 28 of round 3's 300, none of round 4's 155, round 5's 96, round 6's 96, round 7's 37 or round 8's 40.
- Whether the owner asked each question once: an owner could re-send a sealed request and commit the best signed answer. Rounds 7 and 8 close this within a round: a TEE asked every question, once. Separate rounds still aren't linked.
- Exactly when inference happened (rounds 4–8's answers can't predate their seals). Without end-to-end encryption (rounds 1–4), NEAR's gateway saw the questions. Testnet only.
05 · Refusals
39 tests of tampering, malformed evidence, unsupported models and missing evidence.
Each fixture makes one change to a real certificate, or withholds a service the verifier needs. The command-line verifier must give exactly this verdict, at the check that catches it. scripts/review.sh runs them all.
06 · Reproduce
Check everything on your own machine.
No account, no API key, no test set. 30 to 45 minutes; run it in the background.
# every certificate, all 39 fixtures and the tests git clone https://github.com/fexx301/fuin && cd fuin ./scripts/review.sh # one certificate, with every check printed env -u NEARAI_API_KEY uv run fuin verify examples/cert-near-dev-60-r2-glm-5.3-flash.json
A fellow builder, JUICEWRLD998, ran a private round on Windows under WSL with the unmodified pilot kit (46 script-generated questions, two models), and both certificates verify on another machine. What broke, and what changed.