imdpet (IMDPET) security report
Radar by SecureChain AI scanned the verified imdpet source on Ethereum. The token has a fixed supply and no apparent honeypot controls, but the deployer receives the full initial supply and supplied gameplay modules rely on privileged operator controls.
No critical or high-confidence direct token-drain or honeypot path was identified in the supplied IMDPET token source. The main concerns are that the deployer receives the entire initial supply and that the supplied gameplay contracts allow an operator to alter core pet activity and outcomes.
Trust score: 58/100. Source verified: Yes. Chain: ethereum. Contract: 0x5faa9d5a8ee9eda4f92eb4588607066a5523e949.
This report was last modified on 2026-10-10 and contains 3 material findings.
medium finding: Entire fixed supply is assigned to the deployer at construction
The constructor mints the complete fixed supply directly to msg.sender. There is no vesting, distribution, timelock, or contract-enforced limit on subsequent transfers by that address. A compromised or malicious deployer key could therefore transfer the full initial allocation, creating substantial supply-control and market-impact risk.
Evidence: IMDPET constructor calls _update(address(0), msg.sender, _SUPPLY), where _SUPPLY equals 1,000,000,000 * 10**18. The contract provides no allocation controls or vesting logic.
Recommendation: Use an audited vesting or distribution contract where appropriate, document the deployment allocation, and apply independent controls to the address receiving the initial supply.
medium finding: Operator can unilaterally author gameplay activity and pet progression
The PetMealLedger operator can record accepted, rejected, and failed work for any seat, directly changing pet timers, accepted-step counts, and gameplay state. The operator can also hand control to another address. If these records influence benefits, rankings, or token-funded gameplay, the operator is a trusted centralized authority rather than an independently verified work source.
Evidence: serveApple, serveTea, serveBeer, leaveMess, and serveApplesToKennelRow require msg.sender == operator and update pet records. handOver allows the current operator to replace itself with any nonzero address.
Recommendation: Document the operator trust model, use a constrained reporter or verifiable data source, add auditable limits and monitoring, and consider multisig or governance-controlled operator rotation.
medium finding: Gameplay outcomes and economic parameters depend on privileged and block-derived controls
The supplied gameplay contracts allow the operator to change treat prices within a broad range and alter the attacker's win probability. Bonk outcomes also use block.prevrandao, block.number, block.timestamp, and a nonce, which are not a robust source of unbiased randomness for valuable outcomes. These controls can materially change gameplay economics and fairness if the modules are deployed and relied upon.
Evidence: PetTreatShop.setPrice permits the operator to set prices from 1e12 to 1,000,000 ether. PetBonkArena.setAttackerWinBps permits the operator to set the win probability from 3,000 to 6,000 basis points. _roll hashes block.prevrandao, block.number, block.timestamp, _nonce, attacker, and target.
Recommendation: Use a verifiable randomness source for consequential outcomes, put parameter changes behind transparent governance or timelocks, and define bounded pricing and outcome policies in deployment documentation.