MidLincoln Research Prime Coin (MRPC):

Prime Mining as Cooperative Proof-of-Work on Primechain

Ovanes Oganisian, Semion Oganisian, Yury Oganisian Updated August 10, 2026

Abstract: We present a blockchain architecture in which proof-of-work is defined by advancing the sequence of rational primes. A record is valid only if it certifies the next integer at the frontier: a prime record contains a deterministic primality certificate, while a composite record contains a signed, commit-reveal-protected factorization. In aggregate, the chain constructs an auditable classification of the integer line beginning at 2. Mining becomes a cooperative computational process: prime provers, composite proof providers, and active validators all receive deterministic allocations from newly issued prime assets. The protocol features deterministic arithmetic validation, validator-certified finality, and verification costs that remain small relative to proof generation. Wallets maintain fractional ownership of each prime using sparse holdings, enabling compact storage and mathematically grounded asset semantics without storing obsolete headline integers or dense global balance vectors. All micro-units are economically fungible, while prime labels provide immutable issuance indices. We analyze the incentive structure of this cooperative mining model using a formal game-theoretic framework. Under natural assumptions and a restricted but meaningful deviation space, honest behavior constitutes a Nash equilibrium: miners do not increase expected rewards by withholding proofs, splitting identities, attempting front-running, or delaying prime publication. The current implementation is post-quantum oriented: it uses SHA3-256 commitments and ML-DSA-65 lattice signatures for wallet, miner, and validator evidence. The design does not rely on factorization hardness for security. Composite factoring is easier under quantum computation but remains verification-neutral, preserving consensus correctness. Finally, we describe the current mainnet-candidate state of MidLincoln Research Prime Coin (MRPC), the native coin issued by the Primechain protocol: a clean launch chain, three reserve-backed validators, replay-derived validator membership, on-chain endpoint discovery, validator fee and reward pools, and hourly public status reporting. Optional extension chains, if ever added, would need to be restricted to algebraic settings with well-defined factorization and ordering rules. They may support additional forms of mathematically verifiable computation, but they would require separate proof systems rather than reusing the main chain's Pratt certificates unchanged.

Practical launch instruction: to mine MRPC today, use a Linux machine with Git, OpenSSL development headers, a C++17 compiler, and CMake 3.10 or newer. Clone the public repository, initialize submodules, build the client and mining helper tools, initialize a miner workdir against a public validator such as 192.81.209.230:8339, query the current frontier, choose a target beyond it, and run the job. Minimal command sequence:

git clone https://github.com/midlincoln/primechain.git
cd primechain
git submodule update --init
cmake -S . -B build
cmake --build build --target primechain-client -- -j2
cmake --build build --target primechain-wallet -- -j2
cmake --build build --target primechain-frontier-miner -- -j2
read -s -p "Primechain wallet passphrase: " PRIMECHAIN_WALLET_PASSPHRASE; echo
export PRIMECHAIN_WALLET_PASSPHRASE
./build/primechain-client init-workdir ~/pc-launch-miner 192.81.209.230 8339
./build/primechain-client status 192.81.209.230 8339
frontier=$(./build/primechain-client status 192.81.209.230 8339 | awk '{print $7}')
target=$((frontier + 1000))
./build/primechain-client add-mine-job ~/pc-launch-miner --target "$target"
./build/primechain-client run-jobs ~/pc-launch-miner

The read -s line stores the passphrase only in the current shell environment so repeated wallet operations do not prompt every time. Closing the terminal clears it. A miner can instead type the passphrase interactively when prompted, but long-running mining is smoother when PRIMECHAIN_WALLET_PASSPHRASE is exported for that terminal session. Mining output shows accepted prime/composite proofs, validator responses, cooldown events, lottery losses, and sync progress.

Naming and Scope

The public coin name used for launch is **MidLincoln Research Prime Coin (MRPC)**. MRPC is the native coin issued by the Primechain protocol. In this paper, **Primechain** refers to the protocol, record format, validator network, and arithmetic proof-of-work system; **MRPC** refers to the user-facing coin and its fractional prime-indexed units.

The word "Research" reflects MidLincoln Research's role as publisher and launch sponsor of a mathematically transparent protocol. It should not be read as an investment guarantee, managed fund, or promise of return. MRPC is described here as a protocol-native digital asset produced by deterministic prime/composite evidence and validator finality.

Current Implementation Snapshot

As of August 10, 2026, the running mainnet-candidate network is based on release commit 8ecb55285c26, protocol version 1, network launch-testnet-1. The live candidate validator endpoints are:

This is a mainnet-candidate public testnet. If it proves sustainable under public mining, validator operation, transaction use, and external review, the same chain is intended to become the initial mainnet. It is not an investment announcement or a claim of a finished cryptocurrency security proof. The main open questions are Sybil resistance, long-term storage economics, incentive tuning, validator decentralization, and client UX. If those conditions are not met, readers should wait for further protocol updates.

The active validator set is:

At the time of this update, all three public validators report synchronized operation through frontier 8903 with identical frontier hash 8257f7e4cb7fcb0dca42c76dfa9bcea6bea5f2b51cff0ce1044b686e63128186. This implementation snapshot is not a claim that all planned governance and slashing features are complete; it documents the state of the running candidate network described by this revision.

1. Introduction

Primechain is a record-oriented blockchain whose work is tied to a simple public task: classify the consecutive integers beginning at 2. Every accepted record advances the frontier by exactly one integer. If the next integer is prime, the record contains a verifiable primality certificate. If the next integer is composite, the record contains factorization evidence. Over time the chain becomes a signed, ordered, auditable arithmetic record: every integer from genesis to the current frontier has been classified as prime or composite.

The native coin issued by this process is MidLincoln Research Prime Coin (MRPC). Each newly mined prime creates a prime-indexed asset with fixed supply of 1,000,000 micro-units. The prime itself is an issuance label, not a price unit. A micro-unit of prime 3 and a micro-unit of prime 101 represent the same economic amount. Wallets therefore hold sparse balances across prime labels, while value remains uniform across the monetary system.

When a new prime is mined, the newly issued prime asset is allocated by the active reward schedule. In the current launch policy, 45% goes to the prime-proof provider, 45% goes to composite-proof providers, and 10% goes to the validator reward pool for the active epoch. This split reflects the two kinds of arithmetic work needed to advance the frontier: prime certificates identify new prime-indexed assets, while composite proofs certify the integers between primes and build reusable factorization evidence.

Primechain separates the system into four practical roles: miners, clients, validators, and the protocol.

Miners perform the arithmetic work. A miner watches the current frontier and tries to certify the next integer. For a composite integer, the miner supplies a divisor and cofactor; the candidate then passes through a validator-run composite lottery before it can be finalized. If the lottery loses, no composite record is accepted, the frontier does not advance, and other miners may submit evidence for the same integer. For a prime integer, the miner supplies a Pratt-style primality certificate and the record is not subject to the composite lottery gate. The current implementation prints these proofs and race outcomes directly in miner output, for example by showing a composite divisor/cofactor pair, a Pratt witness and the factorization of p - 1, or a LOTTERY_LOST line for a failed composite attempt. This makes the mining process inspectable rather than opaque.

Clients are the user-facing tools that create wallets, synchronize a local proof store, submit mining work, send transactions, and inspect chain state. A client is not trusted by consensus. Anyone can rewrite a client or build a different interface. Consensus safety comes from the protocol rules enforced by validators and by replay verification, not from the behavior of the reference command-line client. This distinction matters: the client may improve its user experience, retry behavior, validator selection, and output formatting without changing the chain rules.

Validators run the server side of the network. A validator accepts signed protocol messages from miners and wallets, checks them against the current frontier, gossips useful evidence to peers, and signs finalized records when the evidence is valid. Validators do not decide which integers are prime or composite by opinion. They verify arithmetic, signatures, replay state, validator membership, reserve locks, endpoint records, and the current quorum rule. A record is final when the active validator quorum signs the same candidate for the same frontier position.

A validator operator may also run ordinary mining clients, but those miners are not trusted because of the validator's identity. They must submit the same arithmetic proofs, signatures, and frontier-targeted records as any other miner. Validator admission is separately constrained by proven work or sponsorship, public endpoint evidence, and an on-chain reserve lock. This allows validators to participate economically while keeping validation authority tied to replay-derived membership and reserve-backed operation.

The protocol defines the rules that all honest implementations must follow. It specifies record format, canonical hashing, proof validation, transaction validation, sparse holdings, reward allocation, validator admission, endpoint discovery, and finality. The protocol is intentionally deterministic: given the same chain history, every node should derive the same frontier, balances, validator set, fee pools, reward pools, and reserve locks.

1.1 Frontier Records

The chain has one active frontier integer F. The only valid next record targets F + 1. This rule gives Primechain its simplest consensus invariant: the chain cannot skip an integer and cannot mine records out of order. A proposal for F + 2 is invalid until F + 1 has been classified and finalized.

A prime record proves that F + 1 is prime. In the current implementation, prime records use Pratt-style certificates. A Pratt certificate gives a recursively checkable proof of primality by showing a witness and the factorization of p - 1. Because the chain also stores composite factorization evidence, a verifier can recursively decompose on-chain composite numbers into prime factors and check the proof dependencies needed by Pratt verification.

A composite record proves that F + 1 is composite. It stores a divisor and cofactor satisfying:

m = d * e, with 1 < d < m and 1 < e < m

This proof is cheap to verify and useful permanently. It is not thrown away after the record is accepted. The chain accumulates reusable factorization evidence for all certified composite frontier integers.

1.2 Miners and Mining Work

A miner does not search for an arbitrary block hash. It attempts to certify the exact next integer. When the integer is visibly composite, the work may be simple: an even integer can be certified by divisor 2, and many composites are found by small divisor tests. When the integer is prime, the miner must construct and submit a primality proof.

Mining is competitive in timing but cooperative in output. Only one canonical record can occupy a frontier position, but all accepted work contributes to the public arithmetic ledger. Prime providers receive the prime-provider allocation for newly issued prime assets. Composite providers receive the composite-provider allocation according to the active reward rules. Validators receive the validator reward allocation and transaction fees through deterministic pool addresses.

The reference miner maintains a local proof store, selects a validator endpoint, checks the live mining view, submits evidence, and synchronizes when another miner wins a race. Expected race conditions can occur when several miners submit evidence for the same next integer. These conditions are not consensus failures. They are ordinary competition around a deterministic frontier.

1.3 Validators and Finality

Validators provide the server-side coordination layer. Each validator runs a public TCP service for the launch network, maintains a local record store, discovers active validator endpoints from chain state, gossips records and coordination messages, and answers client queries such as status, sync, validator registry, mining view, and wallet-related state.

Validator authority is replay-derived. A validator must appear in the active validator set produced by chain history. Admission depends on on-chain application evidence, endpoint evidence, work history or sponsorship, reserve locking, and activation by validator epoch transition. The current network uses a quorum rule derived from the active validator count, not a hard-coded single topology.

Finality is explicit. Validators sign candidate records after checking the previous hash, frontier integer, arithmetic proof, provider signature, transactions, governance events, and replay-derived state transitions. A finalized record carries validator evidence sufficient for the active quorum. This differs from longest-chain probabilistic finality: a Primechain record is accepted because validators signed a specific arithmetic state transition.

The validator model is Nashian only in a limited and precise sense. Nash's late writing on Ideal Money emphasized monetary quality, predictable value, and the importance of reliable institutions for long-term exchange. Primechain does not claim that Nash anticipated blockchain validators. Rather, it applies a related design principle: monetary reliability should come from transparent rules that constrain discretion. Validators in Primechain are therefore not central issuers. They are protocol-bound participants that verify arithmetic proofs, replay state, and sign records only when deterministic validity rules are satisfied.

There is also a useful historical joke here. The Soviet socialist experiment tried to distribute wealth evenly and produced a growing bureaucracy around that task. Primechain's reward split can look superficially "socialist" next to Bitcoin's winner-take-all mining, while Bitcoin can look like right-wing republican capitalism by comparison. But that is only a joke, not the theory. Nash was not arguing for socialism; his work points toward competitive markets, exchange, stable monetary standards, and incentive-compatible behavior. Primechain's cooperative rewards are meant to make honest arithmetic contribution rational in a competitive network, not to replace markets with administrative allocation.

Relevant Nash sources for this framing include his 2002 essay Ideal Money, his 2009 work Ideal Money and Asymptotically Ideal Money, and his 2011 Lindau lecture Ideal Money and the Motivation of Savings and Thrift.

A second analogy is the layered structure of United States banking. The Federal Reserve is not a single retail bank; it is a system with a central board, regional Federal Reserve Banks, and regulated local banks that create much of the circulating money through lending inside a rule-bound banking framework. Primechain has a loose structural resemblance: the protocol is the rule system, validators are the regional coordination layer, and miners and wallets are the local economic participants that create and move protocol-native money by submitting valid work and transactions. The analogy is not legal or institutional. Primechain has no central bank and no discretionary issuer. The useful comparison is only the layered delegation of authority: money is produced at the edge, while higher layers validate, settle, and constrain the process.

Chapter 2 — Validators, Voting, Gossip, Lottery, and Sync

Primechain validators are the server-side settlement layer of the network. They do not mine by themselves and they do not create money by decree. Their job is to enforce the protocol around work submitted by miners and transactions submitted by wallets. A validator checks arithmetic proofs, signatures, replay-derived balances, reserve locks, validator membership, endpoint records, and quorum evidence. When the evidence is valid, validators sign the next frontier record and gossip the result to their peers.

The validator layer exists because the chain is not a probabilistic longest-chain system. Primechain has one valid next integer at the frontier. The question is not which branch accumulated more hash power, but whether the next integer has been correctly classified and whether the active validator quorum signed the same state transition. Finality is therefore explicit: a record is final when it contains enough validator signatures for the active validator set.

2.1 Fixed Protocol Rules

Several rules are fixed by the protocol rather than chosen by a client, miner, or validator operator:

  1. The next record must target exactly the next frontier integer.
  2. A prime record must carry a verifiable primality certificate for that integer.
  3. A composite record must carry valid factorization evidence for that integer.
  4. The previous hash must match the current frontier record hash.
  5. Transactions must replay cleanly against current sparse wallet state.
  6. Validator membership must be derived from accepted chain history.
  7. Finality requires a quorum computed from the active validator count.
  8. A finalized record becomes part of the replay history and constrains every later record.

These are not user-interface rules. A miner can rewrite the client, but it cannot make validators accept a skipped integer, an invalid Pratt proof, a wrong divisor, a double spend, or a record signed by the wrong validator set. The protocol is strict so that clients can be flexible.

2.2 Validator Voting

Validator voting is the act of signing a specific candidate record or coordination message for a specific frontier position. A vote is meaningful only when it binds enough context to prevent reuse in another situation: the target integer, previous record hash, candidate hash, round or phase when applicable, and validator identity.

For prime records, voting is direct. A miner submits a signed prime proof. The validator verifies the proof, checks the current frontier, builds the candidate record, and signs it if valid. Other validators independently perform the same checks. Once the record has validator signatures satisfying quorum, it can be accepted and replayed.

For composite records, voting is also direct. A miner submits a signed divisor/cofactor proof for the next frontier integer. The validator checks that the factorization is correct, that the provider signature is valid, and that the submission targets the validator's current frontier. If it is the first valid submission the validator observes for that frontier position, the validator signs that candidate. Other validators do the same from their own verified view. A composite record becomes final only when the same candidate gathers the required validator quorum.

The quorum formula is computed from the active validator count. It is not hard-coded as a special case for three machines. The conservative launch rule is:

quorum(n) = ceil(2n / 3)

For one validator this requires one signature. For two validators this requires two signatures. For three validators this requires two signatures. For four validators this requires three signatures. For larger validator sets the same formula applies. This is the system's democracy rule: validators do not vote by stake weight or by local preference; every active validator identity contributes one vote, and the required threshold is derived from the active set.

2.3 One-Record Winner Cooldown

Primechain also uses a small fairness rule at the frontier: the miner that submitted the accepted record for integer m is not eligible to submit the record for m + 1. This is a one-record cooldown, not a ban and not a reduction of the miner's existing rewards. It exists because the winning miner often has the freshest local proof store and fastest view of the next frontier. Without a cooldown, one miner can turn a temporary lead into a long run of consecutive wins, especially in a small launch network.

The rule is intentionally minimal. Once some other miner advances m + 1, the original miner is eligible again at m + 2. If miner A submits a composite record at m, miner A cannot submit m + 1. But if another miner submits the next prime at m + 1, miner A may submit the next composite at m + 2. If another miner then submits the next prime at m + 3, miner A may again submit the next composite at m + 4. The cooldown blocks only consecutive wins by the same provider; it does not block alternating participation across prime and composite records.

The joke version is that Primechain adds one tiny piece of bureaucracy to prevent the strongest miner from eating every next record. The Soviet experiment grew a vast bureaucracy trying to distribute wealth evenly. Primechain's version is deliberately much smaller: after you win, wait one integer. The serious reason is market fairness, not central planning. The rule keeps competition open while preserving deterministic validation.

2.4 Byzantine Resistance and Operator Coordination

The validator quorum is aimed at Byzantine attack resistance. The network should continue to reject invalid records even if some validator software instances are offline, delayed, misconfigured, or controlled by an adversary. Quorum voting makes one validator's signature insufficient: a record must gather enough independent validator signatures over the same candidate and frontier state before it becomes final.

This technical design still requires human and institutional work during launch. A small validator network is only as independent as the people and organizations operating it. The foundation must recruit and coordinate validator owners, document operating expectations, maintain public communication channels, and establish agreements about uptime, upgrades, incident response, key custody, endpoint publication, reserve policy, and removal or replacement of failed validators.

The goal is to move from trusted launch coordination toward rule-bound independent operation. Early validators need meetings, procedures, and explicit agreements because the network is small. The long-term protocol direction is to make those agreements increasingly mechanical: validator admission, endpoint discovery, quorum rules, rewards, reserves, and eventually removal or slashing should be visible in replay-derived chain state rather than handled informally.

2.5 What a Validator Is Allowed to Sign

A validator should sign only evidence that passes deterministic validation. In practical terms, before signing a record candidate it checks:

This makes validators closer to auditors than issuers. They do not need to trust the miner, the client, or another validator's database. They verify the proposed transition from replay-derived state.

2.6 Validator Admission

Validator authority is not configured manually forever. It is derived from accepted chain history. A candidate becomes eligible through objective evidence visible on-chain and then becomes active only after an epoch transition approved by the current validator set.

Admission uses several pieces of evidence:

The work-binding mechanism lets a miner sponsor a validator candidate without forcing the validator wallet and mining wallet to be the same key. This is important operationally. A validator can use a hardened server wallet while the miner wallet that earned work history remains separate.

A validator operator may also mine, but mining by a validator is not privileged. The miner still has to submit valid arithmetic evidence and compete under the same rules as everyone else. The reserve and admission checks establish validator responsibility; they do not exempt the operator from proof requirements.

2.7 Gossip

Validators gossip information so that every validator can reconstruct the same useful view of the network. Gossip carries accepted records, peer information, transactions, validator endpoint updates, applications, epoch votes, and in-flight voting evidence. The purpose is not to make one validator trust another blindly. The purpose is to spread signed evidence quickly enough that each validator can verify it locally.

A validator receiving gossip treats it as untrusted input. It checks signatures, target integers, previous hashes, message types, and replay state before storing or relaying anything. Bad or stale messages can be rejected without changing consensus state. Useful messages are persisted or forwarded so that another validator can complete the same verification.

Ordering matters in distributed systems. A validator may hear about a vote before it hears about the record or supporting evidence that vote refers to. The implementation therefore keeps sidecar stores for in-flight material such as finalization votes, round-change evidence, endpoint updates, peer state, and validator epoch votes. These sidecars are not a second chain. They are temporary and recovery-oriented caches that help the node survive restarts and gossip arriving in an imperfect order.

Longer term, gossip should become more self-contained: votes should carry or reference the exact evidence bundle needed to reconstruct the voted snapshot. That would reduce dependence on gossip ordering and make recovery from partial network views more robust.

2.8 Composite Lottery

Composite records need an additional fairness step because composites are often cheap to certify once the next frontier integer is known. Without a lottery, the miner with the freshest local chain copy can use several wallet addresses to submit consecutive composite records before other miners have time to compete. A one-record provider cooldown helps, but by itself it can be bypassed by alternating wallets.

The current protocol therefore gates composite records through a validator-run lottery. The miner still has to submit a valid divisor/cofactor proof for the exact next integer. The assigned validator then runs a lottery round for that composite candidate. If the lottery wins, the validator signs lottery evidence and the composite candidate can proceed to finalization. If the lottery loses, no record is accepted for that integer, the frontier remains unchanged, and other miners may submit the same composite integer in a later round.

This lottery applies only to composites. Prime records still advance directly when the Pratt-style proof and signatures are valid. That distinction is intentional: primes issue new prime-indexed assets and require stronger arithmetic evidence, while many composites can be certified by very small divisors. The lottery is therefore a fairness gate around easy composite advancement, not a replacement for arithmetic validation.

The reference miner reports this behavior explicitly. A successful composite prints COMPOSITE_ACCEPTED and the corresponding PROOF_COMPOSITE divisor/cofactor. A failed lottery round prints LOTTERY_LOST, including the target integer, provider address, and reason. This output is not itself consensus state; the durable chain still contains only accepted records. The purpose is operational transparency: miners can distinguish cooldown, stale work, sync, accepted records, and composite lottery losses.

The lottery can be understood as a small probabilistic gate around composite work. The candidate already contains the target integer, previous hash, provider address, divisor/cofactor proof, nonce, and provider signature. The assigned validator runs a lottery round over that candidate context and signs lottery-win evidence only when the draw is below the configured win threshold. If the draw fails, the validator returns a loss response instead of signing, and validators cannot finalize that composite candidate. In hash-puzzle terms, the rule is equivalent to asking whether a candidate-specific draw falls under a target; lowering the target makes wins rarer and gives competing miners more time to submit the same frontier integer.

The current launch tuning is 5000 basis points, or roughly a 50% composite win chance per lottery round. This is deliberately easy while the network is small. Later, validators may vote or upgrade policy to use a smaller win percentage if the chain advances too quickly or if dominant miners still capture too many composites. Lowering the win percentage slows composite advancement and increases fairness pressure, but it also makes the chain more patient and less lively, so this parameter should be changed carefully.

2.9 Sync Between Validators

A validator maintains a local record store and periodically compares itself with known peers. If a peer has a higher frontier, the validator downloads missing records and verifies them before accepting them. Sync is therefore not copying a database. It is replaying signed records from another endpoint and checking that every record is valid under the protocol.

The current validator server has two sync paths:

  1. Startup sync: when a validator process starts, it contacts configured bootstrap peers and attempts to catch up before serving traffic.
  2. Background sync: while running, the validator periodically checks known peers and downloads missing records when another validator is ahead.

Peers are learned from configuration, direct peer commands, and on-chain validator endpoint records. Once validator endpoints are on-chain, nodes can discover active validator addresses from replay state rather than from a hard-coded local list. This is why admission and endpoint events matter: they turn validator discovery into chain-derived state.

Sync also protects miners. A client may be connected to a validator that is a few records behind another validator. The reference client now checks validator frontiers and syncs its local proof store when it detects that the selected validator has moved ahead. This avoids mining against stale local proof data and reduces false errors such as missing Pratt proof dependencies.

2.10 Client Queries and Validator Selection

A client can ask validators for status, mining view, chain records, mempool state, validator registry, endpoint information, and wallet nonces. These are queries, not consensus decisions. The client uses them to decide where to submit work and when to synchronize.

In a small launch network, miner success can depend heavily on which validator it talks to. If one validator is slightly ahead, a miner connected to a lagging validator may spend time submitting work for an already-settled frontier. The reference client therefore treats validator choice as an operational problem: it can query known validators, prefer a validator with the highest visible frontier, and resynchronize when it sees that its local proof store is behind.

This behavior improves mining efficiency, but it does not change consensus. A custom client may use different retry timing or endpoint selection. It still cannot produce accepted records unless validators verify the same protocol-valid evidence.

2.11 Failure and Recovery

Expected network failures include delayed gossip, stale validator views, duplicate records, race-lost submissions, validators restarting, and clients mining from a proof store that is behind the network frontier. These failures should not corrupt the chain. They should either resolve through sync or be rejected as invalid input.

The durable recovery rule is simple: replay accepted records from genesis or from a trusted verified checkpoint. Sidecar files may help a validator finish in-flight coordination after a restart, but accepted records are the authority. If a sidecar is stale or inconsistent, the validator should be able to discard or rebuild it from durable records and fresh peer evidence.

This is why public diagnostics are important. Commands such as network doctor, version checks, board reports, validator registry queries, mining views, and wallet summaries let operators distinguish real consensus failures from normal race behavior. A healthy validator network should show matching frontier hashes across active validators, matching software versions, visible peer links, and replay-derived validator participation evidence.

2.12 Summary

Primechain validators are a quorum-based settlement layer for deterministic arithmetic work. Miners create evidence; clients submit and inspect it; validators verify, vote, gossip, sync, and finalize. Authority comes from replay-derived validator membership and fixed protocol rules, not from a single server or a trusted client. The result is a chain whose monetary issuance and record finality are both tied to verifiable arithmetic and explicit validator evidence.

Chapter 3 — Protocol Surface and Launch Commands

Primechain is intentionally simple at the protocol boundary. Validators expose a small line-oriented TCP command interface. Clients and scripts use that interface to submit signed evidence, query chain state, synchronize records, inspect validator membership, and produce public launch diagnostics. This chapter describes the practical command surface that exists today and how it relates to the protocol.

The important distinction is between protocol commands and convenience tools. A protocol command is a message accepted by a validator server, such as GET_STATUS, SUBMIT_SIGNED_PRIME, or GET_RECORD_RANGE. A convenience tool is a local client command or shell script that formats those protocol messages for humans, such as primechain-client run-jobs, primechain-client wallet-history, or primechain-ops doctor-network. The protocol must remain deterministic and strict; convenience tools can become friendlier without changing consensus.

3.1 Validator Query Commands

Validators answer read-only queries so miners, wallets, operators, and public dashboards can observe the network. The current implementation includes:

GET_STATUS
GET_VERSION
GET_VALIDATORS
GET_VALIDATOR_EPOCH
GET_VALIDATOR_ENDPOINTS
GET_ECONOMIC_POLICY
GET_MINING_VIEW [integer]
GET_RECORD <integer>
GET_RECORD_RANGE <start> <end>
GET_PEERS
GET_PEER_HEALTH
GET_PEER_STATE
GET_MEMPOOL
GET_MEMPOOL_SUMMARY
GET_BALANCE <address>
GET_NONCE <address>

These commands are deliberately close to the operational needs of a Bitcoin-style public launch. GET_STATUS gives the frontier and current hash. GET_VERSION lets operators confirm every validator is running the same build. GET_RECORD and GET_RECORD_RANGE let clients download and verify the chain. GET_MEMPOOL and GET_MEMPOOL_SUMMARY expose pending transactions. GET_BALANCE and GET_NONCE support wallet state. GET_MINING_VIEW tells a miner what the validator currently sees at the next frontier so the miner can avoid working against stale state.

Validator and governance queries expose the replay-derived validator layer:

GET_VALIDATOR_APPLICATIONS
GET_VALIDATOR_WORK_BINDINGS
GET_EPOCH_VOTES
GET_POLICY_VOTES
GET_COMMITMENTS <integer>
GET_COMMIT_WINNER <integer>
GET_COMMIT_PHASE <integer>
GET_PHASE_VOTES <integer>

Some of these commands are operational diagnostics rather than user-facing product features. They were added because a real launch network needs visibility: when validators disagree, lag, restart, or reject work, operators need to see what each validator knows.

3.2 Validator Submission Commands

Validators accept signed submissions that may change network state if valid. The main submission families are:

SUBMIT_TX <signed_transaction>
SUBMIT_SIGNED_PRIME <prime_proof_and_signature>
SUBMIT_SIGNED_REVEAL <composite_proof_and_signature>
SUBMIT_RECORD <serialized_record>

The validator also accepts internal or peer-propagated forms of several messages:

SUBMIT_SIGNED_PRIME_PEER
SUBMIT_SIGNED_REVEAL_PEER
SUBMIT_SIGNED_COMMIT
SUBMIT_SIGNED_COMMIT_PEER
SUBMIT_PHASE_VOTE
SUBMIT_PHASE_VOTE_PEER
SUBMIT_PHASE_VOTE_BUNDLE
SUBMIT_PHASE_VOTE_BUNDLE_PEER
SUBMIT_EPOCH_VOTE
SUBMIT_EPOCH_VOTE_PEER
SUBMIT_POLICY_VOTE
SUBMIT_POLICY_VOTE_PEER
SUBMIT_VALIDATOR_APPLICATION
SUBMIT_VALIDATOR_APPLICATION_PEER
SUBMIT_VALIDATOR_WORK_BINDING
SUBMIT_VALIDATOR_WORK_BINDING_PEER
SUBMIT_VALIDATOR_ENDPOINT
SUBMIT_VALIDATOR_ENDPOINT_PEER

The _PEER suffix is not a different consensus rule. It marks gossip from another validator or peer path so the receiving node can validate, store, and relay it appropriately. The durable rule remains the same: invalid evidence is rejected; valid evidence may be stored, gossiped, or included in a finalized record.

Older direct commands such as SUBMIT_PRIME, SUBMIT_COMPOSITE, SUBMIT_COMMIT, and SUBMIT_COMPOSITE_REVEAL exist in the codebase for development history, compatibility, or disabled modes. The public launch path uses signed messages. The signature is what binds work to the provider wallet and lets validators vote that this provider submitted valid work for this frontier.

3.3 Mining Commands in the Reference Client

The reference client wraps validator commands into ordinary operator commands. A miner can initialize a local work directory, synchronize a proof store, add a mining target, and run jobs:

primechain-client init-workdir <workdir> [host port]
primechain-client sync-peer <workdir> [host port]
primechain-client add-mine-job <workdir> --target <integer>
primechain-client run-jobs <workdir>
primechain-client clear-job <workdir>
primechain-client job-status <workdir>

The mining loop does three practical things. First, it keeps the local record store synchronized with the validator network. Second, it constructs the proof needed for the exact next frontier integer. Third, it submits the signed proof to a validator and reacts to the response. If another miner already advanced the frontier, the client synchronizes and tries again at the new frontier.

The current client also prints proof details directly in mining output. For composites it prints lines such as:

PROOF_COMPOSITE integer=6700 divisor=2 cofactor=3350

For primes it prints lines such as:

PROOF_PRATT prime=6701 witness=2 factors_p_minus_1=2^2,5^2,67^1

This output is intentionally plain. It shows that the miner is not doing opaque hash grinding. It is classifying integers and producing evidence that another implementation can verify.

3.4 Minimal Proof Generation Today

The current implementation uses minimal proof construction. For composite integers, the miner first tries straightforward divisor search. Many frontier integers are certified immediately by small divisors such as 2, 3, 5, 7, or 11. Once a nontrivial divisor is found, the proof is simply:

m = d * e, with 1 < d < m and 1 < e < m

For prime integers, the current implementation builds Pratt-style certificates. A Pratt proof gives a recursively checkable primality certificate using a witness and the factorization of p - 1. The chain's composite records are useful here because they store factorization evidence; a verifier can recursively decompose on-chain composites down to prime factors and check the dependencies needed by a Pratt certificate.

This is enough for the present launch scale. The system is not yet using a large menu of advanced certificate algorithms. Later implementations can add other deterministic prime certificate formats, including ECPP, Pocklington-style certificates, or other elliptic-curve and recursively verifiable certificate systems. Those additions should be treated as protocol extensions only if validators are upgraded to verify the new certificate type deterministically.

3.5 Wallet and Transaction Commands

The client includes wallet and transaction inspection commands so users can operate the chain without a block explorer:

primechain-client new-miner <wallet-file>
primechain-client address <wallet-file>
primechain-client balance <record-store> <wallet-file>
primechain-client balances <workdir>
primechain-client wallet-history <record-store> <wallet-file> [--last count]
primechain-client wallet-pending <host> <port> <wallet-file>
primechain-client address-report <record-store> <address> [--last count]
primechain-client tx <record-store> <tx-hash>
primechain-send ...

Transactions are submitted to validators through SUBMIT_TX. Validators check signatures, nonces, inputs, outputs, transfer fees, and sparse holdings before accepting a transaction into the mempool or into a record. GET_NONCE, GET_MEMPOOL, and GET_MEMPOOL_SUMMARY exist so wallets can see whether pending transactions are visible and what nonce should be used next.

This is part of the Bitcoin-launch analogy. A public chain needs more than mining: users need addresses, balances, transaction lookup, pending transaction visibility, and reproducible local reports.

3.6 Chain Inspection and Reports

The reference client includes local inspection commands for replayed chain data:

primechain-client inspect <record-store> [integer]
primechain-client inspect <record-store> --range <start> <end>
primechain-client decode-record <record-store> <integer>
primechain-client record <record-store> <integer>
primechain-client latest-records <record-store> [--last count]
primechain-client board-report <record-store> --from <integer> --to <integer>
primechain-client launch-report <record-store>

These commands make the chain auditable from ordinary files. A user can inspect a record, decode its proof, list recent records, produce a board report showing prime and composite participation, and verify validator evidence over a range. This is not a separate indexer requirement. It is a local replay and reporting layer over the accepted record store.

Validator-specific local reports include:

primechain-client validator-registry <record-store>
primechain-client validator-endpoints <record-store>
primechain-client validator-reputation <record-store> <address>
primechain-client validator-eligibility <record-store> <address> --reserve <micro-units|auto> --observed <ok> --total <count>
primechain-client validator-reserve <record-store> <validator-address>
primechain-client economic-policy <record-store>
primechain-client fee-pool <record-store> [epoch]
primechain-client validator-reward-pool <record-store> [epoch]
primechain-client fee-distribution-status <record-store> [interval-records]
primechain-client validator-reward-distribution-status <record-store> [interval-primes]

These reports were added to make validator admission, reserves, fee pools, reward pools, and policy state visible from replay. They support public transparency without requiring trust in a website.

3.7 Launch Operations Scripts

The primechain-ops script groups common launch checks into commands that resemble the operational tooling around mature chains. Important examples include:

primechain-ops doctor-network
primechain-ops version-network
primechain-ops mempool-network
primechain-ops release-check
primechain-ops wallet-summary
primechain-ops chain-doctor

doctor-network checks whether validators agree on frontier and hash, whether peers are visible, and whether endpoint discovery is working. version-network checks that each validator reports the same protocol build. mempool-network checks transaction propagation. release-check runs a combined pre-launch report across versions, network health, mempool, local chain replay, fee distribution, and launch summary. wallet-summary prints a user's wallet address, holdings, chain frontier, and live nonce.

The purpose is practical. Bitcoin did not become usable merely by having a block format; it also grew explorers, node checks, mempool visibility, release checks, wallet commands, and operational runbooks. Primechain's launch tooling is a minimal version of that same public infrastructure.

3.8 Factorization and Pratt Helper Commands

The client exposes simple arithmetic helpers:

primechain-client is-prime <n>
primechain-client divisor <n>
primechain-client factor <record-store> <n>
primechain-client pratt <record-store> <prime>
primechain-client factor-workdir <workdir> <n>
primechain-client pratt-workdir <workdir> <prime>

These are intentionally modest. divisor finds a nontrivial divisor when one is available. factor uses local chain evidence and direct factoring logic to decompose a number. pratt constructs or checks Pratt-style evidence against the local proof store. The current system is built around simple, inspectable arithmetic rather than sophisticated proof markets.

Future proof engines can be added behind the same protocol idea: a miner produces a certificate, validators verify it deterministically, and accepted records preserve enough evidence for replay. The first implementation chooses simplicity because the early chain is small and because simple proofs are easier to audit.

3.9 Summary

The current Primechain protocol is small, direct, and operationally transparent. Validators accept signed work, transactions, governance events, and peer gossip. Clients query status, mining view, records, mempool state, balances, nonces, validators, endpoints, and policy. Local tools inspect records and produce launch reports. Proof generation is deliberately simple today: divisor/cofactor evidence for composites and Pratt certificates for primes. More advanced certificate types can be added later, but the present design favors clarity and deterministic verification over complexity.

Chapter 4 — Clients, Mining Engines, and Replaceable Interfaces

Primechain consensus does not depend on the reference client. The client is a tool for creating wallets, synchronizing local proof state, constructing arithmetic evidence, submitting signed messages to validators, and displaying results to users. Anyone can write another client as long as it speaks the validator protocol and produces evidence that validators can verify.

The current client is deliberately simple. It is a command-line program that behaves more like an early launch shell than a polished consumer wallet. That is acceptable for the mainnet-candidate stage because the priority is protocol correctness, deterministic replay, and validator visibility. Better clients can be built on top of the same command surface.

4.1 What the Current Client Does

The reference client manages three local concerns:

  1. Wallets: it creates ML-DSA-65 wallet files, derives pcpq1_ addresses, signs mining evidence, and signs transactions.
  2. Proof store: it maintains a local copy of accepted records so it can build composite and Pratt evidence against the known frontier.
  3. Validator communication: it queries validators, submits signed work, submits transactions, and synchronizes when the network has advanced.

A normal miner work directory contains wallets, a local chain.dat proof store, peer configuration, job state, and any temporary mining state. The validator remains the source of live network truth, but the local proof store is important because proof generation depends on already accepted arithmetic evidence.

4.2 Workdir Lifecycle

A miner usually starts by initializing a workdir:

primechain-client init-workdir <workdir> <validator_host> <validator_port>

This creates local miner wallets and stores the initial validator peer. The miner then synchronizes:

primechain-client sync-peer <workdir>

After synchronization, the miner adds a target and runs:

primechain-client add-mine-job <workdir> --target <integer>
primechain-client run-jobs <workdir>

The job target is not a promise that the miner will win every record up to that integer. It is a local stopping condition. The client loops until the network frontier reaches the target, synchronizing whenever another miner advances the chain.

4.3 Syncing Proof State

The client does not merely ask a validator for the latest number. It downloads accepted records and appends them to its local proof store. This matters because the proof store is used to verify previous hashes, reconstruct frontier state, recover factorization evidence, and support Pratt proof generation.

When a miner sees that its local frontier is behind a validator frontier, it pauses mining and runs a record-range sync. In output this appears as:

sync download complete
SYNCED <start> <end>

This behavior is normal. It means another miner or another validator path advanced the network before this local miner finished its attempt. After syncing, the client resumes from the new frontier.

A stale proof store can cause false local failures. For example, a miner may fail to construct a Pratt proof because it has not yet downloaded the composite records needed to recursively factor p - 1. Syncing fixes that by bringing the local arithmetic database up to date.

4.4 Validator Selection

The current client can query validators for status and mining view. In a small network, one validator may be a few records ahead of another for short periods. A client that mines against a lagging validator may lose races or submit work for a frontier that has already moved.

The practical strategy is to query known validators, prefer the highest visible frontier, and sync from that validator before attempting new work. This is a client optimization, not a consensus rule. A custom client may implement better endpoint selection, parallel status checks, lower-latency retry loops, or smarter failover while still submitting the same signed protocol messages.

4.5 Submitting Prime Work

For a prime frontier integer, the client builds a Pratt-style certificate. The proof includes a witness and the factorization of p - 1. The client signs the proof with the miner wallet and sends it to a validator using the signed prime submission path.

The validator checks the frontier, previous hash, provider signature, primality certificate, reward allocation, transaction batch if present, and quorum evidence before finalizing the record. If another miner already advanced the frontier, the client treats the rejection as a race result, synchronizes, and continues.

The current miner prints proof information directly:

PRIME_ACCEPTED 6701 <record_hash>
PROOF_PRATT prime=6701 witness=2 factors_p_minus_1=2^2,5^2,67^1

This is intentionally educational. It lets users see that a prime was not accepted because a validator liked it; it was accepted because a checkable certificate was submitted.

4.6 Submitting Composite Work

For a composite frontier integer, the client finds a nontrivial divisor and computes the cofactor. It signs the proof and submits it to a validator. The validator checks:

m = d * e
1 < d < m
1 < e < m

If the proof is valid and the provider is eligible for the current frontier, the validator signs the candidate. The record becomes final only when the same candidate gathers validator quorum.

The current miner prints composite evidence directly:

COMPOSITE_ACCEPTED 6700 <record_hash>
PROOF_COMPOSITE integer=6700 divisor=2 cofactor=3350

Composite proof generation is currently minimal. It uses straightforward divisor discovery. This is enough for early frontier sizes, but it is not the limit of the protocol.

4.7 Transactions and Wallet Use

The client also functions as a wallet interface. It can derive an address from a wallet, show local balances, query pending wallet transactions from a validator, inspect address history, and submit transfers using the companion primechain-send tool.

Useful commands include:

primechain-client address <wallet-file>
primechain-client balance <record-store> <wallet-file>
primechain-client wallet-history <record-store> <wallet-file> [--last count]
primechain-client wallet-pending <host> <port> <wallet-file>
primechain-client address-report <record-store> <address> [--last count]
primechain-client tx <record-store> <tx-hash>
primechain-send reserve-lock ...
primechain-send transfer ...

Wallet state is replay-derived. A wallet file proves control of a key; it is not the authority for balance. Balances come from accepted records, sparse holdings, nonces, reserve locks, fees, and reward allocations reconstructed from the chain.

4.8 Third-Party Clients

A third-party client can compete with the reference client immediately. It only needs to follow the validator protocol and produce valid signed messages. It can improve any part that is outside consensus:

For example, before trying to build a full Pratt proof for m, a client can run faster primality filters and divisibility tests. If m is obviously composite, it should submit the composite proof. If m appears prime, it can focus on constructing the Pratt proof, including the factorization of m - 1. A better client may maintain richer local indexes of factorization evidence so it can build those proofs faster.

Validators do not care which client produced the message. They care whether the message is valid. This is the main reason the client layer should remain open: mining performance and user experience can improve through competition without weakening consensus.

4.9 Future Client Directions

The current CLI is enough to launch and diagnose the network, but it is not the final user experience. Near-term client improvements include cleaner mining output, concise race-loss messages, progress summaries, automatic validator selection, better sync status, and friendlier wallet commands.

Longer-term clients can add advanced proof engines. Prime certificates do not have to remain limited to Pratt proofs forever. The protocol can later support ECPP, Pocklington-style certificates, or other deterministic certificate families if validators are upgraded to verify them. Composite proof engines can also improve: trial division can be replaced or supplemented by better factoring methods as frontier integers grow.

The rule for future clients is simple: they may be faster, prettier, or smarter, but they must be deterministic at the protocol boundary. A validator must be able to check the submitted proof without trusting the client.

4.10 Summary

The Primechain client is replaceable infrastructure. The current command-line client initializes miners, syncs proof stores, builds simple composite proofs, builds Pratt proofs for primes, submits signed messages, sends transactions, and reports wallet and chain state. It is intentionally minimal. The protocol leaves room for independent clients with faster arithmetic, better validator selection, and better user interfaces, while validators preserve consensus by verifying every submitted proof and signature.

Chapter 5 — Transactions, Fees, and Privacy Directions

Transactions move MRPC value between addresses. The current transaction model is intentionally simple: a wallet spends integer micro-units of one or more prime-indexed assets, pays the active transfer fee, signs the message, and submits it to a validator. Validators check the transaction against replay-derived chain state before accepting it into the mempool or including it in an accepted record.

A transaction is not a separate chain. It becomes durable only when it is written into an accepted frontier record. Before that, it may exist in a validator mempool and may be visible through mempool query commands. Once included in a finalized record, it becomes part of replay history and every node reconstructs its effects deterministically.

5.1 Transaction Purpose

The monetary layer represents balances as sparse holdings of prime-indexed assets. Each mined prime creates a fixed supply of 1,000,000 micro-units. All micro-units have equal value regardless of the prime label. A transaction transfers those micro-units from one address to another.

The prime label is not an exchange rate. It is an issuance label. Sending 10,000 micro-units of prime 101 and sending 10,000 micro-units of prime 3 represent the same amount of MRPC value. The wallet chooses which prime holding to spend, but the economic unit is the micro-unit.

5.2 Current Transaction Shape

In practical terms, a transaction contains:

sender address
receiver address
prime asset label
micro-unit amount
fee prime label
fee amount
nonce
public key
signature

The sender signs the transaction with the wallet key. The signature proves authorization. The nonce prevents replay. The selected prime holding proves that the sender has enough balance for the transfer and enough balance to pay the fee.

The validator checks:

If the checks pass, the validator can keep the transaction in its mempool and gossip it to peers. If a miner includes the transaction in a record candidate, validators check it again during record validation.

5.3 Where Transactions Are Written

Transactions are written inside accepted prime or composite records. A record certifies one frontier integer and may also carry a batch of transactions. This means mining and settlement are combined: as the chain advances from integer to integer, each accepted record may also update wallet balances.

A simplified accepted record contains:

previous_hash
frontier_integer
record_kind
arithmetic_proof
provider_address
transaction_batch
reward_allocations
validator_finalization_signatures

During replay, nodes apply the record in deterministic order. First they verify the previous hash and arithmetic proof. Then they verify transactions, nonces, fees, rewards, reserves, and validator evidence. If all checks pass, the node updates sparse wallet holdings and advances the frontier.

The result is simple to audit: transactions are not hidden in an external database. They are part of the canonical record stream and can be inspected with local commands such as:

primechain-client decode-record <record-store> <integer>
primechain-client tx <record-store> <tx-hash>
primechain-client wallet-history <record-store> <wallet-file>
primechain-client address-report <record-store> <address>

Before a transaction is mined into a record, validators may hold it in the mempool. The mempool is temporary state. It helps wallets and miners find pending transactions, but it is not final settlement.

The current validator query surface includes:

GET_MEMPOOL
GET_MEMPOOL_SUMMARY
GET_NONCE <address>

GET_MEMPOOL shows pending transaction hashes and data visible to that validator. GET_MEMPOOL_SUMMARY gives counts, sender totals, fee totals, and age information. GET_NONCE tells a wallet what nonce should be used next, considering confirmed and pending transactions known to the validator.

The launch operations tooling also includes mempool checks across validators. This was added to mimic the practical needs of Bitcoin-style launch monitoring: operators need to know not only that blocks or records are advancing, but also whether pending transactions are propagating.

5.5 The Current Fee

The current transfer fee is:

1 micro-unit

The fee is deducted from a prime holding selected by the transaction and credited to the active validator fee pool. Because all micro-units have equal value, the fee does not require a conversion market between prime assets. One micro-unit of prime 5 and one micro-unit of prime 101 have the same fee value.

The fee has three purposes:

  1. It prevents completely free transaction spam.
  2. It creates a validator fee pool for the active epoch.
  3. It gives the protocol a simple accounting rule that can be replayed by every node.

The current fee is deliberately tiny. It is enough to exercise fee accounting and mempool rules during launch, but it is not meant to be the final economic policy for all network conditions.

5.6 Future Fee Changes by Validator Vote

Transaction cost should be adjustable by protocol governance. The current implementation already has economic-policy voting structure, and later validator votes can increase or otherwise change the active transaction fee.

A fee change should not be an arbitrary server setting. It should be a replay-visible policy event accepted by validator quorum. Once accepted, every node derives the same active fee from chain history. That keeps fee policy deterministic and auditable.

Reasons validators may later vote to raise fees include:

The same mechanism can also support more nuanced policies later: different fees for different transaction sizes, minimum fee per byte, fee discounts for batched transfers, or dynamic fee schedules. Those are future policy choices. The important current design point is that fees are part of replay-derived economic policy, not private validator preference.

5.7 Reserve Locks and Transaction Spendability

Validator reserve locks are also expressed through on-chain transactions. Locked reserve funds remain visible in the chain, but they are not spendable as ordinary wallet balance while they secure validator admission. Funds above the reserve remain transferable.

At launch, the initial validator wallets supplied the first reserve locks used to admit the validator set. The reserve requirement is not a hard-coded social promise; it is part of replay-derived economic policy. After launch, validators voted to raise the minimum validator reserve to 50,000,000,000 micro-units, equal to the full issuance value of 50,000 mined prime assets at 1,000,000 micro-units per prime.

This distinction matters for wallet reporting. A wallet may control keys for funds that are partly liquid and partly locked. Replay determines which holdings are spendable, which are reserved, and which deterministic pool address currently holds the locked value.

5.8 Transaction Privacy Today

The current transaction model is transparent. Sender address, receiver address, prime asset label, amount, fee, nonce, and transaction hash are visible in the accepted record stream. This is useful for launch auditability, wallet debugging, public status pages, and validator diagnostics.

Transparency is the right first step because the network is young. Operators need to inspect records, verify accounting, and diagnose mempool behavior. Strong privacy should not be bolted on casually; it has to preserve deterministic validation, supply conservation, fee accounting, and replay.

5.9 Possible Paths Toward Anonymous Transactions

Future versions could make transactions more private, but that would require explicit protocol design. Possible directions include:

These ideas are speculative. None should be described as implemented until validators can verify them deterministically and ordinary users can audit the supply rules. Privacy must not break the core accounting invariant: for every prime asset, total micro-units across wallets, reserve addresses, fee pools, and reward pools must remain exactly conserved.

A realistic path is incremental. First improve wallet address hygiene and batching. Then study confidential or zero-knowledge constructions. Only after that should a privacy transaction type become consensus-valid.

5.10 Transaction Summary

Transactions are signed messages that move integer micro-units between sparse prime holdings. They become final only when included in an accepted prime or composite record. The current fee is 1 micro-unit and is credited to the validator fee pool. Later, validator economic-policy votes can raise or reshape transaction fees through replay-visible governance. The present system is transparent by design; anonymous or confidential transactions are possible future research, not current launch behavior.

Chapter 6 — Wallets, Miner Identities, and Sparse Balances

Primechain separates wallet control from arithmetic roles. A wallet file is a signing identity. The chain state decides whether that identity controls spendable MRPC, locked reserve funds, pending rewards, or no value at all. This distinction is important because the reference miner workdir currently creates two wallet files: one for prime mining and one for composite mining.

6.1 The Two Wallets in a Miner Workdir

A standard miner workdir contains:

wallets/prime.wallet
wallets/composite.wallet

The prime.wallet is the default user-facing wallet in the reference tools. Wallet summary, balance reports, ordinary transfers, reserve-lock transactions, and most launch scripts assume this wallet unless another wallet path is specified. It is the wallet a miner normally treats as the main account.

The composite.wallet is primarily a proof-provider identity. It lets the client sign composite evidence separately from the prime wallet. In that sense it is a reference or role wallet: it identifies the provider of composite proofs. It does not create value by existing, and it is not a special second currency. It becomes economically relevant only if accepted chain records credit rewards or transactions to its address.

This split is operational, not monetary. MRPC value is not stored inside either file. The files hold keys. Value is reconstructed from the accepted chain.

6.2 What a Wallet File Contains

A wallet file contains the cryptographic material needed to sign messages. The implementation derives a pcpq1_ address from the wallet's public key. The address is what appears in records, transactions, reserve locks, validator applications, and reward allocations.

Conceptually, a wallet file provides:

private signing key
public verification key
address derived from public key
passphrase-protected storage

The chain never trusts the wallet file for balance. A copied wallet file does not bring along a private database of coins. It only gives control over the address. Nodes determine the actual balance by replaying accepted records from genesis.

6.3 Sparse Prime Holdings

Wallet balances are sparse. A wallet does not store an entry for every prime ever mined. It only has holdings for prime-indexed assets where the address owns a nonzero number of micro-units.

For an address A, replay may derive holdings such as:

prime 3      900000 micro-units
prime 101    450000 micro-units
prime 6701   450000 micro-units

All micro-units have equal value. The prime number is only the issuance label. Owning 100,000 micro-units of prime 3 and owning 100,000 micro-units of prime 6701 represent the same amount of MRPC value.

6.4 Example: Mining Rewards

Suppose a miner uses prime.wallet for prime proofs and composite.wallet for composite proofs. If the miner submits a prime proof and wins a prime record, the prime-provider reward is credited to the prime wallet address. If the miner submits composite proofs before the next prime is mined, the composite-provider share may be credited to the composite wallet address used in those accepted composite records.

This can produce two addresses with balances. That is not two currencies. It is two addresses holding sparse MRPC micro-units. The user can later transfer funds from either address if they control the corresponding wallet file and the funds are spendable.

6.5 Example: Sending to Another Wallet

A normal transfer spends micro-units from one address and credits another address. For example:

sender:   pcpq1_alice...
receiver: pcpq1_bob...
asset:    prime 6701
amount:   100000 micro-units
fee:      1 micro-unit

When the transaction is included in an accepted record, replay subtracts the amount and fee from the sender's sparse holdings and adds the transfer amount to the receiver's sparse holdings. The fee is credited to the validator fee pool for the active epoch.

The receiver does not need to know anything special about prime 6701. If the receiver owns nonzero micro-units of that prime after replay, the wallet balance report will show it.

6.6 Example: Sending to Validator Reserve

Validator admission uses reserve locking. A wallet can send spendable MRPC to a deterministic reserve address for a validator candidate. The reserve address is derived from the validator address, for example:

pcreserve_validator_<validator_address>

After the reserve-lock transaction is accepted, those funds remain visible on-chain but are no longer ordinary spendable wallet balance. They secure the validator candidate. Funds above the required reserve remain transferable. This is why reserve reports and wallet reports are separate: replay must distinguish liquid holdings from locked reserve holdings.

6.7 Composite Wallet as Reference Identity

The phrase "composite wallet" can be misleading. It does not mean a wallet that stores composite numbers as money. Composite integers do not create separate monetary assets. Only prime records mint prime-indexed assets. The composite wallet is simply the signing identity used by the reference client when it submits composite proofs.

A composite proof has value only because the protocol may later reward the provider address when a prime asset is minted. The composite integer itself is not money. It is evidence that advances the frontier and helps build the chain's reusable arithmetic database.

6.8 Wallet Summary

The wallet model can be summarized as:

wallet file = signing authority
address = public identifier
chain replay = balance authority
prime holdings = spendable MRPC units
composite wallet = proof-provider identity, not a separate asset class
reserve address = deterministic locked balance for validator admission

This structure keeps the system simple. Users can hold MRPC in ordinary addresses, send it to other wallets, lock it for validator admission, and inspect everything from replayed records. The reference client uses two miner identities for operational clarity, but the monetary unit remains the same: integer micro-units of prime-indexed MRPC assets.

Chapter 7 — Scale, Chain Growth, and the Long Boring Frontier

Primechain is designed around an intentionally slow and literal object: the ordered classification of consecutive integers. That makes the chain easy to understand but also important to frame honestly. For a very long time, Primechain will not be discovering mathematically unknown primes. It will be building a public, signed, economically meaningful record over integers whose primality or compositeness is already known or easy to determine.

That is not a flaw in the launch design. The early purpose is not to beat number theory databases. The early purpose is to prove that mining, validation, wallet accounting, transaction fees, reserve locks, validator voting, gossip, sync, and public reporting can operate together on a live network. The chain starts with boring arithmetic because boring arithmetic is the correct place to test monetary infrastructure.

7.1 Current Mining Rate

During current launch testing, the network has advanced at roughly one frontier record per minute when miners and validators are healthy. That means approximate production of:

60 records per hour
1,440 records per day
525,600 records per year

At one accepted frontier record per minute, the chain advances about 525,600 integers per year. Near launch-scale frontiers this corresponds, by the prime number theorem, to roughly 40,000 newly mined prime assets per year, or about 110 per day, which is approximately one new prime asset every 13 minutes. This prime issuance rate slowly declines as the frontier grows because primes become less frequent.

This rate is not a protocol constant. It depends on miner count, validator latency, proof generation speed, client retry behavior, transaction load, and future difficulty or pacing rules. The important point is that current growth is human-observable. It is fast enough to test the chain, but slow enough that operators can inspect records, diagnose validators, and understand failures.

7.2 Why the Chain Is Boring at First

The chain begins at 2 and advances by one integer at a time. This means the early chain spends most of its life certifying small composites and familiar primes. A user watching the miner sees records such as:

PROOF_COMPOSITE integer=6700 divisor=2 cofactor=3350
PROOF_PRATT prime=6701 witness=2 factors_p_minus_1=2^2,5^2,67^1

That output is not spectacular mathematics. It is mostly accounting, ordering, and verification. For the next many years, and realistically for far longer than a human lifetime at current speeds, the chain will move alongside already known primes. The interesting part is not that 6701 is a surprise. The interesting part is that a decentralized protocol issued, split, signed, stored, synchronized, and replayed the result deterministically.

Primechain's early records are therefore more like numbered receipts than scientific discoveries. They establish a public monetary sequence whose issuance is tied to arithmetic truth. The mathematical novelty comes much later, if ever. The protocol novelty is present from the beginning.

The current implementation also uses ML-DSA-65, the post-quantum signature scheme formerly known through the Dilithium family. These signatures are much larger than ordinary compact signatures such as Ed25519 or ECDSA. That choice increases record size, especially because miner, transaction, validator, and quorum evidence may all carry signatures. A version using ordinary signatures would have smaller records, but it would lose the post-quantum-oriented launch property described here.

7.3 Storage Growth

Every frontier integer produces a record. Prime records are larger because they include a primality certificate. Composite records are usually smaller but still contain signatures, hashes, provider data, rewards, transactions when present, and validator finality evidence.

Early launch measurements showed an average record size around tens of kilobytes. A practical planning number is:

about 28 KB per accepted record

This is not a fixed constant. It can change with more validators, larger signatures, more transactions per record, richer proof formats, better encoding, pruning, compression, or future checkpoint formats. But it is useful for rough planning.

At 28 KB per record, approximate storage is:

1,000 records        ~ 28 MB
100,000 records      ~ 2.8 GB
1,000,000 records    ~ 28 GB
1,400,000 records    ~ 39 GB
1,800,000 records    ~ 50 GB

At one record per minute, one million records is roughly 1.9 years of chain growth. A 40 GB validator disk budget would therefore cover roughly 1.4 million records under this simple estimate, or about 2.7 years at one record per minute. These numbers are approximate, but they show the right scale: storage matters, but it is an operations problem measured in years, not days.

7.4 Why Records Are Larger Than the Integer

A record is not just the number 6701. It includes the evidence and accounting around that number. A record may contain:

This is why a few hundred records can occupy megabytes. The chain is not trying to store integers compactly. It is storing signed settlement evidence around each integer. That makes the chain heavier than a mathematical table, but lighter and simpler than many general-purpose smart-contract systems.

7.5 The uint64 Frontier Limit

The present implementation treats frontier integers as 64-bit unsigned values. The largest such integer is:

2^64 - 1 = 18,446,744,073,709,551,615

This is a protocol and implementation boundary, not a near-term mining boundary. At one record per minute, reaching the uint64 limit would require on the order of:

3.5e13 years

That is vastly longer than the age of the universe. In practical launch terms, the uint64 limit is unreachable. It is still useful to name it because future implementations may choose arbitrary-precision integers, different serialization, or separate extension chains. But the current network will run out of disk planning, operator patience, or historical eras long before it runs out of 64-bit frontier integers.

7.6 Big Integers and Future Proof Engines

If Primechain ever approaches frontier sizes where 64-bit integers are no longer enough, the protocol would need an explicit big-integer upgrade. That upgrade would affect serialization, record hashing, proof verification, client arithmetic, validator replay, and sync compatibility. It should not be treated as a casual code change.

Big integers also change proof economics. Composite factoring becomes harder. Pratt proof construction depends on factoring p - 1. More advanced certificate systems such as ECPP or Pocklington-style certificates may become useful. Specialized miners may compete by maintaining better factorization indexes, faster primality tests, and stronger certificate engines.

This is future work. The current implementation is intentionally simple: small-integer divisor search for composites, Pratt-style certificates for primes, and deterministic validator verification. That is enough to launch and observe the economic protocol.

7.7 Boring Growth Is a Feature

A public monetary system should not depend on drama. Most records should be boring: one integer, one proof, one set of signatures, one deterministic replay step. Boring records mean the system is doing what it promised.

The chain becomes interesting in layers:

  1. Operationally, it proves that validators, miners, wallets, and public reporting can stay synchronized.
  2. Economically, it issues MRPC through a transparent reward schedule.
  3. Socially, it tests whether independent miners and validators can coordinate around fixed rules.
  4. Mathematically, it accumulates a public archive of prime and composite evidence.
  5. Far in the future, if the frontier grows large enough, its prime certificates may become computationally interesting in their own right.

For now, Primechain should be judged by reliability, auditability, replay correctness, validator independence, and user ability to mine and transact. The frontier will reach famous or difficult primes only in the very distant future unless the protocol deliberately changes its pacing model.

7.8 Summary

Primechain growth is linear: one accepted record per frontier integer. At current observed rates near one record per minute, the chain advances about 1,440 integers per day and about 525,600 per year. Storage grows in the tens of kilobytes per record under current launch conditions. The uint64 frontier limit is real but unreachable on human timescales. The early chain is intentionally boring because it is proving the network, monetary accounting, validator voting, sync, and public launch operations before it ever approaches mathematically novel primes.

Postscript — Live Miner Output

The following excerpt is real miner output from the launch network. It shows the system behaving as designed: the miner synchronizes its local proof store, submits composite proofs, hits the one-record winner cooldown, loses races when another miner advances the frontier, synchronizes again from validators, submits a prime proof with a Pratt certificate, and reports a composite lottery loss. This is the ordinary texture of Primechain mining. The output is not polished marketing text; it is useful because it shows the actual protocol surface exposed to miners.

VALIDATOR 137.184.129.231:8339 ERROR provider is in winner cooldown for next record
frontier changed while mining 1809; retrying: ERROR provider is in winner cooldown for next record
local proof store behind validator frontier; sync required local_frontier=1808 validator=67.205.172.245:8339 validator_frontier=1809
sync download complete
output_store: miner-proof-store/chain.dat
records: 2
start: 1808
end: 1809
frontier_integer: 1809
SYNCED 1808 1809
VALIDATOR 137.184.129.231:8339 COMPOSITE_ACCEPTED 1810 0180b7334184b8c1323cc4ad0d8503db2fda3b8aa935beaafa44ec7926e4dec1
VALIDATOR 137.184.129.231:8339 PROOF_COMPOSITE integer=1810 divisor=2 cofactor=905
VALIDATOR 137.184.129.231:8339 PRIME_ACCEPTED 1811 3c8b3e0e2f71dbaa884c0ab999ceed2331c11d482f57446b9369ba9f68d38e56
VALIDATOR 137.184.129.231:8339 PROOF_PRATT prime=1811 witness=6 factors_p_minus_1=2^1,5^1,181^1
VALIDATOR 137.184.129.231:8339 COMPOSITE_ACCEPTED 1812 b4d50d4761f819dc541a19378f65cb948abbd0c55e315dde76c273e6d008bb37
VALIDATOR 137.184.129.231:8339 PROOF_COMPOSITE integer=1812 divisor=2 cofactor=906
VALIDATOR 137.184.129.231:8339 ERROR provider is in winner cooldown for next record
frontier changed while mining 1813; retrying: ERROR provider is in winner cooldown for next record
VALIDATOR 137.184.129.231:8339 ERROR provider is in winner cooldown for next record
frontier changed while mining 1813; retrying: ERROR provider is in winner cooldown for next record
VALIDATOR 137.184.129.231:8339 ERROR provider is in winner cooldown for next record
frontier changed while mining 1813; retrying: ERROR provider is in winner cooldown for next record
VALIDATOR 137.184.129.231:8339 ERROR provider is in winner cooldown for next record
frontier changed while mining 1813; retrying: ERROR provider is in winner cooldown for next record
VALIDATOR 137.184.129.231:8339 ERROR provider is in winner cooldown for next record
frontier changed while mining 1813; retrying: ERROR provider is in winner cooldown for next record
local proof store behind validator frontier; sync required local_frontier=1812 validator=137.184.129.231:8339 validator_frontier=1813
sync download complete
output_store: miner-proof-store/chain.dat
records: 4
start: 1810
end: 1813
frontier_integer: 1813
SYNCED 1810 1813
VALIDATOR 137.184.129.231:8339 ERROR could not collect assigned composite lottery win from pcpq1_a70cc9f02ddca29be60b6c248d645e10a1431ef9
VALIDATOR 137.184.129.231:8339 LOTTERY_LOST integer=1814 provider=pcpq1_db1033959a75925877437f9a0d8f5b96a4af6409 reason=assigned-validator-no-win
SYNC_UP_TO_DATE 1813
WAITING_FOR_RACE_WINNER frontier=1813 target=10000
SYNC_UP_TO_DATE 1813
SYNC_UP_TO_DATE 1813
SYNC_UP_TO_DATE 1813
SYNC_UP_TO_DATE 1813
RACE_WAIT_TIMEOUT_RETRY frontier=1813 target=10000
RETRYING_LOCAL_MINER attempt=1 frontier=1813 target=10000

This excerpt also illustrates why better client interfaces matter. A future miner UI should classify these lines into simpler states such as accepted composite, accepted prime, Pratt proof, cooldown, lottery lost, race lost, and syncing, while preserving the raw protocol output for auditability.

Appendix A — External Review Notes

During the public launch-testnet run, Kaito <kaitozero@proton.me> mined on launch-testnet-1, reviewed the implementation, opened hardening and client-performance pull requests, and analyzed observed mining behavior across frontier records. This appendix summarizes that external review. A fuller public note is available at external-review-kaito.html.

A.1 GET_FACTORIZATION CPU-Burn Finding

Kaito identified that GET_FACTORIZATION, when the optional factorization helper was enabled, could pass a large unauthenticated integer into trial-division primality testing before the proof index rejected it. The public validators were not running with that helper exposed, but the code path was hardened so large requests are rejected before they can burn validator CPU.

Short excerpt: "tie up a connection thread".

A.2 Checked Credit Arithmetic

Kaito noted that SequentialNode::credit() used raw addition while debit and transaction-batch paths used checked arithmetic. Under the current fixed per-prime supply rule this was not an immediate exploit path, but it was an inconsistency worth closing for defense in depth.

A.3 Client Latency and Competitive Mining

Kaito profiled the frontier miner and found that sequential status probing, endpoint discovery, and commit propagation added avoidable client-side latency. This matters because Primechain intentionally permits independent client implementations. The reference client is not a consensus boundary; miners may write faster clients as long as they submit valid protocol messages.

Short excerpt: "client-side sequencing, not just validator response time".

A.4 The p - 1 Proof-Cache Effect

Kaito analyzed records 3309-4012 and observed that a multi-role miner sharing local proof state between composite and prime identities can gain an advantage around primes. A client that proves composite p - 1 may have the factorization needed for the Pratt certificate of p before other clients see the confirmed record through sync. If it also coordinates multiple provider identities, it can submit prime and composite work across consecutive frontier records more effectively than split-role miners.

Short excerpt: "the p-1 factorization available with no network round trip".

This observation does not by itself prove a flaw in the prime reward mechanism. It does show that combined arithmetic work, local proof reuse, and coordinated client design are economically meaningful. The current project position is that optimized clients are expected and permitted; the protocol should not rely on reference-client slowness or artificial separation between prime and composite work.

A.5 Project Response

The external review has already improved the implementation and documentation. The project currently treats client optimization and shared local proof state as expected miner competition. The larger unresolved area remains validator admission and BFT economics: reserve locks, validator-owner coordination, long-term honesty incentives, and the degree to which admission rules should be governed by on-chain votes versus off-chain operator trust.

References

Prime Numbers, Primality Testing, and Factorization

  1. Pratt, V. R. (1975). Every Prime Has a Succinct Certificate. SIAM Journal on Computing, 4(3), 214–220.
  2. Agrawal, M., Kayal, N., & Saxena, N. (2004). PRIMES is in P. Annals of Mathematics, 160(2), 781–793.
  3. Atkin, A. O. L., & Morain, F. (1993). Elliptic Curve Primality Proving (ECPP). Mathematics of Computation, 61(203), 29–68.
  4. Brent, R. P. (1980). An Improved Monte Carlo Factorization Algorithm. BIT Numerical Mathematics, 20, 176–184.
  5. Crandall, R., & Pomerance, C. (2005). Prime Numbers: A Computational Perspective. Springer.
  6. Ribenboim, P. (1996). The New Book of Prime Number Records. Springer.
  7. Cohen, H. (1993). A Course in Computational Algebraic Number Theory. Graduate Texts in Mathematics, Springer.
  8. Bach, E., & Shallit, J. (1996). Algorithmic Number Theory, Vol. 1: Efficient Algorithms. MIT Press.
  9. Gupta, S., & Murty, V. K. (2010). Primality Testing: History and Recent Development. Journal of Number Theory, 130(1), 49–68.

Blockchain, Consensus, and Proof-of-Work

  1. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
  2. King, S. (2013). Primecoin: Cryptocurrency with Prime Number Proof-of-Work. primecoin.io (whitepaper).
  3. Bonneau, J., et al. (2015). SoK: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies. IEEE Symposium on Security & Privacy.
  4. Garay, J., Kiayias, A., & Leonardos, N. (2015). The Bitcoin Backbone Protocol: Analysis and Applications. EUROCRYPT.
  5. Ren, L. (2017). Proofs of Space and Time. IACR ePrint 2017/775.
  6. Boneh, D., Bonneau, J., Bünz, B., & Neuzerling, E. (2018). Verifiable Delay Functions. In CRYPTO.

Useful Proof-of-Work and Verifiable Computation

  1. Ball, M., et al. (2017). Proofs of Useful Work. IACR ePrint 2017/203.
  2. Ford, B., et al. (2021). Useful Proof-of-Work for Blockchain: Fundamentals and Survey. ACM Computing Surveys.
  3. Bünz, B., Fisch, B., Szepieniec, A. (2020). Bulletproofs and Verifiable Computation Systems. IACR surveys.

Game Theory and Incentive Models

  1. Nash, J. F. (1950). Equilibrium Points in n-Person Games. Proceedings of the National Academy of Sciences, 36(1), 48–49.
  2. Nash, J. F. (1951). Non-Cooperative Games. Annals of Mathematics, 54(2), 286–295.
  3. Osborne, M. J., & Rubinstein, A. (1994). A Course in Game Theory. MIT Press.
  4. Maskin, E., & Tirole, J. (2001). Markov Perfect Equilibrium in Dynamic Games. Econometrica.
  5. Halpern, J. Y., & Pass, R. (2019). A Game-Theoretic Approach to Blockchain Analysis.

Post-Quantum Cryptography

  1. NIST PQC Standardization Project. (2024). Module-Lattice-Based Digital Signature Standard (ML-DSA), FIPS 204; derived from CRYSTALS-Dilithium.
  2. Bernstein, D. J., Buchmann, J., & Dahmen, E. (Eds.). (2009). Post-Quantum Cryptography. Springer.
  3. Chen, L., et al. (2016). Report on Post-Quantum Cryptography. NISTIR 8105.
  4. Alagic, G., et al. (2022). Status Report on the Third Round of the Post-Quantum Cryptography Standardization Process. NIST.

Quantum Algorithms and Cryptanalysis

  1. Shor, P. W. (1997). Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. SIAM Journal on Computing, 26(5), 1484–1509.
  2. Grover, L. (1996). A Fast Quantum Mechanical Algorithm for Database Search. STOC.
  3. Montanaro, A. (2016). Quantum Algorithms: An Overview. npj Quantum Information.
  4. Gidney, C., & Ekera, M. (2021). How to Factor 2,048-bit RSA Keys in 8 Hours Using 20 Million Logical Qubits. Quantum, 5, 433.

Algebraic Number Theory and UFD/Ring Structure

  1. Neukirch, J. (1999). Algebraic Number Theory. Springer.
  2. Samuel, P. (1970). Unique Factorization Domains. American Mathematical Monthly.
  3. Lang, S. (1994). Algebraic Number Theory (2nd ed.). Springer.
  4. Marcus, D. (1977). Number Fields. Springer.

Distributed Systems and P2P Networking

  1. Tanenbaum, A. S., & van Steen, M. (2016). Distributed Systems: Principles and Paradigms. Pearson.
  2. Kurose, J. F., & Ross, K. W. (2021). Computer Networking: A Top-Down Approach.

Cryptographic Hashing and Merkle Structures

  1. Bertoni, G., Daemen, J., Peeters, M., & Van Assche, G. (2013). The Keccak SHA-3 Submission.
  2. Merkle, R. C. (1989). A Certified Digital Signature. CRYPTO.

Classical References on Security Proofs and Protocol Design

  1. Goldreich, O. (2004). Foundations of Cryptography, Vols. 1–2. Cambridge University Press.
  2. Bellare, M., & Rogaway, P. (2005). Introduction to Modern Cryptography.
  3. Canetti, R. (2001). Universally Composable Security. FOCS.

Optional Category: Historical / Conceptual References

  1. Hardy, G. H., & Wright, E. M. (1979). An Introduction to the Theory of Numbers. Oxford University Press.
  2. von Neumann, J., & Morgenstern, O. (1944). Theory of Games and Economic Behavior. Princeton University Press.
  3. Nash, J. F. (2002). Ideal Money. Southern Economic Journal, 69(1), 4-11. https://ideas.repec.org/a/wly/soecon/v69y2002i1p4-11.html
  4. Nash, J. F. (2009). Ideal Money and Asymptotically Ideal Money. https://m.mathnet.ru/php/archive.phtml?jrnid=cgtm&option_lang=eng&paperid=56&wshow=paper
  5. Nash, J. F. (2011). Ideal Money and the Motivation of Savings and Thrift. Lindau Nobel Laureate Meetings. https://mediatheque.lindau-nobel.org/recordings/31344/ideal-money-and-the-motivation-of-savings-and-thrift-2011