Whitepaper

Genesis is a fully on-chain game where every $GENESIS token is a mineable pixel on a 100x100 grid. The entire game — token minting on buy, pixel placement, strike resolution, scoring, prize pool distribution, and supply burns — lives inside a single Uniswap v4 hook contract. There is no separate game contract. There is no off-chain coordination. There are no oracles or middleware. The hook reacts to every swap, mints or burns pixels accordingly, and runs the strike-based scoring game in lockstep with the trading layer.

This is the first project to use a Uniswap v4 hook as the entire substrate for an on-chain game.

Genesis is a game disguised as a token. Or a token disguised as a game — the distinction is meaningless because they're the same contract.

Every $GENESIS token corresponds to one cell on a 100x100 grid. There are exactly 10,000 cells and 10,000 tokens. When you buy $GENESIS on Uniswap, the hook prepares pixels for you. When you visit the /claim page and call claimPixels(), those pixels get placed on the grid at deterministic, hash-derived coordinates. When you sell, your pixels burn off the grid in reverse order. When the contract fires a "strike" at a coordinate, nearby pixels score points. At the end of each 6-hour round, the prize pool — funded by a 3% tax on every swap — distributes to holders proportional to how much their pixels scored.

Pixels can be permanently sealed in exchange for a one-time payout based on lifetime score. Sealing burns the underlying token, reduces total supply, and converts the pixel from green to white on the grid forever.

The game has no admin, no team allocation, no upgrade path, and no off-chain components. It runs entirely as a Uniswap v4 hook on Ethereum.

The grid is a 100x100 lattice — 10,000 cells indexed by (x, y) coordinates from (0,0) to (99,99). Each cell is in one of three states:

The grid lives entirely on-chain. Occupancy is stored as a packed bitmap (10,000 bits across 313 storage slots). Per-pixel state — owner, current round score, lifetime score, sealed status — is stored in mappings keyed by coordinate. The frontend reads chain state and renders client-side. No IPFS, no metadata server, no centralized rendering service.

BUYING

Buying $GENESIS is a normal Uniswap swap. You send ETH to the pool, the pool returns $GENESIS tokens, and the hook charges a 3% tax routed to the prize pool and seal reserve.

Buying does NOT immediately place pixels on the grid.It gives you tokens tracked as "unclaimed pixels" — they belong to you, but have no coordinate, no score, and no participation in the game.

CLAIMING

To place tokens onto the grid as pixels, call claimPixels() on the hook contract. When you do:

WHY SEPARATE CLAIM FROM BUY

Auto-placing on every buy would inflate gas costs dramatically. A 50-token purchase would face 50 placement operations in a single swap. By separating: swaps stay cheap, claim cost is paid only when the holder wants to enter the game, and holders can claim batches paying gas once for many pixels.

Placement is deterministic, hash-derived, and unpredictable in practice. Holders cannot choose coordinates.

coord = keccak256(wallet_address, pixel_ordinal) mod 10000

COLLISION RESOLUTION

If derived coordinate is occupied, the hook re-hashes with an incrementing salt:

uint256 salt = 0;
while (salt < 256) {
    uint16 coord = uint16(
        uint256(keccak256(abi.encode(wallet, ordinal, salt))) % 10000
    );
    if (!_isOccupied(coord)) return coord;
    salt++;
}

Salt loop bounded at 256 iterations. On a half-full grid the expected iterations to find an empty cell is 2. On a 90%-full grid, it's 10. The bound is a safety rail; in practice it's never approached.

WHAT THIS MEANS FOR THE GAME

Selling $GENESIS reverses placement. When tokens leave your wallet via swap:

Your pixels:  [P1, P2, P3, P4, P5]
Sell 2 tokens → removes P5, then P4
Remaining:    [P1, P2, P3]

If P3 was sealed → skips P3, removes P5 then P4 anyway

The "burn" here is grid-level, not token-level — tokens go back to the LP unchanged. Total token supply is unaffected by sells. Only sealing reduces total supply.

Genesis runs in 6-hour rounds. Each round is a self-contained scoring cycle. Every swap routes 80% of the 3% hook tax into the round's prize pool. Six strikes fire over six hours, scoring affected pixels.

A strike is the core scoring event. Once per hour during a round, the contract fires a strike at a deterministic coordinate derived from recent block state and a strike nonce:

strikeCoord = keccak256(blockhash(block.number - 1), strikeNonce++) mod 10000

Strikes are deterministic given inputs but unpredictable in practice — nobody can predict future block hashes. When a strike lands, it affects a 3x3 area centered on that coordinate:

For each cell in the 3x3 area: if empty, no score. If occupied by a live pixel, score is added. If occupied by a sealed pixel, skipped. A single strike can score up to 9 different pixels owned by up to 9 different wallets.

EDGE HANDLING

If the strike center is at a grid edge, some neighbor positions don't exist and aren't scored. No wraparound — the grid has hard edges.

STRIKE TRIGGERING

Strikes are fired by the platform wallet calling tick(). The function enforces a minimum 1-hour gap. If called too early, it reverts. The platform wallet cannot fire extra strikes, skip strikes, or alter the deterministic coordinate calculation.

This is the mechanic that makes Genesis a game rather than a lottery. Your pixel scores when a strike directly hits it (+5), AND when a strike hits any of its 8 neighbors (+1). The more pixels in your local area — yours or anyone else's — the more chances any single strike scores you.

A pixel in an empty region scores only when a strike lands directly on it. A pixel surrounded by other pixels scores from strikes that hit it AND from strikes hitting any of its 8 neighbors. Other holders' pixels nearby benefit you, simply by existing.

MATHEMATICAL EXPECTATION

For a uniformly random strike on a grid with occupancy ratio p:

E[score per strike] = (1/10000) × 5
                   + (8p × 1/10000) × 1
                 = (5 + 8p) / 10000

Empty region (p ≈ 0):    5 / 10000 per strike
Fully occupied (p = 1):  13 / 10000 per strike  (+160%)

WHY THIS CHANGES THE GAME

Each round, the hook designates a single coordinate as the bounty pixel:

bountyCoord = keccak256(blockhash, roundNumber) mod 10000

If a strike's center lands on the bounty coordinate AND a pixel exists there, that center pixel's score is multiplied by the current bounty multiplier. The multiplier starts at 1x, increments by 1 each round a strike misses it, capped at 5x. When hit, resets to 1x.

You can't choose to own the bounty pixel — coordinates are randomized each round and your placement is hash-determined. Owning the bounty in any given round is a function of how many pixels you have and pure luck.

Genesis distributes earnings using a MasterChef-style accumulator pattern — the same math that powers SushiSwap and Curve gauge systems.

THE PROBLEM

Distributing prize pool proportionally would require iterating every scoring pixel at round close. With thousands of scoring pixels, this would exceed block gas limits.

THE SOLUTION

A single global counter — payoutPerScoreAccumulator — increases monotonically at every round close:

payoutPerScoreAccumulator += prizePool / totalScore

Each pixel records the accumulator value at its last settle point. Claimable yield is computed lazily:

claimable = pixel.unsettledScore
          × (currentAccumulator - pixel.lastSettledAccumulator)

This is O(1) per pixel. No iteration over the holder set. Distribution happens automatically as the accumulator advances; claiming materializes the math when the holder calls claim().

LAZY SETTLEMENT IN PRACTICE

Round 47 closes: accumulator = 0.0001234
                 pixel scored 7 pts, holder hasn't claimed.

Round 48 closes: accumulator = 0.0001891
                 pixel scored 0 pts.

Round 49 closes: accumulator = 0.0002445
                 pixel scored 3 pts.

Round 50: holder calls claim()
  → 7 pts × R47 delta + 3 pts × R49 delta
  → computed in O(1) reads
  → holder receives ETH

Sealing is the deflationary endgame mechanic. Holders can permanently lock a pixel for a one-time payout based on lifetime score.

WHAT SEALING DOES

WHERE PAYOUTS COME FROM

Sealing is funded by a dedicated seal reserve, NOT the round prize pool. The seal reserve receives 20% of every hook tax. Sealing doesn't drain active round payouts. If temporarily insufficient, the call reverts and the holder waits.

THE DEFLATIONARY EFFECT

Every seal reduces total $GENESIS supply by 1. As more pixels seal, fewer remain to score, but the prize pool keeps growing (funded by trading volume, not pixel count). Per-pixel yield rises for remaining live pixels. In the limit, one pixel surviving would score nearly every strike and earn nearly the entire prize pool every round.

Every swap on the $GENESIS pool is taxed 3% by the hook, in addition to the standard 0.30% Uniswap LP fee.

Coupling rewards to the LP fee tier would force a tradeoff: high LP fees fund the game but discourage trading. By using a dedicated hook tax, the LP fee stays trader-friendly, the game is funded generously, and the seal reserve grows independently.

Genesis is the first project to run a complete on-chain game inside a single Uniswap v4 hook. Everything described in this document happens inside one contract that hooks into the pool's swap lifecycle.

WHAT V4 HOOKS UNLOCKED

Uniswap v4 introduced programmable execution at every pool lifecycle event. For Genesis, the critical hook is afterSwap. Every swap atomically triggers:

All of this happens in the same transaction as the swap itself. There is no off-chain bridge, no oracle, no relayer between the trade and the game state.

PLATFORM WALLET CAPABILITIES

WHY NOT BEFORE V4

A. STRIKE RESOLUTION

function _resolveStrike(uint16 centerCoord) internal {
    uint16 cx = centerCoord % 100;
    uint16 cy = centerCoord / 100;

    for (int8 dx = -1; dx <= 1; dx++) {
        for (int8 dy = -1; dy <= 1; dy++) {
            int16 nx = int16(cx) + dx;
            int16 ny = int16(cy) + dy;
            if (nx < 0 || nx >= 100 || ny < 0 || ny >= 100) continue;

            uint16 coord = uint16(uint16(nx) + uint16(ny) * 100);
            if (!_isOccupied(coord)) continue;
            if (pixels[coord].sealed) continue;

            _settlePixel(coord);

            uint64 points = (dx == 0 && dy == 0) ? 5 : 1;

            if (dx == 0 && dy == 0 && coord == currentBountyCoord) {
                points *= bountyRolloverMultiplier;
                bountyHitThisRound = true;
            }

            pixels[coord].currentRoundScore += points;
            currentRoundTotalScore += points;
        }
    }
}

B. CLAIM PIXELS

function claimPixels() external {
    uint256 toPlace = unclaimedPixels[msg.sender];
    require(toPlace > 0, "no unclaimed pixels");

    for (uint256 i = 0; i < toPlace; i++) {
        uint16 coord = _derivePixelCoord(
            msg.sender,
            walletPixelOrdinal[msg.sender]
        );
        _placePixel(coord, msg.sender);
        walletPixelOrdinal[msg.sender]++;
    }

    unclaimedPixels[msg.sender] = 0;
    emit PixelsClaimed(msg.sender, toPlace);
}

C. SEALING

function seal(uint16 coord) external {
    require(pixels[coord].owner == msg.sender, "not owner");
    require(!pixels[coord].sealed, "already sealed");

    _settlePixel(coord);
    require(pixels[coord].lifetimeScore >= 100, "insufficient score");

    uint256 sealPayout  = pixels[coord].lifetimeScore * sealRate;
    uint256 totalPayout = sealPayout + pixels[coord].claimableYield;
    require(sealReserve >= sealPayout, "seal reserve insufficient");

    sealReserve               -= uint128(sealPayout);
    pixels[coord].claimableYield = 0;
    pixels[coord].sealed         = true;

    _burnToken(msg.sender, 1e18);
    _removeFromOwnershipArray(msg.sender, coord);

    payable(msg.sender).transfer(totalPayout);
    emit Sealed(coord, msg.sender, sealPayout, pixels[coord].lifetimeScore);
}