SECURITY & TRANSPARENCY

Open evidence. Clear boundaries.

Review records, verification evidence and open work, in one place.

External confirmation of 2.3.0 pending

An external assessment is available for an earlier revision.

SALUS Security assessed revision c3cb933 (TapeoutMinerPool/2.0.0) in a report dated 2026-10-28. The website's source snapshot is 8819a59 (TapeoutMinerPool/2.3.0), which contains the remediation of that report and the later two-pool distributor change. No external auditor has reviewed either.

Internal reviews, remediation reports and risk acceptances are listed separately below. None of them is an external audit, a certification or a security guarantee, and none of them establishes a production deployment.

WEBSITE SOURCE SNAPSHOT8819a59TapeoutMinerPool / 2.3.0Verify the source revision (opens in a new tab)

EXTERNAL ASSESSMENTS

Independent external assessments.

Each report covers the revision it names, not later code.

Earlier revision · TapeoutMinerPool/2.0.0

Code Security Assessment, Groupmine

By SALUS Security · report dated 2026-10-28

Covers the earlier 2.0.0 implementation (100 : 1 : 1 of 102, no sink), not 2.1.0 and not the current 2.2.0 remediation. The six SHA-1 values in its scope appendix match the files at c3cb933. It reports 0 High, 3 Medium, 3 Low and 2 Informational findings, all marked Pending.

Revision assessed
c3cb933 (opens in a new tab) · TapeoutMinerPool/2.0.0
Report file added in
c78a6d1 (opens in a new tab) · adding the file does not change the revision assessed
Files in scope
TapeoutMinerPool.sol, PoolMath.sol, TapeoutEntitlementReceipt.sol, TapeoutReceiptDistributor.sol, RecoverableTapeoutMinerPool.sol, CanaryParticipant.sol
Findings of SALUS Security's report, with their current treatment
SALUS IDFindingSeverityStatus in the reportTreatment since the report
#1Rewards locked when all circuits are revoked before registrationMediumPendingOwner-accepted operational risk · not a code fixRecorded as accepted by the owner on 29 October 2026 under a fixed-holder, depositMiners-only workflow. No code change; the unsupported direct-transfer path remains.
#2Admission ordering allows depositors to influence reward allocationMediumPendingImplementer-reported code remediation · SALUS confirmation pending2.2.0 splits each incoming miner's realized carried income by that miner's own burn in a fractional ledger, unchanged in 2.3.0. Both internal reviews of 2.2.0 qualify order independence: it holds for the same realized per-miner payments.
#3Centralization riskMediumPendingImplementer-reported code remediation · SALUS confirmation pending2.2.0 added a one-time distributor binding, finalized allocation before activation and all owners renounced before the first admission; 2.3.0 keeps these gates and changes the binding to membership in the distributor's fixed pool pair. Setup-stage trust and deployed-code identity remain; one internal review of 2.2.0 calls it partially or conditionally addressed.
#4Unbounded wallet revocation can prevent allocation correctionsLowPendingOwner-accepted operational risk · not a code fixRecorded as accepted by the owner on 29 October 2026: limited correction capacity before finalization. revokeWallet is unchanged.
#5Ownership transfer can prevent correction of over-issuanceLowPendingOwner-accepted operational risk · not a code fixRecorded as accepted by the owner on 29 October 2026: one issuance wallet, with corrections finished before funding or finalization. retract is unchanged.
#6Unsolicited receipt transfers can delay allocation finalizationLowPendingOwner-accepted operational risk · not a code fixRecorded as accepted by the owner on 29 October 2026: receipts stay under issuer or distributor control until finalization. In 2.2.0 such a delay also delays activation and custody opening.
#7Missing events for functions that change critical stateInformationalPendingOpen · canary-only codeConcerns the canary helper contract only. Not changed.
#8Magic numbers are usedInformationalPendingOpen · canary-only codeConcerns the recoverable canary pool only. Not changed.

Statuses in the report are SALUS's own and only SALUS can change them. The treatments are taken from the implementer's remediation report and the owner's assumptions document, linked below.

Read the report (PDF) (opens in a new tab)

INTERNAL REVIEWS

Internal reviews of the current implementation.

Owner-authorized, not external audits.

Both reviews examined commit 02ef1f7 (TapeoutMinerPool/2.3.0), whose production source is byte-identical to the website snapshot 8819a59. They are owner-authorized internal reviews, not external audits. Their conclusions differ and both are shown with their open qualifications.

Internal review · not an external audit

Internal review of Groupmine 2.3.0: one distributor for two custody pools

By Claude Fable 5.1 · report dated 2026-10-31 · reviewed 02ef1f7 · file added in 07c2cb3

No confirmed High or Medium defect, asset-locking path or inability to run was introduced or worsened by the change; the complete two-pool lifecycle was executed locally and on a real-state BSC fork. The remaining items are inherited limitations, setup assumptions and tooling gaps for the owner to decide or verify before deployment consideration.

Open qualifications

  • N-1 (Informational, setup trust): the pools do not read each other's binding, so direct calls can bind them to two different genuine distributors; the CLI detects this, the on-chain gate does not.
  • N-2 (Informational, integration): a pool that has not been activated reverts claimable(), which a frontend must show as not active rather than as an error.
  • N-3 (Informational): the distributor authenticates its pools by the views they report, and a member pool can veto funding.
  • T-1 (Low, tooling): the deployment check skips the distributor, the bindings and any pool the addresses file omits.
  • T-2 (Low, tooling): the activation preflight still checks only that the allocation is finalized, not that it covers the issued supply.
  • POL-1 (policy): "optimal" and "regular" are labels, and a miner admitted to the wrong pool cannot be moved.
Read the review (opens in a new tab)
Internal review · not an external audit

Groupmine 2.3.0 Security and Operational-Correctness Review

By ChatGPT, GPT-6 Astra Pro · report dated 2026-10-31 · reviewed 02ef1f7 · file added in 8819a59

A qualified conclusion: the two-pool lifecycle was verified, with no new High or Medium failure of the honest, fully configured route. Production consideration remains gated by identity verification, the known compiler exposure and actual launch-input evidence; the report is not a deployment authorization or SALUS closure.

Open qualifications

  • T23-01 (Medium, tooling): a partial manifest can return MATCHES without checking the whole pool pair or its actual bindings.
  • T23-02 (Medium, conditional): the runtime comparator masks each immutable occurrence independently, now across both pools and the larger distributor.
  • T23-03 (Low): recipient-note behavior, now with two recipient sets; the approved roles still need proof.
  • SETUP-01: membership checks do not make both pools bind one distributor, and allocationFinalized does not prove full-round coverage; genuine code bound the pools to different distributors in a counterexample.
  • SETUP-02: the distributor trusts the getters of its pools, so a look-alike member is accepted.
  • EX23-01 (upstream Low): the pinned compiler settings remain within advisory SOL-2026-7; miscompilation was neither demonstrated nor excluded.
  • EVID-01 (Informational): raw logs are missing from the implementer's new evidence package.
Read the review (PDF) (opens in a new tab)

Internal reviews of the earlier 2.2.0 implementation

Both reviews examined commit 6345de8 (TapeoutMinerPool/2.2.0). They do not cover the later two-pool distributor change; the accounting they reviewed is unchanged in the current source. One report's title calls it independent; it is still an owner-authorized internal review, not an external audit.

Internal review · not an external audit

Internal security review of Groupmine 2.2.0

By Claude Fable 5.1 · report dated 2026-10-29 · reviewed 6345de8 · file added in 629d92b

No confirmed Medium or High production-contract defect within its stated assumptions. It reports SALUS #2 and #3 fixed in code with stated boundaries, #1 as a risk acceptance and #4–#8 open. It states that the targeted changes need no further contract work before external review, provided the owner records the acceptances and the documentation and tooling items are fixed.

Open qualifications

  • P-1 (Low): every admission settles the whole registry, so at about 590 registered miners an admission no longer fits BSC's gas cap and no further miner can ever be admitted.
  • P-2 (Low, policy): a revoked miner keeps its burn in the composition, so later income is still split as if it earned.
  • P-3 (Low, external): a claim failure of one registered miner, other than REVOKED, blocks every later admission.
  • P-4 (Informational): NAND can be paid one raw unit below the floor of its exact entitlement; the documented "under 10^-17" wording describes ledger units, not payouts.
  • X-1 (Medium, external dependency): the miner collection is an upgradeable beacon proxy; the pool cannot detect or mitigate an upgrade.
  • T-1 (Low, tooling): the activation preflight checks that the allocation is finalized, not that it covers the issued supply.
Read the review (opens in a new tab)
Internal review · not an external audit

Groupmine 2.2.0 Independent Internal Security Review

By ChatGPT, GPT-6 Astra Pro · report dated 2026-10-28 · reviewed 6345de8 · file added in 14d972a

Recommends holding production custody until the deployment-identity gaps and the known compiler exposure are resolved and the remaining deployment-specific release gates are met. It finds the central accounting remediation substantially sound under its stated assumptions, with no demonstrated critical or high production-contract defect in the paths it examined.

Open qualifications

  • ST-01 (Medium, conditional): the pool authenticates its distributor only by the views it reports, so a setup owner could bind a look-alike that reports owner zero.
  • TL-01, TL-02 (Medium, tooling): deployment verification can omit the bound distributor, and its immutable masking accepts inconsistent copies.
  • PC-03 (Medium): settling the whole registry at each admission gives admissions a finite gas horizon and a single-miner failure dependency.
  • EX-02 (Medium, conditional): near Mining's shared supply cap, claim order can change the realized per-miner payments, so order independence holds only for the same realized inputs.
  • EX-03 (release gate): the pinned compiler settings are within advisory SOL-2026-7; no miscompilation was demonstrated or excluded.
  • PC-01 (Low): same-ratio admissions can still shift a category by one raw unit; the universal one-unit fairness wording is overstated.
  • ST-02 (Low): a finalized empty or partial distributor does not establish that the allocation covers the full round.
  • SALUS #3 assessed as partially or conditionally addressed; #4–#6 open; #7 and #8 open in canary code.
Read the review (PDF) (opens in a new tab)

REMEDIATION & RISK ACCEPTANCE

Who decided what.

Kept apart, so that none stands in for another.

  1. Original auditor disposition

    SALUS's report marks all eight findings Pending. No later SALUS disposition is recorded in the repository.

  2. Implementer-reported code remediation

    SALUS #2 and #3, changed in TapeoutMinerPool 2.2.0 (2ea526c, merged in 6345de8) and kept in 2.3.0, whose binding now checks membership in the distributor's pool pair. The remediation report's "fixed in code" labels are the implementer's assessment and request SALUS review.

  3. Owner acceptance of operational risks

    SALUS #1, #4, #5 and #6, recorded as accepted on 29 October 2026 under documented operating constraints. These are not code fixes and do not close the findings for SALUS.

  4. Pending auditor confirmation

    SALUS has been asked to confirm these treatments and review the 2.2.0 changes. No confirmation is recorded, and the repository records no SALUS review of the 2.3.0 two-pool change.

  5. Unverified deployment and launch evidence

    Genuine deployed code, bindings of both pools to one distributor, full allocation coverage, ownership renunciation and the first admission are marked NOT VERIFIED in the assumptions document and the two-pool change report. Passing tests and internal reviews do not establish them.

CURRENT DOCUMENTATION

From source to verification.

All links use the same pinned snapshot.

Written by or for the project, not by an independent auditor. Links point to the pinned snapshot commit 8819a59.

Historical · 2.1.0 candidate (superseded)

These records cover the superseded 2.1.0 candidate. 2.2.0 kept its fee split but changed its accounting and setup, so they are not evidence for 2.2.0.

Historical · 2.0.0 candidate

These records cover the earlier 2.0.0 candidate and remain available for traceability.

The source shown on this site is pinned to commit 8819a59 (opens in a new tab), so any future report can be matched against it.