NOFAP (NOFP) security report
Radar AI scanned the verified NOFAP contract on Base. Findings include high-severity bridge authority to mint arbitrary amounts and burn tokens from arbitrary addresses. Slither was not run.
NOFAP is not proxy-based and its ordinary transfers do not show honeypot, blacklist, pause, or fee-manipulation behavior. However, the SuperchainTokenBridge can mint arbitrary amounts and burn tokens from arbitrary addresses without allowance. These are high-severity privileged-control risks that require bridge compromise, misconfiguration, or malicious bridge behavior.
Trust score: 48/100. Source verified: Yes. Chain: base. Contract: 0x2f7077ad88f124ab471af2710b6543ddacbd5b07.
This report was last modified on 2026-10-13 and contains 2 material findings.
high finding: SuperchainTokenBridge can mint arbitrary token amounts
The fixed SuperchainTokenBridge predeploy can call crosschainMint with any recipient and amount. This mint path does not enforce the constructor's maxSupply_ value; it only remains subject to ERC20Votes' much larger uint208 safe-supply limit. A compromised, misconfigured, or malicious bridge could therefore create substantial additional NOFP supply and dilute existing balances.
Evidence: In ClankerToken.sol, crosschainMint(address _to, uint256 _amount) checks only msg.sender != Predeploys.SUPERCHAIN_TOKEN_BRIDGE, then executes _mint(_to, _amount). The constructor uses maxSupply_ only for the initial _mint(msg.sender, maxSupply_) call, and no maxSupply_ storage variable or cap check exists for later bridge mints. GoPlus also reports is_mintable=1.
Recommendation: Document the bridge trust model and expected cross-chain supply invariant. Add an explicit global supply cap or bridge-mint accounting if the token is intended to have a fixed maximum supply, and use monitoring or governance controls for bridge mint events. Treat the bridge as a critical issuer authority.
high finding: SuperchainTokenBridge can burn tokens from arbitrary addresses
The fixed SuperchainTokenBridge can invoke crosschainBurn for any _from address and amount. The function does not require an allowance or verify that the address initiated a cross-chain transfer. If the bridge or its message-validation path is compromised or misused, balances can be destroyed without the token holder's approval.
Evidence: In ClankerToken.sol, crosschainBurn(address _from, uint256 _amount) checks only that msg.sender equals Predeploys.SUPERCHAIN_TOKEN_BRIDGE, then directly calls _burn(_from, _amount). Unlike burnFrom, it does not call _spendAllowance. The inherited _burn function deducts the specified account balance and reduces total supply.
Recommendation: Make the bridge's authorization and message-validation assumptions explicit, monitor CrosschainBurn events, and ensure the bridge implementation can only request burns backed by authenticated outbound transfers. Consider additional protocol-level safeguards against arbitrary-account burn requests.