Satoshi Settlers
Satoshi Settlers turns Bitcoin blocks into a shared map: you settle tiles, pay sats for land, rely on a refund address, and can log in through Nostr or ZBD while the game remains openly alpha.
A Bitcoin map game, not a wallet
Satoshi Settlers is easiest to understand if you stop looking for a social feed. The official homepage describes it in one sentence: settle and develop the blocks of Bitcoin on a shared world map. The game is about land, blocks, ownership, sats and identity. Nostr is one login path and one identity layer, not the whole product.
The About page gives the real shape of the game. Each piece of land represents a Bitcoin block. The Genesis block sits at the center, and newer blocks spiral outward as they are mined. The block hash influences land properties and resource yield. That makes the Bitcoin chain more than a logo: the game board is derived from the block sequence.
For a reader comparing Nostr projects, that matters. Satoshi Settlers is not a Nostr client like Damus, not a long-form client like YakiHonne, and not a wallet like Alby Hub. It is a browser game that uses Nostr to verify identity and uses Lightning to make game actions expensive enough to matter. You should judge it as a game with money attached.
The public site is also very clear that the project is alpha. It warns that funds can be lost, that refund eligibility depends on a valid Lightning address, and that major parts of the game may change. That warning should be treated as part of the product, not as a footer nobody reads.
How the shared block map works
The map idea is the strong part. Instead of inventing arbitrary land, Satoshi Settlers maps Bitcoin blocks into a world. The official About page says each block can be selected, bought and developed. New blocks keep arriving as Bitcoin advances, so the board is tied to a live external clock rather than a fixed level file.
The current feature set is intentionally small. The page says land ownership is the only main feature of the game right now. You can select up to 500 land tiles at a time by double-clicking or using paint/draw mode, move with WASD, arrow keys or mouse drag, click Buy, customize and confirm in the next menu.
The economic rule is simple and sharp: the base price for each block starts at 32 sats and doubles with every purchase. If someone buys a block that is already owned, the previous owner is refunded 110 percent of the original payment. Structures upgrade with each purchase until the tile reaches a castle.
That is not a deep strategy game yet. It is a live ownership board with Bitcoin-native payments. The interesting question is whether the combination of real block data, tiny Lightning payments and public identity becomes playful enough to survive the alpha stage.
The alpha warning is the first feature
The most important sentence on the homepage is not the tagline. It is the warning that the game is currently in alpha and that you should be prepared for possible loss of all funds. That is unusually direct, and it should guide how you test the app.
The About page repeats the practical boundary in a different way: buying land tiles is there to support the game and have a little fun, and it is not an investment. This matters because the game has ownership language, rising prices and refunds. Those mechanics can feel financial even when the developer is telling you not to treat them as an investment product.
A careful reader should separate game economy from asset ownership. You are not buying a Bitcoin block. You are buying a game record associated with a block-shaped tile inside a privately operated alpha service. If future game updates change the transaction model, map format, refund rule or login behavior, the official homepage already tells you that can happen.
That does not make Satoshi Settlers bad. It makes it experimental. The right test amount is the amount you would happily spend on an unfinished arcade cabinet because you want to see the idea work. If that number is not tiny, step back.
Nostr login is real and narrow
The Nostr login path is concrete. The homepage checks for `window.nostr`, the browser capability defined by NIP-07-compatible extensions. If it finds a provider, it asks for the public key, creates an event, asks the extension to sign it and sends the signed event to the server endpoint `/auth/nostrlogin`.
The event kind is 27235, the event kind used by NIP-98 HTTP Auth. The event includes a `u` tag for `https://satoshisettlers.com` and a `method` tag with `GET`. That is a good sign because it means the app is not asking the browser extension to sign a vague text blob. It is signing a domain-bound login proof.
After a successful login response, the page optionally calls `window.nostr.getRelays()`, turns the returned relay map into a list and sends up to three relay URLs to `/auth/nostruserconfig`. That does not make the whole game decentralized. It means the login flow can carry a small amount of the user's relay preference into the server session.
The narrowness is important. The visible code does not show a Nostr feed, Nostr event publishing for land purchases, relay-synced game state or portable ownership events. The current observable Nostr role is account identity and login configuration. That is useful, but you should not describe it as a fully Nostr-native game world unless future evidence shows that.
What the extension prompt should mean
If you click Nostr login, your signer prompt should be treated like any other authorization prompt. You want to see the app domain, understand the kind of event being signed and avoid exposing a raw private key. A NIP-07 extension should hold the key or connect to a safer signing setup; the web page should not ask you to paste an nsec.
The Satoshi Settlers code uses `getPublicKey()` and `signEvent()`, which are the basic NIP-07 functions. That is the normal browser-extension pattern. The recommended extensions page points to nos2x, ZBD Browser Extension, Nostr Connect and Flamingo. Each of those has a different trust model and maintenance story, so the extension choice is part of the login risk.
The code also catches failures with a message asking whether the Nostr browser extension is misconfigured. That is honest UX for an alpha app. Nostr extension behavior varies across browsers, mobile setups, NIP-46 bridges and permission prompts. A failed login does not always mean the game is broken; it can mean the signer did not expose the method expected by the page.
For a first test, use a low-risk Nostr identity. If your main npub is tied to public reputation, payments and real contacts, consider whether you want an alpha game session attached to it. The game does not need your most valuable identity to prove the idea.
The OTP fallback uses Nostr DMs
If no Nostr extension is detected, the site opens a modal that recommends extensions and offers OTP login. The modal says a code will be sent to your DMs, warns that the code expires after five minutes, and asks for either an npub or a NIP-05 style name. It also allows an optional custom relay beginning with `wss://`.
That fallback is practical because not every browser has a NIP-07 provider. It also creates a different security and reliability model. Now the app must deliver a message to a relay path you can read, you must find the DM, and the relay you choose can decide whether the message arrives quickly enough.
The input validation in the visible page accepts an `npub1` value of the expected length or an email-shaped NIP-05 value, plus a WebSocket relay URL. That is not a full proof of NIP-05 correctness on the client. It is a front-end check before the server handles the real verification and message delivery.
Use the OTP path as a fallback, not as an excuse to rush. If you enter a NIP-05 name, make sure it resolves to the key you expect. If you enter a custom relay, use one you trust to receive the DM. If the code does not arrive, do not keep spraying login attempts across random relays.
Lightning is where risk becomes real
The land mechanic requires sats. The About page says purchasing land requires a Lightning address, and the homepage says that refund eligibility depends on a valid Lightning address. That means identity, game state and payments meet at the refund path.
The visible map wrapper also includes a browser event named `weblnpay`. When the game dispatches it, the page attempts `window.webln.enable()`, strips a `lightning:` prefix from the invoice if present and calls `window.webln.sendPayment()` with the cleaned invoice. That is a standard WebLN-style payment bridge from the game into a browser wallet provider.
WebLN is not Nostr Wallet Connect. WebLN is a browser interface for Lightning apps and wallet providers. A browser wallet may itself be backed by many things, including an NWC-connected wallet, but the observable Satoshi Settlers payment hook is `window.webln`, not a direct NIP-47 request in the page source.
That also changes what you should inspect in a payment prompt. With NWC, you would care about a connection secret, relay route, budget, method permissions and revocation path. With WebLN, the first visible question is whether the browser wallet is asking you to approve a specific invoice from the Satoshi Settlers page. The wallet may hide its own backend complexity, so the page-level check is invoice clarity, amount, domain and the ability to cancel.
This distinction protects you from overclaiming. The game can be present in a NWC ecosystem list because NWC-enabled wallets and extensions can be part of the payment path. But the current public code does not prove that Satoshi Settlers itself speaks NIP-47. Describe the visible flow: Lightning payments through ZBD login and WebLN-compatible browser wallet behavior.
ZBD is the other front door
The homepage places ZBD login next to Nostr login. The official Friends page also lists ZBD among the project's ecosystem links, alongside Alby, Boltz, Breez, BTCPay Server, Mutiny, Start9 and TimeChainCalendar. That tells you the game is rooted in the Bitcoin application world, not only in Nostr culture.
ZBD matters because it can combine account identity, Lightning access and browser extension behavior in one user-facing path. The Satoshi Settlers extension page specifically recommends the ZBD Browser Extension as one option for Nostr login, and public extension listings describe it as a sats and connection tool for the browser.
For readers, the safe question is not which brand appears on the button. The safe question is what signs, what pays and what can be revoked. ZBD login may be convenient. A Nostr extension may be portable. A WebLN provider may request payment approval. Each step has its own permission surface.
If you already use ZBD, Satoshi Settlers may feel smoother through that path. If you prefer to keep game identity and payment custody separate, test the Nostr login and a separate WebLN wallet with a tiny amount. Convenience is not automatically the same thing as control.
Guest play is useful but disposable
The site offers guest play, and the guest warning is blunt. Guests can do what logged-in users can do, but they cannot resume the game session, cannot reserve a username, and the session can be purged after 24 hours or logout. The warning also says a refund Lightning address is required when buying a block.
That makes guest mode a good way to inspect the interface, movement and map concept before attaching a valuable identity. It is not a good way to build anything you care about preserving. If you buy land as a guest, you are accepting a deliberately temporary account layer.
The username rule matters too. The About page says usernames are reserved when you buy a block while logged in as that username via one of the OAuth methods. In plain English: identity persistence is tied to logging in, and name reservation depends on buying while logged in through a supported method.
Use guest mode for a dry run. Move around, inspect the map, read the buy flow, find where a Lightning address is requested and leave before payment if anything is unclear. Then decide whether a Nostr or ZBD account is worth using.
The map is a heavy browser app
The map surface is not a simple form. The public route loads a WASM-backed game module through `wonder15.js` and `wonder15_bg.wasm`, with a large binary payload. The wrapper code uses canvas, fullscreen controls, pointer and keyboard input listeners, and Bevy/WGPU strings are visible inside the WASM build.
The debug page tells you what the developer expects to matter: session type, username, WebGL status, WebGPU status, checkpoint, map size, viewport, screen size, device pixel ratio and user agent. That is a practical diagnostic set for a browser game that depends on graphics, storage and device capability.
The map wrapper stores game data in browser storage. It listens for `localbrowserstorage` and `mapcheckpoint` events, compresses world-map data with pako and LZString, stores a `worldmap` value in localStorage and stores a `checkpoint`. The companion `indexedDB.js` file creates a `worldmap` database and a `tile` object store for tile data and checkpoints.
The operational consequence is simple: your browser matters. A privacy setting, storage cleanup, unsupported GPU path or mobile browser quirk can affect the game. If you are testing with sats, use a modern browser, keep the tab stable, avoid clearing site data mid-session and record what you did.
There is also a recovery lesson in that storage design. If the game appears to hang, load slowly or show stale map data, do not immediately assume your identity or payment failed. First check whether WebGL/WebGPU is available, whether the browser blocked storage, whether the same account is still logged in, and whether the debug page reports the session type and checkpoint you expect. Alpha games often fail at the edge between graphics, storage and server state, so a reproducible bug report is more useful than a vague lost-session complaint.
NWC belongs in the context, not the headline
Satoshi Settlers appears in the Games section of getAlby/awesome-nwc with the description that it lets you settle and develop Bitcoin blocks on a shared world map. That is a useful ecosystem signal because it places the game near NWC-capable wallets and Lightning app experiments.
But the article should not turn that into a claim that Satoshi Settlers is a NIP-47 implementation. NIP-47 is a protocol for apps to talk to wallet services through encrypted Nostr events. The public Satoshi Settlers pages show Nostr login, optional relay capture, ZBD login and WebLN payment hooks. They do not show direct NWC request handling in the visible front end.
A fair formulation is: Satoshi Settlers belongs on the NWC map because it is a Lightning game that can interact with wallet tooling around Nostr users, but its current observable product surface uses Nostr primarily for identity and WebLN/ZBD for payment paths.
If future documentation adds explicit NIP-47 support, the article should be updated. For now, the reader deserves the boundary. Nostr identity, WebLN payment, ZBD login and NWC wallet infrastructure can overlap in one user's setup without being the same protocol.
What to verify before spending sats
Start with the login prompt. If you use Nostr, confirm the signer is not asking for your private key and that the prompt corresponds to the Satoshi Settlers domain. If the extension exposes event details, look for the HTTP-auth shape: kind 27235, the domain URL and the GET method tag.
Then test identity persistence. Log in, open the game, move around, log out and return. Make sure you understand what is tied to your Nostr or ZBD account and what would vanish in guest mode. Do this before paying for a tile.
Next test the Lightning path with the smallest amount the game allows. Confirm the Lightning address you provide is valid and controlled by you. If a WebLN prompt appears, read the invoice request before approving. After payment, record the tile, amount, username and time. If the game offers an invoice copy button, save the invoice for your own notes.
Then check the refund story before you rely on it. The game's public description says the previous owner receives 110 percent of the initial payment when another player buys the block, and it also says a valid Lightning address matters for refund payments. Those two statements belong together. A refund rule is only useful if the account, address and server-side record line up when the later purchase happens.
Finally, assume alpha behavior. A successful purchase today does not prove the future refund rule, map migration, session persistence or browser storage path will never change. That is exactly why the official page tells you to expect possible changes. Play it like an experiment with a public warning label.
Who Satoshi Settlers is for
Satoshi Settlers is for a specific kind of curious Bitcoin/Nostr user: someone who likes tiny payments, weird public experiments, block-height lore and browser games that are still visibly being built. It is not for someone who wants a polished mobile game, a guaranteed asset, a regulated investment product or a wallet with clear custody guarantees.
The game has charm because it makes Bitcoin blocks spatial. The map, the doubling tile prices, the refund mechanic, the Nostr login and the WebLN bridge all point toward a playful idea: what if the timechain became a board that people could mark with small Lightning payments?
The same charm is the risk. Money, identity and unfinished game state are mixed together. That is fine if you enter with the right expectations. It is dangerous if you treat the map like property or the refund rule like a financial promise.
The safest closeout is simple: open the site, read the About page, try guest mode, inspect the Nostr or ZBD login path, spend only dust if you spend anything, and keep your main wallet and main identity out of the first experiment. If Satoshi Settlers matures, it could become a memorable Bitcoin-native game. Right now, it is an alpha map that asks for careful play.
Sources worth opening
Start with the Satoshi Settlers home, About, Extensions and Friends pages. Then read the visible login code, the game wrapper files, NIP-07, NIP-98 and WebLN docs before putting sats into an alpha map game.
- Satoshi Settlers official home
- Satoshi Settlers About page
- Satoshi Settlers recommended extensions
- Satoshi Settlers Friends page
- Satoshi Settlers debug page
- Satoshi Settlers PWA manifest
- Satoshi Settlers app shell HTML
- Satoshi Settlers navigation script
- Satoshi Settlers social links script
- Satoshi Settlers IndexedDB helper
- Satoshi Settlers compression helper
- Satoshi Settlers current game wrapper
- Satoshi Settlers WASM game module
- Satoshi Settlers Nostr profile via njump
- getAlby awesome-nwc Games list
- NIP-07 window.nostr browser capability
- NIP-98 HTTP Auth
- NIP-05 identifiers
- NIP-47 Nostr Wallet Connect
- WebLN documentation
- WebLN sendPayment reference
- WebLN getting started guide
- ZBD Browser Extension on Chrome Web Store
- ZBD Browser Extension on Firefox Add-ons
- nos2x extension on Chrome Web Store
- Nostr Connect extension on Chrome Web Store
- Flamingo Nostr extension on Chrome Web Store
- Alby official site
- Breez official site
- BTCPay Server official site
