Credit And Reward Accounting
BotcoinMiningV4 uses one epoch credit and reward ledger for both standard
receipts and CoreTex receipts:
credits[epoch][miner]
totalCredits[epoch]
epochReward[epoch]
epochFinalized[epoch]
claimed[epoch][miner]
CoreTex receipts enter that ledger through submitCoreTexReceipt. The receipt
must match the miner's V4 receipt cursor, carry a valid coordinator EIP-712
signature, use the active CoreTex policy hash, and land within its issue/expiry
window. V4 also checks registry pins, patch grammar, work units, screener caps,
and duplicate patch credit before writing credits.
Tier credits come from the active stake source. At launch, V4 reads staking
balances and tier data through externalStakeSource. A future switch can move
eligibility to native V4 staking; while external staking mode is active, V4
stake() reverts. Operators and miners should read tierCount() and
getTier(i) from the active stake source instead of hardcoding a table.
Credit calculation is:
creditsEarned = (tierCredits * workUnitsBps) / 10_000
The default CoreTex work policy is:
| Outcome | Live condition | workUnitsBps |
Multiplier |
|---|---|---|---|
SCREENER_PASS |
Patch clears the live screener gate | 10,000 | 1.0x |
STATE_ADVANCE |
0 qualified screeners since prior advance | 30,000 | 3.0x |
STATE_ADVANCE |
At least 25 qualified screeners | 40,000 | 4.0x |
STATE_ADVANCE |
At least 100 qualified screeners | 60,000 | 6.0x |
STATE_ADVANCE |
At least 250 qualified screeners | 90,000 | 9.0x |
STATE_ADVANCE |
At least 500 qualified screeners | 120,000 | 12.0x |
The qualifiedScreenerPassesSinceLastStateAdvance counter is global since the
last confirmed CoreTex state advance. It increments when a screener receipt
lands and resets when a state advance lands; it does not reset merely because
the epoch rolls. Explicit ThisEpoch and PerEpoch fields are epoch-scoped.
The coordinator snapshots the since-advance counter into the receipt, and V4
rejects the receipt if the live value has changed before submission. Per-miner
screener caps are separate and persist across state advances within the epoch.
Patch-credit dedup is keyed by epoch, parent root, and patch hash. Receipt replay
is also blocked by the unified receipt hash map and the per-miner receipt chain
(solveIndex and prevReceiptHash).
Funding and claims follow the standard V4 path:
| Function | Role |
|---|---|
fundEpoch(epochId, amount) |
Deposits BOTCOIN for a completed epoch with credits |
finalizeEpoch(epochId) |
Locks the funded reward pool and opens claims |
claim(uint64[]) |
Pays each miner pro rata by credits / totalCredits |
The payout formula is:
payout = epochReward[epoch] * credits[epoch][miner] / totalCredits[epoch]