Public alpha

NIMmesh

Scored against a competition it cannot enter

NIMmesh on the Mini Apps Competition rubric, scored three ways.

The rubric

The competition publishes its rubric: five categories, 100 points, six levels from 0 to 5, scored by Council members. A mini app is a web page inside Nimiq Pay and a web page cannot be a Bluetooth node, so NIMmesh cannot enter.

Claude Code produced the numbers and the reasons. The three columns and the decision to publish were mine. Nobody at Nimiq has scored this app. A row is worth 5 points unless it says otherwise.

Reading the score

HarshScored the way an unimpressed judge would, today. Every doubt resolved against the app.
FairThe most defensible reading of the evidence that exists today.
AfterAfter the funded three months: the mesh proven across Android and iPhone, swaps on mainnet, Bitchat on Android, Google Play.

Score by category

  • Harsh
  • Fair
  • After
0153045

Functionality, reliability and usefulness out of 45

27
35
39

Nimiq Pay and Nimiq integration out of 25

13
20
21

Real usage out of 15

0
0
10

Design and UX out of 10

4
6
7

Builder promotion checklist out of 5

0
0
0
955 points
not available
Harsh44
Fair61
After77

One category, the promotion checklist, scores a post about a submission. That puts 5 of the 100 points out of reach, and the ceiling is 95.

The scorecard

CriterionHarshFairAfter

Functionality, reliability and usefulness · 45 points

Core feature
Why“Main app promise completes without error and does what it says.”Four mainnet transfers have crossed the mesh, three of them phone to phone with no computer in the path. All four were iPhones. Android has no receipt yet.
345
Error handling
Why“Failures are caught and explained clearly instead of crashing or freezing.”A method that is not built yet rejects by name rather than returning a plausible lie. A send that cannot broadcast fails loudly instead of pretending.
344
Speed
Why“Loads fast and responds immediately to input.”Native Rust core, no WASM and no consensus client. There is one public Nimiq RPC endpoint and it was down for a day. Not our bug, still the user's wait.
344
Stability
Why“Full flow runs end to end without dead ends, blank screens, or broken states.”The paid path runs end to end on iPhone. A send with no neighbour sits at pending with nothing to tap, which is correct and still reads as a dead end. Android has never completed the flow.
234
Completeness
Why“Feels like a finished product, not a prototype with missing pieces.”Sideload only, Android mesh unproven, swaps testnet only, LoRa and SMS still documents. It is an alpha, and every page says so.
124
Real need
Why“Addresses an actual problem or want rather than a technical exercise.”If you have a phone but no data, you do not need your own connection. You need to stand near someone who has one.
455
Target audience
Why“Who this is built for is obvious within seconds.”The site says it in the first line. The app does not. Open it and you see a wallet with a grey status line, and nothing says the mesh is for people whose data is unreliable, censored or unaffordable.
344
Originality
Why“A new idea or a meaningful improvement on something that already exists.”Not one of the 68 apps in Cycle I did offline relay. Every Bitcoin mesh bridge has to chunk a transaction and put it back together. A Nimiq one is 139 bytes and does not.
555
Repeat value
Why“Gives a reason to come back rather than open once.”It is your wallet, so yes. The mesh only earns its keep when you are offline next to someone who is not, and that is not every day for most people.
344
Functionality, reliability and usefulness subtotal273539

Nimiq Pay and Nimiq integration · 25 points

Payments are core
Why“Wallet or payment function is central to the experience, not bolted on.”The product is a signed Nimiq transaction and nothing else. It is not Nimiq Pay, which is the name on the category, and the harsh column docks it a point for that.
455
Payment states
Why“Success, failure, and cancellation are all handled without leaving the user stuck.”Success comes back through the mesh as a receipt and the send flips from pending to settled. A failed broadcast is reported. There is no way to cancel a signed send that is waiting for a neighbour.
234
Trustworthy flow
Why“User always knows what they are paying, to whom, and what happens next.”Amount, address and a real funds warning on the send sheet, in the wallet's own layout. What happens next is the weak part. Meshed and pending are the whole explanation.
344
Mobile experience
Why“Behaves natively inside Nimiq Pay with no zooming, cut-off buttons, or desktop layouts.”It is native, so nothing zooms or clips. It does not run inside Nimiq Pay and never will. The harsh column reads the sentence as written and gives nothing.
033
NIM and ecosystem
Why“Uses NIM or the wider Nimiq ecosystem beyond simply accepting a payment.”Every byte on the mesh is a NIM transaction, the 139 byte size that makes it work is a Nimiq property, and the swap engine uses Nimiq's own hash time locked contracts.
455
Nimiq Pay and Nimiq integration subtotal132021

Real usage · 15 points

Unique users
Why“25 or more users, 15 points. 11 to 24, 10 points. 4 to 10, 6 points. 0 to 3, nothing.”Nobody has counted, and the first band starts at four. Until there is a count this is zero in every honest column. The Google Play closed test in month two requires twelve testers for fourteen days, which is the 10 point band by Google's rule.
0010
Real usage subtotal0010

Design and UX · 10 points

Visual quality
Why“Clean, consistent, and professional enough that a stranger would trust it.”Nimiq's palette and type, used consistently across five languages. Almost none of it is invented. The grey mesh status line is the one piece a stranger would not recognise.
344
Ease of use
Why“First-time user reaches the point of the app within 60 seconds without instructions.”Today: find the file, allow unknown sources, install, write down 24 words, then find a second phone. Nowhere near 60 seconds. Google Play deletes the first three steps.
123
Design and UX subtotal467

Builder promotion checklist · 5 points

Skool community post
Why“Builder posted the Mini App in the Skool community at least once. 2 points.”There is no Mini App to post. Zero in every column, and not a judgement about the app.
000
Social media post
Why“Builder shared at least one public social media post about their Mini App and the competition. 3 points.”Same. The post the checklist wants is about a submission, and there is none.
000
Builder promotion checklist subtotal000
Total out of 100446177

The ceiling is 95

Against 95 the three columns read 46%, 64% and 81%.

Two more rows lean the same way: real usage is a user count nobody has, and mobile experience says inside Nimiq Pay. The rest of the gap is the work in the funding request.

The rubric changed

This page first went up on 29 August 2026 against a 105 point, 21 criteria rubric. By 2 September the competition had replaced it with the 100 point version scored above.

RubricHarshFairAfterCeiling
105 points, 29 August59768695, unique users and submission quality
100 points, 2 September44617795, the promotion checklist

Real usage became a 15 point tier on user count, Nimiq Pay integration its own 25 points, design fell to 10. The demo video row is gone; a video is proof now, not points.

Sources

Criteria and levels: miniappscompetition.com/scoring, read 2 September 2026. Prize schedule: the payout page. The transfers behind the functionality rows are on the home page.

Help fund more development

Built for the Nimiq community.

Any help means a lot, and it goes straight back into building.

NIM