verifymessage

verifymessage checks that a base64 signature was produced by the private key behind a given Bitcoin address for a specific message. It lets someone prove control of an address — and therefore of the BTC sitting at it — without ever revealing the key or moving any coins. You pass the address, the signature, and the exact message, and the node recovers the signing key and confirms it matches the address. This is a stateless cryptographic check: no wallet is touched and nothing is written on chain. Call it with positional parameters against https://bitcoin.therpc.io/YOUR_API_KEY.

Use cases

• Verify proof of address ownership in a sign-in or onboarding flow, confirming a user controls the BTC address they claim before granting access.
• Check a signed message attached to a support or refund request, so you can be sure the requester actually holds the address in question.
• Validate an off-chain attestation or agreement that a party tied to a specific Bitcoin address, without requiring any on-chain transaction.

Parameters

Response

Example request

1curl https://bitcoin.therpc.io/YOUR_API_KEY \
2  -X POST \
3  -H "Content-Type: application/json" \
4  -d '{
5  "jsonrpc": "1.0",
6  "id": "therpc",
7  "method": "verifymessage",
8  "params": [
9    "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa",
10    "H0b...=",
11    "hello"
12  ]
13}'

Errors & troubleshooting

Common pitfalls

• This method only supports the legacy (P2PKH) message-signing scheme. Signatures for segwit addresses use different conventions (such as BIP 322) and will not verify here, so expect failures if you feed it bech32-address signatures.
• A false return means the signature simply did not match the address and message — it is a valid outcome, not an error. A malformed address (code -5) or non-base64 signature (code -3) raises an error instead; handle those two cases separately from a plain false.

Supported networks

• Mainnet
• Testnet

See also

• validateaddress
• decodescript