MiningLink to this section

ResponsibilityLink to this section

Mining calculates rewards for completed Squeek blocks, shares them by active mining power and holds the SQK until NFT owners claim it. A shared reward index tracks each position's share without updating every NFT whenever rewards are funded.

It also tracks processed rounds, pending changes to mining power and rounding remainders. This implementation uses a 10,000-basis-point (1×) multiplier, with no user boost or public multiplier setter.

Dependencies and authorityLink to this section

Initialization and bootstrap require a fresh, paused Core with zero work. Later calls that use Core fail if its identity or reported progress does not match Mining's checks.

State and viewsLink to this section

Position unitsLink to this section

Views include changes already applied by Mining but do not mint new SQK. checkpointStatus().fundableRounds means settled rounds remain to be processed, not that they will pay rewards: rounds with no active mining power or no completed blocks receive zero.

ActionsLink to this section

A mining-power change scheduled for round r can activate only after that round has begun and Mining has processed every round through r-1 using the old power. If a checkpoint reaches its activation limit, it stops before the pending change, even across empty rounds.

A merge keeps the inputs' combined old mining power until the new Level's power activates. Mint and merge check Core but do not run a checkpoint; claims neither call Core nor mint new SQK.

Activation and cooldown schedulesLink to this section

For activation period k, the permitted starting rounds are 1, k+1, 2k+1, .... Mint and merge select the first such round strictly after the current round, or round 1 before genesis. For example, with an illustrative period of three rounds, minting during round 4 schedules round 7. These are source rules, not approved launch settings.

Activation requires both the scheduled round to have begun and checkpoint processing through its predecessor. The checkpoint records the reward index at activation; position reads and later actions use that index to credit old power before switching to the full pendingWeight. A delayed checkpoint does not grant new power rewards from earlier rounds.

For a mergeable level, nextMergeBlock is the completed Core height observed at mint or merge plus that level's cooldownBlocks. At maximum Level it is zero because further merging is forbidden. Both inputs must independently have no pending activation and have reached their threshold. Transfers do not reset either schedule; elapsed time, Ethereum confirmations and Mining's funded-block cursor do not substitute for completed Core height. One settlement may complete several Squeek blocks without an opportunity to transact between them.

Running a checkpointLink to this section

The caller needs neither NFT ownership nor an SQK approval, pays the Ethereum transaction fee, and receives no separate checkpoint reward. First verify the graph; this documentation supplies no live Mining5 address.

1. Read configuration(), state() and checkpointStatus() at one Ethereum block. corePaused blocks checkpoint execution. fundableRounds and activationDue indicate possible progress, not a guaranteed mint or completion of the backlog.
2. Compare finalizedThroughRound and mintedThroughBlock with Core's settled frontier and completed height. Use lastActivationRound, weightActivationCursor and weightActivationCount to inspect activation progress.
3. Set maxActiveRounds and maxActivations to integers from 0 through 16, not both zero. checkpoint(16, 16) uses both maxima but is not required. An active-round budget of zero can cover empty spans; it cannot skip an active round.
4. Simulate the call against the verified proxy and review the network fee before requesting authorization to submit.
5. After a successful canonical receipt, decode RoundFunded, WeightActivated and CheckpointAdvanced with the Mining5 ABI. Re-read state and accounting at that receipt's Ethereum block, retaining its hash and confirmation status.
6. Read current status again. A later checkpoint continues from the successful call's cursor if work remains. Use position(id) to inspect activation; owner payment requires a separate claim.

A checkpoint processes each round once, including zero-reward rounds. It stops before a due activation when its activation budget is exhausted, even across empty spans; it never funds a partial active round. Empty-round progress and activation alone create no SQK.

RoundFunded reports each processed active round's amount and multiplier. CheckpointAdvanced reports the resulting round/block cursors, total minted amount, active weight and reward index. The bound Token's RoundMinted repeats caller-supplied attribution; it is not independent proof of work and must not be counted again alongside the aggregate mint Transfer.

The aggregate mint return and balance increase must equal the requested amount, followed by supply and custody checks. Any required read, mint or check failure reverts the entire checkpoint; previously settled Core work is unchanged. Use the error meanings rather than substituting zero progress. A successful zero mint can mean no completed blocks, no active weight, a zero rate, exhausted supply, or only empty-round/activation progress.

Reward calculationLink to this section

The reward curve follows cumulative work, not elapsed time. Let D be workPerBlock, H be halvingWork, R be initialRate in SQK base units per work unit, and C be baseRewardCapPerBlock. The rate in work era e is R >> e, where e = floor(work / H); integer halving eventually makes the rate zero.

For each completed Squeek block at height h, calculate its base reward over the work interval [(h-1) × D, h × D). Sum the work at each applicable era rate, including any halving boundary within that block, then cap that block's base reward at C. Apply the round multiplier m as floor(base × m / 10000) independently for each block. Sum the completed blocks' rewards and clip the round's funding to remaining lifetime mint capacity.

The implementation returns m = 10000; the accepted range is 10000–20000. There is no user boost, idle charge, keeper control or external policy module. Unused per-block cap does not carry forward, and combining more rounds in one checkpoint does not change per-block caps or rounding.

Only completed blocks receive rewards. Their funding belongs to the round that completes them, even when some work predates a Miner's activation. A round with zero active weight is finalized with zero funding and cannot be recovered for later Miners. A zero rate or exhausted supply also produces zero funding; a final payable amount may consume only the remaining supply.

Scaled credit and custodyLink to this section

One SQK base unit, or token atom, is 10^-18 SQK. Reward indexes, position credit and division residuals use SCALE = 2^128, allowing credit smaller than a transferable base unit.

While total active weight is unchanged, a weight epoch keeps its starting index and cumulative minted amount. Its index is epochStartIndex + floor(epochMinted × SCALE / totalWeight) and its openResidual is (epochMinted × SCALE) % totalWeight. Both remain unchanged at zero weight, with zero open residual. Using the cumulative epoch amount avoids additional shared-index rounding loss when the same funding is split across checkpoints.

When an activation changes total weight, the current open residual moves into closedResidual, the current index becomes the new epoch's start, and epoch funding resets to zero. Closed residuals remain protected custody; they are not assigned to the new weight set or available for a treasury sweep.

Each position accrues activeWeight × (index - lastIndex) in scaled credit. Merge catches up both inputs at the same index and combines all credit without rounding. Claim catches up and sums the selected positions, pays floor(credit / SCALE) base units, and keeps credit % SCALE on the first (lowest) selected ID. A zero payout still preserves the remainder and emits RewardsClaimed, without an ERC-20 transfer.

For an illustrative grouping example, two owned Miners with half an atom of credit each pay one atom when claimed together. Separate claims each pay zero and preserve their half-atom credit. Any grouped remainder follows the first NFT on transfer; this is a rounding example, not an earning forecast.

Direct donations can make actual custody exceed tracked custody but do not fund claims, redistribute residuals or restore mint capacity. Claims, ordinary SQK transfers and NFT burns do not reduce SQK supply. Reaching the cap stops new issuance, not claims against already-funded custody.

Events and errorsLink to this section

Mining propagates dependency and inherited initialization/Token transfer errors when those calls fail. Use the complete interface and imported standard sources to decode the ABI.

LimitsLink to this section

• Checkpoint budgets: 0–16 active rounds and 0–16 activations, not both zero; no partial active round funding.
• Claims: 1–32 strictly ascending unique live IDs owned by caller. Fractional base-unit credit stays on the first ID.
• Levels: 1–14 configured levels; power is a positive uint64; each level's power must be more than twice the previous level's.
• Merge cooldowns: positive and increasing at each level, at most 2^48-1 Squeek blocks. The resulting merge-ready block height must also fit uint48; no further merge is allowed at the maximum level.
• Activation period: 1–144 rounds; pending round must fit uint40; at most one pending change per live position.
• Collection size: at most 9,999 NFTs ever minted; burns do not free room for new mints.
• Supply cap: positive and at most 2^128-1; initial rate and halving work positive; base reward cap positive and below supply cap.
• Multiplier acceptance range: 10,000–20,000 basis points; this implementation returns 10,000, not a caller-selected value.
• Added power is grouped by activation round and fits uint192; total power is uint256.
• Each Core round lasts 600 seconds. Incomplete Squeek blocks do not earn rewards yet.
• minted = paid + trackedCustody and Token.totalSupply() = minted; rounding leftovers stay in Mining and cannot be withdrawn.

SourceLink to this section

Based on Mining5 source e0617449; see source and release scope.

• Inherited initialization
• Token payout standard

Related pagesLink to this section

• Read contracts
• Checkpoints and pending rewards
• How rewards work
• Merging Miner NFTs
• Levels and mining power
• Supply limits and rounding