Blotto
Blotto is a tiny-sats Lightning lottery, not a serious wallet or a social client. Read it as an LNFly/NWC experiment: it shows how quickly a Lightning app can be made, how ticket payments can be wired into a web flow, and why permission, randomness, custody and gambling risk matter even when the amounts look playful.
What Blotto really is
Blotto is a small Lightning lottery experiment built with LNFly, the Alby Labs platform for quickly generating Lightning-capable web apps. It is not the academic Colonel Blotto game, not a normal Nostr client and not a wallet. The public NWC ecosystem post describes it as one of the apps created by LNFly and frames it as a simple Lightning lottery.
The current public traces point to a tiny ticket game. The awesome-nwc list says Blotto lets people participate in a Lightning lottery, buy tickets and win prizes. Search snippets for the live page show a V2 interface with 21 sats per ticket, a countdown timer, ticket count, prize pool and a buy-tickets action. Older community posts described a previous version with a higher ticket price, downloadable ticket and a winner chosen after the countdown ended.
That version drift is important. LNFly apps can be regenerated, updated and experimental. Do not treat an old screenshot or post as a rulebook. Treat Blotto as a live web experiment where the current page, current price, current prize pool and current claim instructions are what matter before you send sats.
Why it belongs in Miscellaneous
Blotto belongs in Miscellaneous because it is not a broad product category by itself. It is a little payment-powered game that demonstrates NWC and Lightning app behavior. It is not a social client, not a marketplace, not a wallet interface, not an exchange and not a developer library, even though it depends on developer tooling underneath.
The Miscellaneous label is useful for readers because it lowers the stakes of the claim. Blotto is not presented here as infrastructure you should build a business on. It is an example of a thing NWC makes possible: connect a wallet, pay a small amount, let the app react to payment state and run a lightweight game mechanic around that payment.
That also makes it a good teaching object. You can inspect it to understand how Lightning payments enter app UX, how a prize pool creates custody questions, and why randomness, server state and legal context matter. You should not need to pretend it is more mature than it is.
The LNFly connection
LNFly is the platform behind Blotto. The LNFly README describes Lightning Fly as a way to quickly create apps that can earn through Bitcoin Lightning payments. It supports basic HTML app generation, frontend and backend generation, app publishing, payment-related tools, NWC actions, Bitcoin Connect, WebLN and some Nostr posting behavior.
That context tells you what Blotto is likely made from. LNFly apps are intentionally lightweight. The README says generated output quality varies and that an app may need regeneration if it does not work. It also says the platform focuses on simple frontend files and Deno backend files when backend behavior is needed. This is a rapid-prototyping environment, not a formal audited game studio.
Blotto should therefore be judged like a prototype that happens to move real sats. The Lightning part is real. The ticket price may be tiny. The generated nature still matters because a payment bug, backend restart, storage bug, bad random selection or unclear claim path can cost users money or trust.
The payment surface
Blotto's product action is simple: buy a lottery ticket with Lightning and wait for the outcome. Under the hood, LNFly knows how to use Bitcoin Connect, WebLN, invoice generation, invoice verification and NWC actions such as creating, looking up and paying invoices. The exact Blotto implementation may use only part of that toolkit, so you should inspect the live payment screen before approving anything.
Bitcoin Connect is relevant because it gives web apps a wallet connection and payment modal layer. WebLN is relevant because it standardizes how a web app can ask a Lightning-capable browser or wallet provider to do payment actions. NWC is relevant because it lets apps talk to a wallet service over Nostr relays rather than integrating every wallet separately.
For a user, the safety question is plain: what permission are you granting? A one-off invoice payment is different from pasting a reusable NWC connection string. A payment modal that asks you to confirm a single ticket is different from a connection that can pay future invoices. Blotto is only a tiny game, but the wallet permission model is the same one used by much more serious apps.
Ticket mechanics and version drift
The indexed live app text shows Blotto V2 at 21 sats per ticket with a timer that increases when tickets are bought. Older community discussion described a version where each ticket added ten minutes to the countdown and where a paid ticket could be downloaded after invoice payment. A later Stacker update headline references multiple-ticket purchase and a Nostr bot, but the deep link is not a stable source to rely on here.
This is not a problem by itself. Games evolve. The danger is assuming the rules from one version still apply to another. If the current page says 21 sats and the old post says 210 sats, believe the current page after you verify it. If the current page changes the claim method, follow the current claim method.
Before buying, read the current instructions. Check the ticket price, whether one payment buys one ticket or several, whether a ticket file is issued, whether an email or Lightning address is needed, how the timer works, how the winner is selected, how the prize is claimed and what happens if the page closes before you save proof.
Prize pools need trust boundaries
A prize pool is a custody question. If users buy tickets and the sats accumulate somewhere until a winner is chosen, someone or some process controls the pool. That control may be in a generated backend, an NWC-connected wallet, an LNFly account, a Lightning address, a manual operator flow or a combination of these. The public materials do not give enough detail to treat the pool as trustless.
For a small game, that may be acceptable. A few dozen sats can be entertainment. But the article should not blur amusement into assurance. If the pool becomes large, you need stronger answers: who controls the funds, how winner selection is verified, what happens if the backend stops, whether failed tickets are refunded and whether the claim path can be manipulated.
The right default is to assume you can lose the ticket cost. Do not buy tickets with funds you care about. Do not treat the prize pool as savings. Do not send a reusable wallet permission unless the wallet can cap it tightly. The lower the amount, the more honest the experiment becomes.
Randomness is the core audit question
A lottery is only as credible as its randomness and claim logic. A random paid ticket must be selected from the actual set of paid tickets, not from unpaid attempts, duplicate records, malformed entries or a mutable client-side list. The app also needs a clear way to prove a user owns the winning ticket.
The older community explanation said a ticket could be downloaded after payment and later uploaded to claim the reward if it matched the winning ticket. That is a sensible shape for a prototype because it gives the player a piece of proof. But a reader still needs to ask how tickets are generated, whether the ticket contains secrets, whether it can be guessed, and how the backend verifies it.
If you are evaluating Blotto as a developer, look for public code, deterministic draw records, signed results, public ticket commitments or at least a transparent operator explanation. If those are absent, keep the mental model simple: it is a fun tiny Lightning app, not a provably fair gambling protocol.
Nostr is present, but narrow
Blotto's Nostr relevance is not a profile feed. It comes from the NWC ecosystem, LNFly's Nostr and NWC support, and the NWC account publicly showcasing Blotto as an LNFly-created app. The app is listed in awesome-nwc because it belongs to the growing set of web experiences that can use wallet-connected Lightning flows.
NIP-47 is the important standard if Blotto uses NWC in the active payment or wallet-control path. NIP-04 is also relevant because the published NIP-47 flow uses encrypted request and response events. Nostr relays carry these events, but the user does not need to be a social Nostr user to make a wallet connection.
This is one of the more interesting parts of the project. Nostr is not always visible. Sometimes it is a hidden coordination layer between an app and a wallet. Blotto makes that idea easy to understand because the user action is tiny: approve a payment, watch a counter change and see the app react.
Wallet permissions are the real safety lever
If Blotto asks for a one-time Lightning invoice payment, the risk is mostly the ticket price. If it asks for a NWC connection, the risk depends on the connection limits. A NWC URL can let an app request wallet actions until revoked or expired, depending on the wallet service and permissions you grant.
Use a dedicated wallet or sub-wallet for experiments. If your wallet supports budgets, use the smallest daily or total limit that makes sense. If it supports expiry, set one. If it supports named connections, call it Blotto so you can delete it later. Do not connect your main spending wallet to random games with broad pay permissions.
Alby Hub, Alby Go, Zeus and other NWC-capable wallets exist because users should be able to connect apps without giving every app custody. That is powerful. It also makes permission hygiene more important. A playful app is still software asking your wallet to move money.
Legal and age checks
Blotto is a lottery-style game. Even when the ticket price is tiny and the prize is measured in sats, local laws can treat chance-based prize games seriously. Age limits, gambling licensing, sweepstakes rules, tax treatment and online-gambling restrictions vary by jurisdiction. A small Lightning invoice does not automatically make the activity legal where you live.
A reader should not treat this page as legal advice. The practical rule is simpler: do not use chance-based money games if you are underage, if gambling is restricted in your jurisdiction, if you are trying to avoid regulation, or if you cannot afford to lose the entry cost. Responsible-gambling resources exist because small repeated bets can still become harmful behavior.
For operators, the risk is larger. Running a prize pool, taking ticket payments and paying a winner can create obligations around consumer protection, gambling law, taxes, fraud, sanctions and recordkeeping. If Blotto is a demo, keep it a demo. If it becomes a public product, the legal layer needs real review.
Failure modes to expect
Small Lightning games fail in ordinary ways before they fail in dramatic ways. An invoice can expire. A wallet can pay late. A WebLN provider can be locked. A mobile wallet can be asleep. A relay can be slow. A backend process can restart. A browser tab can close before the user saves a ticket. None of those issues require malice, but each can make a ticket purchase confusing.
Generated app infrastructure adds another layer. LNFly's own README describes variable output quality and a simple frontend-plus-backend model. That is excellent for experimentation, but it means you should not assume mature accounting, durable queues, full replay protection, robust support tooling or carefully audited random selection. The app may be perfectly fun and still not be built for hard financial edge cases.
The most useful pre-flight test is not winning. It is watching one low-value ticket flow from start to finish. Confirm the invoice amount, payment settlement, visible counter change, ticket proof, timer change and cleanup. If any step is unclear at tiny value, it will be more stressful at larger value.
Developers can use those same failures as a checklist. A payment app should explain what happens when an invoice expires, when the wallet pays but the page misses the callback, when the user loses the ticket, when two payments arrive at nearly the same time, when a draw happens during a backend restart and when the prize claim fails. Blotto makes those questions easy to see because the whole product is small enough to reason about.
What to test before playing
Use the smallest possible amount. Open the current Blotto page, read the current ticket price, confirm whether the app asks for a single invoice payment or a wallet connection, and make one low-value test. If the app issues a ticket file or claim token, save it before closing the tab.
Then inspect the result. Did the ticket counter change? Did the prize pool change? Did your wallet show the expected amount? Did the invoice settle once? Did the page give a claim instruction? If the timer changes, does it match the rule shown on the page? If anything feels unclear, stop there.
Finally clean up permissions. If you used NWC, revoke the connection after testing. If you used a browser wallet or WebLN provider, check the site permissions. If you connected with a wallet that supports budgets, confirm no extra spend remains available to the app. A tiny game is a good place to practice wallet hygiene.
What developers can learn
For developers, Blotto is more useful as a case study than as a gambling destination. It demonstrates how a payment-powered app can be made quickly, how a Lightning payment can become an application event and how a NWC-capable ecosystem can make many small apps possible without each app implementing every wallet directly.
LNFly's repository shows the philosophy clearly. It includes frontend generation, backend generation, app publishing, Deno child processes, simple storage, Bitcoin Connect, WebLN, Lightning tools, NWC and Nostr posting support. That is enough to create a surprising amount of product surface quickly, especially for hackathons and demos.
The lesson is also cautionary. The easier it is to make an app that takes payments, the more important it is to label experiments honestly. A generated app with a payment button should explain custody, refunds, failure states and support. If your demo accepts real sats, it has real user risk.
Not a wallet, not a casino platform
Blotto should not be confused with a wallet. A wallet helps you hold, send, receive and manage money. Blotto asks you to spend money on a ticket. Even if NWC is involved, the app is a consumer of wallet permissions, not a replacement for the wallet itself.
It should also not be treated as a mature casino platform. A casino platform would need account controls, jurisdiction handling, responsible-gambling tools, provably fair mechanics, support, terms, dispute handling, AML policy and durable records. Blotto's public footprint looks like a small Lightning experiment, not that stack.
That is not an insult. Tiny experiments are how new payment patterns become understandable. The problem starts only when readers give a prototype the trust they would give a regulated or audited system. Keep the frame accurate and Blotto becomes useful.
The live app can change
The most important practical note is that Blotto's live surface can change faster than articles about it. awesome-nwc currently points to an LNFly app route. Search snippets show the public Blotto subdomain. Community posts describe earlier behavior. LNFly itself is a platform for generating and updating apps.
That means you should verify the current state at the moment of use. The ticket price, app route, available wallet connectors, timer behavior, claim method and prize pool can drift. If the live page is unavailable, reset by an edge server or different from a cached snippet, do not pay until you can see the full flow.
Support expectations should be just as modest. A mature payment product usually has clear terms, contact routes, incident handling, public status, refund policy and a durable account model. Blotto's footprint is closer to an experiment surfaced through LNFly, Nostr posts and community discussion. If a ticket does not appear, a wallet pays after expiry or a claim fails, you may not have the same recovery path you would expect from a normal consumer service. That is another reason to keep the amount tiny. It is also a reason to avoid introducing new users through a game before they understand invoices, wallet prompts and final settlement. For first-time users, a faucet or demo wallet is safer.
A static article can explain the category and risks. It cannot promise that a tiny experimental app will keep the same mechanics forever. The right user habit is direct verification before every payment.
Who Blotto is for
Blotto is for curious Bitcoin and NWC users who want to see a tiny Lightning app in the wild and are comfortable losing a few sats for the sake of experimentation. It is also for developers studying how payment-enabled apps can be prototyped quickly.
It is not for anyone who struggles with gambling, anyone who wants predictable financial value, anyone under local gambling age, or anyone unwilling to inspect wallet permissions. A game that costs 21 sats can still teach bad habits if the lesson becomes clicking every payment prompt without reading it.
The healthiest use is educational: open the app, understand the payment path, maybe try one tiny ticket, revoke permissions and move on. If the prize pool gets exciting, that is exactly when you should become more careful, not less.
The practical close
Blotto matters because it makes the NWC promise concrete in a deliberately small form. A wallet-connected app does not have to be a giant exchange, a social network or a serious enterprise tool. It can be a playful web page where a Lightning payment changes state and the user immediately understands that money has become programmable app input.
That is the charming side. The serious side is that programmable money still needs boundaries. Randomness, custody, claim proof, legal eligibility and wallet permission all matter before a user sends sats. Small amounts make those risks tolerable; they do not make the risks disappear.
If you use Blotto, use it as a tiny demo and a wallet-safety drill. Verify the live page, pay only what you are happy to lose, save any ticket proof, avoid broad NWC permissions and revoke the connection afterward. In that lane, Blotto is a useful little reminder that Nostr and Lightning are not only protocols on paper. They are also small strange apps that help people feel the rails.
Sources worth opening
Begin with the LNFly repository and README, then open the NWC ecosystem post that names Blotto, the awesome-nwc listing, the Stacker and Reddit context, Bitcoin Connect, WebLN, NWC docs, NIP-47, NIP-04, BOLT 11 and basic responsible-gambling references.
