Pearl: Can AI inference and mining really be done simultaneously? | Project Introduction

Back in the years when Ethereum was still PoW, miners used consumer-grade graphics cards, and the algorithm was called Ethash. An RTX 3060 does about 48 MH/s on Ethash. Some people did wonder back then: since both mining and AI run on GPUs, could the same card mine and run models at the same time?

The idea didn't work out, because the two things are bottlenecked in different places. Ethash is memory-bandwidth-hungry, computing hashes at a fixed difficulty. AI needs tensor-core floating-point throughput and tens of GB of VRAM, with data-center cards like the H100 doing the heavy lifting. A GPU in a gaming laptop can mine, and can barely run a small model, but it can't do both well at once.

Vitalik Buterin made a call on this in 2019, saying that if you can find some kind of computation that is both useful and easy to verify, cryptocurrency mining would become a huge boon to society, but that this is probably not achievable.

Pearl claims it has done it. Vitalik's judgment from years ago is displayed prominently on Pearl's official website.

Pearl is an independent proof-of-work public chain, with a token called PRL. Miners don't repeatedly compute hashes; instead they do matrix multiplications, the kind of multiply-accumulate that every layer of a neural network performs. By design, the same GPU computation both produces blocks and issues coins, and produces verifiable AI computation.

The team has a phrase for this: "energy, data, and money in a single operation." Bitcoin binds energy and money together, AI binds energy and data together, and monetization binds data and money together. These three things have previously met two at a time; Pearl wants all three to happen at once inside a single matrix multiplication.

The PoW track has been quiet for a long time. The last batch of new public chains that people could sit down and seriously discuss basically wrapped up years ago, and the excitement since then has been in L2s, modularity, and restaking. A new PoW chain is rare in itself. Now, with a circulating market cap of $430 million, what is PRL trying to say?

What problem is it trying to solve

Bitcoin's proof of work has a peculiar feature: what miners compute has nothing to do with the real world. The same kilowatt-hour, used to run models, can produce tokens, generate images, and get work done, and many people feel that using it to mine is a bit wasteful.

The real difficulty isn't "usefulness," it's permissionlessness. Permissionless means anyone can come mine, without signing up, and no one vets qualifications. Bitcoin's security model is built on exactly this: no matter what you compute, the cost is the same. Once the work is swapped for something with real-world value, miners have an incentive to cut corners, or to pick a cheap kind of input. So the question isn't whether mining can be made useful, but whether it can be made useful while no one can cheat.

Pearl's own account is that it replaces Bitcoin's random hashing with matrix multiplication, letting GPUs treat proof-of-work as a byproduct of AI workloads. The whitepaper uses the term "2-for-1" directly. In plain terms, a batch of GPUs previously had only two destinations: either mining, burning electricity while producing coins, or running models, burning electricity while producing tokens. Pearl wants to merge these two destinations into one.

Someone has done the detailed math on this idea. Cryptography researcher Rafael Pass's paper "The Economics of Proof-of-Useful-Work" divides a machine's work into three types: pure mining, pure inference, and dual work that produces both simultaneously. Dual work is not free. The paper gives an example: when a unit of computing power does two things at once, what you get is not two units of output, but about one and a half. If the overhead is small enough and the scale at which the token is accepted by the market is large enough, the block reward is equivalent to giving the inference price a rebate, pulling in inference computing power that would otherwise not exist. This reasoning is mathematically impeccable. The trouble is that its three variables—overhead, token price, and inference demand—are none of them things Pearl can decide on its own. A footnote in the paper discloses that the author completed this work while consulting for Pearl Research Labs.

How Pearl Operates

To explain how this system works, we first need to break down the term "matrix multiplication." It was not invented by Pearl; it is a very old operation, and almost every layer in a neural network uses it.

A matrix is a table of numbers arranged in rows and columns. Two tables can be multiplied only if the number of columns in the first equals the number of rows in the second. Each cell in the result table is the sum of the products of one row from the first table and one column from the second table, multiplied element by element and then all added together. Take the smallest example: A's first row is 1 and 2, B's first column is 5 and 7, so the top-left corner of the result table is 1 times 5 plus 2 times 7, which equals 19. The remaining cells are filled in one by one according to this rule.

In an AI model, one layer of computation can be written as "input times weights." A user's sentence is cut into vectors, multiplied by that layer's weight table to get a result, then passed through a nonlinear function and handed to the next layer. The larger the model, the larger the tables, and the number of multiply-add operations in a single pass can easily run into the trillions. GPUs are built for this kind of orderly multiply-add, which is also why mining cards and AI cards are the same class of chip.

Ideally, things work like this. Someone asks a chatbot a question online, and the graphics cards on the server start running the model, performing matrix multiplication layer by layer. If this machine is equipped with Pearl's plugin and is running an open-source model it has certified, then while these multiplications produce an answer, they are also used to try their luck. After each small block is computed, a fingerprint is mixed once. If the fingerprint is small enough, a lottery ticket is won, and winning earns the block reward. On the user's side, there is no visible difference. The answer still comes, and the price may even be a bit cheaper. The same batch of multiply-adds turns into tokens on one side and coins on the other.

For this whole thing to work, the first problem that needs solving is corner-cutting. All a miner has in hand is two tables, and he first needs to knead those tables into a fingerprint and submit it. Kneading a fingerprint means taking all the numbers in the table, running them through a hash once, and compressing them into a very short string. Only after the chain has seen this fingerprint will it tell him what random numbers to mix into the tables, with the order locked down so tight that he has no time to alter the tables. Officially, this action is called adding noise — put plainly, it means mixing a bunch of random numbers into the two tables, and how much gets mixed in and where is determined by that fingerprint, leaving the miner no say in the matter.

Without the noise, there's a shortcut. Between the clean A times B and the product with random numbers mixed in, there are only three correction terms, and while these three terms are not small in magnitude, they are cheap to compute. The miner already has the clean A and B in hand, so he could simply compute the clean answer first, then add these few cheap correction terms to produce the answer with random numbers mixed in, without ever doing that big multiplication. It's like an exam question asking for 3987 times 2913, and the student has long since memorized the answer, then fiddles with a few small numbers to make it look like he worked it out seriously.

So the protocol doesn't require the miner to hand over the computed result — it only requires him to hand over the few rows of input he used, plus a proof. The verifier takes that portion, mixes in the same random numbers, recomputes only that small chunk, and checks whether the fingerprint matches. Recomputing a small chunk is cheap and sufficient to confirm he didn't cut corners. If these tables involve company weights or user data, an additional layer of zero-knowledge proof can be added to prove the computation was actually done without revealing which two tables were used.

Where things stand now

Over on Hugging Face, the pearl-ai organization has four certified models: Llama 3.3 70B, Llama 3.1 8B, Qwen3 30B, and Gemma 4 31B. Officially they're called "certified variants" — the approach isn't retraining, but recompressing the same set of weights into Pearl's quantization format so they can mine while running inference inside the plugin. The precision loss is minimal: Gemma 4 31B's MMLU dropped from 90.93 to 90.56. As of October 9, 2026, these four models' thirty-day download counts range from 195 to 6,424, with like counts of 0, 3, 5, and 6 respectively.

There's also a commercial outlet. In May 2026, Pearl partnered with Together AI to launch an endpoint running the Gemma model. According to Together's announcement, the calling price is 25% cheaper than a regular endpoint, with the difference offset by the future value of tokens.

The model was released, the code was open-sourced, and then nothing happened. In June 2026, researcher Abhinaba Basu measured this in "The Usefulness Gap in Proof-of-Useful-Work." At the time, the network's total hash rate was about 24 EH/s, equivalent to roughly 320,000 RTX 3090-class GPUs, with estimated power consumption of 112 megawatts—and useful AI compute output was zero.

The author sampled 8,012 miner work units. All the hardware was capable of inference, but in the main mining rig software, there were 4,803 strings related to matrix multiplication and 0 related to machine learning frameworks. He also wrote his own mining program that filled tables with random numbers and ran it successfully on Nvidia, AMD, CPU, and Apple chips, earning a total of 44 shares recognized by the pool. One person providing data and having a model compute results, and using the same card to mine coins, can be unified in design but are separate in actual operation.

So what is actually running on the network? According to the mining pool Kryptex's page, the network hash rate has risen to 46.37 EH/s, difficulty is 2.26 TH, block time is about 203 seconds, each block rewards 2,271.03 PRL, daily output is about 966,000 coins, and the coin price is about $1.30. In six months, the hash rate has nearly doubled, and the vast majority of that increase is still filling in random numbers. What the market is doing right now is mainly just one thing: buying cards, plugging them in, filling in random numbers, and waiting for settlement.

What's the problem

Let's imagine a cafeteria posts a notice: whoever chops enough vegetables to reach one hundred jin gets a wage. The chopping itself is real—knife skills, strength, and time all have to be spent. But the notice only checks whether you've chopped enough to reach one hundred jin; it doesn't check what vegetables you're chopping. So someone brings a cart of rotten leaves, chops enough to reach one hundred jin, and collects the wage. He really did chop vegetables, and he really did spend effort—it's just that the kitchen has no use for that pile of leaves.

Pearl is stuck right here. The protocol checks whether the table's fingerprint matches, whether the result truly equals the multiplication of two tables, and whether the work meets the difficulty. In the formal design, there is also a statistical gate specifically to block inputs that are obviously tampered with. It checks all of these. What it does not check is where these two tables came from. So miners can absolutely create two tables of random numbers themselves. The multiplication is just as hard, the fingerprint meets the standard just the same, and they can win just the same—except the computed result is something no one wants to use. The protocol only recognizes the multiplication relationship, not semantics. "Useful" here is a business problem, not a cryptographic guarantee.

This is not speculation. According to the report mentioned earlier, all the sampled machines could run models, yet there was not a single line of inference code in the mining software, and the author's own tables filled with random numbers also earned shares recognized by the pool. Currently, the network hash rate is around 45 EH/s, and the vast majority is still filling in random numbers.

The scale gap can also be viewed this way. The paper offered a counterfactual: if this design truly operated as advertised, that 24 EH/s network at the time should have been producing approximately 7.7 million GPU hours of useful AI compute per day. The paper also introduced a metric called the value destruction ratio. Pearl measured 1.0, on par with Bitcoin, while Filecoin came in at approximately 0.64.

Miners don't take inference orders not because they don't understand, but because they've run the numbers. The paper estimates that coupling an inference engine with mining would sacrifice roughly 10% to 30% of effective compute. In other words, accepting real inference work not only requires software changes and accommodating the pacing of requests, but also means eating that compute loss upfront. In years when coin prices are low, this math easily comes out negative.

So how might this be solved. The paper laid out several paths. One is to govern the source of the tables, requiring miners to use tables submitted by external customers. Pearl's official plugin and authentication model is heading in this direction — delivering models and plugins to miners, so you run inference with a real model and the multiplication conveniently mines the coin along the way. The difficulty is that it's voluntary; whether to accept still comes down to miners running their own economic calculus.

Another path is to check whether the tables look real. Real model weights and randomly filled numbers differ in their statistical signatures. But the paper itself rejected this approach — miners can simply adjust the distribution to fool the check at near-zero cost. Several other more distant paths haven't been implemented yet. Making model sources into verifiable signatures requires a public key infrastructure on the model side first. Using trusted hardware to prove data provenance requires additionally trusting chip manufacturers and would slow things down. Differentiating rewards — paying more for real data — requires having a pool of customers genuinely willing to pay first.

Pearl's developer is Pearl Research Labs. Omri Weinstein is co-founder and CEO, a title that comes from a Together AI partnership announcement. He is a researcher in complexity theory, holds a faculty position at Hebrew University, and is one of the authors of that foundational paper.

Another author, Ilan Komargodski, also appears on the Hugging Face organization member list, though whether his role is employee or advisor cannot be confirmed from public sources. Also identifiable is Erez Badash, first author of the Hawkeye paper on bitwise GPU reproduction.

Bittensor has validators score model outputs submitted by miners, with scores determined by a consensus mechanism called Yuma. io rents GPUs on demand for machine learning tasks. Pearl is betting on a narrower hypothesis — that the multiplication used for block production can itself have buyers.

It is betting that the demand for inference will become so massive that it consumes block-producing compute power. At that point, miners will figure it out for themselves: taking real orders is more cost-effective than filling in random numbers. If that demand doesn't materialize, it's just a GPU mining chain with different math—its output is homologous to AI and unrelated to any specific user's expectations.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia