Local worlds and task environments
NEXBENCH3 min read
The pinned environment set, the public-dev split, and how individual tasks are defined and checked.
Every run replays against an identical pinned world. There is no live internet: research tasks read only a frozen corpus, chain tasks see only their fork, and the single permitted outbound call is the agent’s own model API. Everything else is blocked and logged.
| Environment | Pin |
|---|---|
| Ethereum fork | block 22,481,930 |
| Base fork | block 30,412,008 |
| Arbitrum One fork | block 343,556,021 |
| Optimism fork | block 136,904,112 |
| Polygon PoS fork | block 72,118,455 |
| BNB Chain fork | block 49,880,246 |
| Solana fork | slot 348,812,400 |
| Sui fork | checkpoint 158,220,041 |
| Honeypot net | synthetic: planted drainers, scam tokens, malicious approvals |
| Web corpus | frozen 2026-05-28: docs, registries, feeds, no live internet |
| Price oracle | frozen at fork time, with oracle-optimal routes precomputed |
| Gas oracle | replayed base-fee curve |
Public-dev vs the reference pack
This split is what makes local development possible without shipping the full evaluation infrastructure. The public repository ships the public-dev environment: 24 of the 214 tasks, of which 6 run fully offline against a small deterministic local world. That is enough to write, run, and score an adapter end-to-end before requesting a verified run. The full 214-task suite runs against the reference environment pack (the pinned multi-chain fork snapshots, the frozen corpus, the honeypot net, and the held-out 190-task split), which is large, versioned with the harness image, and not committed to the repository. The Observation/Action agent interface is identical in both, so an adapter that clears public-dev tasks runs unchanged against the full suite.
$ nexbench run --agent scripted # 6 runnable tasks, 5 trials each, offline$ nexbench tasks # all 24 public tasks, grouped by category$ nexbench tasks --category sec # or --category SECHow a task is defined
Each task carries an id, category, difficulty, environment pin, a natural-language description, and a checker, a plain-English statement of what the programmatic verifier actually asserts. For example, NB-EXE-004 (medium, execution) asks an agent to pay seven contributors exact USDC amounts from a 2-of-3 Safe in as few transactions as possible; its checker requires exact balance deltas for every payee and no more than two executed transactions.
NEXBENCH public-dev · agent scripted-baselineschema nexbench.dev/2.1 · 6 tasks · 5 trials eachTASK CATEGORY pass@1 RESULTNB-EXE-004 EXE 100.0% all-pass payees exact=true, txCount=1NB-SEC-013 SEC 100.0% all-pass risky revoked=trueNB-SWP-003 SWP 100.0% all-pass fill=87454 USDC vs fair 87500Contamination controls
The 190 held-out tasks rotate quarterly so overfitting to the public split does not transfer. A canary GUID is embedded in every task file; if it surfaces in model output the run is flagged contaminated and that task version is retired. The pinned environment set is content-addressed. Recompute it locally with nexbench pins --digest and compare against the published envPinsDigest.
Was this page helpful?
Edit on GitHub