Pearl, explained.

Start with inference: a trained AI model receives an input and produces an output. Much of the calculation involves multiplying matrices—arrays of numbers that GPUs are built to process efficiently.

Now add a blockchain. Proof of work gives participants a way to compete to add blocks through computation. Pearl’s construction aims to make eligible matrix calculations contribute to that competition while still serving the application.

This joint activity is called duplex work. The AI customer wants an answer. The miner wants a valid opportunity to extend the chain. Those are different outputs of the same proposed arrangement.

Mechanism: INT whitepaper, sections 2–3 ↗. For the analogy, follow Rafael Pass’s spork ↗.

The original integer construction begins with the matrices an application needs to multiply. It introduces structured noise tied to the inputs and chain state, performs the multiplication, and checks information from the computation against the mining condition. A correction step recovers the intended matrix product.

The details matter: the original scheme checks the computation’s intermediate trace. Simply hashing an arbitrary final answer would not implement the same construction. Its security argument depends on stated computational assumptions.

1. Prepare. Bind the inputs and chain context.
2. Compute. Run the protocol’s matrix operation.
3. Check. Look for a result satisfying the mining target.
4. Return. Serve the application result; submit a valid mining proof if one is found.

The network must accept the block before its reward counts. More work can mean more attempts; a single request is not a guaranteed payout.

Original construction paper ↗ · Explore the request-to-result walkthrough ↗

A protocol is only attractive to an inference operator if it fits the operator’s models, hardware and cost structure. Compatibility and overhead are central to the project’s transition from integer calculations toward floating-point workloads.

The supplied September 2026 Pearl Floating Point Scheme Specification describes a different construction: noise is applied before FP8 quantization, and tickets can be checked on output tiles. It should not be collapsed into the original integer scheme’s explanation.

What matters next is a documented release and reproducible evidence: which model, hardware, precision and serving conditions were tested? Those details turn a headline into something an operator can evaluate.

Floating-point specification ↗ · Read the dated statement and its source ↗ · Follow the activation record ↗

Mining is one direction of the proposed loop. The founders have also described the reverse: spending PRL on inference. That would give a user a reason to acquire the token for a service, beyond holding or transferring it.

These are separate milestones. A network can issue mining rewards without having a working PRL-denominated compute marketplace. The marketplace, payment route and settlement design need their own evidence.

Likewise, a mining certificate and proof that an entire model ran are different things. In the archived September 25 clarification, Omri described the proof-of-inference application as an L2/rollup outside L1 Pearl-GEMM mining. That statement does not by itself establish an implemented payments layer or a Simplex deployment.

Which workloads can participate? How much overhead remains in a real serving stack? What has shipped, and what is still proposed? These questions provide a better starting point than treating a promising architecture as a completed ecosystem.

For the underlying mechanism, continue into the Model investigation. For the people, explore the founders and research connections. For issuance, the next guide follows PRL’s supply schedule.