Proof-of-Work Overview

XPower's proof-of-work mechanism is a token distribution engine, not a consensus algorithm. Avalanche's subnet consensus secures the chain; XPower's mining ensures every XPOW token in circulation was created through verifiable computational work. For a broader conceptual introduction, see Proof-of-Work Mining.

Mining as Distribution

There is no pre-mine. Every XPOW token originates from a XPower.mint() call that proves the miner discovered a Keccak-256 nonce meeting a specified difficulty threshold. The contract verifies the proof on-chain, then mints an equal amount to both the miner's beneficiary and the MoeTreasury — doubling the supply with each successful solution.

function mint(address to, bytes32 blockHash, bytes calldata data) external {
    require(_recent(blockHash), ExpiredBlockHash(blockHash));
    (bytes32 nonceHash, bytes32 pairIndex) = _hashOf(to, blockHash, data);
    require(_unique(pairIndex), DuplicatePairIndex(pairIndex));
    uint256 zeros = _zerosOf(nonceHash);
    require(zeros > 0, EmptyNonceHash(nonceHash));
    uint256 amount = _amountOf(zeros);
    _hashes[pairIndex] = true;
    _mint(owner(), amount);  // treasury
    _mint(to, amount);       // beneficiary
}

This is a pure proof-of-work issuance model: no bonding curves, no bonding periods, no airdrops. The only way XPOW enters circulation is via entropy expenditure.

Why Keccak-256

Keccak-256 (SHA-3) is deliberately chosen over memory-hard or ASIC-resistant hash functions:

• Browser-mineable — Keccak-256 is natively supported in Web Crypto APIs (SubtleCrypto.digest("SHA-256")) and performs well in JavaScript. At ~10,000 hashes/second in a modern browser, a miner can expect to find a $z=1$ solution in under 2 milliseconds and a $z=4$ solution in under 7 seconds — making the protocol accessible without specialized software or hardware.
• No hardware arms race — Unlike Bitcoin's SHA-256d, Keccak-256 has no industrial ASIC ecosystem dedicated to it. The hash function was chosen in part because existing SHA-256 or Scrypt ASIC miners cannot be repurposed for XPower mining, reducing the advantage of specialized mining rigs.
• Deterministic verification — A single keccak256() call on-chain verifies what took thousands to billions of attempts off-chain. The gas cost of verification (~150,000) is independent of the difficulty $z$, creating a constant verification cost regardless of the computational effort expended.
• EVM-native — Solidity's built-in keccak256() compiles to the SHA3 EVM opcode, requiring no external libraries or precompiles.

Hash Rate Considerations

Environment	Approximate Hash Rate	$z=4$ Solution Time
Browser (single-threaded JS)	~5,000–15,000 H/s	~4–13 seconds
Node.js (single-threaded, V8)	~20,000–50,000 H/s	~1.3–3.3 seconds
Native (Rust/C++, multi-threaded)	~500,000+ H/s	~0.13 seconds

The protocol is intentionally accessible to browser miners — no GPU or ASIC is required. Native implementations provide better efficiency but don't create an insurmountable advantage, since the fixed 1-hour window and single-use pair index constraint limit how many solutions a single miner can submit per interval.

The Six-Contract Mining Flow

Mining involves the coordinated action of all six core contracts, though the miner interacts directly with only one:

┌─────────────┐
│   Miner     │
└──────┬──────┘
       │ 1. init()
       ▼
┌─────────────┐     ┌──────────────┐
│  XPower     │────▶│ MoeTreasury  │────▶ staking reward pool
│  (moe)      │     │ (mty)        │
└──────┬──────┘     └──────────────┘
       │ 2. mint(to, blockHash, data)
       │
       │  50% to beneficiary
       │  50% to owner (mty)
       ▼
┌─────────────┐     ┌──────────────┐     ┌──────────────┐
│  XPowerNft  │     │  NftTreasury │     │  APowerNft   │
│  (nft)      │◀───▶│  (nty)       │────▶│  (ppt)       │
│ deposit     │     │ stake/unstake│     │ staking recpt│
└─────────────┘     └──────┬───────┘     └──────────────┘
                           │ claim APOW
                           ▼
                    ┌──────────────┐
                    │  APower      │
                    │  (sov)       │
                    │ rate-limited │
                    └──────────────┘

1. XPower (moe) — XPower.sol, the hub contract. Validates nonces via _zerosOf(), checks freshness via _recent(), enforces uniqueness via _unique(), and mints XPOW. The contract is Ownable; the owner is set to MoeTreasury, which receives the treasury half of every mint. Only mint() creates new tokens — there is no mint(address, uint256) function accessible to anyone. The supply is unbounded, limited only by the aggregate hash power of all miners.
2. MoeTreasury (mty) — MoeTreasury.sol receives the treasury's XPOW and holds it as backing for APOW minting. It also governs the APR and APB parameters via setAPR()/setAPB(), protected by role-based access control (APR_ROLE, APB_ROLE). The treasury calls APower.mint() to distribute staking rewards, rate-limited by APower's internal mean-tracking mechanism.
3. XPowerNft (nft) — XPowerNft.sol, an ERC-1155 contract. Users deposit mined XPOW via mint(), which calls XPOW.transferFrom(user, vault, amount * denomination). Each NFT ID encodes 100 * year + level, and levels must be multiples of 3. The contract also supports upgrades (1,000 NFTs at level $\ell \to$ 1 at $\ell +3$) and maturity-gated redemptions.
4. NftTreasury (nty) — NftTreasury.sol escrows XPowerNfts and mints/burns APowerNfts. On stake(), it holds the XPowerNft and calls APowerNft.mint(); on unstake(), it returns the XPowerNft and calls APowerNft.burn(). Each stake/unstake triggers MoeTreasury.refreshRates(false) to update the share distribution.
5. APowerNft (ppt) — APowerNft.sol, an ERC-1155 staking receipt. Tracks staked denomination, age accumulator (time-weighted presence), and per-level share totals. Only NftTreasury can mint/burn. The _age accumulator feeds into the APB (Annual Percentage Bonus) calculation, rewarding longer stake durations.
6. APower (sov) — APower.sol, the store-of-value ERC20. Only MoeTreasury (as owner) can call mint(), which first wraps XPOW from the treasury (transferFrom) and then mints APOW subject to rate-limiting. The formula tracks a long-term mean via square-root smoothing: mean' = mean * time' / t + sqrt(claim) / t, targeting ~1 token/minute. Users can burn() APOW to release proportional XPOW from the treasury.

Miners interact only with the XPower contract. The treasury half flows automatically to MoeTreasury, where it funds the APR + APB staking rewards claimed through NftTreasury → APower — completing the cycle of work → value → rewards.

Mining in One Transaction

From the miner's perspective, the flow is straightforward:

1. Call XPower.init() to cache the most recent Avalanche block hash for the current 1-hour interval
2. Iterate nonces off-chain, computing:

$$h=\text{keccak256}(\text{bytes20}(\text{contract}\oplus \text{beneficiary})\parallel \text{blockHash}\parallel \text{data})$$

3. When $h$ has $z\ge 1$ leading zero nibbles, submit via XPower.mint(beneficiary, blockHash, data)
4. Reward $(2^z-1)\times {10}^{18}$ XPOW is minted — half to beneficiary, half to treasury

All gas is paid by the transaction submitter. There is no off-chain oracle, no relayer, and no trusted third party. The contract is the sole arbiter.

Expected Yield

For a uniform random nonce search, the expected XPOW per hash attempt aggregates over all difficulty tiers:

$$\begin{array}{rl}\mathbb{E}[R]& =\sum _{z=1}^{\mathrm{\infty }}P(z)\times R(z)\\ & =\sum _{z=1}^{\mathrm{\infty }}\frac{1}{{16}^z}\times (2^z-1)\times {10}^{18}\\ & ={10}^{18}\times \sum _{z=1}^{\mathrm{\infty }}(\frac{2^z}{{16}^z}-\frac{1}{{16}^z})\\ & ={10}^{18}\times (\sum _{z=1}^{\mathrm{\infty }}{\left(\frac{1}{8}\right)}^z-\sum _{z=1}^{\mathrm{\infty }}{\left(\frac{1}{16}\right)}^z)\\ & ={10}^{18}\times (\frac{1/8}{1-1/8}-\frac{1/16}{1-1/16})\\ & ={10}^{18}\times (\frac{1}{7}-\frac{1}{15})={10}^{18}\times \frac{8}{105}\approx 0.07619\times {10}^{18}\end{array}$$

This converges to approximately 13.13 hash attempts per 1 XPOW on average, though the distribution is heavily skewed: most rewards come from low-difficulty ($z=1,2$) solutions, while high-difficulty solutions are exponentially rarer but individually larger.

Breakdown by Difficulty Tier

Tier	Contribution to $\mathbb{E}[R]$	% of Expected Yield
$z=1$	$1/16\times 1=0.0625$	82.1%
$z=2$	$1/256\times 3\approx 0.01172$	15.4%
$z=3$	$1/4096\times 7\approx 0.00171$	2.2%
$z=4$	$1/65536\times 15\approx 0.00023$	0.3%
$z\ge 5$	remaining	<0.04%

Over 97% of the expected yield comes from $z\le 3$ solutions. High-difficulty mining ($z\ge 6$) is economically irrational for yield alone — it serves more as a lottery mechanic or a demonstration of hash power.

Profitability Threshold

In economic terms, the expected value of a hash attempt is:

$$\mathbb{E}[\text{profit}]=\frac{R_{\text{beneficiary}}\times P_{\text{XPOW}}}{E[\text{hashes}]}-\frac{G_{\text{tx}}\times P_{\text{gas}}}{E[\text{hashes}]}$$

Where $R_{\text{beneficiary}}$ is the beneficiary's half of the reward, $P_{\text{XPOW}}$ is the market price of XPOW, $G_{\text{tx}}$ is the transaction gas cost (~150,000), and $P_{\text{gas}}$ is the Avalanche gas price. Successful mining is profitable when the market value of the beneficiary's half exceeds the amortized gas cost of the nonce search plus the transaction fee.

Architecture Diagram

The following diagram shows the complete mining flow across all six contracts:

The miner initiates the flow by calling XPower.init() (top left), then submits solutions via XPower.mint(). Treasury XPOW flows downward through the staking pipeline, ultimately emerging as rate-limited APOW rewards.

Sub-Pages

• Difficulty and Rewards — Hash function specification, probability, reward formula, and the 50/50 split
• Block Hash Intervals — 1-hour mining windows, freshness checks, pre-computation prevention, and practical mining strategy
• Duplicate Prevention — pairIndex encoding, replay attack resistance, and storage implications