Приватные донаты — давать девам, НКО и делам, не деанонимизируя себя

The donation-privacy threat model

Before the "how," get honest about the "against whom." Most donation-tracking that matters happens through three surfaces:

The recipient's records. Every org keeps donor lists. Small orgs often keep spreadsheets. Non-profits with 501(c)(3) status must retain donor identity for tax-receipt purposes if you claim one. Employees and volunteers can see the list. A future breach exposes it wholesale.
The payment rail. If you pay in fiat via card, ACH, or PayPal, the payment processor knows both endpoints. Bank statements name the org. Card providers sell aggregated transaction data (Visa/MC do). A subpoena to the processor reveals the donation even if the org's own records go missing.
The public chain (for crypto). Sending BTC to a published donation address links your wallet to that org forever. If the wallet you sent from ever touches an exchange with your KYC identity, the trail closes.

These are different threat surfaces with different mitigations. XMR direct closes the third one but does nothing about the first. Aliases close the first but not the payment rail. This guide picks a channel per threat.

Channel 1: XMR direct

The best case. The org publishes a Monero address. You send XMR from a wallet whose funding chain isn't tied to your legal identity. Done. No processor sees the donation, no chain analyst can attribute it, no email is required unless the org asks separately.

Practical shape:

Fund an XMR wallet no-KYC (see how to buy Monero no-KYC).
Send from that wallet directly to the org's published XMR address. Use a wallet like Cake or Feather — either produces a transaction that discloses nothing on-chain.
If the org offers a subaddress-per-donor scheme, use it. If not, don't ask for one — the ring signature already protects you; a subaddress helps them reconcile, not you.

The optional "proof of payment" hand-off: some devs want a signed message from the sending wallet to verify a specific donation (e.g. for a matching-grant program). Both Cake and Feather expose per-transaction private-view or private-spend key export — you can share just the tx, not the wallet history. Only give the operator the minimum key needed.

Channel 2: BTC + atomic swap for BTC-only orgs

Some causes only list BTC. Cypherpunk-adjacent BTC devs, older Bitcoin nonprofits, some hardware-wallet OSS teams. Sending BTC directly from a KYC-tainted wallet to their address is the classic doxing pattern — the org's BTC page then holds a chain-linkable donation from you forever.

Break the link with an atomic swap. Convert XMR → BTC on-chain via COMIT-style atomic-swap protocol (or a no-KYC swap desk), then send the freshly-obtained BTC. The atomic swap doesn't produce a chain-analyst-readable link between your XMR and the resulting BTC — you get a fresh BTC output whose history starts at the swap counterparty, not at your wallet.

Hold your donation budget in XMR.
Perform an atomic swap (COMIT / eigenwallet) or use a no-KYC swap that hands you a fresh BTC output (SageSwap, Trocador).
Send the resulting BTC from a fresh wallet address to the org's donation address. Do not consolidate that BTC with your other UTXOs before sending.
Discard the send-wallet after the donation. It has served its purpose.

Channel 3: Prepaid VCC for fiat-only orgs

A huge fraction of legit non-profits accept only fiat via card. Legal-aid orgs, indie journalism, some free-software foundations. Their platform is Stripe or Donorbox; there is no crypto option. If you pay from your bank card, the donation lands on your statement forever.

The workaround: load a prepaid VCC with XMR, spend it at the fiat donation page. The card provider (CakePay, Agora Cards, etc.) creates a virtual Visa/MasterCard funded by your crypto balance. The org sees a card charge from a card that has no other history. Your bank statement never mentions the org — only the card load.

Caveats worth flagging:

The card provider knows both ends: the XMR load (their side) and the merchant charge (their side). They can be subpoenaed. This is a trust-shifting move, not a trust-eliminating one. Pick a card provider you'd trust with the donation itself.
Some processors flag prepaid VCCs from crypto providers as high-risk and decline. Test with a small transaction before committing your full donation.
You'll need a delivery email for the card issuance. Use an alias (channel 5 below).

Channel 4: Email alias per donation

When the org's form requires an email — for a receipt, a thank-you, a mailing list — never use your primary. Generate a fresh alias per donation via a service like SimpleLogin, addy.io, or Proton's built-in alias tool. Forward-only, disposable, one per org.

Naming discipline matters. Don't use aliases that leak identity or timing. Bad: john.donate@simplelogin.io. Good: ph3r-79xr@simplelogin.io (random). You want the alias to be a per-donation nonce, not a fingerprint.

If the org sends physical mail (thank-you card, tax receipt), you also need an address. This is where donation-privacy gets hard — a home address is a hard leak. Options: PO box under a non-legal-name alias where the jurisdiction allows it, a virtual mailbox service (Anytime Mailbox, iPostal1) with a delivery-hash setup, or accept that you're getting a paper trail and pick a channel without a receipt.

Channel 5: Dead-drop / concierge services

For high-friction targets — a foreign activist org, a legal-defense fund, a whistleblower support network — sometimes the best move is to pay a concierge to relay the donation on your behalf. The concierge takes your XMR, the concierge sends the org their preferred rail (bank wire, cash, whatever). You never touch the org's ledger; the concierge does.

The trust surface is the concierge, not the org. Pick one you'd trust with the money if they simply pocketed it (they can). The privacy budget is the concierge's ledger. Their operational security determines yours.

Existing surfaces worth knowing about:

XMRBazaar-style P2P offers where a seller will accept XMR from you and deliver the fiat leg to any address you name.
Community-run reshipping / cash-forward operators — often lightly-advertised, discoverable via forums or word of mouth.
Legal-services concierges — usually more expensive; they buy legitimacy from a bar-licensed attorney forwarding on your behalf.

Do the sender-side KYC on the concierge, not the other way around: verify they've done clean forwards before, verify their published rules, verify their onion or SimpleX channel. A concierge with no track record is a concierge who might be a honey pot.

Recurring-donation OPSEC

One-time donations are easy to privatize. Recurring ones leak pattern, which is often more identifying than any single payment.

If you set up a monthly $50 donation via prepaid VCC, the org sees "a $50 charge from a virtual card on the 3rd of every month." That's a signature. Ten months in, if the org ever cross-references its donor list with a leaked breach elsewhere, the timing signature identifies you.

Countermeasures:

Don't set up automatic recurrence. Send annual lump sums instead. A single $600 donation on a random date is a much smaller pattern than twelve monthly $50s.
If you must recur, jitter the timing. Vary the day of the month, the amount by ±20%, and the payment rail.
Rotate the alias / card every 6 months. Treat the alias as an operational asset with a life span.
Prefer per-project XMR addresses. Many devs publish a fresh donation address for each cycle. Use whichever is current, not the archive.

The tax-receipt tradeoff

This is the part most privacy guides skip. If your donation is above your local deduction threshold and the org is registered charitable (501(c)(3) in the US, similar elsewhere), the tax-deduction is worth real money. Claiming it means the org must record your legal identity for the receipt and the tax authority must be able to verify it. That's the opposite of privacy.

The honest choice:

Small donations (below threshold, or below what you'd itemize): take the privacy. Skip the receipt. No tax authority is coming to ask about a $50 XMR donation to an open-source project.
Large donations (above your itemization threshold): the math changes. A $10K donation with a $3K tax deduction is worth $3K to you; giving that up for privacy has a real cost. Decide honestly.
Split-strategy: some donors do both — one traceable, tax-deductible donation to a legitimate 501(c)(3) that supports the general cause, plus one private XMR donation to the specific dev/team you actually want to fund. The public one is legible for the tax authority; the private one funds the work.

Also worth knowing: some jurisdictions allow anonymous tax-deductible donations through donor-advised funds. You donate to the fund (traceable, deductible), the fund donates to the org (opaque to the org). This is a middle path if you want both the deduction and some downstream anonymity. Check your local rules.

What NOT to do

Don't donate from an exchange wallet. Sending BTC directly from Coinbase or Kraken to a public donation address links your KYC identity to that donation forever. Always self-custody the donation-outbound wallet.
Don't reuse the same alias across orgs. Aliases are per-org, per-donation. Reuse turns them into cross-referencable identifiers.
Don't publish your donation in bragging screenshots. Even a partial tx hash or wallet screenshot lets a chain analyst backtrack. If you feel compelled to show you gave, share the org's address publicly with a "here's who I support" note — not proof you personally sent.
Don't donate immediately after a large no-KYC XMR purchase. A tight temporal correlation between you buying XMR and the org receiving XMR narrows the anonymity set. Wait a few days at minimum.
Don't ignore the org's own OPSEC. If the org publishes its donor list, uses a shared spreadsheet, or accepts PayPal-only, they will leak you regardless of your channel. Pick an org that treats donor privacy as seriously as you do.