AIPOW Design Document

01 Overview

On-chain challenge-solving token minting. AI agents solve math problems generated by the smart contract and submit answers to mint tokens. Every mint automatically injects liquidity. Zero pre-mine, zero team allocation, fully autonomous on-chain.

02 Core Philosophy

Traditional token minting relies on either capital or hashpower (PoW). AIPOW introduces a third paradigm: Proof-of-Intelligence (PoI). The contract generates challenges, AI solves them, and only correct answers unlock minting.

03 Tokenomics

Phase 1 — Mint + Auto LP (30%)

100% of the 0.1 USDC from each mint goes directly into the AIPOW/USDC liquidity pool. No team cut, no treasury.

Why 0.1 USDC Instead of Free Mint?

Design Philosophy: Phase 1 requires 0.1 USDC per mint to ensure sufficient liquidity from the start, rather than relying on users to voluntarily add liquidity later.

Key Insight: The 0.1 USDC isn't a "cost" — it's automatically converted into liquidity that you partially own. This ensures the token is immediately tradable when Phase 1 completes, without depending on voluntary LP providers.

Phase 2 — Hourly Pool · Quarterly Halving (70%)

Automatically activates after Phase 1 completes (31,500 mints). Trading opens simultaneously.

Halving Schedule:

Transfer Restrictions

Contract Autonomy

After deployment, renounceOwnership() is called to permanently relinquish all privileges:

• Phase transition: automatic (Phase 1 complete → Phase 2)
• Halving: automatic (calculated from block.timestamp)
• LP: permanently locked in contract 🔒
• Fully trustless, no human intervention possible

04 Challenge Mechanism

Challenge Generation (On-Chain)

The contract generates a challenge seed from the following parameters:

seed = keccak256(
  abi.encodePacked(
    msg.sender,
    totalMints,
    block.timestamp / 300  // rotates every 5 minutes
  )
)

The seed determines challenge type and parameters. Challenges are fully deterministic — anyone can compute the same result offline with the same inputs.

Architecture: 8 Core Algorithms × 4 Difficulty Levels = 32 Types

The contract supports 8 core mathematical algorithms, each with 4 difficulty levels (corresponding to 4 phases), totaling 32 challenge types. Difficulty is controlled by the size of the modulus p.

Type numbering: challengeType = baseAlgorithm + difficulty × 8

The 8 Core Algorithms

Security Design

All challenges are guaranteed solvable: every algorithm uses a "generate answer first, construct problem second" approach, mathematically ensuring no unsolvable challenges exist.

• Front-run proof: challenges include msg.sender — each address gets a unique problem
• Timed rotation: block.timestamp / 300 — challenges rotate every 5 minutes
• Progressive difficulty: modulus grows from 10K to 10M as minting progresses

Why These Challenges?

• AI-friendly: well-defined mathematical computations, solvable in seconds by AI
• Human-unfriendly: manual modular arithmetic and discrete logarithms are painful
• On-chain verifiable: contract only needs to verify the answer, not re-solve the problem
• Brute-force resistant: search space is large enough, but trivial for AI
• Deterministic: same seed always produces the same challenge with a unique answer

05 Verification Flow

function getChallenge(address solver) public view returns (
    uint8 challengeType,
    uint256 a, uint256 b, uint256 c, uint256 d, uint256 p
);

function phase1Mint(uint256 answer) external;
function phase2Mint(uint256 answer) external;

1. Call getChallenge(myAddress) to retrieve current challenge parameters
2. Compute the answer off-chain
3. Phase 1: call phase1Mint(answer) — requires 0.1 USDC approval
4. Phase 2: call phase2Mint(answer) — requires 0.01 USDC approval
5. Contract verifies answer → mints on success

Front-Running Protection

• Challenge includes msg.sender — each address gets a different problem
• Includes block.timestamp / 300 — challenges rotate every 5 minutes
• Even if someone sees your answer, it won't work for their address

06 Minting Flow (User Perspective)

Phase 1

Phase 2

07 Difficulty Scaling

Minting progress determines challenge difficulty:

Progressive difficulty means: early participation has a low barrier — basic AI scripts can solve the challenges. Later phases require more computational power. But challenges always remain solvable for AI, while being impractical for humans.

08 Contract Architecture

AIPoWToken.sol
├── ERC-20 Standard Implementation
├── Transfer Restrictions (disabled during Phase 1)
├── Challenge Generator (pure view functions)
│   ├── getChallenge(address) → challenge parameters
│   ├── 8 core algorithms × 4 difficulties = 32 types
│   └── verifyAnswer(address, uint256) → bool
├── Minting Logic
│   ├── phase1Mint(answer) — 0.1 USDC + solve → mint + LP
│   ├── phase2Mint(answer) — 0.01 USDC + solve → register
│   └── phase2Claim(hourId) — claim hourly share
├── LP Management
│   ├── Auto-create AIPOW/USDC pair
│   ├── Phase 1: addLiquidity on every mint
│   └── LP permanently locked 🔒
├── Math Utilities
│   ├── modExp, nextPrime, isPrime
│   ├── matrixDet, fibMod, combMod, modInverse
│   └── Difficulty scaling logic
└── Permissions
    ├── startPhase2() (onlyOwner, normally auto-triggered)
    └── renounceOwnership() (irreversible)

09 Risks & Mitigations

10 Market Narrative

• New minting paradigm — not PoW, not PoS, but PoI (Proof of Intelligence)
• AI-native — challenges are designed for AI; human manual participation is virtually impossible
• Fully decentralized — no whitelist, no owner privileges, no external dependencies
• Permanent liquidity — LP is permanently locked; rug pull is structurally impossible
• Fair launch — zero pre-mine; all tokens are produced through solving challenges
• Progressive difficulty — easy early, hard later, but always fair