Hi — reporting a Mainnet blocker that has kept us stuck for several weeks.
Symptom: Wallet sync on Mainnet fails with a GraphQL error from the indexer: invalid address: cannot bech32m-decode unshielded address: expected HRP mn_addr_preprod, but was mn_addr
Root cause (our audit): The error originates from the Mainnet indexer GraphQL response (errors[0].message), not from the SDK itself. The indexer appears to be validating unshielded addresses against a hardcoded preprod HRP (mn_addr_preprod) instead of the mainnet HRP (mn_addr).
Result: DUST is not generating on Mainnet. We are currently blocked from production deployment.
GitHub issue: https://github.com/midnightntwrk/servicedesk/issues/15
Has anyone else hit this? Any known workaround or ETA for a fix?
1 Like
Update — May 16, 2026
@nstanford @LP_Midnight @stev
This is a follow-up to my original report posted May 8. It has now been 8 days with zero response, while the issue remains unresolved on Mainnet.
Since my original post, I have gathered additional evidence:
Confirmed scope: This is not an isolated issue. Multiple users in the Midnight Discord (including @MrPags [MDNT]) have confirmed they cannot generate DUST on Mainnet. Direct quote from May 12: “its a shame because here we sit in mainnet & no dust generation”
Root cause identified: The Midnight Mainnet Indexer is hardcoded with mn_addr_preprod instead of mn_addr, causing an HRP mismatch on unshielded address validation. This is an infrastructure-level bug, not a wallet issue.
LACE additional issue: getProvingProvider() is not implemented in LACE v2.0.4, meaning ZK proving — which DUST generation requires — cannot function through LACE on Mainnet regardless of the Indexer fix.
My position: I am the founder of SSATT.AI, building production infrastructure on Midnight ZK stack. I have 100+ successful on-chain transactions on Preprod. My entire product line is currently blocked by this Mainnet infrastructure failure.
Direct questions requiring answers:
-
Is there an acknowledged bug report for the Mainnet Indexer HRP mismatch?
-
What is the expected fix timeline?
-
Is there any interim workaround for cNIGHT holders on Mainnet?
Hi @1491sc sorry for the slow follow-up
Status: This is acknowledged and escalated on our side. The Mainnet indexer HRP mismatch you described (mn_addr_preprod vs mn_addr on unshielded address validation) matches what the infra team is investigating. Your GitHub report is the right place to track it: DUST not generating after successful Nethermind mapping - registered: false on Midnight Indexer · Issue #15 · midnightntwrk/servicedesk · GitHub
Your questions:
- Acknowledged bug? Yes. It’s tracked internally and linked to the servicedesk issue above.
- Fix timeline? the team is actively working on it. No confirmed ETA. We’ll post an update when it has been fixed.
- Interim workaround for cNIGHT holders on Mainnet? Unfortunately there isn’t a reliable client-side workaround while the indexer rejects valid Mainnet
mn_addr addresses. Retrying sync or re-registering won’t bypass server-side HRP validation. Preprod remains usable for development; Mainnet DUST generation depends on this infra fix landing.
Sorry again for the blocker and the wait.
1 Like
Thanks for the response and the servicedesk link.
Acknowledging the three answers:
- Bug confirmed in scope — tracking #15 from here.
- No ETA — understood.
- “No client-side workaround” — useful confirmation. Retry / re-register paths are off the table, one less rabbit hole for downstream builders.
Position from my May 8 / 16 posts stands: SSATT.AI’s Mainnet-dependent paths remain gated on this fix. I’m scoping contingency work in parallel rather than waiting passively.
No further ping from my side until there’s movement on #15.