@simplex although I am fairly new to this world, I have been using Simplex for some time now as a privacy / sovereignty maxi, so I’m writing this in good faith but from a hostile threat-model.
I also do not claim to understand all the technical details here. I am clearly using AI to help me understand and get my point across, still that shouldn't take away from the message I am trying to convey.
First, respect where it’s due:
– Novel protocol, no protocol-level user IDs.
– Serious work on metadata resistance + private routing.
– Clear stance vs MLS and client-side scanning.
– Audits + willingness to say “we’d shut down before ChatControl.”
All that said, the new Community Vouchers / SMPX / zkEVM plan raises big red flags from a sovereignty & Bitcoin perspective, and there are some contradictions I want to put on the record.
(1) “No shitcoins” vs SMPX + NFT + zkEVM
On Nostr/X you’ve repeatedly said “we’re not doing shitcoins” and answered “No” to “are you adding shitcoins to SimpleX.”
At the same time:
– Your own docs say Community Vouchers are implemented as a utility token on an EVM/zkEVM chain (SMPX, ERC-20 compatible).
– You’re issuing a non-transferable NFT on Ethereum mainnet as an access pass to the testnet.
– The token underlies names, server registry, payments and revenue sharing.
From a Bitcoin/sovereignty POV, this is an altcoin/token stack, regardless of pre-mine / speculation / fundraising.
Q1. Why not just say plainly: “Yes, we’re building an EVM-based token layer for network economics, but we’re trying to keep it non-speculative”? Right now it feels like a semantic dodge.
(2) “Not tradable” in the banner vs “maybe transferable” in the FAQ
Public copy and Nostr replies say:
– “Community Vouchers are not tradable, cannot be sold, expire in 6–12 months; no pre-mine; no public sale.”
But your own FAQ also says something like:
– Transfer may be possible with strict limits on number of transfers and holding time, enforced by smart contracts; details TBD.
So at the spec level:
– Vouchers = SMPX tokens on an EVM L2
– ERC-20 compatible
– Transferability not fully ruled out; parameters undecided.
Q2. Can you clarify this honestly: are SMPX vouchers structurally untransferable, or are they transferable with restrictions? If the latter, why keep “not tradable” as your headline?
Q3. What is your explicit stance on secondary / OTC markets for SMPX (even if contracts limit transfers)? Do you expect them, and what do you do when they appear?
(3) Operator “trust evaluation”, identity, and regulatory capture
In the vouchers design you say:
– Operators who confirm identity and accept legally-binding terms get higher revenue share.
– “Trust evaluation” (uptime, longevity, etc.) feeds on-chain metrics.
– Funds are released from the contract only when capacity is proven, then split between operators and a SimpleX “network treasury”.
That means:
– The economically meaningful operators are the known, contract-signing ones.
– You are building a regulator-friendly class of service providers, with KYC-like characteristics and on-chain trust scores.
Q4. How do you prevent this from sliding into full-blown regulatory capture (OFAC lists, EU ChatControl-style terms baked into the operator contract, etc.) once significant money flows through this system?
Q5. Do you commit, in writing, to never making “known, contract-signing operators” a requirement for preset/default servers, even under EU pressure?
(4) Altchain / L2 / stablecoin dependency
By design:
– SMPX lives on a zkEVM/L2.
– Purchases are done via cards/app stores or via crypto (Bitcoin/Monero/etc.), but the settlement & accounting sits in the EVM universe.
– Names, server registry, and payments live in that same stack.
That imports:
– L2 governance politics,
– sequencer centralization,
– stablecoin issuer risk,
– and the full regulatory blast radius of Ethereum-land.
Q6. What is your contingency plan if the chosen L2 starts censoring, gets captured, or dies? Does the network degrade gracefully (names/registry/payments decouple), or are you effectively locking these core functions into that ecosystem?
Q7. Why was an EVM + token stack considered more acceptable than a Bitcoin + Cashu/Fedimint/Lightning approach, given that the latter could also provide unlinkable payments and revenue sharing without creating a new asset?
I understand the “trust in a mint” concern, but you’re now trusting:
– an L2 sequencer,
– complex smart contracts + upgrade keys,
– and an entire altchain governance process.
For some of us, that’s a bigger trust surface, not a smaller one.
(5) “No identifiers” vs IP reality & infra concentration
External analysis (maqp, PrivacyGuides, etc.) has pointed out:
– Default preset servers being concentrated on a small number of infra providers (e.g. Akamai + Flux).
– IP addresses still being long-lived identifiers unless people consciously route over Tor/VPN (which is not default).
Yet your marketing often leans very hard on “no identifiers” and suggests a stronger anonymity set than most people actually get in practice.
Q8. Are you willing to update your public messaging to reflect the real IP/threat model more precisely (especially around preset servers + no default Tor), instead of letting people think SimpleX has “no identifiers” in the strong sense?
Where I’m at:
From my perspective:
– SimpleX is still doing serious work on protocol & privacy.
– Self-hosted SimpleX for 1:1 / small groups is still interesting as a tool.
– But the SMPX/zkEVM vouchers + KYC-tilted operator economics make it impossible to treat SimpleX as a sovereign-grade anchor for comms.
What I am asking for:
– Clear acknowledgment that this is an altchain token + governance layer.
– Honest accounting of the regulatory and centralization risks.
– A concrete answer on why you chose this path over a Bitcoin/ecash-based model, beyond “smart contracts are convenient.”
If you’re willing to engage on those points directly, it would go a long way for those of us who care about both privacy and monetary / governance sovereignty.