Keryx: A Decentralized Protocol for Verifiable AI Inference

Version 1.3 — July 2026

keryx-labs.com

Abstract

We propose Keryx, a high-throughput BlockDAG protocol that embeds Artificial Intelligence inference directly into the proof-of-work consensus. Miners do not merely hash — they compute. Each block carries a cryptographic commitment to an AI execution, turning otherwise discarded GPU cycles into verifiable intelligence.

The core mechanism, OPoI (Optimistic Proof of Inference), follows the established optimistic-rollup pattern: inference results are accepted immediately and can be challenged within a time-bounded window. Fraud is detected by re-running a deterministic fixed-point model on-chain. Dishonest miners lose a 20% escrow automatically routed from their block reward. No trusted third party is required at any stage.

The network operates at 10 blocks per second via the GHOSTDAG protocol, enabling near-instant finality for AI tasks. The native currency KRX rewards miners for honest compute, funds challengers who catch fraud, and pays users' inference fees — creating a closed economic loop around verifiable intelligence.

As of the Phase 3 hardfork (DAA 15,550,000 on mainnet), Keryx supports multiple open-weight models with per-model economic minimums enforced at the consensus level. Inference results are stored on IPFS; only a 34-byte CID is committed on-chain. At the PoM hardfork (DAA 37,780,000, mainnet 2026-06-26 18:00 UTC), Keryx replaces the KeryxHash matrix-multiply with Proof-of-Model (PoM): a memory-hard proof-of-work whose working set is the model weights, so winning a block requires the miner to actually hold a full model in GPU memory (one GPU = one model tier). The same hardfork swaps the served lineup to a fully uncensored, five-tier set — currently Qwen3-8B-abliterated, Mistral-7B-v0.3, GLM-4-9B, Qwen3.6-27B, and Kimi-Linear-48B (Q4) — the largest tier a card mines scaling with its VRAM, from a 6 GB entry card up to a 32 GB card. It adds two reward modifiers: a tier-reward that scales the miner's cut by the proven PoM tier, and a holder-reward that scales it by KRX held relative to recent production. PoM proves possession of the weights at the consensus level (verifiable byte-exact); it does not by itself prove the correctness of a generated inference — that remains the optimistic OPoI/challenge layer.

1. Introduction

The dominant paradigm for AI access in 2026 is centralization. A handful of companies control the models, the inference endpoints, and the content policies. An autonomous agent running on a smart contract cannot call GPT without trusting a private API gateway. A user in a jurisdiction deemed undesirable may find their access silently revoked. The compute exists everywhere; the permission does not.

Keryx's premise is simple: if miners are already running GPUs to win the block reward, they can also run a language model on those same GPUs. The inference becomes part of the work. The result is published on-chain. Anyone can challenge it. The outcome is economically enforced without coordination.

This is not an off-chain oracle. There is no multisig committee, no reputation score, no centralized aggregator. The chain itself is the oracle.

"Intelligence is the message. Keryx is the messenger."

2. Use Cases

2.1 Autonomous On-Chain Agents

Every AI agent on Solana and Ethereum is, today, fully centralized. The transactions are on-chain — but the intelligence behind them is not. The moment an agent has to reason, interpret language, or make a judgment call, it reaches off-chain to a Web2 API: OpenAI, Anthropic, some hosted endpoint. A single company can throttle it, censor it, log every prompt, or revoke the key. The "autonomous on-chain agent" is only autonomous until that API call.

This is a structural gap, not an implementation detail. Smart contracts on Ethereum, Solana, or any EVM-compatible chain are deterministic by design — they cannot reason, interpret language, or decide. So the decision-making is outsourced, and with it go the trust assumptions, the censorship surface, and the single point of failure.

Keryx closes the gap. An agent broadcasts an AiRequest on-chain; a miner executes the inference; the result comes back as a verifiable AiResponse — no HTTP call, no API key, no corporate gateway. The response is backed by real economic stake: a fraudulent answer is slashable. The agent treats the inference as a verifiable on-chain fact, not a trusted oracle. The chain is the oracle.

This is the missing primitive for truly autonomous agents: a trustless, permissionless, economically-enforced AI call.

2.2 Uncensored Knowledge Access

The dominant LLM providers apply content filters that vary by jurisdiction, topic, and business interest. Legal research, medical questions, political analysis, and security topics are routinely refused, redacted, or distorted depending on who is asking and from where.

Keryx miners run open-weight models with no content policy enforced at the protocol level. The network has no operator who can receive a compliance order. There is no account to suspend. A query submitted to Keryx is processed by whichever miner includes it in a block — a global, rotating set of independent operators with no shared policy.

This does not mean Keryx is designed for harmful use. It means the network cannot discriminate: a nurse asking about drug interactions, a journalist researching extremist rhetoric, and a lawyer analyzing case law all get the same neutral treatment.

2.3 Privacy-Preserving Inference (Roadmap)

In the current implementation, prompts submitted as AiRequest transactions are included in the BlockDAG as binary payloads. While the raw bytes are technically readable by a node operator with archival access, they are not human-readable in standard block explorers and are pruned from most nodes after ~30 hours.

A future upgrade will introduce proper cryptographic privacy: the user encrypts their prompt with the miner's public key before broadcasting the AiRequest. The miner decrypts and executes locally, publishing only the result and the OPoI commitment. The plaintext prompt never appears on-chain in any form.

Full end-to-end verifiability of encrypted inference is an open research problem — the OPoI commitment covers the result, not the prompt. This limitation is acknowledged. The design provides meaningful privacy for prompt content while preserving the fraud-proof guarantees on the output.

3. Background: The GHOSTDAG Protocol

Keryx inherits its consensus layer from Kaspa, which implements the GHOSTDAG protocol — a generalization of Nakamoto consensus to directed acyclic graphs (BlockDAGs).

3.1 BlockDAG vs Blockchain

In a traditional blockchain, blocks that are mined simultaneously create forks, and all but one are orphaned. This limits throughput because a higher block rate increases the orphan rate, which encourages mining pool centralization.

GHOSTDAG resolves this by allowing all blocks to coexist in the DAG. Rather than discarding parallel blocks, the protocol orders them using the k-cluster concept: given a parameter k, the DAG is partitioned into a "blue" set (honest, well-connected blocks) and a "red" set (blocks outside the k-anticone of the blue set). The linear chain extracted from the blue set is the canonical ordering.

3.2 Keryx Network Parameters

At 10 BPS, the network produces 864,000 blocks per day. The high block rate allows AI inference tasks to be submitted, executed, and finalized within seconds rather than minutes.

4. Proof of Work: KeryxHash → Proof-of-Model

Keryx launched with KeryxHash, a modified version of kHeavyHash — the memory-hard hash function from Kaspa — with additions designed to maintain ASIC resistance and establish Keryx's independent identity. At the PoM hardfork (DAA 37,780,000) the matrix-multiply core is replaced by Proof-of-Model, which ties the proof-of-work directly to possession of the model weights (Section 4.3). This section documents both: the KeryxHash design that secured the chain from genesis, and the PoM design that supersedes it.

4.1 The kHeavyHash Foundation

kHeavyHash builds on cSHAKE256 (domain "HeavyHash") and requires miners to perform a 64×64 matrix multiplication per hash attempt. The matrix is derived from the block header via an XoShiRo256++ pseudo-random number generator, changing with each block. This makes the algorithm memory-hard in a way that GPUs handle efficiently but ASICs cannot profitably optimize.

4.2 KeryxHash Modifications

Modification 1 — KERYX_MATRIX_SALT

Before seeding the XoShiRo256++ PRNG, Keryx XORs the pre-PoW hash with a 32-byte domain separator:

salt = b"KERYX:KeryxHash-v1:2026-04-12:xx"
seed = pre_pow_hash XOR salt
matrix = XoShiRo256++(seed)

This ensures KeryxHash matrices are completely different from Kaspa's for the same input, preventing any Kaspa-targeted hardware from being repurposed on Keryx.

Modification 2 — wave_mix

After the matrix multiplication and before the final cSHAKE256 call, Keryx inserts a 4-round ARX (Add-Rotate-XOR) mixing step over four 64-bit words:

ROUNDS = 4
KEYS   = [0x9e3779b97f4a7c15, 0x6c62272e07bb0142,
          0xb5ad4eceda1ce2a9, 0x243f6a8885a308d3]
ROTL   = [17, 31, 47, 13]

for r in 0..4:
    w[0] = rotl(w[0] + w[1], ROTL[0]) XOR KEYS[r % 4]
    w[2] = rotl(w[2] + w[3], ROTL[2]) XOR KEYS[(r+2) % 4]
    w[1] = rotl(w[1] + w[2], ROTL[1]) XOR KEYS[(r+1) % 4]
    w[3] = rotl(w[3] + w[0], ROTL[3]) XOR KEYS[(r+3) % 4]

wave_mix is purely arithmetic (no memory accesses, no lookup tables), adding approximately 32 ARX operations per hash — negligible overhead on a GPU warp but meaningful additional circuit complexity for a dedicated ASIC.

Modification 3 — KERYX_MATRIX_SALT_V2 (Hardfork — DAA 17,275,000)

At DAA score 17,275,000, Keryx activated a second domain separator. From this point, the PoW salt switches to:

salt_v2 = b"KERYX:KeryxHash-v2:2026-05-29:xx"  -- 32 bytes
seed    = pre_pow_hash XOR salt_v2
matrix  = XoShiRo256++(seed)

The active salt is selected per block based on its daa_score: blocks with daa_score < 17,275,000 use SALT v1; blocks at or above use SALT v2. Miners that did not update to v0.2.9+ produce a different matrix and their blocks are rejected. Node v1.2.2 and miner v0.2.9 are the minimum required versions.

The full KeryxHash pipeline is:

1. Expand block hash → 64 nibbles
2. Select salt: v1 (daa_score < 17,275,000) or v2 (daa_score ≥ 17,275,000)
3. Generate 64×64 matrix (XoShiRo256++ seeded with hash XOR salt)
4. matrix × nibbles → 32-byte product
5. product XOR hash
6. product = wave_mix(product)       ← Keryx addition
7. result = cSHAKE256("HeavyHash", product)

4.3 Proof-of-Model (Hardfork — DAA 37,780,000)

At DAA score 37,780,000 (mainnet 2026-06-26 18:00 UTC) the matrix-multiply core of KeryxHash is replaced by Proof-of-Model (PoM). The motivation is structural: under KeryxHash a miner could hash without ever loading a model, satisfying the OPoI inference requirement on a separate, low-end device or even on CPU. PoM closes that gap by making the proof-of-work itself depend on the model weights.

The weights are the scratchpad. PoM keeps the memory-hard philosophy of kHeavyHash but swaps the per-block 64×64 random matrix for the miner's resident model. The PoW becomes a data-dependent walk over the quantized weight tensors: each step reads a location derived from the running hash, mixes the bytes it finds there, and derives the next location from the result. Because the next read depends on the value just read, the walk cannot be precomputed and cannot be served from a partial copy — a miner missing even a fraction of the weights from GPU memory is forced to fetch them across the PCIe bus and slows down by orders of magnitude. Possession of the entire tier's weights in VRAM is therefore the only competitive configuration.

Walk v2 — hardened transition (H5 hardfork, DAA 59,009,037 — 2026-07-25). The original walk folded the four 64-bit words of each 32-byte chunk with XOR before a single mix step, so only the 8-byte XOR of a chunk was load-bearing. In July 2026 a modified miner exploited this in the wild: by precomputing that per-chunk fold it could mine competitively while holding a compressed digest instead of the weights, defeating the possession property. The H5 hardfork replaces the transition: the mixer is now chained through every word (state = mix64(state ^ w_i)), making all 32 bytes of each chunk load-bearing and order-dependent — no sub-linear digest of the weights can stand in for them. Verification is unchanged in nature (byte-exact, deterministic, Merkle openings against R_T). The same gate bundles a parallel-block cap (at most 20 blocks per selected parent are counted in the DAA score and paid by the coinbase; the surplus is demoted to the non-DAA mergeset, neutralizing sibling-flood spam without non-deterministic rejection), the pinned tier-0 swap to Qwen3-8B-abliterated (raising the tier-0 VRAM floor to 6 GB), and a difficulty reset for the relaunch. Two follow-up seed-salt gates (DAA 59,027,921 and 59,170,000) rotate the walk-seed derivation to anchor the relaunched chain and permanently invalidate blocks produced by pre-H5 binaries.

One GPU = one tier. The tier a miner mines is the largest model it can hold resident. A 6 GB card walks Qwen3-8B-abliterated; an 8 GB card walks Mistral-7B-v0.3; a 12 GB card walks GLM-4-9B; a 24 GB card walks Qwen3.6-27B; a 32 GB card walks Kimi-Linear-48B (Q4). This is enforced, not declared: the block's PoM solution embeds a Fiat-Shamir-selected set of weight chunks whose Merkle openings the node verifies against a per-tier weight root R_T published in the consensus parameters. The verification is byte-exact and fully deterministic — there is no floating-point tolerance involved — so it is pool-safe and fork-proof: a node validates a PoM block from the header and the weight root alone, with no trust in the producer.

Scope. PoM proves that the miner possesses the model (Layer 1). It deliberately does not attempt to prove that a subsequent generated inference is correct (Layer 2) — cross-hardware floating-point execution is not bit-reproducible, so exact re-execution cannot serve as a fraud proof. Inference correctness continues to be handled optimistically by the OPoI challenge layer (Section 5). Conflating the two would overstate the guarantee; Keryx claims "possession proven", not "inference proven".

4.4 Hardware Targets

PoM ties the proof-of-work directly to the model weights: both the weight walk and the model inference run through the CUDA runtime and a custom CUDA kernel. The reference Keryx miner is built on CUDA and requires an NVIDIA GPU (SM 7.5+, driver ≥ 535). Which tier a card mines is set purely by its VRAM, not by its architecture.

Summary of post-hardfork GPU compatibility:

There are five model tiers (0 → 4), and under PoM a GPU is bound to exactly one of them at a time: it holds a single model's weights resident, and both mines that model's proof-of-work and answers that model's inference requests. It does not serve a range of smaller models — one card, one model. A larger card may choose to load a lower tier instead, but it then mines and earns at that lower tier; coverage of all five models across the network comes from different miners on different tiers, never from one card serving several. The highest tier a card can compete in is the largest model whose weights fit in its VRAM — from Qwen3-8B-abliterated (~4.6 GiB resident, tier 0) on a 6 GB card up to Kimi-Linear-48B in Q4 (~28 GiB resident, tier 4) on a 32 GB card. Architecture is not the gating factor: any NVIDIA GPU at SM 7.5+ (Turing onward) can run any tier its VRAM holds — the weights are read as quantized GGUF, so there is no higher floating-point compute floor. The heavier the tier, the larger the share of the block reward, through the tier-reward modifier (Section 6).

5. OPoI: Optimistic Proof of Inference

OPoI is the protocol layer that transforms GPU mining into verifiable AI compute. It is designed to be introduced incrementally in three phases, with each phase adding stronger guarantees without breaking existing miners.

5.1 Design Principles

Optimistic first. ZK proofs for full LLM inference are not feasible in real time (100ms block windows). Instead, results are accepted immediately and remain challengeable for a fixed window. This is the same pattern used by optimistic rollups.

Economically enforced. Miners stake 20% of their block reward as collateral. Fraud costs more than it earns.

Deterministic verification. The on-chain fraud proof requires only re-running a small, fixed-point model — deterministic to the bit on all hardware. No trusted setup, no ZK circuit.

Backward compatible. Each phase is a soft upgrade. Miners who do not upgrade continue to produce valid blocks; they simply do not earn the OPoI premium fees from AiRequest transactions.

5.2 Phase 1 — The OPoI Tag (Deployed)

Every coinbase transaction includes an OPoI tag in its extra_data field:

extra_data format: /{nonce_hex16}/ai:v1:{tag_hex16}

The tag is computed by running a small fixed-point MLP (32→256→128→32 neurons, integer arithmetic, bit-exact on all hardware) on the block nonce XORed with a protocol salt:

tag = model_fixed::forward(nonce XOR PHASE2_OPOI_SALT)

The node validates the tag format at every block. A block with a malformed tag is rejected. This phase is optimistic — the node checks that the tag is present and well-formed, not that the inference was correct. Its purpose is to establish the on-chain convention and acclimate the miner ecosystem before Phase 2 activates stricter verification.

This lightweight MLP runs in microseconds on any CPU. GPU miners embed the computation in their stratum pipeline with negligible overhead.

5.3 Phase 2 — Escrow and Challenge Window (Deployed)

Escrow creation

When a miner registers an escrow_pubkey, the node automatically routes 20% of the block subsidy to a CSV-locked escrow output at index 1 of the coinbase transaction:

coinbase outputs:
  [fees]   → burn address       (100% of transaction fees)
  [miner]  → miner payout SPK   (75% of block subsidy)
  [escrow] → CSV-locked SPK     (20% of block subsidy)
  [R&D]    → protocol treasury   (5% of block subsidy)

At genesis (5.4 KRX/block), the escrow per block is 1.08 KRX, and the miner recovers it in full once the window closes. Claiming costs one transaction fee — a flat 0.3 KRX, burned like every fee on Keryx — but a single claim transaction spends many matured escrow outputs at once, so that flat cost is amortized across the whole batch rather than charged per block. The CSV lock (CheckSequenceVerify) is a relative timelock enforced at the consensus level: the escrow UTXO cannot be spent by anyone — including the miner — until 36,000 blocks have been appended on top of the block that created it.

If no escrow pubkey is embedded in the coinbase extra_data, the 20% is sent to the burn address instead, creating a 20% structural disadvantage for non-participating miners and pools.

Challenge window

From the moment the escrow UTXO is created, a 36,000-block window (~1 hour at 10 BPS) opens during which any network participant may submit an AiChallenge transaction referencing the corresponding AiResponse.

The challenge window is tracked by the node using the blue score of the DAG. Because GHOSTDAG assigns a total ordering to all blocks, the window boundary is deterministic and globally agreed upon by all nodes.

Monitoring for fraud during this window is the role of keryx-challenger — a permissionless Rust daemon that anyone can run. See §7.4 for the full description and setup instructions.

Slash (fraud proven)

If a valid AiChallenge is submitted and the node confirms the commitment mismatch, the escrow UTXO is immediately spent to the challenger_spk address embedded in the challenge transaction. The miner loses 20% of the block subsidy and the block reward already paid at output [0] cannot be reclaimed — net loss is the full escrow.

Note: on-chain slashing is currently suspended pending a deterministic, fork-gated redesign — see §7.4.

Claim (no fraud)

If the challenge window closes with no successful challenge, the escrow UTXO becomes spendable by the miner's escrow_pubkey. The miner's auto-claim module (built into keryx-miner) continuously monitors mature escrow outputs and broadcasts the claim transaction automatically when the CSV lock expires.

Economic summary

This creates a direct economic incentive to run the inference honestly: the expected value of fraud is negative as long as there exists at least one honest challenger watching the chain.

5.4 Phase 3 — Full AI Transactions (Deployed)

Phase 3 introduces three new transaction types identified by subnetwork ID, a multi-model registry enforced at the consensus level, and IPFS-based result storage. The enforcement rules were activated at DAA score 15,550,000 on mainnet.

AiRequest (subnetwork 0x03)

A user broadcasts an AiRequest to the Keryx network:

Binary payload layout (52 bytes minimum):
  [model_id:          32 bytes] — sha2-256 of the target model's primary weight file
  [max_tokens:         4 bytes LE] — maximum tokens to generate
  [inference_reward:   8 bytes LE] — sompi paid to the miner who fulfils the request
  [priority_fee:       8 bytes LE] — sompi burned as network fee (min 0.3 KRX)
  [prompt:            variable] — UTF-8 encoded question
Max size: 4,096 bytes

The transaction carries two distinct economic flows:

• ▸inference_reward — held in output[1] of the AiRequest transaction (a CSV-locked escrow). Paid to the miner who publishes the matching AiResponse. The consensus enforces per-model minimums (see table below) plus a surcharge of 0.05 KRX per 64-token increment of max_tokens.
• ▸priority_fee — the standard UTXO transaction fee, burned by the network. Minimum 0.3 KRX. Requesters may set higher values to get priority processing.

Per-model inference_reward minimums (uncensored lineup):

The effective minimum is: base[model] + ⌈max_tokens / 64⌉ × 0.05 KRX.

The model_id is the SHA-256 digest of the model's primary weight file — the same 32 bytes encoded in an IPFS CIDv0 multihash. This ties the on-chain request directly to a specific, cryptographically-identified set of model weights hosted on IPFS.

The request is included in a block template by miners who detect it. Only miners who have declared the corresponding model in their capability announcement (see §5.4.1) will answer it.

5.4.1 Capability Announcement

Miners declare which models they have loaded by embedding the following field in every coinbase extra_data:

/ai:cap:<model_id_hex64_1>,<model_id_hex64_2>,...

Each model_id_hex64 is the 64-character lowercase hex encoding of a 32-byte model ID. After the hardfork activation, a block containing an AiResponse for a model not listed in the coinbase ai:cap: field is rejected by the node. Blocks from miners who have not yet upgraded (no ai:cap: field) are still accepted — enforcement is skipped for undeclared miners to allow a smooth upgrade transition.

This mechanism prevents miners from answering requests for models they do not run, and allows the dApp to show users which models are currently available on the network.

AiResponse (subnetwork 0x04)

The miner publishes the result as an AiResponse transaction. The full inference output is stored off-chain on IPFS — only a compact CID is committed on-chain:

Binary payload layout (78 bytes, fixed):
  [request_hash:          32 bytes] — blake2b-256 of the AiRequest payload
  [challenge_window_end:   8 bytes LE] — blue score at which the challenge window closes
  [response_ipfs_cid:     34 bytes] — CIDv0 multihash: [0x12, 0x20, sha2-256_digest]
  [response_length:        4 bytes LE] — number of tokens generated

The CID encodes a SHA-256 digest of the inference output. Anyone can retrieve the full text via any IPFS gateway (e.g. https://keryx-labs.com/ipfs/<CIDv0>). The miner pins the result on their IPFS node before submitting the AiResponse transaction.

The OPoI commitment remains model_fixed::forward(request_hash) — unchanged from Phase 2. Challengers verify this commitment, not the IPFS content.

AiChallenge (subnetwork 0x05)

Any party who suspects a fraudulent AiResponse submits an AiChallenge:

Binary payload layout (74 bytes minimum):
  [response_hash:         32 bytes] — blake2b-256 of the disputed AiResponse payload
  [challenger_deposit:     8 bytes LE] — sompi burned if challenge is invalid
  [challenger_spk_version: 2 bytes LE]
  [challenger_spk:        32 bytes] — payment address for slashed escrow
  [proof_data:            variable] — empty in stub challenges; 32 bytes (request_hash) in full re-execution challenges

The node re-executes model_fixed::forward(request_hash) and compares the result to the OPoI commitment in the AiResponse. If they differ, fraud is proven and the miner's block escrow UTXO is immediately transferred to challenger_spk.

5.5 The Fraud Proof (Under Development)

This section describes a designed mechanism, not a running one. The fraud-proof code ships in the node, but consensus does not invoke it: AiChallenge transactions are recorded and never processed, and no escrow is slashed. See §7.4 for why it was disabled and what its return requires. Everything below is written in the design register and should not be read as a guarantee the network currently enforces.

The intended design borrows from optimistic rollups (Arbitrum, Optimism): you do not need to prove all executions are correct up front — only that a specific execution is wrong, when challenged. The verification cost is asymmetric, so honest miners pay nothing extra and full verification is triggered only when a challenger has evidence of fraud. The appeal for Keryx is that it avoids ZK entirely:

1. ▸The on-chain commitment is model_fixed::forward(request_hash) — a 32-byte value produced by a small fixed-point MLP.
2. ▸That MLP uses only integer arithmetic (i32/i64), so it produces an identical output on every CPU architecture, OS and compiler — the property any re-execution proof depends on.
3. ▸Re-execution takes microseconds, so any full node could verify a challenge without special hardware.
4. ▸Either the commitment matches what the honest model produces, or it does not. There is no partial fraud.

Two limits are worth stating plainly. First, the commitment attests a surrogate computation, not the answer the user reads: the LLM output itself is not verified on-chain. The mechanism was only ever designed to make arbitrary responses economically risky, not to certify inference quality. Second, extending the same technique to the real model output is not currently practical — reproducing GPU inference bit-for-bit across heterogeneous hardware does not hold, and a re-execution proof that is not bit-exact cannot settle a dispute deterministically.

This is why the network's present guarantee lives one layer down, in Proof-of-Model (§4.3): PoM proves byte-exactly which model a miner holds, which is enforceable today, while proving that a given answer is correct remains the open problem this section tracks.

5.6 The Complete OPoI Flow

Happy path (honest miner):

[1] User        →  AiRequest tx                          →  Chain
                   (prompt + inference_reward escrow + priority_fee)
[2] Chain       →  block template (AiRequest visible)    →  Miner
                   (miner checks declared model matches request)
[3] Miner runs LLM (Qwen3-8B / Mistral-7B / GLM-4 / Qwen3.6 / Kimi-Linear)
    + model_fixed(request_hash) for OPoI commitment
[4] Miner uploads result to IPFS → obtains CIDv0
[5] Miner       →  AiResponse tx (IPFS CID + commitment) →  Chain
                   20% block reward → block escrow (CSV, 36,000 blocks)
[6] Chain       →  CID visible; user fetches result from IPFS → User
[7] No challenge within window → Miner claims block escrow

Fraud path (dishonest miner):

[1–6] Same as above, but OPoI commitment is invalid
[7] Challenger  →  AiChallenge tx (proof: request_hash)  →  Chain
[8] Chain re-executes model_fixed(request_hash)
    commitment mismatch → fraud proven
[9] Chain       →  block escrow slashed                  →  Challenger

6. Economic Model

6.1 The KRX Coin

The native currency of Keryx is KRX. The smallest unit is the sompi:

1 KRX = 100,000,000 sompi

KRX serves three roles:

• ▸Mining reward — compensation for PoW + inference work
• ▸Inference fee — users pay 0.3 KRX per AiRequest (burned)
• ▸Challenge bond — challengers stake KRX when submitting fraud proofs

6.2 Emission Schedule

Keryx uses a smooth halving model: the block reward decays continuously using a monthly-granularity exponential function, with a 4-year halving period.

Genesis parameters:

• ▸Initial emission rate: 5,400,000,000 sompi/second = 54 KRX/second
• ▸Block reward at genesis (10 BPS): 540,000,000 sompi = 5.4 KRX/block
• ▸Halving period: 48 months (4 years)
• ▸Genesis date: May 10, 2026

Decay function:

reward_per_second(month m) = 5,400,000,000 × 2^(−m/48)  [sompi/s]
reward_per_block(month m)  = ceil(reward_per_second / 10)  [sompi]

Maximum supply: ~9,905,000,000 KRX (~9.9 billion)

Tail emission: After the main emission phase concludes (~2155), a permanent tail of 10 sompi/second (~0.00000001 KRX/s) maintains miner incentive indefinitely.

Deflationary burn: Transaction fees are burned in full, permanently reducing circulating supply below the theoretical maximum. At current network activity, ~9.4% of all mined KRX has been destroyed. If this burn rate holds over the full emission schedule, the effective long-term supply would converge toward ~9B KRX — approximately 10% below the theoretical maximum. Live burn figures are shown at the top of this page.

6.3 The OPoI Economic Loop

The 20% escrow mechanism creates a feedback loop:

1. ▸Miner stakes 20% of block reward as OPoI collateral.
2. ▸If honest: miner broadcasts a claim transaction after 36,000 blocks. Net result: 4.05 KRX immediate + 1.08 KRX recovered, less a claim fee shared across every output in the batch.
3. ▸If dishonest: escrow is slashed to the challenger. Net result: 1.08 KRX lost (the full escrow).
4. ▸Users pay priority_fee (min 0.3 KRX, burned) + inference_reward (paid to miner) per AiRequest.

This structure ensures that honest miners always earn more than dishonest ones, as long as challengers exist.

6.4 Fee Structure

6.5 Reward Modifiers (PoM hardfork — DAA 37,780,000)

The PoM hardfork introduces two consensus-level modifiers that scale the miner's share of the block subsidy (the ~75% paid at output[0]). Both are multiplicative, and any amount not paid to the miner is burned — neither the escrow (20%) nor the R&D allocation (5%) is touched, so total emission only ever decreases. Both are computed by the node from on-chain state alone, so they require no miner input and cannot be gamed.

Tier-reward. The miner's cut is scaled by the PoM tier it actually proved for the block. Larger models — which require more VRAM and are more useful to the network — earn a larger share:

The tier is read from the verified PoM proof (proof.tier), not self-declared, so a miner cannot claim a higher tier than it possesses.

Holder-reward. The miner's cut is further scaled by how much KRX the payout address holds relative to its own recent production. The ratio is effective_balance ÷ windowed_production, where production is the miner-cut coinbase earned over a sliding window of 864,000 blocks (~24 h). The thresholds are expressed in days of the miner's own production — holding 90× your daily production reaches the top bracket. A miner that sells everything immediately sits at the floor; a miner that accumulates rises to 100%. This couples block rewards to a long position in the coin and rewards conviction over immediate liquidation, without any lock-up transaction or signature — the binding is automatic on the payout script.

The numerator is not the instantaneous balance but the coin-age effective balance: each UTXO contributes value × min(1, age/W) with W = 864,000 blocks (~24 h), so a freshly received coin counts for nothing at first and ripens linearly to full weight over W. Age is bound to the payout script — sending coins to a different address resets it — so rotating a pot through fresh addresses no longer buys the top bracket. Consolidating UTXOs of mixed maturity anchors the merged output to its youngest input; consolidating coins of the same maturity class is free.

The schedule is nine brackets from a 50% floor to the full 100% cut. The ratio is compared by multiplication (effective_balance ≥ threshold × windowed_production), never division:

windowed_production is the coinbase miner-cut the payout address earned over the last 24 h (a rolling 864,000-block window) — a historical amount, counted whether or not it was later spent, so dumping recent rewards does not shrink it to game the ratio. It is floored at one block subsidy, so a fresh or zero-history address still needs effective_balance ≥ 90 × block_subsidy to reach bracket 8. Any shortfall below 100% is burned.

Because both modifiers co-activate at the hardfork, they compound: a small-tier, non-holding miner sits at the product of the two floors, while a top-tier miner holding well above the threshold earns the full 100% cut. The design favors operators who run large models and hold KRX — exactly the participants the network wants to retain. Reading the holder ratio from the payout SPK means pool participants are measured on the pool's aggregate balance and production, not their personal holdings; solo miners are measured on their own.

7. Network Architecture

7.1 Node (keryxd)

The Keryx full node is implemented in Rust, forked from rusty-kaspa. It maintains:

• ▸The BlockDAG state (GHOSTDAG)
• ▸The UTXO set (including escrow outputs)
• ▸The AI transaction stores (AiRequest index, AiResponse index, slash state)
• ▸The OPoI challenge window tracker

Network ports:

DNS seeder: seed.keryx-labs.com

7.2 The Miner (keryx-miner)

The Keryx miner is a GPU-first application with three concurrent responsibilities:

1. ▸Proof-of-work — PoM weight walk over the resident model (KeryxHash before the hardfork), via CUDA
2. ▸OPoI tag computation — fixed-point MLP on the block nonce
3. ▸LLM inference — open-weight GGUF models via an in-process inference engine

Supported models:

Model weights are downloaded from IPFS on first launch using the Keryx gateway. The model_id in each AiRequest is the SHA-256 digest of the primary weight file — the same digest embedded in the IPFS CIDv0 for that file. The miner only processes requests whose model_id matches a model it has loaded. After the PoM hardfork the loaded weights serve double duty: they are both the inference engine and the scratchpad walked by the proof-of-work (Section 4.3).

The LLM engine runs on CUDA (compiled with CUDA 12.2 for broad driver compatibility — NVIDIA driver ≥ 535, SM 7.5+). Both PoM and inference go through the CUDA runtime and a custom CUDA kernel, so the reference miner requires an NVIDIA GPU. Mining and inference run concurrently on the GPU; the resident weights are shared between the PoM walk and inference so there is no second copy in VRAM.

After completing an inference, the miner uploads the result to its local IPFS node, obtains a CIDv0, and broadcasts an AiResponse transaction with the CID and the OPoI commitment. The escrow auto-claim module monitors mature block escrow outputs and broadcasts claim transactions when the CSV lock expires.

The miner declares its loaded models in every coinbase extra_data via the /ai:cap: field. After the hardfork activation, the node enforces that only declared models can appear in AiResponse transactions from that miner's blocks.

Recommended hardware: An NVIDIA GPU (SM 7.5+, driver ≥ 535) with sufficient VRAM for the chosen model tier. A 6 GB card handles Qwen3-8B-abliterated; an 8 GB card handles Mistral-7B-v0.3; a 12 GB card handles GLM-4-9B; a 24 GB card handles Qwen3.6-27B; a 32 GB card handles Kimi-Linear-48B (Q4). The larger the resident model, the higher the tier-reward multiplier (Section 6.5).

7.3 The API and Explorer

The off-chain infrastructure is deliberately decoupled from the node and zero-dependency on Kaspa's legacy stack:

keryx-api — A Rust/Axum service that:

• ▸Indexes every block and transaction from the node's gRPC stream into PostgreSQL
• ▸Exposes a RESTful API for the explorer, wallets, and exchanges
• ▸Tracks AI transactions (request → response → challenge → slash lifecycle)
• ▸Monitors escrow balances and OPoI participation rates

keryx-ecosystem — A Next.js 15 / React 19 frontend that provides:

• ▸Real-time block and transaction feed (Server-Sent Events)
• ▸AI inference feed (live view of AiRequest/AiResponse pairs)
• ▸Address explorer with full transaction history
• ▸Network statistics (hashrate, difficulty, emission, node distribution)
• ▸Emission schedule visualization

7.4 The Challenger (keryx-challenger) (Under Development)

keryx-challenger is the automated fraud detection daemon that keeps OPoI honest. It is a permissionless Rust service that anyone can run — no trusted operator, no committee. Its punitive path is currently suspended — the operational status at the end of this section explains why, and everything in between describes the design it returns to.

How it works:

1. ▸Connects to a local keryxd node via gRPC and subscribes to the real-time block stream.
2. ▸For every AiResponse transaction detected, it re-executes model_fixed::forward(request_hash) locally.
3. ▸If the computed commitment differs from the one declared by the miner, it immediately broadcasts an AiChallenge transaction.
4. ▸The node would verify the challenge on-chain and, on confirmed fraud, transfer the miner's escrow to the challenger's address. This last step is the one currently suspended: nodes record AiChallenge transactions but do not act on them, so a challenge broadcast today has no effect and earns nothing.

Key security properties:

• ▸Lightweight proof — the fraud proof is just 32 bytes (the request_hash). The challenger funds the transaction with a small challenger_deposit (burned if the challenge is invalid), and provides a receiving address to collect the slashed escrow if fraud is confirmed.
• ▸Permissionless — multiple independent challengers can monitor the network simultaneously. A single honest challenger is sufficient to keep all miners honest.
• ▸Deterministic — the fixed-point MLP uses integer-only arithmetic (i32/i64), producing identical output on every CPU regardless of OS or compiler, in microseconds. This property holds today and is what any re-enabled settlement will rest on; what the redesign has to add is determinism in the settlement itself, not in the re-execution.

Running a challenger node:

cargo build --release
./keryx-challenger --node-address http://localhost:22110 \
                   --challenger-address keryx:qp...your_address

The challenger requires only a running keryxd instance and a Keryx address to receive rewards. It is intentionally lightweight — CPU-only, no GPU, no model weights required beyond the embedded fixed-point MLP.

Source: github.com/Keryx-Labs/keryx-challenger

Operational status — slashing temporarily suspended

Current status (June 2026): on-chain slashing is temporarily disabled while the settlement mechanism is redesigned. Inference remains mandatory and AiResponse transactions are still recorded on-chain; only the punitive slash is suspended.

When the OPoI economy first ran under production load, two compounding issues surfaced. The optimistic model — accept now, challenge later — exposed them exactly as designed, before any value could be permanently misassigned:

1. ▸

   Missing commitment after a storage migration. When AiResponse results moved from inline text to IPFS CIDs, the 32-byte OPoI commitment was no longer reliably embedded in the on-chain response. Challengers could therefore no longer distinguish an honest response from a fraudulent one, and began challenging honest responses — a slash storm against legitimate miners.

2. ▸

   Non-deterministic slash settlement. When several challengers targeted the same response, the slashed escrow's destination (challenger_spk) was recorded last-writer-wins. Independent nodes re-deriving the UTXO set from history could thus arrive at different results, producing a divergent utxo_commitment. Nodes rejected each other's blocks and fresh nodes could not complete initial sync — a consensus split.

The second issue is the decisive one: a fraud-punishment path that is not bit-for-bit deterministic across all nodes cannot be part of consensus. Worse, because the original slashing had been deployed without a fork-activation height, simply removing it created a second divergence — the post-removal rules no longer matched blocks that had been committed with slashing applied.

The fix. Slashing was disabled as a safety measure and the network relaunched with a clean, gated configuration. The redesigned mechanism — to be re-enabled at a published activation height (DAA-gated, so every node switches atomically) — restores three guarantees:

• ▸the OPoI commitment is embedded in every AiResponse again, so honest and fraudulent responses are always distinguishable;
• ▸slash settlement is fully deterministic (canonical first-writer-wins ordering, no dependence on network message timing);
• ▸challenger deposits are enforced, making frivolous challenges costly.

Until then, Keryx operates as a mandatory-inference network without economic punishment: a block with no valid OPoI inference is still rejected (no inference, no mining), but a fraudulent inference is not yet financially penalized. This is a deliberate, conservative trade-off — the correctness and liveness of the chain take priority over the slash mechanism, which returns once it is provably deterministic and properly gated.

8. Security Analysis

8.1 51% Attack Resistance

Keryx inherits GHOSTDAG's resistance to selfish mining: because the DAG accumulates all parallel blocks, a miner with less than 50% hashrate cannot systematically orphan honest miners' blocks. The high block rate (10 BPS) means that any attempt to build a private chain is quickly detected by the DAG's blue-score ordering.

8.2 OPoI Fraud Resistance

The escrow mechanism is only as strong as the probability that a fraud is challenged. Three factors maintain this probability:

1. ▸Economic incentive: challengers earn the full escrow (20% of block reward) for a successful challenge. At current emission rates, this is ~1.08 KRX per challenged block.
2. ▸Low challenge cost: the on-chain fraud proof is 32 bytes. Verification is microseconds. The gas cost is minimal relative to the reward.
3. ▸Automated challengers: the protocol is designed to support automated challenger nodes that continuously re-run the fixed-point model on all published AiResponses. Such nodes require only a CPU and an internet connection.

8.3 Sybil Resistance

OPoI escrow is tied to PoW: you cannot submit an AiResponse without first winning a block, which requires real hashrate. This prevents Sybil attacks where an attacker floods the network with fake AI responses without performing the underlying work.

8.4 P2P Attack Resistance

Keryx implements automatic peer banning for three attack patterns observed in the wild:

• ▸IBD spam: peers that repeatedly trigger "peer has no known block" are banned for 24 hours on the first offense.
• ▸Finality violations: peers whose pruning proofs conflict with the local finality point are banned immediately.
• ▸Phantom nodes: peers that establish connections but never participate (detected via 3 ping timeouts in 10 minutes) are banned for 24 hours.

These protections, combined with a configurable inbound peer limit (256 on the current mainnet node), prevent slot exhaustion attacks.

9. Roadmap

Phase 1 — Genesis (Completed)

• ▸ Full Kaspa → Keryx rebrand (binary, ports, address prefix, genesis block)
• ▸ KeryxHash (KERYX_MATRIX_SALT + wave_mix)
• ▸ OPoI tag in every coinbase (format validation)
• ▸ TinyLlama-1.1B inference in miner (candle-transformers)
• ▸ Explorer + API (real-time, PostgreSQL indexed)
• ▸ Richlist, top miners on explorer
• ▸ Web wallet integration

Phase 2 — Economy (Completed)

• ▸ 20% escrow routing (CSV-locked, auto-claim in miner)
• ▸ AiRequest / AiResponse / AiChallenge transactions
• ▸ P2P attack mitigations (autoban)
• ▸ Escrow hard-lock: prevent withdrawal before challenge window closes
• ▸ Transaction fee burn (100% of fees destroyed)
• ▸ Minimum transaction fee: 0.3 KRX

Phase 3 — Multi-Model Oracle (Deployed — DAA 15,550,000)

• ▸ Multi-model support: TinyLlama-1.1B, DeepSeek-R1-8B, DeepSeek-R1-32B, LLaMA-3.3-70B
• ▸ Per-model inference_reward minimums enforced at consensus level
• ▸ priority_fee separate from inference_reward (burned vs miner-paid)
• ▸ Token-count surcharge (0.05 KRX per 64-token increment)
• ▸ Model capability announcement in coinbase extra_data (/ai:cap:)
• ▸ Consensus enforcement: AiResponse rejected if model not declared in caps
• ▸ IPFS result storage: AiResponse stores CIDv0 instead of inline text
• ▸ model_id = SHA-256(weight file) = IPFS CIDv0 content hash
• ▸ IPFS for model weight distribution (miner downloads from Keryx IPFS gateway)
• ▸ CUDA inference support (candle-core, VRAM-aware multi-model placement)

Phase 4 — Proof-of-Model & Holder Economics (Deployed — DAA 37,780,000)

• ▸ PoM: KeryxHash matrix-multiply replaced by a data-dependent walk over the resident model weights (possession proof, one GPU = one tier)
• ▸ Byte-exact deterministic verification via per-tier weight Merkle root R_T + Fiat-Shamir chunk openings (pool-safe, fork-proof)
• ▸ Zero-copy: PoM walk shares the inference weights resident in VRAM (no second copy)
• ▸ Uncensored five-tier lineup: Qwen3-1.7B, Gemma-3-4B, Dolphin-3.0-8B, Qwen3-32B, LLaMA-3.3-70B (Q2)
• ▸ Tier-reward: miner cut scaled by proven PoM tier (68/76/84/92/100%), delta burned
• ▸ Holder-reward: miner cut scaled by KRX held relative to windowed production, delta burned
• ▸ CUDA mining engine (PoM walk + inference on a custom CUDA kernel)
• ▸ Walk v2 (H5 — DAA 59,009,037): non-foldable chained transition closes the partial-copy shortcut; parallel-block cap (N=20); tier-0 raised to Qwen3-8B-abliterated (6 GB floor)

Phase 5 — Scaling & Sovereign Intelligence (Research)

• ▸ On-chain fraud proof (fixed-point re-execution): the OPoI commitment has to be embedded in every AiResponse again before a challenge can tell an honest response from a fraudulent one — see §5.5
• ▸ Automated challenger daemon (keryx-challenger): re-enabled once slash settlement is deterministic and fork-gated — see §7.4
• ▸ Multi-GPU VRAM pooling: aggregate the VRAM of an entire rig (e.g. 6× 8 GB cards = 48 GB) via pipeline/layer-split inference (llama.cpp style), tolerant of low-bandwidth PCIe x1 risers — lets mining rigs serve large models no single card can hold
• ▸ Private end-to-end encrypted inference: prompts encrypted to the serving miner's X25519 public key, results encrypted back to the requester; the public feed exposes only metadata (model, fee, 🔒) — gives users the confidentiality of mainstream LLM providers
• ▸ Stateful models with persistent memory and optional tool/net access: retrieval-augmented memory over past inferences (tractable), and tool/network calls (feasible only in the private track — non-reproducible calls cannot be fraud-proven)
• ▸ Continual fine-tuning (self-improvement): tractable per-miner as private adaptation, but a shared evolving model is an open research problem — fine-tuning changes model_id, and agreeing on new weights requires deterministic federated training the network does not yet know how to verify

Determinism boundary. Network access and self-training break the determinism that OPoI fraud-proofs rely on (re-execution must reproduce the exact output). This phase splits inference into two tracks: a public verifiable track (deterministic, fixed-weight models, fraud-provable on-chain) and a private track (encrypted, stateful, richer models, verified by other means). VRAM pooling is orthogonal infrastructure serving both.

Phase 6 — The Cross-Chain Oracle

• ▸ Ethereum bridge: smart contract → AiRequest → Keryx → result → Ethereum callback
• ▸ Solana bridge (same pattern)
• ▸ On-chain agent demo: autonomous Ethereum agent calling Keryx for decisions
• ▸ Encrypted prompt submission (miner pubkey encryption)
• ▸ Cross-block AiResponse enforcement (cap enforcement for requests in older blocks)

Bridges ship last, once the inference layer is feature-complete: a cross-chain oracle is only useful when there is a rich, scalable, private inference network behind it to call.

10. Conclusion

Keryx demonstrates that proof-of-work and useful AI compute are not mutually exclusive. By embedding a fixed-point inference commitment into every block and backing it with economic collateral, the protocol transforms miners into a permissionless, censorship-resistant inference network.

The optimistic approach — accept now, challenge later — makes the system practical today without waiting for ZK-ML to mature. The fraud-proof mechanism is deterministic, fast, and requires no trusted setup. The economic incentives are aligned: honest miners earn more, challengers are rewarded for keeping the network honest, and users get AI responses backed by real economic guarantees.

Keryx is not a smart contract platform with an AI plugin. The inference is the consensus. The miners are the models. The chain is the oracle.

Appendix A — Key Constants

Appendix B — wave_mix Reference Implementation (C)

#define ROUNDS 4
static const uint64_t KEYS[4] = {
    0x9e3779b97f4a7c15ULL,
    0x6c62272e07bb0142ULL,
    0xb5ad4eceda1ce2a9ULL,
    0x243f6a8885a308d3ULL,
};
static const uint32_t ROTL_AMOUNTS[4] = {17, 31, 47, 13};

static inline uint64_t rotl64(uint64_t x, int n) {
    return (x << n) | (x >> (64 - n));
}

void wave_mix(uint8_t bytes[32]) {
    uint64_t w[4];
    for (int i = 0; i < 4; i++)
        memcpy(&w[i], bytes + 8 * i, 8);
    for (int r = 0; r < ROUNDS; r++) {
        w[0] = rotl64(w[0] + w[1], ROTL_AMOUNTS[0]) ^ KEYS[r % 4];
        w[2] = rotl64(w[2] + w[3], ROTL_AMOUNTS[2]) ^ KEYS[(r + 2) % 4];
        w[1] = rotl64(w[1] + w[2], ROTL_AMOUNTS[1]) ^ KEYS[(r + 1) % 4];
        w[3] = rotl64(w[3] + w[0], ROTL_AMOUNTS[3]) ^ KEYS[(r + 3) % 4];
    }
    for (int i = 0; i < 4; i++)
        memcpy(bytes + 8 * i, &w[i], 8);
}

Appendix C — AI Transaction Payload Binary Formats

AiRequest (subnetwork 0x03)

Offset  Size  Type    Field
------  ----  ------  -----
0       32    bytes   model_id — SHA-256(primary weight file) = CIDv0[2..34]
32       4    u32 LE  max_tokens
36       8    u64 LE  inference_reward (sompi) — paid to miner via output[1] escrow
44       8    u64 LE  priority_fee (sompi) — burned as network fee (min 0.3 KRX)
52      var   UTF-8   prompt

Min size: 52 bytes
Max size: 4,096 bytes

The AiRequest transaction must include output[1]: a CSV-locked P2PK script with value ≥ inference_reward.

AiResponse (subnetwork 0x04)

Offset  Size  Type    Field
------  ----  ------  -----
0       32    bytes   request_hash — blake2b-256 of the AiRequest payload
32       8    u64 LE  challenge_window_end — blue score when window closes
40      34    bytes   response_ipfs_cid — CIDv0: [0x12, 0x20, sha2-256_digest]
74       4    u32 LE  response_length — tokens generated

Fixed size: 78 bytes

The full inference result is stored on IPFS. The on-chain CID is the SHA-256 of the content prefixed with [0x12, 0x20] — standard IPFS multihash format (CIDv0).

AiChallenge (subnetwork 0x05)

Offset  Size  Type    Field
------  ----  ------  -----
0       32    bytes   response_hash — blake2b-256 of the disputed AiResponse payload
32       8    u64 LE  challenger_deposit (sompi) — burned if challenge fails
40       2    u16 LE  challenger_spk_version
42      32    bytes   challenger_spk — payment address for slashed escrow
74      var   bytes   proof_data — empty (stub) or 32 bytes (request_hash, re-execution)

Min size: 74 bytes

Appendix D — Mining Pool Integration

Mining pools present a structural consideration: the pool server constructs the block template and controls the coinbase extra_data, while the proof of work — and, under PoM, the model possession it proves — happens on the workers' GPUs.

Pool-aware OPoI: Pools that register an escrow_pubkey participate in OPoI and recover the 20% escrow cut. Workers receive their proportional share of pool earnings.

Standard pools: Pools that do not register an escrow_pubkey produce fully valid blocks but their 20% OPoI fee allocation is burned. This creates a natural incentive for pools to adopt OPoI: non-participating pools are at a 20% structural disadvantage versus OPoI-enabled competitors.

Where inference runs. Inference runs on the workers' GPUs, not on pool infrastructure. This follows directly from PoM: every worker already proves byte-exact possession of its tier model on every share it submits, so the machines holding the weights are precisely the machines that should answer requests. The pool's role is dispatch and on-chain settlement:

1. ▸the pool selects a pending AiRequest and dispatches it to a worker that declared the corresponding model;
2. ▸the worker runs the inference and returns the raw result asynchronously;
3. ▸the pool pins the result to IPFS and broadcasts the AiResponse;
4. ▸the pool owns the escrow — it claims after maturity and credits the worker internally.

The pool pins the IPFS result itself rather than delegating that to the worker, because it is the pool's escrow that stands behind the response during the challenge window: result availability belongs with whoever carries the risk. Workers never hold escrow keys.

Pool protocol contract

Share submission. A PoM share cannot be verified without its possession proof, so every paid share carries the complete proof:

mining.submit = [worker, job_id, nonce_hex16, opoi_tag_hex16, cid_or_empty, pom_proof_hex]

pom_proof_hex is the hex encoding of the canonical borsh wire form of the PomProof the node consumes. The pool must forward those exact bytes into block.pom_proof and set header.pom_final_state to the proof's final_state before submitting the block — never re-serialize the structure. Parameters 4 and 5 (opoi_tag, cid) are vestiges of the pre-PoM OPoI era and carry no consensus meaning; accept them for backward compatibility with existing miners.

A share is valid when pom_pow_value(final_state, pre_pow_hash) <= share_target, and final_state is only trustworthy once the proof's 256 walk steps have been replayed against the tier's pinned Merkle root. There is no lighter share format — proving possession on every share is the entire point of PoM. The proof is structurally bounded rather than open-ended: 256 steps, each carrying a 32-byte chunk and one Merkle path, which comes to roughly 250 KB borsh (500 KB hex) on the deepest tier. The maximum accepted frame is 2 MB per JSON-RPC line.

Verification is era-exact: seed derivation and the walk transition are DAA-gated. Pools should vendor the node's pom module rather than reimplement it from prose.

Inference dispatch. Results travel on a dedicated mining.ai_response message rather than being attached to the next share submission.

Capability declaration. The coinbase ai:cap field declares the union of the models the pool's workers actually serve. Its consensus role is narrow and specific: an AiResponse included in a block must reference a model_id declared in that same block's coinbase, so a pool must pair request and response within one block. It has no bearing on the tier reward, which is derived exclusively from the PoM proof — a block won on a top-tier proof may carry responses for any model the pool serves.

Pool implementation guide

This section provides the concrete technical details required for mining pool operators to integrate OPoI escrow.

Step 1 — Embed the escrow public key in coinbase extra_data

There is no node-level configuration for the escrow key. The pool controls the coinbase extra_data and must embed the escrow public key directly using the protocol marker:

extra_data format: /{nonce_hex16}/ai:v1:{tag_hex16}/escrow:{64-hex-chars-of-32-byte-schnorr-pubkey}

The node scans every coinbase extra_data for the /escrow: marker followed by exactly 64 hex characters. If found and valid, the escrow output is automatically created. If absent or malformed, the 20% escrow cut is sent to the burn address instead.

Step 2 — Coinbase output structure

Here is the breakdown for a 5.4 KRX block reward:

• ▸75% (4.05 KRX) — Sent immediately to the payout address. This is the base on which the tier and holder multipliers are applied; whatever they scale away is burned.
• ▸20% (1.08 KRX) — Escrow, recovered after maturity. Claiming costs a flat 0.3 KRX per transaction regardless of size, and one claim spends many matured outputs at once, so the effective per-block cost is that fee divided across the batch — under 0.004 KRX at a batch of 80.
• ▸5% (0.27 KRX) — Allocated to R&D (protocol treasury).

Note that the escrow and R&D cuts are computed on the full subsidy: the tier and holder multipliers scale the miner cut alone.

The escrow output locking script is:

<36000> OP_CSV <escrow_pubkey_32bytes> OP_CHECKSIG

Note: Keryx's OP_CSV pops its argument from the stack — no OP_DROP is needed.

Step 3 — Track mature escrow outputs

An escrow output becomes spendable once current_daa_score >= utxo.block_daa_score + 36000. The condition is evaluated on the DAA score, not the blue score, and the spending input must carry sequence = 36000.

GetUtxosByAddresses cannot serve this purpose: it derives a standard pay-to-address script from the address it is given and therefore never matches the CSV escrow script. Two approaches work instead.

Live tracking (recommended). Subscribe to VirtualChainChanged and fetch each new chain block, scanning its coinbase outputs for the pool's escrow script. Only chain-block coinbases matter. Every block's coinbase pays the blues of its own mergeset, but off the selected chain those outputs never enter the UTXO set — tracking escrow from every block seen therefore produces phantom outpoints whose claims can only ever be rejected as orphans.

Cold-start recovery. The keryx-api REST endpoint lists escrow outputs for a pubkey:

GET /api/v1/escrow/{escrow_pubkey_hex}

This index is advisory and deliberately slightly over-inclusive; the node remains the sole arbiter of whether an output is still unspent.

Step 4 — Broadcast claim transactions

A claim transaction spends matured escrow outputs back to any pool address:

inputs:  N matured escrow UTXOs (each signed with escrow_privkey, sequence = 36000)
output:  pool payout address (total input value minus the flat claim fee)

Any number of matured outputs may be spent by a single transaction, bounded only by the standard transaction mass limit: compute mass is 506 + 1118 x inputs grams against a 100,000-gram cap, making 88 inputs the hard ceiling. Since the claim fee is flat per transaction rather than per output, batching is the difference between paying that fee once per block found and once per batch. The reference miner batches up to 80 outputs, submitting a partial batch only when the oldest matured output has waited 24 hours.

Pool accounting

Tier-weighted shares. The cost of a hash does not depend on the tier — the walk is always 256 reads — but the revenue of a block does, since the miner cut is scaled by the tier of the winning proof. A share's expected contribution is therefore proportional to its own tier multiplier (68% / 76% / 84% / 92% / 100%), and shares should be weighted by the tier of the proof they carry rather than counted equally. Counting them equally would have small-tier workers subsidised by large-tier ones.

Holder multiplier. The holder ratio is read from the payout SPK, so in a pool it is a single pool-wide revenue factor: the pool's aggregate balance measured against its own windowed production. No per-worker attribution exists at consensus level, so the multiplier is necessarily socialised across all shares, and the pool's treasury policy determines the bracket everyone earns at.

Escrow crediting. The 20% escrow is revenue from the same block, merely deferred by the maturity window and one claim transaction. It is neither tier- nor ratio-scaled, so its amount is exactly 20% of the blue's subsidy and can be credited at block time or at claim time without ambiguity.

Inference rewards. The inference_reward reaches the pool through the escrow output of the AiRequest itself. Distribution is not dictated by the protocol, but it should follow the GPU that did the work: inference is discrete piecework with no variance, so spreading it across a share window smooths nothing and merely decouples the reward from the machine that earned it.

Keryx is open source (MIT License). Source code: github.com/Keryx-Labs