Proofgold Lightning Network

• Proofgold Lightning Network is an extension of Lightning channels integrating conditional proof bets to settle transactions based on whether a proposition is proven by a deadline.
• The design modifies standard HTLC techniques by introducing custom PTLC scripts that allow participants to wager on provability while preserving off-chain speed and security.
• This system fosters decentralized markets for proof-related outcomes, blending prediction market incentives with efficient channel liquidity and rigorous formal verification.

Proofgold Lightning Network is a proposed extension of Lightning-style payment channel networks to the Proofgold ecosystem in which bidirectional payment channels are augmented so that two parties can bet on whether a proposition will be proven by a certain time. In this construction, parties can request proofs by betting there will be no proof by a certain time, while other parties can provide proofs and be rewarded by betting there will be a proof. The same betting structure may also provide a way to approximate the probability that a certain proposition is provable in the given amount of time. The proposal is presented as a basis for routed proof-related payments and as one possible foundation for a large decentralized infrastructure for fast collaborative formalization projects (Brown et al., 10 Sep 2025).

1. Conceptual basis and relation to Lightning

The starting point is the standard Lightning Network architecture built atop Bitcoin, where bidirectional payment channels use commitment transactions that are revokable and updatable, mediated by secrets, hashes, and time locks. These channels support fast, cheap, off-chain value transfer, while hash timelock contracts enable conditional payments across multiple hops. Proofgold adopts that payment-channel lineage but changes the condition attached to some transfers: instead of conditioning settlement only on revelation of a hash preimage before a timeout, it introduces a condition tied to whether a proposition $P$ has been proven by a deadline $T$ (Brown et al., 10 Sep 2025).

The motivation is specific to Proofgold’s role as a decentralized formalization system. Standard Lightning-like payment channels are described as insufficient when the network is intended not only to transfer value but also to facilitate payments and incentives associated with proving mathematical or logical propositions. The proposed extension therefore turns a payment channel into an instrument for proof requests, proof provision, and proof-contingent settlement. This makes the network simultaneously a payment layer and a mechanism for allocating rewards around theorem-proving outcomes.

The proposal is structurally conservative in one important respect: it does not discard ordinary Lightning mechanisms. Rather, it composes them with a new proof-sensitive output condition. That design choice matters because revocability, unilateral close, and time-bounded recovery remain necessary once adversarial or uncooperative behavior is admitted.

2. Channel construction and proof-contingent outputs

A channel is opened by two users in a 2-of-2 multisig arrangement. The paper gives the illustrative case in which Alice and Bob each deposit 100 Proofgold bars, so the channel starts with Alice:100 and Bob:100. As in Bitcoin Lightning, commitment transactions represent the latest channel state and contain outputs for both parties, protected by HTLC-like scripts. The core extension is a custom output script that makes spendability depend on whether a proposition has been proved by a specified time (Brown et al., 10 Sep 2025).

The central primitive is the Proposition Timelock Contract, written

$\mathsf{p}(P, \beta, T, \alpha),$

where $P$ is a proposition hash, $\beta$ is Bob’s address, $T$ is an expiry block height or time, and $\alpha$ is Alice’s address. This output is spendable by Bob immediately, if and only if $P$ has been proven on-chain, by providing a signature for $\beta$ using the new Proofgold-specific opcode $\mathsf{OP\_PROVEN}$. It is spendable by Alice after time $T$0 by providing a signature for $T$1 using $T$2.

To preserve revocability and prevent exploitation of revoked states, the PTLC is wrapped inside an HTLC-style shell: $T$3 Here $T$4 is the hash of a secret known only to one party, $T$5 is a revocation address, and $T$6 is a timelock measured in blocks. If the secret is revealed, the counterparty can sweep the output immediately; if not, then after $T$7 blocks the script defaults to the PTLC, which decides whether $T$8 or $T$9 can spend based on provability of $\mathsf{p}(P, \beta, T, \alpha),$0 and current blocktime.

Component	Purpose	Technical implementation
Bidirectional Payment Channel	Fast, cheap, off-chain value transfer between parties	2-of-2 multisig, revocable commitment transactions, HTLCs
PTLC	Conditional transfer based on provability of a proposition $\mathsf{p}(P, \beta, T, \alpha),$1	$\mathsf{p}(P, \beta, T, \alpha),$2 using $\mathsf{p}(P, \beta, T, \alpha),$3, $\mathsf{p}(P, \beta, T, \alpha),$4
Combined HTLC/PTLC Output	Revocable, conditional, secure settlement of proof bets	$\mathsf{p}(P, \beta, T, \alpha),$5

The paper’s canonical betting example assigns asymmetric stakes. Alice bets 50 bars that there is no proof of $\mathsf{p}(P, \beta, T, \alpha),$6 by $\mathsf{p}(P, \beta, T, \alpha),$7, while Bob bets 10 bars that there will be a proof of $\mathsf{p}(P, \beta, T, \alpha),$8 by $\mathsf{p}(P, \beta, T, \alpha),$9; the winner takes the 60-bar pot. New commitment transactions are then constructed with the ordinary balance outputs plus the combined HTLC/PTLC output representing the wager. State advancement proceeds in the standard Lightning manner: the parties sign and exchange the new commitments and revoke the previous state by sharing secrets.

3. Settlement semantics, unilateral close, and routed proof bets

Settlement admits both cooperative and non-cooperative paths. If Bob produces or provides a proof of $P$0 before $P$1, Alice may cooperatively update the state to Alice:50 and Bob:150. If she does not cooperate, Bob can publish the proof and the current commitment, and the proof is checked on-chain via $P$2, allowing Bob to claim the 60 bars after the waiting window. If no proof of $P$3 appears by $P$4, Alice claims the 60 bars after $P$5 through her PTLC branch, producing the updated allocation Alice:110 and Bob:90 (Brown et al., 10 Sep 2025).

The design also includes an explicit race condition. If a proof is found during the timeout window between $P$6 and $P$7, both sides may race to claim. The stated incentive effect is that a participant who wants to secure a win is encouraged to publish the proof quickly on-chain. The settlement model is therefore not purely off-chain: off-chain agreement is the fast path, but unilateral publication to the blockchain is the fallback path when one party acts uncooperatively.

These channels are intended to compose into a network in the same general fashion as Bitcoin Lightning. The paper gives an Alice-Bob-Charlie example in which Alice bets Bob about $P$8’s provability and Bob hedges by placing an analogous bet with Charlie. If $P$9 is not proven by $\beta$0, Bob’s wins and losses across the two channels offset, making him a “parimutuel” middleman. More generally, conditional proof bets can be routed through multiple parties, middlemen can charge fees, and successful routing requires sufficient liquidity across the route.

A further operational constraint is temporal. Opening a channel is on-chain, and Proofgold’s block time is described as 1hr, so opening is slow. By contrast, updates based on new commitment transactions with combined HTLC/PTLC outputs are off-chain and instant. This asymmetry reinforces the architectural role of channels as long-lived bilateral relationships over which many proof-related conditional payments can be expressed.

4. Prediction-market interpretation and collaborative formalization

The same mechanism has a second interpretation as a prediction market for provability. The actual betting odds offered and accepted encode information about the perceived likelihood that $\beta$1 will be proven by $\beta$2. In the paper’s numerical example, if Alice is willing to bet 50 for Bob’s 10, the implied probability is

$\beta$3

or 1 in 6 that $\beta$4 will be proven by $\beta$5 (Brown et al., 10 Sep 2025).

With multiple participants making and matching offers over time, the network yields an implicit market probability for provability. The incentive logic is explicitly informational: if someone has a proof, that participant will snap up all available “it won’t be proven” bets, pushing the implied probability toward 1; if someone has a refutation or is convinced that the proposition cannot be proven, the opposite pressure applies. The paper therefore treats the channel extension not only as a settlement primitive but also as a market mechanism for aggregating dispersed beliefs about proof existence within a time bound.

This prediction-market reading should not obscure the more immediate application to proof bounties and collaborative formalization. The network is described as enabling users to hedge, offer, and accept bets dynamically, routing them across a network and thereby creating a global, decentralized market for proof production and verification. The resulting system is characterized as a decentralized and dynamic formalization bounty board. Since payment for proofs and bounties can be resolved off-chain rather than through slower mainchain procedures, the proposal emphasizes speed, dynamic adjustment of offers, and incentive alignment around producing and publishing proofs.

5. Security model and formal-verification context

The Proofgold proposal reuses Lightning-style revocation, timelocks, and unilateral close, so its security context is naturally illuminated by formal verification work on the Lightning Network. A TLA$\beta$6 formalization of Lightning models participants, payment channels, HTLCs, channel updates, channel close, penalties, a global LedgerTime module, and multi-hop payments. Because the full state space becomes too large for direct model checking, that work introduces intermediate specifications and uses a chain of refinements justified by TLC model checking where feasible and by pen-and-paper proof elsewhere (Grundmann et al., 2023).

The verified security properties in that Lightning formalization include that honest users can always retrieve at least their correct balance and that, after multi-hop payments, the amount is deducted from the sender, intermediaries do not lose funds, and the recipient is credited. At the highest abstraction level, the ideal payment network specification tracks externally visible balances, payment records, and honesty or fault of participants, and security is argued through invariants stating that dishonest users cannot steal funds and that balance changes correspond only to legitimate payment evolution.

For the Proofgold setting, this background is significant because the extension is not merely a new asset-flow pattern; it adds a new settlement predicate, namely provability of $\beta$7 by time $\beta$8, while retaining adversarial concerns about revoked transactions and non-cooperative closes. This suggests that any full formal verification of the Proofgold extension would need to model the composed contract

$\beta$9

together with the semantics of $T$0, the timing relation between $T$1 and $T$2, and the race condition around publication of proofs. The proposal itself describes implementation and protocol mechanics, not such a completed proof of correctness.

6. Operational considerations: privacy, liquidity, and intermediary economics

The Proofgold design states that conditional proof bets require sufficient liquidity across the route and that middlemen can charge fees. Those requirements place the proposal squarely within the broader operational literature on payment channel networks. On the privacy side, route discovery in payment channel networks can reveal critical information about transacting entities; LightPIR addresses this by combining hub labeling with private information retrieval so that a source can discover a shortest path to its destination without revealing any information about the endpoints of the transaction (Pietrzak et al., 2021).

On the liquidity side, Lightning research has defined a network imbalance measure and studied proactive rebalancing through circular payments. In the cited simulation on a recent Lightning snapshot, the imbalance distribution after the heuristic is applied has a Kolmogorov-Smirnoff distance of 0.74 relative to the original distribution; the success rate of a single unit payment rises from 11.2% on the imbalanced network to 98.3% in the balanced network; and the median possible payment size across all pairs of participants increases from 0 to 0.5 mBTC for initial routing attempts on the cheapest possible path (Pickhardt et al., 2019). Since the Proofgold paper explicitly notes route-level liquidity requirements, a plausible implication is that analogous rebalancing problems would arise once proof bets are routed through many intermediaries.

Intermediary economics are similarly relevant. Research on payment channels formalizes the problem of choosing where to establish channels and how much fee to charge so as to maximize financial gain, proves the resulting optimization problem NP-hard, and gives a greedy approximation strategy that is at least a factor two better than other strategies in simulation on real-world Lightning data (Ersoy et al., 2019). Because the Proofgold network likewise envisages fee-charging middlemen, the same tension between efficient routing, collateral lock-up, and fee-setting strategy is likely to govern participation incentives.

The Proofgold proposal therefore sits at the intersection of several established payment-channel concerns: correctness of revocable off-chain state transitions, private multi-hop route discovery, dynamic liquidity management, and the economics of intermediary participation. The technical protocol and all requisite commands are implemented in the Proofgold Lava client, but the larger network-level questions remain those already familiar from Lightning-style systems, now recast around proof-contingent payments and the market for formal proofs (Brown et al., 10 Sep 2025).