NONCE

A proof-of-work token that funds its own liquidity

Version 1.0 · Robinhood Chain (4663) · nonce-spec.md is the normative specification

Abstract

NONCE is an ERC-20 token whose only issuance path is proof of work. There is no pre-mine, no allowlist, no investor allocation and no team wallet: every token in circulation was produced by someone spending compute to find a hash.

Three design choices distinguish it from earlier on-chain proof-of-work tokens. Emission follows a smooth polynomial curve rather than discrete halvings, so there is no night on which the reward drops by half and half the miners leave. Each epoch's reward is split proportionally among everyone who submitted, rather than paid entirely to one winner, so a laptop is never shut out. And the protocol's liquidity is built by mining itself — a fraction of every reward and every submit fee accumulates into a permanently locked Uniswap v4 position, so the token's market depth is a function of how much work has been done on it rather than of how much capital a founder was willing to post.

This document describes the mechanism, the economics, and the parts of both that are unfavourable.

1. Motivation

Fair-launch tokens have a liquidity problem. A launch with no pre-sale raises no capital, so either the founder funds the pool from their own pocket — reintroducing the insider they were trying to avoid — or the pool starts empty and the first buyer eats catastrophic slippage.

The usual answer is a bonding curve or a launchpad, both of which reintroduce a privileged party. NONCE takes a different route: the act of mining is also the act of funding the pool. Every submitted solution pays a small fee in ETH, and every epoch routes part of its emission to the same place. Liquidity is therefore earned, and it accrues in proportion to genuine participation rather than to anyone's balance sheet.

Prior art informs three specific decisions:

• Bitcoin established the 21M cap and the credibility of pure issuance-by-work, but its discrete halvings produce cliff events, and its difficulty targets a global hashrate that a single-chain token cannot assume.
• 0xBitcoin brought proof of work to the EVM but rotates the challenge on every successful mint. Every other miner's in-flight work is destroyed the instant someone lands a solution, which makes browser and small-scale mining pointless.
• ORE demonstrated proportional distribution: everyone who submits earns something. This is the single most important property for participation breadth.
• Pearl demonstrated smooth polynomial emission in place of halving cliffs.

NONCE combines ORE's distribution with Pearl's emission curve, fixes the challenge-rotation problem, and adds protocol-owned liquidity funded by the mining itself.

2. Supply and emission

Total supply is capped at 21,000,000. Of that, 210,000 (1%) is minted once at deploy directly into the liquidity contract — never to a wallet — leaving 20,790,000 to be mined. The seed is carved out of the cap, not added to it, so total supply can never exceed 21M.

Cumulative emission follows

A(t) = MINEABLE_SUPPLY × t / (t + H)        MINEABLE_SUPPLY = 20,790,000,  H = 100,000
R(t) = A(t + 1) − A(t)

where t is the epoch number and one epoch is 60 seconds.

The per-epoch reward is defined as the discrete difference of the cumulative curve rather than its continuous derivative. This is not cosmetic: it makes the sum of all epoch rewards equal A(t) exactly, with no drift accumulating from repeated integer division. The property is asserted by fuzz test over arbitrary epoch ranges.

Half the mineable supply is emitted by roughly day 69 (t = H), three quarters by day 208. The curve approaches the cap asymptotically, so the tail never fully exhausts and there is always a reward — however small — for continued work.

2.1 Rollover

If nobody mines an epoch, its emission is not burned. It rolls into the next epoch that does receive a submission. Because A(t) is closed-form, the contract computes an arbitrary gap in constant time:

pot(e) = A(e + 1) − A(lastOpenedEpoch)

A gap of ten epochs and a gap of ten thousand cost identical gas. There is no loop and no unbounded state.

3. Mining

3.1 The work

A valid solution is a nonce whose digest falls at or below the current target:

digest = keccak256(challenge ‖ msg.sender ‖ nonce)     // 84-byte preimage
require(uint256(digest) <= target)

Keccak256 is the EVM's native hash, so verification costs roughly 30 gas plus calldata.

The miner's address sits inside the preimage. A solution is therefore bound to the wallet that found it: it cannot be extracted from the mempool and submitted by someone else, resold, or replayed. This also makes a per-wallet cap pointless — splitting work across wallets does not reduce the work — so none exists.

3.2 Challenge rotation

The challenge rotates once per epoch, not once per solution. This is the correction to 0xBitcoin's central flaw. Under per-mint rotation, a miner with 1% of the hashrate has their search invalidated roughly every time anyone else succeeds, which makes small-scale mining a lottery on latency rather than on work. Per-epoch rotation gives every wallet an independent search space for the full minute.

A future epoch's challenge is derivable in advance, so mining can begin the instant an epoch starts rather than waiting for a first mover. Once an epoch opens, its challenge is pinned and cannot shift under the miners already working on it.

3.3 Submission

A wallet may submit at most 10 times per epoch, and only its best hash counts. Additional submissions are rerolls: a better hash replaces the previous one, a worse hash changes nothing but still costs the fee. The rational strategy is to mine most of the minute, submit once near the close, and reroll only on a materially better result — the reference miner defaults to a 2× improvement threshold, roughly where a second fee pays for itself.

3.4 Distribution

Every valid submitter earns, in proportion to the quality of their best hash:

score  = type(uint256).max / uint256(bestDigest)
share  = score / totalScoreThisEpoch
reward = epochPot × share

A GPU explores more of the space and usually finds a better hash than a CPU, and earns accordingly. But a CPU is never shut out and never spends an entire session earning nothing, which is what a winner-takes-all design does to small participants.

3.5 Difficulty

The target is a spam filter, not a reward mechanism: it sets the minimum hash quality worth putting on chain and has no influence on how the pot is divided.

At the genesis target roughly one hash in 65,536 qualifies, so a 2 MH/s laptop finds well over a thousand valid hashes per minute. Nobody is priced out at launch.

The retarget arithmetic divides before multiplying and clamps the denominator before use, so neither the ratio nor the product can overflow regardless of submission volume — a shape that has produced live failures in comparable systems when the target sits near its ceiling during slow opening epochs.

4. Economics

4.1 Fees

Each submission costs a small ETH fee on top of gas: 0.00002 ETH at launch, split evenly between the treasury and the liquidity accumulator.

The fee halves automatically every 100,000 epochs and is a one-way ratchet — the owner may lower it at any time, including to zero, but the contract will not permit an increase under any circumstances.

4.2 Tax

Before each epoch is distributed, 5% is taken: 1% to the treasury, 4% to liquidity. Miners keep 95%. The split is adjustable but the total is capped at 5% in the contract; it can be moved to 0%/5% or 5%/0% but never to 6%.

Over the full curve this is approximately 207,900 NONCE to the treasury and 831,600 NONCE to liquidity. There is no transfer tax — buying, selling and moving NONCE cost nothing beyond gas.

The contract predates this terminology and still names the destination devWallet, its share devBps, and its withdrawal withdrawDevEth(). Those identifiers are what appear in the ABI and the verified source; "treasury" and dev* are the same single address.

4.3 Protocol-owned liquidity

The token side of the pool is the 210,000 seed plus 4% of every epoch. The ETH side is half of every submit fee. Roughly hourly, the contract pairs what has accumulated into a NONCE/ETH position on Uniswap v4.

Nothing in that table flows the other way. There is no entry for a withdrawal, because no function decreases or burns the position — the only value that ever leaves is trading fees, and those go to an account that can actually move them.

Three properties matter, and each addresses a specific way this goes wrong in practice:

The position is genuinely full range. Ticks are −887200 and 887200, aligned to a tick spacing of 200; no wider aligned pair exists. Native ETH is currency0, so the pool price reads as NONCE-per-ETH. If NONCE falls, the price moves past the upper tick and the position converts to 100% NONCE — the ETH is bought out by the market rather than stranded inside a position nobody can withdraw.

The starting price is derived from the amounts on hand, as sqrt(nonce/eth) × 2^96, rather than chosen in advance. At full range the required ratio is fixed by the price, so initialising at an arbitrary price leaves the surplus side unconsumed — this is the most common cause of funds stranded in a deployment helper. Any remaining dust stays in the adapter and is folded into the next deposit, because deposits read live balances rather than the amount they were handed.

Fees are payable to a wallet, in both currencies. The position NFT is held by the contract and no function decreases or burns its liquidity, so the principal is locked permanently. Trading fees are separate: collectFees() is permissionless to call, its destination is immutable, and it pays out both ETH and NONCE directly to the treasury, an externally owned account. Nothing is forwarded into a contract that cannot move it.

4.4 Staking

Locking NONCE multiplies a miner's score linearly, up to 2×:

effectiveScore = score × (1 + min(staked / stakeTarget, 1))
stakeTarget    = max(epochReward(now) × 5, 100 NONCE)

The target is dynamic, tracking the emission curve — about 1,040 NONCE on day one, shrinking as rewards do. A fixed target would quietly penalise late arrivals, charging them months of mining for the same boost an early miner obtained in minutes.

Stakes lock for 7 days, and topping up restarts the lock on the whole balance. This is what makes the multiplier honest: without it a miner could stake, submit, and withdraw inside a single 60-second epoch, taking a 2× boost on capital they never committed.

5. Governance surface

Enforced by the contract, not by promise:

6. Distribution channels

Four interfaces share one hash implementation: a browser miner using Web Workers, a GPU-accelerated CLI, an MCP server exposing mining as agent tools, and a packaged agent skill that installs and operates the miner end to end.

They share the implementation deliberately. A second implementation of the preimage is a second opportunity to disagree with the EVM by one byte — a failure that presents as persistent bad luck rather than as an error. The JavaScript miner is therefore verified against digest vectors generated by the contract itself, covering nonce 0, 1, 2^64, 2^128−1, 2^255 and 2^256−1.

7. Limitations

Stated plainly, because each of these affects whether the system is worth participating in.

Per-epoch variance is large. The score of a best-of-N hash search is heavy-tailed. Expected score scales with hashrate, but any individual epoch is far noisier than that average: a CPU will occasionally out-earn a GPU and a GPU will occasionally have a bad minute. Published distribution figures describe long-run averages, not what a given minute pays.

No profitability guarantee. Nothing in the protocol ensures mining covers electricity or rent. The system is self-correcting rather than protective: if price falls, miners leave, the remaining miners' shares rise, and mining becomes viable again at a smaller scale. That correction operates on the participant count, not on anyone's individual outcome.

The launch price is not chosen. Because the pool is initialised from accumulated amounts, the opening price is a function of early mining activity. With few miners the pool is thin and the implied valuation very low. This is intentional — it is the cost of refusing to seed liquidity from anyone's balance sheet — but it means early price discovery is noisy.

Difficulty targets submissions, not hashrate. With a target of 50 submissions per epoch and a 10-submission cap per wallet, the difficulty controller responds to participation breadth rather than to total work. As the miner count grows, the target tightens and the weakest hardware is progressively priced out of submitting, even though reward shares remain proportional.

The treasury tax is real. 5% of emission is not zero, and the owner controls its split and the LP fee destination. The constraints above bound what that control can do, but they do not eliminate it.

Current status is testnet. The contracts are deployed and exercised on Robinhood Chain testnet (46630), with the auto-LP write path verified against the live Uniswap v4 deployment via fork testing. They have not been audited by a third party.

8. Parameters

References

• Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System, 2008.
• 0xBitcoin — EIP-918 mineable token standard.
• ORE — proportional proof-of-work distribution.
• Uniswap v4 — developers.uniswap.org/docs/protocols/v4
• Full technical specification: nonce-spec.md