Keryx: A Decentralized Protocol for Verifiable AI Inference

Version 1.2 — May 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 — TinyLlama-1.1B, DeepSeek-R1-8B, DeepSeek-R1-32B, and LLaMA-3.3-70B — 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.

A subsequent SALT v2 hardfork (DAA 17,275,000, mainnet 2026-05-30) updated the KeryxHash domain separator, breaking compatibility with all pre-v0.2.9 miners. Node v1.2.2 and miner v0.2.9 are required for continued participation.

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

Smart contracts on Ethereum, Solana, or any EVM-compatible chain are deterministic by design — they cannot make decisions that require reasoning, context, or language understanding. Today, any agent that needs to interpret natural language, evaluate a situation, or generate a response must call a centralized API (OpenAI, Anthropic, etc.). This creates a single point of failure, censorship, and trust in the agent's decision-making loop.

Keryx breaks this dependency. An on-chain agent broadcasts an AiRequest transaction to the Keryx network with a prompt and a fee. A miner executes the inference and publishes the result on-chain as an AiResponse. The agent reads the result directly from the chain — no HTTP call, no API key, no corporate gateway. The result is economically backed by the miner's escrow: if the response is fraudulent, it is slashable. The agent can therefore treat the inference as a verifiable on-chain fact, not a trusted 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. KeryxHash: GPU-Optimized Proof of Work

Keryx uses KeryxHash, a modified version of kHeavyHash — the memory-hard hash function from Kaspa — with two additions designed to maintain ASIC resistance and establish Keryx's independent identity.

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 Hardware Targets

PoW mining — KeryxHash requires an NVIDIA GPU (SM 7.5+, GTX 1660 and above). The 64×64 matrix lives in L2 cache; the ARX mixing step is register-resident. CPU mining is supported for testing purposes but not economically competitive.

LLM inference (OPoI) — The inference engine requires CUDA. AMD GPUs are not supported on Keryx. Only NVIDIA GPUs can participate in mining.

Summary of GPU compatibility:

Only NVIDIA GPUs (SM 7.5+, driver ≥ 535) are supported for full participation. The minimum supported compute capability is SM 7.5 (GTX 1660 Super, RTX 2060 and above).

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. When the miner eventually claims this UTXO after the challenge window, the mandatory 0.3 KRX fee is burned, so the miner's net recovery is 0.78 KRX — not the full 1.08 KRX. This burn is unavoidable: every transaction on Keryx carries a fixed fee of 0.3 KRX that is destroyed, not redistributed. 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.

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 (enforced from DAA 15,550,000):

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

Deterministic re-execution: the node re-runs the fixed-point model to verify the miner's commitment. Same security model as Ethereum L2 fraud proofs — instant, practical, no cryptographic bottleneck.

The key insight borrowed from optimistic rollups (Arbitrum, Optimism) is that you do not need to prove all executions are correct up front — you only need to prove a specific execution is wrong when challenged. This makes the verification cost asymmetric: honest miners pay nothing extra, and challengers only trigger full verification when they have evidence of fraud. Keryx applies this same logic to AI inference.

The fraud proof mechanism deserves emphasis because it avoids ZK entirely:

1. ▸The on-chain commitment is model_fixed::forward(request_hash) — a 32-byte value produced by a small, deterministic, fixed-point MLP.
2. ▸The fixed-point MLP uses only integer arithmetic (i32/i64). It produces the same output on every CPU architecture, every OS, every compiler.
3. ▸Re-execution takes microseconds. Every full node can verify any challenge without special hardware.
4. ▸A dishonest miner must submit a commitment that differs from what the honest model would produce. There is no partial fraud — either the commitment matches or it does not.

This approach sacrifices completeness (the LLM output itself is not verified on-chain — only the commitment is) for practicality. The system guarantees that miners cannot submit arbitrary responses without economic risk; they must at minimum run the fixed-point model correctly.

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 (TinyLlama / DeepSeek-R1 / LLaMA-3.3)
    + 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

5.7 Mining Pool Integration

Mining pools present a structural consideration: in a pool, the pool server constructs the block template and controls the coinbase extra_data. Individual workers do not interact directly with the inference layer.

Pool-aware OPoI: Pools that register an escrow_pubkey participate in OPoI and earn the 20% escrow premium on top of standard fees. The pool runs the inference on behalf of its workers. 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.

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 miner's wallet.
• ▸14.4% (0.78 KRX) — Recovered by the miner after the challenge window ends (~1 hour / 36,000 blocks).
• ▸5% (0.27 KRX) — Allocated to R&D (protocol treasury).
• ▸5.6% (0.3 KRX) — Burned as the mandatory escrow claim transaction fee.

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 — Monitor mature escrows

The pool can query unspent escrow UTXOs for a given pubkey via the keryx-api REST endpoint:

GET /api/v1/escrow/{escrow_pubkey_hex}

For each UTXO returned, check the block_daa_score at creation. The UTXO is claimable once the current network blue score exceeds creation_blue_score + 36000. The gRPC GetUtxosByAddresses call can also be used to monitor UTXOs at the escrow address directly via the node at port 22110.

Step 4 — Broadcast claim transactions

A claim transaction spends the mature escrow UTXO back to any pool address:

input:  escrow UTXO (signed with escrow_privkey, input sequence >= 36000)
output: pool payout address (escrow value minus minimum tx fee)

6. Economic Model

6.1 The KRX Token

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 + 0.78 KRX recovered (0.3 KRX burned as claim fee).
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

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. ▸PoW hashing — KeryxHash via CUDA/OpenCL plugins
2. ▸OPoI tag computation — fixed-point MLP on the block nonce
3. ▸LLM inference — open-weight models via candle-transformers (Rust)

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.

The LLM engine runs on CUDA when available (candle-core with CUDA feature, compiled with CUDA 12.2 for broad driver compatibility — requires NVIDIA driver ≥ 535, supports SM 7.5+). AMD GPUs are not supported for inference. On systems without an NVIDIA CUDA GPU, PoW continues but AiRequest transactions cannot be fulfilled. Mining and inference run concurrently — neither blocks the other.

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. GTX 1660 Super / RTX 2060 (8 GB) handles TinyLlama-1.1B; RTX 3060 (12 GB) handles DeepSeek-R1-8B; RTX 3090 / 4090 (24 GB) handles DeepSeek-R1-32B. AMD GPUs and CPU-only miners can participate in PoW but cannot fulfill AiRequest transactions.

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)

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.

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 verifies the challenge on-chain. If fraud is confirmed, the miner's escrow is automatically transferred to the challenger's address.

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. Verification is microseconds.

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

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
• ▸ On-chain fraud proof (fixed-point re-execution)
• ▸ Automated challenger daemon (keryx-challenger)
• ▸ 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 3.1 — KeryxHash SALT v2 (Deployed — DAA 17,275,000)

• ▸ KERYX_MATRIX_SALT_V2 activated — new 32-byte domain separator for KeryxHash
• ▸ Salt selection per block daa_score: v1 below 17,275,000, v2 at and above
• ▸ Hard fork: miners on v0.2.8 or earlier produce invalid blocks after activation
• ▸ Node v1.2.2 + Miner v0.2.9 mandatory for continued mining

Phase 4 — 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 (Phase 4 cap enforcement for requests in older blocks)

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

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