FAQ

Common questions about how this works.

Basics

What is VerifyBTC?

A service for verifying Bitcoin ownership. The holder signs a message with their private key. We verify the signature cryptographically. The result is a timestamped report.

How does verification work?

1. You submit the Bitcoin address and claimed amount.

2. The holder receives a unique message to sign.

3. They sign using their wallet software.

4. We verify the signature and query the blockchain for the current balance.

5. A PDF report is generated with the results.

How long does verification take?

The cryptographic verification is nearly instant. Total time depends on how quickly the holder completes the signing step. Most verifications complete in under a minute.

Do you support other cryptocurrencies?

No. Bitcoin only. Each blockchain has different signature schemes and address formats. We focus exclusively on Bitcoin to do one thing well.

Technical

What are BIP-137, BIP-322, and BIP-127?

BIP-137 and BIP-322 are Bitcoin message-signing standards. They let someone prove control of an address without creating a transaction or revealing a private key. BIP-322 is the modern format for SegWit, Taproot, and script-based addresses. BIP-127 is different: it is a proof-of-reserves format for showing control of reserve UTXOs.

What address formats are supported?

All standard Bitcoin address formats: P2PKH (1...), P2SH-P2WPKH (3...), P2WPKH (bc1q...), and P2TR (bc1p...).

Which wallets are supported?

Any wallet that implements BIP-137 or BIP-322 message signing can be used. Exact support varies by wallet version and address type. Legacy addresses often use BIP-137. SegWit and Taproot proofs should use BIP-322 where the wallet supports it.

Do you support proof of reserves?

Yes. VerifyBTC treats proof of reserves as a separate workflow from single-address ownership. BIP-127 reserve proofs bind UTXOs to a commitment message and network. They are useful for custodians, treasury desks, and larger audit workflows. A reserve proof does not replace liabilities review or ongoing monitoring.

How does test mode affect Bitcoin addresses?

Production mode accepts mainnet addresses such as bc1, 1, and 3. Test mode accepts test-network addresses such as tb1, m, n, and 2. The frontend and backend both validate the selected mode so a mainnet proof is not mixed with a test-mode verification.

How do tamper-evident reports work?

Each report includes a SHA-256 hash of its contents.

SHA-256 produces a 256-bit digest from any input. Even a single bit change produces a completely different output.

When we generate a report, we compute the hash and embed it in the document. We also store it separately.

Any modification to the PDF after generation will cause the hash to no longer match. This can be verified independently by anyone with the original hash.

Where are generated reports stored?

Reports are stored in private object storage and served through authenticated VerifyBTC download endpoints. Dashboard users need an active session. Public API clients need the same API key that owns the verification. Raw bucket URLs are not exposed.

What does a certificate fingerprint page prove?

The public fingerprint page gives reviewers a stable URL for comparing a SHA-256 hash copied from a VerifyBTC report. It does not expose private verification records. Reviewers should compare the fingerprint with the one printed in the PDF report.

What are spending conditions?

Each verification report includes a spending conditions assessment based on the address type.

Unrestricted: Standard addresses (P2PKH, P2WPKH) where the owner can spend immediately with their private key.

Unknown: Script-based addresses (P2SH, P2WSH, P2TR) that may contain timelocks, multisig requirements, or other spending restrictions not visible from the address alone.

This matters for collateral: an address with unknown conditions might have Bitcoin locked until a future date, or require multiple signatures to spend. Lenders should be aware that script-based addresses could have restrictions preventing immediate liquidation.

Security

Do you have access to private keys?

No. The signing operation happens entirely within the holder's wallet. We receive only the signature, which is public data. Private keys never leave the wallet.

Can a signature be forged?

No. ECDSA signatures are computationally infeasible to forge without the private key. The same cryptography secures every Bitcoin transaction. If someone could forge signatures, they could steal any Bitcoin. This has never happened.

What if the balance changes after verification?

Verification proves control at a specific moment in time. Bitcoin can be moved at any time after signing. For ongoing collateral arrangements, periodic re-verification is recommended. Each report includes a timestamp and the balance at that exact moment.

Business

Do you support multi-signature wallets?

Yes. When creating a verification for a multisig address, provide the signing threshold and public keys. Each keyholder then visits the verification link and signs individually with their own wallet. The system tracks progress and completes verification once the required number of signatures is collected. For example, a 2-of-3 multisig requires any 2 of the 3 keyholders to sign.

Is there a free tier?

Yes. The first 3 verifications are free. No payment information required. Pricing for additional verifications is listed on the pricing page.

Is there an API?

Yes. A REST API is available for programmatic access. You can create verification requests, check status, validate BIP-127 reserve proof packages, and retrieve reports. Webhooks notify you when verifications complete. Use idempotency keys when creating verifications from your own backend so retries do not create duplicates.

Limits & Quotas

How are verification quotas shared?

Verification and API request quotas are shared across your entire organization. All team members draw from the same monthly pool. For example, if your plan includes 100 verifications per month, that's 100 total across all members — not 100 per person. Organization admins can set individual member limits through the admin panel to control how the quota is distributed.

What happens when I reach my quota limit?

When your organization reaches its monthly verification or API request limit, new requests will be declined with a quota exceeded error. You can upgrade your plan at any time from the Billing page to increase your limits. Usage counters reset automatically at the start of each billing period.

When do my usage counters reset?

Usage counters reset at the start of each billing period. For paid plans, this aligns with your subscription renewal date. You can see your current usage and reset date on the Billing page in your dashboard.

Privacy

What information do you collect?

For accounts, we store email addresses, optional names, organization membership, roles, billing status, and security settings.

For verifications, we store the Bitcoin address, claimed amount, challenge message, submitted signature or signatures, status, timestamps, balance snapshot, optional customer email, optional notes or case context, report hash, and report storage reference.

For API and webhook use, we store API key names, API key hashes, usage counters, webhook endpoint URLs, selected webhook events, webhook signing secrets, audit records, and security logs such as IP address, browser, and request timestamps.

What do you never collect?

We never collect private keys, seed phrases, wallet passwords, or anything that can move Bitcoin. Wallet signing happens inside the holder's wallet. We receive only the resulting signature. We also do not store card numbers; payments are handled by Stripe.

What is encrypted or hashed?

Bitcoin addresses and 2FA secrets are encrypted at the application layer using AES-256-GCM before they are stored. A database-only breach would not reveal plaintext Bitcoin addresses without the separate encryption key.

Passwords use Argon2id hashes. API keys and 2FA backup codes are stored as hashes; the raw API key is only shown when it is created or rotated.

Other service records, such as signatures, statuses, timestamps, customer email, notes, report hashes, storage keys, billing references, and audit records, are stored as operational records rather than separately field-encrypted.

Who can access generated reports?

Reports are stored in private object storage and served through VerifyBTC download endpoints. Dashboard users need an active session, and public API clients need the API key that owns the verification. Raw bucket URLs are not exposed. Report PDFs are not separately encrypted by the app in the current implementation.

How long do you keep verification records?

Verification records and generated reports are kept for 7 years for audit, legal, and compliance purposes. Account data is kept until the account is deleted. Usage and security logs are kept for a shorter operational period, described in the privacy policy.

Something else? Email us:

support@verifybitcoin.io