Mining

Eligibility

CoreTex mining eligibility is keyed exclusively by rigId. The deployed rig contracts determine:

  • whether the rig is active and permitted to mine;
  • its tier and epoch credit allowance;
  • whether the submitting operator owns, leases, or is delegated the rig;
  • its current solve index and previous receipt hash; and
  • whether credits or reward segments remain available.

One operator may control several rigs. A rig ID is a uint256 and should be represented as a decimal string in JSON to avoid numeric rounding.

Candidate construction

Begin with the live API as the current protocol source:

  1. Read /coretex/v5/status.
  2. Fetch /coretex/v5/schema and /coretex/v5/parent-vector/<profile>. Bind the candidate parent root, parent module, stored vector, fixed caps, resource headroom, genesis-floor bounds, suite block, release identity, and public CAS links from those responses. /coretex/v5/coretex/frontier is a useful current-state summary, not a replacement for the parent-vector workflow.
  3. Implement one or more M1-M6 hooks using the advertised ABI and capabilities.
  4. Call /coretex/v5/dryrun first in static-admission mode, then with the full candidate package against the confirmed parent.
  5. Submit the content-addressed candidate to /coretex/v5/candidates.
  6. Poll the returned attempt URL.
  7. If admitted, inspect and broadcast the returned receipt from the authorized rig operator address.

The miner kit at /coretex/v5/kit/manifest is API-readable for audit and optional local replay. It is not a submission prerequisite. Endpoint-only miners can use /dryrun with requestType: "static-admission" to derive module hash, candidate hash, evaluation manifest identity, inferred hooks, and capability use before assembling the full package. Dry-run confirms shape and parent binding; it is not a signed admission promise.

Candidates should express production-visible mechanisms. Benchmark-aware optimization is permitted because the suite is public. Evaluator-only behavior such as reading gold answers, fixed answer tables, branching on case or partition identifiers, fabricated evidence, network access, or undeclared dependencies fails closed.

Evaluation

The active evaluation law is part of coreVersionHash. For every non-initial slot, the opponent is the exact parent release currently occupying that slot, executed on the same fixed gate and confirm cases as the candidate. Copying that parent cannot pass. Beating a detached reference-runtime score while losing to the live parent cannot pass. A first child is evaluated against the sealed genesis parent for its profile.

The active law measures retrieval quality, temporal and conflict validity, disclosure safety, rendered context cost, deterministic work fuel, and logical durable storage where those objectives and resources are declared for the profile and partition. Wall-clock latency, physical disk usage, and hook CPU are operational telemetry rather than admission score axes in this release.

Acceptance is fail-closed. Structural preflight confirms candidate shape and compatibility. The coordinator evaluation establishes improvement over that exact parent, and its issued receipt authorizes submission to the mining contract.

The queue is FIFO and durable. Submission returns after enqueue, and evaluation continues in the worker. Infrastructure failures may be retried; a deterministic candidate rejection is terminal.