With miner.owner() renounced via 0x79df41b236a3c3d09df53ddb42af87f37f72fc4d23d04252c9814e7b142a52d4, setMinDeposit and setExitFee are permanently uncallable on the deployed instance, so the missing events on those two functions affect no future state changes. collectFees remains callable by the immutable feeRecipient and emits no event; operational mitigation is to monitor token outflows from the miner via standard ERC-20 Transfer events from this contract, which capture every safeTransfer including fee collection. The contract is deployed and immutable. The event additions are retained for any future redeployment. Severity retained at Low.

Acknowledged for any future redeployment. The deployed bytecode cannot be patched in place. None of the three documented 0.8.20 issues apply to this codebase as written.

Mitigated on the deployed instance: ownership has been renounced via transaction 0x79df41b236a3c3d09df53ddb42af87f37f72fc4d23d04252c9814e7b142a52d4 and miner.owner() now returns 0x0. The function is therefore permanently uncallable on the live contract. The finding is retained for source-code audit purposes and remains relevant for any fork or version 2 deployment.

Mitigated on the deployed instance: a helper contract MinerSeeder at 0xB90e... has staked a non-zero position into the miner (totalShares() = 680028 at audit time) and has itself renounced ownership, so the seeded shares cannot be unilaterally withdrawn. The withdraw function reverts with OwnableUnauthorizedAccount when called from any external address. This permanently keeps totalShares > 0 and prevents supplyBlock from ever hitting the zero-shares revert. Severity downgraded from High to Low to reflect the permanent on-chain mitigation: the original bricking scenario (zero stakers) is no longer reachable on the live deployment. The contract is deployed and immutable. The defense-in-depth fallback inside distributeRewards is recommended for any future redeployment so the liveness guarantee does not depend on an external seeder contract.

The deployed instance has owner renounced via transaction 0x79df41..., so addPool is permanently uncallable and the set of allowed pool tokens is frozen at the addresses configured before renouncement. None of the currently-allowed pool tokens implement ERC-777 hooks or transfer callbacks, and no new pool tokens can be added, so the cross-function reentrancy vector requires a token in the live whitelist to gain a callback - a state that is no longer reachable through any on-chain path. The nonReentrant modifier blocks same-function reentry as a second line of defense. The contract is deployed and immutable. Severity downgraded from Medium to Low to reflect the closed pool-whitelist on the deployed instance. The CEI ordering correction is recommended for any future redeployment.

The threat model the finding describes is unreachable on the deployed system. The SCADA token returns true on success and reverts on failure (it is an OpenZeppelin-based ERC-20 with no silent-false path). The manager-to-miner transfer immediately preceding distributeRewards uses scadaToken as an immutable reference inside SCADAManager (line 36 of SCADAManager.sol), so the token cannot be swapped. SCADAManager itself is fee-exempt on SCADA (set in the SCADAToken constructor at line 161-165 because SCADAManager is the initial owner and initial recipient), so the manager-to-miner transfer is full-amount and not taxed even if tax parameters change later. With manager.owner() renounced, no path can introduce a SCADA-tax-of-the-manager state change. The contract is deployed and immutable. Severity downgraded from Medium to Low to reflect the unreachability of the underlying failure mode under the deployed system. The pull-based or balance-delta pattern is recommended for any future redeployment.