Custom error 170 on preprod public RPC with ledger-v8 8.0.3, but 8.1.0 deploys fine — version requirement or RPC-specific?

Hi — a question about contract deploy on preprod vs the ledger version requirement.

Setup: a contract built with @midnight-ntwrk/ledger-v8 8.0.3 (compact toolchain 0.30.0, language 0.22.0, midnight-js 4.0.4) deploys fine to mainnet via the foundation RPC and has been running there since May 31. But the exact same 8.0.3 stack, deploying to preprod via the public RPC (rpc.preprod.midnight.network), gets rejected at submit with “1010 Invalid Transaction: Custom error: 170”. Rebuilding the identical contract with ledger-v8 8.1.0 (everything else the same, via temp-log’s lockfile) deploys cleanly to preprod with no 170.

Both networks report the same state_getRuntimeVersion (specVersion 22000, transactionVersion 2).

Question: Is Custom error 170 a ledger-version requirement (i.e. spec 22000 expects ledger 8.1.0 and 8.0.3 tx are no longer valid), or is it specific to the public preprod RPC’s behavior? In other words — for a contract we want to deploy to mainnet, should we be on ledger 8.1.0, or is 8.0.3 still correct for mainnet?

Also: what exactly does Custom error 170 mean (which validation in the runtime)? Couldn’t find it documented.

Thanks!

@takuya Custom error 170 is InvalidDustSpendProof: the node rejected the DUST fee proof on the deploy tx, not the contract deploy proof. See error codes and decode 1010.

Matching specVersion on mainnet and preprod doesn’t mean ledger, proof-server, and wallet stacks are interchangeable. 8.0.3 failing on public preprod while 8.1.0 deploys clean points to a client/proof alignment issue on preprod, not “spec 22000 forbids 8.0.3.” Indexer lag and stale DUST state can also trigger 170 on preprod, but the 8.1.0 fix suggests pinning the whole fee stack (ledger + proof server + wallet/facade per the support matrix) matters more than which RPC hostname you use.

For mainnet vs preprod: pin versions per environment. If preprod needs 8.1.x + a matching proof server, use that for preprod testing even if mainnet still works on 8.0.3 via foundation RPC today.
Also if you are trying to deploy on mainnet you shiuld check this out also
Mainnnet Deployment Guide

Before retrying: proof server matches ledger line, wallet fully synced, fresh DUST, indexer caught up (preprod status).

you can also use this community led effort tool to debug errors like this(not official): midnight-cast using cli commands like mn decode 170, mn tip preprod, mn versions preprod

Update (June 10): This now looks like more than the 170 issue. Since ~June 9, my preprod wallet cold sync never reaches isSynced — it fails with “Failed to decode ledger event payload” on both shielded and dust paths. The raw event bytes start with “midnight:event[v9]:” and protocolVersion is 22000. My local stack: ledger-v8 8.1.0, wallet-sdk 3.0.0, midnight-js 4.1.1, proof-server 8.0.3.

So preprod seems to have moved to ledger event v9, but the compatibility matrix still lists preprod at ledger 8.0.3 (last updated Jun 5). Without a synced wallet I can’t deploy or submit any tx to preprod at all.

Could you confirm the exact set of versions (ledger / wallet-sdk / midnight-js / proof-server) that support preprod’s current event v9 / protocolVersion 22000? In particular, does proof-server also need to move off 8.0.3?

Thanks — I’ll also try mn versions preprod and mn tip preprod from midnight-cast as suggested.

Follow-up with my exact installed versions vs the Jun 8 deploy guide:

My temp-log project:

  • ledger-v8: 8.1.0
  • compact-runtime: 0.15.0
  • midnight-js-contracts: 4.0.4
  • wallet-sdk-facade/dust-wallet: 3.0.0
  • wallet-sdk-shielded: 3.0.0
  • wallet-sdk-unshielded-wallet: 3.0.0
  • wallet-sdk-hd: 3.0.2
  • wallet-sdk-address-format: 3.1.1
  • proof-server: 8.0.3

The Jun 8 deploy guide lists preprod as ledger-v8 8.0.3 / compact-runtime 0.16.0 / midnight-js 4.0.2 / wallet-sdk-shielded 2.1.0 / wallet-sdk-unshielded 2.1.0. So my stack is a mix that’s both newer (ledger 8.1.0, shielded/unshielded 3.0.0) and older (compact-runtime 0.15.0) than the guide.

Since preprod is now emitting event v9 / protocolVersion 22000 and my wallet can’t decode it, could you confirm the exact coherent version set (ledger / compact-runtime / midnight-js / all wallet-sdk-* / proof-server) that works against preprod’s current state? I want to pin one consistent set rather than guess.

@nasihudeenJ
@nasihudeenJ tagging you on this since you helped on the 170 issue — would really appreciate your input. Since ~June 9 preprod emits event v9 / protocolVersion 22000 and my wallet can no longer decode/sync (details in my post above). Could you confirm the exact known-good version set for preprod’s current state? Thanks!

@takuya thanks for the update. This looks like a second issue on top of the original 170 submit failure: now cold sync never reaches isSynced because the wallet can’t decode indexer ledger events (Failed to decode ledger event payload, prefix midnight:event[v9]:, protocolVersion 22000).

midnight:event[v9] not “ledger npm v9”

Important nuance (from engineering on a related preprod report): midnight:event[v9] is the serialized event protocol tag in indexer payloads, not the npm package @midnight-ntwrk/ledger-v8@9.x. Preprod public infra has been on ledger 8.0.x while events can still carry that tag. So this isn’t “preprod moved to ledger v9” in the package sense.

Your stack looks misaligned

You listed:

  • ledger-v8@8.1.0
  • wallet-sdk@3.0.0
  • midnight-js@4.1.1
  • proof-server@8.0.3

The public support matrix (last updated early June) still pins Preprod at ledger 8.0.3 + proof-server 8.0.3 + wallet-sdk facade 3.0.0 (with matching midnight-js line). Ledger 8.1.0 + proof-server 8.0.3 is a cross-line mismatch that can break sync/prove/submit in hard-to-debug ways.

What I’d advice you to try first :

  1. Pin entire fee stack to the Preprod row in the support matrix especially ledger 8.0.3 and proof-server 8.0.3 together (not 8.1.0 + 8.0.3).
  2. Clean install (node_modules, lockfile), fresh wallet cold sync on public preprod RPC + indexer.
  3. Before submit: preprod status RPC tip ≈ indexer tip.

Your earlier observation that 8.1.0 deploys clean on preprod while 8.0.3 hits 170 is useful it may mean some paths tolerate 8.1.0 client-side even when the matrix still documents 8.0.3. I can’t confirm an official “preprod now requires 8.1.0” from docs alone; if matrix-aligned 8.0.3 still fails sync and deploy, that’s worth a servicedesk report with your full version set + first failing event offset.

Relation to original 170

  • 170 = InvalidDustSpendProof (DUST fee leg) error codes
  • Sync decode failure blocks you before you can test submit at all we’ve seen similar preprod reports on dust/shielded sync with midnight:event[v9] (including hard failures on specific dust events). I’ve escalated that class internally; if you’re blocked on sync, include logs + whether a fresh wallet reproduces.

What I can’t confirm from here

I don’t have an official published answer for “exact versions for preprod event v9 / protocolVersion 22000” beyond the matrix especially whether proof-server must move off 8.0.3 when using ledger 8.1.0. I’ve raised version/matrix drift questions internally.

Also see our troubleshooting reference: Common dev issues #1246 (§170 / indexer lag / proof server).

@nasihudeenJ
This is incredibly helpful — thank you for the detailed breakdown.

The clarification that midnight:event[v9] is the serialized event protocol tag (not the ledger npm package) clears up a major misunderstanding on my side. And you’re right that my stack is misaligned: I’d ended up on ledger 8.1.0 + proof-server 8.0.3, which is exactly the cross-line mismatch you described.

I’ll follow your advice and pin the entire fee stack to the Preprod matrix row (ledger 8.0.3 + proof-server 8.0.3 + wallet-sdk facade 3.0.0 + matching midnight-js), then do a clean install and a fresh wallet cold sync against the public preprod RPC + indexer.

I’ll report back here whether the matrix-aligned 8.0.3 stack resolves the sync. If it still fails both sync and deploy, I’ll open a servicedesk report with the full version set and the first failing event offset as you suggested.

Thanks again for escalating the dust-event class internally — really appreciate it.

1 Like

@takuya I have opened a formal bug report for this issue you can track it here

To unblock the team, please share when you can:

  1. Preprod wallet seed (throwaway OK) or whether a brand-new wallet cold-syncs on your setup
  2. Full log / stack trace from the decode failure
  3. Wallet setup Lace vs headless SDK (if headless, how you instantiate shielded/dust)

Also worth trying matrix-aligned 8.0.3 for both ledger + proof-server on a fresh wallet and reporting back.

You’re the primary contact on this track now thanks for staying engaged.

i always ask my AI to please update all dependenices.