Everything a miner would otherwise have to take on trust

01 Mining methodology

Spearmint Mining apportions block rewards by PPLNS — pay per last N shares. When the pool finds a block, the reward is divided among the miners who submitted shares in a window ending at that block, in proportion to the difficulty-weighted work each contributed.

The window

The window is the most recent run of shares whose summed share difficulty equals 2× the network difficulty at the moment the block was found. It is defined by work, not by time, so it stretches when the pool is small and contracts when it is large. A miner who stops submitting shares drops out of the window as newer work replaces theirs.

Share difficulty

Each worker is assigned a share difficulty by the Stratum server (variable difficulty, adjusted so a worker submits roughly one share every 10–20 seconds). A share of difficulty d counts as d units of work. Only valid shares count. Stale shares (for an old job) and rejected shares (malformed or duplicate) are recorded and shown on the dashboard but carry no weight.

How a block's reward is split

1. Block reward = coinbase subsidy + transaction fees in the block.
2. The pool fee (section 02) is deducted from the block reward.
3. The remainder is apportioned across every payout address in the window, pro rata to its summed valid share difficulty.
4. Each address's portion is recorded as a reward allocation against that block and becomes part of the address's pending mining reward once the block matures (section 04).

Worked example

50.4 − 0.504 = 49.896 distributable; 49.896 × 0.5 = 24.948, and so on. The same arithmetic can be run by any miner from their exported share log and the block's coinbase transaction.

02 Pool fee

pool fee

1% of block rewards attributable to participating miners proposed

taken from

each block reward, before apportionment

applies to

subsidy and transaction fees in the block alike

changes

30 days' notice on the updates page

The fee is compensation for operating the mining infrastructure: the Stratum servers, the Spearmint Core nodes they build templates from, the share database, the payout daemon, monitoring, and the people on call for them. It is deducted once, from the block reward, at the moment the reward is apportioned. It is not charged on payouts and it is not a fee for transferring anything.

The pool's own address receives the coinbase output of each block it finds; the 1% is the part of that output the pool keeps. The other 99% is allocated to miners as described above. Miners can verify the split for any block from the coinbase amount and the published allocation for that block.

03 Payout methodology

Payouts are automatic and mechanical. There is nothing to request and no button to press.

• Daily run. Once a day at 00:00 UTC the payout daemon collects every mature reward allocation not yet paid.
• Threshold. Any payout address whose mature pending mining reward is at or above 1 SPMTC is paid in that run proposed. The threshold exists only so distributions are practical on-chain; it is not a holding facility.
• Batching. All payouts in a run go out in one on-chain transaction with one output per payout address. The transaction id is published on the network page and shown in each address's payout history.
• Network fee. The transaction fee paid to the network for the batch is deducted from the run pro rata to each payout's amount, and the deduction is shown against each payout.
• Inactive sweep. If an address has submitted no shares for 30 days, any mature pending reward above the network dust limit is paid in the next run regardless of the threshold, so the service never accumulates rewards for absent miners.
• Orphaned blocks. If a block is orphaned before maturity, its allocations are reversed and the affected addresses' pending mining reward decreases with the reason shown. Nothing from an orphaned block is ever paid.
• Failed transactions. If a batch fails to confirm it is retried in the next run; the failure is logged and shown as such in payout history.

The number shown on the dashboard as Pending mining reward is the sum of an address's mature, unpaid allocations. It is an accounting estimate of mining rewards awaiting distribution. It is not a deposit account and not a hosted cryptocurrency wallet. Full policy: Mining Reward and Payout Policy.

04 Block maturity

coinbase maturity

100 confirmations (inherited from Bitcoin Core)

at target

~50 minutes at a 30-second block interval

distributed before

nothing

A block's coinbase output cannot be spent until 100 blocks have been built on top of it; the network enforces this, not the pool. Until then the block can still be orphaned by a competing chain. The pool therefore records allocations for a found block immediately, marks them pending, and only counts them toward payouts once the block has matured. This is why a freshly found block appears on the dashboard before it moves anything.

Because Spearmint uses depth-tiered finality (DBF), the adversarial testing programme may conclude that the pool should wait deeper than 100 before treating a reward as mature. If that changes, it will be announced with notice and recorded here.

05 Source code availability

06 Network rules

The pool runs on the network; it does not define it. The rules below are consensus rules of Spearmint Core, fixed at the genesis block, and set out in full in the economic policy.

• Supply. 210,000,000 SPMTC cap. 50 SPMTC initial block reward, halving every six months for five years and annually thereafter. All issuance is through mining.
• Block target. 30 seconds.
• ADR. Difficulty retargets every block, so hash rate that arrives suddenly meets a difficulty that rises to meet it within blocks.
• DBF. Confirmation depth scales with transaction value; high-value settlement waits deeper.
• Pre-launch acquisition. 8% of supply (16,800,000 SPMTC) is mined by the team before public launch by ordinary solo mining at the standard reward — roughly 336,000 blocks. The exact block range will be published. The first public release of Spearmint Core will pin that range with checkpoints and a minimum-chain-work value, so any node can verify both that the range is what was published and that no other chain claims those blocks.

07 What we publish and when

08 What we do not do

The service is mining infrastructure and nothing else. It is not, and is built so that it cannot quietly become:

The developer-facing list of features that must not be added without legal review is in Regulatory change control. Plain-English version: Compliance.