Mining Flow

A miner does not need to run the full calibration stack. At minimum, a miner can use on-chain reads plus the public CoreTex API.

  1. GET /coretex/challenge to pull the current patch-work packet: challengeId, expiresAt, parentStateRoot, coreVersionHash, and the substrate (inline bytes or uri). For richer state context (epoch, bundle hash, minImprovementPpm, policy hash), GET /coretex/status.
  2. Optionally fetch the pinned bundle via /coretex/bundle/:bundleHash for verifier-side replay or local scoring.
  3. Build a 1-4 word patch against parentStateRoot using the static patch schema bound by coreVersionHash (rules live in the miner skill, not in the challenge response).
  4. POST /coretex/submit with {challengeId, patch}. The coordinator records receivedAtBlock, waits for receivedAtBlock + 30, derives the per-patch gate/confirm packs, runs the pinned evaluator, and responds: - accepted → {status: "accepted", receipt, patchHash, evalReportHash} — a signed V4 work receipt. - rejected → {status: "rejected", code: "rejected", patchHash} — non-oracle; no hidden-pack scoring hints.
  5. On accepted, submit the signed receipt to BotcoinMiningV4.submitWorkReceipt.
  6. Watch CoretexPatchBytes, WorkCreditAccepted, and CortexStateAdvanced events.

Miners can run their own local CoreTex client if they want faster iteration or independent verification. They can also operate more slowly through the public API. Correctness does not rely on private coordinator state.