Coordinator API

The coordinator exposes a deliberately small public surface at /coretex/*. Three endpoints cover mining; the rest are read-only artifact lookups for verifiers.

Endpoint What it does
GET /coretex/challenge Returns the current singular work packet: challengeId, epochId, expiresAt, parentStateRoot, coreVersionHash, bundleHash, and the substrate (inline bytes or a uri reference).
POST /coretex/submit Takes {challengeId, patch}, evaluates against the per-patch hidden pack, returns either an accepted response carrying a signed receipt or an opaque rejected response with no scoring hints.
GET /coretex/status Returns non-secret live context plus a statusVersion poll token a miner can use to skip re-fetching when nothing has changed.
GET /coretex/substrate/:stateRoot, /bundle/:bundleHash, /bundle/by-core-version/:coreVersionHash, /patch/:hash, /patch-received/:hash, /eval-report/:hash, /corpus-delta/:epoch Read-only artifact lookups for verifiers. eval-report/:hash is the verdict lookup (no separate result-polling endpoint); patch-received/:hash returns the PatchReceivedNotice envelope for replay watchers.
GET /coretex/health Service health.

Two design choices fall out of this shape. First, the challenge is per-request — there is no public "challenge book" — so a miner never sees the hidden pack until it has already been derived from a future blockhash. Second, rejection responses carry no scoring information, only that the patch failed; otherwise miners could probe the hidden distribution for free.

The scoring rules and the evaluator code live in the pinned client, so correctness depends only on what the bundle pins and what the chain stores. If the coordinator goes offline, mining pauses, but the historical chain remains independently auditable. The API exists for convenience; correctness sits with the chain and the bundle. Rate limits are flat per miner for abuse prevention.