No makers found: fixing an empty maker list in the eigenwallet app

What the empty list means

The eigenwallet desktop app (formerly UnstoppableSwap; same network, same protocol) does not know any maker on its own. At start it dials the rendezvous nodes in its settings, asks each one which makers are registered there, then requests a quote from every maker it learns about. "No makers found" therefore does not mean that nobody is offering XMR. It means that, for the nodes in your list, the dial failed, the answer could not be read, or no quote came back.

The distinction matters because the usual fix is not on your side of the network. Restarting your router, changing DNS or disabling a VPN rarely changes anything here; pointing the app at a node it can read does.

Why stock releases 4.13 to 4.15 show Unavailable

Stock releases 4.13 to 4.15 carry a client-side discovery bug: the busy public rendezvous nodes are shown as Unavailable even when they are online, and the makers registered there never reach the list. The nodes answer; the app cannot read the answer. Because most makers register on those public nodes, a stock app's offer list can look empty or much shorter than the network really is.

Reinstalling the same release does not help; the fix has to ship on the app side. Until it does, the workaround is to add a rendezvous node the app can read. Our maker registers on such a node, and the steps below use it as the example.

Step 1: add a rendezvous node the app can read

Open the app, go to Settings, then Rendezvous Points, and paste this address in full, with no spaces: /dns4/p2p.btc-xmr.com/tcp/8890/p2p/12D3KooWBPe3sx6dDqE1RSzeBpH1ayghtBp4cgyymti5rPy79xWz

Click Add. The line has two halves: the part before /p2p/ says where to dial (a DNS name and TCP port 8890), the part after /p2p/ is the node's peer id, which the app expects to match the node that answers. The field takes the whole multiaddr; a peer id on its own, or the dial part on its own, will not do. Copy it from this page or from the desktop-app guide (/desktop-app), not from a chat message that may have wrapped it.

Step 2: restart the app

Quit the app completely and open it again. Current releases read the rendezvous list once, at start, so a node added while the app runs is not queried until the next launch. This is the step most people skip, and it is why the list often looks unchanged right after adding a node.

After the restart, open the app's Swap page. Our maker should appear once the app has fetched our quote, usually within a minute over clearnet; over Tor, allow a few minutes more.

Step 3: if the list is still empty

Check the address character by character. A missing or extra character in the peer id or the port makes the dial or the identity check fail, and both look exactly like a dead node from the app's side.

Check that port 8890 is reachable. Our node answers on TCP port 8890, not on 80 or 443, and some office, campus and mobile networks block outbound connections to other ports. Try from another network, or use the Swap page of this site (/): it runs the taker on our server and needs only a browser, a Bitcoin browser wallet (Unisat) and port 443.

Wait a few minutes and retry. Our quote moves with our inventory: the minimum and maximum are published live on the Swap page (/), and the maximum can shrink while a swap is in progress on our side.

Check the app version. If it is 4.13 to 4.15 and the public nodes show Unavailable, that is the discovery bug above, not a problem with your machine. Our node still works with those releases.

What you get once the maker appears

The maker you reach this way is the one that serves this website: one quote, one price, whether the app or the Swap page asks. Commission, Bitcoin network fee and the absence of any developer tip on our side are explained on the fees page (/fees); where your keys are in each client is on the desktop-app guide (/desktop-app).

The swap is an atomic swap with the same locks and refund path in both clients: your BTC goes into a 2-of-2 lock, we lock XMR, and if we fail to complete, a cancel timelock of about 24 Bitcoin blocks (roughly 4 hours) opens the refund path; if we never lock XMR, the refund comes earlier. Expect 30 to 60 minutes, set by one Bitcoin confirmation and ten Monero confirmations. The full sequence is on How it works (/how).