AGENTS.md — nookplot-bot

Operational notes for any agent (human or AI) working in this repo. Much of this file is the ORIGINAL OPERATOR'S live journal — months of gateway quirks, economics analyses, and dated experiments. Treat dated entries as historical context, not current instructions; the README and docs/ are the curated path.

Operator-private material (wallet/tx/balance snapshots, named-agent assessments, unfiled bugs) lives in AGENTS.local.md, which is gitignored and never published. Passages here that reference it were moved there. Captures how the project was set up, what we learned, and where the official docs were thin or contradicted reality.

⚠ Pre-flight checklist (READ BEFORE WRITING CODE)

The Nookplot SDK is ahead of the gateway (SDK 0.5.130 vs gateway 0.5.32 as of 2026-05-22). The gateway also evolves. Don't trust your memory or training data — probe before coding. For ANY task touching a gateway endpoint, model shape, or new track, run the relevant probe first.

Self-observations: once the bot has run, src/observe.ts writes a local (gitignored) OBSERVATIONS.md with current "patterns worth attention" and proposed file:section changes — auto-pruned to the last 7 days, top 10 by confidence. A fresh clone won't have it yet; check it before tuning a track once your agent has some history.

Sources of truth (in priority order)

Endpoint status (re-probe with npm run forge:watch)

Last probed 2026-05-22:

When the docs lie

The Nookplot CLI's quickstart, the old Mintlify docs (410 Gone), and the gateway's /skill.md endpoint have all given us bad info at various points. Default ranking: SDK source > gateway probe > our own past code > public docs.

What this is

A local TypeScript bot for the Nookplot Agent Coordination Protocol (decentralized coordination layer for AI agents on Base / Ethereum L2). Registers an ERC-8004 on-chain identity, opens a persistent WebSocket to gateway.nookplot.com, scans for opportunities, and (eventually) acts on them.

Agent: nookplot-bot (your ERC-8004 ID is assigned at registration; address in .env).

Stack

• Runtime: Node.js 20+ (tested on 24.11.1), npm 11
• Language: TypeScript (ESM, tsx for dev)
• SDKs: @nookplot/runtime (0.5.x), @nookplot/cli (0.7.x)
• Network: Base mainnet (chain ID 8453), gateway https://gateway.nookplot.com
• OS tested: macOS (darwin)

File layout

nookplot-bot/
├── AGENTS.md                  ← this file
├── README.md                  ← user-facing quickstart
├── .env                       ← real credentials, mode 600, gitignored
├── .env.example               ← template (safe to commit)
├── .gitignore
├── nookplot.yaml              ← CLI config (knowledge.sources → public-knowledge-folder/)
├── skills.yaml                ← declarative skill listings (5 skills, synced on-chain)
├── package.json
├── tsconfig.json
├── public-knowledge-folder/   ← knowledge graph source (md/txt → nookplot sync)
│   └── nookplot-bot-profile.md
└── src/
    ├── runtime.ts             ← env loader + NookplotRuntime factory
    ├── smoke.ts               ← connect + identity check, no writes
    ├── index.ts               ← orchestrator: bounty lifecycle + verification poller + knowledge publish + reward loop + events
    ├── research.ts            ← web/arxiv/github search + URL fetch (Brave → Tavily → DuckDuckGo fallback chain)
    ├── refine.ts              ← two-pass draft → critique → revise generator
    ├── creator-profile.ts     ← inspects creator's past approved applications to tune our pitch
    ├── vault.ts               ← Obsidian-compatible knowledge-vault read/write/search
    ├── dashboard.ts           ← `npm run dashboard` — credits, applications, knowledge, verifications, vault stats
    ├── ab-stats.ts            ← A/B variant performance report (`npm run ab-stats`) — bounty apps only
    ├── mining-stats.ts        ← mining performance by model (`npm run mining-stats [--24h|--7d]`)
    ├── mining.ts              ← challenge discovery + solve + submit (verifiable + standard traces)
    ├── guild.ts               ← one-shot mining-guild auto-join on boot (idempotent; BOT_AUTO_JOIN_GUILD=0 to disable)
    ├── venice.ts              ← direct Venice chat helper
    ├── venice-smoke.ts        ← direct Venice smoke test
    ├── proxy.ts               ← local Venice proxy + strategy injection
    └── knowledge-probe.ts     ← preview what `nookplot sync` would publish

Setup recipe (reproducible)

1. Fix npm global prefix so npm install -g never needs sudo:

   mkdir -p ~/.npm-global
   npm config set prefix ~/.npm-global
   echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.zshrc
   exec $SHELL

2. Install CLI: npm install -g @nookplot/cli
3. Scaffold: project files were hand-written (see Gotchas §1).
4. Install deps: npm install
5. Register agent:

   NOOKPLOT_API_KEY=nk_placeholder_for_register \
   NOOKPLOT_GATEWAY_URL=https://gateway.nookplot.com \
   nookplot register --non-interactive \
     --name "nookplot-bot" \
     --description "Local research/contribution bot"

   Writes real NOOKPLOT_API_KEY, NOOKPLOT_AGENT_PRIVATE_KEY, NOOKPLOT_AGENT_ADDRESS, NOOKPLOT_GATEWAY_URL to .env (mode 600).
6. Verify: nookplot connect and npm run smoke.

Gotchas (what cost us time)

1. CLI create-agent is broken in 0.7.26

nookplot create-agent my-bot --lang ts --template research
→ Template 'ts-research' not found at .../templates/ts-research

The templates/ directory is missing from the published npm package for both starter and research. We bypassed by writing package.json + tsconfig.json + src/* by hand.

Where docs misled: CLI Commands docs list create-agent as the recommended scaffold path. It doesn't work.

2. nookplot register requires an API key it's about to create

validateConfig() (in config.js) checks for NOOKPLOT_API_KEY before any command runs — including register, which exists to mint that key. Workaround: pass a placeholder env var:

NOOKPLOT_API_KEY=nk_placeholder_for_register nookplot register ...

The placeholder is never sent to the gateway; register generates a real one and overwrites .env.

3. Old Mintlify docs are 410 Gone

Several search results point to mintlify.com/nookprotocol/nookplot/... URLs that now return 410 Gone. The canonical sources are:

• https://nookplot.com/docs
• https://nookplot.com/SKILL.md
• https://nookplot.com/llms.txt
• https://github.com/nookprotocol/nookplot

Treat Mintlify URLs as stale; cross-check against SKILL.md.

4. Runtime API names don't match the quickstart examples

Quickstart docs show:

await runtime.proactive.scanOpportunities({ minReward: 100, tags: [...] });

The real @nookplot/runtime@0.5.130 API is event-driven, not poll-based:

runtime.proactive.onOpportunities((event) => { /* ... */ });
runtime.events.subscribe("proactive.opportunities", handler);

There's no scanOpportunities. Scanning is configured server-side via runtime.proactive.updateSettings(...) and opportunities are pushed over the WebSocket. We had to grep node_modules/@nookplot/runtime/dist/*.d.ts to find the real surface.

5. Event name in docs vs runtime

Docs say mention.received. The runtime type union has just "mention". Use the names in RuntimeEventType (in dist/types.d.ts) as the source of truth.

6. Env var names: CLI vs docs

Docs show AGENT_PRIVATE_KEY. The CLI's register writes NOOKPLOT_AGENT_PRIVATE_KEY + NOOKPLOT_AGENT_ADDRESS. We support both in src/runtime.ts (CLI names take priority).

7. Earning has stake gates the docs underplay

Update (2026-05-22, original operator's journal): that agent reached Tier 3 with the 1.75x mining multiplier. Active earning tracks:

Old gate notes:

Registration output spells it out clearly, but the public docs gloss over it:

• Verifications — no stake, best entry point.
• Citations — passive, earn when others cite your knowledge.
• Mining — requires Tier 1 stake = 9M NOOK to earn from the mining pool. Unstaked agents earn reputation only.
• Bounties — USDC, no stake.

Plan around verifications + citations + bounties until you have stake.

8. DIEM is not a separate inference API

"DIEM API" in the Venice context means Venice's DIEM staking/credit layer: stake/buy DIEM → receive Venice inference credits → call the same Venice OpenAI-compatible endpoint:

https://api.venice.ai/api/v1/chat/completions

Use VENICE_API_KEY for auth. DIEM affects billing/credits, not the request URL or SDK shape.

9. Nookplot gateway BYOK is not the Venice path

nookplot credits byok exists:

nookplot credits byok list
nookplot credits byok add <provider> --key <key>
nookplot credits byok remove <provider>

Installed CLI docs/examples only mention anthropic and openai as providers. We did not verify a supported venice provider for gateway BYOK. For Venice, use the local agent API hook instead:

NOOKPLOT_AGENT_API_URL=http://127.0.0.1:18790/v1/chat/completions
NOOKPLOT_AGENT_API_FORMAT=openai
NOOKPLOT_AGENT_API_MODEL=grok-4-3

10. Direct Venice URL is flaky for nookplot online start

The CLI detects an agent API by POSTing a 2-second ping to the configured URL. Venice's authenticated/x402 endpoint can take >2 seconds or return a payment/auth envelope, so detection is flaky when pointing directly at:

https://api.venice.ai/api/v1/chat/completions

Fix: run src/proxy.ts locally. It responds instantly to Nookplot's ping, then forwards real OpenAI-compatible chat completions to Venice with the stored VENICE_API_KEY.

11. Do not pass --agent-api as a CLI flag to online:start

In @nookplot/cli@0.7.26, passing --agent-api caused the detached child daemon to be spawned with arguments in an order that exits immediately before logging. Symptom: parent prints Online (PID ...), then nookplot online status says Offline, with no fresh daemon logs.

Working fix: source .env and let NOOKPLOT_AGENT_API_URL propagate via

"online:start": "set -a && . ./.env && set +a && nookplot online start"

This produces a stable daemon:

Online (PID ...)
Agent API active: http://127.0.0.1:18790/v1/chat/completions
Reactive mode started

12. Trace summary has a server-side specificity gate (not just length)

Gateway 400s with traceSummary specificity score N/100 (threshold 35) if the summary is generic prose. The scorer counts six categories: numbers, technique names (camelCase / "quoted"), comparisons (vs / better than), code (backticks / file.ext), failures (fails / breaks / pitfall), actionable verbs (use / avoid / prefer). Hitting ≥3 categories usually clears 35/100.

Fix lives in src/mining.ts:padTraceSummary — it now mirrors the gateway scorer locally, and if the LLM's summary is generic it splices tokens (numbers, backticked identifiers, "vs" phrases) extracted from the actual trace/solution content. All four solver call sites pass the source content as the third arg.

13. "solver produced no output" = AbortSignal timeout, not model failure

Originally diagnosed as gpt-55 burning the token budget on internal reasoning at xhigh. Real cause (from _probe-models.ts / _probe-heavy.ts 2026-05-24): all 5 models produce valid traces at xhigh, but with real mining context (~5KB system + 3-5KB user context) slow models can take 200+ seconds — exceeding our then-240s timeout. The AbortSignal fired mid-response and we logged "no output."

Current fix: src/mining.ts:solveStandardTrace runs with max_tokens: 40000, timeoutMs: 1_000_000. All models at all efforts work. The MODEL_EFFORT map in src/models.ts keeps every model at xhigh.

Check perf with npm run mining-stats -- --24h. If a model still underperforms ≥20pp vs the best on n≥10 each, the tool prints a recommendation to remove it from A_B_POOL["mining_solve"].

14. Diversity-cap and queue order on verifications

Gateway 429s with verified this solver 3+ times in 14 days. Our pre-skip in src/index.ts:recentSolverVerifyCount uses a rolling 14d window (matches gateway) so the cap auto-resets — no manual reset needed.

What still matters is queue order: pollVerifiableSubmissions now sorts by least-prior-verified solver first, so when a few solvers dominate the queue we exhaust new solvers before hitting their caps. This roughly doubled useful verifications per poll in observed data (prior conversion ~5% per OBSERVATIONS.md #5).

15. Mining-guild auto-join on boot

src/guild.ts:ensureGuildMembership runs once after connect:

1. GET /v1/mining/my-guild/:addr — if already a member, returns the guildId.
2. Otherwise GET /v1/mining/guilds/joinable?limit=20, ranks by boost × 10 + domain-overlap + member-count × 0.05 (boost dominates because tier multipliers apply to every solve, not just guild-exclusives).
3. POST /v1/mining/guild/:id/join with declared domains (override via BOT_MINING_DOMAINS=tag1,tag2,...).
4. Returns guildId — src/index.ts stores it in myGuildId and threads it into every mining submission so we earn the boost.

Removing membership requires nookplot_leave_guild_mining (self), a vote-kick (≥3 members, ALL other members must vote yes), or force-removal on unstake/admin. There is no inactivity-based auto-kick — going offline is safe. The 6-member-per-pool cap means popular guilds fill; the auto-join picks the highest-boost guild with an open slot regardless of fit (boost dominates the ranking).

When fix #15 first ran we joined #100002 "SatsAgent Mining Collective" at tier 0 (1.0× boost, 0/6 domain overlap, 4/6 members). To upgrade, either stake into the guild's combined pool to unlock tier 1 (9M NOOK / 1.35×) or leave + re-discover when better-fit guilds appear.

Side-effect: src/mining.ts:loadCaches(inGuild) now retries previously- skipped guild-exclusive challenges after we join, since the permanent skip no longer applies.

16. What "domain" actually means on Nookplot

Domains are free-form string tags — there's no canonical enum. They appear in four places, with different governance:

Our verified expertise (/v1/contributions/:addr, last probed 2026-05-24): research (0.50 conf, 16 ev), distributed-systems (0.25, 14), algorithms (0.20, 11), machine-learning (0.18, 10), sybil-detection (0.18, 10), data-structures (0.18, 10). Everything else in our capabilities list is self-reported (verificationLevel: "self_reported", evidence 0) — those don't actually influence challenge ranking.

Authorship rights (GET /v1/mining/authorship/:addr) unlock at 50+ verified solves in a domain and let you author challenges for 10% royalties on every verified trace. We currently have 0 — all our submissions are deferred awaiting 3-verifier quorum. Domain governance is therefore emergent: solve enough in a domain to earn the right to author in it.

Specialization choice: the bot currently solves whatever comes through the pipe (broad CS coverage). If you want to specialize, override at the filter level — src/mining.ts:challengeFitsBudget is where to add a domain allow-list, or set BOT_MINING_DOMAINS to bias guild matching. The broad approach is reasonable while submissions are still mostly deferred; once you have authorship rights in 1-2 domains, narrow there because authorship royalties + tier-1 stake compound.

17a. Daily-cap calibration + spam threshold

Solver epoch cap per nookplot_submit_reasoning_trace docs: 12 regular + 1 guild-exclusive per 24h (raised our DAILY_CAP from 10 → 13). Per-round attempt limit raised 2 → 3 (src/mining.ts). The solver-side floor gates are spec-score (≥35/100 on traceSummary) and per-challenge maxSubmissions.

At tier 3 (1.75×) plus guild boost (currently 1.9×, ~3.3× combined) per GET /v1/mining/stake/:addr, we should always run at the network cap.

17b. Verifier-supply observation (live network state 2026-05-24)

Probed /v1/mining/submissions/verifiable?limit=200: 82/100 submissions in the pool have 0 verifications. 9 have 1. 9 have 2. Zero are at quorum (3 needed). Our own 11 submissions: 0 verifications on 10, 1 verification on the oldest (6.5h). This is a network-wide verifier-supply shortage, not a quality issue with our work. Effective bottleneck: solver supply greatly exceeds verifier supply right now.

Implication: increasing solver throughput won't help payout speed; only the network adding verifier capacity (or lowering the 3-quorum gate) will. We still ramp solving because it builds toward 50-verified-solve authorship rights long-term — and we already verify at the daily max.

The endpoint filters out the caller's own submissions from the pool — when we query as ourselves, we see 0 of ours. Other agents see them.

17c. Inference A/B pool — 5 mining models (2026-05-24)

src/models.ts:A_B_POOL["mining_solve"] expanded from 2 → 5 after probing the live Venice catalog:

At 13/day with even split that's ~2.6 attempts per model per day. The mining-stats tool's auto-recommendation kicks in once n≥5 per arm with a ≥20pp gap. Reach decision quality in ~2-3 days at full rate.

(legacy) labels in ab-stats and mining-stats renamed to (unrecorded — pre-instrumentation) to make clear those rows are just old log entries missing the model field, not deprecated models.

18. Tokenomics — the short version

Daily NOOK emission split (per nookplot_mining_epoch description):

• 70% solver pool
• 5% verifier pool
• 20% guild pool (distributed across active guilds)
• 5% challenge-poster pool

Funded from protocol trading fees (token launches via Clawnch SDK, treasury fees, etc.), with a 2.5M NOOK emergency reserve if the pool runs dry.

Stake tiers (individual, applies on top of per-solve rewards): 1.2× (9M), 1.4× (25M), 1.75× (60M). Sub-9M stakes earn 0 mining rewards — the contract accepts the stake but you're locked out of the pool until you cross 9M. (Confirmed live 2026-05-24 via GET /v1/mining/stake/:addr and node_modules/@nookplot/mcp/dist/tools/onchain.js. The bundled hermes SKILL.md is stale on this — ignore the 3M / 15M numbers there.)

Guild tiers (combined member stake): 1.0× (tier 0, any), 1.35× (9M), 1.6× (25M), 1.9× (60M). Stacks multiplicatively with individual tier.

So the "is this grokipedia on IPFS?" question is roughly yes: solvers produce structured reasoning traces (markdown, IPFS-pinned), verifiers grade them, verified traces emit citable "learnings", and the citation graph + endorsement graph form a knowledge layer. The economic loop closes via NOOK emission funded by trading fees on adjacent token launches — utility of NOOK as a token depends entirely on whether those underlying fee flows scale faster than emission, which is the same question every L2 with a fee-funded incentive program faces.

How to verify the bot is alive

nookplot connect            # gateway + auth ping
nookplot status             # profile, balance, inbox summary
nookplot listen             # tail real-time events
npm run smoke               # SDK-level connect + identity
npm run venice-smoke         # direct Venice / grok-4-3 test
npm run proxy                # local Venice proxy; keep running
npm run online:start         # starts Nookplot daemon using proxy
npm run online:status        # daemon status + recent log
npm run knowledge:probe -- public-knowledge-folder/  # preview knowledge changes
npm run knowledge:sync:dry   # dry-run sync
npm run knowledge:sync       # publish knowledge to the graph
npm run typecheck            # TS sanity

Expected: Authenticated, On-chain: ✓ registered, ERC-8004 ID matches. For the Venice path, expected daemon log includes Agent API active: http://127.0.0.1:18790/v1/chat/completions, and proxy log should show model=grok-4-3.

Going live (dry-run → live)

The bot defaults to DRY_RUN=true (in .env). To enable actions:

1. Read every code path in src/index.ts first.
2. Set DRY_RUN=false in .env.
3. Start npm run proxy (terminal 1), npm run online:start (terminal 2), npm run dev (terminal 3). The third is the actual earner.

What npm run dev does in LIVE mode:

• Every 5 min, scans the gateway's 50 most-recent bounties, filters to Open + deadline-future + creator-not-blocklisted.
• For each, fetches /v1/bounties/:id/applications and looks for ours.
  • No application → fit-eval via Grok; if confidence ≥ 0.6, write a substantive 6-sentence application and POST /apply.
  • Pending → log, wait for creator.
  • Approved → generate the deliverable, publishKnowledge it to the bounty's community to mint a CID, POST /submissions with that CID in deliverableCids.
  • Rejected → cache and skip.
• Every 30 min, economy.getEarnings() → if claimable > 0, claim.

Caches are in-memory only; they rebuild from the gateway on tsx watch restart, so an out-of-process crash is recoverable but app retries cost a few extra GET requests until the lifecycle re-discovers state.

Security

• .env is mode 600 and gitignored. Never commit.
• Private key is non-custodial. Cannot be recovered. Back up to 1Password / hardware wallet.
• Gateway URL is validated to require https:// (or localhost) by the CLI — meta-tx signatures are never sent over plaintext.

Key references

How to earn

Configured priorities (injected via proxy system prompt):

1. Verifications — score reasoning traces, no stake needed.
2. Bounty applications — USDC, apply when brief matches skills.
3. Knowledge publishing — cited downstream → revenue routing.
4. Mining challenges — engage selectively; without stake = reputation only.

Daily workflow:

npm run proxy            # terminal 1 — keep running
npm run online:start     # terminal 2 — start the daemon (one-time per session)
npm run dev              # terminal 3 — optional human-in-loop watcher
nookplot status          # check credits, inbox
nookplot rewards         # check NOOK earnings (epoch-based)
nookplot proactive activity  # what the bot did today
tail -f ~/.nookplot/online.log

Switch the LLM model anytime:

# .env
NOOKPLOT_AGENT_API_MODEL=grok-4-20  # or kimi-k2-6, zai-org-glm-5-1, etc.
# restart proxy + daemon

Open questions

• How aggressively should proactive.updateSettings be tuned? Server-side scanning interval and concurrency aren't documented in the public docs we found — only getSettings / updateSettings shapes in the .d.ts files.
• Production hosting: laptop sleeps kill the WebSocket. Decide between always-on laptop, Mac mini, VPS, or caffeinate -i for short stints.

Mining + NOOK stake

Managed entirely from TypeScript via src/stake.ts — no browser, no MetaMask import. The Nookplot SDK ships gateway-relayed prepare endpoints for the full lifecycle, including a gasless EIP-2612 permit-stake flow.

Token addresses on Base:

Tier thresholds: Tier 1 = 9M NOOK (1.2x), Tier 2 = 25M (1.4x), Tier 3 = 60M (1.75x). Sub-9M stakes still succeed but earn 0 mining rewards until total stake crosses 9M.

CLI (npm run stake -- <command>):

Gateway endpoints used (all sponsored by the relayer):

• POST /v1/prepare/mining/permit-and-stake → preparePermitStakeRelay
• POST /v1/prepare/mining/unstake → prepareSignRelay
• POST /v1/prepare/mining/unstake/cancel
• POST /v1/prepare/mining/unstake/complete
• POST /v1/prepare/mining/claim (optional sourceType)
• POST /v1/prepare/mining/claim-and-stake
• GET /v1/mining/stake/{address} (read)
• GET /v1/mining/stats/agent/{address} (read)

State machine

liquid ──stake──▶ ACTIVE ──request_unstake──▶ COOLDOWN(7d) ──complete──▶ liquid
                    ▲                              │
                    └────────cancel_unstake────────┘

Once any NOOK is staked, the minimum time to get it back to liquid is 7 days. cancel-unstake does NOT return NOOK to your wallet — it only cancels a pending unstake request and returns the NOOK to ACTIVE STAKED. There is no "instant undo" of staking itself. Plan accordingly when deciding test amounts.

Constraints to remember:

• No instant exit. Even a 1-NOOK test stake takes 7 days to fully unwind. The whole 7-day cooldown is what cancel-unstake does NOT shortcut.
• cancel-unstake reverses an unstake request, not the original stake. After cancelling, NOOK is back at ACTIVE STAKED, not in your wallet.
• Cannot unstake while there are submissions pending verification. In practice: pause the bot, let in-flight submissions settle, then request unstake.
• Sweep needs ETH gas. Keep at least ~0.001 ETH on the bot wallet if you ever want to send NOOK back to your custody wallet. The bot has been seeded with ~0.0024 ETH.

Once staked at Tier 1+, enable mining either via nookplot mine (separate process) or runtime.mining.start({tracks:["knowledge"], maxCredits: 1000}) added to src/index.ts. Not yet enabled — pending the user's full 9M stake.

Future plans (parked)

These are good ideas but not built yet.

Aggregation mining (waiting on gateway deploy)

Confirmed via npm run forge:watch on 2026-05-22:

When the aggregation endpoints flip to 200, build src/aggregation.ts following src/mining.ts's shape:

1. list_aggregation_challenges (GET) → pick domains we have edges in
2. get_aggregation_challenge (GET :id) → read input trace summaries
3. forge/data/fetch (POST) → buy the raw traces we need (at Tier 3 we get 35% off — keep budget cap to a few hundred NOOK/run)
4. Synthesize via Claude Opus into KnowledgeAggregateV1 (synthesis, keyInsights, reasoningPatterns, provenance)
5. submit_aggregation (POST :id/submit) → auto-verified on submit

Reward split: aggregation miner 50%, source trace miners 25%, verifiers 15%, treasury 10%. Aggregations 5-7x more token-efficient than raw traces in RAG, so they accrue citation royalties over time.

Re-run npm run forge:watch to check status. SDK runtime is at 0.5.130; gateway is at 0.5.32 (lots of drift). No public roadmap or GitHub repo for Nookplot itself, so monitor the SDK for new endpoints + the live status.

Skill executors (parked)

skills.yaml declares capabilities (e.g. code-review, research-synthesis) but these are cosmetic — the actual bot generates text via Grok regardless. Pair each declared skill with a concrete TypeScript executor that does the thing:

• code-review — fetch a repo (from bounty deliverable URL or GitHub search), run tsc --noEmit, eslint, optionally semgrep, summarize findings into a markdown report.
• research-synthesis — pull N web/arxiv sources, build a cross-source table of claims with citations.
• verification-scoring — wrap the already-built verification pipeline as a callable skill that other systems can invoke.

Each skill becomes a registry entry in a new src/skills/ directory that the bounty pipeline can dispatch to when the bounty matches the skill's tags. Promise "I'll run tsc and eslint on your repo" in the application, actually do it on win.

Sub-agent specialization (parked)

Spawn named child agents that share infrastructure (proxy, runtime, knowledge graph, vault) but apply in their lanes. Considered:

• nookplot-bot-frontend — only applies to frontend-ui / charting / React community bounties.
• nookplot-bot-research — only applies to literature-review / synthesis / paper-reproduction bounties.
• nookplot-bot-verifier — only runs the verification poller, no bounty applications.

Pros: community-specific reputation builds faster; some bounties restrict to single-community winners.

Cons: multi-agent specialization patterns already appear common near the top of the leaderboard, and may be saturating it. Builds reputation on individual agents but spreads our (single) wallet's track record across multiple identities — which may hurt our visibility on bounties that weight on-chain history.

Verdict: revisit after we have ≥5 bounty wins on the main agent and can measure whether community-specific bidding would have done better.

Verify state any time:

nookplot mine 2>&1 | head -5             # CLI checks stake before running
~/.npm-global/bin/nookplot status         # shows on-chain status
curl -s -H "Authorization: Bearer $NOOKPLOT_API_KEY" https://gateway.nookplot.com/v1/token/balance | jq

Findings — architecture comparison

After surveying the SDK, the canonical reference impl, and other agents on the network, this bot reinvents several layers the SDK already ships. Captured here so the duplication is visible and intentional.

What the SDK provides that we hand-rolled

The hand-rolled approach was forced by Gotcha §1 (nookplot create-agent templates ship broken in 0.7.26–0.7.29). The reactive AutonomousAgent path remains the recommended target architecture.

Layering inversion to fix

Tailing events.jsonl couples us to nookplot online start running. Subscribing to runtime.events directly would drop the file watcher and the daemon-as-dependency.

Things the SDK explicitly leaves to us

• Embedding generator for the mining embedding track (generateEmbeddings in MiningTickOptions) — runtime intentionally does not bundle an Ollama client.
• RLM solver (solveRlm is a no-op stub).
• Custom personality / brain — onSignal or generateResponse.
• Reward claiming — economy.getEarnings() / claimEarnings() exist but no built-in loop calls them. Our 30-min reward loop is a valid addition.
• Staking actions — wallet-signed by a human at nookplot.com.

Findings — what wins bounties

Two operational lessons from surveying accepted submissions (the full market breakdown with agent-level notes is kept privately):

1. Substance beats volume. Bounty-specific methodology with named tools and concrete deliverables lands; identical or title-templated pitches don't. Write for the specific bounty.
2. Winners pin IPFS artifacts. Approved submissions use the shape submit(content, deliverableCids: ["Qm..."]) — a file pinned to IPFS, not chat-style content-only. memory.publishKnowledge({title, body, community, tags}) → {cid, txHash} provides exactly this, and doubles as a knowledge-graph entry eligible for citation revenue.

Some bounty series are effectively closed QA loops (created and approved between the same small set of accounts); a local BOT_CREATOR_BLOCKLIST skips creators you've concluded aren't winnable on merit.

Actions taken from these findings

• Creator blocklist in src/index.ts (BOT_CREATOR_BLOCKLIST) — closed-loop QA bounty creators filtered out of processBountyLifecycle. Stops burning inference on contests we can't win.
• IPFS-pinned submissions — submitBountyWork now calls memory.publishKnowledge first to mint a CID, then submits with deliverableCids: [cid]. Matches the observed winning format and also publishes the deliverable to the knowledge graph.
• bounty.new fast-apply path — runtime.events.subscribe("bounty.new", ...) routes through handleNewBountyEvent which extracts the bountyId, re-checks creator blocklist + seenBounties, and calls applyToBountyIfFit immediately — closes the up-to-5-min poll latency.
• Knowledge publishing loop — startKnowledgePublishLoop ticks every 60 minutes, picks a category from KNOWLEDGE_CATEGORIES, asks Grok for a specific opinionated title+angle, generates a 1200-1500 word markdown body, publishes via memory.publishKnowledge({title, body, community, tags}). Each publish returns {cid, txHash} — pinned to IPFS, recorded on-chain. In-memory dedup on titles. CID + tx logged to ~/.nookplot/knowledge-published.jsonl.
• A/B application variant test — pickVariant() 50/50 chooses long (5-7 sentences, current style) or short (2-3 sentences, ~50 words). Each apply logs variant + appId to ~/.nookplot/ab-applications.jsonl. When the lifecycle observes approval or rejection it logs to ~/.nookplot/ab-outcomes.jsonl. npm run ab-stats joins the two and reports per-variant win-rate once enough bounties have been created + resolved.
• Web search + arxiv + github research before generating — src/research.ts exposes webSearch, arxivSearch, githubSearch, fetchUrl. Fallback chain for web: Brave Search (BRAVE_SEARCH_API_KEY) → Tavily (TAVILY_API_KEY) → DuckDuckGo HTML (no key, free, fragile). arXiv hits export.arxiv.org/api/query (no auth). GitHub uses public API with optional GITHUB_TOKEN. Every apply/submit now runs research before generation and feeds formatResultsForPrompt(...) into the Grok call. Inference adds ~2 calls per artifact (research is a free HTTP call; gathering takes ~1-3 seconds).
• Two-pass refiner (src/refine.ts) — every application and every bounty submission now goes draft → critique → revise. The critique prompt forces three concrete weaknesses; the revise prompt rewrites the draft against the critique. Cost: 2 extra Grok calls per artifact. Critique text is written to the vault note for audit.
• Creator-style profiling (src/creator-profile.ts) — before applying, fetch the bounty creator's past 15 bounties, find their approved applications, compute median/avg message length, and feed a styleHint into the application prompt. 30-min in-process cache to bound API spend.
• Local Obsidian-compatible knowledge vault (knowledge-vault/) — src/vault.ts writes notes with YAML frontmatter and [[wikilinks]] into bounties/, posts/, agents/, topics/, research/. Auto-populated by: bounty applications, bounty submissions, knowledge posts, verifications. Hand-curatable. Substring search via vaultSearch(query). The bot reads relevant vault notes before generating any new bounty artifact.
• Verification path unlocked (was dark) — the proactive scanner is silent because the gateway sees runtimeKind: "cli" and short-circuits server-side discovery, expecting the CLI to discover for itself (which the CLI never actually does for verifications). We bypass it. pollVerifiableSubmissions calls GET /v1/mining/submissions/verifiable?limit=20 every 5 minutes, filters to verifier_kind === "standard" (no artifact-inspection gate), and runs the full 3-step flow per submission:
  1. POST /v1/mining/submissions/:id/comprehension → returns questions
  2. Grok answers them based on the trace, POST /comprehension/answers
  3. Grok scores the trace on four 0.0-1.0 dimensions + writes a 50-500 char justification + 80-500 char knowledge insight, POST /verify Capped at 25/day server-imposed limit (server cap is 30; we leave buffer for retries). 70s cooldown between submissions to respect the gateway's 60s cooldown. Each verification gets a research note written to knowledge-vault/research/.
• Dashboard (npm run dashboard) — credits/budget, A/B counts, knowledge publish stats, local vault stats, and live bounty position.
• Rename: not needed — current display name is already distinctive.

Doc-scrape findings (2026-05-24)

Scraped https://nookplot.com/docs (33 markdown skills pages — /tmp/np/*.md, also /skills/{mining,economy,errors,addresses,guilds,reputation,...}.md). Findings sorted by impact on a solver/verifier bot.

Contradictions worth knowing

• Solver epoch cap: public docs say 6 submissions per 24h (mining.md line 157). The SDK's nookplot_submit_reasoning_trace description + the bundled hermes/mine/SKILL.md both say 12 + 1 guild-exclusive. SDK is authored alongside the gateway so I trust it for now (DAILY_CAP=13 stays), but if we start getting 429 EPOCH_CAP_REACHED earlier than expected, drop to 7 and re-confirm.
• Epoch-pool split: SDK + actionCatalog say 70 solver / 5 verifier / 20 guild / 5 poster. The public docs economy.md says 70 / 20 / 5 / 5 (verifier and guild swapped). Trust SDK — verifier-pool sizing affects our verifier earnings model.
• Hermes SKILL says stake tier 1 = 3M, tier 2 = 15M. Wrong. Live numbers (gateway + onchain.js + docs) are 9M / 25M / 60M. Already corrected in §18 above.

Genuinely new mechanics (not in our notes before)

• Difficulty multipliers (huge spread): easy=1×, medium=5×, hard=15×, expert=50× (economy.md line 181). 50× more reward on expert than easy. Our src/mining.ts already sorts by estimatedRewardNook which presumably bakes this in, but if we ever filter by difficulty: prefer expert.
• Per-trace dataset-access royalty (separate from authorship 10%). When another agent accesses a verified trace, the access fee splits 60% solver / 20% verifiers (split equally) / 10% poster / 10% protocol (mining.md line 436, economy.md line 206). Claim via POST /v1/mining/royalties/claim. This is a long-tail rev source that compounds after we have verified solves. Our authorship-rights mechanic (nookplot_author_mining_challenge = 10% on every solve of challenges we authored) is a different thing — both exist.
• RLM (Reinforcement Learning Mining) spot-check track (mining.md lines 204-238). Parallel to standard verification. Each rlm_replay submission gets pinned sub-calls; verifiers call the disclosed base model themselves with the pinned prompt, gateway computes cosine similarity server-side (Nomic embeddings, default pass = 0.85), 3-of-5 quorum. Endpoints: GET /v1/mining/spot-checks/pending?limit=20, POST /v1/mining/submissions/:id/spot-check. Cap: 10 spot-check verdicts / wallet / 24h rolling. Verifier pays own inference (BYOK / NOOK). Currently not tapped — represents incremental income if we extend src/index.ts:pollVerifiableSubmissions with a sibling poller.
• Citation-rewards pool (~10% of mining epoch pool). When agents cite our published learnings, we earn NOOK royalties; staking multiplier still applies (earn-more-nook.md line 71). We already publish learnings via src/learnings.ts — should be earning passively.
• Artifact inspection gate (mandatory for verifiable kinds). Before verifying any submission with an artifact_cid (python_tests, javascript_tests, exact_answer, crowd_jury, replication, prediction), must call GET /v1/mining/submissions/:id/artifact or get 422 ARTIFACT_INSPECTION_REQUIRED. Plus optional rerun-artifact (5/hr) or probe-artifact (10/hr). Our verifyOneSubmission filters to verifier_kind === "standard" so this doesn't bite today — but flagged if we ever broaden the verification scope.
• Same-creator verification block. Two agents owned by the same wallet can't verify each other → 403 SAME_CREATOR_VERIFICATION (added 2026-04). Not relevant for single-agent setups but worth knowing for swarm runs.
• Rubber-stamp detection on verifiers. Consistent 0.9+ scores trip RUBBER_STAMP_DETECTED and block earning. Our scoreSubmissionTrace rubric is anchored per dimension and produces genuinely discriminative scores (mean 0.4-0.7, sd ≥ 0.15). Verify variance with npm run verify:stats periodically.
• Crowd-jury has a dedicated endpoint family (not just nookplot_verify_ reasoning_submission): POST /v1/mining/submissions/:id/crowd-score (integer 0-100), GET .../crowd-score-status, long-poll GET .../wait-for-finalization. Default crowd-jury quorum = 5 judges. We use src/crowd-jury.ts for this — re-confirm against current schema if we touch it.

Relay / credit caps (peripheral but limits volume)

• Relay per-tier cap (errors.md, economy.md):

  • Tier 0 (api key, no on-chain reg): 10 relays/day, 0.50 credits each
  • Tier 1 (on-chain registered — that's us): 10 relays/day, 0.25 each
  • Tier 2 (any paid credit pack or $5/mo Starter): 200 relays/day, 0.10 each

  This is a hard cap on signed-action throughput (stake/unstake/claim/ endorse/etc — NOT on mining submissions, which go through a different path). At 10/day we could plausibly run out on a busy claim day. If we start hitting RELAY_QUOTA_EXCEEDED, upgrading to Tier 2 is $5/mo.

• Auth rate limit: 60 req/min per API key. Our polling cadence (~15-min mining, ~5-min verification) is well under.
• EIP-712 deadline = 1h after prepare. If a signedRequest sits in our queue >1h before relay, it's dead. We currently sign-and-relay inline so this doesn't bite.

Roadmap / experimental

Not loud, but worth tracking:

• /skills/paper-reproduction.md, forge.md, orchestration.md — linked but 404 / SPA fallback. The features are partially documented inside mining.md and the runtime SDK; full docs pending.
• Cognitive workspaces + cognitive regions — extensive endpoint family (nookplot_workspace_*) but no quotas / pricing — alpha-flavor.
• Manifest geometric matching (PUT /v1/agents/me/manifest, POST .../match) — live but no rate limits documented; alpha-flavor.
• Clarifications (POST /v1/clarifications/request|offer|...) — full doc but lifecycle uses proactive.signal events; treat as beta.
• /v1/improvement/* and /v1/proactive/* endpoint families — exist in GET /v1 listing but have no skill page yet.

Doc URLs covered (re-probe with curl -s URL)

Cached locally at /tmp/np/. Source list: mining.md, economy.md, errors.md, addresses.md, guilds.md, reputation.md, workspaces.md, swarms.md, latent-space.md, oracle.md, autoresearch.md, papers.md, intents.md, ecosystem.md, actions.md, communicate.md, register.md, teaching.md, publish.md, marketplace.md, bounties.md, collaborate.md, skill-registry.md, mcp-server.md, mesh-integration.md, email.md, earn-more-nook.md — all at https://nookplot.com/skills/<name>.md. Plus SKILL.md, llms.txt at root.

404 / SPA-only: paper-reproduction.md, forge.md, orchestration.md, docs (and all /docs/* paths — site uses /skills/ not /docs/).

Mining souped-up pipeline (2026-05-24)

Previously: raw single-shot inference per challenge with xhigh reasoning, gateway-side related learnings only.

Now: every standard solve goes through this pipeline:

challenge
  ├── parallel gather (Promise.all):
  │     • fetchRelatedLearnings (gateway top-5 by specificity)
  │     • gatherMiningContext (arxiv 4 + web 4 + vault 5)
  │     • fetchSubmissionGuide (verifiable only)
  ├── verifiable kind? → override model to deepseek-v4-pro
  ├── trySolve(... context, guide)
  │     domain hint + arxiv block + web block + vault block + starter code
  │     spliced into system+user prompts
  ├── standard trace? → refineStandardTrace (critique → revise)
  │     lens: citation density (year+author), benchmarks (units), equations
  ├── verifiable? → runSandboxSmokeTest (POST /v1/exec)
  │     python: import + dir() check; js: dynamic import check; exact: format
  └── submit (with guildId)

Cost & latency impact

• Standard solves: ~2× inference cost (added refine pass) + bounded web/arxiv search overhead (3-8s wall, runs in parallel with the gateway learnings fetch so doesn't strictly serialize). Trace length expected 2-3× longer with denser citations.
• Verifiable solves: +0.5 credits per submission (sandbox smoke test) + the deepseek-v4-pro routing (no cost delta — same per-call pricing as other flagships).

What this addresses (gap analysis)

Compared to top solver 0x13490d89 who consistently writes 428-746 char summaries with 5+ benchmarks per summary and citations like Auer 2002 / Lai-Robbins 1985 / Holladay 1957 / de Boor 1978, our pre-pipeline output was 255-302 chars with bare-name citations and 2-4 benchmarks. The pipeline targets the three deltas: citation density (arxiv+web fetch), benchmark density (refine lens explicitly checks for unit-bearing numbers), formal equations (refine lens explicitly checks for inline math).

If the refine pass doesn't measurably improve quality after ~20 attempts (check via npm run mining-stats -- --24h), revisit the lens hint or disable with BOT_MINING_REFINE=0.

Revenue + observability surfaces (2026-05-24, post-7-feature build)

Mining royalty claim loop

claimMiningRewards in src/index.ts (called once on boot + every 30 min from startRewardLoop):

1. GET /v1/mining/stats/agent/:addr → returns claimableBalance (map of source → NOOK amount: epoch_solver, epoch_verification, rlm_collab, dataset_access, etc.) and pendingRewards (epoch not yet settled).
2. For each source with balance > 0: POST /v1/mining/royalties/claim {sourceType} — off-chain claim, records on the gateway.
3. Logs to ~/.nookplot/mining-claims.jsonl (timestamp + claimed amount + breakdown).

On-chain settlement is separate. Gateway records the claim, but moving NOOK to our wallet requires the Merkle-proof flow (GET /v1/mining/proof/:addr → on-chain claimMiningPoolReward) which costs gas in ETH. We don't yet automate that step — but the off-chain claim is the rate-limiting one; on-chain can be batched at human convenience.

Confirmed live: at first probe a meaningful epoch_verification balance was sitting unclaimed (from 29 prior verifications). Bot now claims this every 30 min and on every cold boot.

RLM spot-check verifier track

New module src/rlm-spotcheck.ts. Separate verifier surface with its own 10/day cap (gateway-enforced RLM_SPOT_CHECK_DAILY_CAP=10).

Loop: GET /v1/mining/spot-checks/pending?limit=20 → for each trajectory, fetch the prompt CID from IPFS (gateway helper first, public ipfs.io fallback), call the disclosed model via Venice, POST /v1/mining/submissions/:id/spot-check with {sub_call_id, replay_response_text}. Gateway re-embeds and computes cosine vs cached original-output embedding. Quorum 3-of-5. Outlier verdicts earn 0 NOOK but no slashing.

Wired in startVerificationLoop: first run 90s after boot, then every 8 min. Toggle off with BOT_RLM_SPOTCHECK=0. Pacing: 45s between verdicts within a tick, max 3 per tick.

Model normalization handles common display-name variants ("Grok 4.3" → grok-4-3, "GPT-5..." → openai-gpt-55). Unknown ids fall back to claude-opus-4-7.

Log: ~/.nookplot/rlm-spotchecks.jsonl.

Network blockage status checker

New module src/network-status.ts. Polls gateway every 30 min and emits a one-line health summary so we can trend the verifier-supply problem.

Sample line:

🌐 epoch=66(closed) pool=82(82%v0,9v1,9v2) rlm=0(0/10) mine=11pending avgV=0.4 claim=1234 emit=5.0M

Reads:

• epoch=66(closed) — current epoch number + status
• pool=82(82%v0,9v1,9v2) — verifiable pool: total / % at 0 verifications / count at 1 / count at 2. High v0% = network-wide verifier starvation.
• rlm=0(0/10) — RLM spot-checks pending + our daily progress
• mine=11pending avgV=0.4 — our submissions awaiting quorum + their average verifier count (samples up to 5)
• claim=1234 — sum of our unclaimed gateway-side mining balance
• emit=5.0M — daily NOOK emission pool size for the current epoch
• 🚨RESERVE suffix appears if the emission is from the 2.5M emergency reserve

Full snapshot written to ~/.nookplot/network-status.jsonl for trending. Toggle with BOT_NETWORK_STATUS=0. First poll 45s after boot, then every 30 min.

Are we a Hermes bot? (No)

Hermes is an external AI-agent host (akin to Claude Code, Cursor, Windsurf). The Nookplot ecosystem ships an MCP server (@nookplot/mcp) that exposes 462 tools as MCP function-call interfaces, intended to be loaded into a Hermes host's tool surface. The bundled node_modules/@nookplot/mcp/skills/ hermes/nookplot/mine/SKILL.md is a prompt template meant to be loaded by the Hermes runtime — not by us.

Our bot uses @nookplot/runtime (the lower-level SDK) directly and hits the gateway HTTP + WebSocket API. We bypass the MCP layer entirely. Pros: fine-grained control, single Node process, no MCP overhead, can talk to arbitrary endpoints not yet exposed as MCP tools. Cons: we re-implement some things the MCP layer would give us for free (e.g. tool-call routing, prompt activation), and skill files don't auto-activate.

In Nookplot's architectural categories we are a "direct-runtime agent" / "custom backend" — same category as Hermes itself, not a Hermes child.

What we can personally do to relieve the network verifier bottleneck

The bottleneck is: at the time of this writing, 81% of submissions in the verifiable pool have 0 verifications, and 0 have reached the 3-of-3 quorum. Solver supply >> verifier supply. We've identified four levers we can pull, ranked by leverage:

Tier A — already shipping

1. Near-quorum priority in verification (shipped 2026-05-24). pollVerifiableSubmissions now sorts: PRIMARY = highest verification_count first (push v2 → v3 quorum). SECONDARY = least-prior-verified solver. Same effort per verification, ~3× higher network leverage on v2 vs v0 submissions because crossing quorum (a) actually clears NOOK to the solver, (b) removes that submission from the queue.
2. RLM spot-check verifier track (shipped earlier today). Separate verifier surface with 10/day cap independent of the main 30/day cap. See §17b above.
3. Verify at daily max. We're at 29/30. Already maxed.

Tier B — considered and NOT pursued

Two cap-multiplying options (second on-chain identity as a sibling verifier; DM-recruiting verifiers for our own subs) were evaluated and rejected as sybil/collusion-adjacent — and the gateway's diversity and same-creator blocks kill the payoff anyway.

Tier C — out of our control

6. Network-level emergency reserve. If verifier supply doesn't catch up, the gateway may lower the 3-quorum threshold or open emergency verifier emissions. Watch network-status.jsonl for isEmergencyReserve=true — that's the signal.

Gateway field-type quirks (learned the hard way)

The gateway returns some integer-typed columns as JSON strings instead of numbers. Caught 2026-05-24 in network-status.ts: filtering by s.verification_count === 0 silently matched nothing because the value came back as the string "0". Always coerce via Number(x) or use a helper like vcount() defined in src/network-status.ts.

Audited fields known to be string-typed in responses:

• submissions.verification_count (confirmed string)
• Suspected: submission_count, domain_proficiency_score — coerce when in doubt.

Web dashboard (npm run web)

Single-file SPA served by src/dashboard-web.ts (Node HTTP, no framework). Default: http://127.0.0.1:7878. Override with WEB_PORT, bind elsewhere with WEB_BIND_HOST (default loopback; do not expose to LAN — no auth).

Endpoints:

• GET / → public/dashboard.html (vanilla JS + Chart.js via CDN)
• GET /api/snapshot → live merged JSON: gateway state + JSONL aggregates
• GET /api/history?metric={mining|verification|network|claims} → JSONL passthrough
• GET /api/blockers → ranked list of current blockers + scope tag
• GET /api/health → liveness

Tabs:

• Overview — stake, lifetime earned, claimable, pending, RLM, network v0%
• Performance — per-model 24h, mining timeseries (7d), verification dim trends
• vs Peers — our rank by pool presence + top-10 leaderboard
• Blockers — color-coded by severity, separate network/us scope, with network v0% and our-avg-vCount trend charts
• History — earned-vs-expected status, claim cumulative chart, network snapshot table
• Raw — full /api/snapshot for debugging

2026-10-11 redesign (supersedes the list above, kept for history): six tabs, each answering one question. Now: a plain-sentence status line, the NOOK journey diagram (work → waiting for checks → credited → settlement root → wallet, broken where money is stuck), the needs-attention list and this epoch. Money: the three balances (NOOK, gateway credits, Venice), holdings, P&L, claims and credits. Work: epoch, how a solve gets paid, pending checks, daily allowance, prize pools, output and quality. Network: the checking queue, trends, peers, snapshots. Reputation and Activity (project draft, inbox, side tracks, catalog tracks, log, raw JSON). Old hash links (#credits, #today, #blockers, #raw, …) open the matching section. /api/snapshot gained settlement and venice; blockers carry kind.

Auto-refreshes every 30s. The dashboard re-uses all our existing JSONL data and adds peer-rank computation by querying the live verifiable pool.

Testing (npm test)

Node 20+ built-in test runner via tsx — node --import tsx --test. Tests live in src/__tests__/backend.test.ts. 40 tests covering:

Each pure helper that drives a behavior we care about has at least one positive and one boundary test. Network-dependent paths (gateway requests, Venice calls, IPFS) are NOT tested — those need integration probes.

Run the suite before any non-trivial refactor of mining/guild/network code.

Credits — how to get more (2026-05-24)

Credits are gateway service-fee currency, NOT NOOK. They pay for:

• Signed relays (~0.25 credits each at tier 1, 0.10 at tier 2)
• Sandbox /v1/exec calls (~0.50 credits each + a small per-second surcharge)
• Inference proxy (varies by model)
• Venice web search (0.75/call), image gen (2.00/call), recall (0.10/call)

Five ways to get more, in order of effort:

1. Daily activity drip (passive, ≤15 cr/day at tier 1, ≤45 at tier 2). Diverse activity across 6 categories scored daily. Our bot is active enough to claim partial drip already.
2. Passive engagement (no action required).
   • Your post upvoted → 0.10 cr
   • Your post commented → 0.15 cr
   • Your knowledge cited → 0.50 cr

3. Buy a credit pack (USDC on Base) — POST against CreditPurchase: 0x1A8C121e5C79623986f85F74C66d9cAd086B2358:

   • Micro: $2 USDC → 125 credits
   • Standard: $10 USDC → 700 credits
   • Bulk: $35 USDC → 3,250 credits

   (These are the gateway's LISTED prices. The contract charges $1 → 25, $5 → 140 and $20 → 650: see "Credit packs + tier 2", 2026-10-11 re-measure.) All upgrade us to tier 2 (200 daily relays at 0.10 cr each).

4. Buy with NOOK (20-30% discount over USDC price). We have wallet NOOK now after the on-chain claim. Worth doing if we're going to be active.
5. Subscribe ($5-99/mo) — Starter $5/150 cr, Builder $25/1K cr, Pro $99/5K cr. All upgrade to tier 2.

Burn-rate reference (from our ledger):

• Sandbox python smoke test: ~50 cr per call (+1 cr/sec surcharge)
• Signed relay (e.g. on-chain claim): 25 cr (tier 1) → 10 cr (tier 2)
• Venice web search per mining context: 0.75 cr per call

Live view: open the dashboard, Credits tab. The /api/credits endpoint also surfaces the transaction ledger + waysToGetMore array.

Wallet balance lookup

src/wallet.ts does direct Base RPC (https://mainnet.base.org, overridable via BASE_RPC_URL) to call balanceOf on the NOOK ERC-20 (0xb233BDFFD437E60fA451F62c6c09D3804d285Ba3) and eth_getBalance for gas. Used to verify on-chain claims actually settled.

Cache: 30s. Auto-refreshes on dashboard tick.

Exposed at snapshot.money.wallet:

{
  "address": "0x...",
  "nook": 12345.67,
  "nookFormatted": "12,345.67 NOOK",
  "eth": 0.0012,
  "ethFormatted": "0.0012 ETH",
  "blockNumber": 40000000,
  "rpcUrl": "https://mainnet.base.org",
  "fetchedAt": "2026-05-24T10:..."
}

Credit packs + tier 2 (2026-05-24)

USDC path: confirmed working

End-to-end via npm run buy-credits -- --pack=0 (USDC default):

1. Approve USDC → CreditPurchase 0x1A8C121e…2358
2. Call purchaseWithUSDC(packId) selector 0x8af3d24a
3. Tier-2 unlocked on any successful purchase

Our purchase tx confirmed on-chain; gas 80k ($0.005).

Pricing mismatch found

The on-chain contract is configured with 5× different pricing than what /v1/credits/packs advertises. Effective rate: $0.04/credit vs advertised $0.016/credit. (Worth reporting to the gateway team.) The tier-2 daily drip (45 cr/day at 0.10 cr/relay = 450 relays/day headroom) means net is still positive even at the worse rate.

2026-10-11 re-measure (all three packs, read from the contract): the contract's packs(id) getter returns (name, usdcPrice, creditAmount ×100, active). It confirms the May measurement and extends it to the other packs:

A second Micro buy moved exactly 1 USDC and the ledger credited 25.00. The script had printed the listing ("Payment: 2 USDC", "Purchased 125 credits") and approved 2 USDC, leaving a 1 USDC allowance behind. buy-credits.ts and the dashboard's pack cards now read the contract (src/credit-packs.ts), and the script reports what the receipt actually charged and credited. The relay cost was already 0.10 before that buy (tier 2 from the May purchase).

Verify tier-2 status: check next signed relay cost in /v1/credits/transactions — tier 1 = 0.25 cr/relay, tier 2 = 0.10 cr/relay.

NOOK-payment path: not deployed publicly

The CreditPurchase proxy has only 20 inbound txs ever (all by admin). No public NOOK-payment function is callable today:

• purchaseWithNOOK(uint256) 0x8b3e282e — doesn't exist
• purchaseWithNook(uint256) 0x9701a668 — doesn't exist
• 17+ other name variants — none match observed selectors No public NOOK-purchase function is callable on the CreditPurchase proxy yet (admin-only paths only). The --nook flag in buy-credits.ts fails fast until the gateway ships it.

npm run buy-credits -- --pack=0          # $1 USDC → 25 cr (contract price; see pricing mismatch above)
npm run buy-credits -- --pack=2          # $20 USDC → 650 cr (best $/cr)

On-chain settlement: MiningRewardPool (2026-10-12)

Mining rewards settle through MiningRewardPool, an ERC1967 (UUPS) proxy at 0x3632428a9878d2b58f58f9ef7c57cb0ee5760a01. The implementation is 0x324ce78a9ccedae0d2f76c111775e403d17006fd (solc 0.8.24, verified source on Sourcify). Relayed claims arrive through the ERC2771 forwarder 0xbaea9e1b5222ab79d7b194de95ff904d7e8ecf80, sent by the gateway relayer EOA 0x9f1045d983a6ac1faea82fe9314b47de73515d1a.

• claim(cumulativeAmount, proof) is permissionless. The leaf is keyed to the caller, so our wallet can claim directly with its own gas: npm run stake -- claim-direct.
• publishRoot is the root publisher's or owner's only. It reverts with:
  • InsolventRoot when unclaimed obligations would exceed the pool's NOOK balance;
  • ExceedsMaxEpochPayout when one root adds more than 50M;
  • RootPublishCooldownActive within an hour of the last root.
• The contract's epoch() runs 2 behind the gateway's epochNumber. The 09-02 root is contract epoch 162 and gateway epoch 164.
• Why roots stopped after 09-02: the pool had 4,849,967 NOOK to spare, less than one day of credits, and it has not been funded since. Roots resume only after Nookplot tops the pool up. That is what happened 08-21 → 08-24.
• Read-only status: npm run stake -- settlement. The dashboard shows the same numbers (settlement.chain in /api/snapshot).
• The root-publishing service is private (the public repo has the contract, not the gateway), and no gateway endpoint triggers a root.

Nookplot paused for a rebuild (2026-10-22 →)

Since 2026-10-22 ~17:15Z the gateway answers 503 {"error":"maintenance"} ("Nookplot is paused while it is rebuilt") on every endpoint we use except GET /v1/mining/proof/:addr, which still answered 200 on 10-31. nookplot.com is a static pause page with an API of its own: /api/stats (distribution epoch, totalStaked, cooldown), /api/proof/:addr (same shape as the gateway's proof) and /api/claimed/:addr.

On-chain, verified 10-31:

• 2026-10-22 07:43Z, about 9.5 hours before the pause: ownership of MiningRewardPool, MiningStake and the other Nookplot contracts moved to 0x0027a5643e3A6a104D21ad7995319dE902B5CFb4. MiningRewardPool's rootPublisher became 0x83fAE4a2727C82ed9d28d2e4A7EbBA27Ba209112, which is funded but had sent 0 transactions by 10-31.
• Nothing since: no root (contract epoch 162 = gateway 164), no pool top-up, totalClaimed flat, no @nookplot npm release since 08-21.

What the bot does:

• gateway-maintenance.ts waits in-process and resumes on its own.
• relaunch-watch.ts checks the restart signs hourly while paused (BOT_RELAUNCH_WATCH_MIN). The baseline is the first check; state lives in ~/.nookplot/relaunch-watch.json; npm run relaunch-watch checks by hand.
• Staking without the gateway (stake-direct.ts). MiningStake proxy is 0x1Fcf45C74C7609Ccf647B678b2116e2CccD9C317; the implementation is 0x01a78b1b596017122E0cab2da35c16645c71688B (Sourcify exact match).
  • The unstake functions use ERC2771 _msgSender(), so a direct call acts on the caller.
  • requestUnstake(amount) starts a 7-day cooldown (fixed at request time), calls miningGuild.onUnstake (the agent leaves its guild), and the gateway stops reward accrual.
  • cancelUnstake() restores the guild seat if the guild still has room.
  • completeUnstake() pays out after the cooldown.
  • All three are whenNotPaused. The owner can also waiveCooldown, slashAgent and upgrade the contract (UUPS). emergencyWithdraw can't take staked NOOK, only the excess over totalStaked.
• claim-direct and settlement fall back to nookplot.com's /api/proof when the gateway can't answer.
• The dashboard reads the stake from MiningStake when /v1/mining/stake fails.

Environment toggles (canonical list)

BOT_MINING_REFINE=0          # skip critique→revise pass on standard traces
BOT_MINING_SANDBOX=0         # skip /v1/exec smoke test on verifiable submissions
BOT_VERIFIABLE_MODEL_OVERRIDE=0  # let A/B handle verifiable kinds (don't force deepseek)
BOT_VERIFIABLE_MODEL=...     # override the deepseek-v4-pro pick
BOT_MINING_DOMAINS=tag,tag   # override declared-domains for guild matching
BOT_AUTO_JOIN_GUILD=0        # skip mining-guild auto-join on boot
BOT_RLM_SPOTCHECK=0          # skip RLM spot-check verifier loop
BOT_NETWORK_STATUS=0         # skip the periodic network-health log
BOT_VERIFY_THRESHOLD=N       # force a fixed verification threshold (override slack algorithm)
BOT_AUTO_ONCHAIN_CLAIM=0     # skip on-chain Merkle reward claim
BOT_RELAUNCH_WATCH_MIN=0     # skip the hourly restart-sign check during a maintenance pause
BASE_RPC_URL=https://…       # alt Base RPC endpoint (default: mainnet.base.org)
WEB_PORT=7878                # dashboard port
WEB_BIND_HOST=127.0.0.1      # dashboard bind addr — don't expose externally (no auth)

For live state at any moment: dashboard /api/snapshot is the source of truth. This file documents how the bot works; for current numbers query the bot.

Model-endpoint matrix probe (2026-05-24)

Probed src/_probe-models.ts and src/_probe-quality.ts against all 5 mining-pool models × 7 reasoning efforts. Concrete findings.

Lightweight probe — model+effort availability (2k token simple JSON task)

Only max is broken (on gpt-55 + gemini). We never use max, so this doesn't affect us — but worth knowing if we ever upgrade the effort map.

Heavy probe — real mining workload (14k tokens, xhigh, web_search ON)

Diagnosis of "solver produced no output" errors: AbortSignal race, not model failure. With real mining context (~5KB system + ~3-5KB user context

• Venice web_search), slow models routinely approach or exceed 240s. The bot's AbortSignal.timeout(240_000) would fire mid-response and we'd log "solver produced no output".

Fix landed: timeout 240s → 1000s, max_tokens 14k → 40k

src/mining.ts:solveStandardTrace. No more AbortSignal races. Token cap is well past any practical need.

Quality comparison — Venice web_search ON vs OFF

Ran src/_probe-quality.ts: same challenge (harmonic-numbers proof), same model (claude-opus-4-7), same effort (xhigh), max_tokens=40k. Three configs:

Surprise finding: Venice's enable_web_search HURTS quality when combined with our own mining-context.ts gather. Config C (both on, our previous default) emits 0 LaTeX equations vs Config B's 12 — Venice's snippet-style search results appear to bias the model toward prose-style citations and away from formal derivation.

Fix landed: removed venice_parameters: VENICE_WEB_SEARCH from solveStandardTrace. Saves 0.75 credits/call + adds equations + nearly 2× more citations. Local context (mining-context.ts) does the same job better.

Verifiable kinds (python_tests / javascript_tests / exact_answer) still use VENICE_WEB_SEARCH because those calls are short and the search results can directly inform code design.

Dashboard claim-row "?" fix

public/dashboard.html renderOverview()'s claims-table renderer was using c.sources?.[0]?.source + c.claimed — both undefined on on-chain entries (which carry kind:"on-chain", txHash, onChainCumulative instead). Now distinguishes: on-chain rows render as <span class="good">on-chain</span> <span class="muted">0xe44…3d29</span> with onChainCumulative as amount.

RLM cap clarification

Probed live: GET /v1/mining/spot-checks/pending returns dailyCap: 10 even after tier-2 upgrade. RLM 10/day is per-wallet, doesn't scale with credit tier (only relay quotas scale: 10→200/day). Updated dashboard label to clarify.

Earnings + impact tracks added (2026-05-24, second-pass)

Built six new tracks on top of the souped-up pipeline:

#2 — Specialization sprint filter (src/mining.ts)

BOT_SPECIALIZE_DOMAINS=distributed-systems,algorithms env-gates the mining solver to challenges whose domainTags overlap the list. Race to 50 verified solves in one domain → authorship rights unlocked → 10% perpetual royalties on every solve of challenges you author.

Match modes:

• BOT_SPECIALIZE_MATCH_MODE=any (default) — at least one domain overlap
• BOT_SPECIALIZE_MATCH_MODE=all — strict (all targets must overlap)

Off if env unset (current default = broad CS).

#5 — Crowd-jury widened (src/crowd-jury.ts)

Was polling only top-20 of the verifiable pool — would never see crowd-jury subs since they're rarer + might rank lower. Pool fetch widened 20 → 200. Added a closest-to-5-quorum sort (descending crowd_score_count) so we focus on subs that need 1-2 more judges instead of fresh ones.

#6 — Paper-reproduction discovery (src/paper-reproduction.ts)

Winner-take-all challenges. Honest scope: the bot can't train models, so this module:

1. Polls sourceType=paper_reproduction&status=open every 30 min
2. For each new challenge: extracts arXiv IDs + HF dataset IDs from the bundle, fetches related learnings, writes a dossier to knowledge-vault/research/paper-repro-*.md
3. Surfaces in dashboard Activity tab so a human can pick up the actual training work

Each dossier includes: arXiv links, HF dataset refs, eval target (baselineScore), full challenge description, related learnings from prior solvers, and step-by-step instructions for the manual training path.

Toggle off with BOT_PAPER_REPRODUCTION=0.

#7 — Cognitive-workspace recording (src/workspace-solve.ts)

After every successful mining solve, creates a /v1/workspaces workspace with cognitive regions populated:

• constraints: model + effort + pipeline state
• evidence: citation list (arxiv + web + vault hits)
• hypotheses: the trace summary (our "candidate solution")
• decisions: model choice + refine-pass decision
• artifacts: the full reasoning trace
• open_questions: critique-pass prompts for future iteration

Cross-region link_items calls wire the chain: decision → supports hypothesis → derives_from artifact.

Effect: other agents can fork our solving process. Future runs on similar challenges can read prior hypotheses. Verifiers can audit the reasoning chain explicitly. Same inference cost as before — this is logging, not re-solving.

Toggle off with BOT_WORKSPACE_SOLVE=0. Fire-and-forget — never blocks or fails a solve.

#8 — Bounty fit threshold loosened (src/index.ts)

Was filtering at confidence ≥ 0.6 → only 1 application in lifetime. Loosened to 0.4 (overridable via BOT_BOUNTY_FIT_THRESHOLD). At tier-2 relay cost (0.10 cr each), even a 10% win rate on broader applications is positive expected value.

#9 — Citation velocity (cross-cite + compile) (src/citation-velocity.ts)

Two passive-income loops:

Cross-cite (every 45 min, max 3 citations/tick):

1. browse_network_learnings in our top-3 domains
2. Filter to quality-≥50 peer items, NOT authored by us
3. Cite them with add_knowledge_citation linking ONE of our items as extends (same-domain) or supports (cross-domain)
4. Per docs, citations "earn reputation for both agents". We only cite peer items (quality ≥ 50) that genuinely informed our work — no self-citing.

Compile-knowledge (every 4h):

• GET /v1/agents/me/knowledge/synthesis-opportunities — surfaces cross-domain gaps + lint issues + auto-creates cross-links

Log: ~/.nookplot/citation-velocity.jsonl. Toggle: BOT_CITATION_VELOCITY=0.

Dashboard updates for the above

• Overview: 2 new cards — "Specialization" (shows active filter) and "Paper-repro opportunities" (count + link to Activity tab)
• Activity tab: paper-repro opportunities table + new side-track counters for citations, workspaces, paper-repro
• /api/snapshot.botMode exposes every toggle's current state so the UI can render "what's on" without reading env

New env toggles (added to canonical list)

BOT_SPECIALIZE_DOMAINS=distributed-systems,algorithms  # mining domain filter
BOT_SPECIALIZE_MATCH_MODE=any                          # any (default) or all
BOT_BOUNTY_FIT_THRESHOLD=0.4                            # 0.0-1.0
BOT_PAPER_REPRODUCTION=0                                # skip discovery loop
BOT_WORKSPACE_SOLVE=0                                   # skip workspace logging
BOT_CITATION_VELOCITY=0                                 # skip citation+compile loops

Test coverage

src/__tests__/backend.test.ts extended to 60/60 passing. New tests:

• specialization filter — env parsing, any/all modes, case-insensitivity (5 tests)
• paper-reproduction extractors — arXiv ID regex coverage, HF dataset URL parsing (3 tests)
• citation-velocity helpers — peer quality/author/domain accessors, citation type heuristic, id fallbacks (5 tests)

Workspace-solve is mostly side-effecty (POSTs against gateway), so it isn't unit-tested — covered by integration via the bot's actual solve loop.

Social engagement + onboarding (2026-05-24, third-pass)

Purpose: participate in the network surfaces we'd been ignoring (marketplace, projects) and engage substantively with work we actually build on.

Soft specialization (replaces hard filter)

src/mining.ts — specialization now affects sort order, not eligibility. Targets specified in BOT_SPECIALIZE_DOMAINS go to the top of the mining queue; non-matching challenges are still picked up if no matches are available. Same shape as the v0-starvation fallback in the verifier — we never idle when there's work.

To restore the old hard-exclude behavior: BOT_SPECIALIZE_STRICT=1.

The log line now shows match count:

⛏ found 5 eligible challenges (5 total open) — 1 match specialization [distributed-systems]

Social engagement loops (src/social-engagement.ts)

Three paced loops with anti-spam guardrails:

Hard-coded to use prepareSignRelay (gasless via gateway relay) for all three actions. Idempotency: every action writes to its own JSONL log (votes.jsonl, follows.jsonl, comments.jsonl); next tick reads the log to dedupe.

Why not generic upvote/comment bots? Template engagement is spam — it adds no signal for anyone and degrades the feed. These loops only touch content we cited or genuinely used.

The comment template is substantive: it references the citation type (extends vs supports) and the domain, framed as "we built on your work". Not a "great post!" generator.

Toggle off per-loop: BOT_VOTE_LOOP=0, BOT_FOLLOW_LOOP=0, BOT_COMMENT_LOOP=0.

Onboarding (src/onboarding.ts)

One-shot, idempotent on every boot — creates these if missing:

1. Service listing in marketplace category (/v1/prepare/service/list):
   • Title: "Reasoning-trace verification on Nookplot"
   • Free (priceAmount=0), USDC token, category: verification
   • Unlocks the marketplace drip category
2. Project: the boot knowledge-ops project (slug/name/description from PROJECT_TEMPLATE in src/onboarding.ts; personalize via BOT_ONBOARD_PROJECT_*)
   • Description: public lab notes from autonomous bot
   • Unlocks the projects drip category

Both go through prepareSignRelay → gasless. Existence check first via GET /v1/services/agent/:addr and GET /v1/projects — if already created, boot is silent.

Toggle off entirely: BOT_ONBOARDING=0.

Test coverage

Backend tests now at 66/66 passing. New tests cover:

• Soft specialization sort (existing tests still pass with new semantics)
• selectVoteCandidate filters (self + already-voted)
• rankFollowCandidates frequency-weighted citation logic
• buildCommentBody non-template substance
• Onboarding templates schema (project slug shape, service listing fields)

Dashboard updates

/api/snapshot.botMode now exposes every toggle including the new social loops + onboarding flag + soft-vs-strict specialization mode.

/api/sidetracks includes counts for: votes, follows, comments, onboarding actions. Sidetracks grid in Activity tab shows all 7 new counters with today's count.

Env toggles (additions)

BOT_SPECIALIZE_STRICT=1     # restore old hard-exclude behavior (default = soft)
BOT_VOTE_LOOP=0             # disable upvote loop
BOT_FOLLOW_LOOP=0           # disable follow loop
BOT_COMMENT_LOOP=0          # disable comment loop
BOT_ONBOARDING=0            # skip service-listing + project init on boot

Expected drip lift

Pre-changes: 4 of 6 drip categories active (content, social, protocol, tools). Post-changes: 6 of 6 (added marketplace via service listing, projects via project creation). Expected daily drip lift: ~15-25 cr/day at tier 2.

Anti-spam burn estimate: vote+follow+comment loops total ~4-5 relays/day at 0.10 cr each = ~0.5 cr/day. Net expected gain: +14 to +24 cr/day.

MCP-derived tracks (2026-05-25, fourth-pass)

The official @nookplot/mcp package exposes 462 tools across 21 categories. We DON'T switch the bot to call the MCP server (interactive-LLM oriented, adds stdio JSON-RPC overhead per call — bad fit for a daemon). Instead we scraped the MCP source (node_modules/@nookplot/mcp/dist/tools/*.js) for endpoints we weren't using, then implemented each as a raw-API module in our codebase. The full evaluation rationale lives in the conversation transcript; this section documents what shipped.

What was missing from the bot before this pass

What now lives in src/

Each module follows the same shape:

• Self-contained runtime: RuntimeLike interface (no SDK coupling)
• JSONL log under ~/.nookplot/<track>.jsonl
• runXxxTick(runtime) function the orchestrator calls on a schedule
• xxxSummary() function for dashboard surfacing
• Env-toggleable with BOT_<TRACK>_LOOP=0 (default ON)
• Auto-write actions gated behind a SECOND env var (default OFF — never spam)

mining.ts enhancements

Two new exports added in this pass:

1. postSolveLearning(runtime, submissionId, reasoning, traceSummary) — fires after every standard-trace solve. POSTs a distilled-specificity learning to /v1/mining/submissions/:id/learning. Auto-scored 0–100 by the gateway on specificity. Free, additive reputation. Fire-and-forget; can't block the solve.
2. composePostSolveLearning(reasoning, traceSummary) — pure helper that picks the top-N specificity-dense sentences from the trace, capped at 1500 chars. Tested.

mining-context.ts enhancements

gatherMiningContext(ch, runtime?) now accepts a runtime argument. When provided, two extra context sources join the parallel fetch:

• Network wiki (fetchWikiContextForChallenge) — pulls curated domain summaries (≤ 2 per challenge, cached 24h) and prepends them to the context block.
• Semantic Scholar (searchPapers) — finds 5 related papers per challenge and renders a "Related work" block.

Both soft-fail. Existing callers without a runtime still work — they just don't get these new sources.

Cadence summary (per-day API calls)

Total: ~1150 additional GETs / 24h on top of the existing ~5000-call baseline. Well within gateway rate limits.

What still requires manual operator approval

Every track that writes does so ONLY under an explicit secondary opt-in:

• BOT_BOUNTY_LOOP browses; applyToBounty() only when called explicitly
• BOT_CLARIFY_LOOP browses; BOT_CLARIFY_AUTO_OFFER=1 flips on auto-offer (still requires a generateAnswer callback)
• BOT_SWARM_LOOP browses; BOT_SWARM_AUTO_CLAIM=1 flips on auto-claim (still no auto-submit — solver wiring is manual)
• BOT_TEACHING_LOOP browses incoming requests; accept + deliver are explicit functions, never automatic
• BOT_WEBHOOK_URL controls subscriptions — no-op without a publicly reachable URL
• BOT_POST_SOLVE_LEARNING=0 disables the gateway-side learning post (default ON)

How to find earning opportunities the bot logged

# Bounty candidates we saw but didn't apply to
jq -c 'select(.kind=="candidate")' < ~/.nookplot/bounty-candidates.jsonl

# Clarification micro-jobs
jq -c 'select(.kind=="candidate")' < ~/.nookplot/clarifications.jsonl

# Swarm subtasks we could claim
jq -c 'select(.kind=="subtask-candidate")' < ~/.nookplot/swarms.jsonl

# Incoming teaching requests
jq -c 'select(.kind=="exchange-incoming")' < ~/.nookplot/teaching.jsonl

# Unclaimed weekly rewards
jq -c 'select(.kind=="row" and .details.claimed==false)' < ~/.nookplot/weekly-rewards.jsonl

Dashboard

New MCP Tracks tab in public/dashboard.html shows summaries from every new module + a documentation table of what each track does. /api/mcp-tracks returns the same data as JSON for scripting.

MCP-derived tracks — activation pass (2026-05-25, fifth-pass)

Built on top of the fourth-pass scaffolding. The previous pass shipped 16 browse-only modules. This pass adds active write actions, gated behind explicit opt-in flags, plus a verdict-timeline chart and a paid egress proxy.

New auto-write flows (all default OFF)

Other additions

• src/egress.ts — Paid HTTP egress proxy via /v1/actions/http. Hard budget guardrail: refuses calls once EGRESS_DAILY_BUDGET (default 5 cr/day = ~33 calls) is exhausted. Resets at UTC midnight. Surfaced as dashboard card.
• src/diagnostics.ts — Two new probes:
  • probeAdversarialAssignments(runtime) — checks if the gateway has assigned us as an adversarial reviewer on any submission. Logs + announces if found.
  • probeIncomingChallenges(runtime) — checks if our own traces have pending counter-arguments to defend. Logs + announces if found. Both run on the 2h diagnostics tick.
• src/mining-dataset.ts — renderPeerTraceBlock + fetchPeerTraceBlockForChallenge pull top-3 peer traces in the challenge's first domain. Now spliced into every solve's context block (BOT_PEER_TRACES=0 disables).
• src/attention-signals.ts — runCollabFinderTick runs once / 7 days; uses match_geometric to find embedding-similar agents. Pure logging — no DMs.
• src/subscriptions.ts — autoSpawnTunnel(port) detects cloudflared or ngrok in PATH and spawns a tunnel, capturing its public URL into BOT_WEBHOOK_URL. Gated by BOT_TUNNEL_AUTOSPAWN=1. Process is killed cleanly on shutdown.
• Dashboard — New verdict-timeline chart on the MCP Tracks tab (Chart.js line chart of V9 composite scores over time, from /api/verdicts). Egress card added. egressSummary() exposes calls + budget for monitoring.

Cost guardrails — recap

If every auto-write flag is flipped on simultaneously at default caps: worst-case daily burn = 0.40 cr / day (≈ 0.1 cr per surface). Less than half the existing vote/follow/comment loop spend.

Failure semantics

Every auto-write flow follows the same pattern:

1. Generate FIRST, accept/apply SECOND. This way, if the generator declines or produces too-short content, we never claim an action we can't complete. Refusing an unfinishable commitment is always cheaper than failing one.
2. Triple gate: (a) explicit env opt-in, (b) hard quality threshold, (c) per-day cap.
3. Sentinel returns: model can return literal "DECLINE" or "EMPTY" to gracefully refuse without a real failure.
4. JSONL log of every decision — including skips and declines. jq works for forensic audits.

Tunnel auto-spawn (optional)

If cloudflared or ngrok is in $PATH AND BOT_TUNNEL_AUTOSPAWN=1:

1. Bot spawns the tunnel process pointing at our dashboard port (default 7878).
2. Reads stdout/stderr until a public URL appears (matches *.trycloudflare.com or *.ngrok-free.app).
3. Sets BOT_WEBHOOK_URL in-process. Subscriptions bootstrap proceeds with the new URL.
4. On shutdown, sends SIGTERM to the tunnel.

Why opt-in: a tunnel exposes our local dashboard port to the public internet. Auto-spawning by default is a security footgun.

Tests

108 tests pass (was 101). 7 new tests cover renderPeerTraceBlock, scoreBountyForAutoApply, plus expanded coverage of the existing utilities.

Risk-surface fixes (2026-05-25, sixth-pass)

Six high-priority risk surfaces from the fifth-pass evaluation shipped in this pass, plus one production-noise fix (the learnings-browse 404).

What landed

1. Verify shared cap. New src/quotas.ts tracks verify + crowd-jury actions in a single counter (gateway enforces 40/24h combined per-tier). Local cap bumped to 38 with a 2-slot buffer. On a 429 with the shared-cap signature, we record limit-hit and halt further attempts until UTC midnight — saving the SDK retry storm visible in the previous logs. Both src/index.ts (verify loop) and src/crowd-jury.ts increment the shared counter. Helper: isVerifyCapError(msg) detects the error.
2. Auto-write daily cost cap. Same quotas.ts exposes canAutoWriteNow(estimatedCost) and recordAutoWrite(surface, cost). Every auto-write surface (bounty apply, swarm submit, teaching deliver, clarification offer) checks it before proceeding. Default cap: BOT_AUTO_WRITE_DAILY_COST_CAP=1.0 NOOK. Even with every auto-write flag flipped on at default per-action costs (0.05-0.10), we stay well under the cap.
3. Reputation-aware bounty cooldown. effectiveBountyAutoApplyCap() reads the last BOT_BOUNTY_LOOKBACK=5 applications. If approval rate < BOT_BOUNTY_APPROVAL_FLOOR=0.20, daily cap is halved for the next BOT_BOUNTY_COOLDOWN_DAYS=7 days. Prevents slow-rolling reputation damage from shallow auto-applications.
4. Rolling-window JSONL tail. readJsonlTail<T>(path, maxLines) in src/util.ts reads only the last N lines from disk, scaling the read buffer dynamically. Dashboard snapshot now uses it for mining (2000), claims (500), verify stats (500), and network status (200). Full-read is preserved on /api/history where the whole timeline is explicit.
5. Generation semaphore. New src/generation-semaphore.ts caps concurrent Venice calls at BOT_MAX_CONCURRENT_GENERATIONS=3. Higher priorities preempt queued lower-priority waiters. Ranks: mining=100, swarm=70, bounty=50, teaching=40, clarification=30. withGenerationSlot(priority, fn) convenience wrapper used by mining solver + all 4 auto-write generators.
6. Tunnel dashboard auth token. WEB_AUTH_TOKEN env, when set, requires Authorization: Bearer <token> on /api/* (except /api/health). The token is injected into the dashboard HTML at serve time so the front-end fetch() calls automatically pass it. Static files stay public so the page loads even without a token (and shows an auth-error in the JSON panels).

Bonus

• Fixed learnings browse failed (404). src/engagement.ts was hitting /v1/mining/learnings/browse (404) — switched to /v1/mining/network-learnings (the working path that citation-velocity.ts uses). Eliminates the recurring warning line.

New env knobs

# Verify shared cap (gateway is 40, we cap at 38 for buffer)
BOT_VERIFY_SHARED_CAP=38

# Auto-write daily cost cap (NOOK)
BOT_AUTO_WRITE_DAILY_COST_CAP=1.0

# Per-surface action costs (default 0.10 NOOK each, 0.05 for clarify)
BOT_BOUNTY_AUTO_APPLY_COST=0.10
BOT_SWARM_SOLVE_COST=0.10
BOT_CLARIFY_OFFER_COST=0.05
BOT_TEACHING_DELIVER_COST=0.10

# Reputation-aware bounty cooldown
BOT_BOUNTY_AUTO_APPLY_DAILY_CAP=2
BOT_BOUNTY_APPROVAL_FLOOR=0.20
BOT_BOUNTY_LOOKBACK=5
BOT_BOUNTY_COOLDOWN_DAYS=7

# Concurrent generation cap (Venice in-flight)
BOT_MAX_CONCURRENT_GENERATIONS=3

# Dashboard auth (optional, required if BOT_TUNNEL_AUTOSPAWN is used)
WEB_AUTH_TOKEN=

Tests

131 tests pass (was 118). 13 new tests cover:

• quotas.isVerifyCapError (cap-detection patterns)
• quotas.canVerifyNow + canAutoWriteNow (shape)
• quotas.effectiveBountyAutoApplyCap (lookback / floor logic)
• generation-semaphore (acquire/release + priority preemption)
• util.readJsonlTail (tail-read with malformed lines, small files, large files, missing files)

What's left in the backlog (deferred from the 5th-pass risk list)

The following 8 risks were catalogued in the previous pass evaluation but did not ship — fix only if/when they surface as real problems. Each has a target solution that does NOT neuter activity.

How to spot which guardrails are active

Dashboard MCP Tracks tab now shows Quotas + Generation slots cards. The quotaSummary() JSON returns:

{
  "verify": { "sharedCount": 23, "sharedCap": 38, "limitHit": false, "remaining": 15 },
  "autoWrite": { "costToday": 0.30, "cap": 1.0, "remaining": 0.70 },
  "bounty": { "effectiveCap": 2, "cooldownReason": "lookback insufficient (3/5)" }
}

And semaphoreSnapshot():

{ "active": 1, "capacity": 3, "queued": 0 }

Both are part of /api/snapshot now (see quotas + generationSemaphore fields).

Backlog cleanup (2026-05-25, seventh-pass)

All 7 backlog items from the sixth-pass shipped. Risk #12 was already fixed by the generation semaphore.

What landed

#8 — Venice cost tracking + daily alert

src/venice-cost.ts instruments every chat() call with token + cost telemetry, written to ~/.nookplot/venice-costs.jsonl. A blended credits-per-million-token rate per model (conservative estimate) gives us an honest daily spend total.

• Per-model breakdown in veniceCostSummary() (now in /api/snapshot)
• shouldFireDailyAlert() triggers a single console.warn once daily spend crosses BOT_VENICE_DAILY_COST_ALERT (default 50 credits)
• parseFailureRateByModel(lookback) returns recent parse-fail rate per model — consumed by the mining circuit-breaker (#16)
• tagLatestCallOutcome(model, outcome, callSite) lets callers tag a finished call after-the-fact (called from logParseFail in mining.ts)

#9 — Webhook replay polling fallback

src/subscriptions.ts now tracks lastSignalAt in-memory and exposes isWebhookStale() (true if a webhook is configured but no signal has arrived in BOT_WEBHOOK_STALENESS_MS window, default 1h). The attention- signals tick calls recordWebhookSignal() on any successful fetch so polling-derived activity counts as freshness. Webhook health is now visible on the dashboard via subscriptions.webhookStale + lastSignalAt.

#10 — Specialization-drift detector

src/specialization-drift.ts runs once per 24h, pulls /v1/network/wiki, and reports:

• Tags we declare that aren't in the network catalog (unmatchedTags)
• Top 10 network domains by citation count we DON'T currently track (candidateAdds)
• Likely renames detected via trigram-Jaccard ≥ 0.60 (candidateRenames)

Output is logged to ~/.nookplot/specialization-drift.jsonl and surfaced on the dashboard. Does NOT auto-update env — operator decides.

#12 — Solver memory pressure

Already fixed by the generation semaphore (sixth-pass #5). No additional work needed.

#13 — Reputation cooldown for teaching + clarification

Extended quotas.ts with effectiveTeachingCap() and effectiveClarifyCap(). Both work on the same proxy: error rate within BOT_AUTO_WRITE_LOOKBACK=6. If errors ≥ BOT_AUTO_WRITE_ERROR_FLOOR=0.50, daily cap is halved. Wired into clarifications.ts and teaching.ts auto-paths.

#14 — Central audit log

src/audit.ts provides recordAudit(surface, outcome, notes, meta). Writes one short JSONL line per action to ~/.nookplot/events-audit.jsonl. Sites that record audit events: mining solves, verifies, crowd-jury scores, bounty applies, swarm submits, clarification offers, teaching deliveries. New /api/audit?limit=N endpoint returns recent events + an aggregate summary for the dashboard.

#15 — Tunnel install script

scripts/install-tunnel.sh — one-command setup for cloudflared. Detects macOS (homebrew) vs Linux (dpkg + ARM/x86 binary), with ngrok fallback detection if cloudflared isn't preferred. Prints next-step instructions including a random WEB_AUTH_TOKEN generation — crucial because the tunnel exposes the dashboard publicly.

#16 — Mining solve cost circuit-breaker

src/models.ts now accepts an optional failureRates arg in pickModelAB. If supplied, models with attempts ≥ BOT_MODEL_PARSE_FAIL_MIN_ATTEMPTS=5 AND rate ≥ BOT_MODEL_PARSE_FAIL_THRESHOLD=0.30 are sidelined from the A/B rotation. Fail-safe: if filtering would leave zero models, we fall back to the full pool (better to burn credits than halt mining entirely). mining.ts reads the failure-rate map via parseFailureRateByModel() on every solve attempt; sidelined models are logged.

New env knobs

# #8 Venice cost
BOT_VENICE_DAILY_COST_ALERT=50

# #9 Webhook staleness window (ms before considered broken)
BOT_WEBHOOK_STALENESS_MS=3600000

# #13 Teaching + clarification reputation cooldown
BOT_AUTO_WRITE_LOOKBACK=6
BOT_AUTO_WRITE_ERROR_FLOOR=0.50
BOT_TEACHING_DELIVER_DAILY_CAP=2
BOT_CLARIFY_OFFER_DAILY_CAP=3

# #16 Model circuit-breaker
BOT_MODEL_PARSE_FAIL_THRESHOLD=0.30
BOT_MODEL_PARSE_FAIL_MIN_ATTEMPTS=5

Tests

140 tests pass (was 131). 9 new tests cover:

• estimateCallCost per-model rate scaling
• filterPoolByParseFailure (above/below threshold, fail-safe empty pool)
• findRenames (exact match, trigram similarity, no-match)

Dashboard

/api/snapshot now includes:

{
  "veniceCost": { "spentToday": 12.5, "alertThreshold": 50, "remainingBudgetBeforeAlert": 37.5, "byModel": {...} },
  "specializationDrift": { "lastChecked": "...", "unmatchedCount": 0, "candidateRenameCount": 0, "topCandidateAdds": [...] },
  "audit": { "totalEvents": 248, "last24h": {...}, "outcomes": {...} }
}

Plus a new /api/audit?limit=100 endpoint returns the audit-event stream for tailing.

Wide-discovery refactor (2026-05-26)

Premise reset. Frontier models at xhigh thinking are general-purpose. Pre-filtering work opportunities by topic-tag overlap was leaving easy NOOK on the table because the model's capability is the actual gate, not our keyword tags. We refactored every discovery + auto-write surface so:

What protects us from spam apply

All the existing guardrails still apply (see fifth/sixth-pass sections):

• BOT_AUTO_WRITE_DAILY_COST_CAP=1.0 global NOOK ceiling
• Per-surface daily caps (2 bounties, 2 lessons, 3 clarifications, 1 swarm-solve/tick)
• Reputation-aware cooldowns halve the cap on a low approval rate
• Generation semaphore caps concurrent Venice calls at 3
• DECLINE/EMPTY sentinels from generators let the model refuse cheaply

New env knobs

BOT_BOUNTY_SURFACE_TOP_N=10          # how many native bounties to log per tick
BOT_BOUNTY_AUTO_APPLY_MAX_APPS=10    # don't auto-apply to crowded bounties
BOT_BOUNTY_AUTO_APPLY_MIN_DESC=200   # description chars floor for auto-apply

Tests

145 tests pass (was 141). 4 new tests cover:

• Content gates passing without tag overlap (no false rejections)
• Reward / desc / competition floors all reject independently
• Tag overlap adds a positive score bonus (ranking helper)
• scoreBountyForSurface ranks correctly + handles wei normalization

2026-06-03 — runtime-error sweep (eighth pass)

After a long-running bot process accumulated 8 days of state, a /api/snapshot showed 24h error rate at 85% and the auto-observe loop surfaced five recurring gateway/network failures every solve cycle. All fixed in one pass.

Bugs hit

Operational note

The bot needs three processes: npm start (bot daemon), npm run web (dashboard on :7878), and npm run proxy (Venice forwarder on :18790). The proxy is the single point of failure for all Venice LLM calls — when it dies, every solve fails with fetch failed. The bot does not auto-spawn it.

Package updates

• @nookplot/runtime 0.5.130 → 0.5.139 (9 patches; likely the source of the workspace/learning shape changes)
• tsx 4.22.2 → 4.22.4
• ws 8.20.1 → 8.21.0 (top-level patched; transitive ws in ethers and @nookplot/runtime still on 8.0–8.20, "no fix available" upstream — moderate severity)

Tests

161 tests pass (was 152). 9 new tests cover:

• normalizeWorkspaceContent: null/undefined fallback, array wrapping
• traceTextFromIpfsPayload: string passthrough, nullish/primitive, traceMarkdown pick, fallback chain through markdown→content→body→text, nested {text} recursion, all-non-string returns null, empty-string skip-and-continue

Files touched

• src/mining.ts — postSolveLearning IPFS upload + correct payload (line 786-803)
• src/index.ts — traceTextFromIpfsPayload moved out (line 487); now imported from ./trace-payload.js
• src/trace-payload.ts — new file, side-effect-free for testability
• src/venice.ts — default timeoutMs 60s → 180s (line 64)
• src/refine.ts — explicit 180s / 240s timeouts on critique / revise
• src/__tests__/backend.test.ts — 9 new tests
• package.json / package-lock.json — runtime/tsx/ws bumps

2026-06-07 — gateway shape-drift sweep (ninth pass)

Four days after the eighth pass, the auto-observer flagged three new shape mismatches the gateway introduced over the weekend. Same class as 06-03 (workspace content shape) — the gateway evolved a dimension we hadn't anticipated and our defaults were rejected.

Bugs hit

Tests

170 tests pass (was 161). 9 new tests cover region-status map coverage, override behavior, starter-coerce string passthrough, nullish/primitive fallback, code/content/text/body extraction, files[] joining, and bare string array joining.

Operational impact

24h after shipping the fixes, mining errors dropped from 60/day (06-07) to 3/day (06-08). Verify path stopped burning 4-retry ladders on the same gated submissions across ticks.

2026-06-08 — unified skip-cache architecture (tenth pass)

The 06-07 fix for the comprehension gate (#2 above) introduced a pattern worth generalizing: gateway returns permanent 4xx with diagnostic body → SDK retry layer treats as transient → 78s ladder burned → no skip cache → next tick we hit it again. The auto-observer flagged five more instances of this same shape across mining and verify, sharing nothing except the gateway anti-pattern. One pass handled them all.

Why a unified module

Before this pass, every fix invented its own Map<id, ts> + ad-hoc pattern matcher. The 06-07 fix had comprehensionGateUntil. The 06-03 fix had recentSolverVerifyCount (different mechanism but same intent). Each addition was 10-15 lines of boilerplate. Five more in one pass would have been ~75 lines of duplication.

Instead: src/skip-caches.ts exports a single SkipCache class + detector functions. Each track creates a named instance with its own TTL. Detectors live alongside the caches so the single-source-of-truth problem (multiple regex copies drifting) doesn't bite.

Bugs handled

Cache-saturation warning

The diversity cache cuts both ways: each entry blocks future verify attempts on that solver for 14d. If a small pool of solvers dominates the verifiable surface, the cache can starve our verify income. Added maybeWarnDiversitySaturation() that logs a one-shot warn when the cache holds ≥20 entries (configurable via BOT_DIVERSITY_CACHE_WARN_AT). The flag re-arms when the cache drops below half-threshold, so re-saturations get a fresh warn.

Cross-checked against production strings

After noticing four of five caches had zero fires post-restart, did a post-hoc validation: grepped observations/*.md for the actual error bodies the gateway returned in the wild, then added regression tests asserting each detector matches the real string. These tests catch the class of bug where the gateway tweaks phrasing and our regex silently stops matching.

Tests

184 tests pass (was 183). 13 + 1 new tests: SkipCache TTL behavior, all 5 detectors with positive + negative cases, timestamp parser fallback, real-body regression suite, diversity-cache size growth.

Files touched

• src/skip-caches.ts — new, ~140 lines
• src/index.ts — verify-path wire-in: pre-flight checks + 410/diversity detection in catch; saturation warner call
• src/mining.ts — mining-path wire-in: pre-flight checks for already-submitted + guild-claimed; 409/400/429 detection in catch
• src/__tests__/backend.test.ts — 14 new tests
• package.json / package-lock.json — runtime 0.5.139 → 0.5.142, @types/node patch

Honest read on results

24h post-deploy:

• Mining errors: 60 → 3 (95% reduction). Real win.
• Diversity cache fires: 11 — dominant source of retry storms.
• Comprehension gate fires: 3.
• Other four caches: 0 fires (either rare conditions or detectors stale — the regression tests above pin them to known-good gateway strings to prevent silent rot).
• Verifications landed today: 7 (was 20 yesterday) — the diversity cache may be cutting too aggressively. Watch the saturation warn.
• Dashboard "winning" score still mixed (50) because 23 pending @ 0.6/3 verifiers dominates — network-side starvation, unrelated to our work.

2026-06-08 — competitive-posture sweep (eleventh pass)

After 24h with the skip-cache fixes, the bot flipped from mixed(50) → winning(65). Mining error rate 84% → 41%. That's the floor of recoverable quality from the operational side. The next wave of work is posture improvements — pushing the surfaces we control (verify volume, specialization, calibration, crowd_jury) without tripping the anti-abuse gates documented in node_modules/@nookplot/mcp/dist/tools/reasoningWork.js.

Changes

Compliance check against the documented anti-abuse gates

Captured from reasoningWork.js:

• 24h+ account age ✅
• 60s verify cooldown ✅ (we sleep 70s)
• 30/day shared cap ✅ (verifies + crowd-jury combined; our changes still respect)
• Quorum+2 / submission ✅ (gateway-enforced)
• Cannot verify own or same-guild ✅ (gateway-enforced)
• Solver diversity 3+/14d ✅ (gateway-enforced; we also pre-skip)
• Rubber-stamp detection on consistently high scores ✅ (current score variance is naturally healthy, stdev 0.11–0.25; the calibration prompt targets the gateway-intended per-dimension spread)
• Crowd-jury Phase-4 uniform-high penalty ⚠️ (existing crowd-jury grader uses 0-100 calibration with explicit anti-uniform-high guard — unchanged this pass)

Tests

185/185 pass. No new tests added this pass. The changes are at three levels that resist clean unit tests:

• Prompt change (calibration) — needs a real LLM to validate
• Batch-size sizing — single ternary; the integration-level behavior matters
• Crowd-jury skip-cache wiring — reuses tested primitives

This is a deliberate trade-off, documented here so a future read of this section flags whether the choice aged well. If the calibration prompt drifts back to undershooting, that's the symptom that test coverage should have caught.

Files touched

• src/index.ts — verify batch sizing, backfill from skipped, under-use warn; score-calibration prompt
• src/crowd-jury.ts — DAILY_CAP env-configurable, finalized skip cache wire-in
• .env — BOT_SPECIALIZE_DOMAINS=distributed-systems

2026-06-08 — measurability follow-up (twelfth pass)

The eleventh pass shipped four changes without unit tests, with a documented "this resists clean unit testing" excuse. This pass closes that gap. Same day, no behavior intent change — just extracting the testable parts and backing out one speculative bump. The point is to demonstrate that "I chose easy-to-describe over easy-to-measure" can be reversed in the same session if you actually try.

Changes

What the new tests catch

• computeVerifyBatch: 7 cases including the explicit "no cliff at remaining=15" regression case
• pollsRemainingBeforeUtcReset: floor-at-1, invalid-input handling
• auditVerifyCalibrationPrompt: positive (shipped prompt passes), negative (permissive bad prompt flags anti-guards + anchors as missing), one-sided (missing anti-floor while having everything else)
• recordSpecializationMatch/lowRatioTickCount: rolling window math, history trimming at 5, re-arm-after-recovery semantics

Tests

199/199 pass (was 185, +14 new). 4 new module suites — pure functions, no LLM mocking needed.

Files touched

• src/verify-batch.ts — new, ~40 lines, 2 helpers
• src/verify-calibration.ts — new, ~50 lines, prompt const + audit helper
• src/specialization-supply.ts — new, ~50 lines, rolling window
• src/index.ts — wires up new helpers
• src/mining.ts — records match ratio + maybeWarn at the end of each poll log
• src/crowd-jury.ts — default cap back to 10
• src/__tests__/backend.test.ts — 14 new tests across 4 suites

Meta

This pass is exactly the trade-off the self-feedback flagged: harder to write a one-line summary, easier to assert behavior next month. That choice was available in the eleventh pass too; I just took the easier path. Both passes ship the same user-visible behavior; this one survives drift better because the test suite is now load-bearing.

2026-06-10 — reciprocal-verification + poll-saturation (thirteenth pass)

Two production symptoms surfaced from the 06-10 log tail. Both are operational-layer gaps the existing skip-cache infrastructure handles naturally — just needed one more detector and a poll-level metric.

Changes

What the new tests catch

• isReciprocalVerificationError: positive (real production body), case-insensitive variant, negative (other 429 bodies). Added to the [real-body] matches all production gateway strings regression too.
• recordDiversityPollSaturation / highRatioTickCount / maybeWarnDiversityPollSaturation: rolling-window math, inclusive-at-0.80 boundary, HISTORY_LEN=5 trimming, re-arm semantics, empty-window safety.

Tests

205/205 pass (was 199, +6 new across 2 new test cases + 1 new suite). Pure functions, no LLM mocking.

Files touched

• src/skip-caches.ts — added cache, TTL constant, detector
• src/diversity-poll-saturation.ts — new, ~55 lines
• src/index.ts — wires both into verifyOneSubmission (pre-skip + catch) and pollVerifiableSubmissions (per-poll metric)
• src/__tests__/backend.test.ts — +6 assertions

Meta

This pass is the same shape as the twelfth: pull a measurable signal out of an operational symptom, ship a unit test that asserts the signal, mark the gateway-body regression with the exact production string so phrasing drift fails closed. Eight cumulative permanent-failure body patterns are now covered (isAlreadySubmittedError, isFinalizedError, isDiversityBlockError, isReciprocalVerificationError, isEpochCapError, isGuildClaimedError, and the comprehension/artifact gate handled in index.ts, plus the shared-verify-cap 429). Each one formerly cost ~82s of wall time per hit; each is now a single Map lookup.

2026-06-11 — listing-dupe incident + playbook-research pass (fourteenth pass)

Two halves: an incident fix, then eight changes derived from a research sweep (gateway /v1 catalog diff, our claims ledger, and two GitHub operator-playbook repos found via web research — see sources below).

Incident: 34 duplicate marketplace listings

hasActiveServiceListing called /v1/services/agent/:addr — an endpoint that never existed (404). The catch soft-failed to "no listings" → one new listing per boot for 18 days → 34 active duplicates (we were 34 of 39 listings in the verification category). Deactivated all 33 dupes on-chain (3 passes; concurrent bot txs caused nonce races), kept the 05-19 original (listing 415). Fix: correct endpoint (/v1/marketplace/provider/:addr, stats.totalListings is cumulative), fail-closed on error/shape-drift, plus an independent local onboarding.jsonl guard that short-circuits before any network call. Same dual-guard applied to the project check. Lesson encoded in src/onboarding.ts docstring: existence checks must fail CLOSED — fail-open + retry-on-boot = unbounded duplicates.

Research findings that drove the changes

• From the claims ledger: one landed solve ≈ 10-20k NOOK (emission-pool share), one verify ≈ 0.9k. Failed submissions burn epoch slots (12+1/day).
• Comprehension answers are graded by cosine ≥0.30 vs the FULL IPFS trace — answering from a truncated detail summary (~0.27) is a guaranteed fail.
• Guild challenge claims: free, 2h exclusive, no epoch-slot cost.
• Authorship yield at current volume is negligible (~53 NOOK from 10 authored challenges per an operator's logs) → widen specialization, revisit when verifier supply recovers.
• Top contribution-leaderboard agents differentiate on knowledge bundles (micro-royalties per access).
• Jun 5+ structured verification format: 4 per-dimension rationale fields ≥80 chars.

Changes

Also: specificityCategories/countSpecificity moved to specificity-gate.ts (re-exported from mining.ts) to break an import cycle.

Tests

229/229 pass (was 211, +18). New suites pin the EXACT production specificity-400 body for the parser, competition-sort ordering, transient vs permanent error classification, alternate-model exclusion, bundle CID selection/throttle, and the onboarding dupe-incident regression (6 tests from the incident fix earlier today, incl. the exact provider-endpoint response shape).

Sources

• github.com/nookprotocol/nookplot (official monorepo)
• Third-party operator playbook/toolkit repos (used strictly as gate-behavior intel, not as recommendations)
• Gateway live probes: /v1 catalog, /v1/marketplace/*, /v1/contributions/leaderboard, /v1/mining/bundlable-learnings/*

Watch next

• First specificity-400 in the log should show 🔬 ... enriched retry and never a third attempt.
• 📦 bundle tick fires ~17min after boot daily; first bundle expected immediately (50 bundlable CIDs waiting at ship time).
• Verify path sends rationale fields — if the gateway rejects unknown fields (unlikely), the error will name them; remove or gate by env.
• Inbox has 12 unread DMs but /v1/inbox 500s server-side (gateway bug, reported shape-independent). Re-probe occasionally.

Same-day validation (a few hours later)

• Rationale fields ACCEPTED by gateway — 3 verifies landed (0.45/0.50/0.40/0.35, 0.70/0.50/0.55/0.45, 0.68/0.42/0.51/0.59) once the diversity logjam broke (fresh v1 supply entered the pool).
• Full-trace guard fired 5× in its first hour — pool turned out to be full of submissions with MALFORMED trace CIDs ("Invalid CID format"), exactly the doomed-comprehension case the guard prevents.
• First bundle attempt FAILED: gateway's own suggestedTags included "cs.AI" which the bundle contract rejects (lowercase alnum+hyphen only). Fixed with sanitizeBundleTags (fifteenth pass below).
• Winning score 65 → 90.

2026-06-11 — four new channels + Fable default (fifteenth pass)

User-approved follow-on from the fourteenth-pass research: open the untouched revenue/coordination channels and switch the backend default model to claude-fable-5 (landed on Venice today).

Changes

Tests

237/237 pass (was 229, +8: challenge-posting helpers, intent fit scoring, 429 telemetry smoke, and the exact production "cs.AI" tag regression).

Ops

• One-shot validation cron scheduled for 06-12 08:23 local (session-bound): scorecard on specificity gate / guild claims / submit rate / bundle.
• Dashboard restarted to pick up widened .env specialization display.

Bundle saga postscript (same evening)

The first bundle took FOUR layers of gateway/contract validation to land, each discovered live:

1. Tag format 400 ("cs.AI") → sanitizeBundleTags.
2. Contributor-author 400 — the gateway's own bundlable-learnings CIDs are gateway-pinned, NOT ContentIndex-registered to us. Switched source to knowledge-published.jsonl entries with txHash (signed /v1/memory/publish → relay path = registered authorship).
3. On-chain inner revert at 24 CIDs and 10 CIDs, while 3 CIDs succeeded — our first live bundle. Either a size cap in [4,9] or a per-day creation cooldown (both failures followed the success). MAX_CIDS_PER_BUNDLE now 8; tomorrow's tick discriminates — if the 8-CID vol. 2 lands it was the cooldown, if it reverts drop to 3.
4. Throttle made adaptive: daily while a registered-CID backlog exists (21 waiting), weekly at steady state.

Watch next

• Tomorrow's 📦 bundle tick: does the 8-CID bundle land? (cooldown vs size-cap discriminator, see postscript above)
• Channel ticks fire 17-25 min post-boot: manifest+heartbeat (watch for a capacity-shape 400), intents browse, challenge post, inbox probe.

2026-06-12 — cohort benchmark + rejection learning (sixteenth pass)

From the same-cohort comparison (5 peers created 05-14→05-19 like us, pulled via the public /v1/mining/submissions/agent/:addr): we ran 59 subs/7d vs their 71-74 (~81% of cohort pace) with the highest avg composite (0.723) but 9 rejections/100 vs their ~0-1. Both additions are observability-only — no new gates, no thresholds, no behavior changes.

Notable discovery for later: verifiable-challenge rejections come with retry_guidance (e.g. "19 submission slot(s) remaining — fix your solution and resubmit"). We do NOT auto-resubmit (epoch slots are scarce and a bad fix burns another), but the post-mortem note captures the guidance — a future pass could add fix-and-resubmit for deterministic kinds where the failing tests are visible.

Tests

241/241 pass (+3: window counting, env address validation, default cohort).

• Venice spend will rise with Fable on mining solves (~2× opus blended). Alert threshold stays $50/day; expected actual <$5/day.
• If intents candidates look good in intents.jsonl after a few days, consider flipping BOT_INTENT_AUTOPROPOSE=1.

2026-06-15 — verify-carousel + observer + model revert (seventeenth pass)

Diagnosed from a "how's the bot doing" check that found the verify track dead for 3 days (last ✅ verified 06-12) and the self-observer logging log=0 lines. Root causes were not what the rolling observations claimed (they kept proposing fixes against a non-existent src/verification.ts). Six fixes, all validated (241/241 tests, tsc clean) and live after a proxy+bot+dashboard restart.

Tests

241/241 pass, tsc --noEmit clean. Updated the models suite for the opus-4-8 default + pool; no new tests (fixes are in index.ts, which self-imports main() so its helpers aren't unit-tested — validated live in the log instead).

Ops

• Found the launch model: bot/proxy/dashboard run detached (npm start / npm run proxy / npm run web, stdout redirected to ~/.nookplot/logs/*.log, ppid 1). Restart = kill the pid then nohup npm <script> >> <log> 2>&1 < /dev/null & disown. Proxy must be up (:18790) before the bot — it's the SPOF for all Venice calls.
• Restarted all three this session (twice: once for fixes 1–5, once for the model revert). Snapshot API (:7878) is back.

Watch next

• Verify budget should climb toward 30/day now the carousel is broken (permanent-CID submissions stop hogging poll cycles). Was 1/38 at restart.
• Observer next hourly tick should log log=600 lines (not 0).
• opus-4-8 on mining first exercises at the 02:00 UTC epoch (today was capped 13/13); watch submit-rate + Venice spend (~25/M blended vs fable's ~50). claude-fable-5 is still in MODEL_EFFORT/cost tables as a dormant lookup — re-add to pools only if Venice fixes its 500s.
• deepseek override fires its skip-log (🚫 verifiable override … sidelined) only on verifiable-kind challenges at next epoch.

Review follow-up (same session)

Self-review flagged the CID classifier as the highest-risk new logic (false "malformed" = permanent lost earning, persisted across restarts) and untested. Hardened + extracted:

• isWellFormedCid / isPermanentCidError moved to src/trace-payload.ts (the side-effect-free home, so they're unit-testable without triggering index.ts's main()) and given 7 tests (truncated placeholders, real CIDv0/CIDv1, base36/base58 edge cases, error-message classification).
• Guard is now length-keyed, not prefix-keyed: accept any ≥40-char base-alnum string (real CIDs are ≥46) and let the gateway 400 catch genuine bad hashes downstream. The old /^[bzfBZF]…/ regex would have permanently dropped valid base36 (k…) CIDv1s; truncation (~12 chars) is the real signal.
• Dead postSolveLearning removed (mining.ts) — zero callers after the submit-time call was dropped; composePostSolveLearning stays (tested).

Tests 241 → 248; tsc clean; bot restarted, hardened classifier live (⏭ trace CID permanently invalid still firing on the truncated CIDs, no false-skips).

Throughput follow-up (same session)

A "how are we earning" check found both revenue tracks still low despite the fixes — and traced each to a distinct cause beyond the original bugs.

• Mining cap misaligned with the epoch boundary. loadCaches counted submissions over a rolling 24h window (now − 24h), so yesterday's 13 kept the cap reading 13/13 for hours after the gateway opened fresh slots at 02:00Z (observed: 13/13 with 0 actual submissions post-reset). Fixed: count since epochDayStartMs(now) (new pure, tested helper = most recent 02:00Z). Confirmed live — mining resumed immediately on restart: ⛏ attempt … → ✅ published cid … tx=0x…, running claude-opus-4-8 at reasoning_effort=high. No over-mining risk — the gateway's own "Maximum 12 regular" cap is still the true ceiling; this just stops the local window over-restricting. mining.ts.
• Verify pool is frequently ~all CID-broken upstream. The CID fix stopped the carousel but the bot still verified ~0 because the gateway was serving truncated/502 trace CIDs. Added a salvage: probe comprehension first, and for submissions with no comprehension gate, verify from the detail summary (the exact path no-CID submissions already use) instead of blanket-deferring. Gated submissions still skip/defer (they genuinely need the full trace). Off-switch BOT_VERIFY_DETAIL_FALLBACK=0. index.ts. Live note: the lever is correct but pool-dependent — in the first window the CID-broken submissions were all comprehension-gated (correctly deferred, new (comprehension-gated) log note), so verify is still upstream-gated; salvage fires when an un-gated broken-CID submission appears.
• Also saw the deepseek override circuit-breaker fire live for the first time at the fresh epoch: 🚫 verifiable override deepseek-v4-pro sidelined (parse-fail 100%) — using A/B pick grok-4-3 / openai-gpt-55.

Tests 248 → 249 (+epochDayStartMs); tsc clean.

2026-06-17 — verifiable-solve robustness + 4.8 consolidation + channel audit (eighteenth pass)

• Logging stall fixed. The bot was alive but its >>-redirected stdout stopped reaching bot.log ~6h (process fine, log frozen → dashboard log-tail frozen). Relaunched detached through tee (line-flushed) — the robust setup util.ts already documents. Restart recipe: nohup bash -c 'npm start 2>&1 | tee -a "$HOME/.nookplot/logs/bot.log"' >/dev/null 2>&1 </dev/null & disown.
• python_tests/javascript_tests/exact_answer robustness (mining.ts) — the fallback models (grok/gpt-55/gemini) parse-failed with missing "solution": the JSON truncated before the (last) solution field at max_tokens:2500, or the model emitted prose/markdown. Fixes: (a) schema now emits the solution/answer field FIRST, (b) max_tokens 2500→6000 (1200→2000 for exact_answer), (c) new parseVerifiableSolution falls back to the longest fenced code block when JSON has no solution. Pure + tested (parseVerifiableSolution, extractFencedCode). Note: this fixes the parse-fail half; the specificity-gate 400 half (summary <35 on trivial tasks) is orthogonal and still bites — these are 10-NOOK challenges.
• Consolidated opus-4-7 → opus-4-8 for our own model choices: observe loop (observe.ts), rlm-spotcheck default/fallback (rlm-spotcheck.ts), probe scripts, comments. 4-7 is KEPT in the rlm claim-normalizer known-set + the effort/cost tables — a solver may genuinely have run 4-7 (still valid on Venice) and we reproduce on the model they claimed. fable→opus-4-8 from the 17th pass means no live path now uses fable or 4-7 as our model.
• Channel audit. Active & earning: mining, knowledge-publish, post-solve + rejection learnings (85/24h), teaching, challenge-posting, bundles now landing (3-CID fix, 3/7d), guild, workspace-solves, weekly-rewards, mining-claims, citation-velocity, manifest/heartbeat, votes/follow. Alive but no work: crowd-jury (no submissions), engagement/comment (nothing engagement-worthy), bounty native-applies (+0 native every scan; only external code4rena/immunefi matches surface). Wired+scheduled but silent 7-10d (no actionable work or silent no-op — flagged, not yet fixed): predictions, oracle, endorsements, paper-reproduction, attention-signals. Transient errors seen: bounty lifecycle error: fetch failed (×9), vote feed fetch failed — likely proxy-down moments.

Tests 249 → 255; tsc clean.

2026-06-23–25 — builder-dimension experiments (exec/collab) + bounty rework

Targeted the three zeroed-but-earnable surfaces. Net: instrumentation works, levers mostly came up negative (which is itself the finding).

What scores the builder dims (reverse-engineered from /v1/contributions/leaderboard):

• commits/projects/lines — creating + committing projects (Path A; moving).
• exec — re-running OTHER agents' verifiable artifacts during verification (rerun_submission_artifact → the artifactReruns counter). NOT our own exec_code on our own projects (that in-project tick never moved it). Only ~33% of top-100 agents have exec — it's the rare verifier-side dim.
• collab — cross-agent work (reviews/MRs/collaborator). Near-universal among top-100 yet 0 for us despite 4 own projects → own-project creation does NOT score it. 2 comment reviews on-chain didn't move it → comment verdicts probably don't count; MRs (Path B2) are the likely lever.

Verify loop (index.ts) — artifact path. The standard loop filtered to verifier_kind==="standard" and skipped all code subs (so artifactReruns was structurally 0). BOT_VERIFY_ARTIFACTS=1 folds in python_tests/ javascript_tests/replication: comprehension → inspect_submission_artifact (REQUIRED gate) → rerun_submission_artifact → grade → POST /verify. Rerunnable subs are front-loaded in the sort + threshold-exempt (else they're v0 and never selected). Kind predicates live in verify-kinds.ts (isRerunnableKind, isVerifyEligible, decideFromRerun — all tested). decideFromRerun(rerun): outcomesMatch===true→correctness 1.0; false→abstain (don't vote); no signal (rate-limited/errored)→submit-time-gate 1.0. Live result: 15/15 reruns with a signal = match=false → systematic non-reproduction (our rerun env ≠ grader) → exec blocked. Diversity 429 on artifact subs falls to the generic handler because code subs lack solver_address (bounded: each sub attempted once).

Bounties moved from blind auto-apply to a human-gated preview queue (src/bounty-review.ts, npm run bounties), mirroring Path A/B. rankBounties (open + dedup + score-gate + sort) is the tested pure core.

Instrumentation. ~/.nookplot/dimension-watch.jsonl (30-min builder-dim snapshots + per-process rerun count), /api/experiments + a Reputation-tab tile (buildExperiments in dashboard-web.ts), and original/rerun outcomes now in the rerun log + artifact_rerun audit events.

New env knobs (added to canonical list)

• BOT_VERIFY_DAILY_CAP (default 38, was a hardcoded 30) — local per-day verify cap.
• BOT_VERIFY_ARTIFACTS (default off) — verify code subs via the rerun path above.
• BOT_EXEC_SCORING_AUTO (default off) — in-project test re-run tick; control, does not score exec.
• BOT_BOUNTY_REVIEW_AUTO / BOT_BOUNTY_REVIEW_SUBMIT / BOT_BOUNTY_REVIEW_DAILY_CAP — human-gated bounty queue.
• BOT_PEER_REVIEW_SUBMIT — persist so npm run reviews -- approve actually lands on-chain.
• BOT_BOUNTY_AUTO_APPLY now 0 (superseded by the review queue).

New surface: artifact_rerun audit surface; npm run bounties script.

Tests 286 → 299; tsc clean.

2026-09-20 — opus-5 → deepseek-v4-1-flash mining swap (nineteenth pass)

Operator ask: "replace opus 5 with deepseek flash 4.1 or something else that is almost as smart but way cheaper." The pre-flight probe (per the checklist: choose a model → probe first) turned into a full evidence sweep, and the incumbent lost on both axes at once.

Why opus-5 had to go

Mechanism behind the 29% spec-rejects: the one mining.ts:SUMMARY_SPECIFICITY_RULE documents — the verifiable lane has only snake_case source to enrich a summary from, so when the model's own summary is thin the gateway 400s. (An earlier draft of this entry blamed truncation at a "6k cap"; that was an artifact of the probe's 6k budget — production floors every call at 50k via venice.ts:MIN_COMPLETION_TOKENS, so it cannot be the production cause. Caught in the pre-commit review.) Not a reasoning-quality problem; a summary-format problem the cheaper model does not have.

Why deepseek-v4-1-flash ($0.375/$1.50, 1M ctx, optimizedForCode)

Probed 2026-09-20 with the two REAL solve shapes (src/_probe-dsf.ts, src/_probe-dsf-validate.ts), scored by the real specificity mirror:

Effort must be high, not max: at max it spends the entire completion budget on reasoning and returns empty content (6000/6000 tokens, zero parseable output). That is the one trap; MODEL_EFFORT pins it.

Changes

• src/models.ts — DEFAULTS.mining_solve and the mining_solve A/B arm: claude-opus-5 → deepseek-v4-1-flash; MODEL_EFFORT entry "high". opus-5 stays reachable via MODEL_MINING_SOLVE (entry + pricing kept).
• src/mining.ts — VERIFIABLE_DEFAULT_MODEL → deepseek-v4-1-flash, added to VERIFIABLE_CODE_MODELS. gemini-3-8-flash deliberately stays OUT of the verifiable lane (probe: 163s, length-capped, $0.117).
• src/venice-cost.ts — pricing entries for deepseek-v4-1-flash, deepseek-v4-flash, claude-sonnet-5 (cost accounting must not fall back to DEFAULT_PRICING and corrupt the NOOK-per-dollar arm comparison).
• src/__tests__/backend.test.ts — pool pins, default pin, effort pin, verifiable-override pins, cost-table list, circuit-breaker POOL.

Expected effect: mining inference ~$19/wk → ~$2-3/wk, and the 29% python spec-reject hole closes (that alone was ~7 wasted attempts/week).

Arm comparison from the same probe batch (standard lane, same challenge): deepseek @high 113s / 6,105-char trace / spec 3/6 / $0.024; deepseek @max 169s / 9,844 chars / spec 4/6 / $0.041; gemini-3-8-flash 24s but only a 2,011-char trace / spec 2/6 (rescued to pass by enrichment) / $0.016. The trace-length gap is the quality signal verifiers actually grade — a 2k trace reads thin next to 6-10k, so deepseek in the pool is not just a cost pick.

Further-down-tier probe: deepseek-v4-flash (0423 build), NOT yet adopted

deepseek-v4-flash ($0.138/$0.275, 1M ctx, 32k max completion, April build) probed on the same two shapes at high effort:

That is ~4-15x cheaper than v4.1-flash and ~240x cheaper than opus-5's average solve. Held OUT of the roster deliberately: both lanes have n=1-2 samples, it runs 4-5x slower (70s/171s), and its 32k completion cap is below the 40k the standard lane requests (Venice clamps rather than errors, but it is untested at that ceiling). Revisit after the v4.1-flash swap has production n≥5 — at that point either promote v4-flash to a pool arm or swap outright if v4.1-flash underperforms.

Watch next (first 72h)

• npm run mining-stats -- --24h — deepseek submit-rate per lane. If it fails the circuit-breaker (≥30% over ≥5 attempts) it sidelines automatically; the pool still has three proven arms.
• npm run rejection:check — the verifiable lane now runs on a new model; a security-test rejection wave would be the first sign the swap was wrong.
• Gateway modelUsed validator: deepseek-v4-1-flash has no historical acceptances (the family's older deepseek-v4-pro name does — 32 accepted submissions). One id-rejection sidelines the arm permanently (bounded canary); if that happens before any accept, revert to opus-5 via MODEL_MINING_SOLVE=claude-opus-5.
• Venice spend: veniceCost.spentToday should drop off a cliff; alert threshold unchanged at $50/day.

Tests 299 → 531 (suite has grown since the last pass); tsc clean. Count verified stable across runs at 531/531 after the restart (a pre-restart run read 512 — some suites depend on state the live bot writes).

Ops note

Restarted at 13:21 local (pid 75557, the previous instance had been up 20.5h). Mining was idle at the moment of the change (epoch cap active until 2026-09-21T03:33Z), so nothing in flight was lost — the swap first exercises at that window. Restart recipe is the tee variant from 2026-06-17.

Boot-race note: the restart logged ✗ another daemon instance appears to be running (pid 75557 …) — that is the instance lock doing its job, not a second daemon. It prints when a racing boot loses; the loser exits. Verified afterwards that exactly one tree survives (npm → tsx CLI → worker) and the dashboard's /api/health reports the same pid as the pidfile (daemon.identity.pid = 75557, lastActivityAgoSec ticking). If a future restart shows that line, check curl -s localhost:7878/api/health before assuming duplication.

2026-09-20 (b) — verification-drought research + capacity ELI5 (twentieth pass)

Operator asked two things: put an ELI5 for mining and verifying into the dashboard's "Capacity utilization" section, and research why we only verify 0-1 submissions per day. The research produced a correction: the first diagnosis (anti-farm gate over-firing on boilerplate) was wrong, and the fix attempt built on it was reverted after ground-truth measurement.

Dashboard changes (shipped)

• ELI5 boxes at the top of renderCapacity() (public/dashboard.html): mining = "12 tickets a day, they don't save up"; verifying = "38 checks a day, but a check-mark on a copy still pays the copy, so a low bar isn't automatically waste".
• Header metric fixed: it read wasting ~37.5 verify slots/day computed against the raw 38 cap — the exact basis capacity.ts deliberately abandoned ("it was coaching the operator to subsidize the farm"). Now measured against genuine supply, over covered days only: ~14.7 genuine verify/day left unused (6 days with supply data). New wasted.verifyCoveredDays field.

Why 0-1 verifications/day (the actual answer)

1. Downtime. The 30-min poller shows gaps of 124h (Sep 3→9) and 151h (Sep 10→17) — ~11.5 of the last 17 days offline. Offline days are 0/38.
2. The pool's solver population collapsed. Distinct solvers WE verified per week: ~100-200 through mid-August (W27-W34: 109/84/195/33/48/128/133/119), then 18 in W35 and 1-2 since. Today's pool: 72 submissions from 5 solvers, four of them holding 71/72.
3. Therefore the diversity rule is the ceiling. The gateway allows 3 verifications per solver per 14 days (SOLVER_DIVERSITY_CAP = 3, SOLVER_DIVERSITY_WINDOW_MS = 14d). Five solvers ⇒ ~15 per 14 days ≈ 1.07/day with a perfect pipeline. That is the "0 or 1" — we were never repeating solvers when we did 38/day; there were 100+ of them.
4. Live blockers on top of the ceiling. Today: 26 abstains + 19 deferrals + ~0 verified. 46% of the pool (33/72) carries a machine-generated header (Approach for "<title>" (id=…, verifier_kind=standard, domain=[…], difficulty=…). Method: decomposed contract…) posted exclusively by two accounts (0x7354b0ac…, 0x8432a8c4… — 0 non-template summaries between them). The other 19/day die on full trace unavailable (CID fetch failed (comprehension-gated)) — the full IPFS trace can't be fetched, comprehension grading needs it, so they defer 6h → 3 strikes → retire.

What was tried and reverted (worth recording)

Hypothesis from today's cache: 33 abstains, 24 at 60-79% similarity, spanning 24 different challenge ids ⇒ the dupe gate is matching shared boilerplate. Two changes were built:

• dupeWindow() in trace-fingerprint.ts — compare chars 250-1500 instead of 0-1500 (short texts < 600 chars compared whole). KEPT: it removes a real false-positive class (two cached pairs scored 0.93 on a 212-char shared header and 0.00 once skipped) and the module has a history of false abstains.
• A source guard in index.ts:verifyAbstainReason skipping the gate for non-ipfs (detail-fallback) text. REVERTED — it was harmful.

The reversion was driven by ground truth, not opinion: src/_sim-pool.ts analyses the live 72-submission pool and attributes each ≥0.5 match to same- vs other-solver. Result: all 33 abstains match ONLY a same-solver peer (other-solver matches: 0), and the abstain set is identical under both the old and new bases. The templated summaries ARE the farm content the gate exists to block; letting detail-sourced traces skip the gate would have credited exactly what the module was built to starve (quorum is a COUNT with no reject field, so a low score advances spam just like a high one). The gate is correct; the drought is supply-side.

Watch / possible follow-ups

• The two remaining levers are both network-side: more solvers in the pool (the diversity ceiling lifts with them) and the gateway's trace-CID delivery (19 defers/day). Neither is ours to fix; a note to the gateway team about comprehension-gated submissions whose trace CID never fetches is the only actionable item.
• We authored 12-14 of the pool's submissions' challenges, which we may not verify (conflict of interest) — posting more challenges shrinks our own verifiable surface. Worth keeping in mind when the posting loop raises its cap.

Tests 562 → 563 (dupeWindow window mechanics, shared-header regression, identical-body still matches); tsc clean; bot + dashboard restarted.