The Operator's Anonymity Checklist

This isn't a breakdown of "why," it's a hands-on checklist — a quick pass to make sure there's nowhere left a bridge from the service back to your real name. Run it before launch and once a quarter as you grow. For the detailed mechanics behind each item, look to the opsec articles.

This material is about engineering your own infrastructure and is educational in nature. It's about the privacy of a law-abiding operator, not about circumventing KYC. You comply with the laws of your own jurisdiction yourself.

We covered the mechanics and threat model in the theory piece "The Operator's Anonymity," and the split across layers in the practice piece "Opsec in Practice." Here is the concentrate: a run-through list to verify you haven't left a link to anything personal anywhere. There's one main principle — the service identity never intersects with the personal one. Go top to bottom.

The service identity

A separate set for the project, not mixed with anything personal at any point:

• [ ] E-mail for the service — not in your name, not your primary one. A provider that doesn't require a phone (Proton, Tuta).
• [ ] Telegram for the service — a separate account for the bot and support, not personal.
• [ ] Browser profile (or a separate browser/VM) for everything service-related, with no personal Google/VK logged in.
• [ ] Password manager or vault — separate, business secrets not mixed in with personal ones.

Check for reuse: the same nickname, email, or phone in both personal and service contexts is a ready-made bridge. This is the single most common cause of deanonymization.

Numbers and SIMs

• [ ] Number(s) used for registrations are not personal (eSIM / a virtual number from a legal service).
• [ ] Different numbers for different tasks: one for the clouds, another for support.
• [ ] Important things (money, domains) live on a stable number, not on a disposable SMS service.

Paying for infrastructure

• [ ] Hosting, domains, and proxies are paid for with crypto, not a card in your name.
• [ ] The domain is with a registrar offering WHOIS privacy. Verify the data is actually hidden:

# the output should not contain your name/address/phone
whois your-domain.com | grep -iE 'name|registrant|email|phone'

• [ ] There is a break in the crypto chain between the exchange (KYC'd in your name) and paying for the service — an intermediate wallet or a privacy coin.

Receiving money from clients

• [ ] Receipts aren't mixed with personal accounts in a single transfer.
• [ ] The "crypto vs. instant-payments/cards" balance is weighed: the more "clean" the intake, the more trail leads to you.
• [ ] Payment-processor keys and secrets live only in .env, not in git and not in logs.

Behavior (where real people get burned)

• [ ] You've never exposed income, the panel, or payment details under your personal name — not in chat, not in a story.
• [ ] Nicknames, avatars, and writing style in the service context differ from your personal ones.
• [ ] The time zone and hours of support activity don't give away your real schedule.
• [ ] Metadata is stripped from files sent to clients. One command before sending:

# strip EXIF and metadata from an image/screenshot
exiftool -all= -overwrite_original screenshot.png

• [ ] Personal and service contexts don't live on the same device (otherwise autofill and the clipboard will eventually betray you).

Server and client data

Technical opsec is part of anonymity too — briefly here:

• [ ] Traffic logs are not kept, client PII is minimal (only what's needed: expiry, plan, tg_id).
• [ ] Secrets (tokens, payment-processor keys) live in .env or a secrets vault, not in git.
• [ ] Backups are encrypted and stored off the main server.
• [ ] There's a plan for a quick move: a reserve of white IPs, a ready cascade — in case a node is seized or blocked.

The check rhythm

• [ ] You've gone through the whole list before launching the service.
• [ ] You return to it once a quarter and every time you add a new node/payment-processor/domain — new bridges appear precisely as you grow.

The detailed "why" behind each item is in the theory piece "The Operator's Anonymity: Threat Model." The step-by-step layer-by-layer breakdown with pitfalls is in the practice piece "Opsec in Practice: Spreading the Trail." Technical hardening of the server and panel is in the neighboring articles of this section.