Cycle 1 is officially in the books. 62 Mini Apps submitted, all of them scored by the Nimiq Community Council, and the results are final. 🥁 Drumroll please… 🥇 1st place: Nimiq Space by @Harley NSpace An open multiplayer world where wallet-signed players can see who is online right now, paint a persistent 500x500 collaborative floor, and build rooms that sync live for everyone in them. 🥈 2nd place: NimJump by @Emre Alt An arcade game built around a minimal client-authority architecture, where the server replays every run itself instead of trusting the score the client reports. 🥉 3rd place: NimQuest by @mystiquemide A learn-and-prove Mini App with server-graded quizzes, where a completion only counts once you sign a one-time message in Nimiq Pay. Congratulations to all three. Winners will be contacted directly to arrange payout. To everyone else who submitted, thank you. You shipped something real in four weeks and set the bar high for future cycles. Every app you built is yours under the MIT License, so keep going with it. 🗓️ Cycle 2 opens August 24. Same $17,000 USDT prize pool, four Sip & Ship calls, submissions close September 18 at 23:59 UTC. If your app did not place this time, you can refine it and submit it again. Full breakdown on all three winners: https://www.nimiq.com/blog/mini-apps-competition-cycle-1-winner-announcement

I'm trying to figure out how to get my Nimiq Pay to connect to testnet. Is there a hidden setting somewhere?

Hey builders! 👋 Just submitted Nimble — and if you're from Poland you'll recognize the idea instantly: it's BLIK-style payments on Nimiq. Here's the 10-second pitch: QR codes can be swapped with a sticker, links can be phished, addresses are unreadable hashes you trust blindly. A one-time 6-digit code has none of those problems — it's not a credential, it moves no money by itself, and you can say it out loud across a market stall. In Poland this UX beat cards for P2P. I wanted that "just tell me the code" moment for crypto. How it works (takes ~15 seconds with two phones): 1. Payer taps Pay → gets a code inside a countdown ring 2. Receiver types the amount + the code 3. Payer sees exactly who gets paid and how much → one tap in the wallet 4. Both screens go green "Paid" seconds after inclusion; Albatross finality and the receipt settle silently in the background Try it right now (testnet, no real money): - Nimiq Pay → long-press settings → switch to Testnet → grab faucet NIM - Mini Apps → Custom URL → https://nimble.gallareton.pl - Grab a second phone (or a friend here!) and pair with a code 🎥 Demo video: https://youtu.be/mwSJtvYDoeA 💻 Code (MIT): https://github.com/gallareton/nimble Under the hood: wallet-signature auth with silent session refresh, atomic code claiming with rate limits and uniform errors, real-time status over SSE, on-chain reconciliation if the app dies mid-payment (token hidden in the tx data field), receipts with the USD value frozen at finality, 6 languages picked up from Nimiq Pay's host language. I'd love feedback on: the two-phone pairing flow (any confusion?), the "Paid vs final" two-phase status, and what you'd want next — I have request-by-link, bill splitting and Cashlink-style cheques on the roadmap. Happy to test your apps back — drop your links 👇

Following up on the network request from this week — here's a second small gap, with a real bug story attached. What happened: I added a pre-flight check to Nimble so a payer sees "not enough NIM" on the approval screen instead of tapping through to the wallet only to be refused. My backend read the balance from the embedded Nimiq client… and every payment got blocked. Turns out the web client runs Pico sync: no accounts tree, so getAccount() returns balance: 0 for any address it doesn't own. A wallet holding 200k NIM reported zero — before and after subscribing the address. I ripped the feature out. Then I looked for the obvious source instead — the wallet itself. It's the connected wallet, it's the user's own account, and Nimiq Pay clearly knows the number (it's on the home screen). But window.nimiq exposes: listAccounts, sign, isConsensusEstablished, getBlockNumber, sendBasicTransaction(WithData) + staking. No balance anywhere, and nothing on window.nimiqPay either (language + device id only). The ask: nimiq.getBalance() (or balance on the accounts returned by listAccounts) for the connected accounts only — no privacy expansion, the user already granted access to that account. Why it's worth it: any Mini App handling payments wants to answer "can this user afford this?" before the wallet sheet opens. Right now the alternatives are all bad: run a full node just to read one balance, depend on a third-party RPC/explorer, or let people hit a refusal they could have been warned about. It's a UX papercut in every payment app on the platform, not just mine. Happy to test a beta build against Nimble, and to open an issue/PR if you point me at the right repo. If you've hit the same wall, a +1 below probably helps 🙂

Question for the Nimiq team / anyone who's dealt with this. The problem: Nimble (my submission) isn't a pure frontend — it has a backend that watches the chain: subscribes to transactions, tracks finality, issues receipts. That backend can only follow one network, and for the competition it follows testnet. But a regular Nimiq Pay user is on mainnet — and if they open the app and pay, the wallet happily broadcasts a real mainnet transaction that my testnet backend will never see. Payment status hangs, user is confused, real NIM moved. What I couldn't find: a way to ask the wallet which network it's on. window.nimiq exposes wallet methods (listAccounts, sign, sendBasicTransaction*, getBlockNumber, staking), and window.nimiqPay gives language + device identifier — but no network / networkId field anywhere I could see. What I did instead: after connect, I call the wallet's getBlockNumber() and compare it with my server's own chain height (exposed via my API). If they differ by more than 100k blocks, I show a warning banner telling the user to switch networks (long-press settings) and block the payment path. Testnet and mainnet Albatross heights are millions of blocks apart, so in practice this can't misfire — but it's obviously a heuristic, not a contract. My questions: 1. Is there an official way to read the host network that I missed? 2. If not — is height comparison a sane interim approach, or is there a failure mode I'm not seeing (e.g., wallet's getBlockNumber behavior before consensus, or during sync)? 3. Feature request, if the team is reading: a network field on window.nimiqPay (next to language) would solve this cleanly for every backend-driven Mini App. Happy to open an issue/PR wherever this lives. Curious how other builders with backends handled it — or did everyone just go frontend-only and inherit whatever network the wallet is on? 🙂