veridiacoin (VC) security report
Radar AI scanned the verified VeridiaCoin contract and supplied GoPlus evidence. No Critical or High exploit was established. Medium risks involve a constructor-disabled initializer and full initial-supply custody by the factory caller. Slither was not run.
No Critical or High exploit was established from the supplied source. The main material concerns are a potentially broken initialization design and centralized initial-supply custody. GoPlus reports the token as mintable because the source contains an initializer mint, but no callable post-initialization mint function exists.
Trust score: 72/100. Source verified: Yes. Chain: ethereum. Contract: 0x116510fa1e99de5b2717426d064983d54aa4ac04.
This report was last modified on 2026-09-29 and contains 2 material findings.
medium finding: Constructor permanently disables initialize
The constructor sets factory to address(0xdead), while initialize() can execute only when factory equals address(0). As written, initialize() will always revert after deployment, preventing initialization and initial supply creation. This conflicts with the supplied GoPlus state showing a 1,000,000,000 total supply, so the deployed bytecode or deployment flow should be reconciled with the verified source.
Evidence: RobinVistaToken.constructor() executes factory = address(0xdead). initialize() begins with if (factory != address(0)) revert AlreadyInitialized();. The supplied GoPlus evidence reports total_supply=1000000000 and is_proxy=0, which is inconsistent with a fresh deployment of this source having an accessible initializer.
Recommendation: Verify the deployed runtime bytecode and constructor state against the published source. If this pattern is intended for factory deployment, use a correctly initialized clone or set the factory state during deployment. Do not rely on an externally callable initializer unless its one-time initialization state is deliberately and safely established.
medium finding: Entire initial supply is assigned to the factory caller
When initialization is reachable, the contract mints totalSupply_ directly to msg.sender, which is the factory rather than the declared deployer_ address. The contract contains no allocation limits, vesting, timelock, or required distribution mechanism. This creates a material custody and concentration risk during launch, even though no later external mint function is exposed.
Evidence: initialize() records deployer = deployer_ but calls _mint(msg.sender, totalSupply_). These balances do not by themselves establish malicious control, but they support the stated concentration concern.
Recommendation: Mint to an explicitly specified distribution or treasury address, or enforce documented allocation, vesting, and timelock rules in the launchpad. Emit and verify allocation events, and ensure deployer_ is either used or removed to avoid misleading custody expectations.