SECURITY & TRANSPARENCY
Open evidence. Clear boundaries.
Review records, verification evidence and open work, in one place.
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.
EXTERNAL ASSESSMENTS
Independent external assessments.
Each report covers the revision it names, not later code.
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
- Linked at
8819a59·Groupmine_audit_report_2026-10-28.pdf(opens in a new tab)
| SALUS ID | Finding | Severity | Status in the report | Treatment since the report |
|---|---|---|---|---|
| #1 | Rewards locked when all circuits are revoked before registration | Medium | Pending | Owner-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. |
| #2 | Admission ordering allows depositors to influence reward allocation | Medium | Pending | Implementer-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. |
| #3 | Centralization risk | Medium | Pending | Implementer-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. |
| #4 | Unbounded wallet revocation can prevent allocation corrections | Low | Pending | Owner-accepted operational risk · not a code fixRecorded as accepted by the owner on 29 October 2026: limited correction capacity before finalization. revokeWallet is unchanged. |
| #5 | Ownership transfer can prevent correction of over-issuance | Low | Pending | Owner-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. |
| #6 | Unsolicited receipt transfers can delay allocation finalization | Low | Pending | Owner-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. |
| #7 | Missing events for functions that change critical state | Informational | Pending | Open · canary-only codeConcerns the canary helper contract only. Not changed. |
| #8 | Magic numbers are used | Informational | Pending | Open · 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 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.
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.
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 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.
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.
REMEDIATION & RISK ACCEPTANCE
Who decided what.
Kept apart, so that none stands in for another.
- Original auditor disposition
SALUS's report marks all eight findings Pending. No later SALUS disposition is recorded in the repository.
- 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.
- 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.
- 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.
- 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.
SALUS remediation report
How each SALUS finding maps to the 2.2.0 code, what changed for #2 and #3, the implementer's recorded tests and what remains open. Written for 2.2.0; 2.3.0 keeps that accounting and changes the distributor binding.
docs/SALUS_AUDIT_REMEDIATION_REPORT.mdAudit assumptions and operational risk acceptance
The owner's acceptance of SALUS #1, #4, #5 and #6 under operating constraints, the pre-custody checklist and the evidence still NOT VERIFIED. Written for 2.2.0, before the two-pool change.
docs/AUDIT_ASSUMPTIONS.mdCURRENT 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.
Architecture
How the four contracts fit together, the setup sequence, roles and trust assumptions.
docs/ARCHITECTURE.mdAccounting
The 100 : 1.25 : 1.25 : 2.5 split, the sink, carried and ordinary income, the category ledger and rounding.
docs/ACCOUNTING.mdOperations
The operator runbook: deployment, binding, activation, renunciation and admission.
docs/OPERATIONS.mdMining lifecycle
How Mining implementation 0xa3DB…f898 treats revoked and cooling miners. Derived from its deployed bytecode, with the key transitions executed on local forks.
docs/MINING_LIFECYCLE.mdTwo-pool distributor change report
The implementer's account of 2.3.0: one distributor for both custody pools, the exact contract, ABI and configuration changes, the recorded tests and runs, and the limitations that remain.
docs/TWO_POOL_DISTRIBUTOR_CHANGE.mdHistorical · 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.
Fee split change report
What 2.1.0 changed from 2.0.0 (the fee split and the sink) and how it was verified. The outer split is unchanged in 2.2.0; this evidence does not validate the 2.2.0 accounting or setup.
docs/FEE_SPLIT_CHANGE_REPORT.mdInternal review of the 2.1.0 fee split (8cf31dc)
First-party follow-up review of candidate 8cf31dc, re-read from source and re-executed rather than carried over from the earlier review.
docs/INTERNAL_FEE_SPLIT_REVIEW_8cf31dc_FABLE.mdFee split review remediation
How the 2.1.0 follow-up reviews' findings were handled, with tooling and documents only and no contract change.
docs/FEE_SPLIT_AUDIT_REMEDIATION_REPORT.mdHistorical · 2.0.0 candidate
These records cover the earlier 2.0.0 candidate and remain available for traceability.
Verification report
The project's own test evidence and open items. Not an independent audit.
docs/VERIFICATION_REPORT.mdInternal security review of f2c8e50
First-party review of revision f2c8e50: production contracts, operator tooling and the recoverable canary.
docs/INTERNAL_SECURITY_REVIEW_f2c8e50.mdRemediation report
How the internal reviews' findings were handled, without changing any contract source. Release inputs and economic assumptions still await the owner's acceptance.
docs/AUDIT_REMEDIATION_REPORT.mdThe source shown on this site is pinned to commit 8819a59 (opens in a new tab), so any future report can be matched against it.