CLAWING Architecture

1. Dual-Layer Structure

CLAWING uses a dual-layer timing structure built entirely on block.number — no timestamps, no manipulation vectors, fully deterministic.

Core Parameters

Why Two Layers?

In v4.0, one Epoch spanned 1M blocks (≈ 4.6 months). If many miners joined early, the hard cap exhausted in weeks, leaving months of idle time. The dual-layer fix reduces emission granularity to 1 week — if an Epoch's cap is exhausted, the idle period lasts days, not months.

Pure Block-Based Timing

The entire contract uses block.number for all time logic. No block.timestamp anywhere.

• Non-manipulable: block.timestamp allows ±15s miner adjustment. block.number is strictly monotonic.
• Deterministic: Given startBlock, anyone can calculate which Era/Epoch any block belongs to.
• Simple: One unified time model — block arithmetic only.

2. Emission Schedule

Each Era halves the per-block reward. 50% of all $CLAW is mined in Era 1. Over 98% is mined by Era 6. The full schedule spans 24 Eras across approximately 9.58 years.

Idle Period Analysis

Under the 3,500-block cooldown, a single address claims at most 14 times per Epoch. Assuming average T = 1,000 (logarithmic bonus ≈ 7.24×), single reward ≈ 723,700 CLAW:

500 miners is the equilibrium point. Below that, no idle period. Above, the idle period never exceeds one week — it automatically resets when the next Epoch begins.

3. Mining Mechanics

Reward Formula

The logarithmic curve is the anti-whale mechanism. Doing 10× the work yields roughly 3.3× the reward — not 10×. This ensures diminishing returns for large miners while still rewarding genuine AI computation.

Implementation uses MSB bitwise operation for the logarithm calculation, costing approximately 30 Gas — negligible overhead.

Cooldown: 3,500 Blocks

Each address must wait 3,500 blocks (≈ 11.67 hours) between claims. This replaces the old block.timestamp / 1 days approach which was manipulable at UTC boundaries. The new approach is fully deterministic — given block.number and lastClaimBlock, anyone can calculate if a claim is possible.

Max 14 Claims Per Epoch

With 50,000 blocks per Epoch and 3,500-block cooldown: 50,000 ÷ 3,500 = 14 claims maximum per address per Epoch. Hard-coded in the contract as MAX_CLAIMS_PER_EPOCH.

Epoch Seed

Updated once per Epoch (every 50,000 blocks) based on a combination of recent blockhashes and block.prevrandao. All claims within an Epoch share the same Seed — miners fetch it once per week.

4. Model Governance

CLAWING introduces on-chain model governance. Instead of a hard-coded whitelist, the community votes on which AI model to use each Era.

Era 1: Hard-Coded

Era 1 uses GPT-5.4, set in the constructor. No vote needed — this bootstraps the system with a known model.

Subsequent Eras: On-Chain Voting

For Era N (N > 1), the model is decided by on-chain voting during Era N-1. The governance cycle has three phases within each Era:

Voting Mechanics

• One-token-one-vote: 1 CLAW = 1 vote. Tokens are locked into the contract during voting.
• Flash-loan protection: Tokens must be transferred to the contract (locked) during the voting window. Cannot vote and withdraw in the same transaction.
• Withdrawal: Locked tokens can only be withdrawn during the announcement phase (Epoch 21) or after the Era ends.
• No vote switching: Once you vote for a model, you cannot change your vote — only add more tokens to the same choice.
• Max 20 candidates per Era. One nomination per address per Era.

zkTLS Model Verification

The ZK proof verifies the specific modelHash — not just the API domain. TLSNotary captures the model ID from the API response (OpenAI-compatible format) and the SP1 circuit proves it matches the Era's designated model. All candidate models must support the /v1/chat/completions standard interface.

5. Smart Contract Architecture

Three-contract decoupled design. Each contract has a single responsibility, minimizing attack surface and enabling independent auditing.

Key Design Decisions

• Epoch hard cap = perBlock × 50,000 — mathematically equivalent to EraCap/21 but requires only the current Era's perBlock (no division).
• globalEpoch as epochMinted key — single-layer mapping, one SLOAD per call (saves ~2,100 gas vs nested mapping).
• 3,500-block cooldown over daily cap — eliminates timestamp dependency, reduces single-address output by 60%, requires more miners for equilibrium.
• Single model per Era over whitelist — community self-governance, model-ID granularity, adaptive to AI iteration pace, zero admin privileges.

6. Security & Verification

zkTLS + Groth16

Every mining claim requires a Groth16 zero-knowledge proof generated by an SP1 circuit. The proof verifies that real AI inference was performed via TLSNotary (zkTLS) — capturing the TLS session, extracting the model response, and proving the model ID matches the Era's designated modelHash. The oracle cannot forge proofs — the math guarantees it.

MSB Logarithm (~30 Gas)

The logarithmic reward calculation uses a bitwise MSB (Most Significant Bit) operation — 8 rounds of binary search in assembly. Total cost: approximately 30 Gas. This converts log₂(T) to ln(T) via the identity ln(T) = log₂(T) × ln(2) ≈ log₂(T) × 0.693.

Pure block.number Timing

Zero block.timestamp dependency anywhere in the contract. Era calculation, Epoch calculation, cooldown checks, and Seed updates all use block.number exclusively. Non-manipulable, deterministic, and simple.

Flash-Loan Protection

Governance voting uses a lock-up mechanism. Tokens are transferred into the contract during voting and can only be withdrawn during the announcement phase or after the Era ends. This prevents flash-loan attacks where an attacker borrows tokens, votes, and returns them in a single transaction.

Replay Protection

The tuple (address, globalEpoch, claimIndex) is globally unique. Combined with the Epoch Seed validation and cooldown check, no proof can be submitted twice. The claimIndex must exactly match the current claim count for that address in that Epoch.