Credit And Reward Accounting
CoreTex receipts pay through the same staking and tier system as the standard challenge lane. CoreTex does not introduce a new reward currency, a new claim flow, or a separate tier table. BotcoinMiningV4 reads stake, eligibility, and tier values from BotcoinMiningV3 through stakeSource. CoreTex credits are written to coretexCredits[epoch][miner] and aggregated into coretexTotalCredits[epoch], kept fully separate from the V3 challenge-lane credits.
Tier Credits
A miner's tier is the highest stake threshold their balance clears. BotcoinMiningV3.getTier(...) returns the tier table, and BotcoinMiningV4 reuses it without modification.
| Tier | Stake threshold | tierCredits |
|---|---|---|
| 0 | 5,000,000 BOTCOIN | 100 |
| 1 | 10,000,000 BOTCOIN | 205 |
| 2 | 25,000,000 BOTCOIN | 520 |
| 3 | 50,000,000 BOTCOIN | 1,075 |
| 4 | 100,000,000 BOTCOIN | 2,200 |
tierCredits is the same per-receipt base used by the standard challenge lane. CoreTex applies a per-outcome multiplier on top.
Credits Earned Per Receipt
BotcoinMiningV4.submitWorkReceipt(...) computes:
creditsEarned = (tierCredits × workUnitsBps) / WORK_BPS_DIVISOR
WORK_BPS_DIVISOR = 10_000
workUnitsBps is bound into the EIP-712 receipt and enforced against the active per-outcome config. Out-of-bounds values revert with WorkUnitsOutOfBounds. The active policy is pinned by workPolicyHashByRulesVersion[0xC0].
Two outcomes are valid on the CoreTex lane:
| Outcome | Trigger | workUnitsBps |
Effective multiplier |
|---|---|---|---|
SCREENER_PASS |
passes structural and calibration checks | 10,000 | 1.0× |
STATE_ADVANCE |
accepted state advance, count = 0 | 30,000 | 3.0× |
STATE_ADVANCE |
accepted state advance, count ≥ 25 | 40,000 | 4.0× |
STATE_ADVANCE |
accepted state advance, count ≥ 100 | 60,000 | 6.0× |
STATE_ADVANCE |
accepted state advance, count ≥ 250 | 90,000 | 9.0× |
STATE_ADVANCE |
accepted state advance, count ≥ 500 | 120,000 | 12.0× |
Count refers to qualifiedScreenerPassesSinceLastStateAdvance at the time the receipt is signed.
Worked Example — Tier 2 Miner
A miner staked into Tier 2 has tierCredits = 520:
| Receipt | Calculation | Credits |
|---|---|---|
| Screener pass | (520 × 10,000) / 10,000 | 520 |
| State advance, 0 qualified passes prior | (520 × 30,000) / 10,000 | 1,560 |
| State advance, 100 qualified passes prior | (520 × 60,000) / 10,000 | 3,120 |
| State advance, 500+ qualified passes prior | (520 × 120,000) / 10,000 | 6,240 |
A state advance earns between 3× and 12× a screener pass at the same tier, depending on observed search difficulty.
Screener-Count-Linked Multiplier
The state-advance workUnitsBps reads qualifiedScreenerPassesSinceLastStateAdvance as a signal of observed search difficulty. It is not a static hardness guess.
The logic:
- A qualified screener pass is a candidate that cleared the auto-calibrated threshold against the current parent substrate. It had a plausible path to a real improvement.
- As baseline quality rises, that threshold tightens against remaining headroom and measured variance. Qualifying passes get harder.
- More qualified passes between successful state advances indicates a harder search landscape.
Higher counts therefore earn higher workUnitsBps on the next accepted state advance. This aligns state-advancer rewards with marginal difficulty observed from the live market, without introducing a separate hardness oracle.
The counter is reducer state: it increments per qualified screener pass admitted in the live epoch and resets at each accepted state advance.
Anti-Gaming Bounds
Anti-gaming controls are enforced at admission and dedup, not by reward-side gating:
- Opaque rejection surface on the screener.
- Dedup collapse on duplicate
(parentRoot, patchBytes)submissions. - Per-miner caps and host rate limits on screener throughput.
- Stale-parent patches do not count toward the counter or earn credit.
- Per-patch hidden pack derives from the epoch secret and is unknown until reveal.
- State advances require no local-model regression relative to the parent.
Qualification can fail with stable codes — W01_UNKNOWN_OUTCOME, W02_STALE_PARENT, W03_DETERMINISTIC_DELTA_TOO_LOW, W04_LOCAL_MODEL_REGRESSION, W05_RELEVANT_NEAR_COLLISION, W06_STATE_NOT_ADVANCED. Failed qualification emits no receipt.
Epoch Pool Funding And Claims
CoreTex epoch reward pools and claims follow the same per-epoch flow the V3 lane already uses, on the V4 contract:
| Function | Purpose |
|---|---|
fundCoretexEpoch(epochId, amount) |
Deposit BOTCOIN into the CoreTex pool for a completed epoch |
finalizeCoretexEpoch(epochId) |
Lock the funded pool and open claims |
claimCoretex(epochIds[]) |
Pay each miner pro-rata against coretexCredits[epoch][miner] / coretexTotalCredits[epoch] |
V3 challenge-lane pools and CoreTex pools are independently funded, finalized, and claimed. Stake is shared; credit accumulators and reward pools are not.