Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

SCADA Info

nukethesupply.com

Supply Block is SCADA's core innovation — a function that, when triggered, removes a portion of the bonus liquidity SCADA farms from trading and splits the retrieved tokens: 90% of SCADA is permanently burned, reducing total supply forever. The remaining portion is distributed as rewards to stakers and the caller who executed the block. Meanwhile, the paired WPLS is used to market-buy SCADA, creating upward price pressure. This process strengthens the liquidity floor while continuously shrinking the circulating supply — a self-reinforcing cycle that rewards holders over time.

SCADA Logo
Onboarded date 04/05/2026

TrustNet Score

The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.

23.86
Poor Excellent

Real-Time Threat Detection

Real-time threat detection, powered by Cyvers.io, is currently not activated for this project.

This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks. For more information, click here.

Security Assessments

Select the audit
"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
N/A
Network N/A
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2026/05/04
Revision date 2026/05/04

Summary and Final Words

No crucial issues found

The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.

Contract owner cannot mint

It is not possible to mint new tokens.

Contract owner cannot blacklist addresses.

It is not possible to lock user funds by blacklisting addresses.

Contract owner cannot set high fees

The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.

Contract cannot be locked

Owner cannot lock any user funds.

Token cannot be burned

There is no burning within the contract without any allowances

Ownership is renounced

The contract does not include owner functions that allow post-deployment modifications.

Contract is not upgradeable

The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.

Scope of Work

This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.

The auditing process consists of the following systematic steps:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.

A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.

Final Words

The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.

Smart Contract Analysis Statement

Contract Analysis

The SCADAToken contract implements an ERC20 token with a bounded buy/sell tax, an automated liquidity injection mechanism on Uniswap V2, and cross-chain mint/burn coupling with the SCADABridge. The contract is deployed and immutable; the team has acknowledged each finding below and provided on-chain or operational mitigations where applicable. Residual concerns are summarized as follows:

  • The auto-LP swap and addLiquidityETH calls ship with zero slippage parameters. The auto-LP path is gated to the protocol's own SCADA/WETH main pair, so MEV exposure on a triggering trade is bounded by the round-trip tax cost (1.00 percent buy + 1.20 percent sell = 2.20 percent of swap notional) and capped per cycle by MAX_SWAP_TOKENS = 10,000 SCADA. Residual sandwich risk remains real on shallow-liquidity periods where a single auto-LP swap can produce price impact above the tax band; the operational mitigation is to monitor pool depth and ensure liquidity stays sufficient. The on-chain slippage hardening is recommended for any future redeployment.
  • The LP-token transfer to the manager does not check the ERC-20 boolean return. The pair token is fetched live from the canonical Uniswap V2 factory, so it is always the canonical UniswapV2ERC20 implementation, which reverts on insufficient and unconditionally returns true. The originally High-rated extraLP corruption scenario is therefore unreachable on the deployed pair; this finding has been downgraded to Low.
  • The auto-LP step fires inside the user's transfer to the main pair and the partial-failure path leaves orphan ETH inside the contract. Recovery is available through rescueETH (creator role, bounded, cannot rescue SCADA or the LP token), and the SCADA accounting drift on a failed addLiquidityETH catch arm is self-cleaning over multiple subsequent tax cycles because the auto-LP trigger sweeps the entire contract balance. The combined residual exposure is bounded loss-of-availability of orphan ETH until rescue, with no permanent loss of user funds; severity has been downgraded to Medium accordingly.

Initial Supply Custody

The 1,000,000 SCADA initial supply was minted in the SCADAToken constructor to the SCADAManager contract address (initialRecipient set to the deploying SCADAManager), not to an EOA wallet or team multisig. SCADAManager subsequently contributed the entire mint - together with deployer-funded WETH - as initial Uniswap V2 SCADA/WETH liquidity via the one-shot SCADAManager.initializeLiquidity() function. The resulting initial LP baseline is structurally retained by SCADAManager and cannot be withdrawn to the deployer or any admin. The post-bootstrap extra LP that the auto-tax mechanism subsequently accumulates is removed only in bounded portions by the permissionless supplyBlock cycle, with the unwound SCADA and WETH routed entirely through burn / staker reward / bounded caller incentive - never to the deployer; see the SCADAManager audit statement for the full LP-lock enumeration. SCADAToken itself has no recall, freeze, or clawback capability over its own supply held elsewhere, and the constructor mint is the only mint outside the SCADABridge user-driven unwrap path.

Ownership Privileges

The ownership of the contract has been delegated to the SCADAManager (which has itself renounced its Ownable owner via 0xe6308d...), while a separate immutable creator role retains permanent but bounded parameter-tuning powers. The owner retains full privileges including:

  • Adjust the buy tax inside [0.10%, 2.00%]
  • Adjust the sell tax inside [0.10%, 2.00%]
  • Adjust the auto-swap threshold inside [10, 10,000] SCADA
  • Mark addresses as AMM pairs or as fee-exempt, set the bridge once via a one-shot setter, and rescue accidentally received ETH or non-protocol ERC-20 tokens
  • Cannot mint SCADA outside the bridge's user-driven unwrap path
  • Cannot move user funds or freeze transfers
  • Cannot raise the tax above the 2% hardcoded cap on either side
  • Cannot un-set or change the bridge once configured

Security Features

The contract implements several positive security features:

  • Hardcoded MIN/MAX tax constants enforced at the contract level - the creator cannot push fees outside a 0.10-2.00% band, and these bounds were verified by symbolic analysis.
  • Immutable creator address and a one-shot bridge setter that locks the bridge address permanently after the first call.
  • ReentrancyGuard on every user-facing entry point plus an internal inSwap flag that prevents the auto-LP path from re-entering itself.
  • Explicit fee-exempt list covering the protocol's own contracts and the Uniswap V2 router, so internal protocol movements never accidentally pay tax.

Note - This Audit report consists of a security analysis of the SCADAToken smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the SCADAToken team. Other contracts associated with the project were audited separately by our team. We recommend investors do their own research before investing.

Files and details

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Findings and Audit result

Critical
High
3
Medium
6
Low
4
Optimization
6
Informational
medium Issues | 3 findings

Acknowledged

#1 medium Issue
Auto-LP fires inside the user's transfer to the main pair, exposing every triggering trade to MEV
SCADAToken.sol
L291-340
Description

The _update hook calls _swapAndAddLiq before completing the user's transfer to mainPair. The auto-LP path swaps half of the accumulated tax for ETH and adds liquidity into the same pair the user is selling into. Because both operations execute inside the user's transaction, a frontrunner can amplify the slippage cost extracted from the contract and the protocol always pays the bad side of its own price impact. Even with non-zero slippage parameters, this transaction-ordering amplification persists.

Comments

Decouple the auto-LP step from _update. Inside _update only flag readiness (for example, set autoLPReady = collectedForLP >= swapTokensAtAmount). Add a public keepAutoLP() function that anyone can call - ideally a Chainlink Automation or Gelato keeper running through a private mempool such as Flashbots, so the auto-LP transaction cannot be sandwiched. Optionally pay a small SCADA reward to keepers from the existing tax pool. This also greatly simplifies the failure handling in _swapAndAddLiq.

Alleviation

The auto-LP path is gated to to == mainPair and routes only through the protocol's own SCADA/WETH pair, so the embedded swap and addLiquidity touch a single venue. Sandwich profitability on that venue is bounded by the round-trip tax cost (1.00 percent buy + 1.20 percent sell = 2.20 percent of swap notional), and the per-cycle swap notional is capped by MAX_SWAP_TOKENS = 10,000 SCADA. Two residual concerns remain: (1) for shallow-liquidity periods, a 10,000 SCADA swap can produce price impact above the 2.20 percent tax cap and re-open the sandwich window; (2) the user whose sell triggers the auto-LP path absorbs additional same-block price impact from the contract's own swap, which is independent of any external MEV bot and applies on every triggering trade. The contract is deployed and immutable, so deferring the swap to a keeper transaction is not retrofittable. Operational mitigation: monitor pool depth and document the auto-LP behaviour to users so they understand a sell at the trigger threshold may experience higher slippage than a sell that does not trigger the auto-LP cycle. Severity retained at Medium. The keeper-based design is recommended for any future redeployment.

Acknowledged

#2 medium Issue
Bookkeeping inconsistency in _swapAndAddLiq leaves orphan ETH and corrupted collectedForLP, and the surrounding try/catch silently swallows router failures
SCADAToken.sol
L342-431
Description

If the swap to ETH succeeds but addLiquidityETH reverts (and the catch arm fires), the function sets collectedForLP = otherHalf - that is, only half of the original input is restored to bookkeeping. The other half has already been converted to ETH and is now sitting in the contract with no tracking. The orphan ETH is recoverable only through rescueETH by the creator. Combined with the silent try/catch in _swapTokensForETH, the result is that a failing router interaction can leak tax tokens into the contract balance without a clean recovery path and without distinct event signals that operators can react to. Visible in event logs as inconsistent collectedForLP deltas and a maintainability hazard for any future refactor.

Comments

Use a single accumulator and only mutate collectedForLP at the end of the function. Introduce a new state variable such as 'unaccountedETH' to track ETH that resulted from a successful swap but a failed addLiquidity, and add a permissionless or creator-only function that recycles that ETH back into the auto-LP cycle. The intended invariant should be: address(this).balance equals unaccountedETH at all times. Drop the try/catch around notifyNewLP - either revert (preferred) or emit a structured ledger-correction event. For _swapTokensForETH and addLiquidityETH, replace the silent catches with structured events that distinguish 'router reverted with reason X', 'router returned zero ETH', and 'liquidity-add failed', so off-chain monitoring can react to each case differently and operators are not left guessing why the auto-LP cycle stopped progressing.

Alleviation

Two distinct sub-issues, both with documented recovery paths and no permanent loss of user funds. (a) SCADA accounting drift on a failed addLiquidityETH catch arm: collectedForLP is reset to otherHalf rather than the original amount. The auto-LP trigger inside _update sweeps the entire contract token balance once both contractTokenBalance and collectedForLP exceed swapTokensAtAmount (the trigger sets tokensToSwap = balanceOf(address(this)) in both branches), so the drifted SCADA is recovered automatically once enough new tax accrues to bring collectedForLP back above the threshold. Recovery may span multiple tax cycles depending on how far below the threshold otherHalf falls. (b) Orphan ETH from successful swaps followed by failed addLiquidityETH, plus refunds returned by addLiquidityETH that exceed the pair's current ratio: ETH accumulates in the contract balance and is not reused on the next cycle, since ethReceived is computed as ethAfter - ethBefore and captures only the new swap delta. Recoverable exclusively via rescueETH by the permanent creator role at 0x66c66A4e56d444BB8630B269aef62CADA6A77F79, which is bounded and cannot rescue SCADA itself or the LP token. Off-chain visibility: LiquidityAddFailed and ErrorRecovered events fire on every catch path; address(this).balance drift is observable continuously. Combined residual risk is bounded loss-of-availability of orphan ETH until creator rescues it. The contract is deployed and immutable. Severity downgraded from High to Medium to reflect the bounded residual exposure with a working recovery path. The cleaner accumulator pattern with an unaccountedETH state variable is recommended for any future redeployment.

Acknowledged

#3 medium Issue
No slippage protection in auto-LP swap and addLiquidityETH calls
SCADAToken.sol
L388-395
L440-446
Description

_swapTokensForETH uses swapExactTokensForETHSupportingFeeOnTransferTokens with amountOutMin set to 0, and _swapAndAddLiq calls addLiquidityETH with both amountTokenMin and amountETHMin set to 0. The Uniswap documentation explicitly recommends amountOutMin > 0 for the fee-on-transfer variant, since the variant intentionally forgoes the K-invariant slippage check. Together these calls are fully sandwichable on every triggering sell, slowly leaking value to MEV searchers and contradicting the project's '100% efficient tax' claim.

Comments

Replace the hardcoded zeros with sane minimum-out values. Compute these on-chain from the pair's current reserves with a fixed tolerance such as 5%, for example: 'uint256 minETHOut = (expectedETH * 9500) / 10000;'. Optionally add a creator-controlled slippage parameter bounded between 50 and 500 basis points. Combined with moving auto-LP behind a keeper, this removes the sandwich exposure entirely.

Alleviation

The auto-LP path operates exclusively against the protocol's own SCADA/WETH pair (the canSwap predicate requires to == mainPair), so MEV exposure is bounded by the round-trip tax cost a sandwicher must pay to enter and exit the pair: 1.00 percent buy plus 1.20 percent sell, totaling 2.20 percent of the swap notional. For pool depths where the auto-LP swap stays inside that band, the sandwich is uneconomic. The per-cycle swap notional is also capped by MAX_SWAP_TOKENS = 10,000 SCADA, bounding the worst-case price impact. The contract is deployed and immutable, so the slippage parameters cannot be retrofitted. Mitigation relies on (a) maintaining sufficient pool depth so a single auto-LP swap stays inside the tax-cost band, and (b) operational monitoring of pool reserves to detect liquidity erosion before it makes the auto-LP path sandwichable. Severity retained at High to reflect that the residual MEV risk is real on shallow-liquidity periods even though it is bounded. The on-chain slippage hardening is recommended for any future redeployment.

low Issues | 6 findings

Acknowledged

#1 low Issue
Permissive bridgeBurn parameter accepts arbitrary 'from' address
SCADAToken.sol
L267-274
Description

The bridgeBurn function calls _burn(from, amount) without checking allowance, so the bridge can technically destroy any user's SCADA balance. Today this is safe because the only path that reaches bridgeBurn is wrap(), which always passes msg.sender as 'from'. However, the function design is more permissive than necessary and any future bridge variant could burn arbitrary balances without user consent.

Comments

Tighten the API so that the bridge cannot, by design, burn an arbitrary user's balance. A clean approach is to make the bridge call transferFrom into itself first and then burn its own balance, instead of calling _burn(from, amount) directly. Alternatively, add an allowance check inside bridgeBurn when 'from' is not msg.sender. This is defense-in-depth: the current bridge contract only ever passes the wrap caller as 'from', but the function signature does not enforce that constraint.

Alleviation

The only authorized caller is the SCADABridge, configured via a one-shot setBridge that requires bridge == address(0) on entry, so the bridge address is permanently locked to the deployed instance. The SCADABridge contract itself has no owner, no admin, and no upgrade path - all references (scada, wscada, scadaManager) are immutable, and its wrap function unconditionally passes msg.sender as the 'from' argument. There is no on-chain path that can reach bridgeBurn with a different from value. The contract is deployed and immutable. The recommendation is retained for any future redeployment.

Acknowledged

#2 low Issue
State changes in setAMMPair and setFeeExempt without distinct events
SCADAToken.sol
L232
L240
Description

setFeeExempt mutates the isFeeExempt mapping silently with no event. setAMMPair emits AMMPairSet, but that same event is also used by setMainPair, making it impossible for off-chain indexers to distinguish the two paths. This complicates monitoring, dashboards, and after-the-fact incident response.

Comments

Add a dedicated event such as FeeExemptUpdated(address indexed account, bool value) and emit it in setFeeExempt. Consider also emitting a different event (or a flag in AMMPairSet) to distinguish setAMMPair from setMainPair, so off-chain indexers and dashboards can reliably reconstruct the state.

Alleviation

Partially mitigated. setMainPair and setAMMPair both emit AMMPairSet(pair, value); off-chain indexers can disambiguate the two paths by tracking which transaction emitted the event and against which storage slot the call mutated. setFeeExempt remains uninstrumented and is callable by the permanent creator role, which is not renounceable. Operational mitigation for the deployed instance is to monitor the isFeeExempt mapping via direct storage reads on a periodic schedule and alert on any change. The contract is deployed and immutable. The event additions are retained for any future redeployment.

Pending

#3 low Issue
nonReentrant modifier is not the first modifier
SCADAToken.sol
L183
L246
L485
Description

Several functions order modifiers as 'onlyCreator nonReentrant'. None of the current access-control modifiers make external calls, so this is not directly exploitable, but the recommended best practice is to put nonReentrant first as defense-in-depth.

Comments

Place nonReentrant before any other modifier in the modifier list, for example: function rescueETH(uint256 amount, address to) external nonReentrant onlyCreator. This guarantees the reentrancy guard executes before any modifier code that could (now or in the future) make external calls.

Acknowledged

#4 low Issue
Solidity 0.8.20 has known issues - prefer a newer patch version
SCADAToken.sol
L1
Linterfaces/IERC20Helper.sol:1-2
Description

Solidity 0.8.20 contains three documented compiler issues: VerbatimInvalidDeduplication, FullInlinerNonExpressionSplitArgumentEvaluationOrder, and MissingSideEffectsOnSelectorAccess. None of them apply to this codebase (no inline assembly, no verbatim, no selector arithmetic), but using the most recent patched compiler is preferred.

Comments

For any future redeployment, pin the pragma to a recent stable compiler such as 0.8.24 or later, and recompile. The deployed bytecode at 0xa7D12701385abB9814F220D2df705b9FE75bFdFA cannot be patched in place; this recommendation applies to forks, migrations, and version 2 deployments.

Alleviation

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

Pending

#5 low Issue
Empty or weak require strings, plus 'uint' alias instead of 'uint256'
SCADAToken.sol
L194
L202
L210
L221
Description

Several require statements have no error string or only weak ones, and event signatures plus function parameters use the 'uint' alias instead of explicit 'uint256'. Pure style and gas issues, but on a 761 nSLOC contract these revert strings and inconsistent declarations add up to non-trivial bytecode and reduce readability.

Comments

Replace require strings with custom errors for clearer revert reasons and lower runtime cost, for example: 'error InvalidBuyTax(uint256 provided, uint256 min, uint256 max);'. Standardize on uint256 everywhere instead of the 'uint' alias. Run forge fmt and forge lint as a CI gate to keep the style consistent going forward.

Acknowledged

#6 low Issue
Unchecked ERC-20 transfer return value when sending LP tokens to the manager
SCADAToken.sol
L403
Description

After auto-LP, the contract calls IERC20(pairAddress).transfer(scadaManager, liquidity) without checking the boolean return value. The Uniswap V2 pair token is externally controlled. If transfer ever returns false without reverting (uncommon but allowed by the ERC-20 standard), the LP tokens stay in this contract while notifyNewLP is still invoked, so the manager would credit extraLP for liquidity it does not hold. The next supplyBlock then computes lpToRemove against an inflated extraLP and reverts on the actualLPBalance check, permanently disabling supplyBlock with no admin recovery path.

Comments

Use SafeERC20.safeTransfer for the LP transfer: 'SafeERC20.safeTransfer(IERC20(pairAddress), scadaManager, liquidity);'. SafeERC20 is already imported in this file, so no new dependency is needed. Make the same change anywhere ERC-20 tokens are moved without checking the return value. Additionally, do not call notifyNewLP if the LP transfer fails - either revert the auto-LP attempt or emit a structured ledger-correction event.

Alleviation

The pair token used for the LP transfer is fetched live from the canonical Uniswap V2 factory at 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f via getPair(address(this), WETH), so on Ethereum mainnet it is always the canonical UniswapV2ERC20 implementation. UniswapV2ERC20 (Solidity 0.5.16) reverts on insufficient balance via SafeMath.sub and unconditionally returns true on success - the silent-false branch this finding describes is unreachable against the live pair. The originally High-rated extraLP corruption scenario therefore cannot be triggered on the deployed pair. The contract is deployed and immutable. Severity downgraded from High to Low to reflect the unreachability of the underlying failure mode under the canonical pair. The SafeERC20 hardening is retained for any future redeployment where the pair token might be a non-canonical implementation.

optimization Issues | 4 findings

Pending

#1 optimization Issue
scadaManager could be declared immutable
SCADAToken.sol
L39
Description

scadaManager is set in the constructor and never modified afterwards, but it is declared as a regular storage variable. Marking it immutable removes a storage slot and saves gas on every transfer that touches the AMM pair logic.

Comments

Change 'address public scadaManager;' to 'address public immutable scadaManager;' and assign it once in the constructor. This saves an SLOAD on every transfer (since _update reads scadaManager indirectly) and removes any future code path that could change it. There is no current setter for this variable, so this is a pure improvement.

Pending

#2 optimization Issue
pairAddress is re-derived from the factory inside hot paths
SCADAToken.sol
L401
L472
Description

Inside _swapAndAddLiq and getMainPairInfo the pair address is fetched from the factory at runtime via getPair(...). The factory does not change and the pair address is already cached in mainPair after setMainPair runs. The redundant external call is wasted gas in the hot auto-LP path.

Comments

Replace the runtime call IUniswapV2Factory(UNISWAP_V2_FACTORY).getPair(...) with a direct read from the cached state variable mainPair, which is already populated by setMainPair during liquidity initialization and never changes afterwards. This saves an external static call (around 800 gas) per auto-LP cycle.

Pending

#3 optimization Issue
swapTokensAtAmount initialized twice
SCADAToken.sol
L69
L167
Description

swapTokensAtAmount is declared with an inline value of 10_000 * 1e18 and then immediately reassigned to the same value inside the constructor. The inline declaration writes a slot that is overwritten almost immediately, wasting an SSTORE at deployment.

Comments

Drop the inline initializer 'uint256 public swapTokensAtAmount = 10_000 * 1e18;' and keep only the constructor assignment. This removes one SSTORE at deployment time, saving roughly 20,000 gas, with no behavioral change.

Pending

#4 optimization Issue
Modifiers swapping and onlyManager are each invoked exactly once
SCADAToken.sol
L119-123
L138-141
Description

The 'swapping' modifier is used only by _swapAndAddLiq, and the 'onlyManager' modifier is used only by managerBurn. Single-use modifiers add unnecessary indirection and a small gas overhead.

Comments

Inline the modifier bodies into the only callsite. This saves around 40 gas per call and removes a layer of indirection, making the audit trail and future maintenance simpler.

informational Issues | 6 findings

Pending

#1 informational Issue
Contract does not formally inherit from its declared interface
SCADAToken.sol
L30
Linterfaces/ISCADAToken.sol
Description

An ISCADAToken interface is declared in src/interfaces/ISCADAToken.sol, but SCADAToken does not inherit from it. As a result the compiler does not verify that the public surface stays in sync with the interface. A separate but related issue is that SCADAMiner.sol redeclares its own local ISCADAToken interface, creating a name collision and a real maintenance hazard.

Comments

Make SCADAToken explicitly implement ISCADAToken: 'contract SCADAToken is ERC20, Ownable, ReentrancyGuard, ISCADAToken { ... }'. Also remove the duplicate ISCADAToken declaration that lives inside SCADAMiner.sol and import the canonical one from src/interfaces/ISCADAToken.sol. This makes the compiler enforce signature parity.

Pending

#2 informational Issue
Empty require string in setMainPair
SCADAToken.sol
L221
Description

setMainPair has an explicit defense-in-depth check require(msg.sender == scadaManager) on top of the onlyOwner modifier, but the require has no revert string. The intent of the dual check (covering the case where ownership is ever transferred away from the manager) is not visible to a future maintainer.

Comments

Add a descriptive revert reason: 'require(msg.sender == scadaManager, "setMainPair: only manager");'. This makes future maintenance and incident response easier without changing any behavior.

Pending

#3 informational Issue
Function and parameter naming follows leading-underscore style instead of mixedCase
SCADAToken.sol
L276
L232
L240
L209
L246
L485
Description

Several function parameters use leading underscores ('_bridge', '_creator', etc.) which deviates from the Solidity style guide's mixedCase convention. Pure style finding.

Comments

Rename function parameters from '_bridge', '_creator', and similar to plain 'bridge', 'creator' (or 'newBridge') to match the Solidity style guide. This is purely cosmetic and does not affect the ABI.

Pending

#4 informational Issue
Strict equality on ethReceived == 0 is intentional but flagged by detectors
SCADAToken.sol
L365
Description

_swapAndAddLiq uses 'if (ethReceived == 0)' as a recovery trigger when the router returns no ETH. The strict equality is correct here - any non-zero amount means a partial swap succeeded - but Slither and Decurity flag the pattern as a 'dangerous strict equality'. Documenting the intent prevents future false positives.

Comments

No code change required. Add a brief inline comment explaining that the strict equality is intentional - it gates the failure recovery path when no ETH was returned by the router - so future maintainers and tooling do not flag it as a bug.

Acknowledged

#5 informational Issue
Centralization disclosure - the creator role retains permanent recovery and parameter powers (not renounced)
SCADAToken.sol
L183-189
L232-235
L240-242
L485-490
L246-250
Description

Unlike the SCADAManager and SCADAMiner contracts (which have renounced ownership to address(0)), the SCADAToken's creator role is persistent by design. The creator is set in the constructor as immutable and there is no path to remove or change it. The creator's powers are intentionally bounded by hardcoded constants but they still represent a centralization vector that should be disclosed explicitly to investors and users.

Comments

This is a trust-model disclosure rather than a vulnerability. The creator role at 0x66c66A4e56d444BB8630B269aef62CADA6A77F79 retains the following permanent powers, all bounded by hardcoded constants: tune buy/sell tax inside [10, 200] basis points, tune the auto-swap threshold inside [10, 10_000] SCADA, mark/unmark addresses as AMM pairs (taxes them but does not block transfers), mark/unmark addresses as fee-exempt, rescue accidentally sent ERC-20 tokens (excluding SCADA itself and the LP token), rescue accidentally received ETH, manually trigger the auto-LP recovery path, and one-shot-set the bridge address. The creator cannot mint, cannot move user funds, cannot freeze transfers, cannot raise tax above 2 percent, and cannot un-set the bridge once configured. Document this scope clearly in user-facing material so holders understand the residual administrative surface, and consider migrating these powers to a multisig or a timelock if the project later wants to tighten the trust model.

Alleviation

Disclosure-only finding. The creator role at 0x66c66A4e56d444BB8630B269aef62CADA6A77F79 is set immutably in the constructor and cannot be revoked or rotated. All powers are bounded by hardcoded constants enforced at the contract level (MIN/MAX_BUY_TAX, MIN/MAX_SELL_TAX, MIN/MAX_SWAP_TOKENS, the cannot-rescue-SCADA/LP fence, and the one-shot setBridge guard). The creator cannot mint, move user funds, freeze transfers, raise tax above 2 percent on either side, or un-set the bridge once configured. The contract is deployed and immutable.

Acknowledged

#6 informational Issue
Centralization disclosure - rescueETH and rescueTokens allow the creator to extract any non-protocol asset from the contract
SCADAToken.sol
L183
L485
Description

rescueETH and rescueTokens let the creator extract any ETH or any non-SCADA, non-LP ERC-20 from the contract to an arbitrary recipient. The bounds are sensible (cannot rescue SCADA, cannot rescue the LP token) but the functions are unrestricted otherwise. Combined with the unaccountedETH situation noted in M-02, the creator can effectively reclaim any orphan funds that the auto-LP path leaks.

Comments

These functions are reasonable by design (the contract should not hold arbitrary assets) and are explicitly fenced against rescuing SCADA itself or the SCADA/WETH LP token. However, they constitute a permanent fund-recovery hook controlled by a single address. If the project later wants to harden the trust model, route both functions through a multisig wallet or a timelocked contract acting as creator. As an additional protection, log every rescue to an immutable on-chain registry so off-chain monitoring can flag unexpected outflows.

Alleviation

Disclosure-only finding. The rescue functions are fenced against the two assets that would represent protocol-fund extraction (SCADA itself and the SCADA/WETH LP token are explicitly blocked in rescueTokens), so the creator cannot drain user-held SCADA or the protocol's own liquidity through this path. Combined with the bounded creator role described in I-05, the residual surface is limited to recovering accidentally-sent assets and the orphan ETH path described in M-02. The contract is deployed and immutable.