Ransomware operators sometimes claim a victim has paid when they haven’t, and victims occasionally claim non-payment when they have. The blockchain is the ground truth. This tutorial walks through verifying a claimed payment from start to finish using free tools.
Step 1: Get the alleged transaction details
You need either the transaction hash, the receiving wallet address, or the date/amount window claimed. With one of these you can find the others.
If the operator’s leak site lists a wallet (common for the negotiation contact form), grab that. If the victim’s negotiator has the receipt-style transaction confirmation, that’s better. Most ransom payments are in BTC; some operators take USDT or Monero (Monero can’t be verified on-chain, that’s the whole point of Monero).
Step 2: Look up the wallet
Drop the receiving address into Mempool.space. The page shows every transaction sent to or from that address, confirmation count, value, timestamp. Visually inspect the recent transactions for one that matches the claimed amount and date.
Cross-reference with Blockchain.com Explorer or OXT.me to confirm. The same transaction should show up identically in all three.
Step 3: Confirm the amount in fiat
Ransom demands are usually quoted in fiat. Convert the claimed BTC amount to fiat using the BTC/USD rate at the transaction’s timestamp, CoinGecko’s historical chart works for this. If the dollar value matches the claimed demand within a few percent, it’s almost certainly the payment. Off by 50%? That’s a different transaction.
Step 4: Confirm sender authenticity
The trickier question: did the victim actually send this payment, or did the operator self-fund the wallet to fake a paid-victim list?
Click into the transaction on Mempool. The “Inputs” panel shows the sending addresses. Run those through WalletExplorer, if WalletExplorer labels the cluster as a known exchange (Coinbase, Kraken, etc.), that’s consistent with a real victim payment from a fiat-funded exchange account. If the input cluster is itself unlabelled and small, it might be the operator self-staging.
Step 5: Check Ransomwhe.re for known operator wallets
Ransomwhe.re is a public, crowdsourced database of wallets attributed to ransomware operations. Drop the receiving address, if it’s already there with attribution, you have a strong starting point. If it’s not, consider submitting it (after you’ve finished your own verification).
Step 6: For ETH/USDT instead
Same workflow but on Etherscan for ETH and ERC-20 USDT, or Tronscan for TRC-20 USDT. The “Token Transfers” tab shows all stablecoin movements. Same logic on confirming amount, sender cluster, exchange labels.
Step 7: Document the verification
Save: the transaction hash, the receiving address, the timestamp in UTC, screenshots of the explorer pages, the BTC/USD rate at timestamp, the WalletExplorer labels for input cluster. The transaction hash is the immutable evidence, anyone can independently verify everything else from that one string.
Step 8: Common scenarios and what they mean
Operator claims victim paid; victim denies. If you can find a transaction matching amount + date going to the operator’s wallet from an exchange-cluster sender, the victim is likely lying. Some companies pay quietly to avoid disclosure obligations. Public-record transparency benefits when these are documented.
Victim claims paid; operator continues to publish data. Blockchain confirms payment happened. Operator violated the agreement. Goes into the operator’s reputation track record, research firms factor this when advising future victims.
No transaction found. Either the payment was on a non-public chain (Monero), the addresses you have are wrong, or the payment never happened. All three are worth distinguishing.
The blockchain doesn’t lie, and these tools are free. Anyone willing to spend an hour can verify or refute most ransom-payment claims with public-record evidence. That capability changes the dynamics of how victims, operators, and journalists negotiate the truth.