Payment Proof

What Is a Payment Proof?

A payment proof is cryptographic evidence confirming that a payment was successfully sent and received. In the context of Bitcoin and its Layer 2 networks, payment proofs take different forms depending on the protocol, but they all share one property: anyone can independently verify them using mathematics rather than trusting a third party.

Traditional payment systems rely on attestations: a bank statement or receipt confirms a payment because the bank says it happened. If the bank disputes the record, resolving the conflict requires legal processes. Cryptocurrency payment proofs work differently. They are rooted in hash functions, digital signatures, and consensus rules that make them independently verifiable by anyone with access to the relevant data.

How It Works

The mechanism behind a payment proof depends on the protocol layer. Each layer of the Bitcoin ecosystem produces a distinct type of proof with different security properties and verification methods.

On-Chain Bitcoin: Transaction ID

On the Bitcoin base layer, the payment proof is the TXID: a 64-character hexadecimal string produced by applying SHA-256 twice (double-SHA256) to the serialized transaction data. Once the transaction is included in a block and confirmed by subsequent block confirmations, the TXID becomes an immutable record on the blockchain.

Verification is straightforward: paste the TXID into any block explorer to view the inputs, outputs, amounts, fees, and confirmation count. Because every full node stores the complete blockchain, anyone can verify a TXID independently without trusting a third party.

# Verify a Bitcoin payment using bitcoin-cli
bitcoin-cli gettransaction <txid>

# Check confirmation count
bitcoin-cli getrawtransaction <txid> true | jq '.confirmations'

# Example TXID (64-character hex string)
# a1b2c3d4e5f6...  (SHA-256d of serialized transaction data)

Lightning Network: Payment Preimage

On the Lightning Network, the payment proof is the payment preimage: a random 32-byte secret generated by the recipient. The recipient computes a payment hash (SHA-256 of the preimage) and embeds it in a BOLT 11 invoice. The BOLT 11 specification states explicitly: "Preimage of this provides proof of payment."

The payment flow creates a chain of HTLCs across the route, each locked to the same payment hash. When the recipient claims the payment by revealing the preimage, it propagates backward through each hop. The sender receives the preimage as final confirmation: only the original recipient could have produced a value that hashes to the payment hash in the invoice.

1. Recipient generates a random 32-byte preimage (R) and computes its hash: H = SHA-256(R)
2. Recipient encodes H into a Lightning invoice and sends it to the payer
3. Payer routes HTLCs through the network, each locked to hash H
4. Recipient reveals R to claim funds; R propagates back to the sender
5. Sender stores R as cryptographic proof that the payment reached the intended recipient

# Decode a Lightning invoice to see the payment hash
lncli decodepayreq <bolt11_invoice>

# After payment, retrieve the preimage (proof of payment)
lncli listpayments | jq '.payments[-1].payment_preimage'

# Verify: SHA-256 of the preimage must equal the payment hash
echo -n "<preimage_hex>" | xxd -r -p | sha256sum

Spark: Signed VTXO Transfer

On Spark, payment proofs work through cryptographic key rotation. Spark uses a 2-of-2 multisig model where the user holds one key and the Spark Operators collectively hold the other via FROST threshold signatures. When a transfer occurs, the operators generate a new key share for the recipient and delete the sender's old key share, making the transfer irreversible.

The recipient's proof of ownership consists of valid key shares that, combined with the operator key shares, can produce a valid Schnorr signature for the underlying on-chain UTXO. The recipient also holds pre-signed exit transactions that allow them to unilaterally withdraw to the base layer if needed.

For payments routed from Spark to Lightning, the Lightning preimage serves as the bridge between proof models: the Service Signing Provider submits the preimage to the Signing Entity, which atomically finalizes the Spark transfer.

Payment Proofs vs. Traditional Receipts

The fundamental difference between cryptocurrency payment proofs and traditional payment receipts is the source of trust. Traditional receipts are attestations by an institution: a bank confirms a wire transfer, a card network confirms a charge. These attestations can be delayed, lost, or disputed.

This shift from institutional trust to mathematical proof is particularly valuable for cross-border payments where multiple banks and jurisdictions complicate dispute resolution.

Use Cases

Merchant Dispute Resolution

In traditional card payments, chargebacks allow buyers to reverse transactions by disputing them with their issuing bank. Merchants bear the burden of proof and lose an estimated 0.5% to 1.5% of revenue to chargebacks and related fees. Cryptocurrency payment proofs eliminate this dynamic entirely: a TXID or preimage is mathematically irrefutable evidence that payment was made.

For Lightning payments, the preimage is especially powerful because it proves the intended recipient received the funds (not just that a transaction was broadcast). This makes Lightning payment proofs well-suited for crypto dispute resolution in commerce.

Accounting Reconciliation

Payment proofs enable automated reconciliation by providing deterministic, timestamped records. Unlike bank confirmations that may arrive hours or days later, on-chain TXIDs are available the moment a transaction enters a block, and Lightning preimages are available within seconds of payment completion.

Businesses can systematically store TXIDs and preimages alongside invoice identifiers, creating a verifiable audit trail. The blockchain itself serves as an immutable ledger: transactions cannot be altered or deleted after confirmation, providing a higher standard of record-keeping than traditional bank statements. See the stablecoin accounting guide for practical implementation details.

Regulatory Compliance

Regulators increasingly require financial institutions to maintain detailed transaction records. Blockchain-based payment proofs provide timestamped, tamper-proof records suitable for audit. The Travel Rule and KYC/AML frameworks require transaction documentation that cryptocurrency payment proofs satisfy natively.

Atomic Cross-Layer Operations

Payment proofs enable trustless coordination across different systems. In a submarine swap, the Lightning preimage serves as the cryptographic link between on-chain and off-chain transactions: claiming one side reveals the proof needed to claim the other. Similarly, Spark uses Lightning preimages to atomically bridge transfers between Spark and the Lightning Network.

Limitations of Keysend Payments

Not all Lightning payment methods produce valid proofs. Keysend payments allow sending funds without an invoice by letting the sender generate the preimage. Because the sender already possessed the preimage before the payment, receiving it back proves nothing: it does not confirm the recipient received the funds. This makes keysend unsuitable for commerce where proof of payment is required.

The upcoming BOLT 12 (Offers) protocol addresses this by introducing "payer proofs" that use BIP-340 Schnorr signatures and Merkle-tree-based selective disclosure. Payer proofs allow a wallet to cryptographically prove it made a payment while selectively revealing only the necessary invoice fields.

Risks and Considerations

Privacy Tradeoffs

On-chain payment proofs (TXIDs) are pseudonymous but publicly visible. Any party with a TXID can view the transaction details, including amounts and addresses. This creates tension between provability and privacy: the same property that makes proofs verifiable also makes transactions traceable via chain analysis.

Lightning preimages are more private since payment details are not publicly broadcast, but a shared payment hash across all hops means any node appearing in multiple payment paths can correlate them. PTLCs aim to solve this by using different cryptographic points at each hop.

Proof Does Not Prove Identity

A TXID proves that specific UTXOs were spent to specific addresses, but it does not inherently prove who controlled those addresses. Similarly, a Lightning preimage proves a payment reached the invoice creator, but does not verify the real-world identity behind the node. Additional identity verification may be required for regulatory or legal purposes.

Storage and Backup

Payment proofs must be stored carefully. On-chain TXIDs can always be recovered from the blockchain, but Lightning preimages exist only in the payer's wallet database. If the wallet is lost or corrupted without a backup, the preimage (and thus the proof) is lost permanently. Businesses accepting Lightning payments should implement robust backup and archival systems for preimage records.

Confirmation Requirements

An on-chain TXID is not fully reliable as proof until the transaction has sufficient block confirmations. A transaction with zero confirmations can still be replaced via replace-by-fee (RBF) or dropped from the mempool. Most merchants require at least one confirmation for small amounts and six or more for larger values.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.