SPEARMINT SPMTC

Spearmint/Mining/Rewards

Spearmint Mining · reward flow

How mining rewards work

Seven steps from your hardware to SPMTC at your own address. Every one of them is either computation, network consensus, or arithmetic you can repeat from the published logs. None of them is a deposit.

Pre-launch · pool not open Parameters proposed
  1. You

    Your miner hardware

    A SHA-256 ASIC you own, power, and run. The pool never touches it.

  2. Stratum

    Submits computational work

    Shares — partial proofs of work — sent over Stratum and credited to the payout address in your username.

  3. Spearmint Mining

    Mining pool

    Aggregates every worker's shares and builds block templates from its own Spearmint Core node.

  4. Spearmint network

    Block discovered

    A share that also meets the network target is a valid block; the pool broadcasts it and the network accepts it.

  5. Spearmint network

    Block reward matures

    The coinbase output becomes spendable after 100 confirmations — about 50 minutes at the 30-second target.

  6. Spearmint Mining

    Reward apportioned

    PPLNS: shares in the window are paid in proportion to difficulty, after the 1% pool fee.

  7. You

    SPMTC sent to your external Spearmint address

    In the next daily payout run, batched with every other miner's portion, to the address the shares were mined under.

No step in this diagram accepts anything from you except computational work. There is no deposit arrow.

01 Where the reward comes from

Every Spearmint block contains one special transaction, the coinbase, with no inputs. Its output is the block subsidy — 50 SPMTC at launch, halving on the published schedule — plus the fees of the transactions the block confirmed. The coinbase is created by the network's consensus rules and checked by every node; a block whose coinbase claims one satoshi too many is rejected by the whole network. The operator does not issue it, cannot inflate it, and cannot direct it anywhere the rules do not allow.

When Spearmint Mining finds a block, its template has already named the pool's own operational address as the coinbase recipient, so that a single mature output can be split among the miners whose shares produced it. That is the only moment the pool holds anything, and what it holds is new coin that the network created a few minutes earlier for the pool's work. The operator never holds SPMTC that was yours before it was mined, because nothing of yours ever enters the system — only hashes do.

02 Worked example

The pool finds a block at height 1,234,567. Figures are illustrative and assume no transaction fees in the block, to keep the arithmetic visible; real blocks include fees, apportioned on the same basis.

One block, one miner — illustrative
StepValue
Block reward (subsidy + fees)50.00 SPMTC
PPLNS window (summed share difficulty)2 × network difficulty
Your valid shares inside the window, by difficulty2.00%
Your gross portion1.00 SPMTC
Pool fee, 1% (proposed)−0.01 SPMTC
Your mining reward for this block0.99 SPMTC
Added to pending mining reward on maturity (100 confirmations)+0.99 SPMTC
Paid in the next 00:00 UTC run once mature pending reward ≥ 1 SPMTCto your address

In this example 0.99 SPMTC is just under the 1 SPMTC minimum, so it waits for the next block your shares participate in. If your address stops submitting shares for 30 days, the 0.99 is paid anyway in the next run, because it is above the network dust limit and the pool does not keep what is not its own.

03 Timing

  1. t = 0

    Share submitted

    Recorded against your payout address with its difficulty, the job it was for, and a timestamp. Visible on your worker statistics within seconds.

  2. minutes to hours

    Block found by the pool

    How long depends on the pool's share of network hashrate. The block record appears with its height, hash, and coinbase transaction ID, and every share in the PPLNS window is listed against it.

  3. + ~50 minutes

    Block matures

    100 confirmations. Your portion moves from "immature" to pending mining reward. Until then it is shown but not counted, because an orphaned block pays nothing.

  4. next 00:00 UTC

    Payout run

    If your mature pending reward is at least 1 SPMTC, it is included in the batch transaction. The transaction ID is recorded in your payout history and the network fee share is shown.

  5. + 30 seconds to a few minutes

    Confirmed at your address

    Your own node or any explorer shows the output. At this point the pool's record and the chain's record should agree exactly; if they do not, that is a bug and we want to know.

04 What "pending mining reward" means — and does not mean

The number labelled pending mining reward on your dashboard is an accounting estimate: the sum of your apportioned shares of blocks the pool has found, less the pool fee, that have not yet been included in a payout run. It exists because payouts are batched daily and because the network makes rewards wait 100 blocks.

It is

A calculation

  • Derived from share logs and block records you can export
  • Split into immature (block under 100 confirmations) and mature (eligible for the next run)
  • Paid to your address automatically when the rules say so
It is not

A place value is kept for you

  • Not a deposit account, wallet, or stored amount you can spend on the pool
  • Not transferable to another miner or redirectable to another address
  • Not guaranteed until the block behind it matures

Orphaned blocks

Occasionally two miners find a block at nearly the same moment and the network keeps only one. If the pool's block is the one discarded, its coinbase never becomes spendable and nobody is paid for it. Your immature portion for that block is removed and the block is marked orphaned in the block list with the competing hash. The pool cannot make this good from its own reserves without becoming a creditor rather than a mining service, so it does not. Spearmint's per-block difficulty retargeting and 30-second target make orphans somewhat more frequent than on Bitcoin; the rate is published on the network page.

05 Verifying it yourself

The point of publishing the methodology is that you should not have to take the pool's word for the result.

  • Share logs. Every valid, stale, and rejected share for your address is exportable as CSV: timestamp, worker, job, difficulty, result. The PPLNS window for each block is listed with the same fields for every participating address, so you can recompute your percentage.
  • Block list. Height, hash, coinbase transaction ID, subsidy, fees, pool fee taken, distributable amount, and status (immature, mature, orphaned). Look the coinbase up on your own node with getrawtransaction <txid> true and the amount should match.
  • Payout history. Each run's transaction ID, your output amount, and your share of the network fee. The transaction is on the chain; your node is the authority, not this site.
  • Pool operational address. Published on the transparency page, so that the coinbase recipient of every pool block can be checked against it.

06 Questions

Why not pay me instantly when a block is found?
Because the network will not let the pool spend the coinbase for 100 blocks, and because the block might be orphaned in that time. Paying before maturity would mean paying from the operator's own reserves, which is exactly the credit relationship the service is designed not to have.
Can I lower the 1 SPMTC minimum for my address?
Not in the first release. A per-address minimum would need a settings interface tied to the address, which is a small feature with a large surface area. The 30-day sweep already guarantees nothing is retained indefinitely. If demand justifies it, a signed-message setting (like notifications) is the likely route and will be announced first.
Who pays the network fee on the payout?
The miners in that run, pro rata to their payout amounts, and it is shown next to each payout. Batching keeps it small. The pool does not absorb it, because absorbing costs on miners' behalf is another way of quietly becoming their creditor.
What if the pool's numbers and the chain disagree?
Then the pool is wrong, and it is a bug. Send the payout address, block height, and what you expected to support. Discrepancies and their fixes are recorded in the build log, including the ones that were our fault.