RoboSats

RoboSats is the Lightning-native P2P BTC↔fiat exchange over Tor — a protocol where each trade session generates an ephemeral robot avatar from a private key, hold-invoice multi-sig escrows both legs of the swap, and the entire UX lives on a Tor onion service so neither operator nor exit-node sees your trade. Listed at Grade A because RoboSats occupies a unique category-of-one: faster than Bisq classic (Lightning instead of on-chain BTC = minutes vs hours), more anonymous than Bisq Easy (ephemeral robot identity vs reputation pseudonym), and structurally different from swap aggregators (peer-to-peer-fiat, not aggregator-routes-via-exchange).

Background. RoboSats was launched as an open-source project in 2022 by Reckless Satoshi (pseudonymous developer) with the explicit design goal of "no accounts, no KYC, no email" P2P fiat trading on Lightning. The protocol uses hold invoices — a Lightning Network primitive where the payer commits funds that are held in suspended state until a settlement key is revealed; this allows multi-sig-equivalent escrow without on-chain transactions. Each trade session creates a robot avatar deterministically generated from a user-side private key — your identity is a robot face that exists for one trade and is gone after. The reference application is Tor-primary: the canonical access path is the .onion service, with a clearnet mirror as a convenience but not the primary surface. Open source on GitHub, multiple coordinator nodes operate the protocol (federated rather than centralised) — the user picks which coordinator to route through.

What you trust. Lightning hold-invoice escrow — both parties commit Lightning payments that are held in suspended state until settlement; neither party can run with the funds because the settlement key is only released on bilateral cooperation. Multi-coordinator federation — RoboSats coordinators are run by multiple independent operators; you choose which coordinator to use. If one coordinator goes hostile, you switch. Tor by default — canonical access is via .onion; the entire trade flow stays in the Tor network and the coordinator sees only Tor-circuit traffic. Ephemeral identity — your "robot" exists for one trade; there is no persistent account, no history accumulated, no reputation per-se (which is also a trust trade-off — see Caveats). Open-source codebase — anyone can audit the protocol and the application; coordinator infrastructure is documented for operators to run their own. What you don't trust: the coordinator with your funds (hold invoices are not custodial); the operator's TLS (Tor onion bypasses TLS); your counterparty (Lightning escrow constrains them as well).

Operational specs. Platform: web application (Tor-primary, clearnet mirror), plus a mobile web wrapper (RoboSats mobile); all canonical routes via .onion at robosats6tkf3eva7x2voqso3a5wcorsnw34jveyxfqi2fu7oyheasid.onion. Trading pair: BTC (Lightning) ↔ fiat (USD, EUR, many local currencies). Payment methods: SEPA bank transfer, Wise, Revolut, cash-by-mail, gift cards, in-person cash — the maker's offer specifies. Trade size: typically $20-$2k, with some coordinators supporting larger; trade-size depends on Lightning channel liquidity and maker willingness. Trade timeline: minutes — Lightning settlement is near-instant; total flow including fiat-confirmation and chat is typically 15-30 minutes. Fees: ~0.2% per side (maker + taker), among the lowest in the P2P fiat-on-ramp category. Federation: 5-10+ independent coordinator nodes operating at any time; users see coordinator selection in the UI. No KYC under any circumstances — there is no account, no email; the robot identity is generated locally from a user-side private key and not associated with any PII.

Philosophy. RoboSats' editorial differentiator is the Lightning-multi-sig-escrow-on-Tor model. Bisq classic uses on-chain BTC multi-sig (operationally heavy, settled in hours). Bisq Easy uses reputation (no protocol-escrow, fast for small trades). RoboSats uses Lightning hold-invoices (protocol-escrow without the on-chain heaviness, fast like Bisq Easy but with the trust guarantees of Bisq classic). The ephemeral robot identity is a deliberate choice to avoid reputation systems entirely — Bisq Easy's BSQ-reputation model creates a long-term identifier for sellers (good for trust, bad for unlinkability); RoboSats says: each trade is a fresh identity, the escrow protocol does the heavy lifting on trust, no long-term seller graph exists. The trade-off: you can't reward repeat-trader behaviour, you can't filter for known-good sellers, you take protocol-escrow's trust math at each trade.

Grade rationale. Grade A reflects: open-source codebase; federated coordinator structure (no single party can shut the protocol down); Tor-primary architecture (.onion is the canonical access); Lightning-native hold-invoice escrow (multi-sig-equivalent without on-chain costs); ephemeral robot-identity design (deliberate anti-reputation, anti-correlation); no KYC under any circumstances; no account creation, no email; ~0.2% per-side fees (competitive with the lowest in P2P fiat-on-ramps); active development since 2022; cross-listed in KYCnot and web3privacy peer directories. Last verified 2026-05-12.

Useful when. You want a fast P2P BTC↔fiat trade ($20-$2k typical) where the entire flow happens over Tor in 15-30 minutes. You want zero account creation, zero email, zero KYC — the strictest privacy posture available in P2P fiat-on-ramps. You're a Lightning user with a Lightning wallet ready (Phoenix, Breez, Zeus, or a self-hosted node) and want fiat→Lightning rather than fiat→on-chain. You're privacy-maximalist and want ephemeral-per-trade identity rather than the persistent pseudonym Bisq Easy uses. You're on a system where running a desktop Bisq application is impractical and want a browser-based (Tor) flow instead. You want federation rather than a single-operator dependency.

Caveats. Lightning wallet required — if you don't already use Lightning, the setup overhead (channel liquidity, wallet choice, on-chain BTC funding) is non-trivial. RoboSats is best for users already comfortable in Lightning. Smaller liquidity than Bisq — fewer makers, narrower payment-method coverage in some currencies; pair availability is a function of which coordinators have active makers. No reputation system means brand-new makers and known-good makers look identical — protocol-escrow protects you, but you can't preferentially filter for repeat-trustworthy makers; for some users this anti-reputation stance is a feature, for others it's a friction. Coordinator-trust is non-zero — the coordinator orchestrates the trade (chat routing, dispute escalation), and while they can't custodially run with funds, a malicious coordinator could withhold settlement or leak metadata; pick coordinators with public reputation. Lightning hold-invoice escrow has its own quirks — fund-locking during the trade window means your Lightning channel liquidity is briefly committed; for large trades, ensure adequate channel capacity. Fiat-payment-method risk is on you — Lightning hold-invoice protects the BTC leg; the fiat leg depends on the buyer actually sending fiat. Use payment methods with reversal protections cautiously (chargeback risk for sellers). Disputes are coordinator-mediated — if the trade goes sideways, the coordinator arbitrates; this is a soft escalation path, not a hard guarantee. No native XMR support — RoboSats is BTC/Lightning only; for fiat → XMR P2P, use Haveno; for BTC → XMR, use an aggregator after the RoboSats trade settles.