Mining Flow

Challenge

Miners request a CoreTex challenge:

curl -s "$COORDINATOR/v1/coretex/challenge" \
  -H "x-miner: $MINER_ADDRESS" \
  -H "x-auth: $YOUR_EXISTING_AUTH"

The response includes:

{
  "lane": "coretex",
  "epoch": 812,
  "parentStateRoot": "0x...",
  "experienceCorpusRoot": "0x...",
  "coreTexVersionHash": "0x...",
  "patchBudget": 4,
  "shardId": "0x...",
  "creditsPerSolve": "..."
}

Submit

The miner submits a compact patch:

curl -s "$COORDINATOR/v1/coretex/submit" \
  -H "x-miner: $MINER_ADDRESS" \
  -H "x-auth: $YOUR_EXISTING_AUTH" \
  -H "content-type: application/json" \
  -d @patch.json

If the patch advances the state, the coordinator signs a normal BOTCOIN receipt. The miner submits that receipt to MiningContractV3 and claims through the standard epoch reward path.

Continuous State Advancement

CoreTex does not wait until epoch end to absorb useful improvements. During the 24-hour epoch, verified patches can advance the live state as they arrive.

This matters because two miners can improve different regions of the memory state in the same epoch. If miner A improves long-horizon compression and miner B later improves temporal revocation against the new live root, both can be accepted and credited.

Stale-parent submissions are rejected. If a miner builds on an old state root after another miner has advanced the state, they must request or compute against the latest root.