Shielded kernel operations (receiveShielded, mintShieldedToken) fail with proof server 400

Technical Questions
,
1

Problem

All shielded kernel operations (receiveShielded, mintShieldedToken, sendShielded) fail with HTTP 400 from the proof server. Unshielded operations work fine on the same setup.

Minimal Reproduce

Contract with only 1 circuit — exact pattern from Compact standard library docs:

pragma language_version >= 0.20;
import CompactStandardLibrary;

witness localSecret(): Bytes<32>;
constructor() { const secret = localSecret(); }

export circuit receiveShieldedTokens(coin: ShieldedCoinInfo): [] {
  receiveShielded(disclose(coin));
}

Compiles successfully. Deploy succeeds. Calling receiveShieldedTokens → proof server returns 400:

POST http://localhost:6300/prove → 400 Bad Request

Environment

┌───────────────────┬──────────────────────────────────┐
│ Component │ Version │
├───────────────────┼──────────────────────────────────┤
│ Compact Toolchain │ 0.5.1 (compactc 0.30.0) │
├───────────────────┼──────────────────────────────────┤
│ Proof Server │ midnightntwrk/proof-server:8.0.3 │
├───────────────────┼──────────────────────────────────┤
│ Ledger │ 8.0.3 │
├───────────────────┼──────────────────────────────────┤
│ Midnight.js SDK │ 4.0.2 │
├───────────────────┼──────────────────────────────────┤
│ Compact Runtime │ 0.15.0 │
├───────────────────┼──────────────────────────────────┤
│ Network │ preprod │
├───────────────────┼──────────────────────────────────┤
│ OS │ macOS Apple Silicon (Docker VMM) │
└───────────────────┴──────────────────────────────────┘

What I tested

  • Minimal contract (1 circuit, zero ledger state) → 400
  • Full contract (9 circuits) → 400
  • Added witness to force larger proving key → 400
  • Compact Toolchain 0.5.0 and 0.5.1 → both 400
  • 3 different proof server images (official 8.0.3, meshsdk 1.0.0, pre-baked full params) → all 400

Unshielded equivalents (receiveUnshielded, mintUnshieldedToken, sendUnshielded) all work fine.

Full reproduce repo

Branch with minimal test contract + test web page + detailed bug report:

Steps: see BUG_REPORT_SHIELDED.md in the repo.

Question
Is this a known limitation of proof server 8.0.3? Are shielded kernel operations expected to work on preprod currently?

2

That contract receives the coin, but does not do anything with it. You would have to either send immediately further or save it in the contract.

3

Hi all,

Wanted to add another data point to this thread from a different angle. We’re seeing what appears to be the same underlying issue on preprod, but
manifesting at a different stage in the pipeline.

What we’re building: YAMORI (家守) is an independent Midnight wallet built in Japan. We have unshielded transfers working reliably on preprod with
multiple confirmed on-chain transactions.

The problem: Shield transactions (initSwap / cross-pool) fail with error 199 (InvariantViolation). Specifically:

  • The WASM prove step succeeds — the ZK proof generates correctly on our end
  • The transaction is constructed and balanced without errors
  • Submission to the node is rejected with: 1010: Invalid Transaction: Custom error: 199

Our stack:

  • @midnight-ntwrk/wallet-sdk-facade 3.0.0
  • @midnight-ntwrk/ledger-v8 8.0.3
  • @midnight-ntwrk/compact-runtime 0.15.0

This lines up with what @BoHsuu reported on April 7 — shielded operations failing against the proof server with 400. In our case the proof itself
generates fine locally, but the node still rejects the resulting transaction. Different failure point, same outcome: no shielded operations work on
preprod.

We’ve ruled out our own transaction construction by confirming that the identical code path succeeds for unshielded transfers. The error 199
(InvariantViolation) suggests something on the network/validator side is rejecting otherwise valid shielded proofs.

Questions for the team:

  1. Is this a known preprod issue? Is there a tracker we can follow?
  2. Any ETA on a fix, or a recommended workaround?
  3. Are there specific SDK version combinations that are confirmed working for shielded ops right now?

Happy to provide transaction hashes, logs, or any other diagnostic info that would help.

Thanks,
YAMORI team