Independent security analysis of the $NANOCLAW smart contract using Slither static analysis (101 detectors) and manual code review. No critical or high-risk vulnerabilities found.
The constructor() and setTreasury() accept an address parameter without validating it isn't the zero address. Setting treasury to 0x000...000 would make revenue unrecoverable.
Risk is limited — both functions are owner-only. This is an operational concern, not an external attack vector.
The claimRevenue() function uses .transfer() which forwards only 2300 gas. Holders using smart contract wallets (e.g., Gnosis Safe) may be unable to claim revenue as their fallback functions require more gas.
Regular EOA wallets (MetaMask, Trust Wallet, etc.) are unaffected.
If someone accidentally sends a random ERC-20 token to this contract address, those tokens are permanently locked. No rescueTokens() function exists.
Anyone can call depositRevenue() and deposit POL. This doesn't risk fund loss (it's giving money to holders) but could cause accounting confusion between legitimate bot revenue and external deposits.
The RevenueClaimed event is emitted after .transfer(). While technically against checks-effects-interactions pattern, .transfer() limits gas to 2300, preventing reentrancy. No actual risk.
OpenZeppelin's interface files use broad version constraints (>=0.4.16, >=0.6.2). The listed compiler bugs are irrelevant — the contract was compiled with Solidity 0.8.20+ which resolves all issues. Standard across every project using OpenZeppelin.
Three inherited OpenZeppelin functions are unused: _burn(), _msgData(), _contextSuffixLength(). Normal for any ERC-20 token — no security or gas impact.
The dividend-per-share (revenuePerToken) pattern is correctly implemented. The _update() override properly settles both sender and receiver before token transfers, preventing double-claiming. Token allocation math sums to exactly 100M.