Interesting. We use cloudflare to determine if you're behind tor, but it seems that this api is not correctly identifying tor exits.. I've encountered this myself, so this is something we'll need to look into, although it is very important to make users aware that they should at least use a rotating IP.

IPs are one of the few obvious things we (or other parties that are between the custodian and the user) can undetectably log to link your in and outputs together.

You're right. On our TODO list. Perhaps we should just remove the links for now.


Here's where things get tricky, and perhaps have been explained a bit poorly from our side of things..
While we absolutely recommend you to use tor, due to the level of access the wallet requires from features such as indexedDB, it seems impossible (for now at least) to use it in combination with the Tor Browser itself.

It also would not make much sense to use the Tor Browser as it does not persist most data (cookies, local storage), which for the moneypot wallet would mean that you'd have to resync your entire wallet every time you open your browser.

(Assuming that that is what you've just tried to create a wallet with?)

So a workaround would be to download the standalone tor client (if on windows), and set the socks proxy of your browser of choice to
These are the recommended fees to get confirmed within 6 blocks, and so if you were to make a "batched" transaction using moneypot, which means you only pay for a single output (32 vbytes in most instances), it would be significantly cheaper than using any other wallet (where you will always pay for the entire transaction, eg ~561 WU v 32 * 4 WU).

Of course, you'd need to wait for an initatior that is willing to pay for an IMMEDIATE transaction, so depending on the number of people using moneypot, this might take a significantly longer time than liked.

You can also send custom transactions with whichever feerate you like (1 sat/vb) while paying for the entire transaction. And, if above 0.01BTC (for now), a free transaction, but this only gets send if we find an "optimal solution" in regard to input usage (no change). which again, could take longer than liked to be sent.


We will probably scrap these "consolidation fees" completely for any incoming transfer over 100k sats, as it's really not meant to be anything other than a deterrent from users sending dust to our wallets from stuff such as faucets. Our business model is not centered around collecting fees from in- and outputs in any way.