Mainnet: DUST not generating — indexer returns HRP mismatch error on unshielded address

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:

  1. Is there an acknowledged bug report for the Mainnet Indexer HRP mismatch?

  2. What is the expected fix timeline?

  3. 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:

  1. Acknowledged bug? Yes. It’s tracked internally and linked to the servicedesk issue above.
  2. Fix timeline? the team is actively working on it. No confirmed ETA. We’ll post an update when it has been fixed.
  3. 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:

  1. Bug confirmed in scope — tracking #15 from here.
  2. No ETA — understood.
  3. “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.