Kungaupei (KUNG) security report
Radar AI scanned Kungaupei KUNG on Ethereum. Findings include full initial deployer allocation and a source-to-ABI functionality mismatch. Slither was not run.
The token transfer logic is relatively simple and lacks several common administrative attack surfaces, but the deployment has a material concentration risk because the full supply is initially assigned to the deployer. The source and supplied ABI also appear inconsistent: the ABI exposes promise and operator functionality that the supplied Kungaupei contract does not implement.
Trust score: 62/100. Source verified: Yes. Chain: ethereum. Contract: 0x737cdd61c72cbd0320c06c976dda960307aef12e.
This report was last modified on 2026-10-10 and contains 2 material findings.
medium finding: Entire fixed supply is initially assigned to the deployer
The constructor assigns the complete fixed supply to msg.sender in one transaction. The token contains no vesting, timelock, treasury distribution, or contract-enforced allocation mechanism, so the deployer has unilateral control over the initial token inventory and can transfer it without protocol restrictions.
Evidence: In contracts/Kungaupei.sol, the constructor sets _tot = _SUPPLY and _bal[msg.sender] = _SUPPLY. _SUPPLY is defined as 1,000,000,000 * 10**18. The transfer function permits the balance holder to move tokens to any nonzero address, with no vesting or release schedule.
Recommendation: Use audited vesting or timelock contracts for deployer and treasury allocations, publish the allocation schedule, and consider separating operational, treasury, and ecosystem balances under transparent controls. Verify the deployed allocation independently before relying on the token distribution model.
medium finding: Supplied ABI and verified source expose materially different functionality
The supplied ABI includes promise-ledger state and functions such as pledge, claimKept, confirmKept, setGrace, and operator controls, while the supplied Kungaupei source defines only the token implementation and basic constants, balances, allowances, and burn functions. The source also imports auxiliary contracts but does not instantiate them in the constructor. If this ABI is intended for the scanned address, integrations may target unavailable selectors and the documented multi-contract functionality may not exist at that address.
Evidence: The supplied ABI lists promiseCount, promises, keptCount, pledge, confirmKept, setGrace, and operator. In the supplied contracts/Kungaupei.sol, the constructor only initializes _tot and the deployer's balance; there is no deployment of CellKeyRegistry, SealedRendezvousVault, PromiseScoreLedger, or BurnSignalBook, and no pledge or operator implementation in the contract body.
Recommendation: Reconcile the verified artifact, deployed bytecode, and ABI. Confirm that the ABI corresponds to the scanned address, publish the addresses and deployment relationships of any auxiliary contracts, and test every advertised selector against the deployed bytecode before enabling integrations.