How to prove and verify a Blocknet payment

Verify a specific Blocknet payment by matching its transaction key and recipient address to the transaction. This guide follows official CLI v1.2.0 and core v0.22.0, checked on October 27, 2026. It covers generating the proof, sharing the right fields and reading the result alongside the payment’s chain status.

How do you prove a Blocknet payment?

Start with the payment you want to establish

Save the full transaction ID from your sending record. The sending guide explains where the official client prints it, while the explorer guide covers finding the transaction and its containing block. A public transaction ID locates the transfer, but the ordinary explorer page does not disclose the private amount paid to a particular address.

Agree which recipient address and payment record you are checking. Use the complete address associated with that payment rather than a shortened label or screenshot. If you paid by name, retain the address used for the transaction. The proof is useful for checking a specific receipt or resolving a payment question with the recipient; it does not establish someone’s real-world identity.

Generate the transaction key in the sending wallet

Attach to your running mainnet core from a terminal:

blocknet attach mainnet

Open the sending wallet and inspect its records inside the interactive shell:

load
address
history

Select the intended wallet file and unlock it through the client if needed. If you need initial setup, use the wallet guide.

Run this command inside the shell, replacing the placeholder with the complete transaction ID:

prove <txid>

The reviewed client accepts a 64-character hexadecimal transaction ID and displays the returned transaction key. The core looks for the transaction on its local chain and checks that the derived key matches its public key. Use the wallet that sent it; generation does not create another payment.

Which information should you share?

Share the transaction ID, returned transaction key and intended recipient address through the agreed channel. The transaction key is specific to this transaction. Keep your recovery seed, spending key, wallet password and wallet-wide private viewing key private. The verifier needs the transaction proof fields, not access to your loaded wallet or its recovery material.

Treat this as deliberate disclosure of payment information: the key and a recipient address let a verifier identify matching outputs, amounts and any recoverable memo in that transaction. Share it with the people who need that evidence. The memo guide explains payment notes; consider their contents before sharing a proof. A key already shared can be copied, so use the recipient’s agreed private channel.

Verify through the documented core API

The official API provides a public proof-verification endpoint that does not require a loaded wallet or bearer token. Prefer a node you control for this procedure. Save the following template as proof.json in a private working folder and replace all three placeholder strings with the actual proof fields. Keep the field names unchanged.

{
  "txid": "REPLACE_WITH_TRANSACTION_ID",
  "tx_key": "REPLACE_WITH_TRANSACTION_KEY",
  "address": "REPLACE_WITH_RECIPIENT_ADDRESS"
}

From that folder, submit the file to your node’s API address:

curl -H "Content-Type: application/json" --data-binary @proof.json http://127.0.0.1:8332/api/verify-proof

Use your configured local port if different; in Windows PowerShell, use curl.exe for this command. The node guide covers running a core. This request checks evidence and does not send coins. Using a remote server instead discloses the submitted proof fields to that operator.

Read key validity and recipient matches separately

First inspect valid. A true value means the transaction key matches the transaction’s public key. Then inspect outputs: entries with match set to true belong to the supplied recipient address. The total_matched field is the sum of their amounts. A valid key can still produce zero matching outputs when the supplied address did not receive that transaction.

The API reports amounts in atomic units: 100,000,000 units equal 1 BNT. Convert the total before comparing it with a BNT-denominated invoice; keep all integer digits rather than rounding early. Check any returned memo against the expected record. Verify the transaction’s inclusion and confirmations separately through your node or explorer. A proof result alone does not tell you that an invoice was fully paid or that funds are currently spendable.

Resolve a mismatch using the original records

For an invalid key, compare the complete transaction ID and transaction key with the sender’s original output. For a valid key with no recipient matches, recheck the full address used for that payment. If the transaction is not found during proof generation, check the node’s network and chain progress: the reviewed generation endpoint requires an on-chain transaction. Follow the sync guide when the local chain is behind.

For pool payouts, your receiving wallet is not the sending wallet that generated the pool transaction. Start with the pool tracking record and your wallet’s incoming history; obtain any sender proof from the actual sender. Coinbase mining rewards also have no sender proof in the reviewed generation endpoint. These distinctions help you select evidence that corresponds to the payment you are checking.

Keep the proof with its purpose and result

Store the transaction ID, recipient address, relevant payment reference and verification result together in your private records. Record which network and node you checked and when you checked it. Retain only the payment information needed for that purpose. Someone receiving the proof can independently repeat the check rather than relying on a screenshot of another person’s result.

A signed message serves a different purpose: it demonstrates control of the signing key for an address and a particular message. Use the payment proof for transaction-specific evidence and the message workflow for an agreed ownership challenge. The view-only guide explains why viewing access remains sensitive even though it cannot authorize spending. Keep each kind of evidence associated with the question it answers.