Difficulty and Rewards

The XPower mining contract uses a probabilistic difficulty system with exponential rewards. Difficulty is measured in leading zero nibbles and the reward scales as a power of two.

Hash Function Specification

The miner constructs a 256-bit Keccak-256 hash over three concatenated components:

$$h=\text{keccak256}(\text{bytes20}(\text{uint160}(\mathtt{\text{address(this)}})\oplus \text{uint160}(\mathtt{\text{beneficiary}}))\parallel \text{blockHash}\parallel \text{data})$$

Where the three input components are:

Component	Width	Source
contractAddr XOR beneficiaryAddr	160 bits (padded to 256)	address(this) ^ beneficiary
blockHash	256 bits	Avalanche block hash from init()
data	256 bits	Miner-supplied: 32 bytes containing the nonce

The XOR of the contract address with the beneficiary address serves two purposes:

1. Ties the hash to the specific contract — a nonce valid for one deployment is not valid for another
2. Ties the hash to the intended recipient — prevents a miner from submitting the same nonce to benefit a different address

The data field is 32 bytes (256 bits), giving a search space of $2^{256}$ possible nonces per (beneficiary, blockHash) pair.

Why bytes20 Casting

The contract explicitly casts uint160(address(this)) ^ uint160(to) to bytes20 before concatenation. This ensures the XOR result occupies exactly 20 bytes in the hash preimage, with bytes.concat handling the conversion to a fixed-width bytes32.

Difficulty: Leading Zero Nibbles

Difficulty $z$ is defined as the number of leading zero nibbles (4-bit hex digits) in the 256-bit hash output. A nibble is zero when all 4 bits are zero.

The contract computes $z$ via:

$$z=63-\lfloor \frac{{\log }_2(h)}{4}\rfloor$$

In Solidity (XPower.sol:_zerosOf):

if (nonceHash > 0) {
    return uint8(63 - (Math.log2(uint256(nonceHash)) >> 2));
}
return 64;

Math.log2 returns the floor of the binary logarithm (position of the highest set bit). Dividing by 4 (>> 2) converts bits to nibbles. Subtracting from 63 gives the count of leading zero nibbles. A hash of zero would have $z=64$ (all nibbles zero), though this is astronomically improbable ($1/{16}^{64}$).

The contract requires $z\ge 1$; a nonceHash with no leading zero nibbles reverts with EmptyNonceHash.

Probability

For a uniformly random 256-bit hash, the probability that the first $z$ nibbles are zero is:

$$P(z)=\frac{1}{{16}^z}$$

Each nibble independently has a $1/16$ chance of being zero. The expected number of hash attempts to find a solution of difficulty $z$ is:

$$\mathbb{E}[\text{hashes}]=\frac{1}{P(z)}={16}^z$$

Reward Formula

The XPOW reward for difficulty $z$ is:

$$R(z)=(2^z-1)\times {10}^{18}$$

In Solidity (XPower.sol:_amountOf):

function _amountOf(uint256 level) internal view returns (uint256) {
    return (2 ** level - 1) * 10 ** decimals();
}

Where decimals() returns 18, so the base unit is ${10}^{18}$ (1 XPOW). The formula yields:

$z$	$2^z-1$	Reward (XPOW)
1	1	1
2	3	3
3	7	7
4	15	15
5	31	31
6	63	63
7	127	127
8	255	255

The reward doubles plus one for each additional zero nibble. This creates a slight super-exponential relationship: doubling the difficulty ($\times 16$ expected hashes) yields slightly more than double the reward.

Complete Difficulty-Reward Table

$z$	$P(z)$	Expected Hashes	Reward (XPOW)	$\mathbb{E}$[XPOW/hash]
1	$1/16$	16	1	0.0625
2	$1/256$	256	3	0.01171875
3	$1/\mathrm{4,096}$	~4K	7	0.00170898
4	$1/\mathrm{65,536}$	~66K	15	0.00022888
5	$1/\mathrm{1,048,576}$	~1M	31	0.00002956
6	$1/\mathrm{16,777,216}$	~17M	63	0.00000376
7	$1/\mathrm{268,435,456}$	~268M	127	0.00000047
8	$1/\mathrm{4,294,967,296}$	~4.3B	255	0.00000006

The last column shows each difficulty tier's contribution to the overall expected yield. The sum across all $z$ converges to the expected yield of $\approx 0.076$ XPOW per hash derived in the Overview.

The 50/50 Split

Every successful mint() call creates two identical mints:

_mint(owner(), amount);   // treasury
_mint(to, amount);        // beneficiary

The owner() of the XPower contract is the MoeTreasury (set during deployment). This means each mining solution doubles the total XPOW supply, with exactly half flowing to the treasury that funds staking rewards.

Why Split?

The split serves multiple purposes:

• Protocol sustainability — The treasury accumulates XPOW to back APOW minting, funding the staking reward system indefinitely
• Incentive alignment — Stakers benefit from mining activity even if they don't mine themselves, creating a natural demand floor for XPOW
• No inflation-only token — Unlike pure mining tokens where miners are the only beneficiaries, the split ensures value flows to the entire ecosystem

Treasury to Staking Pipeline

The treasury half of each mining reward follows this path:

1. Accumulation — XPOW is minted directly to MoeTreasury's balance
2. Backing — Treasury XPOW backs APOW minting; APower.mint() calls XPOW.transferFrom(treasury, APower, amount) to lock XPOW
3. Distribution — When stakers call MoeTreasury.claim(), the treasury calculates (APR + APB) * age * denomination and calls APower.mint(beneficiary, reward)
4. Rate limiting — APOW minting is rate-limited to ~1 token/minute (long-term mean), preventing treasury drain from batched claims

The treasury receives XPOW continuously (from mining) and releases APOW slowly (rate-limited), creating a natural buffer. See Rewards Overview for the full staking reward calculation.

Compound Difficulty

A miner searching for any valid solution experiences the union of all difficulty tiers. For a single hash attempt:

$$P(\text{any solution})=\sum _{z=1}^{\mathrm{\infty }}\frac{1}{{16}^z}=\frac{1}{16}\times \frac{1}{1-1/16}=\frac{1}{15}$$

A randomly chosen hash has approximately a $1/15\approx 6.67\mathrm{\%}$ chance of having at least one leading zero nibble. But since this is overwhelmingly a $z=1$ solution (worth 1 XPOW), miners may prefer to target higher difficulties for larger payouts — see Block Hash Intervals for strategy considerations.

Practical Implications

• Low difficulty ($z=1$) — 16 expected hashes, 1 XPOW reward (0.5 to beneficiary). Easily mined in-browser but requires frequent on-chain submissions, incurring gas costs
• Medium difficulty ($z=4$) — ~66K expected hashes, 15 XPOW reward (7.5 to beneficiary). Balances hash effort against gas cost for most miners
• High difficulty ($z=8$) — ~4.3B expected hashes, 255 XPOW reward (127.5 to beneficiary). Substantial computational investment; only viable with optimized mining software

The optimal target difficulty for a given miner depends on their hash rate, gas costs on Avalanche C-Chain, and the market value of XPOW.