BIP322 is a Bitcoin standard for signing messages with Bitcoin addresses and scripts.
It allows someone to prove that they can satisfy the spending conditions associated with a Bitcoin address without broadcasting an actual Bitcoin transaction.
In simple terms, imagine someone asks:
“Can you prove that you control this Bitcoin address?”
Instead of sending them a small amount of Bitcoin, you can sign a message using the keys or spending conditions associated with that address.
The other person can then verify the signature.
BIP322 was designed to make this process work with modern Bitcoin address types and spending conditions, including SegWit, Taproot, and multisig. The current specification is Complete and is version 2.0.0.
What Is Bitcoin Message Signing?
Bitcoin uses cryptographic signatures to prove that someone can authorize spending from a particular set of coins.
Normally, this happens inside a Bitcoin transaction.
For example:
Bitcoin → Wallet → Transaction → Digital Signature → Network
The signature tells Bitcoin’s network that the person creating the transaction can satisfy the conditions required to spend those coins.
Message signing uses a similar cryptographic idea, but there is an important difference.
Instead of signing a transaction that transfers Bitcoin, you sign a message.
For example:
“I control this Bitcoin address.”
The message itself doesn’t move any Bitcoin.
This can be useful when someone wants evidence that a particular person or organization controls a Bitcoin address.
Why Was BIP322 Needed?
Bitcoin already had message-signing functionality before BIP322.
However, the older system had an important limitation.
It was designed primarily around legacy P2PKH addresses.
As Bitcoin developed, users began adopting newer output types such as:
- P2SH
- SegWit
- P2WPKH
- P2WSH
- Taproot
- Multisig scripts
The old message-signing format wasn’t designed to handle all of these spending conditions in a consistent way.
That created a problem.
Imagine a wallet has a modern Taproot address.
The wallet owner may control the coins perfectly well, but an older message-signing system might not provide a standardized way to prove control of that address.
BIP322 was created to generalize message signing around Bitcoin Script, allowing message proofs to reflect the same spending conditions that Bitcoin uses for actual funds.
BIP322’s Basic Idea
The easiest way to understand BIP322 is this:
If you can satisfy the spending conditions for a Bitcoin output, you can use those same conditions to prove control of it in a signed-message protocol.
That is the key idea behind the standard.
Instead of creating a completely separate signature system for every type of Bitcoin address, BIP322 builds the message-signing process around Bitcoin’s existing transaction and scripting model.
This makes the system much more flexible.
For example, the same general framework can support:
- Single-signature wallets.
- SegWit addresses.
- Taproot outputs.
- Multisig arrangements.
- Other scripts that Bitcoin can validate.
Bitcoin Optech describes this as generic message signing: if a wallet can spend from a script, it can use that spending ability to sign a message for the same script.
Does Signing a Message Spend Bitcoin?
No.
This is one of the most important things to understand.
When you sign a BIP322 message, you aren’t sending Bitcoin to anyone.
You aren’t creating a normal transaction that miners can confirm.
Instead, BIP322 creates a special signing structure that represents what would need to be satisfied to spend from the relevant Bitcoin output.
The process therefore gives you a way to demonstrate control without transferring your coins.
Think of it as:
Normal transaction
“I authorize spending these Bitcoin.”
versus:
Signed message
“I can demonstrate that I control the spending conditions associated with this Bitcoin output.”
The second action doesn’t move the funds.
Why Not Just Send a Tiny Bitcoin Transaction?
You might wonder:
“Why do we need message signing? Couldn’t I just send someone a tiny amount of Bitcoin to prove I control the address?”
Technically, you could send a transaction.
But that creates unnecessary problems.
First, you would actually move money.
Second, you would pay a transaction fee.
Third, the transaction would become part of Bitcoin’s public blockchain history.
Finally, sending a transaction doesn’t necessarily prove the exact thing someone wants you to prove.
Message signing provides a way to demonstrate control without requiring an actual payment.
That can be much more convenient for certain situations.
What Can BIP322 Be Used For?
BIP322 has several potential applications.
Proving Control of a Bitcoin Address
Suppose you publish a Bitcoin address and someone wants to verify that you actually control it.
You can sign a specific message.
They verify the signature against the address.
If the verification succeeds, the proof demonstrates that the signer was able to satisfy the address’s spending conditions at the time of signing.
Proof of Funds
BIP322 also defines a Proof of Funds variant.
This goes beyond simply signing a message for one address.
A signer can include additional inputs representing specific UTXOs they want to demonstrate control over.
The resulting proof can therefore demonstrate control over a chosen set of Bitcoin outputs.
This could be useful in situations where someone wants to demonstrate that they control a certain amount of Bitcoin without actually transferring those coins.
However, Proof of Funds has important privacy and interpretation considerations, which we’ll examine later.
Multisig Verification
BIP322 also makes message signing possible for more complicated spending conditions.
For example, consider a 2-of-3 multisig arrangement.
Three different keys exist, but any two must cooperate to spend the funds.
A generic message-signing system needs to understand those same spending conditions.
BIP322’s Script-based design makes this possible.
Multiple wallets can cooperate to produce the necessary signatures or witness data for the message proof.
This is a major improvement over a system designed only around a single private key.
BIP322 and Bitcoin Script
If you’ve read our article on Bitcoin Script, this is where that topic becomes especially useful.
Bitcoin Script defines the conditions that Bitcoin spending transactions must satisfy.
For example, a simple Bitcoin output might require a valid signature from a particular public key.
A multisig output can require signatures from multiple keys.
A Taproot output can use more advanced spending conditions.
BIP322 essentially asks:
“What would someone need to satisfy in order to spend from this output?”
It then uses those same conditions as the basis for the message-signing process.
That’s why BIP322 can support many different Bitcoin output types.
It isn’t trying to reinvent Bitcoin’s spending rules.
It builds on them.
The Virtual Transaction Trick
This is one of the most interesting parts of BIP322.
The standard uses something called virtual transactions.
These look structurally similar to Bitcoin transactions, but they aren’t ordinary transactions that can be broadcast and confirmed on the Bitcoin network.
The current specification defines two virtual transactions called:
to_spend
and
to_sign
The first connects the message to the Bitcoin spending conditions being proved.
The second contains the information needed to demonstrate that those conditions can actually be satisfied.
This approach allows existing Bitcoin transaction-signing concepts to be reused for message signing.
Why Use Virtual Transactions?
There is a practical reason for this design.
Bitcoin wallets already understand how to sign transactions.
Hardware wallets understand transaction signing.
Multisig systems understand transaction signing.
PSBT-based workflows understand transaction signing.
So rather than forcing every wallet to implement a completely unrelated message-signing system, BIP322 makes the message proof resemble a Bitcoin transaction.
That creates a bridge between:
Message signing
and
Bitcoin transaction signing
This is one of the reasons BIP322 can support complicated spending conditions.
Does BIP322 Prove Ownership?
Not exactly.
This distinction is extremely important.
A valid BIP322 signature can demonstrate that the signer was able to satisfy the spending conditions associated with the address or script at the time of signing.
But that doesn’t necessarily prove that:
- The signer is a particular real-world person.
- The signer owns the Bitcoin economically.
- The signer will continue controlling the funds later.
- The signer personally created the address.
- The signer would actually spend the funds.
The BIP itself warns that no message-signing protocol can permanently prove control of funds.
A person could sign a message and then transfer the Bitcoin immediately afterward.
Someone could also willingly sign a message on behalf of another person.
Therefore, a signature is evidence of control under specific conditions—not permanent proof of ownership or identity.
BIP322 vs. a Normal Bitcoin Transaction
Here’s the simplest comparison:
| Feature | Bitcoin Transaction | BIP322 Message |
|---|---|---|
| Transfers Bitcoin | Yes | No |
| Can be broadcast | Yes | No |
| Appears on blockchain | Yes | No |
| Uses Bitcoin spending conditions | Yes | Yes |
| Can demonstrate control | Yes, indirectly | Yes |
| Requires moving funds | Usually | No |
| Can support complex scripts | Yes | Yes |
The important takeaway is that BIP322 borrows Bitcoin’s transaction and scripting concepts without creating an actual payment.
Why BIP322 Matters
Bitcoin has evolved considerably since the original message-signing functionality appeared.
Modern Bitcoin can use SegWit, Taproot, multisig, complex scripts, and PSBT-based workflows.
A message-signing standard that only understands older address formats would therefore become increasingly limited.
BIP322 provides a more general framework.
Its goal is simple:
Make Bitcoin message signing work with the same spending conditions used by modern Bitcoin outputs.
The 2026 update also expanded the standard with a more defined Proof of Funds construction and PSBT-based signing flow, making the current version considerably more capable than the early proposal.
How Does BIP322 Actually Work?
In Part 1, we established the basic idea behind BIP322.
Instead of creating a completely separate system for every Bitcoin address type, BIP322 uses Bitcoin’s existing transaction and scripting concepts to create a standardized message-signing process.
The clever part is that the message isn’t simply signed as a piece of text.
BIP322 creates two virtual transactions:
to_spend → to_sign → Signature
These aren’t normal Bitcoin transactions that move coins on the blockchain.
Instead, they create a structure that allows a wallet or verifier to check whether the signer can satisfy the spending conditions associated with a Bitcoin address or script.
1. The Message Becomes a Hash
Suppose you want to sign this message:
“I control this Bitcoin address.”
BIP322 first creates a specific cryptographic hash of the message.
The current specification uses a BIP340 tagged hash with the tag:
BIP0322-signed-message
The message is used as-is for this hashing step rather than being wrapped in the older message format used by traditional Bitcoin message signing.
Why hash the message?
Because cryptographic signatures normally operate on a fixed-size digest rather than an unlimited piece of text.
The hash also becomes part of the virtual transaction structure.
So conceptually:
Your message → BIP322 message hash → to_spend
2. What Is to_spend?
The first virtual transaction is called to_spend.
Despite its name, nobody actually spends it.
Instead, it represents the connection between the message and the Bitcoin spending conditions being proved.
A simplified version looks like this:
Input: special nonexistent input containing the message hash
Output: the script being proved
The output has a value of zero.
The input refers to a special null outpoint that doesn’t exist on the real Bitcoin blockchain.
That’s intentional.
It means the structure behaves like a transaction for signing and verification purposes without representing an actual spendable Bitcoin transaction.
3. The Bitcoin Address Becomes the Challenge
The Bitcoin address you’re proving control over determines the scriptPubKey used as the message challenge.
This is an important concept.
BIP322 doesn’t simply ask:
“Can you produce a valid signature?”
It asks:
“Can you produce the data required to satisfy the spending conditions associated with this Bitcoin output?”
That distinction allows BIP322 to support more than simple single-key addresses.
For example, the challenge can represent conditions involving:
- P2WPKH
- P2WSH
- P2TR
- Multisig scripts
- Other supported Bitcoin spending conditions
This is one of the major advantages of BIP322’s Script-based design.
4. Then Comes to_sign
Once to_spend has been created, BIP322 constructs a second virtual transaction called to_sign.
This transaction is designed to prove that the signer can satisfy the challenge created by to_spend.
Its first input spends the output of to_spend.
However, to_sign doesn’t send Bitcoin anywhere.
Its output has:
Value: 0 satoshis
and:
Script: OP_RETURN
Again, this is a virtual structure used for verification rather than an actual transaction intended for the Bitcoin network.
The basic relationship is:
Message → to_spend → to_sign → Script verification
5. Why Does This Resemble a Bitcoin Transaction?
This design was chosen partly for compatibility.
Bitcoin wallets already know how to create and sign transactions.
Hardware wallets understand transaction structures.
Multisig wallets understand transaction signing.
PSBT workflows are also based around transaction signing.
By making BIP322 resemble a transaction, existing Bitcoin signing infrastructure can be adapted to message signing.
The BIP specifically describes this as a way to make the format compatible with existing signing hardware.
That’s a clever design choice.
Instead of inventing:
“A completely new way to sign messages.”
BIP322 effectively says:
“Let’s represent the message proof in a form Bitcoin signing systems already understand.”
6. What Does the Wallet Actually Sign?
The wallet needs to satisfy the spending conditions contained in the message challenge.
For a simple single-key SegWit address, that may involve producing a normal cryptographic signature and public key.
For a multisig script, multiple signatures may be required.
For other script types, different witness data may be necessary.
This is why BIP322’s definition of a signature is broader than simply “one digital signature.”
Depending on the script, the resulting proof can contain a complete witness stack, a full virtual transaction, or a PSBT.
7. BIP322 Has Three Main Signature Formats
The current BIP322 specification defines three main formats:
Legacy
The older compact Bitcoin message-signing format.
Simple
A compact witness-based format for supported native SegWit address types.
Full
A complete to_sign transaction.
There is also a specialized Full Proof of Funds variant that uses a finalized PSBT.
Each format has a different purpose and level of flexibility.
8. What Is the Legacy Format?
The Legacy format exists mainly for compatibility with older Bitcoin message-signing systems.
It uses a compact, Base64-encoded ECDSA signature and is restricted to the traditional P2PKH address format under the current specification.
New proofs should generally use the newer BIP322 formats, even when proving control of a P2PKH address.
So you can think of Legacy as:
Old Bitcoin message signing → kept for compatibility
while BIP322’s newer formats provide the generalized approach.
9. What Is the Simple Format?
The Simple format is designed for certain native SegWit address types.
These include:
- P2WPKH
- P2WSH
- P2TR
with some script limitations.
Instead of including the entire virtual transaction, the Simple format provides the necessary witness stack.
The signature is encoded using Base64 and carries the human-readable prefix:
smp
That prefix helps a verifier identify which BIP322 signature format it is dealing with.
For a compatible simple address, the basic process is therefore:
Message → to_spend → to_sign → witness stack → smp signature
10. What Is the Full Format?
The Full format provides more flexibility.
Instead of sending only the witness stack, the signer provides the complete to_sign transaction.
The encoded signature uses the prefix:
ful
This allows the verifier to inspect the complete virtual transaction and validate it against the BIP322 rules.
The Full format becomes particularly useful when the signing conditions are more complicated or when additional transaction information needs to be represented.
11. How Does BIP322 Support Multisig?
This is one of the most useful features.
Imagine a company controls Bitcoin using a 2-of-3 multisig wallet.
Three keys exist:
- Key A
- Key B
- Key C
But two keys must cooperate to satisfy the spending condition.
A traditional single-signature message system isn’t naturally suited to this arrangement.
BIP322 can represent the multisig spending conditions using Bitcoin Script.
The different signers can therefore cooperate to create the required witness or transaction data.
In practice, the coordination can resemble the process used to sign a normal multisig transaction.
This is possible because BIP322’s newer signing workflows use PSBT infrastructure.
12. What Is a PSBT?
If you’ve read our article on PSBTs, you’ll recognize this part.
PSBT stands for:
Partially Signed Bitcoin Transaction
A PSBT allows different parties or devices to work on the same transaction-signing process without immediately broadcasting the transaction.
For example:
Wallet → Hardware Wallet → Multisig Signer → Finalization
Each participant can add the information or signatures they are responsible for.
BIP322 now uses this same concept for message signing.
The current specification defines a new PSBT global field called:
PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE
This field carries the UTF-8 encoded message being signed.
13. Why Is PSBT Support Important?
PSBT support makes BIP322 much more practical for advanced wallets.
Consider a multisig organization.
Instead of asking everyone to implement a completely separate message-signing protocol, the participants can use a PSBT-style workflow similar to the one they already use for Bitcoin transactions.
One signer can create the signing request.
Another device can review it.
Another signer can add its signature.
The process can continue until the spending conditions have been satisfied.
The BIP doesn’t define exactly how multiple signers must coordinate, but it says the process should closely resemble multisig transaction signing.
14. What Does the Hardware Wallet See?
This is an important security detail.
A BIP322 PSBT technically contains a transaction-like structure.
However, the user should not be misled into thinking they’re sending a transaction.
The current BIP says the signer should inform the user about:
- The message being signed.
- The Bitcoin address or challenge being signed for.
The hardware wallet interface should therefore present the operation as a message signing request, rather than suggesting that the user is spending Bitcoin.
That’s important because signing something you don’t understand can be dangerous.
15. What Is Proof of Funds?
BIP322 also defines a more advanced variant called Proof of Funds.
The basic message-signing process demonstrates control of the spending conditions associated with a particular address.
Proof of Funds goes further.
The signer can include additional UTXOs that they want to demonstrate control over.
For example, suppose someone wants to prove that they control several Bitcoin outputs.
Instead of signing a separate message for every address, the Proof of Funds construction can include those UTXOs as additional inputs in the virtual signing structure.
This makes the proof more flexible.
16. Does Proof of Funds Prove How Much Bitcoin Someone Owns?
Not necessarily.
This is a very important limitation.
The signer chooses which UTXOs to include.
The list does not prove that those are all the Bitcoin they control.
It also doesn’t automatically prove that every listed UTXO is still unspent.
A verifier needs to consult the blockchain to determine whether the referenced outputs currently remain unspent.
So if someone proves control over:
5 BTC
that doesn’t automatically mean:
“This person owns exactly 5 BTC.”
They could control additional Bitcoin elsewhere.
The proof only demonstrates control of the particular outputs included in the proof.
17. How Does Proof of Funds Work?
The basic concept looks like this:
Message
↓
Address challenge
↓
to_spend
↓
to_sign
↓
Additional UTXOs added
↓
Sign the required inputs
↓
Finalize PSBT
↓
pof Proof of Funds
The current BIP322 specification represents the final Proof of Funds signature as a Base64-encoded finalized PSBT with the prefix:
pof
This is one of the significant changes introduced by the current version of the standard.
18. Why Would Someone Use Proof of Funds?
There are several possible applications.
OTC Trading
A trader could demonstrate control of selected Bitcoin before entering a large transaction.
Business Verification
A company could demonstrate control over certain reserves without transferring them.
Financial Negotiations
Participants could provide evidence that they control specific UTXOs.
Audits
An organization could prove control of selected outputs at a particular point in time.
However, users should interpret these proofs carefully.
A Proof of Funds message doesn’t automatically establish someone’s complete financial position.
19. BIP322 Verification
So what happens when someone receives a BIP322 signature?
The verifier has three main pieces of information:
Bitcoin address
Message
BIP322 signature
The verifier reconstructs the required to_spend structure from the message and address.
It then checks the provided signature or transaction structure.
Finally, it evaluates whether the relevant Bitcoin Script spending conditions are satisfied.
If everything checks out, the verifier can report the proof as valid, subject to the rules and any applicable timelocks.
The current specification also allows a validator to return inconclusive when it cannot fully evaluate the scripts involved.
Why BIP322 Is More Than “Sign a Message”
At first glance, BIP322 sounds like a simple feature:
Write message → click sign → verify signature
But underneath, it is much more sophisticated.
BIP322 connects:
Messages
with:
Bitcoin transactions
with:
Bitcoin Script
with:
Wallet signing
with:
PSBTs
This is what allows one standard to work across many different Bitcoin spending conditions.
It also explains why BIP322 can support advanced use cases such as multisig and Proof of Funds.
A Simple Mental Model
If all the technical details feel complicated, remember this model:
Step 1
You provide a message.
Step 2
BIP322 hashes that message.
Step 3
The message hash becomes part of to_spend.
Step 4
Your Bitcoin address or script becomes the spending challenge.
Step 5
to_sign references to_spend.
Step 6
Your wallet satisfies the spending conditions.
Step 7
The resulting proof is encoded as a Legacy, Simple, Full, or Proof of Funds format.
Step 8
Another person can independently verify the proof.
No Bitcoin needs to move.
What Are the Advantages of BIP322?
BIP322 solves a problem that became increasingly important as Bitcoin developed.
The original Bitcoin message-signing system worked mainly with legacy P2PKH addresses.
Modern Bitcoin, however, supports many different spending conditions.
BIP322 creates a generalized framework that can work with those conditions.
Here are some of its biggest advantages.
1. Supports Modern Bitcoin Addresses
One of BIP322’s biggest improvements is its ability to work beyond traditional legacy addresses.
The specification is designed around Bitcoin Script, allowing message proofs to correspond to different types of spending conditions.
That includes modern SegWit and Taproot-based outputs as well as multisig arrangements.
This makes BIP322 much more flexible than the original message-signing approach.
2. No Bitcoin Needs to Move
BIP322 can demonstrate control without requiring an actual Bitcoin payment.
That means you don’t need to:
- Send coins to another address.
- Pay a transaction fee.
- Wait for blockchain confirmation.
- Create unnecessary on-chain history.
For certain verification situations, this can make the process much simpler.
3. Works With Multisig
BIP322 isn’t limited to a single private key.
Multiple wallets can cooperate to produce a valid message proof for a multisig script.
The current specification supports PSBT-based signing, making the process similar to coordinating signatures for a normal multisig transaction.
This is especially useful for businesses, organizations, custody arrangements, and advanced Bitcoin users.
4. Supports Proof of Funds
The current BIP322 specification also defines a Proof of Funds format.
This allows a signer to demonstrate control over a selected set of UTXOs.
For example, someone could prove control over several Bitcoin outputs without actually transferring those coins.
However, this proof must be interpreted carefully because it doesn’t establish that the listed UTXOs represent the person’s entire Bitcoin holdings.
5. Uses Familiar Bitcoin Signing Concepts
BIP322’s virtual transaction design makes the process resemble ordinary Bitcoin transaction signing.
That’s useful because wallets and hardware devices already understand concepts such as:
- Inputs.
- Outputs.
- Scripts.
- Witnesses.
- Signatures.
- PSBTs.
The standard can therefore build on existing Bitcoin infrastructure rather than creating an entirely unrelated signing system.
What Are the Limitations of BIP322?
BIP322 is useful, but it doesn’t magically prove everything someone might want to know.
Understanding its limitations is just as important as understanding its advantages.
1. A Signature Does Not Prove Real-World Identity
Suppose someone signs:
“I am Ali and I control this Bitcoin address.”
A valid signature can demonstrate control of the relevant spending conditions.
But it doesn’t prove that the signer is actually Ali.
Bitcoin cryptography doesn’t automatically connect a private key to a real-world identity.
The person receiving the signature needs some other way to establish who actually signed it.
2. Control Is Not Permanent
A valid signature represents control at a particular point in time.
Someone could sign a message and then transfer the Bitcoin somewhere else immediately afterward.
The signature doesn’t permanently freeze the person’s ownership or control.
This is one of the limitations explicitly acknowledged by the BIP itself.
Therefore:
Valid signature ≠ permanent ownership
3. Someone Can Sign on Another Person’s Behalf
Another important limitation is that possession of a private key doesn’t tell you why someone used it.
Imagine a company controls a Bitcoin wallet.
An employee could have access to the necessary signing device.
That employee might sign a message for the company.
The cryptographic proof can show that the required key or spending conditions were satisfied.
It doesn’t tell you whether the person signing was the beneficial owner of the funds.
BIP322 cannot solve that social or legal problem.
4. Proof of Funds Is Not Proof of Total Wealth
This is particularly important.
Suppose someone creates a Proof of Funds showing:
10 BTC
That does not necessarily mean:
“This person owns exactly 10 BTC.”
The signer chooses which UTXOs to include.
They could control additional Bitcoin that they didn’t include in the proof.
The BIP explicitly says the UTXO list isn’t intended to prove completeness. A verifier also needs to check the blockchain to determine whether those UTXOs remain unspent.
So Proof of Funds is better understood as:
“I can demonstrate control of these selected Bitcoin outputs.”
Not:
“This is my complete Bitcoin balance.”
5. Proof of Funds Can Reveal Financial Information
There is also a privacy concern.
If someone asks you to prove control of a collection of UTXOs, you may reveal information about your Bitcoin holdings.
Depending on how the proof is constructed, observers may be able to connect multiple outputs that weren’t previously known to belong to the same entity.
This is why Proof of Funds should not be treated as a harmless routine procedure.
Before signing such a proof, understand exactly what information you’re revealing.
6. The UTXOs Can Be Moved Later
Even after a valid Proof of Funds is created, the signer can move the Bitcoin.
The proof demonstrates control of the selected outputs when the proof is created and subject to the verifier’s blockchain checks.
It does not lock those coins in place.
A person could create a valid proof and then spend the funds afterward.
Bitcoin Optech has highlighted this distinction when discussing BIP322-based Proof of Funds.
Therefore, Proof of Funds should not be interpreted as a permanent financial guarantee.
7. Verification Can Be More Complicated Than Traditional Signatures
Simple legacy message signing can be easy for wallets to verify.
Generic BIP322 verification can be more complicated because the verifier may need to evaluate Bitcoin Script and transaction rules.
For some complex scripts, a wallet may not have enough information or functionality to determine whether the proof is valid.
The BIP therefore allows a verifier to return an inconclusive result when it cannot fully evaluate the proof.
That is better than incorrectly claiming that a complex proof is valid or invalid.
BIP322 vs. Traditional Bitcoin Message Signing
The easiest comparison looks like this:
| Feature | Traditional signmessage | BIP322 |
|---|---|---|
| Designed for legacy P2PKH | Yes | Yes, with compatibility |
| Modern SegWit support | Limited | Yes |
| Taproot support | Limited | Yes |
| Multisig | No general support | Yes |
| Script-based | Limited | Yes |
| PSBT workflow | No | Yes |
| Proof of Funds | No general BIP322-style construction | Yes |
| Current standard status | Legacy approach | Complete |
The key difference is flexibility.
Traditional message signing was closely tied to older address formats.
BIP322 generalizes the concept around Bitcoin’s spending conditions.
The current BIP also keeps a legacy compatibility path for P2PKH, while recommending the newer format for new proofs.
BIP322 vs. PSBT
These two technologies are related but aren’t the same thing.
BIP322 defines how Bitcoin messages can be signed and verified.
PSBT defines a standardized way to exchange information about partially signed Bitcoin transactions.
BIP322 uses PSBT as part of its newer signing workflow.
For example, multiple multisig participants can cooperate through a PSBT-style process to create a BIP322 message proof.
So:
PSBT = signing coordination format
BIP322 = generic signed-message standard
BIP322 vs. Proof of Reserves
These concepts can also be confused.
BIP322 Proof of Funds lets a signer demonstrate control over selected UTXOs.
A broader Proof of Reserves system attempts to provide evidence about an entity’s reserves or financial obligations.
Those aren’t automatically the same thing.
A company could prove that it controls certain Bitcoin without proving that it has enough assets to cover all customer liabilities.
Bitcoin Optech notes that Proof of Reserves schemes have their own limitations and require careful interpretation.
Therefore, a BIP322 Proof of Funds shouldn’t automatically be advertised as proof that an exchange or company is financially solvent.
What Can BIP322 Be Used For?
BIP322 has several potential applications.
Address Control Verification
A service could ask a user to prove that they control a particular Bitcoin address.
The user signs a unique message.
The service verifies the proof.
No payment is necessary.
Business Verification
A business could use message signing to demonstrate control over a Bitcoin address used for donations or payments.
This could help customers distinguish an official address from a fraudulent one.
However, users should still verify the message and identity through an independent channel.
Multisig Organizations
A company using multisig could potentially prove control of a Bitcoin spending policy without transferring funds.
For example, a 2-of-3 arrangement could cooperate to produce a BIP322 signature.
This gives organizations a way to demonstrate control without relying on a single private key.
Proof of Funds
A trader, business, or other participant could demonstrate control over selected UTXOs.
This might be useful during negotiations or other situations where counterparties want evidence that Bitcoin is available.
But because these proofs can reveal financial information, privacy should be considered before signing.
Software and Protocols
BIP322 can also serve as a building block for other Bitcoin applications.
A protocol may need someone to prove that they can spend from a particular output without actually spending it.
Instead of inventing its own signature system, an application can potentially use a standardized generic message-signing format.
This is one reason Bitcoin developers have continued working on generic signmessage functionality.
Is BIP322 Safe?
The underlying cryptographic design is intended to use Bitcoin’s existing signature and Script mechanisms.
However, using a secure protocol incorrectly can still be dangerous.
The biggest practical risk for ordinary users is signing something they don’t understand.
For example, if a website says:
“Sign this message to verify your wallet.”
don’t automatically assume it’s harmless.
Before signing, ask:
- What exactly am I signing?
- Why does this website need the signature?
- Which Bitcoin address is involved?
- Is the message clear?
- Could the signature be reused elsewhere?
- Am I revealing information about my Bitcoin holdings?
Never provide your private key or seed phrase to a website or person claiming that they need it to verify a BIP322 signature.
A legitimate message-signing process should use the wallet’s signing capabilities rather than asking you to reveal the secret itself.
Can a BIP322 Signature Be Reused?
This depends heavily on the message.
That’s why applications should create specific, unique messages rather than asking users to sign vague statements.
For example, a better message might include:
- The service name.
- The user’s account identifier.
- The exact purpose.
- A timestamp or expiration.
- A unique nonce.
This makes it harder for someone to take an old signature and present it as proof for an unrelated action.
The signature proves what was signed—not whatever someone later claims the signature meant.
What Should a Good Signing Request Look Like?
A responsible application should clearly tell the user:
What is being signed
Which address or script is involved
Why the signature is required
For example:
“Sign this message to prove control of Bitcoin address X for account verification on Example.com. This signature does not authorize a Bitcoin payment.”
That is much better than:
“Click Sign to continue.”
The user should understand what they’re authorizing before approving the operation.
Frequently Asked Questions
What is BIP322?
BIP322 is a Bitcoin standard for interoperable signed messages based on Bitcoin Script. It allows users to create proofs associated with Bitcoin spending conditions without broadcasting an ordinary Bitcoin transaction.
Is BIP322 complete?
Yes. The current specification is version 2.0.0 and has Complete status.
Does BIP322 move Bitcoin?
No. A normal BIP322 message signature does not transfer Bitcoin or become a normal confirmed blockchain transaction.
Can BIP322 work with Taproot?
Yes. BIP322’s generic Script-based approach is designed to support modern output types including Taproot.
Can BIP322 work with multisig?
Yes. Multiple signers can cooperate to create the necessary witness data, with PSBT-based workflows supporting coordination between signers.
What is a BIP322 Proof of Funds?
It is a proof that demonstrates control over selected Bitcoin UTXOs. It does not prove that those UTXOs represent the signer’s complete Bitcoin holdings.
Does Proof of Funds prove ownership forever?
No. The Bitcoin can be moved after the proof is created.
Does BIP322 prove someone’s identity?
No. It proves that the required Bitcoin spending conditions were satisfied. Connecting that key to a real-world identity requires separate evidence.
Can BIP322 prove that someone owns all the Bitcoin in an address?
No. A Proof of Funds list isn’t intended to prove completeness.
What is to_spend?
to_spend is the first virtual transaction used by BIP322 to connect the signed message with the Bitcoin spending conditions being proved.
What is to_sign?
to_sign is the second virtual transaction that contains the data needed to demonstrate that the spending conditions can be satisfied.
What are smp, ful, and pof?
They are human-readable prefixes identifying the BIP322 signature variant:
smp— Simpleful— Fullpof— Full Proof of Funds
The current specification added these prefixes as part of its 2026 update.
Is BIP322 the same as a Bitcoin transaction?
No. BIP322 uses transaction-like virtual structures for signing and verification, but the normal message-signing process doesn’t create a broadcastable Bitcoin payment.
Should beginners use BIP322?
Most beginners won’t need BIP322 every day.
However, understanding it is useful if a service asks you to prove control of a Bitcoin address or if you encounter Bitcoin message signing.
The most important rule is simple:
Understand what you’re signing before you sign it.
Final Thoughts
BIP322 solves a surprisingly important Bitcoin problem.
Bitcoin users don’t always need to send Bitcoin to prove control of Bitcoin.
Sometimes they simply need to demonstrate that they can satisfy the spending conditions associated with a particular address or script.
That’s where generic message signing becomes useful.
BIP322 takes the concept further than traditional Bitcoin message signing by building the proof around Bitcoin Script and virtual transactions.
That allows it to work with modern Bitcoin spending conditions, including SegWit, Taproot, and multisig.
The current version also introduces a standardized PSBT-based signing workflow and a more defined Proof of Funds construction.
But BIP322 has an important limitation:
Cryptographic control isn’t the same thing as identity or permanent ownership.
A valid signature tells you that the required spending conditions were satisfied.
It doesn’t tell you who the person is.
It doesn’t prove that they will control the coins tomorrow.
And a Proof of Funds signature doesn’t prove that the listed Bitcoin represents their entire financial position.
Therefore, BIP322 should be treated as a cryptographic proof tool, not a magic ownership certificate.
The safest approach is to understand exactly what a signature proves, what it doesn’t prove, and why you’re being asked to sign.
BIP322 in Five Points
If you remember only five things, remember these:
1. BIP322 standardizes generic Bitcoin message signing.
2. It uses Bitcoin’s spending conditions and virtual transactions rather than inventing a completely separate system.
3. It can support modern outputs, including SegWit, Taproot, and multisig.
4. Its Proof of Funds format can demonstrate control of selected UTXOs but doesn’t prove complete holdings.
5. A signature proves cryptographic control—not someone’s identity or permanent ownership.



