Pearl PoUW | Useful Work vs. Consensus

0. Start here — product, users, and mass adoption

What is the product? (there are three, not one)

Not a product today: training compute, generic matmul-as-a-service, marketplace GPU rentals (compute.pearlresearch.ai is gated), industry-standard FP8/BF16 stacks.

User stories (four personas)

Training or inference?

The world if everyone used Pearl

Is mass adoption realistic?

Why mass adoption might happen (bull case):

1. PRL price pumps → mining subsidy exceeds inference margin → every GPU farm installs Pearl plugin “for free money.”
2. More cloud APIs copy Together → discounted inference pulls developers into Pearl quant models.
3. FP PoUW ships → training clusters join → “useful work” expands beyond inference.

Why it might not (bear case — AGTI default):

1. Protocol allows bare mining — farms skip LLM entirely once subsidies are high enough (whitepaper admits this).
2. Not commodity matmul — industry runs BF16/FP8 google/* on stock vLLM; Pearl requires pearl-ai/*-pearl, int7 NoisyGEMM, sm90 Hopper, and most layers/dims never mine (§7).
3. Circular economics — Together discount depends on PRL emissions; if coin is weak, subsidy vanishes.
4. Training never arrives — without it, “AI-native PoW” is really “inference-miner PoW.”
5. Bitcoin dynamics repeat — specialization wins; dual-use hobbyist GPUs lose to dedicated matmul lottery farms.

AGTI plain answer: The product that exists today is PRL + miner software, with one subsidized inference API as a proof-of-concept. Mass adoption is not unrealistic for the coin/mining layer (another PoW chain can absolutely attract hashrate). It is unrealistic as stated for “the AI industry runs on Pearl matmul” unless Pearl quant becomes a standard, PRL stays valuable, and inference demand genuinely co-locates with mining — none of which is proven yet.

1. The tension in one glance

Pearl’s whitepaper sells 2-for-1 GPU economics: security subsidy plus useful AI output from the same watt-hours. The open-source reference miner grinds random matrices until a BLAKE3 jackpot clears difficulty — no LLM, no user, no tokens.

2. Whitepaper promise vs chain rules

The whitepaper also admits: “Pearl attracts compute that does not necessarily have useful work.”

3. How Pearl mining works (PoUW pipeline)

Code anchors: bare search in zk-pow/src/ffi/mine.rs · defaults in node/zkpow/miner.go (k=1024, rank=32) · verify in node/zkpow/verify.go.

4. Two miners, one protocol

5. ASIC economics — when dual-use wins

The whitepaper’s ASIC argument is profitability, not impossibility: a Pearl-only chip “will lose the ability to do useful work, and thereby be overall less profitable.”

6. Fleet dynamics simulation (AGTI model)

The quadrant map above is qualitative. To stress-test when dual-use wins vs ASIC/bare farms, AGTI built a monthly fleet dynamics model in Python/numpy: three fleet types (dual-use GPU, bare GPU, ASIC) compete on hashrate share, revenue, and profit-driven capacity growth.

Question: If PRL subsidies rise, inference demand stays flat, and ASIC hash/$ improves, does the network stay on the useful-work path — or converge to matmul lottery farms? Source: AGTI fleet simulation (simulate.py). Parameters are illustrative, not calibrated to mainnet.

Scenario charts — 36-month horizon

AGTI simulation

baseline

moderate PRL

Endogenous PRL mean-reversion cannot stop ASIC crowding once hash/$ advantage compounds.

inference_boom

best case

Only scenario where dual-use hashrate stays double-digit and inference becomes ~half of network revenue.

prl_pump

subsidy shock

Higher PRL alone attracts capital into best hash/$ — ASICs and bare GPUs, not vLLM farms.

asic_creep

hardware curve

4× ASIC efficiency gain → HHI ≈ 1.0. Matches whitepaper's "compute without useful work" branch.

together_only

May 2026 shaped

Tiny API demand (~50 GPUs) + low PRL: dual-use starts weak and terminal useful hash → 0.2%.

bitcoinification

stress test

Combined pump + ASIC creep + flat inference — mission collapse. Structurally Bitcoin-shaped.

AGTI read from the sim: PRL price alone does not preserve useful work. The whitepaper virtuous loop (§8 below) requires inference demand scaling with subsidies — the only lever that materially keeps dual-use competitive in this model. Today’s adoption profile maps closest to together_only.

Code anchors (reproducible)

Run locally (scripts hosted on AGTI — no repo clone required):

mkdir pearl-economics && cd pearl-economics
curl -LO https://agtico.github.io/assets/research/pearl-economics/requirements.txt
curl -LO https://agtico.github.io/assets/research/pearl-economics/simulate.py
curl -LO https://agtico.github.io/assets/research/pearl-economics/compare_inference_pricing.py
python3 -m venv .venv && .venv/bin/pip install -r requirements.txt
.venv/bin/python simulate.py --all --plot
.venv/bin/python compare_inference_pricing.py

Full folder: agtico.github.io/assets/research/pearl-economics/

Limits: Not calibrated to Pearl mainnet difficulty (~4.9M), block reward decay, pool variance, or token sell pressure. ASIC is modeled as zero inference utility by definition (protocol allows it). See the research README.

7. Adoption & useful-work reality check

Pearl’s pitch treats “matmul” as if the AI industry already runs it. It doesn’t. When Google ships Gemma 4 31B, the ecosystem runs BF16/FP8 weights through stock vLLM, TensorRT, llama.cpp, SGLang — thousands of hosts, hundreds of billions of tokens/week on aggregators like OpenRouter. Pearl’s stack is a parallel, incompatible matmul pipeline: proprietary 7-bit/8-bit integer paths, NoisyGEMM crypto noise, Blake3 + Plonky2 proofs, and a Pearl-only vLLM plugin — today on three pearl-ai/* checkpoints and Hopper (sm90) GPUs only.

Plain English: Pearl did not turn “GPU matmul” into a commodity. They built a specialized lottery algebra that resembles linear layers inside one forked inference stack. Most layers in a Pearl model never mine. Most matrix sizes never mine. Standard BF16 Gemma on normal vLLM cannot produce valid Pearl blocks even if you point it at the same GPU.

What Pearl matmul actually means (three stacks)

Pearl conflates three different workloads under one brand. Only the first is what pearld validates; the second is optional dual-use inference; the third is inference-only inside the plugin.

Mainstream AI matmul vs Pearl matmul

OpenJarvis model enablement docs state explicitly: raw Hugging Face models like google/gemma-4-31b-it are not mineable — you need pearl-ai/Gemma-4-31B-it-pearl with quantization_config.quant_method = "pearl", mining layers tagged for 7-bit NoisyGEMM and attention/MLP down-proj kept on 8-bit vanilla paths.

Layer selection rules (why most matmul never mines)

Model config — a layer is a “mining layer” only if weights and activations are 7-bit, static channel/tensor weights, dynamic per-token activations, symmetric quant (vllm_config.py):

Runtime thresholds — even on 7-bit mining layers, NoisyGEMM (PoW path) runs only when all of m, n, k are ≥ 1024 (config.yaml). Smaller matmuls (typical of many attention/MLP shapes in a single forward step) fall back to vanilla GEMM → inference OK, no mining.

Consensus — separately, pearld only accepts Int7×Int7→Int32 MMA with strip values in [-64, 64], independent of whether anyone ran an LLM (verify.rs / proof.rs). The whitepaper’s “arbitrary matmul” is this fixed lottery format, not PyTorch torch.matmul generically.

What breaks if you use standard BF16/FP8 vLLM

Pearl’s HF model card notes plain vLLM works for inference-only (no mining). Mining requires the full Docker stack: pearld + gateway + plugin-enabled vLLM.

Hardware & precision moat (May 2026)

• GPU: Pearl pearl-gemm compiles with arch=compute_90a,code=sm_90a — Hopper H100/H200 (setup.py).
• Precision: Pearl whitepaper §1.1 states today’s protocol is exact INT matmul; FP/quantized PoUW for modern BF16/FP8 inference is a future upgrade — not what mainnet verifies today.
• Ecosystem: Google’s Gemma 4 launch targets BF16 on 80GB H100 and quantized variants on workstation GPUs via standard runtimes (Google announcement coverage) — a completely different supply chain from Pearl’s int7 plugin.

AGTI read: Pearl matmul is not fungible with industry matmul. Adopting Pearl means adopting Pearl-quantized models, Hopper-only kernels, and accepting divergent behavior vs the commodity google/* endpoints developers already use. That is why “the AI industry runs on Pearl matmul” is misleading — the industry runs BF16/FP8; Pearl runs a sidecar int lottery on a tiny model list.

Inference API pricing — subsidized vs market?

Together markets pearl-ai/gemma-4-31b-it at ~25% off, subsidized by Pearl mining. AGTI queried public catalogs May 24, 2026 (OpenRouter models API, OpenRouter endpoints, Together model pages).

Blended example (1M input + 200k output tokens): OpenRouter best ≈ $0.19 · Together Pearl ≈ $0.45 → Pearl is ~2.3× more expensive than where Gemma 4 31B actually trades volume today.

AGTI read:

1. The discount is internal. Pearl is ~23% below Together’s own $0.39/$0.97 SKU — that’s the “~25% off” claim. It is not below OpenRouter’s $0.12/$0.37 market.
2. Subsidy isn’t showing up as market undercut. If PoUW + PRL emissions were funding cheap inference, Together’s Pearl route should compete on absolute price. Instead OpenRouter routes away from Together to cheaper hosts.
3. Not commodity Gemma. pearl-ai/gemma-4-31b-it is a Pearl re-quantized checkpoint (HF: pearl-ai/Gemma-4-31B-it-pearl), not Google’s base weights. INT8 vs FP8, 32K vs 262K context, Pearl vLLM plugin required. Developers cannot treat it as a fungible swap for google/gemma-4-31b-it on OpenRouter — quality, latency, and behavior are questionable to assume equivalent.
4. No separate OpenRouter listing. There is no pearl-ai/* slug on OpenRouter. Pearl only appears as Together’s 32K / $0.28 / $0.86 backend when the router hits that provider.

Reproduce pricing check: compare_inference_pricing.py (public APIs, no keys).

AGTI read: Useful work is weakly evidenced and narrowly compatible. The chain proves matmul lottery tickets; the one external API is not market-competitive on price and not interchangeable with commodity Gemma 4 31B on OpenRouter.

8. Whitepaper virtuous loop vs reality

9. Verdict & due diligence

Evaluators should track:

1. Share of hashrate on vLLM vs bare clients (see §6 simulation)
2. Whether Pearl API prices undercut OpenRouter commodity Gemma (today: no — §7 pricing)
3. Whether developers adopt pearl-ai/* vs staying on google/* (model migration, not swap)
4. ZK proving cost vs search cost at target difficulty
5. Together endpoint traffic + HF inference provider count on pearl-ai models

Full source doc with code citations: agti/docs/pearl_pouw_useful_work_asic_analysis_2026-05-23.md

Disclaimer: Independent AGTI research for informational purposes only. Not investment advice.