There is no widely agreed upon protocol for proving solvency in Bitcoin.

The first successful protocol describing proofs of solvency is due to Greg Maxwell who described a Merkle-tree-based solution for proving solvency. Maxwell's solution provides proofs logarithmic in size with respect to the number of creditors. Maxwell's protocol is extensively described by Zak Wilcox. It has the advantage of being easy to understand and to implement. Unfortunately, Maxwell's protocol leaks the number and size of creditor accounts as well as the total liabilities of the exchange.

An alternative mechanism of using a trusted auditor has been applied by Mike Hearn on Bitstamp, Stefan Thomas on Kraken, Antonopoulos on Coinbase and others. These verifications rely on centralized trusted third parties and cannot protect against collusion between the services and the auditors, a property generally undesired in decentralized systems such as bitcoin.

The above problem is addressed by Benedict Bünz, etc. on their provisions paper and an implementation is provided. Unfortunately, their proofs are somewhat more convoluted and require slightly more advanced cryptographic tools (specifically zero-knowledge proofs of knowledge). However, they provide trustless verifiability without sacrificing privacy of total funds or account sizes. However, these new developments are not currently applicable to the current bitcoin blockchain, as provisions only works against pay-to-pubkey UTXOs, not pay-to-pubkey-hash UTXOs which are now standard on bitcoin. Pay-to-pubkey-hash transactions can be used against addresses that have been reused or for which the public keys are known. However, current best practices mandate no address reuse, so this requirement is not perfect.

Based on the provisions paper, a zk-SNARKS proof system which can provide for p2pkh transactions is an interesting research problem with ongoing research. It remains to see if it can be implemented efficiently in a way that proofs are concise and quick. The problem of a trusted setup required by SNARKS must also be addressed by such an implementation.