Whitepaper v0.1 (draft) · October 2026 · AWAI Network, L.L.C.

Mining Inference: Proof of Inference and KUMO

Turning Bitcoin miners' power, and the PCs people already own, into an AI inference network.

1. Background

Bitcoin mining draws roughly 12 GW worldwide. Miners hold cheap power contracts, sites with cooling and electrical plant, and round-the-clock operations. AI inference infrastructure is short of exactly those things.

Mining ASICs cannot run inference, so moving into inference reinvests power and sites rather than repurposing machines. At the end of September 2026, hashprice was about $40 per PH/s per day; a 15 J/TH machine grosses about $110 per MWh. The same power spent on video inference grosses, on our assumptions, several hundred to over a thousand dollars per MWh. It also needs demand and much more capital.

Miners trust proof of work because it pays without customers, is cheap to verify, balances itself through difficulty adjustment, pays out liquidly, and reduces to one comparable number, hashprice. Inference has none of these properties by default. This design supplies a substitute for each.

2. The murakumo network

murakumo joins ordinary machines into one network: Mac minis, Strix Halo boxes, RTX-class PCs and GPU servers. It serves them through an OpenAI-compatible API. Each node brings its own model server (Ollama, llama.cpp, vLLM, MLX and others). murakumo provides identity, enrollment, health checks, job placement and distributed inference across machines.

Each video generation is an independent job, so GPUs need no high-speed fabric between them. Large text models run across several machines by pooling their memory. As a result, nodes can take part without datacentre GPUs such as the B300.

Hardware

Bitcoin mining went from CPU to GPU to FPGA to ASIC. murakumo follows the same order: commodity machines first, then machines with accelerator cards, then dedicated silicon. For miners we publish an efficiency metric equivalent to J/TH: output video-seconds per kWh.

3. Proof of Inference

The unit of work: VCU

One VCU (Verified Compute Unit) is one PFLOP of verified, useful inference compute. Text and video are counted in the same unit. VCU is computed from the job specification, never self-reported by the node.

video / image: 2 · P_dit · N_latent · steps · cfg
text:          2 · P_active · (T_out + c · T_in)

Asymmetric verification

Proof of work is valuable because work is expensive and verification is cheap. We build the same asymmetry for inference.

• Video (step replay). The node submits a Merkle root over the hashes of every intermediate latent. A verifier picks one step at random, recomputes it and compares the result within a tolerance. This costs about 1/steps of the original job.
• Text. Generation is sequential, but checking a finished output takes one parallel prefill pass. The verifier compares top-k log-probabilities at sampled positions.
• Canaries. Jobs with known answers are mixed in, indistinguishable from customer jobs.
• Memory-bandwidth timing. Response times must match the declared GPU, which rules out fake GPUs.
• TEE. An upper tier uses confidential computing on GPUs such as the H100 and B200.

Stake and slashing

Verification samples jobs rather than checking all of them. With sampling rate p and gain G from one act of cheating, stake S is set so that S > G / p. A node that fails a check loses half its stake and its unconfirmed rewards. The sampling rate starts at 20% for new nodes and falls with track record to 5% and 2%, to 1% with a TEE, and to 0.5% on dedicated silicon that produces bit-exact results.

4. The KUMO economy

Bitcoin, mapped

Two units

Customers pay fees in credits, which are denominated in US dollars and not transferable. Nodes cash those credits out in fiat. KUMO pays the subsidy and serves as stake and slashing collateral; it can optionally pay fees too. Because of this split, the fee economy works from day one, with or without a token.

Supply

hard cap          2,100,000,000 KUMO
  Miner Genesis Allocation   105,000,000 (5%)
  block subsidy            1,995,000,000 (95%)
block             one settlement block per Bitcoin block
halving           Bitcoin halving heights: 1,050,000, 1,260,000, 1,470,000, …
era 0             genesis → next Bitcoin halving height (L0 blocks)
era 0 subsidy     R0 = 1,995,000,000 / (L0 + 210,000), fixed at genesis
later eras        R0 / 2^n per block, 210,000 blocks each

For example, with genesis in mid-2027 (around Bitcoin height 1,013,000):

Because KUMO halves on Bitcoin's halving blocks, miners can plan mining and inference revenue on one four-year calendar. The cost is that BTC and KUMO subsidies drop on the same day. The capacity pool below and fee growth soften that drop.

Splitting the subsidy

treasury       10% (first 210,000 blocks after genesis only)
verification    5% (permanent)
production     the rest
  customer pool   min(production, λ × block fees ÷ KUMO reference price)
  capacity pool   production − customer pool

The customer pool is capped at the value of the fees paid (λ = 1). Whatever is left pays nodes for answering protocol-issued work: verifying other nodes, generating public datasets and running benchmarks. Early on, when demand is small, the subsidy mostly pays for proven capacity. As demand grows it shifts to customer work, and eventually fees carry the rewards alone. This rule plays the part of difficulty adjustment.

Why self-dealing does not pay

Inference is customer work, so a node could buy jobs from itself to farm subsidy. murakumo places jobs on random nodes, so a participant with share s of network capacity gets back only s of what its own jobs pay out. With fee F, protocol cut c and customer-pool subsidy e per VCU, self-dealing loses money when:

s · ((1 − c) · F + e) < F

With e ≤ F and c = 10%, every participant below about 52.6% of capacity loses money by self-dealing. On top of that, no single operator may take more than 25% of a block's customer pool. The capacity pool cannot be gamed this way at all, because the protocol chooses that work.

Fees, stake and the ledger

• Nodes receive 90% of each fee. The other 10% funds the PPS reserve and operations. Fee revenue is never used to buy back KUMO.
• When fees are paid in KUMO, part of the payment is burned, as with EIP-1559.
• New nodes start on probation with no stake required. Their confirmed rewards lock automatically as stake, so nobody has to buy KUMO to start.
• The ledger decentralises in three phases. It starts as murakumo's own ledger with every block hash anchored to Bitcoin. It then moves to a federation of independent signers. Finally it moves to a chain that supports post-quantum signatures.
• Parameters can change only within fixed bounds, by VCU-weighted signalling (90% over 2,016 blocks). The cap and the halving schedule are immutable.

5. Ways to join

Start today on a home PC

curl -fsSL https://murakumo.cloud/install.sh | sh
murakumo node init
murakumo node doctor
murakumo node join --name my-pc

doctor inspects your GPU and memory and suggests which jobs to take. The client:

• stops work while you are using the PC
• receives challenges only inside the hours you declare
• pauses itself when earnings would not cover electricity
• needs no port forwarding

Home PCs receive only community-tier jobs, from customers who chose a lower price, plus public-dataset and verification work. They never receive confidential jobs.

If you already mine Bitcoin at home or in a pool, proving it earns a 1.5× Season 0 points multiplier for six months (90-day average of 1 TH/s or more).

6. Miner Genesis Allocation

5% of the cap (105 million KUMO) is reserved for Bitcoin miners. It is carved out of the 2.1 billion, so supply does not grow. Past hashrate decides how much a miner can reserve. Only power actually delivered to murakumo unlocks it.

• Hashrate is proven as a 12-month average, by BIP-322 signature, pool attestation or production report.
• Reservation weight is linear up to 50 PH/s and grows with the square root beyond that. No entity may reserve more than 5% of tranche A.
• 10% unlocks when the first machine passes verification. The remaining 90% unlocks monthly over 24 months, and each month requires delivering at least 80% of the pledged MW.
• Unlocked KUMO goes to stake first.
• Anything left undelivered returns to the block subsidy, never to the treasury.

7. Quantum readiness

Quantum computers threaten signatures, not mining. Grover's algorithm gives only a quadratic speed-up against SHA-256, which is no practical threat to mining. Shor's algorithm can recover elliptic-curve private keys. That puts at risk the roughly 6.0–6.9 million BTC whose public keys are already exposed. 2026 estimates put breaking secp256k1 at about 1,200–2,330 logical qubits. Today's best machines have at most around 100.

murakumo's fees are priced in dollars, and demand for them does not depend on elliptic-curve security, so they diversify a miner's revenue. murakumo will also migrate the Ed25519 and X25519 it uses for node identity and transport. Reward receipts, payout authorisations and node identity move to dual signatures, Ed25519 plus ML-DSA-65 (FIPS 204). Transport moves to hybrid X25519 plus ML-KEM-768 (FIPS 203).

8. Risks

• Demand. The reserve caps how much PPS can pay. If demand does not grow, rates fall.
• Price decline. Inference prices can fall by tens of percent a year as hardware and models improve.
• Obsolescence. GPUs turn over quickly, and dedicated silicon can lose efficiency if model architectures change sharply.
• Limits of verification. Proof of Inference combines sampling with economic penalties. It is not mathematically complete verification.
• Licensing. Some consumer GPU drivers restrict datacentre use.
• Regulation. Issuing and circulating KUMO requires legal clearance in each jurisdiction.

9. Roadmap

10. Legal

KUMO is not sold. There is no allocation to the team or investors, and no buyback from fees. KUMO is distributed only for verified work. Until counsel clears Japan's Payment Services Act and Financial Instruments and Exchange Act, and the rules of every target jurisdiction including the United States, KUMO remains non-transferable. Rewards earned before then are recorded as non-transferable credits.

Contact: support@murakumo.cloud