FAQ

Mining

What is XPower mining and how does it work?

XPower mining is a proof-of-work token distribution mechanism where miners compute Keccak-256 hashes to discover nonces with a required number of leading zero nibbles. When a valid nonce is found, the miner submits it via XPower.mint(), and the contract verifies the proof on-chain, then mints XPOW tokens — half to the miner's beneficiary and half to the MoeTreasury. This is a pure issuance model: no bonding curves, no airdrops, no pre-mine.

Can I mine XPower in a web browser?

Yes. Keccak-256 is natively supported in browser Web Crypto APIs and performs well in JavaScript. A typical browser achieves 5,000–15,000 hashes per second, finding a difficulty-1 solution in under 2 milliseconds and a difficulty-4 solution in 4–13 seconds. The protocol was intentionally designed to be browser-mineable without specialized hardware or GPUs.

How many hashes do I need to find a valid nonce?

The expected number of hashes depends on difficulty $z$: 16 hashes for $z=1$, 256 for $z=2$, ~4,096 for $z=3$, ~65,536 for $z=4$, and so on. On average across all difficulty tiers, approximately 13 hashes are needed per 1 XPOW of expected yield, though the distribution is heavily skewed toward low-difficulty solutions (over 97% of expected yield comes from $z\le 3$).

What happens to the XPOW that goes to the treasury?

The 50% of each mint directed to the MoeTreasury funds the staking reward pool. When stakers claim rewards, the treasury wraps XPOW and mints APOW at a rate-limited pace of ~1 token per minute. This creates a feedback loop: mining funds the treasury, treasury backs staking rewards, and staking demand incentivizes more mining.

Is there a limit on how much I can mine?

There is no hard cap on XPOW supply — it grows with total hash power. However, each (beneficiary, blockHash, pairIndex) tuple can only be used once, and block hashes expire after 1 hour. This limits throughput per beneficiary per hour, though a miner can submit multiple solutions against different block hashes within the window.

Staking

How do I stake my XPOW tokens?

Staking is a two-step process. First, call XPowerNft.mint() to deposit XPOW and receive an XPowerNft at your chosen level (multiples of 3 from 0 to 99). Second, call NftTreasury.stake() to escrow the XPowerNft and receive an APowerNft staking receipt. The APowerNft begins accruing rewards immediately based on its denomination, the APR and APB parameters, and the dynamic share scalar.

What are NFT levels and which should I choose?

Levels range from 0 to 99 in steps of 3 and determine both the denomination (${10}^{\ell }$ XPOW per NFT) and the maturity lock period. Lower levels (0–9) are accessible with modest XPOW holdings and have short lockups; higher levels (30+) require large denominations but earn proportionally higher rewards. The dynamic rate mechanism redistributes rewards across levels based on staking demand, so under-supplied levels may offer higher effective rates.

Can I transfer my staked APowerNft?

Yes, APowerNfts are fully transferable via standard ERC1155 safeTransferFrom. However, transfer resets the age accumulator for the recipient (they start with age zero), and the refreshClaimed() function proportionally reduces the sender's claimed counter to prevent the new owner from re-claiming already-paid rewards. This eliminates any incentive to buy old positions purely for accumulated APB bonuses.

How does the upgrade mechanism work?

You can consolidate 1,000 XPowerNfts at level $\ell$ into 1 XPowerNft at level $\ell +3$ by calling XPowerNft.upgrade(). This increases the denomination by 10× (${10}^{\ell +3}=1,000\times {10}^{\ell }$) but also extends the maturity lock period. The tradeoff is liquidity for earning power — higher denominations earn proportionally more rewards.

What happens when my NFT matures?

When the current year reaches the NFT's maturity year (mint year plus $2^{\lfloor \ell /3\rfloor }-1$ years), you can call XPowerNft.redeem() to burn the NFT and receive the underlying XPOW deposit back. Before maturity, redemption is blocked. Levels above ~75 have maturity dates exceeding millions of years, making them effectively permanent.

Rewards

How are staking rewards calculated?

Rewards accrue continuously per staked APowerNft using the formula $R=(\text{APR}+\text{APB})\times \text{age}\times D\times {10}^{18}/({10}^6\times C)$, where APR is the level-based rate, APB is the age-based bonus, age is staking duration in seconds, $D$ is the denomination, and $C$ is the CENTURY constant. Rewards are denominated in XPOW and claimed as APOW through the MoeTreasury.

What is the difference between APR and APB?

APR (Annual Percentage Rate) varies by NFT level — higher levels earn higher base rates, with the default parameters yielding 1.125% per level. APB (Annual Percentage Bonus) varies by stake age — it rewards loyalty, with the default parameters yielding 0.1% per year regardless of level. The two are additive: a level-30 NFT staked for 5 years earns $\text{APR}(30)+\text{APB}(5)$.

How do I claim my rewards?

Call MoeTreasury.claim(account, nftId, amount, nonce) to mint accrued APOW for a single NFT, or claimBatch() to process multiple NFTs in one transaction. The claim passes through Banq enforcement (MIN_NET2RIP ratio check, supply cap, optional pool locking) and is subject to APower's rate limiting (~1 token/minute mean). Claims that exceed the treasury balance are partially satisfied and the remainder stays as pending.

Why do reward rates change over time?

The dynamic rate scalar adjusts effective APR at each level based on the share distribution of staked capital. When a level is under-supplied relative to the average, its effective rate increases; when over-supplied, it decreases. This redistribution preserves the total reward budget while incentivizing stakers to diversify across levels. Additionally, governance can adjust the APR and APB polynomial parameters within Rpp bounds (0.5×–2.0×, minimum 1 month between changes).

What prevents me from staking briefly during a high-rate window?

The integrator mechanism enforces time-weighted smoothing of all rate changes. When rates change, the old rate is appended to a history linked list with its timestamp, and future reward calculations use the duration-weighted arithmetic mean of the entire rate history during the stake period. The formula $\overline{r}=\sum r_i\times (t_{i+1}-t_i)/(t-t_0)$ ensures that flash-stakers cannot capture the full benefit of a brief high-rate window.

Migration

Why do I need to migrate my tokens?

The XPower protocol was rearchitected from v9.x (Hardhat) to v10.x (Foundry) with improved gas efficiency (ReentrancyGuardTransient via EIP-1153), cleaner inheritance, and additional features including Banq anti-gaming, integrator smoothing, and dynamic rates. Migration preserves economic continuity — all existing token and NFT positions remain valid, but must be moved to the new contracts within the migration window.

How do I migrate my legacy XPOW and XPowerNfts?

For XPOW: approve the legacy contract to spend your tokens, then call migrateFrom(amount) on the new XPower contract. Old XPOW is burned, new XPOW is minted 1:1. For XPowerNfts: first call migrateFromOld(ids, amounts) to burn legacy NFTs, then call migrateDeposit(level, amount) to mint new XPowerNfts with the equivalent XPOW value. For APOW: call migrateFrom(amount) on the new APower contract for atomic 1:1 exchange.

What happens when the migration deadline passes?

After approximately 4 years (126,230,400 seconds) from contract deployment, migration is permanently sealed. The seal() function on each Migratable contract is one-way and irreversible — once called or once the deadline auto-passes, all migrateFrom() calls revert. No tokens are lost (they remain in the old contracts), but they cannot be migrated to the current protocol. Check moeMigratable.migrationDeadline() on-chain for the exact cutoff.

Security

How does the protocol prevent supply manipulation attacks?

The Banq system provides defense-in-depth against supply manipulation through atomic balance differencing: every claim operation compares pre- and post-balances, classifies any excess beyond the legitimate claim as "rip supply," and burns it automatically. The MIN_NET2RIP ratio (100:1) ensures attackers cannot use small legitimate claims to mask large illicit mints. Additionally, the supply cap (43,830 APOW) acts as a hard stop — no execution path can exceed it regardless of reward formula errors.

Has the XPower protocol been audited?

Yes. A comprehensive security audit was conducted by Hacken in 2024, covering the full v10.x Foundry contract suite. The audit reviewed the proof-of-work verification logic, staking reward calculations, Banq anti-gaming mechanism, migration system, and role-based access controls. Known compiler warnings (2394, 3860, 5574, 4591) are suppressed by foundry.toml configuration after review. The protocol also inherits from audited, battle-tested OpenZeppelin v5.4.0 and PRB Math v4.1.0 libraries.