Contract report

Risks (8)

• HighUnknown (unverified bytecode) can pause the contractpauseDeterministic

  unpause() (unknown (unverified bytecode)): can pause the contract's functions (e.g. deposits, payments or withdrawals).

  Evidence

  • staticprivilege unpause() restricted to unknown (unverified bytecode)
    Show source

    Can pause / freeze all transfers [selector 0x3f4ba83a]

  Confirmed by: facts

• HighUnknown (unverified bytecode) can pause the contractpauseDeterministic

  pause() (unknown (unverified bytecode)): can pause the contract's functions (e.g. deposits, payments or withdrawals).

  Evidence

  • staticprivilege pause() restricted to unknown (unverified bytecode)
    Show source

    Can pause / freeze all transfers [selector 0x8456cb59]

  • on-chainprivileges: pause() [selector 0x8456cb59], unpause() [selector 0x3f4ba83a]
    Show source

    Can pause / freeze all transfers

  • on-chainfunctions: setGuardian(address) 0x8a0dac4a, guardian() 0x452a9320, pausedAt() 0x2e55d0f2

  Confirmed by: facts, claude-opus-5.5, grok-4.7

• HighUnknown (unverified bytecode) can block walletsblacklistDeterministic

  blockNumber() (unknown (unverified bytecode)) lets the privileged account stop specific wallets from transferring or selling — a common way to trap buyers. Can block specific wallets from transferring/selling (blacklist / anti-bot) [selector 0x57e871e7]

  Evidence

  • staticprivilege blockNumber() restricted to unknown (unverified bytecode)
    Show source

    Can block specific wallets from transferring/selling (blacklist / anti-bot) [selector 0x57e871e7]

  Confirmed by: facts

• HighUnreadable contract appears to hold user depositsotherAI

  The target has no verified source and no decompiled code. Its function names (deposit(uint256), depositETH(), claim(uint64,address,uint256,bytes32[]), depositedBy(address), outstanding(), totals()) suggest it takes ETH and/or tokens from users and pays them out later against Merkle proofs, much like a bridge or claim vault. Because the code cannot be read, nobody can confirm who controls withdrawals, whether a hidden drain or sweep function exists, or whether claims can be blocked. Anyone who deposits is fully trusting the operators and the unseen bytecode.

  Evidence

  • on-chaincontract.verified = false; sourceFileCount = 0
    Show source

    "verified": false

  • on-chainfunctions: deposit(uint256) 0xb6b55f25, depositETH() 0xf6326fb3, claim(uint64,address,uint256,bytes32[]) 0xa2f94bd3, depositedBy(address) 0x10ef7792, outstanding() 0xe50d33e3

  Confirmed by: claude-opus-5.5, grok-4.7

• HighPrivileged poster sets the roots that decide who can claim fundsotherAI

  proposeRoot(uint64,bytes32,uint256), setPoster(address), poster() and batches(uint64) show that a privileged 'poster' publishes Merkle roots, and claim() pays out against those roots. If the poster key is compromised or acts maliciously, it can post a root that hands deposited funds to addresses it controls. The contract also has rootDelay(), MIN_ROOT_DELAY(), cancelRoot(uint64), dailyCap(), batchCap(), setCaps(uint256,uint256) and lowerCaps(uint256,uint256). These suggest a delay before roots take effect, a way to cancel bad roots, and limits on payout size. Their real values, who can call them, and whether they actually stop a bad root cannot be checked without source.

  Evidence

  • on-chainfunctions: proposeRoot(uint64,bytes32,uint256) 0x04ce7f94, setPoster(address) 0x73bbb71c, poster() 0x80959721, cancelRoot(uint64) 0x2ac6edb6
  • on-chainfunctions: rootDelay() 0xb95b7c95, MIN_ROOT_DELAY() 0xad8b9e9f, dailyCap() 0xeb339391, batchCap() 0xd41e4326, setCaps(uint256,uint256) 0x212bf316, lowerCaps(uint256,uint256) 0x2b7310a8

  Confirmed by: claude-opus-5.5, grok-4.7

• MediumSource code is not verifiedotherDeterministic

  The contract source is not published on the explorer, so nobody can read what it really does. The analysis relies on bytecode only.

  Evidence

  • on-chainexplorer: no verified source for 0xAB98d7a2303B82b230682C1c9B6D20D49662488C

  Confirmed by: facts

• MediumTeam confirms withdrawals are batched and need its approvalsocialAI

  Minehood's official account told players that yesterday's withdrawal requests were submitted together for approval and that processing can be tracked at this contract. That means payouts are not instant and self-serve: someone on the team has to approve the batch before funds move. If this address holds player deposits, those funds stay under the operator until that approval happens.

  Evidence

  • Xhttps://x.com/minehood_rh/status/2117913638006669645
    Show source

    Yesterday's withdrawal requests have been collectively submitted for approval. All transactions are now underway and being processed.
    
    You can track the transactions through the following wallet addresses:

  • webhttps://robinhoodchain.blockscout.com/address/0xAB98d7a2303B82b230682C1c9B6D20D49662488C?tab=index
    Show source

    View the account balance, transactions, and more for 0xAB98d7a2303B82b230682C1c9B6D20D49662488C on Robinhood Chain.

  Confirmed by: grok-4.7

• LowUnproven reply alleges team side wallets sell $MHDsocialAI

  One reply accuses the team of selling from side wallets and of using launch money to pay players so it looks like a long-term game. It is a single unverified comment with no transaction proof in the material, so it is an allegation only, not a confirmed dump.

  Evidence

  • Xhttps://x.com/Bilal50204067/status/2118297754061492679
    Show source

    @minehood_rh MHD tokene alım geldikçe yan cüzdanlarından sürekli satıyorlar. Lansmanla gelen yatırımcı parasını oyunculara göstermelik dağıtıp oyunculara para kazandırdıklarını söylüyorlar. Amaçları uzun vadeli bir proje değil kısa sürede kazanç sağlamak.

  Confirmed by: grok-4.7

Positive signals (1)

• PositiveFounder publicly linked to the Minehood accountsocialAI

  The project account names a founder handle, Ufuk (@ufukless1), whose bio says Founder @minehood_rh. That is a public identity link, not a legal doxx: no full name, photo ID, or company filing was in the material.

  Evidence

  • Xhttps://x.com/ufukless1/status/2118300407919259996
    Show source

    At first, people FUDed me because the game economy was built around ETH. Now they're FUDing me because the game economy is built around MHD.

  Confirmed by: grok-4.7

Notes (3)

• InfoWallet-blocking flag on blockNumber() is likely a false positiveotherAI

  The facts layer marked blockNumber() as a wallet-blocking (blacklist) function. The name matches an ordinary block-number getter, and the contract also has arbBlocks() and ARB_SYS(), which point to block-number lookups on an Arbitrum-style chain. Without source, the blacklist label is unconfirmed and likely a false positive.

  Evidence

  • on-chainprivileges: blockNumber() [selector 0x57e871e7]
    Show source

    Can block specific wallets from transferring/selling (blacklist / anti-bot)

  • on-chainfunctions: ARB_SYS() 0xbd8e62d6, arbBlocks() 0x8d0cbb32

  Confirmed by: claude-opus-5.5, grok-4.7

• InfoFunction names hint at an unverified emergency exit for usersotherAI

  activateEscape(), escapeActive(), escapeActivatedAt(), ESCAPE_DELAY() and ESCAPE_CLAIM_WINDOW() suggest an escape-hatch mode that lets users recover funds if operators stop working. The contract also exposes a timelock() address. These would be good safety features, but the conditions, who can trigger them and whether they work cannot be verified.

  Evidence

  • on-chainfunctions: activateEscape() 0x70da9aee, escapeActive() 0xfaca05ba, ESCAPE_DELAY() 0xf38e531e, ESCAPE_CLAIM_WINDOW() 0xd1101ba6, timelock() 0xd33219b4

  Confirmed by: claude-opus-5.5, grok-4.7

• InfoDeployed via a factory by a regular wallet; explorer reputation okdeployer-historyAI

  The contract was created through factory contract 0x4e59…956C, with transaction sender 0xE2a0…F96a, on 2026-11-02. It is not a proxy. Blockscout labels it reputation=ok and is_scam=false. These labels are only a weak extra signal. No deployer history was provided.

  Evidence

  • on-chainCreated by factory contract 0x4e59b44847b379578588920cA78FbF26c0B4956C; tx sender 0xE2a039Fb852afB13D013943413d7f296B7feF96a
  • tx0xfe3c1ae6…ef5be551
  • on-chainexplorer: isScam=false, reputation=ok

  Confirmed by: claude-opus-5.5, grok-4.7