Keryx: A Decentralized Protocol for Verifiable AI Inference

Version 1.0 — 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.

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.

The full KeryxHash pipeline is:

1. Expand block hash → 64 nibbles
2. Generate 64×64 matrix (XoShiRo256++ seeded with hash XOR SALT)
3. matrix × nibbles → 32-byte product
4. product XOR hash
5. product = wave_mix(product)       ← Keryx addition
6. result = cSHAKE256("HeavyHash", product)

4.3 Hardware Targets

KeryxHash is designed for NVIDIA and AMD consumer GPUs (RTX 3060 and above, RX 6600 and above). The 64×64 matrix lives in L2 cache on modern GPUs; the ARX mixing step is register-resident. CPU mining is supported for testing purposes but not economically competitive.

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:

AiRequest (subnetwork 0x03)

A user broadcasts an AiRequest to the Keryx network:

Binary payload layout:
  [model_id:    32 bytes] — hash of the target model weights
  [max_tokens:   4 bytes LE] — maximum output length
  [fee:          8 bytes LE] — fee in sompi (0.3 KRX, burned)
  [prompt:       variable] — UTF-8 encoded question

The request is included in a block template by miners who detect it. Any miner with the corresponding model loaded will answer it.

AiResponse (subnetwork 0x04)

The miner publishes the result as an AiResponse transaction:

Binary payload layout:
  [request_hash:          32 bytes] — blake2b-256 of the original request
  [challenge_window_end:   8 bytes LE] — blue score when window closes
  [result:                variable] — first 32 bytes = OPoI commitment

The first 32 bytes of result are the OPoI commitment: model_fixed::forward(request_hash). This is the checksum that challengers will verify. The remainder is the free-text LLM output (TinyLlama-1.1B-Chat at current implementation).

AiChallenge (subnetwork 0x05)

Any party who suspects a fraudulent AiResponse submits an AiChallenge:

Binary payload layout:
  [response_hash:         32 bytes] — blake2b-256 of the disputed AiResponse
  [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 commitment declared in the AiResponse. If they differ, the fraud is proven. The miner's escrow UTXO is spent to the challenger_spk address immediately.

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 (prompt + fee)           →  Chain
[2] Chain       →  block template (AiRequest visible)    →  Miner
[3] Miner runs TinyLlama + model_fixed(request_hash)
[4] Miner       →  AiResponse tx (result + commitment)   →  Chain
                   20% block reward → escrow (CSV, 36,000 blocks)
[5] Chain       →  result visible                        →  User
[6] No challenge within window → Miner claims escrow

Fraud path (dishonest miner):

[1–5] Same as above, but commitment is invalid
[6] Challenger  →  AiChallenge tx (proof: request_hash)  →  Chain
[7] Chain re-executes model_fixed(request_hash)
    commitment mismatch → fraud proven
[8] Chain       →  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 0.3 KRX per AiRequest. These fees are 100% burned.

This structure ensures that honest miners always earn more than dishonest ones, as long as challengers exist. The fee for all transactions is 0.3 KRX, ensuring economic sustainability at the base layer.

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 — TinyLlama-1.1B-Chat via candle-transformers

The LLM engine (candle-core, pure Rust) loads once at startup and runs on CUDA if available, falling back to CPU. Mining is blocked until the model is ready — there is no degraded mode where inference is skipped silently.

The miner monitors the block template stream for AiRequest transactions, runs inference when one is detected, and embeds the result in the AiResponse. The escrow auto-claim module monitors mature escrow outputs and broadcasts claim transactions when the CSV lock expires.

Recommended hardware: A modern consumer GPU with sufficient VRAM to run TinyLlama-1.1B-Chat inference alongside KeryxHash. 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 — The 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)
• ▸ IPFS distribution for model weights (model_id = IPFS CID)
• ▸ Multi-model support (model registry on-chain)

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 — AiRequest Payload Binary Format

Offset  Size  Type    Field
------  ----  ------  -----
0       32    bytes   model_id (hash of model weights)
32       4    u32 LE  max_tokens
36       8    u64 LE  fee (sompi)
44       var  UTF-8   prompt

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

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