SPEARMINT SPMTC

Spearmint/Legal/Reward and Payout Policy

Spearmint Mining · reward and payout policy · draft v0.1

Mining Reward and Payout Policy

The mechanical rules by which a block reward becomes a payment to your address: where it comes from, how it is apportioned, when it matures, when it is paid, and what happens when something goes wrong. Everything here is checkable against the exportable share logs.

Pre-launch · pool not open Draft for attorney review

Prepared by , Instant Access · Version 0.1 · 13 September 2026 · Draft for review by counsel

Draft First-pass draft prepared for review by qualified counsel. Not in force and not legal advice. Values marked proposed are final at service opening. Last revised 13 September 2026.

01 Reward source

  1. The only source of mining rewards is the block reward of blocks the pool finds: the block subsidy created by the Spearmint network's consensus rules (50 SPMTC initially, halving on the published schedule) plus the transaction fees included in that block.
  2. The coinbase output of each block the pool finds pays this reward to an operational address controlled by the Operator. No other value ever enters the payout system. Nothing is received from miners, and nothing is advanced by the Operator from its own resources.
  3. If the pool finds no blocks, there is nothing to distribute.

02 Reward methodology — PPLNS

  1. Rewards are apportioned by Pay Per Last N Shares (PPLNS). When a block is found, the calculator looks back over the most recent valid shares submitted to the pool, from all payout addresses, until their summed difficulty equals twice the network difficulty at the time the block was found. Those shares are the window.
  2. Each share in the window is weighted by its difficulty. A payout address's weight is the sum of the difficulty of its shares in the window divided by the total difficulty of the window.
  3. The allocation to each payout address is its weight multiplied by the block reward after the pool fee.
# PPLNS allocation for one block window = most recent valid shares such that sum(share.difficulty) == 2 × network_difficulty_at_block weight[addr] = sum(share.difficulty for share in window if share.address == addr) / sum(share.difficulty for share in window) net_reward = (block_subsidy + block_tx_fees) × (1 − pool_fee) # pool_fee = 0.01 alloc[addr] = weight[addr] × net_reward # invariant: sum(alloc) + fee == block_subsidy + block_tx_fees
  1. Only valid shares count. Stale and rejected shares are recorded but have zero weight.
  2. PPLNS was chosen over pay-per-share (PPS). Under PPS an operator pays a fixed amount per share whether or not a block is found, which means paying miners from the operator's own resources and creating a credit relationship. Under PPLNS every allocation is a share of a reward the pool actually earned. This is deliberate and is part of the service's design as a mining service rather than anything else.
  3. Allocations are rounded down to the smallest SPMTC unit; rounding remainders stay with the pool fee.

03 Pool fee

  1. Pool fee: 1% of block rewards attributable to participating miners (proposed).
  2. The fee is taken from each block reward before apportionment, as shown in the formula above. It is the Operator's compensation for operating the mining infrastructure.
  3. The fee is not a transaction fee. No fee is charged on a payout beyond the pro-rata share of the Spearmint network transaction fee described in section 06.
  4. The fee taken from each block is published alongside the block in the pool statistics.

04 Maturity

  1. A block reward matures after 100 confirmations — roughly 50 minutes at the 30-second block target. This is the coinbase maturity rule inherited from Bitcoin Core and enforced by the Spearmint network; a coinbase output cannot be spent before it.
  2. Allocations from a block are calculated when the block is found but are marked pending until the block matures. Nothing is paid before maturity.
  3. The maturity depth may be raised as a result of the delayed-block-finality testing recorded in the build log. Any change is announced under section 11.

05 Orphaned blocks

  1. A block the pool finds may be replaced by a competing block before it matures. Its coinbase is then not spendable and the reward does not exist.
  2. When that happens, every allocation from the orphaned block is reversed. Each affected address's pending mining reward goes down by its allocation, and the dashboard shows the block as orphaned with the reason.
  3. Because nothing is paid before maturity, an orphan never results in a payout that has to be clawed back.

06 Payout runs

  1. A payout run occurs automatically every day at 00:00 UTC. There is no button to press and no request to make.
  2. In each run, every payout address whose mature pending mining reward is at least 1 SPMTC (proposed) is paid the whole of that amount, less its pro-rata share of the network transaction fee.
  3. All payouts in a run are combined into one Spearmint transaction. The Spearmint network transaction fee for that transaction is divided among the recipients in proportion to their amounts, and each recipient's share is shown in the payout record.
  4. Inactive-address sweep: if a payout address has submitted no shares for 30 consecutive days, any mature pending mining reward above the Spearmint network dust limit is paid in the next run regardless of the threshold.
  5. On permanent closure of the service, a final run pays every mature pending mining reward above the dust limit regardless of the threshold.
  6. Payouts are on-chain and irreversible. The transaction identifier for every run is published, and each address's payout history shows its amount, fee share, and transaction identifier.

07 What the threshold is for

  1. The 1 SPMTC minimum exists solely to make mining-reward distributions operationally practical: paying amounts smaller than the network fee they would attract wastes the reward, and batching keeps each miner's fee share small.
  2. The threshold is fixed by this policy. Miners cannot raise it, and the Operator does not offer to hold rewards for longer at a miner's request. This is deliberate: a configurable hold would make the pending figure look like something kept for the miner rather than something on its way to them.
  3. Pending amounts are not a deposit and not a hosted wallet. They are an accounting estimate of mining rewards awaiting distribution, they belong to the address they were mined under, and the only thing that can happen to them is that they are paid.

08 Failed payouts

  1. The Stratum server validates payout addresses on connection — checksum, network prefix, and encoding — and refuses invalid ones, so a syntactically invalid address should never accumulate a reward.
  2. If a payout transaction fails to broadcast or confirm, the affected allocations remain pending, the failure is logged with its cause, and payment is retried in the next run.
  3. The Operator cannot tell whether a valid address is one whose keys the miner still holds. A payout to a valid address the miner has lost is a completed payout; the Operator cannot reverse it.
STOP — legal review required before implementation Counsel to determine what the Operator must do with a mature allocation that cannot be paid after 90 days of consecutive failed runs (for example, an address that became unspendable under a future network rule). This is an abandoned-property and escheat question under Pennsylvania law and possibly the law of the miner's location. Until counsel specifies otherwise, the allocation stays pending, keeps being retried, and is never taken by the Operator.

09 Withheld payouts

  1. The Operator will withhold a payout only where the law requires it — in practice, where a payout address or the miner behind it is subject to U.S. sanctions, as set out in the Sanctions / Restricted Persons Policy. Every withholding is logged with its basis.
  2. The Operator does not withhold payouts for any other reason — not for disputes, not as a penalty, and not at a third party's request without legal compulsion.
STOP — legal review required before implementation Withholding is the one point at which the service retains value that its design says it distributes. Counsel must specify the exact procedure: whether a withheld reward is blocked property, how it is segregated, how and when it is reported, what the miner is told, and what happens if the match was a false positive. The withholding function must not be built until that procedure is written.

10 Records and verification

  1. For every payout address, the share log — timestamp, worker, difficulty, and result of every share — is exportable from the dashboard.
  2. For every block the pool finds, the height, hash, coinbase transaction identifier, reward, fee taken, and status (pending, mature, orphaned) are published.
  3. For every payout run, the transaction identifier, total paid, and network fee are published, and each address's payout history shows its line.
  4. These records together let any miner reproduce their allocation for any block and confirm the payout on their own node. The records the Operator keeps and for how long are listed at /docs/recordkeeping/.

11 Changes

  1. Changes to the methodology, fee, threshold, schedule, or maturity are published at /updates/ and on this page at least 30 days before they take effect, except where required by law or to protect the network from an active threat.
  2. A change applies to blocks found after its effective time. Allocations already calculated are paid under the rules in force when the block was found.

12 Version

version
0.1 — draft for attorney review
revised
13 September 2026
effective
Not in force; the service is not open
proposed values
PPLNS window 2× network difficulty · pool fee 1% · maturity 100 blocks · daily run 00:00 UTC · threshold 1 SPMTC · inactive sweep 30 days
← All legal documents How rewards work Transparency