标签：#midnight

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