This is a non-exhaustive compilation based on past experience of users. We have not tested every wallet, if you test a wallet that is not yet covered, please report here.

Core Lightningv0.11.1 
  1. UX: Does the wallet convey clearly that there is an “ongoing” payment (hodl invoice)?
  2. Bonds: Can the wallet lock the invoices with long expiry time needed for the bonds?
  3. Payout: Can the wallet receive payouts from RoboSats after the user buys Sats?
  4. Compatible: Is the wallet overally compatible end-to-end with RoboSats?
  5. Total: Is the wallet compatible and stable enough to be used consistently without issues?

Alby (browser extension)

Alby is a browser extension compatible with WebLN standard. Since RoboSats supports WebLN, the experience with Alby is probably best-in-class: you won’t have to scan the QR codes or generate invoices, simply click on the Alby pop up to confirm the actions. You can connect the Alby extension to most of the popular nodes and wallets, or simply let Alby host a custodial wallet for you.

Special instructions to install Alby in Tor Browser:

  1. Install the Alby extension from the Firefox add-ons store
  2. Alby needs persistent memory, Tor Browser disables it by default. Go to Settings, type "History" on the search bar and uncheck "Always use private browsing mode"
  3. Click on the Alby extension and follow the prompts to setup your wallet.

Blixt (Android/iOS, LND light backend on device)

Most development testing for Robosats has been done using Blixt. This is one of the most complete lightning wallets around. However, it does lead to misunderstanding when hold invoices are locked, as it shows a spinner with payment in transit. The user needs to check on the website for confirmation. Blixt allows for multiple pending HTLCs, this is necessary as a seller since you need to lock a taker/maker bond and then a trade escrow (2 pending concurrent HTLCs). It might eventually also display as paid/charged invoices that are still pending, specially if the user force closes blixt and reopens it. Occasionally can display as charged fidelity bonds that have in fact been returned.

Electrum (Desktop)

Experience using Electrum is limited. It does not seem to support more than one pending HTLCs (even if there is multiple channels). This wallet is not recommended to use with RoboSats. However, it works well if you are a buyer, as only one hold invoice for the fidelity bond is needed. The payment shows as pending with a spinner for the duration of the locktime.

LND (CLI Interface)

Raw, it shows exactly what is happening and what it knows “IN_FLIGHT”. It is not user friendly and therefore not recommended to interact with Robosats by beginners. However, everything works just. If you are using LNCLI regularly, you will find no issue to use it with RoboSats.

Core Lightning / CLN (CLI Interface)

Works as expected. The lightning-cli pay <invoice> command does not conclude while the payment is pending, but can use lightning-cli paystatus <invoice> to monitor the state.

Zeus (Mobile, LND, CLN, Eclair remote backend)

It is an interface to LND, CLN and Eclair. It works as expected. It is extremely misleading with a full red screen “TIME OUT” a few seconds after sending the HTLC. Yet, if the user checks on the website, the invoice is correctly locked.

Muun (Mobile)

Muun plays same nicely with hold invoices as Blixt or LND. You can be a seller in RoboSats using Muun and the user experience will be great. However, in order to be a buyer, you need to submit an onchain address for the payout, a lightning invoice won’t work. Muun is fee siphoning attacking any sender to Muun wallet. There is a mandatory hop trough a private channel with a fee of +1500ppm. RoboSats will strictly not route a buyer payout for a net loss. Given that RoboSats trading fees are 0.2% and it needs to cover the routing fees, RoboSats will never find a suitable route to a Muun wallet user. At the moment, RoboSats will scan your invoice for routing hints that can potentially encode a fee siphoning attack.If this trick is found, the invoice will be rejected: submit an onchain address instead for an on-the-fly swap.

Phoenix (Mobile)

Phoenix works very well as an order taker. Phoenix will also work well as an order maker as long as the order settings public duration + deposit duration are lower than 10 hours. Otherwise you might have problems locking the maker bond. If the total duraton of bonds/escrow invoices exceeds 450 blocks, Phoenix will not allow users to lock the bond (Cannot add htlc (...) reason=expiry too big).

Bluewallet (Mobile)

It works well. But they are having issues in the custodial mode. Escrows that RoboSats returns are charged to users (so Bluewallet is keeping that balance?). Bonds that are slashed…are charged twice by Blue! More info once they reply to us. EDIT: Blue has confirmed they are working to soon solve these accounting bugs!

Bitcoin Beach (Mobile)

The hodl invoice shows as a grey icon while waiting. Need to tap the obvious back button to return to the main screen while the payment is pending.

SBW (Mobile)

One of the simplest and one of the best. The hodl invoice shows as “on fly”. Nowadays (14-06-2022) it is NOT recommend to use the default Hosted Channel until the developer is back but the wallet is safe and works fine.

Help keep this page updated

There are many wallets and all of them keep improving at lightning speed. You can contribute to the RoboSats Open Source Project by testing wallets, editing the content of this page and opening a Pull Request