Emerald AI (Emerald) security report
Emerald AI was AI-scanned using verified source and GoPlus evidence. No active Critical or High issue was confirmed. The main Medium risk is unrestricted first-call initialization on an uninitialized clone, which could let an attacker set metadata and mint the initial supply. The source also makes direct deployment uninitializable, creating a deployment-integrity concern. Slither was not run.
No Critical or High-confidence active exploit was confirmed from the supplied evidence. The main material risk is a Medium-severity initialization design flaw: if an instance is ever uninitialized, any address can call initialize first and mint an arbitrary initial supply to itself. Slither was skipped, so this is not a completed static-analysis result.
Trust score: 72/100. Source verified: Yes. Chain: ethereum. Contract: 0x0f796941b72ecbc9a0cce455c070461aac5941bf.
This report was last modified on 2026-09-29 and contains 2 material findings.
medium finding: Unrestricted first-call initialization can let an attacker claim an uninitialized clone
The initialize function is externally callable and only checks whether factory is zero. It does not verify that msg.sender is the intended launchpad factory. On a clone or instance whose factory storage is still zero, the first caller can set token metadata, choose deployer, and mint any totalSupply_ to itself.
Evidence: RobinVistaToken.initialize() contains `if (factory != address(0)) revert AlreadyInitialized();`, then assigns `factory = msg.sender` and calls `_mint(msg.sender, totalSupply_)`. No factory allowlist or caller authorization is checked. GoPlus reports the current token as initialized with total supply and holders, so exploitation of this specific address is not established from the supplied data.
Recommendation: Restrict initialize to the expected factory, use an immutable or constructor-configured factory authority, and ensure deployment and initialization occur atomically. Add tests proving an arbitrary address cannot initialize an uninitialized instance.
medium finding: Shown constructor makes direct deployment permanently uninitializable
The constructor sets factory to a nonzero sentinel address, while initialize reverts whenever factory is nonzero. A contract deployed directly with this constructor can therefore never initialize, never mint its intended supply, and retain zero metadata and balances. This is a deployment-integrity risk and may indicate that the source is intended only for minimal-proxy clones.
Evidence: The constructor executes `factory = address(0xdead);`. initialize immediately executes `if (factory != address(0)) revert AlreadyInitialized();`.
Recommendation: Make the deployment model explicit. If clones are required, use a dedicated implementation pattern and factory-controlled initialization; if direct deployment is supported, do not set factory to a nonzero value before initialization. Verify deployed bytecode, constructor state, and initialization transaction against the published source.