In this article
You prove funds before a crypto OTC trade without moving them by signing a fresh challenge message with the key of the address that holds the assets: the counterparty checks the signature against the address, reads the balance on the public ledger, and nothing leaves the wallet. Where no signature is possible, because the assets sit with a custodian or an exchange, the equivalent is a statement issued by that institution directly to the party asking, and for the fiat leg a proof-of-funds letter from the bank.
A proof of funds is a narrow piece of evidence, and most of the trouble it causes comes from asking it to say more than it can. It answers three questions: do the assets exist, does this counterparty control them, and at what moment was that true. It says nothing about tomorrow. A desk that treats it as a guarantee of settlement, or a fund that hands over a screenshot and considers the matter closed, has each misread the document.
What follows is the working method: what the proof must establish, how the available methods compare, the procedure for a signed-message proof and its verification, the cases where the holder cannot sign (custody, multisig, smart-contract wallets), the weaknesses a reviewer looks for, and a worked exchange on a $5,000,000 trade with its timeline. The rules that govern onboarding and source-of-funds checks vary by country and by the status of the firm; this article covers the evidence itself, not the regulatory file around it.
Figures from the worked example in this article: an illustrative trade of 80 BTC against 5,000,000 USDC. Real timings depend on the signers and the custodian.
What must a proof of funds establish before an OTC trade?
A proof of funds before an OTC trade must establish three things: that the assets exist in the stated amount, that the counterparty controls them, and the time at which both were true. A proof that is missing any one of the three is an assertion, not evidence.
Existence is the easy part for assets held in a self-custodied wallet. The ledger is public, and anyone can read the balance of an address at a given block. For assets held at a custodian or an exchange, existence is not visible from outside: the institution pools client assets in its own wallets, and the client's entitlement is a line in the institution's books. Existence then rests on what the institution states.
Control is the part a public ledger cannot show by itself. An address with a large balance belongs to somebody, and nothing on the explorer page says who. Control is shown by doing something only the key holder can do: producing a signature that verifies against the address, or sending a transaction from it. For custodied assets, control means the right to instruct the custodian, and only the custodian can confirm that.
Time is the part most often left out. A signature has no clock inside it. Unless the signed text itself contains something that could not have been known earlier, a signature produced last year verifies exactly as well as one produced this morning. The proof therefore has to be tied to a moment by its content: a date, the name of the party asking, and a random string supplied by that party.
What can a proof of funds not establish?
A proof of funds cannot establish that the assets will still be there at settlement, that they are unencumbered, or who their beneficial owner is. Each of those questions has its own answer elsewhere in the process, and the proof should never be filed as if it covered them.
| Question | Answered by proof of funds? | Where the answer comes from |
|---|---|---|
| Do the assets exist in this amount? | Yes, at the block or statement time | Ledger balance or institution statement |
| Does the counterparty control them? | Yes, at the time of signing | Signature, test transfer or institution confirmation |
| Will they be there at settlement? | No | A fresh balance read at settlement, and the settlement method itself |
| Are they pledged, lent or promised elsewhere? | No | Representations in the trade terms; the custodian for custodied assets |
| Who is the beneficial owner? | No | Onboarding and identity checks |
| Is the source of the assets acceptable? | No | Source-of-funds review and ledger analysis |
The first "no" matters most in practice. An unlocked balance in a wallet can leave in the next block. The same holder can show the same balance to three desks in the same afternoon, and each proof will be valid. Proof of funds is a filter that removes counterparties who do not have the assets; it does not remove the risk that a counterparty who has them fails to deliver. That risk is handled by how the trade settles, which is a separate subject.
The encumbrance point has an onchain side as well. A balance can sit in a wallet and still be committed: posted as collateral in a lending protocol through a derivative token, subject to a token approval that lets another contract move it, or locked under a vesting schedule. Reading the token balance alone does not reveal all of these. A reviewer who needs to know asks for a written representation that the assets are free of any lien or commitment, and for custodied assets asks the custodian to state whether the balance is available or restricted.
Which methods prove funds, and how do they compare?
Five methods are in common use to prove funds before an OTC trade: a signed message from the address, a small test transfer, a view of the address on a block explorer, a statement or letter from a custodian or exchange, and a bank proof-of-funds letter for the fiat side. Only the first two prove control of a self-custodied address, and only the signed message does so without moving anything.
| Method | What it shows | What it leaves open | Funds moved, cost and delay |
|---|---|---|---|
| Signed message from the address | Existence and control, tied to a moment by the challenge text | Future balance, encumbrance, ownership | Nothing moved, no network fee, minutes |
| Small test transfer (often called a satoshi test) | Existence and control, timestamped by the ledger | Same as above; also creates a public link between the two parties | A small amount moved, a network fee, one or more confirmations |
| Block explorer view alone | Existence of a balance at an address | Control: the address may belong to anyone | Nothing moved, instant |
| Custodian or exchange statement | Balance held for the client, as stated by the institution | Depends on the institution's wording and on verifying the document's origin | Nothing moved, hours to days |
| Bank proof-of-funds letter | Fiat balance or availability on a date, as stated by the bank | Future balance; must be confirmed with the bank | Nothing moved, usually days |
The test transfer deserves a fair word, because many desks and compliance teams rely on it. The asking party names a small, specific amount, and the holder sends exactly that amount from the address being proven, either to an address the asking party gives or back to itself. Because the amount was chosen after the request, the transaction could not have been prepared in advance, and the ledger timestamps it. It works with every wallet, including those that cannot sign messages, and it leaves a permanent public record. Its costs are the ones the title of this article sets out to avoid: funds move, a network fee is paid, and a transfer between the two parties' addresses publicly associates them before any terms are agreed. A transfer from the address to itself avoids that last point.
The explorer view alone is the weakest method and the most often offered. It is useful as the second half of a signed-message proof, where it supplies the balance. Alone, it proves that someone, somewhere, holds the assets.
How do you run a signed-message proof, step by step?
A signed-message proof runs in six steps: the asking party issues a fresh challenge, the holder signs that exact text with the key of the settlement address, and the asking party verifies the signature and reads the balance itself. The asking party writes the challenge; the holder never chooses the text.
- Agree the address and the assetThe holder states the address, the network and the asset, and confirms in writing that this is the address the trade will settle from. If settlement will come from a different address, that address is the one to prove.
- Issue a fresh challengeThe asking party writes a short plain-text message containing the date and time in UTC, its own legal name, the holder's address, a random string it has just generated, and a line stating that the message authorises no transaction. It sends the text over the channel already used for the trade.
- Sign the exact textThe holder pastes the challenge, character for character, into the message-signing function of its wallet and signs with the key of the stated address. No transaction is created and no network fee is paid.
- Return three itemsThe holder sends back the address, the message exactly as signed, and the signature string. A screenshot of the wallet is not one of the three.
- Verify independentlyThe asking party checks the signature with a tool it selects and trusts, confirms that the result is the stated address, and compares the signed text with the challenge it issued, including the random string.
- Read the balance and file the recordThe asking party reads the balance of the address on the ledger from its own node or explorer, notes the block height and time, and files the challenge, signature, verification result and balance together.
A workable challenge reads along these lines, as an illustration: "Proof of control requested by Northgate Trading Ltd. Address: the holder's full address. Network: Ethereum mainnet. 14 March, 09:00 UTC. Reference: 7F3K-92QX-LM4T. This message authorises no transaction and no transfer of assets." Every element does a job. The date bounds the age of the proof. The name of the asking party stops the same signature from being presented to another desk. The random string, chosen by the asking party, proves the signature was made after the request. The closing line is for the signer's own protection and for the file.
The message stays in plain, readable text for a reason. A signer should be able to read exactly what is being signed on the wallet or hardware device screen. A request to sign an unreadable string of hexadecimal characters, a structured payload from an unfamiliar interface, or anything presented as a "verification transaction" is outside this procedure and should be declined and logged. Signing a message proves control; it should never be capable of doing anything else.
How do you verify the signature on Ethereum and on Bitcoin?
You verify a signed message by recomputing, from the message and the signature, the address that produced it, and checking that the result is the address under review. The standards differ by network, and the verifier needs to know which one the wallet used.
On Ethereum and compatible networks, a plain-text message signed by an ordinary key-controlled account follows the format described in ERC-191, a final standard in the Ethereum Improvement Proposals. The wallet prefixes the text with a fixed header and the length of the message before hashing and signing. According to that standard, the leading byte of the format exists so that signed data can never be a valid transaction: a signed message cannot be replayed as a transfer. Verification recovers the signer's address from the signature and the prefixed message; a match with the stated address is a pass. Wallets, command-line libraries and several block explorers offer this check.
The second Ethereum format is EIP-712, also final, which signs typed, structured data so that a wallet can display labelled fields instead of an opaque string. It can carry a proof of funds, with the challenge elements as named fields, and some institutional wallets prefer it. One point from the standard itself matters here: EIP-712 states that it does not include replay protection. Freshness is the application's job in both formats, which is why the date, the name and the random string belong in the message whatever the encoding.
On Bitcoin, the long-standing signed-message function produces a compact 65-byte signature, and it was designed for single-key addresses. BIP-137 documents a format that lets a verifier tell which address type a signature was made for, covering legacy and single-key SegWit addresses. BIP-322 defines a newer scheme built on Bitcoin Script, so that any address type can sign, and it restricts the legacy format to legacy single-key addresses. Wallet support for each format is uneven, so the two parties should agree on the format before the holder signs, and the verifier should use a tool that supports that format. A failed check caused by a format mismatch is common and is not a finding against the holder; a second attempt in an agreed format settles it.
Three rules hold on every network. The verifier chooses the verification tool, never a page or script supplied by the party being verified. The verifier compares the signed text with its own copy of the challenge, not with the copy returned. And a valid signature is only half the proof: the balance is read separately, by the verifier, from a source it controls.
BIP-322 adds a caution worth carrying over to any proof: its text notes that a list of coins supplied with a proof does not show that the list is complete or that the coins are still unspent, and that the verifier must consult the blockchain for that.
How do you prove assets held at a custodian or an exchange?
Assets held at a custodian or an exchange are proven by a statement or confirmation issued by the institution, because the client holds no key and cannot sign. The quality of that proof depends on two things: what the document says, and how the reviewer confirms that it really came from the institution.
On an exchange or with a pooled custodian, the client's assets are not at an address the client can point to. The deposit address shown in the account is a route into the institution's wallets, not a store of the client's balance. A signed message is therefore impossible, and an explorer view of the deposit address is meaningless. With a segregated custody account, the assets may sit at a dedicated address, and some custodians can produce a signed message from it on the client's instruction; where that service exists, it is the strongest option and follows the procedure above.
In every other case, the proof is a document. A useful custodian or exchange statement names the account holder exactly as it appears in the trade documents, states the asset and the quantity, states the date and time of the balance, says whether the balance is available or subject to any restriction, lock or pledge, and identifies the person at the institution who issued it. A statement that gives a balance without saying whether it is available answers only the existence question.
Origin is then verified. The stronger routes, in descending order, are: the institution sends the statement directly to the reviewer from its own systems; the reviewer calls the institution on a number obtained independently and has the reference confirmed; the client grants read-only access to the account through the institution's own audit or viewer function. A file forwarded by the client, with no confirmation from the institution, is weak evidence, however well formatted. A screen-share of the account sits between the two: better than a screenshot, short of a confirmation.
A custodied holder can also run a test transfer, withdrawing a small agreed amount to an address the reviewer names. This shows that the client can instruct withdrawals, which is real evidence of control, but it shows nothing about the size of the balance behind the withdrawal. It complements a statement and does not replace it.
How does the fiat side prove funds?
The fiat side of a crypto OTC trade proves funds with a letter or statement from the bank, confirmed with the bank by the party relying on it. No signature from the account holder can substitute, because a bank balance has no public ledger to check it against.
A bank proof-of-funds letter is issued on the bank's letterhead, names the account holder, states the balance or confirms that a stated amount is available, gives the date, and is signed by a named officer. There is no single universal template, and the wording varies by bank and by country: some banks confirm a balance, others confirm only that the client is able to meet a commitment of a given size. The reviewer reads which of the two the letter says.
The same three limits apply as on the crypto side. The letter speaks for its date, not for settlement day. It does not say the funds are free of commitments unless the bank says so. And its origin has to be confirmed: a call to the bank on an independently sourced number, or a confirmation sent bank to bank, turns a document supplied by the client into evidence. Banks set their own conditions and lead times for issuing and confirming such letters, so the fiat proof is usually the slowest item on the timeline and should be requested first.
Who signs when the wallet is a multisig or a smart contract?
For a multisig or smart-contract wallet, the proof is signed by the wallet's authorised signers up to its threshold, and verified by asking the contract itself whether the signature is valid. A signature from one signer's personal key proves control of that key, not of the wallet.
A smart-contract wallet has no private key. ERC-1271, the final Ethereum standard for this case, states the problem directly: contracts cannot produce ordinary signatures, so the standard defines a function that a contract exposes and that any party can call to ask whether a given signature is valid for a given message hash. The contract applies its own rules, typically that enough owners have signed, and returns a fixed value for a valid result. In a multisig built this way, the owners each sign the challenge in the wallet's interface until the threshold is reached, for instance two of three, and the collected signatures are returned as one proof.
Verification differs from the single-key case in three ways. First, the check is a read-only call to the contract on the network where the wallet lives, not an offline recovery of an address; the reviewer needs a tool that performs an ERC-1271 check. Second, the standard allows validity to depend on the contract's state, so a signature that is valid today can become invalid if the owners or the threshold change; the reviewer records the block at which the check was made. Third, a contract wallet's address on one network says nothing about another network: the same address elsewhere may be undeployed or configured with different owners. The proof is checked on the network that holds the assets and that the trade will settle on.
A reviewer may also want to know who the signers are and what the threshold is, because that describes who can actually move the assets. Both are readable from the contract. A fund whose assets sit in a wallet where one external party holds enough keys to act alone has a different control profile from one where the fund's own officers form the threshold.
Bitcoin multisig is different in kind: the script lives in the address, not in a contract. The legacy signed-message format does not cover multisig addresses. BIP-322 was designed to, since it signs against the script itself, but tool support is uneven. Where the wallet software of a Bitcoin multisig holder cannot produce a signature the reviewer can verify, the practical fallback is a small test transfer from the address to itself, which requires the same quorum of signers as any other spend.
What weaknesses does a reviewer look for in a proof of funds?
A reviewer looks for three recurring weaknesses in a proof of funds: a signature that is not fresh, evidence that is an image and not data, and an address that is not the one the trade will settle from. Each has a simple control.
| Finding | Why the evidence fails | Control |
|---|---|---|
| Signature over a text the holder chose, or one with no date or random string | It may have been produced at any earlier time, or by a previous holder of the key | The asking party writes the challenge; text is compared with its own copy |
| Signature addressed to no one | The same proof can be shown to several desks | The asking party's legal name is in the signed text |
| Screenshot of a wallet, an explorer page or an account | An image can be edited and proves neither control nor origin | Accept only the address, message and signature as text; read the balance independently |
| Proven address differs from the settlement address | Control is shown over assets that will not be used in the trade | Settlement address stated before the proof; any change triggers a new proof |
| Signature from one signer of a multisig | Shows control of one key, not of the wallet | Verify against the contract, at threshold |
| Verification run on a tool supplied by the holder | The result is not independent | The reviewer selects and operates the verification tool |
| Statement forwarded by the client only | Origin is unconfirmed | Confirmation obtained from the institution directly |
| Balance read hours or days before terms | Existence is stale | Balance re-read at quote and again at settlement, block height noted |
Two further points belong in the review. A proof supplied by an intermediary on behalf of an unnamed principal proves that someone has the assets and nothing about whether that person is party to the trade; the challenge should be signed by the principal, and the file should say who that is. And a proof can be valid while the balance behind it is borrowed for the occasion: a holder can receive assets shortly before the proof and return them shortly after. The history of the address is public, and a balance that arrived an hour before the request is worth a question.
None of these findings implies bad faith. Most stale or malformed proofs come from a holder reusing the last one it produced, or from a wallet that signs in an unexpected format. The reviewer's job is to record what the evidence shows and to ask for what is missing.
What does a proof exchange look like on a $5,000,000 trade?
On a $5,000,000 trade, a proof exchange for both legs fits inside one working day: under an hour for a self-custodied leg proven by signed message, and most of the day for a leg held in custody. The following is a worked example with invented parties; the timings are illustrative.
Call the desk Northgate. It is arranging a sale of 80 BTC at an agreed reference price of $62,500 per bitcoin, a notional of 5,000,000 USDC. The buyer is a fund holding its stablecoins in a 2-of-3 multisig on Ethereum. The seller holds its bitcoin with an institutional custodian. Northgate's policy is that each side proves the full notional before terms are confirmed, that a proof is valid for 24 hours, and that balances are re-read before settlement. All times are UTC.
| Time | Step | Evidence filed |
|---|---|---|
| Tue 09:00 | Northgate sends a challenge to the fund and a statement request to the seller | Challenge text; request |
| Tue 09:10–09:25 | Two of the fund's three signers sign the challenge | None yet |
| Tue 09:30 | Fund returns address, message and combined signature | The three items, as text |
| Tue 09:40 | Northgate runs the contract check: valid. Balance read: 5,240,000 USDC | Result, block height, balance, owners and threshold |
| Tue 15:00 | Custodian sends a statement to Northgate directly: 80 BTC, available, unrestricted | Statement |
| Tue 15:30 | Northgate confirms the statement by call-back on an independently sourced number | Call note, name of officer |
| Tue 16:00 | Terms confirmed by both sides | Trade confirmation |
| Wed 09:15–09:35 | First proof is past 24 hours: second challenge issued, signed and verified | Second challenge, signature, result |
| Wed 09:45 | Balance re-read: 5,240,000 USDC. Custodian reconfirms 80 BTC available | Block height, balance, confirmation |
| Wed 10:00 | Settlement begins | Outside the scope of the proof |
The stablecoin leg took 40 minutes from challenge to verified proof, most of it waiting for a second signer. The balance of 5,240,000 USDC exceeded the notional by 240,000 USDC, a margin of 4.8%, which the desk noted without requiring it: its policy asks for the notional, and a fund is entitled not to show more than the trade needs. A holder with a much larger balance who prefers not to disclose it can move the trade amount to a dedicated address ahead of time and prove that address, at the cost of one transfer within its own wallets.
The bitcoin leg took 6.5 hours from request to confirmed statement, entirely on the custodian's clock. Had the request gone out when the trade was first discussed, it would not have set the pace.
Settlement was scheduled 25 hours after the first challenge, one hour past the validity window, so the desk asked for a second signature. It took 20 minutes. The second challenge carried a new date and a new random string; the first signature, although still cryptographically valid, was no longer accepted as current.
What the file does not show is as important as what it does. It does not show that the fund's stablecoins were free of commitments, which the fund represented in the trade terms. It does not show the source of the assets, which the desk's onboarding covered. And it does not protect either side during settlement itself.
What should the file contain once the proof is accepted?
The file for an accepted proof of funds should let a third party, reading it a year later with no one to ask, repeat the verification and reach the same result. That means data in text form, not images, and the reviewer's own readings alongside what the counterparty supplied.
For a signed-message proof, record:
- the challenge exactly as issued, with the time it was sent and the channel used;
- the address, the network and the asset, and the holder's written confirmation that this is the settlement address;
- the message exactly as returned and the signature string, as text;
- the signing format used (plain-text message, typed data, or the Bitcoin format agreed);
- the verification tool, its version, the result, and the name of the person who ran it;
- for a contract wallet, the block at which the validity check was made, the owners and the threshold at that block;
- the balance read by the reviewer, with block height and timestamp, and the source of the reading;
- the validity window applied and the time the proof expires;
- each later balance read, including the one made before settlement.
For a custodian, exchange or bank document, record:
- the document as received, and how it arrived (from the institution directly, or through the client);
- the account holder's name as stated, checked against the trade documents;
- the amount, the asset or currency, the balance date and time, and the wording on availability or restrictions;
- the confirmation step: who was contacted, on what number or channel, how that contact detail was obtained, when, and what was confirmed;
- any limit the institution placed on reliance on the document.
For the file as a whole, add the name of the principal whose assets were proven, the representation on encumbrance given in the trade terms, any finding raised during review and how it was closed, and the reviewer's sign-off with date. A desk that keeps this record for every trade can show an auditor, a regulator or its own risk committee not only that proof was requested, but what the proof showed, when, and what it was never asked to show.
