I am creating an anonymous services marketplace - what security measures should I take into account?

Please don't even accept BTC and only use XMR. Also, I'd really like to know what language you'd like to develop this in first, as you want something really reliable here in the end. In addition, do you have general experience in actual management, e.g. dedicated servers secure and under Linux? I think you are too naïve in this regard and I don't mean that in an insulting way, but for your own sake.

be ready to potentially to do LIFE in prison.

also I would recommend to do what the white house admin did. don`t stay in the game too long. after maybe 2 or three years shut the operation down gracefully ( with notice to your user base ), give them time to let everyone withdraw funds and then disappear into the ether. burn that identity, keys everything. delete your site's code base, private keys, database, EVERYTHING...deleting the code base will stop you from re-using the code of your market if you decide to start a new one.

and if you really want to risk it start a new market with a complete different usernames, market code and everything new

good luck mate

Appreciate the concern — that’s a valid perspective.

I already have two dedicated servers, one located offshore (Bahamas). Both run hardened Linux environments with full disk encryption, strict firewall configs, no logging, and isolated services. Internal routing is done over Tor with proper separation between components.

While most of the core logic is in Python, I’m also writing performance-critical microservices in C++, especially for handling cryptographic operations and secure escrow processes.

BTC isn’t part of the plan — XMR only, by design.

I fully understand the risks involved — that’s why I’m taking my time and doing it right. Feedback like yours helps push that further.

very interested in this please update in the future

Solid initiative — it’s clear you’re taking this seriously, and that’s rare. A few thoughts from experience and observation:

🔐 1. Escrow & Disputes

Multisig (2-of-3) is still the gold standard for trustless escrow, but with digital services (esp. fraud-related), dispute arbitration gets messy fast. You’re right to ask whether automation is viable — in most cases, it isn’t. Quality control on digital goods (e.g. dumps, drops, etc.) often requires domain knowledge.

✅ Suggestion: Manual arbitration by niche-experienced moderators. Maintain a rotating pool, and log all disputes (minus user info) for transparency and pattern detection.

💸 2. Payment Handling

Glad you’re going XMR-only. Even BTC + mixers are risky.

Avoid centralized balances when possible. Instead, generate subaddresses per user, and track credits on-chain. That way, you’re not sitting on large custodial balances.

✅ Suggestion: Use monero-wallet-rpc or Monero-LWS for scaling. Subaddress-per-deposit is lightweight and deterministic.

🧅 3. Access & Comms

I2P and Tor access is good. Re: PGP-only messaging — great for security, but as others said, it’s UX-hostile.

✅ Suggestion: Offer PGP optional on user side, but mandatory for vendors and dispute resolution. Auto-encrypt server-side where possible (OpenPGP.js or similar).

📉 4. Abuse Mitigation

Self-reviews and fake traffic are rampant. Consider:

• CAPTCHA variants for Tor (e.g. proof-of-work)

• Flagging multiple vendors with same pgp/pubkeys or overlapping review patterns

• Rate limits per IP/session to stop spam

✅ Suggestion: Also consider per-session reputation weights when displaying reviews (older users > new sockpuppets)

🛡 5. Hosting & Infra

• Use layered relays (Tor over VPN, different entry guards)

• Consider hosting backend components on Qubes AppVMs

• For anti-DDoS: front onion with nginx + HAProxy, use guard relays with high uptime, and keep endpoints private

✅ Suggestion: Study the Kingpin model used by some legacy markets: frontend .onion with blind-backend accessed only by internal RPC over onion.

📊 6. Trust & Rep

Simple stars + reviews are too easy to game.

✅ Suggestion: Add metrics like:

• Dispute ratio

• Refund ratio

• Volume vs account age

• Arbiter notes (internal or optional public tag)

🧠 Final note:

The hardest part is burnout and OPSEC drift over time. Set a shutdown timeline, rotate keys, and assume compromise is inevitable. Compartmentalize hard — physically and digitally.

Happy to brainstorm more in DMs or /d/OnionDev. Best of luck 🍀

That's actually a really good idea.

I would also strongly advise against using C++ because it poses serious security risks, mainly due to its memory-insecure nature and the great alternatives that already exist like Rust that solve these problems while basically delivering the same performance.

Since you're using Python for the body anyway, I don't see any real benefit for the performance-critical microservices in e.g. C++ as Python can be a viable choice for the most part, especially with a more security-oriented framework like Django, but Python is just too slow. That would be a massive bottleneck. Personally, I would only use Rust with probably Axum or Actix Web as the framework for the entire app.

In my opinion, for such an operation, where it is hosted, it does not matter, it is important to use only dedicated servers that meet the absolute minimum security requirements, such as full RAM encryption. Additionally, you should have those servers as distributed as possible across providers and even if you got some then at the same provider you should always use for each a customer account for its own and leave no indication of a connection here.

Also, I just recently checked the Tor source code and saw that they are still working on the rewrite in Rust as a language. Personally, I would first help out here and make sure that at least the things that are most important to me are finished and solidly integrated, so that I can run my project on this more secure basis.

After all, not only should you have the strictest security measures in place from start to finish, but you should also plan for a breach of such and how your service and data will still be safe in such a scenario. A very important point here is also to implement quantum-secure encryption at all levels. You also need to keep in mind that your data may not be breached at the moment, but it could be stored for a few years and then easily encrypted.

[removed]

hey im interested in helping. I have experiece with simple website coding and have been working on a similar project. Dm me

I’m down to help — done lil web stuff and on a similar ting. DM me.