Pearl Whitepaper

1.1 Planned Upgrades

The core of the Pearl network is a new implementation of exact (INT) MatMul operation. As such it can be used as a drop-in replacement in applications that can be cast to this setting, e.g., inference. However, many modern AI workloads are not done natively in INT, but rather in low-precision floating-point formats (e.g., BF16 for training, and FP8 and FP4 for inference). The continued shift toward low-precision floating point is driven largely by throughput and I/O considerations: low-precision weights and activations can significantly increase tokens-per-second (TPS), a key KPI in many production systems (e.g., coding assistants). This speed/accuracy tradeoff is the essence of model quantization, and by now is a standard component of modern AI training and inference pipelines.

Extending the current PoUW scheme to floating-point datatypes is technically challenging^*Floating-point (FP) formats have a non-uniform dynamic range. As a result, even small perturbations to the input matrices (A, B) can produce disproportionately large changes in intermediate values, harming numerical stability and downstream accuracy.. Thus, in parallel to the implementation of Pearl, we have been developing a future PoUW protocol designed to address both challenges simultaneously. This future version will not preserve exact matrix multiplication. Instead, it computes a high-accuracy approximate MatMul, just like quantized multiplication works. Thus, we view it as a plug-in quantization library that simultaneously provides a PoW certificate. The key idea is to leverage native quantization noise as the perturbation mechanism needed for PoW, while forcing the miner to commit to the underlying (pre-quantization) weight and activation matrices.

A formal specification and security/accuracy analysis of the new scheme will be made public for review in a future technical article and accompanying blog post. The purpose of this subsection is to prepare the Pearl community, a priori, for a future upgrade. This upgrade is intended to (i) enable on-boarding of training workloads, and (ii) support state-of-the-art low-precision inference workloads without adaptation. We will only propose upgrading the network after we complete extensive testing of both its accuracy and its security.

3.1 High-Level Description

A central idea of our protocol is to introduce and eventually remove a carefully constructed form of noise in the matrix multiplication process, to preserve computational correctness while unifying computational hardness across all inputs. Specifically, we generate two noise matrices E and F, and add them to the input matrices A and B, respectively. The protocol then computes the product of the perturbed matrices (A+E) and (B+F), and producing a proof attesting to the correctness of this computation.

The distribution of the noise matrices E and F needs to be carefully designed.

On one hand, the product (A+E)·(B+F) should be as hard to compute as the product of two random matrices, so that an adversary cannot construct A and B in a way that simplifies the computation. This guarantees that the protocol maintains its computational hardness and that no miner can gain an unfair advantage by selecting degenerate or specially structured inputs.

On the other hand, we require that the original matrix product A·B can be efficiently and accurately recovered from the noised product (A+E)·(B+F). This recoverability condition is essential to ensure the usefulness of the computation: the final output must yield the intended matrix product, even though the proof was generated with respect to the noised version.

Hence, the protocol, details of which will be elaborated in the subsequent sections, proceeds as follows:

• Given the inputs A, B, and the blockchain state σ, generate corresponding noise matrices E and F.
• Compute the product (A+E)·(B+F), and extract from the execution trace of the matrix multiplication algorithm a cryptographic proof that constitutes a valid proof of work.
• Recover the original product A·B from the result (A+E)·(B+F) via a quick post-processing step.

3.1.1 Low-Rank Noise Paradigm

We construct E and F as random matrices of rank r, derived deterministically from a seed that is itself a cryptographic commitment to the inputs A, B, and the blockchain state σ. The use of low-rank matrices allows one to efficiently correct the noise. Given that E and F are rank-r matrices, the correction terms E·B, A·F, and E·F can each be computed using only O(n²r) scalar multiplications. Consequently, once the noised product (A+E)·(B+F) is computed, the original product A·B can be recovered via the identity:

A · B = (A + E)(B + F) − (E · B + A · F + E · F)

As long as the rank r remains small relative to the matrix dimension n, the post-processing step is asymptotically negligible compared to the main multiplication, preserving the overall efficiency of the protocol. On the other hand, the correction identity is symmetric and can be evaluated in either direction. In particular, it also enables efficient computation of (A+E)(B+F) from a known A·B and the low-rank terms E·B, A·F, and E·F. This symmetry poses a potential risk: it undermines the guarantee that miners actually performed the full matrix multiplication on the noised inputs, since one could simulate the output of (A+E)(B+F) using only a precomputed A·B and the inexpensive low-rank corrections. To eliminate this shortcut and ensure that the prescribed computation is faithfully executed, our PoW mechanism requires not only knowledge of the resulting product (A+E)(B+F), but also a proof that this product was obtained through a direct execution of a valid matrix multiplication algorithm. In essence, the miner must supply a verifiable trace of the actual computation performed on the noised matrices.

4.1 Mining Configuration

Our protocol requires the miner to set the following parameters:

• Common dimension  k.   The dimension common to both matrices A, B.
• Noise rank  r.   The rank used for the noise factors that are added and later removed.
• Tile shape   (t_m, t_n).  A periodic partition of rows of A and columns of B. For exposition, we assume A is divided into disjoint blocks of t_m consecutive rows, and B into strips of contiguous t_n columns.
• Difficulty target  b.   A fractional number of bits that defines the logarithmic acceptance probability per int8 multiply-add operation. Larger b yields fewer accepted tiles.
• Matmul-accumulate type. An identifier of the exact matmul algorithm being done. Initially, must be 0 denoting input matrices have [−64, 64] entries and matmul-accumulate being done in a int32 datatype.

4.2 MatMul Framework

Given matrices A, B to multiply, we first run our commitment hash with A, B, the mining configuration μ, and the blockchain state σ as its input; resulting in two 256-bits seeds s_A and s_B depending on A, B, μ, σ. We then generate noise matrices E := E_L·E_R, F := F_L·F_R using s_A as the seed for generating E and s_B as the seed for generating F. We compute the noised matrices A′ := A+E, B′ = B+F. We then run a MatMul algorithm on A′, B′ that works tile-by-tile and checks a block-opening condition on each computed tile. Finally, we peel off the noise and return

which we can compute quickly due to the shapes of E_L, E_R, F_L, F_R.

For protocols over 8-bit integers, we quantize both A, B to integers in [−64, 64] and the noise matrices E, F are to the range [−63, 63]. That way, the noised matrix also fits in 8-bit integers without overflows.

4.3 Commitment Hash

The noise seeds s_A, s_B, also called the commitment hashes, depend on BLAKE3 hashes H_A, H_B of A, B respectively, on the mining configuration μ, and the blockchain state σ.

H_A is computed as the BLAKE3 hash of the matrix A parsed as a row-major stream, keyed with μ and σ. H_B is computed likewise but with B parsed column-major. s_B is the hash of μ, σ, H_B while s_A is the hash of s_B, H_A.

The reasons for this choice of derivation of s_A, s_B are:

• H_A, H_B are keyed hashes of A and B to forbid preparing matrices with particularly advantageous hashes.
• A is parsed row-major while B column-major to reduce the size of the proof. A proof of block opening only involves revealing a few rows of A and columns of B. This is because BLAKE3 is a Merkle tree of the hashed data, thus only a Merkle proof for the elements involved in the computation of the winning tiles need to be revealed.
• The reason for asymmetry between the derivation of s_A, s_B in the protocol is that commonly in AI inference, the matrix B is known in advance. Hence, allowing F not depend on A allows the optimization of pre-noising B once per σ update.

4.4 Noise Matrices Generation

Seeded with the commitment hashes s_A, s_B, we generate two low-rank noise matrices E := E_L·E_R and F := F_L·F_R, where the rank of E (and F), and thus also the common dimension of E_L, E_R (and of F_L, F_R) is the chosen parameter r.

Each entry in the matrix E_L is drawn uniformly over all signed 6-bit integers, using BLAKE3 applied to a message containing the entry index and keyed with s_A as a pseudo-random generator (PRNG).

The matrix E_R, on the other hand, is a column-wise "selection" matrix in which every column has a single 1 and a single −1 in two uniformly random distinct positions, chosen by the same PRNG but with domain separation.

The matrices F_L, F_R are drawn likewise using the seed s_B but with F_L sharing the same distribution as EtR and F_R sharing the distribution of EtL.

This choice has the following features:

• E, F are of rank r, allowing for efficient peeling.
• Each entry of E and F has high entropy (6.7), forbidding significant non-useful speedups.
• Even with non-useful A = B = 0, computing all matmul tiles of E·F using identities such as:
  EF = (E_LE_R)(F_LF_R) = E_L(E_RF_LF_R) = E_L(E_RF_L)F_R,

  does not exhibit apparent speedups, as long as k ≤ O(r²).

4.5 Tiled MatMul Algorithm

We execute the standard tiled matrix multiplication algorithm by partitioning the matrices A′ and B′ into tiles of size t_m×r and r×t_n respectively. We maintain an accumulator C_i,j for each output tile, initialized to zero. For all tile indices ℓ = 0, …, ⌈k/r⌉−1 the accumulator is updated by adding the product of the corresponding input tiles:

While the matrix product is computed for all tiles, the hash state updates are restricted to full-rank tiles, where ℓ < ⌊k/r⌋. For these steps, we compute (ℓ)Xi, j   , the int32 XOR of all t_mt_n entries in the current accumulator (ℓ)Ci,j. This value updates a 512-bit state vector Mi, j, partitioned into 16 int32 elements and initialized to zero:

Upon completion, a block is effectively opened if the final hash state satisfies the difficulty condition:

where b is the blockchain difficulty target and the hash output is interpreted as a little-endian uint256.

4.6 Block Opening Proof

A block opening proof provides the verifier with all the information needed to reconstruct the candidate tile and to check both the inner and outer hash predicates. The proof must be sufficient to validate that the rows and columns used in the reconstruction indeed belong to the committed matrices, and that the claimed tile location is correct. Concretely, the proof uses the property that BLAKE3 is a Merkle tree hash and contains:

• Matrix commitments. The BLAKE3 hashes H_A and H_B of matrices A and B.
• Merkle authentication data. For both A and B:
  • – The leaf data covering the rows or columns used.
  • – The indices of these leaves within the Merkle tree.
  • – The Merkle paths needed to recompute H_A and H_B from the leaves.
• Tile metadata.
  • – The row indices in A corresponding to the opened block.
  • – The column indices in B corresponding to the opened block.
  • – The depth index identifying the opened block.
• Mining Configuration and Matrix shapes. The matmul shape (m, n, k) of A, B, as well as rank r and tile shapes t_m, t_n.

Verifier.

1. Validate Merkle proofs for the provided rows of A and columns of B against HA and HB.
2. Derive noise seeds s_a, s_b from HA, HB, the blockchain state μ, and the mining config k, r, t_m, t_n.
3. Generate the noise matrices EL, ER, FL, FR from the noise seeds.
4. Reconstruct the candidate tile Ctile from the provided noised matrix strips, at the specified position and depth.
5. Test inner hash condition on Ctile with difficulty b₁ and the outer hash with difficulty b₂.

4.7 ZK-SNARK Block Opening Proof

The Merkle/fragment-based block-opening proof described above is conceptually simple but raised two main concerns: size and privacy. Specifically, the commitments are constructed as BLAKE3 Merkle roots over the rows (for A) and columns (for B). To open a block, one must include the corresponding leaf data from the relevant row and column strips, along with their authentication paths and indices.

A simple calculation shows that for two 16384×16384 matrices with tile size 16, the proof size approaches 0.5MB, and with a tile size of 64, it grows to nearly 2MB. Storing proofs of this magnitude in blockchain headers would significantly impact scalability. In terms of privacy, these row and column strips may contain personal or proprietary information that cannot be publicly revealed, making this approach unsuitable for AI or confidential workloads.

This simultaneously compresses a multi-megabyte opening into a compact proof (kilobyte scale, depending on the backend) and preserves privacy for AI participants whose matrices contain proprietary or sensitive data.

1. Fast. These zkSNARKs rely solely on lightweight cryptographic primitives (e.g., hash functions), avoiding expensive public-key or pairing-based operations. This results in exceptionally fast proof generation and verification.
2. Post-quantum security. Hash-based SNARKs are among the most efficient and most secure known approaches for achieving post-quantum security. Their security relies solely on the hardness of cryptographic hash functions, whereas other SNARK constructions typically depend on additional, stronger algebraic assumptions (e.g., knowledge-of-exponent or elliptic-curve pairing assumptions). As a result, hash-based SNARKs remain secure even against adversaries equipped with quantum capabilities.
3. Transparent setup. These schemes do not require a trusted-setup or shared randomness. Any verifier can independently validate a proof, and no trapdoors can be embedded in the system. This property greatly simplifies deployment and enhances user trust, as trusted setups are often viewed as a major security liability.

• Direct arithmetic representation. Instead of compiling the computation from a high-level programming language into arithmetic constraints, we directly express the desired verifier circuit in Arithmetic Intermediate Representation (AIR) form. While high-level languages improve developer ergonomics, a hand-crafted AIR allows fine-grained control over constraint structure, enabling to design a more efficient system.
• Preprocessed columns. While about 2/3 of the running time of the plaintext verifier is spent on deriving the noise E, F from s_A, s_B, the zk-prover and verifier can agree on the plaintext noise, rather than zk-proving the correct derivation of it^*Observe that native plaintext execution is significantly faster than zero-knowledge proof generation. Jolt, one of the most advanced zkVMs available, is capable of proving 1.5 × 10⁶ cycles/sec on a CPU with 1.3 × 10¹¹ cycles/sec.. To this end, we extend Plonky2's AIR representation with preprocessed columns — allowing circuit reliance on public data agreed by both prover and verifier.
• Recursion. While hash-based zk-provers typically trade off proving time against proof size, recursion offers the best of both worlds: first prove the claim as fast as possible with only modest proof-size reduction, then recursively compress the proof aggressively while keeping the running time acceptable. We employ a 3-layered recursion, resulting in a final proof size below 60KB.

4.8 Supported PoW Parameters

The supported PoW protocol parameters are chosen to depict AI-relevant GPU-compatible matrix multiplications. The parameters are restricted as follows.

• m, n ≤ 2²⁴
• The common dimension k must satisfy 16r ≤ k ≤ 4r² for security of the protocol. It must also satisfy k ≤ 2¹⁶ to avoid matmul overflows, and 64 | k for commitment hash alignment.
• Each of the tile shapes t_m, t_n is specified as a 3-D arithmetic progression (S₁, S₂, S₃, L₁, L₂, L₃)
  T = { ℓ₁S₁ + ℓ₂S₂ + ℓ₃S₃ : 0 ≤ ℓ_i < L_i },
  with 1 ≤ S₁ | S₂ | S₃ and 1 ≤ L₁L₂L₃ the size of the tiles. Each tile has the form t+T = {t+ℓ : ℓ ∈ T}. A tile partially outside of the m, n boundaries is illegible for proof of work.
• The rank r is allowed from the set {2⁵, 2⁶, …, 2¹⁰}. Lower or higher ranks are not expected to be an efficient miner choice.
• Let h be the size of row tiles and w the size of the column tiles. We require h·w ≥ 32 to ensure sufficient entropy in M. Furthermore, the verifier restricts k(h+w) ≤ 222.

5.1 Block Structure

Separating the certificates keeps header format stable, yet allowing future upgrades to the certificate mechanism. We enforce a certificate size limit of 65KB.

serialized as 116 bytes. Here pouw_meta is a 32-bytes commitment (SHA-256) to the underlying PoUW witness — the public data revealed by the zkSNARK as detailed in Section 4.7. While several certificates may circulate for a single block, the pouw_meta field binds them to the same underlying useful work instance.

5.2 Addresses

Traditional cryptocurrency systems such as Bitcoin have accumulated multiple address formats over time, beginning with legacy pay-to-public-key-hash (P2PKH), followed by pay-to-script-hash (P2SH), and later SegWit variants. While each introduction was necessary for incremental upgrades, the coexistence of multiple formats today leads to fragmentation, implementation complexity, and a larger attack surface. Moreover, most legacy formats rely directly on ECDSA or Schnorr signatures, both of which face emerging risks in the presence of quantum adversaries.

Taproot, introduced via Bitcoin Improvement Proposal (BIP-341), consolidates the benefits of Schnorr signatures with a flexible script path structure. It enables uniform address representation, improved efficiency, better privacy, and a natural path toward quantum- and post-quantum–hardened upgrades in the future.

In the design of our system, we made the explicit choice to remove support for legacy address types (including ECDSA- and Schnorr-based formats) and to standardize exclusively on Taproot addresses. This decision was motivated by a combination of security, simplicity, and forward-compatibility considerations, as explained above. While this choice imposes the short-term cost of abandoning legacy address formats, it significantly strengthens the long-term resilience, security, and maintainability of the network.

Additionally, we implement the Pay-to-Merkle-Root (P2MR) output type proposed in BIP-360. P2MR functions similarly to Taproot but eliminates the quantum-vulnerable key-path spend, requiring all spends to occur via a script path and Merkle proof to minimize public key exposure.

5.3 VM and Script Extensions

Pearl employs a stack-based, non-Turing-complete virtual machine based on Bitcoin. Notably, we enable the opcode OP_CAT, which concatenates two stack items: given two byte strings a and b (with b on top of the stack), OP_CAT pops both items and pushes their concatenation:

To prevent excessive memory usage, OP_CAT is subject to strict resource bounds. The output size is capped at 520 bytes, and the operation incurs a dynamic cost of ⌈length_out/64⌉ against the tapscript budget, analogous to the fixed cost charged by OP_CHECKSIG.

5.4 Fees, Block Time, and Emissions

Let t ∈ { 0, 1, 2, … } denote the block height (i.e., the number of blocks since genesis). We target a fat but finite tail by choosing an emission rate that decays approximately like 1/t², so that the remaining supply decays like 1/t^*For intuition, normalize the total supply to 1 and consider a continuous-time emission rate e(t) = 1/t² for t ≥ 1. The cumulative allocation by time t is then t∫u = 11u²du  =  −1utu = 1 =  1 − 1/t, so the remaining supply fraction is
1 − (1 − 1/t) = 1/t..

We now normalize the curve so that (1) the basic unit of time is a single block, and (2) we match Bitcoin's approximate cumulative emissions after four years, i.e., 50%. With an expected block time of 194 seconds, four years correspond to H = ⌊4 · 365 · 24 · 60 · 60/194⌋ = 650,226 blocks. We use H as the characteristic time scale (in blocks) of the emission schedule.

Define the remaining supply fraction at block height t by

so that R(0) = 1 and R(t) → 0 as t → ∞, and R(H) = 1/2. The corresponding cumulative allocation fraction is

In terms of absolute units of supply, the cumulative allocation by block t is S · A(t).

The per-block emission is obtained by the discrete derivative of the cumulative curve, that is

with t starting at the first post-genesis block, i.e., t = 1. The actual emission is the floor of E* (t) in grains.

Aiming for responsivity and stability, we use the Weighted-Target Exponential Moving Average (WTEMA) algorithm. Recall the difficulty of a block is determined by a uint256 target, which serves as the upper bound of a mining candidate's hash to be considered valid. In WTEMA-N rule, the target of the next block is determined by the target of the current block and its solvetime t, defined as the difference between the current and parent timestamps:

Here, T is the intended solve time of 194 seconds (3:14 minutes), and τ = N·T corresponds to a characteristic decay time of τ of 7 days. Initial difficulty is set low (nbits=0x1b00ffff) in order to (i) give early miners a fair opportunity to participate before significant AI enterprise adoption increases the network hashrate, and (ii) ensure the core team has minimal resources needed to support the massive research, development and infrastructure required to continually support state-of-the-art AI architectures and hardware.

Further constraints are imposed on timestamps to limit manipulations:

• Monotonicity: A block timestamp must be later than the timestamp of its parent block. Since timestamps are encoded in seconds, the time difference must be at least 1 second.
• Reduced Future Time Limit: In order to limit timestamp manipulation, a verifier must (temporarily) not accept a block whose UTC timestamp is 5 minutes or more into the future. In Bitcoin this threshold is 120 minutes. This change assumes a lenient clock-synchronization requirement.

Tie breaking. Unlike Bitcoin, where adjacent blocks typically have identical difficulty, WTEMA may assign a distinct difficulty to each block. If nodes were to select the heaviest chain exactly as in Bitcoin, then between two competing tips with the same parent they would systematically prefer the slightly harder block with the earlier timestamp. This creates an incentive for miners to backdate timestamps, pushing difficulty above the intended target interval T. To mitigate this, when two tips have nearly equal cumulative work, nodes should break ties by the order in which the tips were received, and revert to the heaviest-tip rule only when the cumulative work differs materially. Concretely, the work-difference threshold is min(tip-work₁, tip-work₂) / 4.

6.1 The Distribution of Costs of Work

Our starting point is that the mining power in the world that is potentially available for participation in the system at any given point in time is composed of processors that have "useful work" that can be combined with mining and those that do not have such useful work. Our basic assumption is that those processors have a cost of some amount C per unit of compute, whose units we will take in this note to be USD per the equivalent of 1 hour of an H100 GPU. The assumption is that there will be a significant difference between processors without useful work whose costs will be close to the current market price of compute (which in our example will be approximately the current value of about 1.7 USD per H100-hour), and processors with useful work who will only need to pay the overhead which is a small fraction of the total compute price (which in our example will be about 10% of that number).

The following graph on the left depicts a "histogram" of the costs of all available processors where the "bump" on the left are the costs of overhead of processors with useful work, and the bump on the right is those without useful work. For ease of analysis we will take a simplified model of costs as depicted by the figure on the left where all non-useful work has a fixed cost of C (in our example C = 1.7), and all useful work (i.e. the overhead on such work) has costs τ·C (in our example, τ = 0.1). This simplified model will make all analysis below easy, but its basic implications carry over to the more general model of costs, and in fact also to even more general, "general-equilibrium" type of models.

6.2 Minting, Security, and Block Rewards

We will assume that the network allocates block rewards at some fixed rate that varies with time, i.e., that there is some fixed schedule of emissions e(t) which denotes the instantaneous rate of emission of tokens at time t. We will denote by S = ∞∫0 e(t)dt the fully diluted total supply of tokens. The units of S are "tokens" and the units of e(t) are tokens per hour. We assume that at every time t the emissions are distributed between the miners at that time, proportionally to their mining power at that time. The total amount of mining power at a given point in time may be viewed as the "security" of the system at that time since an adversary will need a majority of that computing power in order to corrupt the network.

As our running example we will take the parameters of the Pearl system (see Section 5.4): a fully diluted supply of S = 2.1 · 910 tokens with the emission rate schedule of e(t) = S · H / 2(H + t), where H = 4 years = 35040 hours is the "first halving time", i.e., after H time, half of the tokens remain unallocated, i.e. S/2 = ∞∫H e(t)dt. With this schedule, the number of tokens that remain unallocated at any time T is given by ∞∫T e(t)dt = S · H/(H + T).

6.3 Instantaneous Equilibrium

The basic equilibrium idea is that the net cost of compute devoted to mining should be equal to the value of the minted tokens. If the former is larger than the latter then the miner loses money and should use its GPUs for something better. If the latter is greater than the former then miners make significant money and we would expect more miners with more compute power to enter into the mining market. We will say that we have an instantaneous equilibrium at time t if the following equation is satisfied:

Here G(t) is the computing power devoted to mining at time t (in GPUs), D(t) is the cost of compute (units are $ per GPU per hour), p(t) is the token price (in $ per token) in time t, and e(t) is the emission rate at time t (in tokens per hour).

Before we continue our investigation under the assumption of "instantaneous equilibrium" let us pause for a second to look more closely at this assumption. Will the system necessarily reach this type of equilibrium? If the token price is too low relative to hash rate, τ·G(t)·D(t) > p(t)·e(t) then it is hard to believe that miners will keep mining. After all, they can buy the token at market prices at a lower price than their compute costs for mining, thus shrinking the mining pool. On the other hand, it is easier to imagine scenarios where the token price is significantly higher than mandated by compute costs, τ·G(t)·D(t) < p(t)·e(t). One may look at two different types of causes for such discrepancy:

1. Success: The system managed to recruit 100% of useful work so there are no new miners that can enter even though benefits > cost.
2. Marketing Failure: even though mining is beneficial, companies holding the useful work refuse to do so due to lack of trust, lack of awareness, regulation constraints, administrative overhead, or just plain delay or laziness.

It seems likely that on day 1 we will indeed have a large gap due to the second reason, since very few holders of useful work will be set up to mine Pearls while producing their useful work. So, in such cases, what keeps the token price high? The answer is obviously future expectations. If a token holder today believes that the system will succeed and that the future will see miners flocking to the system then the token price will increase immediately to reflect the expected price in the future (with appropriate discounting). This increase in token price will provide net positive utility to each miner (since now the price of tokens obtained is strictly larger than the costs of mining) and will thus attract, with time, more miners. One can model such scenarios more carefully, looking at the "future expectations multiplier" F(f) = p(t)·e(t)/(τ·G(t)·D(t)) > 1   which drives the increase in mining power.

The main point of this analysis is that it determines the momentarily relation between the token price and the mining power. The following graph depicts the hashing power (security) as a function of token price according to this instantaneous equilibrium equation, assuming the distribution of costs as above with a total of 1M GPUs of useful work and 2M GPUs of non useful work, on day 0, where e(0) = 59931 tokens/hour (as in the Pearl minting curve).

So we can see a linear relation between the mining quantity and the price that gets saturated when all useful work is used also for mining. During this stage, we are in an instantaneous equilibrium where just enough miners enter the market to equate mining costs and rewards. If the price rises further due to expectations of future growth, then new miners cannot enter the market since all useful work is exhausted (this is the first reason for not being in instantaneous equilibrium mentioned above) but miners start making higher and higher net utility as the rewards become significantly larger than the costs. In the third part of the graph, mining rewards are so high that even processors without useful work benefit by participating in mining.

Let us briefly pause to point out that in an instantaneous equilibrium, holding the price of compute, and the computing power devoted to mining, fixed, the price of the token is proportional to the overhead parameter τ — in particular, the price of the token becomes 0 if τ = 0. This is an artifact of the fact that in this simple model, we are keeping the price of the useful work (i.e., AI training or inference) fixed, as a first-order approximation. In the full-fledge general equilibrium model (to appear soon), we model the AI price as an endogenous variable (depending among other things on an AI demand curve); in equilibrium, the AI cost will decrease when computation overheads decrease — intuitively, as useful proof of work miners are also receiving tokens, they need to provide a rebate on the AI cost to stay competitive. This means that even if the computational overhead for useful mining decreases (even reaching 0), the cost-overhead τ always stays positive(and in fact grows with smaller computational overhead, as the rebate miners need to pay grows.) Let us also point out that the rebate provided by miners has an additional benefit: if the AI price decreases, the demand for it grows, which in turn leads to future growth in mining.

6.4 Token Price Appreciation

Assuming that we stay in equilibrium in the long term, we expect the token price to increase as more compute power enters the mining pool and as the emission rate decreases with time. To proceed from here, we will require some assumption on how much the computing power devoted to the mining pool grows with time:

Assumption: Pearl maintains the same fraction of world computing power as this computing power grows over time.

Before we proceed, let us take a moment to reflect on this assumption. The basic reason why we may expect this type of behavior is that everything in the model scales linearly with the absolute global computing power. In some sense, the fraction of world compute power that is willing to participate in Pearl mining (or in any other proof of useful work system) may be viewed as some "success" measure. While clearly that success level may vary over time according to the specifics of the system, its management, marketing, etc., on the average, once we have reached some kind of equilibrium, there is no reason to expect such "success" to increase or decrease.

If we further assume that the efficiency factor τ remains constant, then we we can use the equilibrium equation τ·G(t)·D(t) = p(t)·e(t) at two different times t₁ < t₂ to calculate the token appreciation between these two points in time:

where

ρ_e can be directly calculated from the emission curve: ρ_e = e(2t)/e(1t) = ((H + t2)/(H + t1))2. E.g., in the first year, between t₁ = 0 and t₂ = 8760 hours, we have 1/ρ_p = (5/4)2 ≈ 1.56, while in the tenth year, between t₁ = 87600 hours and t₂ = 96360 hours we will have 1/ρ_p = (15/14)2 ≈ 1.07.

The main part of the expected increase in token price is our expectation of the growth of ρ_G·ρ_D which is the growth of the total cost of worldwide compute. We thus get that the expected increase in token price is just slightly super-linear in the total world computing costs, where the slight super-linearity is due to ρ_e that starts at a value of 56% increase per year and decreases as the system gets more mature. This may be viewed as implying that the token value is "indexed" to the worldwide cost of useful computing (and a bit more). Again, let us emphasize, that this is under the two assumption that (a) the system remains (approximately) in instantaneous equilibrium and (b) maintains its share of world computing power.

Assuming the continuation of current trends that (more or less) double computing power annually and halve costs bi-annually, then while we remain in instantaneous equilibrium, we should expect the token value to slightly more than double bi-annually. Of course, as discussed above, part of this expected future growth may already be incorporated in today's price.