diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki
index f8e09dd3..d70dc434 100644
--- a/bip-0322.mediawiki
+++ b/bip-0322.mediawiki
@@ -26,15 +26,26 @@ interoperability with existing signing hardware, we also define a signature mess
 resembles a Bitcoin transaction (except that it contains an invalid input, so it cannot be spent on
 any real network).
 
+The Proof of Funds variant allows demonstrating control of a set of UTXOs.
+The list of UTXOs may or may not be related to the address being signed with (the
+<code>message_challenge</code>).
+But in any case, the UTXO list does not aim to prove completeness (e.g. it does NOT mean:
+"these are all UTXOs that exist for an address") nor that they are unspent (e.g. a
+validator must consult the blockchain to verify that).
+
 Additionally, the current message signature format uses ECDSA signatures which do not commit to the
 public key, meaning that they do not actually prove knowledge of any secret keys. (Indeed, valid
 signatures can be tweaked by 3rd parties to become valid signatures on certain related keys.)
 
 Ultimately no message signing protocol can actually prove control of funds, both because a signature
 is obsolete as soon as it is created, and because the possessor of a secret key may be willing to
-sign messages on others' behalf even if it would not sign actual transactions. No signmessage
+sign messages on others' behalf even if it would not sign actual transactions. No message signing
 protocol can fix these limitations.
 
+Finally, this BIP only addresses the use case where a signer shows they will be able to control
+funds sent to the invoice address. Proving that a signer sent a prior transaction is not possible
+using this BIP.
+
 == Types of Signatures ==
 
 This BIP specifies three formats for signing messages: ''legacy'', ''simple'' and ''full''.
@@ -148,7 +159,11 @@ full signature as above, with the following modifications.
 </ul>
 
 Unlike an ordinary signature, validators of a proof of funds need access to the current UTXO set, to
-learn that the claimed inputs exist on the blockchain, and to learn their scriptPubKeys.
+learn that the claimed inputs exist on the blockchain and remain unspent.
+An offline validator therefore can only attest to the cryptographic validity of the additional
+inputs' witness stack, but not its blockchain state.
+An attested list of UTXOs can also never prove that there don't exist more UTXOs for a certain
+address.
 
 == Detailed Specification ==
 
@@ -256,8 +271,8 @@ through the special case as described above.
 
 == Acknowledgements ==
 
-Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poelstra, and many others
-for their feedback on the specification.
+Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poelstra, Luke Dashjr,
+and many others for their feedback on the specification.
 
 == References ==