If you're considering building on Midnight, read this before you start.
I want to be upfront about what this article is and isn't.
It's not a tutorial. It's not a portfolio flex. It's what I actually experienced spending 45 days going full-time on Midnight - what broke me, what surprised me, what I built, and whether I'd do it again.
The short answer is yes. The longer answer is more interesting.
What "45 Days Full-Time" Actually Means
I was a final-year engineering student when I started. Full-time meant 2pm to 4-5am most nights, with weekend slots eaten by events and workshops. No structured hours, no team, no roadmap handed to me; just me, the docs, a lot of Discord messages, and a proof server running in Docker.
I studied DeFi math, ZK cryptography, and Midnight's architecture simultaneously. I built while I learned. Some contracts took a day. Some took a week of debugging a single circuit constraint. By the end of 45 days I had built roughly 15 contracts and ~10 full-stack dApps.
Here's what that actually looks like:
- Escrow contract with ZK commitment schemes and state machine ordering
- Linear bonding curve token with ZK-verified quadratic reserve math
- pUSD v3 lending protocol (180+ tests, hit Midnight's block size limits, had to cut from 28 to 10 circuits)
- Prediction market with range-based rewards (Bet in Range: submitted to hackathon)
- Quadratic voting with ZK-verified sqrt weighting
- ZK allowlist with depth-20 Sparse Merkle Tree and domain-separated nullifiers
- LMSR prediction markets, NFT launchpad, coin flip dApp, gamified learning platform
-
mn-scaffold: an npm CLI for scaffolding Midnight projects from a live template registry -
midnight-wallet-kit: React hooks for Lace and 1AM wallet integration, published to npm - Midnight Club: an open-source developer hub for the ecosystem
Two contributions came directly out of this period that I'm particularly glad exist. The first: when Midnight SDK v8 landed with significant breaking changes, a new WalletFacade.init pattern, mandatory encrypted private state, the signRecipe methodology replacing manual intent signing, I'd already worked through all of it while upgrading my own projects. That understanding turned into a PR to Midnight's official create-mn-app repository, upgrading the hello-world template to SDK v8. It's approved and pending merge. The second is already live: a documentation PR to the official midnight-docs repo clarifying the create-mn-app project selection flow, specifically documenting that the CLI prompts you to choose between a Contract or a Full dApp, and which templates are available for each. It's the kind of thing that seems obvious once you know it and completely opaque when you don't. Both came from the same place: hitting a wall, figuring it out, then making sure the next developer doesn't hit the same wall.
I also got selected into the Midnight Aliit, the ecosystem's selective technical fellowship program for builders who contribute through code, education, and community. The name comes from Mandalorian: aliit means "family" or "clan," which is an accurate description of what it actually feels like. Fellows are chosen based on prior contributions, demonstrated technical depth, and a track record of helping others build. It's not a badge; it comes with direct access to the teams building Midnight, the ability to feed product feedback directly upstream, and a responsibility to keep bringing new developers into the ecosystem. Getting in validated that the 45 days weren't just productive for me personally.
The Thing That Made Me Cry: Developer Experience
I'm going to say something that every Midnight developer is thinking but most won't write publicly: the DevEx is genuinely hard right now.
This isn't a complaint. It's a fact worth stating clearly for anyone evaluating whether to build here.
There's no publicly hosted proof server. Every developer who wants to build, test, or demo anything that involves ZK proofs has to run the proof server locally in Docker. This is fine for development. It becomes a serious problem the moment you want to deploy something real at zero cost, the way you'd deploy a Solana program or an EVM contract and have users interact with it immediately. On Midnight, your users need a running proof server, or you need to run one for them, which isn't free.
I built midnight-wallet-kit specifically because there was no proper documentation for Lace provider APIs. I spent hours inspecting window objects in the browser console to figure out what methods existed, what payloads they accepted, and how to make them work reliably across both wallets. There was no spec to read. I reverse-engineered it.
The Compact compiler's error messages, at least in the versions I was working with, could be cryptic. Circuit constraints that fail don't always tell you why clearly. You learn by developing an intuition for what the ZK constraint system will and won't accept, which takes time and pain.
I hit Midnight's block size limits while building pUSD v3. Had to reduce the contract from 28 circuits down to 10. The documentation on block size constraints didn't exist at the time; I found the limit by hitting it.
None of this made me want to stop. But it would make a lot of developers stop, and I've seen it happen.
The Thing That Surprised Me: The Team Actually Shows Up
I expected a new ecosystem with thin developer support. What I got was the opposite.
Every time I got seriously stuck, and I mean seriously stuck, the kind of stuck where you've been debugging for two days and you're considering starting over, someone from the Midnight team was in Discord helping me work through it. Not a bot. Not a "have you read the docs?" response. Actual engineers engaging with my specific problem.
I know "good developer support" sounds like a bare minimum. In practice, it's not. Most chains at Midnight's stage have a Discord that's 90% price talk and 10% confused newcomers. Midnight's developer channels are genuinely technical. The people building the chain are in the same channels as the people building on it.
This matters more than it sounds when you're working alone at 3am on a circuit constraint that won't compile.
The Thing I Didn't Expect: ZK Stopped Being Scary
I came into this with a genuine fear of zero-knowledge cryptography. I'd tried to implement ZK-adjacent things on other chains and made a mess every time.
Midnight changed that.
Not because Midnight made ZK easy, it didn't. But Compact forces you to engage with the actual concepts rather than letting you abstract over them. When the compiler rejects your program because you tried to move witness data to the public ledger without disclose(), you don't just fix the error and move on. You understand why it's an error. The language teaches you the mental model.
By week three I was writing blog posts explaining ZK commitment schemes and the witness-verify pattern to other developers. By week five I was implementing Sparse Merkle Trees and domain-separated nullifiers. That's not knowledge I would have picked up passively. Midnight forced it.
The DeFi math came the same way. Bonding curves required integrating a price function. LMSR prediction markets required understanding logarithmic scoring rules. pUSD required thinking about liquidation thresholds and collateral ratios under ZK constraints. I learned all of it because I had to implement it.
If you come to Midnight for the privacy primitives, you'll leave with a significantly deeper understanding of cryptography than when you arrived. That's a real return on investment that doesn't show up in any ecosystem metric.
What's Missing: The Proof Server Problem Isn't Fully Solved
Midnight does provide publicly hosted proof server endpoints for Preview, Preprod, and Mainnet. So technically, you don't have to run one locally.
But here's the thing the official docs say immediately after listing those endpoints: you should only use a proof server you control, because the proof server receives your private data; token ownership details, private state, witness inputs. Using a hosted proof server you don't control means trusting a third party with exactly the data Midnight's privacy model is designed to protect.
For development and testing: the hosted endpoints are convenient and fine. For a production dApp where privacy actually matters: you're back to running it yourself or self-hosting infrastructure. And for attracting users who aren't developers and won't run Docker, the UX friction is still real.
This isn't a criticism of Midnight's architecture. The local proof server is the right privacy model. But it creates a genuine tension: the chain's core value proposition is privacy, and the most privacy-respecting deployment requires infrastructure that most dApp users will never set up themselves. That tension doesn't have an easy answer, and I'd rather name it honestly than pretend the hosted endpoints make the problem disappear.
Should You Build on Midnight?
The honest version of my answer: it depends on your risk tolerance and your grinding capacity.
If you want a chain where you can build a polished dApp in a weekend and ship it to users immediately, Midnight is not that chain yet.
If you're willing to grind through rough DevEx for a period of time in exchange for being early to a genuinely novel privacy primitive layer, the kind of early where there's almost no competition for the problems you're solving, then Midnight is worth serious consideration.
The privacy problem in blockchain is real and unsolved. Midnight is one of the most technically interesting approaches to it. The team is building in public and engaging with developers. The ecosystem is small enough that good work gets noticed immediately, my escrow contract got into the official awesome-dapps list and onto the fireside dev hangout within 1 week of publishing.
I would not have gotten that visibility shipping my 50th Solana DEX fork.
If you're thinking about building on Midnight and want someone to walk you through the rough parts, I'm happy to help personally. I've hit most of the walls already.
What Comes Next
This retrospective is a checkpoint, not an ending. The repos stay open, the series stays up, midnight-wallet-kit is on npm, and there's more to build.
If you're starting your Midnight journey and want to skip some of the walls I hit, find me on X or GitHub. The repos are open, the series is up, and the walls are documented.
Midnight in Practice series · midnight-wallet-kit · mn-scaffold · Midnight Club
Top comments (3)
@tusharpamnani, thank you for writing this... genuinely.
Not because it's flattering (though parts of it are, and I'll be specific: the section about developers actually showing up in Discord matters to me personally, b/c responsive human support is, in my view, the single most important thing an early-stage ecosystem can get right. The Aliit mention too, we built that program to recognize builders who contribute rather than just consume, and seeing it land the way you described it lands is meaningful).
But you also named the real things. The proof server deployment tension, the block size limits you hit without documentation to catch you, the hours spent inspecting
windowobjects because the Lace provider API wasn't written down anywhere. These are tracked on our end, and posts like this make them harder to deprioritize.The midnight-wallet-kit you built is filling a gap that should have been filled sooner. Worth saying clearly, because the next developer landing on your npm package deserves to know it came from someone who did the hard work of figuring it out first.
What I can say is that your create-mn-app PR is landing this week. That one matters. SDK v8 has been a genuine onboarding cliff for new builders, and the fact that you upgraded it after working through your own migration, rather than just filing a complaint... is exactly the kind of contribution the Aliit is designed to recognize and amplify🔥
Keep writing. The ecosystem needs more of this.
Great job I enjoyed reading it.
This is a really thoughtful analysis! Thank you for sharing on DEV 🙏