Draft addendum to Primechain whitepaper v2. This page describes proposed staged evidence-layer work and does not replace the current v2 protocol paper.

Primechain Evidence Layer Addendum

From Ordered Integer Classification to Verifiable Arithmetic Evidence

Ovanes Oganisian, MidLincoln Research

Draft addendum, August 12, 2026

This note is an addendum to the current Primechain whitepaper v2:

https://midlincoln.com/opportunities/prime-mining/launch-proof/prime-mining-whitepaper-v2.html

The purpose of this addendum is to summarize the current public testnet state and to describe the next research direction: adding a staged evidence layer around mined primes. The evidence layer is intended to extend Primechain from an ordered prime/composite classification chain into a public corpus of verifiable arithmetic evidence.

This is not a replacement for the v2 whitepaper. The v2 paper remains the main protocol description for the current launch network. This addendum describes planned and proposed work.

1. Current State

Primechain currently runs as a public mainnet-candidate testnet on network launch-testnet-1. The chain begins at integer 2 and advances one frontier integer at a time. Each accepted record classifies the next integer as either prime or composite.

As of August 13, 2026, the public implementation is tracked at repository commit 276e0498bec0. The cross-round finalization-lock protocol used by the current validator design was introduced at release commit 8ecb55285c26.

Prime records carry Pratt-style primality certificates. Composite records carry divisor/cofactor evidence and pass through the validator-run composite lottery. If the lottery loses, no composite record is accepted, the frontier does not advance, and the same integer remains open for later submissions.

The current implementation uses SHA3-256 commitments/hashing and ML-DSA-65 signatures. Validators provide quorum finality, gossip, synchronization, transaction handling, wallet balance queries, validator registry replay, fee and reward pools, and operational status reporting.

The current chain is still a testnet and not a finished cryptocurrency security proof. The intended direction remains conditional: if the network proves sustainable under public mining, validator operation, transaction use, client diversity, and external review, the current chain is intended to become the initial mainnet rather than being discarded. If it does not prove sustainable, the protocol will need further revision before mainnet.

The main open areas are:

2. External Review and Tooling

External review has already materially improved the project.

Kaito <kaitozero@proton.me> has mined on the public chain, reviewed the implementation, opened hardening and client-performance pull requests, and developed independent local tooling around the Primechain command-line client.

Notable contributions and review areas include:

Kaito's public tooling repositories are:

https://github.com/kaito-zero/primewallet
https://github.com/kaito-zero/primescan

These tools remain separate from core Primechain at this stage. That separation is useful: the core protocol can continue to stabilize while wallet and explorer UX improve independently.

3. Why Add an Evidence Layer?

The present chain certifies the integer line:

2, 3, 4, 5, 6, 7, ...

Each frontier record answers one deterministic question:

Is the next integer prime or composite?

Once a prime has been mined, however, it can serve as an anchor for additional mathematics. A mined prime p can become the base point for verifiable evidence about finite fields, algebraic extensions, splitting behavior, ramification, and eventually class groups or related ring structure.

The proposed evidence layer extends the project from:

classify the next integer

to:

classify the next integer, then build verifiable arithmetic evidence around the primes discovered by the chain

This direction is attractive because it keeps the core Primechain idea simple while creating additional useful work for researchers, miners, explorers, and wallet users.

4. Evidence Task Families

The first evidence layer should focus on three task families.

4.1 Prime Behavior in Algebraic Extensions

For a mined prime p, a participant may submit evidence about how p behaves in a finite-degree algebraic extension:

K = Q(alpha)

where alpha is a root of a defining polynomial f(x) over the integers.

The submitted claim may say that p:

For simple early cases, validators or off-chain verifiers can check the factorization of f(x) modulo p.

Example split evidence:

p = 7
K = Q(sqrt(2))
f(x) = x^2 - 2

x^2 - 2 = (x - 3)(x + 3) mod 7

claim: 7 splits in Q(sqrt(2))

Example non-splitting / inert evidence:

p = 7
K = Q(sqrt(3))
f(x) = x^2 - 3

x^2 - 3 is irreducible over F_7

claim: 7 remains inert in Q(sqrt(3))

This gives the chain a natural bridge from mined rational primes into algebraic number theory.

4.2 Finite-Field Construction Evidence

For a mined prime p, a participant may submit an irreducible polynomial over F_p.

Example:

p = 7
n = 2
f(x) = x^2 + 1 over F_7

Since x^2 + 1 has no root in F_7, it is irreducible. This gives a concrete construction:

F_49 = F_7[x] / (x^2 + 1)

This evidence is useful because finite fields are central to cryptography, coding theory, elliptic curves, pairings, and zero-knowledge systems. A mined prime can therefore anchor verifiable finite-field constructions:

Finite-field irreducibility is one of the simplest evidence types to verify automatically, so it is a good candidate for the first machine-checkable evidence class.

4.3 Extension, Ring, and Class-Group Characterization

After an algebraic extension is registered, participants may submit deeper structural evidence:

Example:

K = Q(sqrt(2))
ring/order = Z[sqrt(2)]
discriminant = 8
class number = 1
class group = trivial
UFD = yes

This category is mathematically richer but harder to verify automatically in full generality. It should begin as manually reviewed or tool-assisted evidence, then later admit carefully defined automatically checkable subsets.

5. Chain Structure

The evidence layer should not modify old records. Evidence about an old prime should be written into a later record.

Example:

record 7:
  PRIME_ACCEPTED 7

record 1009:
  EVIDENCE_EVENT base_prime=7 type=FINITE_FIELD_IRREDUCIBLE_POLY ...

The current record structure already supports transactions as payload data inside finalized records. Evidence can be added in the same spirit:

record q:
  prime_or_composite_proof
  transactions
  evidence_events
  finalization_votes

The record remains append-only. The evidence event references the earlier mined prime p, but the original record for p is not changed.

This requires versioned record support:

old record versions:
  no evidence section

new record versions after activation:
  evidence_count
  evidence_events[]

Records may still contain zero evidence events. Frontier mining must continue even when no evidence is available.

6. Evidence Identity and Duplicate Rules

Each evidence event needs a canonical identity:

evidence_id = SHA3-256(canonical evidence payload)

Validators and derived indexes should track accepted evidence IDs and evidence-specific duplicate keys.

Examples:

finite_field_poly_key =
  (base_prime, degree, canonical_polynomial)

prime_behavior_key =
  (base_prime, field_id, order_id, behavior_type)

class_group_key =
  (field_id, order_id, claim_type)

The first implementation should reject exact canonical duplicates. It should not try to solve general field isomorphism at launch. Many different irreducible polynomials of the same degree over F_p define isomorphic copies of F_{p^n}. That is acceptable: the early reward or credit is for submitting a valid concrete construction/model, not for proving mathematical non-isomorphism.

7. Derived Evidence Index

Evidence about prime 7 may appear in record 1009, 1401, or later. A naive client should not have to scan the entire chain to answer:

What evidence exists for prime 7?

Therefore evidence lookup should be implemented through a derived index:

chain.dat.evidence.idx

The index can map:

base_prime -> evidence events
field_id -> field behavior and class-group reports
provider -> submitted evidence
evidence_id -> inclusion record

This index is not consensus state. The chain remains the source of truth. If the evidence index is missing or corrupt, it can be rebuilt from chain.dat.

This follows the same design principle as address, reward, and participation indexes already being added around the client and explorer:

chain.dat = truth
derived indexes = fast lookup

8. Evidence Reward Plan

Evidence rewards should be introduced cautiously and only after the evidence validation path is stable. The first implementation should record and index evidence without changing monetary distribution. Rewards can be activated later by a forward-only policy rule.

The likely reward range is small:

evidence pool: 1% to 5% of newly mined prime issuance

This range is large enough to signal that evidence work matters, but small enough that frontier mining remains the primary incentive. Primechain still depends on miners advancing the integer frontier. Evidence work should complement that process, not replace it.

For example, after activation, each newly mined prime q could allocate:

prime miner: existing main share, mostly preserved
composite miners: existing composite share, mostly preserved
validator pool: existing validator share, mostly preserved
evidence pool: 1% to 5%, capped by policy

The exact split should not be hard-coded in this addendum. It should be voted or activated only after testing, because the effect on mining incentives is not yet known. If the evidence share is too large, miners may prefer evidence collection over frontier advancement. If it is too small, useful evidence may remain mostly unpaid. The first safe target is therefore a capped research allocation, not a major redesign of issuance.

Evidence rewards should also be non-retroactive. Evidence about an old prime can be submitted and included later, but payment should come only from future issuance after the evidence-reward activation point:

evidence_rewards_active_from = M

No existing wallet balances should be recalculated. No old prime, composite, or validator allocations should be changed.

9. Staged Implementation Plan

The evidence layer should be implemented in stages.

Stage 1: Manual Evidence Registry

Create a web or CLI registry for signed evidence submissions.

Each submission contains:

evidence_type
base_prime
claim
mathematical payload
provider address
signature
status: pending / accepted / rejected
review notes

At this stage, evidence is public and credited but not yet consensus state and not yet rewarded by issuance.

Stage 2: Automatic Verification for Simple Evidence

Add machine-checkable validation for the simplest cases:

Class-group and UFD evidence should remain manual or tool-assisted until the automatically checkable subset is clearly defined.

Stage 3: Evidence Events in Records

Add versioned evidence_events to new records after an activation integer:

evidence_events_active_from = N

After N, miners may include accepted evidence events in new records. Validators check that each event is valid, unique, canonical, signed, and attached to a previously mined prime or registered field.

This stage records evidence on-chain but does not need to change reward allocation yet.

Stage 4: Derived Evidence Index

Add client and explorer support:

update-evidence-index
evidence-for-prime
evidence-by-id
evidence-by-provider
field-report

The explorer can then show a page for each mined prime:

Prime 7
  mined at record 7
  finite-field constructions
  splitting/non-splitting evidence
  class-group/ring evidence

Stage 5: Forward-Only Evidence Rewards

Only after the evidence validation and indexing path is stable should rewards be considered.

Rewards must be forward-only:

evidence_rewards_active_from = M

No existing balances are rewritten. No old records are changed. No old prime/composite rewards are recalculated.

If activated, a small capped evidence pool may be allocated from future newly mined prime issuance. Frontier advancement should remain the dominant incentive.

Example policy direction:

prime miner: existing main share mostly preserved
composite miners: existing composite share mostly preserved
validator pool: existing validator share mostly preserved
evidence pool: small capped research allocation

The evidence pool should not be large enough to make miners stop advancing the frontier.

10. Design Constraints

The following constraints should guide implementation:

11. Summary

Primechain currently classifies the integer line through prime certificates and composite proofs. That remains the core protocol.

The proposed evidence layer extends the meaning of mined primes. A mined prime can become an anchor for additional verified arithmetic:

finite fields over F_p
irreducible polynomials
splitting and non-splitting in algebraic extensions
ramification evidence
ring and class-group structure

The staged path is deliberately conservative:

manual evidence first
simple automatic verifiers second
on-chain evidence events third
derived evidence indexes fourth
future evidence rewards last

This keeps Primechain's existing chain and rewards intact while expanding the project toward a broader public infrastructure for verifiable mathematical work.