The check is smaller than the claim it gets asked to settle
A signed Bitcoin message tends to arrive as if it ends an argument: here is proof. What the verification actually establishes is much narrower. A successful check means the supplied signature satisfies the rules that apply to the supplied message and address, under any time conditions the result reports. It does not identify who signed, does not say what funds they hold today, and does not authorize a payment. Each of those is a separate question that needs its own evidence.
Which conditions were actually checked
Under BIP322 the verifier takes an address, a signature and a message, then evaluates the transactions that the proof constructs and the script rules that govern the address. A less obvious consequence is that a valid proof need not even contain an ordinary cryptographic signature; what counts depends on the address’s script. So the question worth asking is not whether the proof looks convincing but which conditions were actually checked, because that is exactly what the result vouches for.
Three claims the message cannot carry
Identity is the first. BIP322 is explicit that a key holder can sign messages on another person’s behalf while refusing to sign real transactions, and that the scheme cannot establish who sent a prior transaction. The proof shows that whoever produced it controlled the relevant key. It does not attach a name to that key.
Current funds are the second. The proof-of-funds variant lets the signer choose which unspent outputs to include, so it does not establish completeness, and a check run offline cannot confirm those outputs still exist on-chain. If the question is what a party can spend right now, request a current-chain check and record when it was performed.
Solvency is the third, and the one most often overclaimed. A selected set of outputs is silent about omitted assets and liabilities, and no signed message, however carefully formed, turns that into a reserve attestation.
Read the result as a state, not a verdict
BIP322 separates invalid, inconclusive and valid outcomes. A failed required check is invalid. A script the verifier cannot evaluate, or a failure of the specified upgradeable rules, is inconclusive, which is neither accepted nor rejected. A successful result carries time conditions: a locktime value and a sequence value. Hold on to those; they describe the result’s window, not the moment someone signed.
Decide what the proof must support, before verifying
The durable safeguard is to write down the decision the message is meant to support before checking it. A fresh challenge that names the purpose, the verifier and the session makes it harder to replay a message from one context into another, the domain-separation concern that BIP340 addresses with its tagged hashes. But a careful challenge narrows the claim; it does not remove the limits of cooperative signing or reveal who physically holds the key.
The acceptance record then reduces to a short list: was the format supported, what did the script check return, what was the challenge context, and is current-chain evidence still needed. A message that clears those four items is evidence for exactly one decision, and nothing beyond it.
Source: BTCUSA.