STOP — legal review required before implementation
The features in the table below are compliance-significant. They must NOT be implemented — not merged, not
deployed behind a flag, not prototyped against production data — without a new legal review recorded on the
attorney review list. This applies regardless of who asks for the feature,
how small the change looks, or whether a competitor offers it. If a proposed change conflicts with the
custody statement, the change is what gets flagged, not the statement.
01 The list
| Feature | Why it changes the regulatory character | What to do instead |
|---|---|---|
| Hosted wallets | FinCEN's guidance says a pool operator that also hosts wallets for members engages in account-based money transmission. It is the one feature the guidance singles out. | Keep address-is-identity. The miner's own wallet or node holds the keys; the service never generates or receives one. |
| Deposits | Accepting value from a miner makes the operator a holder of that miner's property and creates the inbound leg of a transmission. | None. Nothing enters the system from a miner except shares. |
| User withdrawals from custodial accounts | A withdraw action presupposes an account the operator holds on the miner's behalf. | Payouts are automatic distributions of mining rewards on a published schedule. There is no withdraw button. |
| User-to-user transfers | Moving value from one person to another through the operator is money transmission in its plainest form. | None. No table, no endpoint, no support procedure can move value between payout addresses. |
| Cryptocurrency swaps | Exchanging one asset for another makes the operator an exchanger. | The service handles only the SPMTC it mined. |
| Fiat purchases | Selling SPMTC for fiat is exchange activity and, in Pennsylvania, transmission for consideration. | None. The site does not sell SPMTC. |
| Fiat withdrawals | Paying out in fiat requires holding and converting value for the miner. | Rewards are paid only in SPMTC, only to the mined-under address. |
| Debit cards | Card issuance is a payment-service relationship with a stored value behind it. | None. |
| Payment processing | Accepting payment on behalf of a third party is money transmission. | None. |
| Merchant payments | As above; also markets SPMTC as a payment product the operator intermediates. | None. Merchants who accept SPMTC do so on the network directly. |
| Custody of customer private keys | Total independent control over a miner's value is FinCEN's fourth hosted-wallet criterion. | Never request, receive, or store a miner's key or recovery phrase. The permanent warning stays on every form. |
| Exchange functionality | Order books, matching, or brokerage make the operator an exchange or broker. | None. No price feed on the site. |
| Lending | Advancing value against future rewards is a credit product. | None. PPLNS pays only from blocks found. |
| Borrowing | Taking miners' value on loan is deposit-taking by another name. | None. |
| Interest | Paying a return on held value is the defining feature of a deposit or investment product. | None. Pending rewards do not grow; they are paid. |
| Staking services | Staking on a miner's behalf is custody plus an operator-produced return. | None. Spearmint is proof of work. |
| Investment products | Packaging mining or SPMTC as an instrument with an expected return moves the service into securities territory. | None. The site states supply rules factually and promises nothing. |
| Mixing or anonymisation services | Obscuring the source of value is a money-transmission activity that FinCEN and OFAC both scrutinise heavily. | None. Payouts are ordinary transparent transactions with a published txid. |
| Payment forwarding | Receiving value to pass on is transmission. | None. |
| Receiving cryptocurrency from users for onward transmission | The general case of every row above. | None. The only inbound path is Stratum shares. |
02 The process
- Label. Any pull request that touches the payout daemon, the reward ledger, payout-address handling, the sanctions gate, or introduces any new path by which value could enter the system must carry the
compliance-impactlabel. Reviewers may add the label to any PR that should have had it; removing it requires the named reviewer's approval. - Named reviewer. One maintainer is the compliance reviewer of record. Their approval is required on every labelled PR and cannot be delegated by the author.
- Counsel sign-off. If the PR implements, enables, or approaches any feature in the list above, or changes any parameter on the matrix marked STOP, counsel's review is recorded — question, date, counsel, outcome — on the attorney review list before merge.
- Documentation first. The transparency page, the payout policy, and the architecture document are updated in the same PR. If the code and the documents disagree after merge, the code is wrong.
- Notice. Changes to fee, methodology, threshold, or schedule are announced on Updates at least 30 days before taking effect.
03 Schema and API rules
Schema rule
No table may hold miner-owned value except
No table may hold miner-owned value except reward_allocations pending payout
There is no balances, deposits, transfers, or accounts table, and there will not be one. A migration that adds a column representing value owed to or held for a miner anywhere else is a compliance-impact change by definition.
API rule
No endpoint may move value between payout addresses
Internal or external, authenticated or not. The only operation that changes reward_allocations is the reward calculator adding allocations for a matured block, the orphan reversal removing them, and the payout daemon marking them paid with a txid.
A test in the pool repository enumerates the schema and the routes and fails the build if either rule is violated. Disabling that test is itself a compliance-impact change.
04 Pre-merge checklist
Run through this before requesting review on any PR touching the pool, payout, or website code.
- Does this change create any new way for value to enter the system from a miner? If yes, stop.
- Does this change let the operator, support, or a miner redirect an allocation to a different address? If yes, stop.
- Does this change lengthen the time an allocation can sit unpaid, or let a miner choose to lengthen it? If yes, label and get counsel.
- Does this change introduce any asset other than SPMTC? If yes, stop.
- Does this change add a table, column, or endpoint that represents value owed to or held for a miner outside
reward_allocations? If yes, stop. - Does this change collect any new personal data? If yes, is it necessary to mine, and is the privacy policy updated in the same PR?
- Does this change alter the sanctions gate, the SDN screening, or the withholding path? If yes, label and get counsel.
- Does any new UI text use a prohibited term from the terminology list? Grep for: balance, deposit, withdraw, funds, cash out, interest, yield, investment, passive income.
- Does any new copy describe SPMTC or mining in terms of price, appreciation, or return? If yes, remove it.
- Are the transparency page, payout policy, and architecture document updated to match?
- Does the schema-and-routes test still pass, unmodified?
05 Wording rules
The interface uses mining terminology and never banking or investment terminology. The unpaid figure is "pending mining reward", never "balance". A payout is a distribution of a mining reward, never a withdrawal. The fee is compensation for operating mining infrastructure, never a transaction fee. The full recommended and prohibited lists, with what to say instead, are on the terminology page. Copy that fails the grep in the checklist above does not merge.
06 Version
- version
- 1.0
- date
- 13 September 2026
- status
- Binding on all contributors to the pool, payout, and website repositories. Pending counsel's review of the underlying analysis; the rule applies regardless.
- owner
- Compliance reviewer of record, Instant Access
- changes
- Amendments to this document are themselves compliance-impact changes.