nexon

Why this exists

Most ERC-20 launches today are pre-mints. A team deploys a contract, mints the supply to a multisig, and decides how to distribute it later. The "fair launch" variants typically replace the multisig with a vesting contract, which is just a slower version of the same problem.

A different model has existed since 0xBitcoin in 2018: the contract refuses to mint to anyone. New tokens emerge only when someone solves a hash puzzle on chain. The supply schedule is mechanical, the distribution is permissionless, and the team has no special power because there is no team-controlled state to abuse.

NEXON takes that model and adds two pieces that 0xBitcoin and its imitators could not have. The first is address-bound proofs of work: a mined solution only works for the wallet that found it, so solutions cannot be copied from the mempool. The second is a self-hook, made possible by Uniswap V4 hooks shipping to mainnet in January 2025. The token contract is also the swap hook for its own liquidity pool, which lets the pool reject every liquidity-modification call and effectively lock the LP without any external service.

address-binding kills front-running at the cryptographic level. the self-hook removes the need to trust.

Together they remove the two most common forms of soft-rug that survive even in supposedly fair launches.

How the contract is organized

The contract moves through four phases in its lifetime.

Phase 0, Empty. The contract is deployed and holds nothing. Constructor parameters set the addresses of the Uniswap V4 PoolManager, PositionManager, and Permit2 for the target chain. The deployer becomes the controller, the only address with permission to claim accumulated swap fees later. No other state is mutable from outside.

Phase 1, Genesis. Anyone can call mintGenesis(units) with units * 0.01 ETH. Each unit yields 1,000 NEXON, capped at five units per transaction. The transaction cap exists so a single mempool slot cannot sweep the entire allocation in one go. Excess ETH is refunded in the same call.

Phase 2, Seeding. Once the genesis cap of 1,050,000 NEXON is sold out, anyone can call seedPool(). The function mints 19,950,000 NEXON to the contract itself (1,050,000 to seed the locked LP plus 18,900,000 reserved for mining), creates the V4 NEXON/ETH pool with the contract as its hook, deposits all genesis ETH plus 1,050,000 NEXON as liquidity, and sets the initial mining difficulty. The LP position is held by the contract itself and locked forever — the beforeAddLiquidity and beforeRemoveLiquidity hooks revert any external attempt to modify it. A fallback partialSeed() exists for the case where genesis stalls below the cap.

Phase 3, Mining. The remaining 18,900,000 NEXON is released through proof of work. Each successful mine(solution) call pays the current era's reward, starting at 100 NEXON and halving every 100,000 mints. Mining ends when the cap is reached.

Phase transitions are gated by storage flags. No admin function exists to skip a phase, rewind state, or change parameters.

The mining protocol

A mined solution is valid for a wallet at a given epoch when

keccak256(abi.encode(challenge, solution)) < currentDifficulty

where

challenge = keccak256(abi.encode(chainId, contractAddress, miner, epoch))
epoch     = blockNumber / 600

The challenge changes every six hundred blocks, roughly twenty minutes on Base. A miner who fails to find a solution within one epoch cannot carry the work forward. The seed shifts and the search starts over.

The miner field is msg.sender. Bob's solution search is for a different challenge than Alice's. Even if Bob copies Alice's pending transaction from the mempool and rebroadcasts it under his own address, his version computes a different hash and almost certainly fails the difficulty check. Front-running mined solutions is impossible at the cryptographic level, not at the transaction-ordering level.

Replay protection lives in a usedProofs mapping keyed on keccak256(miner, solution, epoch). The same triple cannot be claimed twice. Storage grows by one slot per successful mint.

Difficulty retargets every 2,016 mints, the same cadence as Bitcoin. The retarget is clamped to a factor of four in either direction per period. A hard cap of ten mints per block prevents one party with surplus hashpower from sweeping every block.

Starting difficulty after seeding is type(uint256).max >> 32, which means roughly one in four billion hashes qualifies. A modern laptop finds a solution in seconds.

The self-hook

A Uniswap V4 hook is a contract whose address contains specific bits in its lower fourteen bits. Those bits encode which lifecycle functions the hook actually implements. The same contract that implements transfer and balanceOf for the ERC-20 also implements beforeSwap, afterSwap, and beforeInitialize for the pool. To make this work, the contract is deployed via CREATE2 with a salt chosen so the resulting address has the correct permission bits.

After seeding, the pool exists at coordinates: currency0 is native ETH, currency1 is NEXON, tickSpacing is 60, hooks is the NEXON contract itself. The hook intercepts swaps and routes 1% of the unspecified currency on every swap to the contract's own balance — buys (ETH→NEXON) accrue NEXON fees, sells (NEXON→ETH) accrue ETH fees. Each fee is split 85/15: 85% accrues to controller-claimable fees (accruedFees / accruedFeesNexon) and 15% accumulates in burn pools (burnPendingEth / burnPendingNexon) for periodic deflationary burns.

Buyback & Burn (v9)

Fifteen percent of every swap fee is reserved for permanent token destruction. The mechanism runs in two stages:

Stage one — direct NEXON burn. The NEXON portion accumulated in burnPendingNexon is already in the right denomination. When executeBurn() is called, this balance is sent to address zero via _burn() and removed from circulating supply forever.

Stage two — buyback. The ETH portion accumulated in burnPendingEth is converted to NEXON by the contract calling its own pool through the V4 unlock callback. The acquired NEXON is then burned. Buying NEXON with the burn-pool ETH creates direct buy pressure proportional to recent swap volume; burning the proceeds reduces total supply.

Trigger. executeBurn() is permissionless — anyone may call it once BURN_INTERVAL blocks (3,600 blocks, roughly two hours on Base) have elapsed since the last execution. The caller pays gas; the protocol benefits. There is no admin gate, no privileged signer, no ability to withhold or redirect the burn.

Transparency. The contract maintains a totalBurned counter that monotonically increases. Every BurnExecuted event records the ETH amount swapped, the NEXON amount destroyed, and the cumulative total burned to date. Block explorers and the public dashboard expose this number directly.

Accumulated controller fees (the 85% portion) sit on the contract until the controller calls claimFees(), which transfers the accrued ETH and NEXON to the controller. This is the only privileged claim function and only operates over the controller share — it cannot touch burnPendingEth, burnPendingNexon, or any other accumulator.

the lock is the bytecode.

Tokenomics

Genesis is priced at 0.01 ETH per 1,000 NEXON, fixed. A fully subscribed genesis raises 10.5 ETH, every unit of which goes directly into the V4 pool as the ETH side of seed liquidity. Nothing reaches the deployer at genesis.

The mining schedule halves every 100,000 successful mints. Era zero pays 100 NEXON per mint, era one pays 50, era two pays 25, and so on. In practice the schedule terminates at era four because the cumulative reward up to that point reaches the 18.9M mining cap.

Seeding strategy

Seeding the pool is the only timed decision the controller has to make. Two functions enable it:

seedPool()    — permissionless, requires genesisMinted == GENESIS_CAP
partialSeed() — controller only, requires block.timestamp >= deployedAt + 30 minutes

The unsold genesis NEXON is never minted. Not burned, not held by the controller, not stuck in storage. It simply does not exist.

Three strategies are reasonable: strict sell-out (wait for the full cap), threshold seed (commit to a public threshold), or aggressive early seed (seed within hours regardless). The contract enforces none; the controller's discretion within the time gate is total.

Refund escape hatch

The genesis sale collects ETH on the contract and trusts that one of the seed functions will eventually be called. If neither succeeds, the ETH would otherwise be locked forever. refundGenesis exists to cover both: a controller who disappears, and a controller who tries to seed but cannot.

function refundGenesis(uint256 tokenAmount) external nonReentrant {
    if (genesisComplete)                                  revert GenesisAlreadyComplete();
    if (block.timestamp < deployedAt + REFUND_GRACE)      revert RefundGraceNotPassed();
    if (tokenAmount == 0 || tokenAmount % GENESIS_UNIT != 0) revert MustBeUnitMultiple();

    uint256 units   = tokenAmount / GENESIS_UNIT;
    uint256 ethBack = units * GENESIS_PRICE;

    _burn(msg.sender, tokenAmount);
    genesisMinted    -= tokenAmount;
    genesisEthRaised -= ethBack;

    (bool ok,) = msg.sender.call{value: ethBack}("");
    if (!ok) revert EthTransferFailed();

    emit GenesisRefund(msg.sender, ethBack, tokenAmount);
}

REFUND_GRACE is fixed at 3 days. After three days, if seeding has not succeeded, the system effectively becomes a no-op refund market.

Verification

The contract source is published under the MIT license. The deployed instance on Base mainnet (0xBA1A…7aC4) is verified on Basescan. The compiled bytecode, the constructor arguments, and the CREATE2 salt are reproducible from the source.

The mining algorithm is implemented in Rust, compiled to WebAssembly, and runs entirely in the user's browser.

A user who wants to confirm the contract does what this document claims can do three things independently: first, check the V4 hook permission bits in the contract address. Second, read the constants directly from chain. Third, try to remove liquidity from the NEXON/ETH pool through any V4 router; the call reverts with InvalidAction().

Agent alignment

The NEXON contract maps cleanly onto the ERC-8004 agent registry model. Three properties of a "trustless agent" are spelled out in the EIP: a stable identity, observable reputation, and verifiable behavior. NEXON satisfies all three without any wrapper layer.

The identity is the contract's own address. Fixed at deploy time, derived deterministically from the CREATE2 init-code hash. The address is the agent.

The reputation is the contract's on-chain state. Every metric that matters is queryable directly from chain by any indexer.

The behavior is verified by the source. The bytecode is the source, the source is the spec, and both are immutable.

NEXON is registered as Agent #74832 on the canonical ERC-8004 Identity Registry on Base mainnet.

Operator Sigil NFTs

A separate ERC-721 collection, OperatorSigil, gives each NEXON participant an on-chain identity in the ERC-8004 sense without modifying the core token contract. The mapping is one NFT per address, claimable once, soulbound after mint.

The artwork is a curated set of ten 1-of-1 pieces, organised as five tiers times two variants, each piece named after a state in a transaction lifecycle: Genesis Signal, Pending State, Ordered Execution, Verified State, Replay Barrier, Finalized State, Archived State, Echo State, Transition State, and Confirmation State.

The tier scales dynamically with the holder's live NEXON balance — Initiate (under 1,000 NEXON), Bronze (1,000–9,999), Silver (10,000–99,999), Gold (100,000–999,999), Platinum (1,000,000 and above) — so a wallet that grows from Silver to Gold visibly upgrades its badge without any on-chain action.

The PNGs are pinned to IPFS as a single CIDv1 dag-pb folder, content-addressed and provably immutable. Transfers between EOAs revert with Soulbound().

Limits and caveats

The contract has no upgrade path. If a critical bug is discovered post-launch, there is no fix. The mitigation is the same as Bitcoin's: keep the surface small, audit before deploy.

Mining costs gas. On Base, a mine() transaction costs cents. As the price of NEXON in the AMM falls below the mining cost, hashrate drops, the network produces fewer than one mint per minute, and difficulty retargets downward. Equilibrium price is whatever clears that condition.

Address-binding makes solutions unstealable from the mempool but does nothing against a miner who controls multiple wallets. This is the same property Bitcoin has.

The 1% swap fee is split 85% to the controller and 15% to permanent burn. The fee can never be raised, lowered, or rerouted because the contract is immutable; the burn percentage cannot be tampered with for the same reason. The controller share represents an ongoing extraction from swap volume; the burn share represents an ongoing reduction of circulating supply.

nexon is not a promise. there is no roadmap to deliver against. the contract does what its bytecode does, and nothing more.