Proofgold: Blockchain for Formal Mathematics

• Proofgold is a blockchain platform integrating formalized mathematics with cryptocurrency by supporting content-addressed theories, definitions, and proofs.
• Its hybrid proof-of-stake/proof-of-burn model and native proof checker ensure that formal proofs are consensus-critical, blending logical verification with value transfers.
• An incentive layer with bounties and advanced payment channels fosters collaborative theorem proving and decentralized management of formal mathematical knowledge.

Proofgold is a blockchain that supports formalized mathematics alongside standard cryptocurrency functionality. It incorporates logical constructs into the blockchain, including declarations of formal theories, definitions, propositions and proofs, while also supporting ordinary value transfers. Its design combines a hybrid proof-of-stake/proof-of-burn cryptocurrency, an embedded intuitionistic higher-order logic proof checker with functional extensionality, and an incentive layer based on bounties for proving conjectures. The platform is accompanied by the OCaml-based Lava client, a web-based blockchain explorer exposing both transactional and formal content, and an extension of bidirectional payment channels that allows parties to bet on whether a proposition will be proven by a deadline (Brown et al., 10 Sep 2025, Brown et al., 10 Sep 2025).

1. Chain architecture and consensus model

Proofgold’s base consensus is a hybrid proof-of-stake/proof-of-burn cryptocurrency. The burn element re-uses Litecoin’s proof-of-work, while stake is held in “bars” of Proofgold. This places the system within the family of cryptocurrency ledgers while distinguishing it by the kinds of objects that blocks may carry.

Every block in Proofgold may carry not only ordinary value-transfers, but also transactions that introduce or modify formal objects—entire theories, definitions, conjectures or proof scripts. Each such object is content-addressed by a 256-bit identifier, specifically a Merkle root of the object’s abstract syntax tree. For a theory declaration $t$, the identifier is written as $id_t = \mathrm{SHA256}(\ldots t \ldots)$. The use of content addressing makes the formal layer intrinsic to ledger state rather than an auxiliary data store.

On-chain proof checking is part of the core protocol. Whenever a block includes a “publish-proof” transaction, the chain rules reject it if any proof step fails type or inference checks. This means that consensus validity depends not only on the usual cryptocurrency conditions but also on logical verification. A plausible implication is that Proofgold treats theorem certification as a consensus-critical operation rather than an application-layer annotation.

The resulting architecture integrates monetary transfer, formal object publication, and proof validation into a single ledger. This suggests a decentralized model of mathematical knowledge management in which theories, theorems, and proofs are first-class blockchain data.

2. Formal objects and embedded logic

Proofgold embeds several formal entities directly into transactions: theories, definitions, conjectures and theorems, and proof objects (Brown et al., 10 Sep 2025). Theories are collections of typed constants and axioms. An example given in the system description is:

$o$5

The entire theory file is hashed to produce its on-chain identifier. Definitions introduce new constants by binder or $\lambda$-abstraction. The examples

$$\mathrm{lam} : \iota \to (\iota \to \iota) \to \iota, \qquad \mathrm{ap} : \iota \to \iota \to \iota$$

are used to represent set-encodings of restricted functions and function application. Conjectures and theorems are propositions of type $o$, either open with a bounty or marked as proved.

Proof objects are fully explicit derivation scripts checked by the embedded proof engine. Internally they correspond to a tree of inference-rule invocations, but users see them as sequences of lemma applications. The distinction is significant: the internal representation emphasizes proof-theoretic explicitness, whereas the user-facing presentation is organized for navigability.

The logic implemented by the core includes intuitionistic higher-order logic with functional extensionality. Because formal objects are published on-chain and validated at inclusion time, Proofgold does not merely store proof artifacts; it enforces logical well-formedness and proof correctness as part of ledger evolution. This suggests a tight coupling between formal semantics and distributed state transition.

3. Incentive layer and bounty mechanism

Proofgold supports placing and collecting bounties on proving propositions, thereby incentivizing development of the formal libraries contained in the system (Brown et al., 10 Sep 2025). Any user can attach some bars of Proofgold to a new conjecture in a theory. Once a proof transaction for the conjecture is included in a valid block, ownership of the proved proposition, encoded by a public-key marker, automatically entitles the prover to withdraw the attached bars.

The system also included automatic bounties during its early history. The first 5 000 blocks each randomly minted a small bounty on a “pseudorandom” proposition in the built-in hereditarily finite-set theory (HF). This mechanism coupled block production with seeded formalization tasks.

The quantitative state reported for the platform is summarized below.

Mechanism or outcome	Reported value
Initial automatic-bounty phase	first 5 000 blocks
Total bounties placed to date	over 13 000
Bounties resolved to date	nearly 3 000

The incentive effect is described as having funded a growing HOTG library, including Mizar-style axioms, Megalodon variants, a HOAS syntax module, and reals via Conway’s surreals. A plausible implication is that the bounty system functions not only as an economic incentive but also as a prioritization mechanism for formal library growth. Because bounties are attached to propositions within explicit theories, the incentive layer is structurally aligned with the formal ontology of the chain.

4. Lava client, transaction processing, and the web explorer

The standard Lava client is an OCaml implementation of Proofgold Core, extended with an “explorer mode” that continually rescans the chain up to the current tip, type-checks every formal transaction, and populates 34 in-memory hash tables, approximately 10 GB, with theory and object metadata as well as bounty status (Brown et al., 10 Sep 2025). The metadata include types, owners, and dependencies; the bounty tables record amount, proposer, prover, and whether the bounty is open or collected.

Lava exposes custom RPC calls over a thin JSON layer. These calls support querying by object identifier, listing a theory’s contents, fetching a proof script, and enumerating bounties. Validation remains consensus-oriented: every incoming block must satisfy the usual proof-of-stake/proof-of-burn rules and additionally pass Lava’s checker on each proof transaction before becoming part of the local view of the ledger.

The explorer architecture is described as:

$o$6

The PHP backend serves HTML pages for blocks, transactions, addresses, theories, theorems, proofs, and bounties. It calls Lava’s RPC in real time to retrieve structured JSON data and formats interactive views. The interface supports inspection of blocks, transactions, and addresses, as well as theories, definitions, theorems, and proofs. It also supports submission of transactions to the blockchain by allowing users to paste raw hex of a signed transaction, which the explorer relays to Lava and onward to the peer-to-peer network without requiring the user to run a full node.

Several navigator features are singled out. The chain graph uses colored nodes for theory declarations, proofs, bounties, invalid steps, and missing blocks. The main dashboard presents block height, circulating supply, transaction volume, and address count. Bounty tables expose highest open and collected bounties and category breakdowns such as “Random AIM,” “Surreal,” and “Category Theory.” Transaction details combine value inputs and outputs with anchors to formal objects, for example “publish-proof of theorem X.”

In context, the explorer is not limited to block inspection in the conventional cryptocurrency sense. It is designed to support navigation of formal content and facilitate mathematical knowledge management in a decentralized setting. This suggests that Proofgold’s user interface is part of its epistemic infrastructure, not merely an operational console.

5. Category-theoretic formalization and adjunction bounties

A concrete case study concerns category-theory adjunction bounties placed in summer 2021 (Brown et al., 10 Sep 2025). In that period, 33 bounties of 750 bars each were placed on the conjecture

$$\exists F_0 : \iota \to \iota.\ \exists F_1 : \iota \to \iota \to \iota \to \iota \to \iota \to \iota.\ \exists \eta,\epsilon : \iota \to \iota.\ \mathrm{MetaAdjunction\_strict} (\lambda X.\top) (\mathrm{HomSet}) (\mathrm{lam\_id}) (\lambda X\,Y\,Z.\ \mathrm{lam\_comp}\ X) (\lambda A.A\ 0) (\lambda A\,B\,f.f)\ \eta\ \epsilon$$

Here $(\lambda X.\top)$ and $\mathrm{HomSet}$ present the category of sets, $\mathrm{lam\_id}$ and $\mathrm{lam\_comp}$ give its identity and composition, and $id_t = \mathrm{SHA256}(\ldots t \ldots)$0 and $id_t = \mathrm{SHA256}(\ldots t \ldots)$1 define the forgetful functor from a structure category back to sets. The predicate $id_t = \mathrm{SHA256}(\ldots t \ldots)$2 bundles the axioms for a left adjoint, namely $id_t = \mathrm{SHA256}(\ldots t \ldots)$3, $id_t = \mathrm{SHA256}(\ldots t \ldots)$4, unit $id_t = \mathrm{SHA256}(\ldots t \ldots)$5, counit $id_t = \mathrm{SHA256}(\ldots t \ldots)$6, together with well-typedness.

The reported outcomes were 14 proven, 3 refuted, and 19 still open. Proven cases included graphs, irreflexive partial orders, equivalence relations, injections, and bijections. Refuted cases included a buggy monoid category without identity arrows that accidentally used semigroup homomorphisms only; the negation proof exploited the lack of a unique map to the two-element monoid. Open cases included free topological spaces on Hausdorff or $id_t = \mathrm{SHA256}(\ldots t \ldots)$7 spaces and free abelian groups.

For the bijections case, the Megalodon syntax excerpt is:

$o$7

Once BijLeftAdj is checked by Lava and included in a block, the 750-bar bounty on “free permutation structure” is automatically released to the prover. This case study illustrates how abstract category-theoretic constructions are operationalized as bounty-bearing formal objects on-chain. A plausible implication is that Proofgold can host not only isolated theorem statements but structured research programs organized around families of parametrized formal conjectures.

6. Payment channels with proofs and Lightning-style composition

Proofgold extends bidirectional payment channels so that the two parties can bet on whether a proposition $id_t = \mathrm{SHA256}(\ldots t \ldots)$8 will be proven by a certain time $id_t = \mathrm{SHA256}(\ldots t \ldots)$9 (Brown et al., 10 Sep 2025). The blockchain provides a scripting language supporting 2-of-2 multisig, HTLCs, CLTV, CSV, and additionally $\lambda$0, which succeeds if proposition $\lambda$1 has appeared on-chain. The extension replaces one output in each commitment transaction with a proposition timelock contract, or PTLC, paying out according to whether $\lambda$2 is proven before or after a deadline.

For a channel with total value $\lambda$3, update index $\lambda$4, free balances $\lambda$5, and collateral stakes $\lambda$6, the invariant is

$\lambda$7

Fresh revocation secrets $\lambda$8 with hashes $\lambda$9 and $$\mathrm{lam} : \iota \to (\iota \to \iota) \to \iota, \qquad \mathrm{ap} : \iota \to \iota \to \iota$$0 revoke old states in the usual manner.

The PTLC is defined so that it pays to one party if $$\mathrm{lam} : \iota \to (\iota \to \iota) \to \iota, \qquad \mathrm{ap} : \iota \to \iota \to \iota$$1 succeeds, and otherwise to the other after blockheight $$\mathrm{lam} : \iota \to (\iota \to \iota) \to \iota, \qquad \mathrm{ap} : \iota \to \iota \to \iota$$2 via CLTV. This PTLC is nested under an HTLC delay in the bet output. In the description, the combined script takes the form

$$\mathrm{lam} : \iota \to (\iota \to \iota) \to \iota, \qquad \mathrm{ap} : \iota \to \iota \to \iota$$3

The effect is conditional payout on theorem provability, while preserving revocation-based fraud protection and unilateral-close behavior.

Dispute resolution follows the standard channel logic augmented by proof conditions. Revealing old secrets revokes prior commitment transactions. If a counterparty broadcasts an outdated state, the honest party can use the known secret in the HTLC to steal the entire channel output. A race condition exists around PTLC settlement: if one party closes after blockheight $$\mathrm{lam} : \iota \to (\iota \to \iota) \to \iota, \qquad \mathrm{ap} : \iota \to \iota \to \iota$$4, the other may also compete to claim the refund branch. The timeout windows $$\mathrm{lam} : \iota \to (\iota \to \iota) \to \iota, \qquad \mathrm{ap} : \iota \to \iota \to \iota$$5 and $$\mathrm{lam} : \iota \to (\iota \to \iota) \to \iota, \qquad \mathrm{ap} : \iota \to \iota \to \iota$$6 therefore function as explicit safety margins.

These channels can compose into a Lightning-style network. Participants form a graph $$\mathrm{lam} : \iota \to (\iota \to \iota) \to \iota, \qquad \mathrm{ap} : \iota \to \iota \to \iota$$7 of open channels, and a proof request can be routed along a path

$$\mathrm{lam} : \iota \to (\iota \to \iota) \to \iota, \qquad \mathrm{ap} : \iota \to \iota \to \iota$$8

using onion-encrypted bets analogous to Lightning’s HTLC routing. Each intermediary locks routing fees and bet stake into chained BET scripts. Atomicity is obtained by using nested BET scripts with the same proof deadline $$\mathrm{lam} : \iota \to (\iota \to \iota) \to \iota, \qquad \mathrm{ap} : \iota \to \iota \to \iota$$9 and coordinated hash-lock preimages.

The proposal also gives an odds-to-probabilities interpretation. If one party stakes $o$0 for “no-proof” and the other stakes $o$1 for “proof,” then

$o$2

This realizes a prediction market on theorem provability. The intended application is a large decentralized infrastructure for fast collaborative formalization projects, where most interaction remains off-chain and on-chain activity is limited to opening, closing, or disputing channels.

7. Limitations, operational barriers, and future directions

Several principal challenges are explicitly identified in the current Proofgold ecosystem (Brown et al., 10 Sep 2025). The Lava client alone supports over 200 commands and requires a live Litecoin RPC, DBM libraries, and specific OCaml versions, which steepens the entry barrier. The current PHP front end can be slow on large history queries, and proof scripts lack rich in-browser highlighting. Better semantic search across the HOTG library is needed, including content-based formula retrieval and graph-navigation.

Collaboration flow is also described as incomplete. Integration with the Megalodon Wiki GitHub-Actions pipeline is a start, but peer review and pull-request workflows for theory changes are only rudimentary. At the systems level, scale is a further concern: as the chain grows, on-chain verification of thousands of proofs per hour will strain both storage and compute, and more aggressive Merkle indexing, sharding, or off-chain caching may be required.

For payment channels with proofs, the security assumptions are conventional in form but specialized in content (Brown et al., 10 Sep 2025). They include standard Proofgold-chain finality and timelock security, SHA256 preimage binding, signature unforgeability, correctness of the $o$3 oracle, and the assumption that honest participants periodically watch the chain or use watchtowers. Liquidity management and routing on large graphs are described as mirroring Lightning’s open problems, though they also benefit from the additional semantics of PTLCs.

A common misconception would be to regard Proofgold as merely a blockchain that stores mathematical documents. The system description instead makes proof checking consensus-critical, encodes formal objects as content-addressed ledger entities, and ties economic incentives directly to theorem proving. Conversely, it would also be inaccurate to treat it as only a proof assistant with tokenization: the architecture includes conventional cryptocurrency functionality, a hybrid proof-of-stake/proof-of-burn base layer, transaction submission, block and address inspection, and payment-channel mechanisms.

In summary, Proofgold is a combined cryptocurrency and formal-mathematics platform in which theories, definitions, conjectures, theorems, and proofs are native blockchain objects, proof validation is enforced by the ledger rules, bounties incentivize library development, and payment channels with $o$4 extend the design toward a Lightning-style network for theorem-provability markets and collaborative formalization. The present implementation demonstrates decentralized, machine-checked mathematical knowledge management while also exposing clear constraints in usability, search, collaboration, and scalability.