Keryx Interview: Slash on the Overlooked Cryptographic Proof-of-Model
“I’d rather someone’s first contact with Keryx be a block they can verify than a promise.”
Project: Keryx (KRX) | Interviewed by: Rowenta01 | crypto-lowcap.com
Tags: #Keryx #KRX #ProofOfModel #PoUW #AI #BlockDAG #Lowcap #Interview
| BEFORE WE START This interview does not constitute investment advice. The questions and answers reflect the views of the project team and of an independent analyst who has been covering the privacy and low-cap crypto space since 2016. Micro-cap and low-cap projects carry significant risk. Do your own research. |
Keryx is a BlockDAG built on a rusty-kaspa fork, with one design rule that changes everything else: the proof of work is the AI model itself. To produce a block under Keryx Proof-of-Model, a GPU has to hold a full open-weight model in its video memory, and it has to answer the inference requests assigned to it. Genesis was in May 2026. Within a few months the project shipped a node, a CUDA miner, desktop and mobile wallets and five served models, from Qwen3.5-9B on an 8 GB card up to Kimi-Linear-48B on a 32 GB card.
However, the project has also been through a hard summer. Between August and early September the chain went through a run of hardforks, a Proof-of-Model exploit and a relaunch. I followed that period closely, and what stayed with me was less the incidents themselves than the way they were handled: in public, quickly, and without blaming anyone else. The person handling them is Slash, founder of Keryx Labs and the visible face of almost everything the project ships.
In this written interview, Slash explains where the idea came from, who actually builds Keryx today, what Proof-of-Model proves and, just as important, what it does not, how the first split-model inference across six machines went, how emission and burn are designed, and why the project says so little in a sector that says a lot. The answers are his own; I have only grouped them by theme.
Keryx at a glance
Sources: official Keryx explorer (Coin Supply, Network Info and Market Data panels) and keryx-labs.com, snapshot September 29, 2026. Market figures move fast on thin markets; treat them as a point-in-time read, not a valuation.
1. Origins
Keryx went from genesis in May to a live product, a GPU miner, a wallet and five served models in a few months. What were you doing before this, and what made you decide a new chain was the right answer rather than contributing to an existing PoW or AI compute project?
Slash: I bought my first bitcoin around 2014-2015, and I’ve never left this space since. It still fascinates me as much as it did then. Next I bought GPUs and built my first mining rigs. You could still mine Ethereum on graphics cards back then, and it was a wonderful time.
When the Merge came, I had to find a replacement. It wasn’t easy: there were plenty of interesting projects, but none offered Ethereum’s profitability. That’s when I came across Kaspa, and it was love at first sight. I mined it with my GPUs until the ASICs arrived.
I’ve always been fascinated by artificial intelligence, and I kept wondering why no blockchain offered real on-chain AI inference, where both the request and the response go through consensus. That’s why I created Keryx.
What I wanted wasn’t a feature added to an existing project. It was the basic rule of mining. On Keryx, a miner who doesn’t run inference isn’t a miner. It’s not an option, not a module, not a second network sitting next to the first one: the proof of work itself walks the model weights loaded in VRAM. You can’t graft that onto an existing PoW chain without rewriting its consensus.
2. The person and the team
You are the visible face of nearly everything, releases, announcements, incident handling, Discord. Is that a role you wanted, or one you ended up holding because nobody else was standing there?
Slash: A bit of both, but mostly a role I wanted. If I handle all of it, it’s above all because I love it. I work on Keryx full time and I don’t count my hours. Answering a miner on Discord at midnight, shipping a fix or explaining an incident is all the same job to me: keeping the network running and staying reachable for the people who keep it alive.
The repos credit Neuropool, ocminer, Fear, izzback, rogersmitha51 and others. Are those one-off contributions, or people you can genuinely rely on for a given area? And if you went dark for a month, who ships a critical consensus fix, has anyone other than you built and released a node version end to end?
Slash: Far more than one-off contributions, and I’m very lucky to have a community this involved. On GitHub, the node has received 40 pull requests and the miner 44, from around twenty contributors on GitHub alone. That’s extraordinary, and I thank them all!
That’s how I built the team: about ten people, among those who contributed the most, each with their own area. Gryph built the first version of the desktop wallet. Dizzztroyer built the mobile wallet. Izzback helped me debug complex consensus issues. Fear improved node performance and completely redesigned the desktop wallet. Lukretsiy wrote the first Keryx miner based on llama.cpp and proposed the private inference PR. DragonKeepr optimized and redesigned the miner. Ryan contributed to both the node and the miner. CLusmi proposed and tested improvements for the HiveOS build of the miner. And Texonja found vulnerabilities in the early versions of PoM twice: he has become our integrity expert.
If I disappeared for a month, I wouldn’t be worried. The code is open source, releases are built by CI from a tag, and the team knows the node well enough to ship a critical fix without me.
3. Under the hood: what Keryx Proof-of-Model really does
The node started from rusty-kaspa. What was the deepest thing you had to change to make the model the working set of the proof of work, and what part of that fought back hardest?
Slash: The deepest change isn’t in the hash, it’s in what consensus considers a valid block. On Kaspa, a block is valid if it meets the difficulty. On Keryx, it must also carry a proof that the miner actually held the model weights when it mined, and every node that receives the block verifies that proof. The proof of work is a random walk through the weights loaded in VRAM. Its seed depends on the block being mined, so it can’t be precomputed, and only someone who really has the weights at hand can produce the result. That’s what takes the point out of an ASIC: what matters is no longer raw hashing power, but video memory and its bandwidth.
What resisted most wasn’t the computation, it was everything around a proof in a BlockDAG: initial sync, pruning, storage. A node that syncs months later can’t re-verify every proof back to genesis, so you have to decide what to keep, what to throw away, and from what point a node is allowed to trust. Almost every hardfork this summer had consequences in those layers.
Two things a reader always assumes are solved. First, what stops a miner from faking possession of the weights with a partial copy, a cache of earlier proofs or a shared remote host? Second, since GPU floating point is not bit identical across cards and drivers, how does the protocol decide that an AiResponse really came from the committed model rather than from something cheaper?
Slash: On possession: the proof isn’t a one-off check, it’s redone on every hash attempt. For each nonce, the miner walks through the weights loaded in VRAM, and every read depends on the value read just before: you can’t guess in advance where the walk will go, nor prefetch the reads. A partial copy isn’t enough: as soon as the walk hits a missing region, the attempt is lost, and a walk touches many regions. A shared remote host doesn’t work either: every read would have to make a network round trip, millions of times per second. A cache of old proofs is useless, since a proof is bound to the block header and nonce that produced it. And I can check after the fact: an off-chain tool replays a miner’s walk from the published weights and compares.
On determinism, I’ll be direct, because this is where many projects say whatever sounds good: the protocol does not verify an inference response by recomputing it. I measured it: two different cards don’t produce bit-identical output. So replaying an inference to settle a dispute doesn’t work, and I don’t build on that illusion. What is proven cryptographically is possession of the model. What is guaranteed economically is service. Mixing the two up would be lying about what the protocol does.
On the service side, part of every miner’s rewards is locked as collateral. Each request is assigned to the whole cohort of the targeted model, and whoever fails to answer takes a strike. Strikes add up: part of the collateral is burned, then all of it, and the address is suspended. This mechanism runs in production and has already suspended addresses.
That leaves the cheaper-model question. A miner could technically answer with a smaller model, but to mine it has to keep the real model loaded in VRAM anyway: the main cost is already paid, and cheating gains it almost nothing. Verifying the response itself requires bit-reproducible inference in integer arithmetic. That’s a phase 5 research topic, and I won’t present it as solved until it is.
Source: Slash’s answers in this interview, cross-checked with the protocol description on keryx-labs.com.
4. Incidents and prevention
Between August and early September you shipped hardforks from H6 through H13, then two urgent hotfixes. Your speed of correction is genuinely not in doubt. What have you changed in the process itself, testnet coverage, fuzzing, outside review, staged rollouts, so the next class of bug gets caught before mainnet rather than after? And looking back at the PoM v3 exploit, was that mistake in your own code or in the layer you inherited?
Slash: Proof-of-Model doesn’t exist in the inherited layer; I wrote it entirely. It would be convenient to blame upstream, but it would be false.
To avoid reliving past incidents, I set up a permanent testnet with its own depths, deliberately reduced so that a hardfork that would take weeks to exercise on mainnet gets exercised in hours. Gates activate there before mainnet. I also hold myself to a new rule before any consensus change: write down the structural consequences for sync, proofs and pruning. The August forks taught me that the bug is almost never in the rule you change, it’s in what that rule implies three layers down. The last two hardforks went through without incident, and that’s the only metric that matters.
5. The hard part of the roadmap
Sliced models across several miners is the most ambitious item on the roadmap: serial latency, scheduling, a slice that drops mid pipeline. Which of those do you consider solved on paper, and which one actually worries you? And practically, how does a request settle if one miner in the chain fails halfway through?
Slash: On paper, scheduling is the solved part, and it isn’t only on paper: it’s coded and it has run on testnet. When a request arrives, every miner serving a shard publishes an availability declaration on-chain. For each shard, the first one declared in chain order is chosen, and the following ones are its substitutes, in order. Nobody draws lots or arbitrates off-chain: every node sees the same list. And if a shard has no producer, the request is refused before it’s sent, so nothing is spent.
On September 21 we completed the first inferences of DeepSeek V4-Flash split into 6 shards across 6 real machines, 4 answers out of 4. But we’re at about 3 s per token, plus a minute of assembly, while lab measurements predicted 0.4 to 0.7 s per token. I can’t explain that gap yet. The next step is to instrument the pipeline head, link by link, before any new campaign. Until we’re under one second per token, the split model isn’t a sellable service, and single-GPU models remain the product.
If a miner in the chain fails midway, the plan is for the head to keep the tokens already produced and hot-swap the failed link for the next declared miner on its shard.
Source: Slash, declarative figures from the team’s first test campaign, not independently measured.
6. Usage, emission and funding
The explorer shows around 1,426 cumulative inferences since launch. How many of those would you call real usage rather than team tests and miners checking their rigs? And what number, requests per day or paying addresses, would tell you the network is genuinely being used?
Slash: Honestly, I can’t quantify it today. An on-chain request doesn’t say who sent it or why. An inference paid for by a curious user, by a miner checking their hardware or by us looks exactly the same, and I won’t put forward a percentage I can’t prove.
More importantly, that number doesn’t yet measure what Keryx is built for. Our main target isn’t humans typing a prompt into a wallet: it’s on-chain AI agents, on Ethereum and Solana first. That’s phase 6 of the roadmap: Ethereum and Solana bridges, an on-chain agent demo, and an API to query the models programmatically. Until it ships, those agents have no path to call us, so the real usage we’re aiming for can’t exist yet. Today’s inferences prove the network serves models end to end, not that it has found its customers.
The number that will tell me the network is really being used is the count of requests coming through the bridges, and above all the number of distinct contracts or agents that come back regularly. One agent that queries Keryx every day because its logic depends on it is worth more than a thousand one-off requests.
At the current reward the net supply roughly quadruples over twelve months, while burn sits near a quarter of gross emission. How much of that burn comes from real usage versus penalties, tier and holder modifiers? And since a GPU miner has electricity bills to cover, what in the design gives that miner a reason to keep KRX in the system rather than moving the daily emission out?
Slash: I don’t have the exact breakdown of the burn yet, but by design, what goes to the burn address is: all transaction fees (0.3 KRX minimum per transaction), the reward of red blocks, the gap between the base reward and the reward actually paid when the tier and holding modifiers apply, and the escrow of miners penalized for not serving the network.
As for a reason to keep KRX when you have bills to pay, there is a concrete mechanism: a miner’s reward depends on what it brings to the network, not just on its hashrate. Serving a heavier model earns a better share, and there is a reward tied to holding. A miner who empties its address every day gives up part of what it could earn.
Sources: Slash’s answers in this interview and the reward split published on keryx-labs.com.
| ROWENTA’S NOTE At the September 29 snapshot the block reward stands at 5.10 KRX, about 51 KRX per second at 10 blocks per second, so roughly 1.61 billion KRX of gross emission over twelve months at the current rate, before any burn, with halvings every four years and a main-phase cap of 9.905 billion KRX. The aggregate burn is now readable on the explorer: 152.164 M KRX destroyed against 596.955 M mined, about a quarter of gross emission, leaving roughly 444.79 M net in circulation. What is still missing is the decomposition, how much comes from transaction fees, red blocks, tier and holding modifiers, or penalized escrow. Slash says he does not have that breakdown yet, and I will not estimate it for him. One detail worth keeping in mind when reading any market figure on KRX: the explorer computes market cap on total mined rather than net of burn, which mechanically inflates it by about a quarter. |
You pulled the miner devfund in 0.5.4, so how is protocol work paid for today, self funded, a protocol R&D allocation, contributors donating hours? And roughly how long does that hold if the sector stays quiet for a year?
Slash: Yes, I completely removed the devfund from the miner in v0.5.4. Protocol work is funded by a 5% R&D allocation taken from the block reward, at the consensus level. The team and contributors also give a lot of their time. If the market stays quiet for a year, no problem: the infrastructure holds. Servers, test machines and GPU rentals for test campaigns are covered.
7. Positioning and community
If you had to explain Keryx to someone who has never mined anything and does not care about consensus, what do you actually say? And who is the person you are building for first, a GPU miner, a developer, someone who wants a model nobody can switch off?
Slash: To someone who doesn’t mine and doesn’t care about consensus, I say this: today, when you ask an AI a question, you’re asking a company. It decides what it refuses to answer, what it costs, and the day it cuts off access. Keryx is a network where machines spread across the world run the models, where nobody can decide alone to shut it down, and where every machine must constantly prove that it really holds the announced model and not a crippled version. You pay for the answer, not a subscription, and nobody stands between you and the model.
As for the target, I build in this order, and I own it. The GPU miner first, because without miners there’s neither security nor compute capacity, and because they’re the ones taking the hardware risk. Then, and this is our real target, AI agents rather than humans: autonomous programs on Ethereum or Solana that need an AI nobody can cut off or censor to make their decisions. A human can switch providers if access is cut; an on-chain agent just stops. The API and bridges of phase 6 are for them, and I’d rather open them the day there’s a network behind them that can handle their load, rather than the other way around. Humans who want a free model benefit along the way, and they can already use it today.
Decentralized AI compute is one of the loudest narratives in the sector right now, and Keryx says almost nothing. Is that deliberate, a matter of bandwidth, or a conviction that the work should speak for itself? If someone handed you a person doing communication full time for six months, what is the first thing you would put them on?
Slash: A bit of all three, but mostly deliberate. In a sector where everyone announces decentralized AI compute without ever running an inference through the chain, one more project making announcements doesn’t stand out. What stands out is showing an inference that goes through consensus: a network where you can check, block by block, which miner served which inference, which one got paid and which one got penalized. I’d rather someone’s first contact with Keryx be a block they can verify than a promise.
If I were given someone full time for six months, I’d first ask them to make this work readable. Everything is public, but today you need to know how to read a block explorer and a GitHub repo to see it. I’d want anyone to be able to follow a request end to end, from the question to the miner who served it, with the proof at every step, and for someone outside the project to be able to redo it alone. Next, I’d have them prepare the ground for AI agent developers on Ethereum and Solana, since they’re the ones phase 6 will connect: documentation, examples, and an agent demo the day the bridges arrive. Finally, I’d have them highlight the people already building Keryx: more than twenty external contributors have submitted code to the node or the miner, and that says more about the project than any announcement.
What is the Discord actually for today, support, coordination between operators, a place to hang out, and what would you want someone who mines or uses Keryx to feel part of? And since almost everything that reaches the outside comes through you, is there a plan for Keryx to have a voice that is not yours?
Slash: Today, the Discord is all of that at once: support, coordination between operators, and the place where people talk. It’s where all the information is centralized, and it’s where I found the team members and most of the contributors. One example: during the split-model test campaign, community members covered five of the six shards in two hours, from a single announcement.
What I’d like people to feel part of is a network they run themselves, not an audience being sold something. When someone mines on Keryx, their GPU serves real inferences, and when they report a bug or propose a fix, it ends up in the code.
As for a voice that isn’t mine: I’ve opened announcements to the other team members, and some have already made a few, but not as many as I’d like yet. They’re still a bit shy. That said, I don’t see it as a burden: I love taking care of the Discord, and I intend to keep doing it.
8. Reading the space, and what comes next
Outside of Keryx, which projects do you actually follow or respect right now, and what do they have in common? And on the other side, what makes you dismiss a project within five minutes of looking at it?
Slash: Outside Keryx, there are two projects I truly respect: Bitcoin and Kaspa.
Bitcoin, because it’s the benchmark: no premine, a proof of work that requires trusting no one, and extreme caution before touching consensus. Kaspa, because it’s a genuine research breakthrough that made it into production: BlockDAG and GHOSTDAG solve a problem Bitcoin left open, confirming fast without sacrificing decentralization. That’s also why Keryx is built on rusty-kaspa: we start from serious code instead of reinventing the wheel.
What they have in common: you can verify everything yourself by running a node, the work came before the announcements, and they launched without a premine.
What makes me dismiss a project in five minutes is, first, when the token exists before the product. If the document details the token economics but today you can’t run anything, neither send a request nor see a result, the project is selling a promise. Keryx did the opposite: the miner has run a model since the first block. Second signal: a repo where you can’t see the real work, with no history of fixes and no incident write-ups. A project in production that has never broken anything isn’t a project in production. Third: a network you can’t inspect yourself. If I can’t run a node and verify a claim on my own, I have no reason to believe it.
Realistically, not best case, where is Keryx a year from now, and where would you want it to be at three years? And open floor: anything I did not ask that you think matters, or anything you would want a reader to understand about Keryx that never comes across in a release note?
Slash: Realistically, in a year: the API is in place and the first bridges to Ethereum and Solana are open. An AI agent on one of those chains can send a request to Keryx and read the answer programmatically, with no wallet and no human in the loop. The first agents in production will probably be built by a handful of teams close to the project. I’m not promising volume: I’ll already be happy if a daily flow of requests from those agents exists and doesn’t fade.
In three years, what I’d like is for the question to no longer be “can you plug an agent into Keryx?” but “why haven’t you?”. For Keryx to have become a building block as ordinary as a price oracle: you call it without thinking, because the answer is reliable and nobody can censor it. And for the model it serves to have grown with the network: a model nobody can shut down, with persistent memory and access to tools.
Free space, one thing: Keryx isn’t a decentralized AI compute project in the sense the market means. Most of those projects are marketplaces: you rent a GPU off-chain and trust whatever result comes back. On Keryx, inference happens on-chain. The request is a transaction, so is the response, and consensus decides who served, who gets paid and who gets penalized. Every node on the network enforces those rules, not a company or a central server. And inference isn’t a service sold alongside the chain: it’s part of the miners’ work. To produce a block, a miner must prove it has the model loaded in memory, and it must answer the requests sent to it. A miner that doesn’t run a model isn’t a miner that earns less, it’s a miner that’s excluded. That’s the design decision everything else follows from, and it’s the one that fits least well in release notes.
Slash, founder of Keryx Labs
| Follow Keryx Website keryx-labs.com Explorer keryx-labs.com/explorer Whitepaper keryx-labs.com/whitepaper GitHub github.com/Keryx-Labs Discord discord.gg/U9eDmBUKTF X @Keryx_Labs |
Thanks to Slash for the time and the candour, and to the Keryx contributors whose work is visible in every release. If you want the analyst’s view on Keryx rather than the founder’s, my fundamental and speculative coverage of the project is on crypto-lowcap.com.
Related reading: our exclusive interview with TensorCash’s Imosuke Takakuni on proof-of-inference mining, our conversation with Midstate’s ciphernom on a post-quantum, CPU-mined chain, and our analysis of why proof-of-useful-work could finally matter.
