InitVerse (INI): Backdoors, Blacklists, Stolen PoW & Pool Lockout – Centralized Mining

Like other pools such as K1Pool, we’re always on the lookout for new coins to support. We came across InitVerse (INI), were genuinely interested, and started digging — only to find the backdoors, blacklist, stolen algorithm, and centralized control we document below. We’re publishing this so the community and exchanges can see what’s in the code and on the chain.

—

What Is InitVerse?

InitVerse claims to be a decentralized PoW blockchain using their “VersaHash” algorithm. They sell ASIC miners (Pinecone INIBOX, 850 MH/s), cloud mining hashrate (inimining.cloud), and raised 500 BTC (~$50M) from investors. INI trades on MEXC and XT.COM at ~$0.12.

What we found after analyzing their node source code, on-chain data, and miner binary tells a very different story.

For a recent video overview: Rabid Mining on YouTube — InitVerse (INI) breakdown and Nexa2InitVerse (proof that INI uses NexaPoW and the pool blocks GPU miners).

—

Finding 1: VersaHash Is NexaPoW (Rebranded)

Their “proprietary” VersaHash algorithm is cryptographically identical to NexaPoW — same double SHA-256, same Schnorr signature (secp256k1, RFC 6979), same Schnorr+SHA256 tag, same final SHA-256. They took Nexa’s algorithm, renamed it, and called it their own. Independent proof: Nexa2InitVerse mines INI using standard NexaPoW (Rigel) via an adapter that speaks YatesPool; the chain accepts the blocks, confirming algorithm identity. The privacy and homomorphic-computing features they market (e.g. data processing for hospitals or labs) are not present in the node code; the chain is a fork of Binance Smart Chain (itself a fork of Ethereum), with nothing meaningfully new on-chain.

They have two whitepapers. The Technical White Paper describes Proof of Resources (POR) with validators and an 86% / 10% / 4% block split, halving at 1 year then every 3 years — the live chain does not implement that. The one they link on their site, the INIChain Whitepaper, matches the current narrative: PoW, VersaHash, DDA, team “mining address” for “community building and airdrops,” weekly halving — same as the tokenomics page. So the “official” story is the INIChain whitepaper; the catch is that VersaHash in it is just NexaPoW (same algorithm, rebranded). The Technical White Paper’s POR design is unimplemented.

—

Finding 2: YatesPool Is Effectively the Only Pool — and They Control Who Can Produce Blocks

InitVerse publicly says anyone can mine with GPUs and run nodes. In practice, they control who can produce blocks and have designed the pool protocol to block GPU miners.

Block producer whitelist. They maintain a whitelist of addresses that can produce blocks. As K1Pool have reported и Nexa2InitVerse demonstrates: only official wallet addresses can serve as nodes, and even if someone finds a block, they can’t add it to the chain. So they define who can actually mine blocks — not just who can transact.

YatesPool is the only mining pool that works for INI. When a miner connects, the pool sends a Ping that only an inibox (their ASIC) can decode. If the miner fails to respond with the correct Pong, it is disconnected. This blocks anyone from submitting shares using standard NexaPoW miners or GPU software like Rigel — even though the underlying algorithm is NexaPoW.

Independent researchers built Nexa2InitVerse to prove the point: by connecting an inibox to the adapter, they can impersonate an inibox and mine INI using NexaPoW (Rigel) on the other side. The adapter decodes the Ping, responds with the correct Pong, and forwards shares. Without an inibox to spoof, GPU miners are locked out.

Reports from others state: Their official GPU mining software runs at roughly one-twentieth of normal speed to appear different from NexaPoW. On their pool, GPU hashrate is capped at 10 MH/s display unless you buy an inibox. The inibox itself is very likely a modified Dragonball Nexa ASIC miner — same algorithm, locked to their pool. So: one pool (YatesPool), a whitelist of who can produce blocks, protocol-level blocking of GPU miners, and a strong incentive to buy their hardware.

As of March 2, 2026, we attempted connecting with a GPU and CPU per their mining guide and could not even connect at all even using their exact example run command (and our own address). This leads us to believe they have completely disabled GPU and CPU mining

—

Finding 3: 77% of Blocks From Four Addresses

We scanned the last 2000 blocks. Only 6 addresses produce blocks:

• 0xd843…5b27 — 26.6%, 54.8M INI, 11 outgoing txs (Unknown whale)
• 0xFDd8…c893 — 21.6%, 5.3M INI, 742,540 outgoing txs (YatesPool)
• 0x989f…3A26 — 21.6%, 41.3M INI, 13 outgoing txs (Unknown whale)
• 0x9ABD…4432 — 20.0%, 44.8M INI, 2 outgoing txs (Unknown whale)
• 0x55D4…f8af — 9.1%, 25.7M INI, 20 outgoing txs (Unknown whale)
• 0x1f0c…8edA — 1.1%, 1.8M INI, 370,113 outgoing txs (Genesis miner)

The four whales hold ~167M INI combined (~$20M) and have made a grand total of 46 outgoing transactions between them. They are NOT pools — pools make payouts (YatesPool has 742K outgoing txs). These wallets just accumulate block rewards.

They are all regular wallets (EOAs), not smart contracts. They received zero incoming transactions ever — their only source of funds is mining rewards. No public pool or mining service maps to these addresses.

—

Finding 4: All Whales Send to the Same Batch Payout Contract

Using the INIScan explorer API, we traced every outgoing transaction from every whale and unknown miner. They all send to the same contract: 0xcFe5D32a0BA122016303Cb12e4BC73a2f61897Cc

This contract uses method 0xe59f33b0 — a batch distribution function that takes lists of addresses and amounts. It has 226 incoming transactions, zero outgoing (distributes via internal txs).

Senders to this contract: WHALE-1, WHALE-2, WHALE-3, WHALE-4, UNKNOWN-A, UNKNOWN-B (via intermediary), UNKNOWN-C (via intermediary). Every insider mining address uses the exact same distribution infrastructure. This is a single operation, not independent miners.

What the payout contract actually does (traced from public data): We pulled all internal transactions from the contract via the INIScan API. The contract has 15,091 internal transfers (outgoing) and 226 incoming txs. An operator address 0x841f16b0e2e4769d790b1c4e7816deb9fd3a760f is the one calling the contract 200+ times; whales fund intermediaries that fund this operator. Payouts are equal per batch — e.g. one tx sent 638 INI each to 10 addresses, 50 times in a single batch (31,900 INI per recipient). That’s not proportional like pool payouts; it’s fixed-amount batches to lists of addresses.

Their tokenomics page does say the official team retains “a mining address” and that “all tokens mined through this address will be fully allocated for community building and airdrops.” So the batch distribution we see is consistent with that narrative — they publicly describe airdrops. What they don’t provide is (1) which address or contract is “the team’s,” (2) who receives airdrops or by what criteria, or (3) any claim flow. And they say “a” mining address (singular); on-chain we see four whale addresses plus unknowns, all feeding the same operator and the same payout contract. So either the whole operation counts as “the team’s mining” or the docs are understating the setup. (Charitable read: this could be airdrops as in the whitepaper; we can’t verify who recipients are from public data. The algorithm and centralization findings stand either way.)

Additionally, WHALE-4 and UNKNOWN-A both sent funds to the same intermediary address 0xAfd9...a02c, directly linking them. And YatesPool sent 1.28 INI directly to WHALE-2 — an on-chain link between the “public pool” and an insider whale.

—

Finding 5: They Control Who Can Mine — Backdoors and Blacklist

We reviewed the full ini-chain node source (a fork of go-ethereum/BSC). We audited a clone at commit 7712e4e; snippets below are from that tree so they remain valid if upstream changes or removes code. They define who can participate:

Address Blacklist Contract (0x000000000000000000000000000000000000C001): A single admin can blacklist any wallet from sending or receiving. The contract exposes addBlacklist, getBlacksFrom, getBlacksTo, и isBlackAddress; 286 addresses have been blacklisted, zero ever removed. First blacklists started Nov 23, 2025. Anyone can verify the blacklist on-chain via the explorer or by calling the contract’s view functions.

Hidden Difficulty Divisor (biq library): The chain imports github.com/jj-twa/biq. That library overrides SetBytes() so that instead of setting the integer from the byte slice (as in standard math/big), it divides the value decoded from the slice by z.Int (which can be supplied by a smart-contract call such as checkValid). So the node can make mining N times easier for any specific address — a stealth difficulty reduction invisible to anyone not reading the source. (Researchers have reported up to ~500x for favored addresses.) We preserve the code below; the repo may change or remove it.

P2P Network Whitelist: Whitelisted nodes get priority block propagation and don’t forward transactions. Two-tier network. (See chain repo p2p/ and related config.)

Commented-Out PoW Verification: The verifySeal check is commented out in verifyHeader, so header validation can pass without running PoW seal verification. Code snapshot below.

Code evidence — ini-chain @ commit 7712e4e (and biq library). All snippets preserved so they can’t be removed upstream.

1. Blacklist contract and checkValid — consensus/inihash/systemcontract/abi.go:

AddressListContractName = "address_list" AddressListContractAddr = common.HexToAddress("0x000000000000000000000000000000000000C001") ValidMethod = "checkValid"

2. Chain uses biq for “difficulty” — common/big.go:

import ( "github.com/jj-twa/biq" ... ) var ( ... NewBig = biq.NewInt(1) )

3. Commented-out PoW seal check in header verification — consensus/inihash/consensus.go in verifyHeader:

// Verify the engine specific seal securing the block //if seal {
  // if err := inihash.verifySeal(chain, header, false);
  err != nil {
    // return err //
  }
  //
}

4. Difficulty divisor from blacklist contract — In Finalize, the node calls checkValid(header.Coinbase) on contract 0x...C001 and passes the return value into PoW verification (consensus/inihash/consensus.go):

bigUtil := common.NewBig.Copy() if chain.Config().IsNewTon(...) {
  abi := systemcontract.GetInteractiveABI()[systemcontract.AddressListContractName] data, err := abi.Pack(systemcontract.ValidMethod, header.Coinbase) // ... msg := core.NewMessage(systemcontract.AddressListContractAddr, ...) result, err := vmcaller.ExecuteMsg(msg, state, header, ...) // ... bigUtil.SetUint64(ret[0].(*big.Int).Uint64()) // divisor from contract
}
if err := inihash.verifySeal(chain, header, false, bigUtil);
err != nil {
  ...
}

5. PoW check uses bigUtil.SetBytes(result) — In verifySeal, the mining hash is “checked” via the same bigUtil (a biq type). Standard SetBytes would set the value; biq.SetBytes divides by bigUtil, so a contract-returned divisor makes the check easier (consensus/inihash/consensus.go):

target := new(big.Int).Div(two256, header.Difficulty) if bigUtil.SetBytes(result).Cmp(target) > 0 {
  return errInvalidPoW
}

6. biq library: SetBytes divides instead of setting — jj-twa/biq @ commit d3ef6a5:

func (z *Int) SetBytes(buf []byte) *big.Int {
  if z.Int == nil {
    z.Int = big.NewInt(1)
  }
  if z.Int.Int64() == 0 {
    z.Int = big.NewInt(1)
  }
  z.Int.Div(big.NewInt(0).SetBytes(buf), z.Int) // ← divides hash by z.Int, not Set return z.Int
}

They can also shut down the network. On 2026-02-04, wallets couldn’t load INI balances, miners couldn’t connect to the pool, the official block explorer was down, and exchange INIChain integrations showed errors. As one researcher put it, they can run their network however they want.

So: they can block any wallet, favor specific miners via a hidden difficulty backdoor, gate who effectively participates, and take the network offline. Combined with the YatesPool protocol that blocks GPU miners, they control who can mine.

—

Finding 6: The Difficulty “Dial” — They Control Profitability At Will

We sampled difficulty across the entire chain history. The whales can turn mining profitability up or down like a switch:

September 2025: The Whale Vacation

• Sep 17: Difficulty 17.3T, Yates 25%, Whales 35%
• Sep 19: Difficulty 11.6T, Yates 50%, Whales 0% — WHALES TURN OFF
• Sep 20: Difficulty 9.4T, Yates 75%, Whales 0%
• Sep 25: Difficulty 10.4T, Yates 75%, Whales 0%
• Sep 30: Difficulty 7.6T, Yates 50%, Whales 0% — DIFFICULTY CRASHED 55%
• Oct 1: Difficulty 10.1T, Yates 25%, Whales 50% — WHALES RETURN
• Oct 7: Difficulty 14.6T, Yates 15%, Whales 80%

The whales completely disappeared for 12 days, difficulty crashed 55%, YatesPool miners suddenly looked very profitable. Then Oct 1, they came back and difficulty immediately spiked. This is not natural PoW behavior — legitimate independent miners don’t all simultaneously stop and restart in unison.

During the “vacation,” other insider addresses (UNKNOWN-C) took over ~24% of blocks, so insider control never actually went to zero — they just rotated addresses.

—

Finding 7: The Timeline Tells Everything

• Jan 2025: Chain launches, only YatesPool + genesis miner
• Apr–Jun: Whale addresses appear one by one
• Jul 3: INI listed on MEXC — can now sell tokens
• Jul 2025: INIBOX ASIC goes on sale — hardware revenue begins
• Jul 24: BitcoinTalk post from new account promoting INI cloud mining
• Sep 9: WHALE-2 sends 30M INI to distribution address
• Sep 19–30: Whales turn off — difficulty drops 55%, mining looks profitable
• Oct 1: Whales return full force, squeeze public miners to ~15%
• Oct 23: All whales move huge sums to intermediary addresses
• Nov 23: Mass blacklisting begins (286 addresses)
• Nov 24: Whales call batch payout contract — distribute tens of millions of INI
• Nov 25: InitVerse raises 500 BTC (~$50M) from investors

The MEXC listing is the key. Before July 3, the token had no market. After, they can sell. The September “vacation” where mining looked profitable? Perfect timing to sell ASICs and cloud mining contracts.

—

Finding 8: The Revenue Machine

This is a vertically integrated operation:

• Built the chain — forked BSC/geth, stole NexaPoW, renamed it
• Control ~77% of mining — through insider whale wallets
• Sell ASIC hardware — Pinecone INIBOX, real USD
• Sell cloud mining — inimining.cloud, real USD
• Control who participates — blacklist contract, P2P whitelist, block producer whitelist
• Control profitability — difficulty dial via whale hashrate
• Distribute tokens — batch payout contract to hundreds of wallets (creates appearance of broad distribution)
• Got exchange listings — MEXC, XT.COM (thin liquidity, incentivized trading rewards)
• Raised investor money — 500 BTC (~$50M)
• $746M market cap on $1.3M daily volume — price held up by thin order books

Every layer exists to make the next layer look legitimate. The batch distribution to hundreds of wallets creates the appearance of decentralization — exactly what an exchange due diligence team wants to see.

—

Whitepaper vs Reality

They publish two whitepapers. The one linked on their site is the INIChain ecosystem whitepaper; the other is an older Technical White Paper that describes a different, unimplemented protocol.

A. Technical White Paper (POR — not implemented)

InitVerse Technical White Paper

• Консенсус: Proof of Resources (POR) — validators and cloud service providers jointly create blocks. Providers are challenged (Merkle-tree workload proofs); validators verify. Mining probability = f(pledged tokens, PoR quota). No hash mining.
• Token distribution (Section 3.4): Block reward split 86% provider, 10% validator, 4% technical team. 50% immediate, 50% vested (1% daily). Tx fees to black hole. Halving: 1 year, then every 3 years.
• Ecosystem: UDS, verifiable market, ProviderFactory / AuditorFactory / ValidatorFactory, SDL.

Reality: The live chain does not use POR or the 86/10/4 split. This document describes an unimplemented design.

B. INIChain Whitepaper (site-linked — current narrative)

INIChain Whitepaper (linked on inichain.com)

• Consensus / mining: PoW with VersaHash (“multi-stage hash module”) and Dual Dynamic Adjustment (DDA) — high-privacy blocks vs standard blocks, dynamic difficulty. TfhEVM, TFHE, parallel block generation.
• Tokenomics (Section 6): Matches the tokenomics page: 6B cap, all from block production; team retains “a mining address” and allocates to “community building and airdrops”; weekly halving (~20,160 blocks), initial block reward 729.166665 INI; pool fees as extra community rewards.
• Ecosystem: SaaS, INICloud, Testnet, ObsSwap, Clown Wallet, INIScan, Candy.

Reality: This is the narrative that aligns with the live chain (PoW, team mining → airdrops, weekly halving). The gap: they present VersaHash as their “multi-stage hash” innovation; we’ve shown it is NexaPoW (same algorithm, rebranded). DDA / high-privacy vs standard blocks may or may not be implemented as described; the mining we analyzed is standard hash PoW.

What the live chain actually does

• Консенсус: Classic PoW — NexaPoW (rebranded as “VersaHash”). Hash-based mining; no POR. ASICs (e.g. INIBOX) mine blocks.
• Block reward: 100% to miner (coinbase). No on-chain 86/10/4 or vesting.
• Halving: Per tokenomics / INIChain whitepaper — ~7-day cycle (20,160 / 60,480 blocks after IIP-003).
• Distribution: Team “mining address” → on-chain we see whale miners → intermediaries → operator → batch payout contract → many recipients (equal-per-batch, airdrop-style). Consistent with “community building and airdrops” in the site whitepaper and tokenomics.

Charitable interpretation: “Could this just be them doing what the whitepaper says?”

Airdrops. The whitepaper and tokenomics say the team keeps “a mining address” and allocates to “community building and airdrops.” On-chain we see: mining addresses → one operator → batch contract → many recipients, equal amounts per batch. That is the shape of an airdrop (fixed amounts to lists of addresses). So yes — the mechanism could be “team mining revenue being distributed as airdrops” as stated. The gap is that they never say which address or contract is the team’s, who gets airdrops, or what the criteria are. So we can’t tell “community airdrop” from “insider/partner list”; the implementation could match the narrative but the narrative is too vague to verify.

Staking. The INIChain whitepaper (Section 6) mentions staking for governance (“voting rights”) and “staking of INI tokens for liquidity provider fees,” but it does not describe how to stake, which contract to use, or how staking rewards are paid. If some of the batch recipients were stakers, that would be an undocumented program. Typical staking rewards are proportional to stake; our batches are equal per recipient (e.g. 638 INI each to 10 addresses), which fits airdrop or “fixed reward per participant” more than proportional staking. So: staking is mentioned in the whitepaper but not specified; the payouts we see look more like airdrop batches than like staking reward distributions.

“One” mining address vs several. They could be counting the whole operation as “the team’s mining” (multiple keys or wallets, one logical “address” for the narrative). That would make the multi-whale → one-contract flow consistent with “we use our mining for airdrops.” It would still understate the setup (they say “a” address, we see four+ plus intermediaries).

What doesn’t survive the charitable read.

(1) VersaHash — the whitepaper presents it as their invention; it’s NexaPoW. That’s not “implementing the whitepaper,” it’s misrepresenting the algorithm.

(2) Decentralization — even if the team legitimately runs “their” hashrate for airdrops, 77% in a few wallets, a difficulty dial, blacklists, and a block producer whitelist mean the network is not permissionless or decentralized as claimed.

(3) Transparency — a charitable “they’re doing airdrops” doesn’t explain why recipients and criteria aren’t public, or why the operator/contract aren’t named in the docs.

Bottom line. It’s plausible that the batch payouts are airdrops (or similar) as in the whitepaper. What we can’t do from public data is confirm who those recipients are or whether the program is as open as the wording implies. What we can say is that the algorithm is not theirs, the chain is highly centralized, and the docs overstate both innovation and decentralization — regardless of whether the distribution is “legit” airdrops or something else.

Conclusion. The INIChain whitepaper (and tokenomics) describe a fair, decentralized PoW chain with an innovative hashing algorithm and a single team mining address used for community airdrops. On-chain and in the node source we see:

(1) No innovation in the algorithm — VersaHash is NexaPoW, renamed.

(2) Heavy centralization — a handful of unidentified miners and one distribution operator, with coordinated hashrate (difficulty dial) and shared payout infrastructure.

(3) Documentation understatement — “a” mining address vs multiple whale addresses all feeding the same system; “permissionless” and “decentralized” vs blacklists, block producer whitelist, and a hidden difficulty backdoor. So: the narrative (whitepaper + tokenomics) is consistent with “PoW + team mining → airdrops,” but the implementation contradicts the whitepaper’s claims about innovation (VersaHash), decentralization, and permissionless participation. Our conclusion is that the chain is centralized in practice, the algorithm is not their invention, and the official docs (including the whitepaper) overstate both.

—

Key On-Chain Evidence (Verifiable by Anyone)

• Blacklist contract (AddressList): 0x000000000000000000000000000000000000C001 — view blacklisted addresses and admin on the explorer or via RPC (getBlacksFrom, getBlacksTo, checkValid).
• Admin: 0xad1E145b11b65E779f23683387938DA8B51cAeAC
• Payout contract: 0xcFe5D32a0BA122016303Cb12e4BC73a2f61897Cc — internal txs and incoming txs visible on explorer.
• RPC: https://rpc-mainnet.inichain.com (Chain ID 7233)
• Explorer: iniscan.com
• Node source (chain): Project-InitVerse/chain (go-ethereum fork). We audited a clone at commit 7712e4e; Finding 5 embeds snippets from that tree (systemcontract C001, verifyHeader/verifySeal, common/big.go, inihash consensus).
• Difficulty backdoor (biq): jj-twa/biq — full snippet and permalink @ commit d3ef6a5 in Finding 5.
• Nexa2InitVerse (proof that INI uses NexaPoW, pool blocks GPU miners): Hazelmeow/Nexa2InitVerse
• Video (Rabid Mining): InitVerse / Nexa2InitVerse breakdown
• K1 Pool (block producer whitelist): Twitter/X post

All findings are reproducible from public chain data and open-source code. Where we cite external repos, we use commit permalinks (not main) and embed code snippets so the evidence remains valid if maintainers change or remove the code.

—

Заключение

InitVerse presents itself as a decentralized PoW chain with an innovative algorithm and open mining. On-chain and in the node source we see: a stolen algorithm (NexaPoW rebranded), backdoors (blacklist, hidden difficulty divisor), control over who can mine (block producer whitelist, pool protocol blocks GPUs, blacklist blocks wallets, difficulty backdoor favors insiders), and heavy centralization (four addresses, one payout pipeline, coordinated difficulty dial). As a mining pool, we’re reporting what we found. The rest is for the community and exchanges to decide — and as others have asked: why are coins like this still listed?