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

Milestone HODL Token Info

dev-mht.github.io

Milestone HODL Token (MHT) is a decentralized protocol on the BNB Smart Chain engineered to transform market growth into direct, automated rewards for holders. By integrating Chainlink Automation technology, MHT eliminates human intervention, ensuring token distribution is strictly based on real-time Market Cap performance.

Milestone HODL Token Logo
Onboarded date 09/03/2026

Team and KYC Verification

The team has securely submitted their personal information to SolidProof.io for verification.

In the event of any fraudulent activities, this information will be promptly reported to the relevant authorities to ensure accountability and compliance.

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.

85.36
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

"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
0x22E0...33fa
Network
BNB Smart Chain - Mainnet
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2026/03/09
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 Milestone HODL Token (MHT) contract implements a BEP-20 token on BNB Smart Chain with milestone-driven holder rewards, automatic LP tranches, a flush-LP schedule on price tiers, Chainlink Automation, buy and sell taxes, an anti-whale per-transaction cap, a hardcoded V1 snapshot airdrop with mirror burn, and a deliberate trustless transition through renounceOwnership. V2.3 is a cosmetic-only revision over V2.2_corrected and applies the three remaining stylistic items from the prior audit (I-16 modifier ordering on rescueTokens, I-17 marketing-BNB observability event, I-18 dead _swapping toggle removal). All HIGH and MEDIUM items from earlier rounds are resolved or accepted as documented design trade-offs. A few residual items still need attention before mainnet:

  • Spot-price reads in getMarketCap and getMHTPrice still gate milestone, LP-tranche and flush-LP releases. The team has accepted this as a design trade-off; the mitigation rests on five layers (registry caller restriction, 1 percent maxTx, 7 percent round-trip taxes, LP tokens routed to burn, and the one-tranche-per-upkeep cap). A multi-block adversarial-timing surface remains and is documented in NatSpec.
  • The blacklist primitive is bounded to a 7-day post-deploy window and a 32-address cap. After day 7 the function reverts unconditionally, including for un-blacklisting, so the entire list must be reviewed before the window closes. This should be a hard deadline in the launch checklist.
  • The catch branch of the auto-LP path discards the success boolean of the marketing-wallet BNB salvage. Pre-renounce these BNB amounts are recoverable through rescueTokens. Post-renounce, if the marketing wallet ever rejects native BNB, the value would be silently stranded. A 1-wei native-BNB probe of the marketing wallet between initLiquidity and renounceOwnership is the recommended off-chain mitigation and should be a hard prerequisite for renounce.

Ownership Privileges

The ownership of the contract has not yet been renounced - the deploy plan calls for renounceOwnership() after the live configuration is verified. Until that step, the owner retains a meaningful admin surface. After renounce, the contract becomes fully trustless and every privilege below is permanently removed.

  • Set the PancakeSwap pair address and initialise 30M MHT plus 10 BNB of starting liquidity (one-shot through initLiquidity).
  • Set or change the Chainlink Automation registry. Setting the registry is mandatory before renounceOwnership can succeed; the same applies to liquidity initialisation.
  • Maintain the blacklist (redirect-to-burn) within the 7-day window and the 32-address cap, and grant or revoke per-address exemptions from taxes, the per-transaction cap, and the rewards distribution.
  • Adjust the per-transaction cap within hard bounds of 0.1 percent and 10 percent of total supply, and rescue accidentally-sent tokens or BNB (for MHT, strictly bounded to the contract balance not already tracked).
  • After renounce, no party can change the pair, the registry, the blacklist, the exclusion sets, the per-transaction cap, or rescue stuck assets.
  • The owner cannot mint new tokens.
  • The owner cannot pause transfers or freeze user balances arbitrarily (the blacklist is windowed and capped).
  • The owner cannot drain user-held tokens or affect the milestone reward accounting of any holder.

Security Features

The contract implements several positive security features:

  • ReentrancyGuard with nonReentrant on every privileged or value-moving entry point (initLiquidity, performUpkeep, claimRewards, rescueTokens), and a separate _swapping latch that suppresses tax and anti-whale logic during the contract's own internal swaps.
  • Strict Chainlink oracle validation (roundId, answer, updatedAt, answeredInRound) with a 600-second staleness window, roughly ten times the BNB/USD heartbeat on BSC. Registry-restricted performUpkeep, a 24-hour milestone cooldown, and a one-tranche-per-upkeep cap on both LP-MCap and flush-price paths prevent multi-tranche cascades.
  • Post-constructor allocation invariant that asserts balanceOf(this) equals the sum of all tracked balances, plus a renounce-time dual guard requiring both a configured automation registry and an initialised liquidity pool. The operational brick scenario that would have frozen roughly 80 percent of the supply if renounce was called out of order is blocked on chain.
  • Router refund on the auto-LP success path is captured and forwarded to the marketing wallet, observable through a dedicated MarketingBnbForwarded event with discriminated source codes for all three native-BNB-to-marketing paths. Eligible-supply denominator excludes the contract, burn address, pair and marketing wallet so the milestone rate reflects claimable holders only, and LP tokens minted during auto-liquidity are routed directly to the burn address.

Note - This audit report consists of a security analysis of the Milestone HODL Token smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Milestone HODL Token team. Other contracts associated with the project were not audited 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
Medium
3
Low
Optimization
3
Informational
high Issues | 2 findings

Resolved

#1 high Issue
Constructor founderBonus Calculation Over-Counted flushLpBalance
MilestoneHodlToken_V2_3.sol
L527-540
L621-624
Description

The previous fix that introduced the BONUS pro-rata distribution added six BONUS constants and six super._update calls but failed to subtract the snapshot total from the founderBonus formula. Tracked balances therefore exceeded the actual contract balance by exactly the snapshot total of 4,300,573.505500874925621347 MHT. flushLpBalance was overstated by exactly that amount. Operational impact would have been that the sixth flush tranche, which sweeps the whole remaining flushLpBalance, would have triggered an insufficient-balance revert and the state machine would have been permanently stuck.

Comments

Verified end to end with full 256-bit precision. The constructor subtracts both the holdersBonus total (3,959,969 MHT) and the holdersSnapshot total (4,300,573.505500874925621347 MHT) from BONUS_V1_SUPPLY to compute the founder share. flushLpBalance after the constructor is exactly 61,706,452.560769524309831498 MHT, balanceOf(this) is exactly 791,706,452.560769524309831498 MHT, and the post-constructor invariant balanceOf(this) == vaultBalance + lpBalance + startLpBalance + flushLpBalance holds to the wei. These numbers match the on-chain readings reported on the BSC testnet deployment exactly. Confirmed unchanged in V2.3.

Alleviation

Subtract the snapshot total inside the constructor so that founderBonus = BONUS_V1_SUPPLY - holdersBonus - holdersSnapshot. Set flushLpBalance = startResidue + founderBonus. Add a post-construct invariant assertion that balanceOf(this) equals vaultBalance + lpBalance + startLpBalance + flushLpBalance and refuse to deploy if it does not match. Add a long-running invariant test that balanceOf(this) is greater than or equal to vault + lp + startLp + flush + autoLpBuffer + marketingBuffer + rewardsPool to catch any future regression.

Resolved

#2 high Issue
_autoAddLiquidity Did Not Reset Tranche Flag When addLiquidityETH Reverts
MilestoneHodlToken_V2_3.sol
L1143-1195
Description

_autoAddLiquidity pre-decremented lpBalance or flushLpBalance before the external swap and addLiquidity calls. On swap failure (bnbReceived == 0) the flag and balance were correctly restored. But on addLiquidityETH failure, the catch block only reset the _swapping flag; the tranche flag remained true and the tracked balance remained decremented even though only the half that went through the swap had actually left the contract. The other half MHT and the bnbReceived BNB were untracked inside the contract. After renounceOwnership() they would have been permanently stranded. The failure mode was highly likely with the previous 5% slippage on amountETHMin.

Comments

The catch branch resets the tranche flag with otherHalf (not the full mhtAmount, which would over-credit because half was already swapped away to the pair), forwards bnbReceived to marketingWallet, and the amountETHMin was relaxed to bnbReceived/4. The accounting is internally consistent and the original permanent stranding is closed. The relaxed slippage side effect (router refund up to 75% on the success path) was tracked separately as MHT-V22-M-01 and is resolved in V2.2_corrected with explicit refund forwarding to marketingWallet. V2.3 adds a discriminated MarketingBnbForwarded event to both branches for observability. Confirmed unchanged in V2.3.

Alleviation

In the catch branch reset the tranche flag so the keeper retries, and adjust the tracked-balance restore to add back only otherHalf (the half that is still inside the contract) rather than the full mhtAmount (the other half is already gone, swapped to the pair). Forward the BNB just received to marketing or burn it. Loosen amountETHMin: the original 95% bound was the wrong invariant because it bounds the gap between the swap output and the pairing optimum, which is structurally large after a self-induced sell. A safer bound is bnbReceived/4, which allows 75% imbalance. Cap the cascade by releasing at most one tranche per performUpkeep so tranche N+1 does not fire against the post-tranche-N price.

medium Issues | 5 findings

Resolved

#1 medium Issue
_swapAndDistribute Stranded keepForLP MHT When addLiquidityETH Reverts
MilestoneHodlToken_V2_3.sol
L1285-1290
Description

Inside _swapAndDistribute, autoLpBuffer and marketingBuffer were cleared before the addLiquidityETH attempt. If addLiquidityETH reverted (caught by try/catch), the BNB was salvaged into bnbForMkt and forwarded to marketing, but the keepForLP MHT (equal to autoLpBuffer/2) had already been implicitly deducted by the buffer reset. That MHT remained in the contract but was no longer tracked anywhere. Pre-renounce the loss was recoverable, post-renounce it would have been permanent. Cumulative under volatile market conditions where the slippage band is repeatedly tripped.

Comments

The catch branch burns keepForLP to BURN_ADDRESS, which is consistent with the deflationary LP-burn design philosophy and prevents permanent stranding. The bnbForLP earmark is rolled into bnbForMkt and forwarded with the marketing send. The fix is clean and aligned with the rest of the contract. Confirmed unchanged in V2.3.

Alleviation

On addLiquidityETH catch do one of: burn keepForLP to BURN_ADDRESS (deflationary, matches the burned-LP design philosophy); restore autoLpBuffer = keepForLP so the next sell retries; or increment a marketing accounting variable equal to the keepForLP MHT-equivalent and reflect it on the next swap. Burning is the simplest and most aligned with the existing design.

Resolved

#2 medium Issue
setBlacklistBatch Was an Irreversible-After-Renounce Confiscation Primitive
MilestoneHodlToken_V2_3.sol
L1334-1351
Description

Pre-renounce, the owner could mark any address with isRedirectToBurn = true. Once set, every transfer out of that address was silently converted into a burn: taxes were skipped, anti-whale was skipped, _updateReward(from) was called, then super._update(from, BURN_ADDRESS, value). The user retained the balance only nominally; any movement burned it. Because the owner could blacklist a holder immediately before renounceOwnership(), the blacklist became permanent. This was documented as silent anti-scam but represented a confiscation primitive and a centralisation risk that did not exist in earlier versions.

Comments

Core issue resolved. Both the time and size bounds are enforced on chain: the 7-day window uses an immutable deployTime, and a blacklistCount counter caps the active list at 32 entries. Mandatory NatSpec disclosure is in place. Residual operational trade-off (acknowledged): after day 7 the function reverts unconditionally, so even un-blacklisting (redirectToBurn = false) is no longer possible. If a holder is mistakenly blacklisted on day 6 and the team only notices on day 8, recovery is impossible. This is the deliberate cost of trustlessness post-renounce. The team must therefore review and verify the entire blacklist before the 7-day window closes, and disclose this clearly to the community. Treat the day-7 cutoff as a hard deadline in the launch checklist. Confirmed unchanged in V2.3.

Alleviation

Make the function callable only within a fixed window after deployment (for example require(block.timestamp <= deploymentTime + 7 days)); cap the maximum number of blacklisted addresses (for example <= 32); and require that every blacklist call emit a public on-chain rationale or at least a clear event so the listing service and the community can audit entries before renounce. Mandatory disclosure in the project page is also recommended.

Resolved

#3 medium Issue
automationRegistry Permanently Zero After Renounce Freezes All Milestones, LP and Flush
MilestoneHodlToken_V2_3.sol
L1415-1419
Description

performUpkeep required automationRegistry != address(0) and msg.sender == automationRegistry. If the deployer forgot to setAutomationRegistry before renounceOwnership, the registry would be permanently zero and no one could call performUpkeep. The full vaultBalance, lpBalance and flushLpBalance would have become permanently unreleasable. There was no recovery path post-renounce. This was a one-line operational mistake that could have bricked roughly 76% of the supply forever.

Comments

renounceOwnership is overridden to revert if automationRegistry is the zero address. The deployer must call setAutomationRegistry first, which is the safe ordering recommended. The customer's testnet log confirmed the revert path. Same pattern is also applied for liquidityInitialized (V22-M-02 / M-05 fix). Confirmed unchanged in V2.3.

Alleviation

Override renounceOwnership() to revert if automationRegistry equals the zero address. This allows the deployer to verify the registry address is correct and fund the upkeep before relinquishing control. An alternative would be to bake the registry address as immutable in the constructor, but the override pattern is safer because it keeps a verification step before the trustless transition.

Resolved

#4 medium Issue
Aggressive bnbReceived/4 Slippage Strands BNB Refunded by addLiquidityETH
MilestoneHodlToken_V2_3.sol
L1159
L1171-1178
Description

_autoAddLiquidity uses amountETHMin = bnbReceived/4 to allow up to 75% slippage on the BNB side. This was needed because a self-induced sell shifts the pool ratio, so pairing the full otherHalf MHT only consumes a fraction of the BNB just received. PancakeSwap V2 router refunds msg.value - amountETH back to msg.sender, which is the contract. The MHT contract has receive() and accepts the refund. That BNB is not credited to any tracked accounting variable, so post-renounce the only path to send BNB out of the contract is the same _autoAddLiquidity / _swapAndDistribute flow which uses the freshly-received delta and never touches the historical refund.

Comments

Resolved in V2.2_corrected (customer label M-04). The success branch of _autoAddLiquidity captures address(this).balance before the addLiquidityETH call, computes the router refund as bnbAfterAdd - (bnbBeforeAdd - bnbReceived), and forwards it to marketingWallet via low-level call. Math verified: bnbBeforeAdd = previousBalance + bnbReceived (no BNB-changing op between _swapMHTForBNB and the capture line); the subtraction cannot underflow; the contract's pre-existing BNB balance is preserved (only the new refund is forwarded). V2.3 adds an explicit MarketingBnbForwarded(bnbRefund, 1) emit on this success-path forward for observability. Residual concern: the boolean returned by the marketing forward is discarded, so a marketingWallet that rejects native BNB silently strands the refund (tracked under V22-N-01 with operational mitigation via the deploy runbook).

Alleviation

Measure the refund explicitly inside _autoAddLiquidity by tracking address(this).balance before and after the addLiquidityETH call and forward any positive delta to marketingWallet on the success path with a checked transfer. The same hardening can be applied to the addLiquidityETH call in _swapAndDistribute, although the tighter 5% slippage there caps the leak per cycle to 5% at most. Avoid simply tightening _autoAddLiquidity slippage because the looser bound was intentional to prevent reverts after a self-sell.

Resolved

#5 medium Issue
renounceOwnership Should Also Require liquidityInitialized
MilestoneHodlToken_V2_3.sol
L1415-1419
Description

The custom renounceOwnership override correctly guards against a missing automation registry but does not guard against a missing initial liquidity. If renounce is called before initLiquidity, startLpBalance is locked, the pair has no reserves, all price-derived functions revert, and performUpkeep cannot fire. The contract is permanently bricked and roughly 80% of the supply (start LP, vault, LP and flush balances) is frozen forever, with no recovery path because all owner functions are dead.

Comments

Resolved in V2.2_corrected (customer label M-05). The renounceOwnership override now requires both automationRegistry != address(0) (M-09) and liquidityInitialized == true (M-05) before delegating to super.renounceOwnership(). Customer testnet trace confirms both revert paths: 'MHT: Set registry first' when registry is unset, 'MHT: Init liquidity first' when liquidity is uninitialised. The operational brick scenario that would have frozen ~80% of supply is closed. Recommended deploy ordering: setPancakePair -> initLiquidity -> setAutomationRegistry -> setBlacklistBatch (within 7 days) -> verify exclusions -> probe marketingWallet BNB acceptance -> renounceOwnership. Confirmed unchanged in V2.3.

Alleviation

Extend the renounceOwnership override with an additional require: require(liquidityInitialized, 'MHT: Init liquidity first'). One line, no downside, prevents the operational brick that would lock about 80% of the supply if the deployer renounced before calling initLiquidity. Pair this with a deploy runbook that enforces the strict ordering: setPancakePair -> initLiquidity -> setAutomationRegistry -> setBlacklistBatch (within 7 days) -> renounceOwnership.

low Issues | 8 findings

Resolved

#1 low Issue
Unused Return From Low-Level Call Allows Silent BNB Loss
MilestoneHodlToken_V2_3.sol
L660-661
L1191-1193
L1295-1296
Description

Solc 0.8.34 emits 'unused local variable' warnings for several (bool sent, ) = payable(addr).call{value: x}('') sites. If the receiver is a contract whose receive or fallback reverts, the returned boolean is false but no error is propagated. In initLiquidity this could leave fragments of the deposited BNB stranded. In _swapAndDistribute every successful sell could silently leak BNB to a misconfigured marketing wallet. Pre-renounce the BNB is recoverable via rescueTokens, post-renounce it would be permanently stranded.

Comments

Two of the three low-level call sites are properly checked. In initLiquidity (lines 660-661), the BNB refund to msg.sender uses require(ok, 'MHT: BNB refund failed'). In _swapAndDistribute (lines 1295-1296), the marketing transfer uses require(sent, 'MHT: Marketing BNB transfer failed'). The third site, inside the _autoAddLiquidity catch branch (lines 1191-1193), still discards the boolean return. Now emits MarketingBnbForwarded(_, 2) for observability (V2.3 [I-17] fix). The intent is documented in NatSpec ('recoverable via rescueTokens while owner active') and the team accepts the trade-off pre-renounce. Tracked separately as MHT-V22-L-02 for the post-renounce residual.

Alleviation

Always inspect the boolean returned by low-level call. For initLiquidity (the BNB refund of msg.sender) add require(sent, 'MHT: BNB refund failed'). For _swapAndDistribute (the marketing send) the safe approach is to require success on the call. Alternatively document that marketingWallet must be an EOA or a contract with an unconditional receive() and add a deploy-time assertion.

Resolved

#2 low Issue
excludeFromRewards Allows Setting Self-Inclusion of address(this)
MilestoneHodlToken_V2_3.sol
L1357-1375
Description

_updateReward always returns early for account == address(this). If the owner mistakenly called excludeFromRewards(address(this), false) to 'include' the contract, the function would silently update userRewardPerTokenPaid and clear the exclusion flag, but _updateReward would still skip subsequent updates. The contract's own balance could therefore never accumulate pending rewards, but the owner would be led to believe it could.

Comments

The function reverts when the caller passes address(this) or BURN_ADDRESS, so the foot-gun is removed. The address-zero guard was already in place. Confirmed unchanged in V2.3.

Alleviation

Add require(addr != address(this), 'MHT: cannot include contract'); inside excludeFromRewards. Apply the same protection to BURN_ADDRESS so that the contract itself and the burn sink can never be flipped back to a rewards-eligible state.

Resolved

#3 low Issue
BNB/USD Oracle Staleness Window Too Generous
MilestoneHodlToken_V2_3.sol
L690
Description

The previous version accepted a Chainlink answer up to 60 minutes stale. The BSC BNB/USD aggregator updates on a 0.5% deviation or every 60 seconds, so the previous threshold allowed a price 60x more stale than normal heartbeat. Combined with the 24h MILESTONE_COOLDOWN this was benign for milestones, but the LP-tranche and flush-LP paths could fire repeatedly within that window with a stale BNB price.

Comments

Staleness window reduced from 3600 to 600 seconds. With the BNB/USD heartbeat of around 60 seconds on BSC, the new tolerance gives a 10x safety margin which is consistent with industry practice. Confirmed unchanged in V2.3.

Alleviation

Reduce the require(block.timestamp - updatedAt < ...) window to 600 to 900 seconds and document the chosen heartbeat tolerance.

Resolved

#4 low Issue
High Cyclomatic Complexity in _resetTrancheFlag
MilestoneHodlToken_V2_3.sol
L1199-1216
Description

_resetTrancheFlag uses an 11-arm if/else dispatch that toggles tranche flags and adjusts lpBalance or flushLpBalance based on a tranche id. The hand-rolled dispatch is hard to review, easy to break with a future tranche-id change, and is repeatedly flagged by static analysis with cyclomatic complexity 12.

Comments

Resolved in V2.2_corrected. _resetTrancheFlag is a two-branch dispatch (LP tranches 1-5 vs flush tranches 101-106) with a single balance increment per branch. Cyclomatic complexity dropped from 12 to ~7. The recommended array-based refactor was not adopted, but the new shape is materially clearer and the dispatch is symmetric. The _update simplification via _collectTaxes (lines 787-822) is preserved. Confirmed unchanged in V2.3.

Alleviation

Refactor _resetTrancheFlag to use two arrays: bool[5] for the LP tranches and bool[6] for the flush tranches, each indexed by tranche number minus the appropriate offset. Keep the public lpTranche{1..5}Released and flushTranche{1..6}Released getters as thin view shims so the ABI does not change. The dispatch then becomes a one-line update plus a balance increment for each of the two ranges.

Resolved

#5 low Issue
performUpkeep Lacks nonReentrant
MilestoneHodlToken_V2_3.sol
L968
Description

performUpkeep chains _executeMilestone -> _swapAndDistribute -> addLiquidityETH/swap and _checkAndReleaseLPTranches -> _autoAddLiquidity -> swap, with no nonReentrant modifier in V2.1.1. Re-entry was bounded by the strict automationRegistry caller check and by the _swapping boolean inside _update. If automationRegistry is ever set to a multicall-style relay, an EOA, or a contract that can be tricked into re-entering, the _swapping boolean alone would be insufficient.

Comments

nonReentrant modifier present on performUpkeep. Defence-in-depth is in place against any future change of automationRegistry. Confirmed unchanged in V2.3.

Alleviation

Add nonReentrant to performUpkeep. Cost is zero risk to the keeper flow and gives full belt-and-braces against any future registry change.

Acknowledged

#6 low Issue
Silent BNB Loss in _autoAddLiquidity Catch Path
MilestoneHodlToken_V2_3.sol
L1188-1193
Description

Inside the _autoAddLiquidity catch branch, the BNB salvage path does (bool okCatch, ) = payable(marketingWallet).call{value: bnbReceived}(''); okCatch; which intentionally drops the return value to silence the unused-variable warning. If the marketing destination ever rejects the transfer, the BNB sits inside the contract balance with no tracking variable. After renounceOwnership() the rescueTokens function becomes unreachable, so the BNB cannot be recovered through any normal flow.

Comments

The catch branch still forwards bnbReceived to marketingWallet using a low-level call and discards the success boolean (the variable is renamed okCatch and a NatSpec note states 'recoverable via rescueTokens while owner active'). V2.3 adds emit MarketingBnbForwarded(bnbReceived, 2) so the salvage attempt is observable on chain. The team has explicitly chosen to keep this trade-off rather than introduce a bnb-buffer + flush function. Pre-renounce the funds are recoverable via rescueTokens. Post-renounce, if marketingWallet rejects native BNB, the funds are permanently stranded. Mitigated operationally by the deploy-runbook step that probes marketingWallet acceptance with a 1-wei test before renounceOwnership. Acknowledged residual.

Alleviation

Avoid hard-constraining the marketing wallet to an EOA - multisigs are a legitimate operational choice. Instead, the requirement is behavioural: marketingWallet must accept native BNB transfers (a contract wallet must implement receive() or fallback() in a non-reverting form). Two complementary changes are recommended. First, on the marketing call in the catch branch, capture the boolean and on failure store the BNB in a marketingBnbBuffer state variable plus emit a MarketingPushFailed(value) event, so monitoring can detect a misconfigured wallet immediately. Second, expose a permissionless flushMarketingBnb() function that retries the send to marketingWallet against the buffered amount; this keeps the path live after renounceOwnership() and removes the silent-loss surface entirely. As a deploy-time sanity check, the team can also probe the configured marketing wallet by sending a 1-wei test transaction before renouncing.

Acknowledged

#7 low Issue
Marketing-Wallet BNB Acceptance Is an Unverified Deploy-Time Invariant
MilestoneHodlToken_V2_3.sol
L1175
L1191
L1295
Description

After the M-04 (V22-M-01) fix in V2.2_corrected, three code paths can route native BNB to marketingWallet. _swapAndDistribute uses require on the success boolean (loud failure). The two _autoAddLiquidity paths intentionally discard the boolean (silent failure). This asymmetric trust model is acceptable pre-renounce because a misconfigured wallet would be detected immediately by failed sells, but post-renounce a marketingWallet that cannot receive native BNB will continue to silently strand value into the contract address with no event and no recovery path.

Comments

The contract has three native-BNB transfer paths to marketingWallet with asymmetric failure semantics: _swapAndDistribute (line 1295) reverts on failure (require(sent)), while both _autoAddLiquidity paths (success-path refund forward at 1175, catch-path salvage at 1191) silently swallow the failure. If marketingWallet is misconfigured to reject native BNB, user sells exceeding the swap threshold will revert with a clear error (visible immediately), but keeper-driven LP and flush tranches will continue and silently strand BNB. Post-renounce the stranded BNB cannot be recovered. V2.3 adds a discriminated MarketingBnbForwarded event on all three paths so the silent-loss surface is at least observable. Closed operationally by adding a 1-wei native-BNB probe of marketingWallet to the deploy runbook between initLiquidity and renounceOwnership.

Alleviation

Operational (no code change required for mainnet): include in the deploy runbook a step that sends a 1-wei native-BNB transaction from the deployer to marketingWallet after initLiquidity and before renounceOwnership. If it succeeds, the marketing-wallet's native receive path is proven live. Document this as a hard prerequisite for renounce. Optional code hardening: introduce a marketingBnbBuffer state variable plus a permissionless flushMarketingBnb() retry function so the silent-loss surface is closed even after renounce.

Acknowledged

#8 low Issue
Spot-Price getMarketCap and getMHTPrice Manipulable Under Adversarial Timing
MilestoneHodlToken_V2_3.sol
L700-722
L726-745
L968-995
Description

getMarketCap and getMHTPrice derive their value from IPancakePair.getReserves() with no time-weighting. performUpkeep re-reads them at execution time and gates all milestone, LP-tranche and flush-LP releases on those spot values. The atomic single-transaction attack is not exploitable because performUpkeep is gated by the automation registry caller check. The realistic threat is multi-block adversarial timing: an attacker holds a manipulated price across the keeper polling window so checkUpkeep returns true on a manipulated reading and the actual performUpkeep transaction lands while the spike is still active. The 24h milestone cooldown limits the milestone path but does not protect the LP-tranche or flush paths.

Comments

Acknowledged by the project team. Five-layer mitigation in place: (1) Chainlink registry restricts performUpkeep callers, (2) the 1% maxTxAmount caps per-transaction price impact, (3) the 2% buy and 5% sell taxes make round-trip manipulation expensive, (4) any released LP tokens are sent directly to the burn address so the attacker cannot extract a profit, and (5) the cascade is capped at one LP tranche and one flush tranche per performUpkeep so a multi-block adversary cannot trigger several tranches in a single manipulated transaction. Mandatory NatSpec disclosure remains on getMarketCap, getMHTPrice and performUpkeep. The residual multi-block adversarial-timing surface still exists for individual tranches but is substantially smaller. Confirmed unchanged in V2.3.

Alleviation

Defence-in-depth options in order of strength: compute a 30-minute TWAP from PancakeSwap V2 cumulative reserves and use that for the upkeep gate; gate price-driven releases on observation persistence by firing only if the price has been above the threshold for several consecutive blocks; cap the per-upkeep cascade by releasing at most one LP tranche and one flush tranche per performUpkeep; and explicitly document the trust assumption that the automationRegistry is a Chainlink Automation registry whose keepers do not sandwich their own upkeep.

informational Issues | 18 findings

Resolved

#1 informational Issue
Stale Comment on flushLpBalance Pool Size
MilestoneHodlToken_V2_3.sol
L348-350
Description

The constructor comment block previously cited 65,666,421.560 MHT or 45,699,426.494 MHT figures that did not match the executed code. After the H-04 fix the correct value is 61,706,452.560770 MHT and the comment must reflect that.

Comments

Comment reads 61,706,452.560770 MHT and matches the actual code result. Confirmed unchanged in V2.3.

Alleviation

Update the comment block above flushLpBalance to match the post-fix code: pool total flush LP equals startResidue (19,966,995.066270 MHT) plus the founder share of Bonus V1 net of snapshot and prorata bonus (41,739,457.494499 MHT), totalling 61,706,452.560770 MHT, distributed over 6 price tiers where the 6th tier sweeps the remainder so there is no dust.

Resolved

#2 informational Issue
First Milestone Bypassed Cooldown Because lastMilestoneTimestamp Was Zero
MilestoneHodlToken_V2_3.sol
L666
Description

lastMilestoneTimestamp was left at the storage default of zero. The cooldown check block.timestamp >= 0 + MILESTONE_COOLDOWN was always true at deploy, so the first milestone had no cooldown protection. Combined with the spot-price oracle behaviour, this could have allowed a thin-liquidity manipulation at the very first eligible block to fire the first milestone, the first LP tranche and the first flush tranche together.

Comments

Set inside initLiquidity at the same time as liquidity is added, so the first milestone respects the 24h cooldown from the moment trading begins. Confirmed unchanged in V2.3.

Alleviation

Initialise lastMilestoneTimestamp = block.timestamp inside initLiquidity() so the first milestone is at least 24 hours after liquidity is added.

Resolved

#3 informational Issue
pendingRewardsOf Uses Live balanceOf and Latent Component Drifts on Transfer
MilestoneHodlToken_V2_3.sol
L884-894
Description

pendingRewardsOf returns pendingRewards[account] plus (balanceOf(account) * delta) / 1e18. If a user transfers all tokens out before claiming, _updateReward(from) inside _update computes the latent component at the old balance and crystallises it correctly, but a front-end that read pendingRewardsOf before the transfer and then re-reads after will see the same crystallised value plus a newly-zero latent component, which can look like a jump to the user. This is the standard staking pattern and is correct on-chain.

Comments

Documented in NatSpec as a UX guidance for front-end integrators. The on-chain accounting is exact; only the displayed value can appear to jump at the moment of a transfer. Confirmed unchanged in V2.3.

Alleviation

Document in NatSpec that pendingRewardsOf is exact only when called immediately after _updateReward (i.e. after any transfer or claim). Optionally split the view into a crystallised and a latent component so the front-end can present both clearly.

Resolved

#4 informational Issue
_executeFlush Per-Tranche Math Depends on Cumulative Balance
MilestoneHodlToken_V2_3.sol
L1117-1120
Description

Per-tranche amount is flushLpBalance / (7 - trancheNumber) for tranches 1 through 5 and flushLpBalance for tranche 6. The math is sound only if tranches fire in strict sequence and flushLpBalance accurately reflects the contract holdings. With the H-04 fix in place this holds, but the invariant is worth keeping under test.

Comments

NatSpec note explains the dependency on the H-04 invariant. With H-04 verified to the wei, and with the V22-I-01 / I-09 cascade cap (one flush tranche per upkeep) operationally guaranteeing strict sequential firing, the math is sound. Confirmed unchanged in V2.3.

Alleviation

Add a Foundry invariant test that asserts mht.balanceOf(address(mht)) is always greater than or equal to vaultBalance + lpBalance + startLpBalance + flushLpBalance + autoLpBuffer + marketingBuffer + rewardsPool over the full system lifetime to catch any future regression in the per-tranche accounting.

Resolved

#5 informational Issue
Pre-Renounce Owner Can Permanently Grant Tax and maxTx Exclusions
MilestoneHodlToken_V2_3.sol
L1377-1392
Description

excludeFromFees and excludeFromMaxTx allow the owner to grant any address tax-free or unlimited-tx privileges. Pre-renounce only, but a malicious or compromised deployer could grant these privileges to an attacker wallet then renounce, leaving the attacker with permanent immunity. Not a vulnerability in the cryptographic sense, just a governance and due-diligence note.

Comments

Disclosure NatSpec is present on excludeFromFees and excludeFromMaxTx. This is a governance and due-diligence item rather than a code defect: the deployer must verify the exclusion list before calling renounceOwnership. Confirmed unchanged in V2.3.

Alleviation

Document the pre-renounce admin surface in the project page and in NatSpec on the affected functions. The deployer should verify the snapshot of exclusions before renouncing. Optionally consider a one-shot lock that snapshots all exclusions at renounceOwnership(), although this is automatic in practice because renounce sets _owner to zero and onlyOwner reverts afterwards.

Resolved

#6 informational Issue
Hardcoded V1 Snapshot Recipient Addresses Must Be Verified
MilestoneHodlToken_V2_3.sol
L580-617
Description

Six hardcoded addresses receive the V1 snapshot and bonus prorata at deploy. ERC-20 transfer to a contract whose receive reverts does not revert (no callback), but if any of the six addresses is a self-destructed contract or a now-deprecated multisig whose threshold can no longer be reached, the tokens are unreachable on-chain. The audit cannot verify ownership of those addresses and depends on the project team's due diligence.

Comments

Comment confirming manual verification of the six addresses is in place. The audit cannot independently verify private key custody; this remains an off-chain trust item that the team has acknowledged and dispatched. Confirmed unchanged in V2.3.

Alleviation

Confirm with each holder that the address is currently controlled and able to sign transactions. Check on the explorer that each address has recent activity. Document that the V1 token had the same balances at the snapshot block.

Resolved

#7 informational Issue
V1_BURN_MIRROR Constant Cannot Be Verified Without V1 Address
MilestoneHodlToken_V2_3.sol
L574
Description

V1_BURN_MIRROR was presented as the exact V1 burn balance at snapshot time. If the V1 burn balance changed between the snapshot block and the V2.1 deploy block, the mirror would be stale. Pinning the V1 address in source allows mechanical verification.

Comments

The V1 contract address is pinned in the @custom:v1 NatSpec tag (0x4EA0b53dC11c6C361904383b20E321d1478C37ac). The team's pre-deploy checklist should include a script that queries the V1 contract at the deploy block and asserts that V1.balanceOf(BURN_ADDRESS) equals V1_BURN_MIRROR within rounding. Confirmed unchanged in V2.3.

Alleviation

Pin the V1 contract address in the NatSpec (@custom:v1 0x...) and write a Foundry script that queries the V1 contract at the V2.1 deploy block and asserts IERC20(V1).balanceOf(BURN_ADDRESS) equals V1_BURN_MIRROR plus or minus 1 wei. Run it as part of the pre-deploy checklist.

Resolved

#8 informational Issue
encodeWithSelector Replaced With encodeCall for Type Safety
MilestoneHodlToken_V2_3.sol
L1442-1444
Description

rescueTokens previously used encodeWithSelector for the IERC20.transfer call to an arbitrary token. encodeCall is the modern type-safe alternative and is preferred to catch signature mismatches at compile time.

Comments

Uses abi.encodeCall(IERC20.transfer, (owner(), amount)) which is type-checked at compile time. Confirmed unchanged in V2.3.

Alleviation

Replace abi.encodeWithSelector with abi.encodeCall in low-level transfer calls inside rescueTokens for compile-time argument checking.

Pending

#9 informational Issue
Stylistic Static-Analysis Findings Roll-Up
MilestoneHodlToken_V2_3.sol
Lvarious
Description

Aggregate roll-up of low-impact static-analysis findings observed in V2.3: use-custom-error-not-require, large-numeric-literal, use-nested-if, inefficient-state-variable-increment, use-multiple-require, init-variables-with-default-value, naming-convention on the external IPancakeRouter02.WETH() function (cannot change), and dangerous strict equality on bnbReceived == 0 (intentional zero-detection of swap failure).

Comments

Aggregate of low-impact stylistic flags from the static analysis run. None are security blocking. Address as part of routine cleanup if and when convenient. V2.3 re-run with Slither 0.11.5 and Aderyn 0.6.8 produced no net-new actionable items beyond the redundant-statement flags on the documented unused-boolean discard markers (fwd; and okCatch;).

Alleviation

Optional gas micro-optimisations and stylistic improvements. None block deploy. Consider replacing require with custom errors where appropriate, switching to scientific notation for large literals, splitting compound require statements into multiple require statements with clearer revert reasons, and using prefix increment in loops where idiomatic.

Resolved

#10 informational Issue
Constructor _swapping Toggle Around super._update Was Dead Code
MilestoneHodlToken_V2_3.sol
L562-617
Description

The previous constructor set _swapping = true around super._update calls. Because those used super._update (the ERC-20 base) and not the override that gates on _swapping, the flag had no effect. The dead code mis-led readers about constructor behaviour.

Comments

Removed from the constructor. The constructor calls super._update directly without the misleading toggle. The same dead-code pattern previously present in rescueTokens has now been removed in V2.3 (customer label I-18, see MHT-V22-N-02). Confirmed unchanged in V2.3 for the constructor.

Alleviation

Delete the _swapping = true and _swapping = false toggles around the constructor super._update calls. They neither help nor harm but they suggest a tax or anti-whale pathway is being skipped that does not exist for super._update.

Resolved

#11 informational Issue
rescueTokens Lacked nonReentrant Modifier
MilestoneHodlToken_V2_3.sol
L1427
Description

rescueTokens executes a low-level call against an arbitrary token contract address. A malicious token could re-enter into other onlyOwner functions during its transfer. No privileged user-state could be re-entered to drain user funds because everything else is onlyOwner anyway, but defence-in-depth was free.

Comments

nonReentrant present on rescueTokens. Defence-in-depth against any malicious token whose transfer could re-enter. V2.3 also reorders the modifier chain so nonReentrant precedes onlyOwner (customer label I-16, tracked under MHT-V22-N-04). Confirmed in V2.3.

Alleviation

Add nonReentrant to the function signature. Replace the inline encoded-selector pattern with a SafeERC20-style helper that wraps the low-level call and the data check together. As a follow-up, place nonReentrant as the first modifier so any future modifier added to the chain is also covered by the re-entrancy guard.

Resolved

#12 informational Issue
Cascading Tranche Releases in a Single performUpkeep
MilestoneHodlToken_V2_3.sol
L1049-1079
L1085-1115
Description

When the market cap or the spot price jumps far above several thresholds at once, performUpkeep can fire all eligible LP and flush tranches in the same transaction. Each tranche moves the pool, so the next tranche fires against a price that has already absorbed the previous tranche's impact. There is no cap on the cascade.

Comments

Resolved in V2.2_corrected (customer label I-09 / I-12). _checkAndReleaseLPTranches and _checkAndFlushLP have explicit return statements after each tranche release. At most one LP tranche and one flush tranche fire per performUpkeep call. The keeper must invoke multiple times if several thresholds are crossed simultaneously, which gives the price a chance to settle between releases and substantially reduces the multi-block manipulation surface from M-06. Side benefit: the per-tranche flush math (flushLpBalance / (7 - trancheNumber)) is operationally guaranteed to fire 1->6 in order with no dust. Confirmed unchanged in V2.3.

Alleviation

Refactor _checkAndReleaseLPTranches and _checkAndFlushLP to release at most one LP tranche and one flush tranche per call. The keeper would then need multiple performUpkeep calls (one per block) to release a sequence, which gives the price a chance to settle between tranches and substantially reduces the multi-block manipulation surface from M-06.

Resolved

#13 informational Issue
Blacklisted Addresses Can Claim Rewards But Cannot Use Them
MilestoneHodlToken_V2_3.sol
L900-912
Description

claimRewards blocks excluded-from-rewards addresses but does not block redirect-to-burn (blacklisted) addresses. The reward payout uses super._update which is the base ERC-20 transfer and bypasses the override. A blacklisted wallet therefore receives the reward in its balance but cannot transfer it without triggering a burn through the override.

Comments

Resolved in V2.2_corrected (customer label I-13). claimRewards reverts with 'MHT: Blacklisted address' for any account flagged isRedirectToBurn. The unusable-dust accumulation surface is closed. Minor residual: pendingRewards continue to accrue to blacklisted holders via _update -> _updateReward whenever they participate in a transfer; those rewards become un-claimable but remain accounted, slightly reducing rewardsPool headroom for non-blacklisted holders. Optional one-line cleanup in setBlacklistBatch (zero pendingRewards on flag-set) would reclaim that headroom; not a security issue. Confirmed unchanged in V2.3.

Alleviation

If the design intends blacklisted holders to forfeit all activity, add a require(!isRedirectToBurn[msg.sender]) check in claimRewards. Alternatively, document the current behaviour explicitly so users understand that claiming is allowed but spending is not. Either is acceptable; the current behaviour is not a bug, just an inconsistency worth documenting.

Acknowledged

#14 informational Issue
Self-Tax Gas Cost on User Sells Above Swap Threshold
MilestoneHodlToken_V2_3.sol
L787-822
L1247-1302
Description

The override _update calls _collectTaxes which can call _swapAndDistribute when the combined autoLp and marketing buffers exceed SWAP_THRESHOLD. The full cycle - swap MHT to BNB, addLiquidityETH, marketing transfer - runs inside the user's transaction context and consumes their gas. This is industry standard for tax tokens.

Comments

Observation. When a holder sells, _collectTaxes invokes _swapAndDistribute before the user's main transfer completes. This means the holder pays gas for the entire swap-and-distribute cycle (potentially including an addLiquidityETH call) when buffers exceed SWAP_THRESHOLD. This is a standard tax-token pattern and is documented practice on BSC. No fix needed; just informational so the team can prepare a clear support note about why some sells cost noticeably more gas than others. Confirmed unchanged in V2.3.

Alleviation

No change recommended. Document in user-facing material that some sell transactions trigger an internal swap and distribution to top up liquidity and marketing, and that those transactions therefore cost more gas than a plain transfer. The 100,000 MHT threshold on the buffer keeps this from happening on every sell.

Acknowledged

#15 informational Issue
Single-Step transferOwnership Regression
MilestoneHodlToken_V2_3.sol
L191-194
Description

transferOwnership executes immediately without an acceptance step from the new owner. If the owner accidentally passes a wrong address (typo, copy-paste error), ownership is irrevocably lost and all admin functions become permanently inaccessible.

Comments

Observation. The contract uses a minimal in-file Ownable that exposes a single-step transferOwnership and renounceOwnership. The published deploy plan calls for renounceOwnership and not transferOwnership, so the practical risk is bounded. If the team ever decides to transfer instead of renounce, do it from a multisig or via a 2-step Ownable derivative, because pre-renounce mistake recovery is impossible if the new owner address is wrong. Confirmed unchanged in V2.3.

Alleviation

If transferOwnership will ever actually be used before renounce, replace the inline Ownable with a 2-step variant (a pendingOwner state and an explicit acceptOwnership call). If the deploy plan is to renounce only, consider removing transferOwnership entirely so it cannot be used by accident.

Resolved

#16 informational Issue
Dead Code _swapping Toggle Around super._update in rescueTokens
MilestoneHodlToken_V2_3.sol
L1427-1448
Description

rescueTokens wraps super._update with _swapping = true / _swapping = false. Because super._update calls the base ERC-20 _update, the override gating on _swapping is never reached. The toggle is dead code that mis-leads readers about the function's behaviour. Identical in shape to the previously-resolved MHT-I-15 finding for the constructor.

Comments

Resolved in V2.3 (customer label I-18). The _swapping = true / _swapping = false toggles previously wrapping super._update inside rescueTokens have been removed. NatSpec note '[N-02] _swapping toggles supprimés - super._update appelle la base ERC-20, le flag _swapping n'est pas vérifié dans ce chemin (dead code supprimé)' confirms the intent. The function now matches the constructor cleanup that was applied earlier under MHT-I-15.

Alleviation

Delete the _swapping = true and _swapping = false toggles around the super._update call inside rescueTokens. The toggle is ineffective because super._update bypasses the override that checks _swapping, and the misleading code suggests an internal-swap path is being protected when it is not.

Resolved

#17 informational Issue
No Event Emitted for BNB Forwarded to Marketing Wallet
MilestoneHodlToken_V2_3.sol
L497
L1177
L1193
L1297
Description

After the M-04 fix, three paths can move native BNB from the contract to marketingWallet. None emitted a dedicated event in V2.2_corrected. The aggregated SwapAndDistribute event covered only the _swapAndDistribute path. Monitoring tools that wanted to distinguish sources or detect silent forwarding failures could not do so from on-chain logs alone.

Comments

Resolved in V2.3 (customer label I-17). New event MarketingBnbForwarded(uint256 amount, uint8 source) is declared at line 497 and emitted from all three native-BNB-to-marketing call sites with discriminated source codes: source=1 in _autoAddLiquidity success-path refund forward (line 1177), source=2 in _autoAddLiquidity catch-path salvage (line 1193), source=3 in _swapAndDistribute (line 1297). Operators can now distinguish which path is responsible for a given marketing BNB inflow on chain. Note: source=2 is emitted unconditionally on the boolean return, so a consumer cannot distinguish 'forwarded successfully' from 'salvage attempted but receiver rejected' - the deploy-time 1-wei probe of marketingWallet remains the intended monitor for that case.

Alleviation

Introduce an event such as event MarketingBnbForwarded(uint256 amount, uint8 source) and emit it from all three native-BNB-to-marketing call sites with distinct source codes (1 = _autoAddLiquidity success refund, 2 = _autoAddLiquidity catch salvage, 3 = _swapAndDistribute). This provides full on-chain accounting of the marketing BNB stream without changing logic.

Resolved

#18 informational Issue
nonReentrant Should Be the First Modifier on rescueTokens
MilestoneHodlToken_V2_3.sol
L1427
Description

rescueTokens declared modifiers in the order onlyOwner nonReentrant. Static analysers (Aderyn, Slither) recommend that nonReentrant always be the first modifier so any future modifier added to the chain is automatically covered by the re-entrancy guard.

Comments

Resolved in V2.3 (customer label I-16). Modifier order on rescueTokens is now 'external nonReentrant onlyOwner' so the re-entrancy guard precedes any other modifier in the chain. Future-proofs the function against any later modifier addition that might call out before nonReentrant takes effect. Aderyn no longer flags this.

Alleviation

Reorder modifiers to nonReentrant onlyOwner so the reentrancy guard precedes any other modifier in the chain. This is a recommended best practice and matches the convention used by OpenZeppelin's reference implementations.