SPEARMINT SPMTC

Meeting record · security review and timeline · decisions noted below

11.09.2026

Security review and timeline meeting

Security concerns arising from the rapid spread of AI tooling were reviewed, an additional testing programme was confirmed, and the public launch window was placed under review — with 2027 now the working assumption.

Later record Two days after this meeting the public mining service was designed end to end and published, with a legal review added as a second gate before the pool opens. See the 13 September update.
Summary The network will not open to the public until the new testing programme is complete. The launch window previously described as early 2026 is under review, and the team is planning on the basis that it moves to 2027. No date has been set. The published economic policy and chain parameters are unchanged.

01 Purpose and scope

  • Review how the security landscape has changed since the October 2025 comparison session, specifically the effect of widely available AI tooling on the cost of attacking a new proof-of-work network.
  • Decide whether the existing test programme is sufficient before public launch, or whether it needs to be extended.
  • Reassess the launch window in light of the above.

This was a working session with decisions, unlike the October 2025 meeting, which was comparison only. The decisions are recorded in section 06.

02 Launch timeline

The roadmap published at the start of the project described closed testing through Q1 2026 and a public launch window in early 2026. That window has passed without a launch, and the meeting agreed it should not be restated until the additional testing described below has been completed.

previous
Public launch window: early 2026
status
Under review
working assumption
2027
date set
None

The principle that mining endpoints open progressively as stability thresholds are met still applies. The thresholds themselves are being extended to include the new security testing.

03 Security concerns raised

No confirmed vulnerability was presented at the meeting. The concerns are about the changed cost of several attacks: work that previously required scarce skill or time is now substantially cheaper because of AI tooling, and a small proof-of-work network is exposed to that change more than a large one. The following areas were raised for review.

Consensus code

Automated review of novel logic

The Bitcoin Core base is heavily reviewed; the Spearmint additions (per-block retargeting, tiered finality) are not. AI-assisted auditing makes it far cheaper for an adversary to search that new logic for edge cases.

Hash-rate attacks

Optimised rental timing

ADR is designed to make brief rented hash rate unprofitable. The concern is planning tools that can model the retarget response and time rentals to the windows where it is weakest.

Maintainers and releases

Social engineering and supply chain

Convincing, targeted approaches to maintainers, AI-generated contributions, and pressure on the release-signing process were all raised as risks to a small named team.

Infrastructure

Automated probing of endpoints

Pool, Stratum, and node endpoints will be probed by automated agents from the moment they are public. Defaults and monitoring need to assume that rather than hope otherwise.

04 Additional testing

A new testing programme is under way in response to the concerns above. It extends the adversarial simulation work proposed in October 2025 rather than replacing it. The programme covers:

  • Adversarial simulation of ADR and DBF against hash-rate schedules that are planned to exploit the retarget response, not just random volatility.
  • Fuzzing and targeted review of the retarget and finality code paths that differ from Bitcoin Core.
  • A review of the release process: key custody, signing, reproducible-build verification, and how contributions are accepted.
  • Hardening and monitoring of pool and node infrastructure before any endpoint is exposed publicly.

Results will be recorded in the build log as they are produced, including anything that fails, consistent with how the log has been kept so far.

05 What does not change

  • The economic policy — 210 million cap, 50 SPMTC initial reward, 30-second target, six-month then annual halvings — is unchanged and remains proposed until genesis.
  • The chain identity recorded in the build log (HRPs, ports, magic bytes, genesis texts) is unchanged.
  • The pre-launch acquisition model — 8% by ordinary solo mining, block range published — is unchanged.
  • The commitment to publish parameters, failures, and fixes before launch is unchanged. This page exists because of it.

06 Decisions recorded

Decisions, 11 September 2026
ItemDecision
Launch windowUnder review. Not restated until testing completes. Working assumption: 2027.
Testing programmeExtended to cover the four areas in section 04. Launch is gated on completion.
Economic policyNo change.
Chain parametersNo change.
DisclosureTesting results, including failures, to be published in the build log.

07 Open questions

  • Which ADR parameter ranges hold up against planned, rather than random, hash-rate schedules — and does the answer change the values published in the economic policy?
  • What confirmation depths should DBF require by value tier once the simulation results are in?
  • What level of independent review is appropriate for the consensus additions before launch, and who performs it?
  • What are the objective criteria for declaring the testing programme complete?

08 Next steps

  • Run the extended adversarial simulations and publish the method and results.
  • Complete the release-process review and publish the resulting signing and contribution policy.
  • Define the completion criteria for the testing programme and publish them.
  • Reconvene to set a launch window once the criteria are met. Until then, the roadmap says 2027 as a working assumption and nothing firmer.