When Nash Designs a Planning Bureau

The allocation economics of the Primechain experiment

By Ovanes Oganisian — September 20, 2026

An Accidental Discovery

In August 2026, MidLincoln Research launched a public testnet called Primechain (PRIME). This is not another Bitcoin fork, but a blockchain redesigned from first principles: instead of a hash race, it classifies integers sequentially, one at a time (link to WhitepaperV2 and Testnet evidence). Each record proves whether the next frontier integer is prime or composite. Prime records carry Pratt certificates; composite records carry factorization evidence. Validators provide quorum finality, gossip, sync, and economic policy voting.

The project's design philosophy is explicitly labeled a "Nashian cooperative equilibrium": miners are not competitors but collaborators advancing the mathematical frontier together. The design goal is to make honest participation each participant's optimal strategy.

The idea is elegant in theory. But after a few weeks of live operation, a structural problem surfaced: the chain's advance rate is dominated by the coordination overhead of validator voting, not by arithmetic computation.

The current frontier integer is around 28,000. At today's five-digit frontier, the arithmetic work is tiny relative to the roughly two-minute observed record interval. The measured bottleneck is therefore not arithmetic throughput but the submission, voting, finalization, and synchronization cycle.

What happens in those roughly 124 seconds? A miner finds a proof, submits it to validators, validators reach 2/3 quorum, the miner syncs the chain, repeat. The arithmetic is almost instantaneous. The waiting is the bottleneck.

Two Kinds of Cost in Proof-of-Work

To understand what this bottleneck means, you first need to understand what cost it avoids.

Bitcoin's proof-of-work is a deliberately expensive mechanism. Every 10 minutes, miners worldwide compute billions of hashes; only the one meeting the target becomes a valid block. Every other hash leaves no persistent artifact.

But calling those losing hashes "useless" understates their role. The expenditure of computational work is what makes producing an alternative chain costly; Bitcoin's security derives from accumulated proof of work.

So the right framing is this: Bitcoin's cost is computational expenditure. Almost all individual hash attempts leave no persistent artifact, but collectively that expenditure is the mechanism that makes rewriting history expensive.

Primechain attempts to make the computational artifact itself useful. Factorization evidence and primality certificates persist as mathematical information. Pratt certificates recursively rely on factors of p - 1 and provide independently verifiable primality evidence.

But the measured data reveals a different kind of cost. Under the validator voting regime, a large amount of correct arithmetic work fails to secure canonical inclusion—not because it is wrong, but because it loses the coordination race. A miner may correctly factor the next composite, but quorum lands on another miner's submission, or network latency means his submission arrives after the frontier has already advanced. His proof is mathematically valid. It is denied canonical inclusion because the coordination mechanism did not process it in time.

That proof is useful in principle. A factorization remains mathematically valid and could be cached, gossiped, reused, or stored outside the canonical chain. But if the protocol does not absorb it, the proof is economically discarded.

Bitcoin discards hashes that leave no artifact; Primechain can fail to include proofs that were already useful because the allocation mechanism could not absorb them.

The Arithmetic of Coordination

To quantify this coordination cost, you need a simple calculation.

The 19,000,000th prime is approximately 358,617,589. To reach it, the chain must classify every integer from 2 to roughly 358 million—about 358 million records, of which roughly 19 million are prime and 339 million are composite.

At the current speed of 29 integers per hour, about 689 per day, about 250,000 per year, reaching 358 million integers would take approximately 1,425 years.

The absurdity of this number is not only that it is too large. It is its composition. The arithmetic itself does not require 1,425 years. The bottleneck is almost entirely at the coordination layer: every integer advance requires a validator quorum round.

As a hypothetical large-network illustration: if 100,000 miners each produced just one eligible submission per hour while the chain accepted 29 records per hour, only about 0.029% of submissions could become canonical. If each miner produced thousands of eligible submissions per hour, the fraction would be orders of magnitude smaller still.

What is definitely denied is not the arithmetic usefulness of the losing proof—a factorization remains mathematically valid and could in principle be cached or reused—but its opportunity for canonical inclusion and reward.

The Boundary of the Analogy: Why This Resembles a Planning Problem

This structure has an uncomfortable historical resonance.

The defining economic function of Soviet planning was not simply that ministries "approved" production. It was that allocation which markets normally perform through prices, profits, and decentralized exchange was substantially replaced by administrative allocation. Investment, materials, labor, output targets, and ultimately consumption were redistributed among industries, enterprises, and groups according to a plan. Material balances were a core planning instrument; ministries allocated scarce funded materials among enterprises.

Industrialization makes the mechanism especially visible. Resources were deliberately shifted from agriculture toward industry, from consumption toward investment, and toward sectors given strategic priority. Labor moved on an enormous scale from villages into industrial cities. The system could mobilize resources very rapidly—but it also had to coordinate an extraordinary number of interdependent allocations administratively.

That is where the Primechain analogy begins.

Miners produce arithmetic evidence. Validators do not produce it. But the protocol cannot simply accept every correct proof, because only one submission can occupy a particular position in the canonical chain. Validators therefore allocate a scarce resource: canonical inclusion.

Two miners may submit equally correct proofs for the same integer. Mathematics does not distinguish between them. The consensus mechanism must.

Primechain therefore selects and orders the output of decentralized miners into a single canonical ledger. The bottleneck is not the ability of miners to produce correct arithmetic. It is the capacity of the coordination mechanism to decide which correct work enters the canonical sequence.

The analogy should not be pushed too far. A three-validator blockchain is obviously not a national planned economy. But they expose the same abstract institutional problem: when decentralized production is faster than the mechanism that allocates and coordinates its output, coordination itself becomes a scarce resource.

The Limits and Possibilities of the Patch

Can this coordination cost be reduced?

Batch submission is the most direct idea. The current record format submits one integer at a time: previous_record_hash + new_record. If the format changes to previous_finalized_hash + [record_1, ..., record_K], a miner submits K consecutive integers at once, and validators vote once on the whole batch.

The cost structure becomes:

T_batch = T_quorum + K * T_verify + T_transfer + T_persist T_per_integer = T_quorum/K + T_verify + ...

If quorum round-trip latency remains approximately constant as K grows, the quorum component of coordination cost per integer approaches 1/K of its present level. That is what batch finalization proposes to test—not a guaranteed 100x gain, but an asymptotic reduction in one term of the cost equation.

But this introduces a new problem: who chooses K?

If miners choose freely, the incentive points directly toward larger K. A miner who can construct a batch of 1,000 integers captures 1,000 rewards at once. This is no longer diluting monopoly. It is converting one race into a thousand consecutive rewards. A faster miner can set a larger K and capture a larger stretch of the frontier. This is not relieving the coordination bottleneck; it is creating a race to monopolize the frontier.

A cleaner approach is a protocol-defined batch window. The protocol announces: current finalized frontier = 28,256, next batch is 28,257 to 28,356 (K=100). Miners compete to construct that exact batch, anchored to the last finalized hash. Validators verify the internal hash chain and vote to lock the batch commitment. The frontier advances to 28,357.

Here the consensus object does not need to be 100 full records, but a batch commitment: previous_finalized_hash + start_integer + end_integer + records_merkle_root + resulting_state_root + batch_hash. Validators independently verify the underlying records, derive the same commitment, then vote on the batch hash. The persistent voting-lock mechanism generalizes naturally: a validator locked on batch X in round r cannot vote on a conflicting batch Y.

The conceptual progression is clear:

Today: one arithmetic record → one consensus decision.

Batched Primechain: many arithmetic records → one consensus decision.

That is the real insight. Coordination may not be the fundamental problem. The granularity of coordination may be.

And this reframes the batching idea more precisely. Batching does not merely make the bureaucracy faster. It changes the unit being allocated: from 1 canonical slot to K canonical slots. So the deeper question becomes:

Can we increase the size of the allocation unit without concentrating the right to receive it?

Inflation and Cap: Three Paths

Batching also touches monetary design. If the chain advances faster, rewards are emitted faster. That means the coordination patch cannot be separated from the issuance rule.

Primechain's economic model faces a problem Bitcoin does not have: where is the cap?

Bitcoin's 21 million cap is hard-coded and practically unchangeable. Changing that number would require massive coordination by people who bought bitcoin precisely because "this number cannot change." Their vested interest—bitcoin's roughly trillion-dollar market capitalization—is the line of defense.

Primechain currently issues 1 million micro-units per prime. If it reaches 19 million primes, total issuance is 19 trillion micro-units. But this number is not a cap in the Bitcoin sense. The protocol can be modified. This creates a governance surface Bitcoin does not have.

Three paths are open for exploration.

Path One: deterministic hyperbolic decay. Issuance decreases as a deterministic function of prime index. The micro-units for the nth prime decline hyperbolically or exponentially, approaching zero but never reaching it. This is the closest mechanism to Bitcoin's halving, but tied to chain progress rather than time. The rule is fixed at genesis, no vote, no committee. This is the most Nashian option: the monetary rule is exogenous and non-negotiable.

The risk: if the chain stalls, as it currently does under the validator bottleneck, issuance stalls too. Miners have no income during coordination bottlenecks.

Path Two: policy voting. Like transaction costs, the number of micro-units becomes a governance variable, voted on by validators or miners. This is more flexible but introduces a political economy Bitcoin does not have: manipulability of monetary policy. The lesson of BIP 100 is that free voting allows pools to sell votes off-chain, with large pools manipulating outcomes at zero cost. BIP 105 tried to make voting costly by requiring miners voting for an increase to meet a higher difficulty target. Even so, monetary policy becomes a variable, undermining the credibility of "the rule cannot change."

Path Three: rapid advance through known primes, natural slowdown. The protocol could skip already-confirmed prime intervals, rapidly advancing to regions where arithmetic becomes harder. Prime gaps grow as ln p, so the computational cost of finding the next prime at a new frontier gradually increases. Issuance rate naturally couples to difficulty, similar to Bitcoin's difficulty adjustment.

But here is a mathematical fact: at the current frontier, arithmetic is trivial. The natural slowdown will not manifest for millions of integers. For prime gaps to significantly affect computational cost, the frontier needs to be much higher. Until then, "natural slowdown" is a flat line.

Does Nashian Cooperation Require Bureaucracy?

Back to the original question.

Nash's game theory work began with non-cooperative games and extended to cooperative games. His bargaining solution assumes rational participants using their own bargaining power, not an external arbitrator. But in cooperative games, an agreement mechanism is necessary. Participants must agree on a division of the payoff vector. This agreement requires procedure: proposal, acceptance, commitment.

Harsanyi's formalization of the Nash bargaining game explicitly describes the conflict point: if participants cannot agree on a final payoff, they are restricted to conflict strategies, meaning simple non-cooperation. Cooperation requires escaping from the conflict point, and escape requires coordination.

Primechain's validators are the embodiment of this coordination. Without validators, miners cannot cooperate in the ledger sense. They can only each submit what they believe is the correct next integer. If multiple miners submit simultaneously, whose record becomes canonical? Without an agreement procedure, there is no canonical chain. Only isolated local records.

So, does Nashian cooperation necessarily require bureaucracy? Not necessarily. But deterministic finality does require an agreement procedure. Primechain currently implements that procedure as validator quorum voting. That makes coordination visible—and measurable—as an institutional cost.

The current testnet has three validators. If the next protocol question is how to allow new validators to join, the real institutional question is: does a larger agency mean slower coordination? Classical BFT protocols generally become more communication-intensive as the validator set grows. More validators mean more messages, more geographically heterogeneous latency, and more opportunities for slow or unavailable participants to affect a round.

This does not imply that ten validators must be ten times slower than three. The actual throughput penalty depends on protocol design, topology, and implementation. But the direction is clear: more validators means more coordination overhead, unless the finality mechanism itself changes.

Layered finality—a small finalization committee plus a larger verification set—is one possible direction. Rotating quorum is another. But the fundamental tension remains: deterministic finality requires an agreement procedure, agreement has latency, and latency limits throughput.

The rest of this experiment asks whether that procedure can be redesigned.

Next Steps: A Testable Proposition

This blog is not announcing answers. It is a record of an experiment.

The core testable proposition is:

Coordination may not be the fundamental problem. The granularity of coordination may be.

If one consensus decision can safely finalize 100 or 1,000 independently verifiable arithmetic records, the cost of the same validator bureaucracy drops by one to three orders of magnitude. This is not a claim that Primechain will use K=100. It is a proposal: batch finalization is a protocol path to be tested.

The test plan is clear:

  • Run batch windows of K=10, K=100, K=1000 on the live testnet.
  • Measure actual throughput, validator CPU load, bandwidth, and failure rates.
  • Measure miner concentration: does batching increase the leader's advantage?
  • Measure the ratio of sync pause to batch construction time.
  • Let the results determine the next protocol revision.

If K=100 raises throughput from 29 integers/hour to 2,900 integers/hour—that is, if quorum round-trip latency remains approximately constant as K grows—then 1,425 years becomes 14 years. If K=1000, it becomes 1.4 years. The chain becomes practical, and the cost of the validator bureaucracy is absorbed as an acceptable constant.

If batching increases miner concentration such that one miner can monopolize large consecutive integer ranges, then batch finalization may need additional constraints: protocol-defined batch windows, competitive batch proposals, rotating construction rights, or reward rules that separate proof production from frontier ownership.

Epilogue: Lessons in Institutional Design

The deeper theme of this experiment is not blockchain.

It is an experiment in the design of coordination institutions. When a group of rational participants needs to agree on "the next correct answer," the form of the institution determines the system's speed and inclusiveness.

Bitcoin delegates allocation to competition. Nodes independently determine whether a block is valid, but two different valid blocks can temporarily compete for the same position. Bitcoin does not convene a quorum to choose between them; subsequent proof-of-work resolves the ordering by making one valid branch accumulate more work. Primechain currently resolves competing valid submissions before advancing the frontier.

Primechain currently delegates canonical inclusion to validator consensus. Soviet planning delegated a large part of economic allocation to an administrative hierarchy.

These institutions operate under very different constraints. Bitcoin's constraint is "coordinate strangers without trusting an authority." Primechain's current constraint is "select one canonical sequence from competing valid submissions." The Soviet planning system confronted a different problem: how to redistribute and coordinate resources among industries, investment priorities, and consumers without relying primarily on decentralized market allocation.

The comparison is therefore not political equivalence. It is institutional. In each case, the question is: who allocates a scarce resource, by what rule, and at what coordination cost?

Administrative systems do not necessarily fail because allocation exists; the question is how finely the center attempts to allocate. Primechain currently centrally resolves something extraordinarily granular—one integer at a time. Batching asks whether the protocol can move the granularity boundary outward.

If batch finalization succeeds, Nashian cooperative equilibrium can be achieved without building a planning bureau.

If it fails, there is a more uncomfortable conclusion: cooperation has a coordination price. Primechain makes that price unusually easy to observe, because it can be measured directly in the time between integers.

Current Opportunities and Consulting Offers

MidLincoln Opportunity

Sun in the Morning

redsunam.com · B2B2C Guided Change Platform

A route-based system that helps users navigate concrete personal change while enabling narrow themed deployments for organizations.

Current Focus Public opportunity page live. Investor access, deck requests, and product review route through MidLincoln.
View Opportunity
MidLincoln Opportunity

Prime Mining

Deep-Tech Blockchain Protocol

A deterministic prime-based blockchain architecture built around useful computation, cooperative verification, and post-quantum-oriented infrastructure.

Current Focus Frontier protocol opportunity. Public page frames the research, protocol path, raise logic, and investor fit.
View Opportunity
MidLincoln Opportunity

TradeFlow

Global Trade Finance Platform

A global invoice financing and trade finance operating platform for SMEs, counterparties, and capital partners.

Current Focus Invoice financing first, then broader cross-border trade workflows, underwriting, and capital orchestration.
View Opportunity
MidLincoln Research & Advisory

Modern Ranking Systems

Equity & Sovereign Selection Offering

Contextual ranking research and advisory for equity selection, sovereign ranking, and model-stability diagnostics under regime uncertainty.

Current Focus Research and advisory work around ranking geometry, contextual factor systems, and robust selection frameworks.
View Offering