Harrie ✨@IamHarrie
I've been spending the last couple of weeks writing tutorials for the Midnight Eclipse Content Program.
@MidnightNtwrk is a privacy focused blockchain that lets you write zero knowledge smart contracts in a language called Compact. The bounty program pays developers to write documentation for it, including tutorials, guides, and security breakdowns.
This post is a summary of four submissions that have gone through the review process. Most of them had feedback applied and are. I'm writing this partly to document what I built, and partly because the individual articles are dense and technical. This is the friendlier version of what each one is actually about.
If you're building on Midnight or just curious about ZK development, hopefully at least one of these is useful to you.
.
1. Why ownPublicKey() can't be trusted for access control
When you write a smart contract on most blockchains, the standard way to protect an admin function is to check who's calling it, something like "only the owner can call this." On Ethereum, you check msg.sender. On Midnight, the function that looks equivalent is ownPublicKey().
But ownPublicKey() doesn't work the way you'd expect in a zero knowledge context.
Here's why. In a ZK proof, the prover is the one who generates the proof on their own machine before submitting it to the chain. The prover chooses what values to supply as private inputs. ownPublicKey() compiles down to an unconstrained private_input in the ZK circuit, meaning the prover can put anything there. They can read the owner's public key from the on chain ledger, which is public state, plug it into their local proof as the value for ownPublicKey(), generate a valid proof, and submit it. The chain accepts the proof because the math checks out. There's no on chain identity verification happening.
This affects every contract that gates a privileged function behind an ownPublicKey() check. It also affects OpenZeppelin's Ownable.compact, which uses the same pattern.
The correct approach is to store a commitment on chain rather than a public key. The admin knows a secret. When they deploy the contract, they store persistentHash(["admin:v1", secret]) on the ledger. When they want to call an admin function, they supply the secret as a private witness and the circuit checks that it hashes to the stored commitment. Nobody can fake this without knowing the secret because the secret itself never goes on chain.
I built a proof of concept exploit for this against Midnight's own example bulletin board contract and wrote a full breakdown, covering the four steps of the attack, the correct commitment based pattern, and a note on how to migrate existing contracts.
The reviewer asked me to add a "valid uses of ownPublicKey()" section, since there are patterns where it's fine to use, and to pin the compiler version. Both done.
Read the full article: dev.to/iamharrie/comp…
.
2. Why your Midnight deploy fails before it even starts
I was calling balanceUnboundTransaction, the SDK function that figures out the fees and token movements for a transaction, and it was returning wrong results, and incorrect balances. The transaction would then fail downstream.
The root cause was that the wallet hadn't finished syncing yet.
The Midnight wallet is not just one wallet. It's three. There's a shielded wallet for private tokens using ZK proofs, an unshielded wallet for public token balances, and a DUST wallet specifically for paying network fees. Each one syncs independently from the chain, and each one has a different shape for its sync state in the SDK.
The state object for the shielded wallet is at state.shielded.state.progress. For the unshielded wallet, it's at state.unshielded.progress. For the DUST wallet, it's at state.dust.state.progress. They all nest differently. If you call .isStrictlyComplete() on the wrong path, you get undefined back instead of false or true. Your sync check passes and you proceed with an incomplete wallet.
There's also a known issue with the DUST wallet specifically. On idle chains, like a local devnet with no recent activity, isStrictlyComplete() hangs and never resolves. The workaround is to wrap the sync check in a timeout and catch the timeout as a best effort completion.
The safe pattern is RxJS based: wallet.state().pipe(filter(s => s.isSynced), take(1), timeout(60_000)). I spent time pulling the actual syncWallet function out of Midnight's CLI tutorial code and walking through what each RxJS operator is doing because the "why throttleTime?" and "why each: instead of a total timeout?" questions kept coming up when I was reading it.
The reviewer asked me to remove some duplicated text, which was a paste error on my end, soften a claim I'd made about the DUST bug being "documented" when it was actually just something I observed on a local devnet, and run through the style guide. All done.
Read the full article: dev.to/iamharrie/unde…
.
3. Working with Maps and Merkle Trees in Compact
Compact has two main data structures for managing on chain state: Map and MerkleTree. They serve different purposes and the choice between them matters. Using the wrong one produces contracts that are either wasteful or broken.
Maps are the simpler one. A Map is a key value store that lives on chain. You use .insert(key, value) to write, .lookup(key) to read, and .member(key) to check if a key exists before reading it. Reading a missing key panics, so the check matters. Maps are good for things like token balances, allow lists you want to update easily, or any state where you need to look up a specific entry directly.
MerkleTrees are for proving things privately. A MerkleTree stores up to 2^n leaves and lets you generate a path from any leaf to the root. A user can then prove "I have a leaf in this tree" by submitting a ZK proof of the path without revealing which leaf they have or where it sits. This is the pattern behind anonymous allowlists, private voting, and confidential membership systems.
The catch with MerkleTree is that it only validates the current root. If you're running a live registry where new members get added regularly, every insertion changes the root and every existing member's Merkle path becomes stale.
To fix this, Compact has HistoricMerkleTree, which keeps every root the tree has ever held. Membership proofs also stay valid regardless of subsequent insertions. This distinction trips people up sometimes.
The tutorial builds a hybrid contract that uses both, a Map for publicly queryable state and a HistoricMerkleTree for private membership proofs. It also runs both contracts through the Compact compiler and walks through the full API for each structure.
Read the full article: dev.to/iamharrie/work…
.
4. Compact Standard Library as a verified reference to every export
The Compact Standard Library ships with every contract. It's the set of built in types, functions, and circuits that Midnight makes available without any extra imports. Things like Maybe, Counter, persistentHash, elliptic curve operations, shielded token functions, and block time queries.
The official docs cover the basics but don't have working compiled examples for every export. This article was written to help with that showing every export in the library with a standalone compiled contract demonstrating it.
I started with seven .compact files covering the main categories. The reviewer came back with four corrections.
Block time queries. I'd documented getBlockTime, getBlockNumber, and getEpoch as the API, but those names don't exist in the library. The real functions are blockTimeLt, blockTimeLte, blockTimeGt, and blockTimeGte, comparisons rather than reads. You can't fetch the current block time as a plain value. You can only compare against a threshold. I rewrote that section entirely with working examples.
JubjubPoint and elliptic curve operations. I'd noted that JubjubPoint is an opaque type, meaning you can't inspect its fields, and steered readers toward persistentHash instead. The reviewer pointed out that ecAdd, ecMul, and ecMulGenerator all compile and work fine. You can do real elliptic curve arithmetic on JubjubPoint. You just can't read the coordinates directly. I added working examples for all three operations.
Counter.decrement. I'd said Counter only supports increment. Decrement compiles fine. Fixed, with a note that the value saturates at zero rather than wrapping.
MerkleTree in ledger. I'd described a workaround using persistentCommit because I thought MerkleTree couldn't be stored in a ledger field. I tested against the current compiler, v0.31.0, and it works. I dropped the workaround and replaced it with a clean example.
After fixing all four, the repo grew from seven contracts to eleven. I also wired up GitHub Actions so every .compact file compiles on push. Then I ran through the full style guide pass with sentence case headings throughout, British spelling, and an updated quick reference table reflecting all the corrections.
Read the full article: dev.to/iamharrie/comp…
_________________________
A few things I noticed across all of this
Writing for Midnight is different from writing about most blockchains because the ZK layer introduces a whole class of bugs that don't show up in normal smart contract development. The ownPublicKey() vulnerability is a good example. On any non ZK chain, checking the caller's identity is trivial and safe. On a ZK chain, the caller constructs their own proof, so checking the caller's identity requires a completely different mechanism.
Another Is, if you're building on Midnight, the main habit I'd suggest developing early is compiling everything and testing assumptions at the API level, not just reading the docs. Several things I thought worked didn't, and a few things I thought didn't work did.
It was altogether fun though.
#MidnightforDevs
