The moment you publish a donation address, you've published a public ledger of everyone who supports you and exactly how much you've raised. That's the part most projects don't think through. A single posted address is convenient, but every contribution to it is permanent, public, and attributable — anyone can see each donor's wallet, the amount, the timing, and your running total. For a creator that's a privacy problem for supporters; for a nonprofit or an open-source project it can be a safety problem for donors and a strategic one for the organization.
This post is about taking donations on Solana without turning them into surveillance data — protecting both the donor's privacy and your treasury's.
What a public donation address actually exposes
Post one address and accept everything to it, and the chain now records:
- Every donor's wallet. A supporter who donates from a wallet tied to their identity has just published "I support this project" forever. For politically sensitive causes, journalism, or anything controversial, that link can be a real risk to the donor.
- Your exact total, live. Competitors, counterparties, and the curious can read your raise in real time. There's no "we don't disclose" — it's on the explorer.
- Your spending. Every outflow from the donation address is equally public. Vendors, salaries, and grants paid from it are all attributable, which is the same problem treasuries face: /blog/dao-treasury-privacy-on-solana.
Encrypting amounts wouldn't fix the core issue here — the relationships (who supports you, who you pay) are the sensitive data, and those stay public even if the figures are hidden. /blog/encrypted-amounts-are-not-private covers why.
Two sides to protect: the donor and the recipient
Donation privacy has two independent halves, and which one you care about shapes the setup.
Protecting donors means a supporter can give without publishing the link between their identity-bearing wallet and your cause. The donor does this on their side: they deposit into the shielded pool from their own wallet, then have the withdraw delivered to your donation address. The chain shows their wallet depositing into a pool and an unrelated withdraw arriving at your address — no edge connecting the supporter to you. From your side, you just receive funds. (If you publish guidance for donors, /blog/sending-sol-without-revealing-your-main-wallet is the walkthrough to point them at.)
Protecting the organization means your total and your spending aren't an open book. Rather than accumulating everything in one visible address, funds can be moved through the pool so that the inflows you control and the outflows you make aren't trivially tied into a single public balance and payment graph.
A workable setup
There's no single "donation button" that does all of this magically, but the pieces compose cleanly:
- Accept to a rotating set of fresh addresses, not one forever-address. A single long-lived donation address is the worst case — it aggregates everything. Rotating destinations limits how much any one address reveals. Each should be fresh in the sense of /learn/choosing-a-recipient-address.
- Tell privacy-conscious donors they can give through the pool. Donors who want to hide their support deposit into the shielded pool and direct the withdraw to your address. Their identity wallet never appears connected to you.
- Accept the asset you actually want. If you'd rather hold USDC than SOL, donors (or you, on withdraw) can convert inside the private step — /blog/swapping-sol-to-usdc-privately — so you're not doing a public, correlatable swap of donation funds afterward.
- Move accumulated funds through the pool before spending. When you pay a vendor or a contributor, routing through the shielded pool breaks the link between "donations in" and "this specific payment out," the same discipline as any private payout.
The honest limits
A few things to be straight about, because overpromising on donor safety is worse than useless:
- The donor controls their own privacy. If a donor gives directly from an identity-linked wallet to your public address, you can't retroactively hide that for them. Donor-side privacy is a donor-side action.
- Off-chain disclosure still leaks. If a donor publicly tweets "just gave 10 SOL to X" and the timing matches a pool withdraw to your address, the inference is theirs to avoid. Privacy is a pipeline; the chain is one stage. /learn/what-solmask-cannot-protect-you-from.
- Compliance and record-keeping are your responsibility. Privacy of the public graph and your own bookkeeping obligations are separate things; this post is about the former, not advice on the latter.
Where to start
Read the /blog/solana-wallet-privacy-checklist for the operational discipline, then set up your first private receive flow at /swap. If you run a treasury alongside donations, /blog/dao-treasury-privacy-on-solana extends the same ideas to vendor and contributor payments.
FAQ
Q. Can I make my total raise completely invisible? A. You can make it much harder to read by not aggregating everything in one public address and by moving funds through the pool, but on a public chain, perfect treasury opacity is not a guarantee anyone honest should promise. The goal is removing the easy, one-glance read.
Q. How does a donor donate privately? A. They deposit into the shielded pool from their own wallet and have the withdraw delivered to your address. The connection between their wallet and your cause never becomes a public edge. Point them at /blog/sending-sol-without-revealing-your-main-wallet.
Q. Should I publish one donation address or many? A. Prefer rotating fresh addresses. A single forever-address aggregates every contribution and payment into one fully public balance and graph.
Q. Can I accept donations in USDC even if donors send SOL? A. Yes — the conversion can happen inside the private withdraw so there's no separate public swap. See /blog/swapping-sol-to-usdc-privately.