标签：#midnight

If you installed the Midnight wallet SDK a while back and pinned the package names, your imports are now pointing at a deprecated scope. Nothing is broken yet. But the packages you depend on moved, and the old names are living on borrowed time. Here is what changed, why it matters, and the one gotcha that trips people up. The short version The wallet SDK packages moved from the @midnight-ntwrk scope (with a dash) to @midnightntwrk (no dash). @midnight-ntwrk/wallet-sdk-facade -> @midnightntwrk/wallet-sdk-facade The old dashed packages still install, so your build keeps working for now. They are published as a transitional alias. But the dashed scope is deprecated, and the newest releases only show up on the new no-dash scope. So you want to move over. There is one exception. @midnight-ntwrk/ledger-v8 stays on the dashed scope. Do not rename that one. More on that below. What actually changed Straight from the wallet SDK v1.2.0 release notes: the npm scope has changed from @midnight-ntwrk to @midnightntwrk (no dash). New installs should depend on @midnightntwrk/* . The old @midnight-ntwrk/* packages continue to be published as a transitional alias during the migration window, so existing consumers keep working, but the dashed scope is deprecated. So both scopes exist on npm right now. That is why nothing breaks. But they are not equal. The no-dash scope is where the active releases land, and the dashed scope lags behind. You can see it yourself. Here are the current latest versions, dashed vs no-dash: Package Dashed (old) No-dash (new) wallet-sdk-facade 4.0.1 4.1.0 wallet-sdk-hd 3.0.2 3.0.3 wallet-sdk-shielded 3.0.1 3.0.2 wallet-sdk-dust-wallet 4.1.0 4.2.0 If you stay on the dashed names, you quietly get the older packages. The version fixes and new features go to the no-dash scope first. The gotcha: ledger-v8 does not move This is the part that catches people. When you do a find and replace across your project, it is tempting to swap every @midnight-ntwrk for @midnig

Written from months of grinding on shielded liquidity DeFi protocols on Midnight. If you've been trying to build anything serious with shielded fungible tokens on Midnight lending protocols, liquidity pools, DEXes you've probably hit some walls that the documentation doesn't fully prepare you for. The Midnight programming model around shielded tokens is genuinely different from anything in the EVM world, and a lot of the intuitions you carry from Solidity or even other ZK environments will get you into trouble fast. This post is a breakdown of the most impactful errors and misconceptions I ran into while building shielded liquidity DeFi contracts using Midnight's Compact language. These are not theoretical every single one of these either broke a circuit or caused a proof server failure at some point. I'll walk through what the issue is, why it happens, and what the correct pattern looks like. Background: How Shielded Tokens Actually Work Under the Hood Before we get into the errors, let's get clear on the underlying mechanics because this context is what makes the errors make sense. Midnight uses a protocol called Zswap for shielded token operations. When a user sends tokens to your contract by calling receiveShielded , what actually happens is more involved than it looks on the surface. When your circuit calls receiveShielded(coin) , the Compact runtime records a shielded receive obligation in the transaction being constructed. At this point, the proof server kicks in to generate the ZK proof for your circuit. But here's the thing your circuit only describes what the contract side is doing. The transaction still needs to be balanced : the tokens being received by the contract have to come from somewhere. This is where the wallet gets involved through an internal mechanism that runs beneath your circuit. The wallet looks at the ShieldedCoinInfo you're receiving the coin's color (token type) and value and finds a matching UTXO in the user's private coin set. It then