Re:Ranker (RANK) security report
Radar AI scanned Re:Ranker RANK on Ethereum. The token has fixed supply and no detected blacklist or tax logic, but connected contracts contain privileged NFT mint/burn and signer controls.
The RANK token itself shows no detected mint, blacklist, fee, honeypot, or transfer-restriction mechanism in the supplied source. Material risks remain in the connected game contracts: forge addresses can mint and burn NFTs, signers can authorize rewards and ranks, and the initial token supply is assigned to the deployer.
Trust score: 48/100. Source verified: Yes. Chain: ethereum. Contract: 0x3d0be2a4a958ccca6b8af532a5fc0159023d80b1.
This report was last modified on 2026-10-13 and contains 4 material findings.
high finding: Configured forge contracts can mint unlimited NFTs and burn existing NFTs
Each supplied NFT contract gives its configured forge authority to create new items and destroy any existing item. The deployer sets the forge once through setForge(), and forgeMint() and forgeBurn() do not require token-holder consent. If a malicious or compromised forge is configured, it can dilute NFT supply or irreversibly destroy user-held items.
Evidence: RiftBlades.sol, WardenArmor.sol, BeastTrophies.sol, ShardRelics.sol, RankSigils.sol, RankerCharms.sol, HealingVials.sol, ZoneDeeds.sol, BestiaryCards.sol, and GateCompanions.sol each implement setForge(address f) with msg.sender == owner and forge == address(0) checks. Their forgeMint() calls _mint(to,k) for the forge, while forgeBurn(uint256 id) deletes _owners[id] and decrements the holder balance without checking holder approval. The same pattern is used by the other supplied NFT contracts.
Recommendation: Use immutable, audited role addresses or a multisignature-controlled role registry. Separate mint and burn permissions, restrict burning to assets explicitly deposited for crafting, add holder authorization where appropriate, and emit or enforce governance controls for forge changes before deployment.
medium finding: Signer-controlled rank and reward issuance is a centralized authorization risk
The game signer can determine player rank progression and authorize claims from funded reward pools. A compromised or malicious signer can assign arbitrary points, mint rank sigils through progression, or redirect authorized reward claims to callers. This is a privileged-control risk rather than an unprivileged exploit in the reviewed code.
Evidence: RankLadder.setSigner() allows the current signer to replace signer with any nonzero address. RankLadder.submit() accepts any higher pts value accompanied by a signature from signer and then calls sigils.forgeMint() for each rank through the submitted score. QuestBoard.setSigner() has the same replacement pattern, and QuestBoard.claim() pays a signer-authorized amount up to MAX_CLAIM from the contract's RANK balance.
Recommendation: Use multisignature or governance-controlled signer rotation, publish signer changes, enforce bounded score and reward policies on-chain where feasible, and add replay-domain/versioning and operational monitoring for signer compromise.
medium finding: The entire fixed RANK supply is assigned to the deployer at construction
The token has no visible post-deployment mint path, but its constructor assigns the entire fixed supply to msg.sender. Control of the deployer-held allocation is therefore a material distribution and key-management risk. The source does not provide vesting, timelocks, or an on-chain allocation schedule.
Evidence: ReRankerERC constructor calls _update(address(0), msg.sender, _SUPPLY), where _SUPPLY is 1000000000 * 10**18. No vesting, timelock, or allocation contract is implemented in ReRankerERC, and the token's transfer functions permit the recipient to transfer the allocation normally.
Recommendation: Use a documented multisignature or allocation contract for initial distribution, add vesting or timelocks where appropriate, and publish deployment and allocation controls. Treat the deployer key as a high-value administrative asset.
medium finding: GoPlus open-source status conflicts with the supplied source evidence
The supplied GoPlus signal reports is_open_source=0, while Radar was provided with a multi-file Solidity source package described as verified. This inconsistency does not prove a contract defect, but it limits confidence that the reviewed source corresponds to the deployed bytecode and that all relevant dependencies were exposed to GoPlus.
Evidence: GoPlus evidence contains "is_open_source":"0". The scan input separately supplies verified Solidity source for ReRankerERC and numerous imported contracts. Slither was not run, so no independent bytecode-to-source or static-analysis confirmation is available in this report.
Recommendation: Reconfirm the deployed bytecode, compiler settings, constructor arguments, and every imported contract against the verified source on the Ethereum explorer. Resolve the GoPlus verification discrepancy before relying on source-based conclusions.