You just wrote your first Midnight dApp. The code compiles, the proof server is running, you call balanceUnboundTransaction — and nothing happens. Or worse, you get a cryptic error about missing UTXOs. The problem isn't your contract. The problem is that your wallet hasn't synced.
This tutorial explains what wallet sync actually means on Midnight, why skipping it breaks everything, and the exact patterns to ensure your transactions always work.
Midnight contracts produce zero-knowledge proofs — cryptographic attestations that a transaction is valid without revealing private data. These proofs are essential for Midnight's privacy model, but integrating proof generation into an existing Node.js backend introduces specific challenges:
Midnight's privacy model relies on DUST — a shielded network resource, not a token, that pays for transaction fees. Every transaction consumes DUST. But here's the catch: new users start with zero DUST, and generating it requires holding NIGHT tokens through a multi-day lifecycle.
This creates a cold-start problem. How does a brand-new user submit their first transaction if they don't have DUST to pay fees?
The answer is DUST sponsorship: one wallet (the sponsor) pays the DUST fees for another user's transaction. This tutorial shows you exactly how.
You deploy your first Midnight dApp. Everything works in testing — single transactions sail through. Then you go live, and something strange happens: users report that transactions randomly fail with an error like "stale UTXO" or "UTXO already consumed." Not every time. Just sometimes. And only when multiple actions happen close together.
This is the UTXO race condition, and it catches almost every developer building on UTXO-based chains. If you come from Ethereum or Solana, where accounts have balances you just increment and decrement, the failure mode feels alien. On Midnight, the same wallet trying to send two transactions at the same time can break — and understanding why requires understanding how UTXOs actually work.
This tutorial explains the root cause, walks through concrete failure scenarios, and gives you three battle-tested patterns to handle concurrent transactions on Midnig
This tutorial walks through writing automated tests for Midnight Compact smart contracts. You'll learn two testing approaches — fast simulator tests that validate circuit logic locally, and integration tests that exercise full on-chain interactions against a local devnet — and set up a CI pipeline to run them automatically.
The companion code uses a simple Voting contract, but the patterns apply to any Compact contract.
| // Complete React Component for Contract State Dashboard | |
| // Companion file for Frontend Contract State Tutorial (#310) | |
| // | |
| // This component demonstrates the full pattern: | |
| // 1. Configure providers on mount | |
| // 2. Query initial state | |
| // 3. Subscribe to real-time updates | |
| // 4. Call circuits (e.g., increment) | |
| // 5. Handle loading, error, and null states | |
| // 6. Clean up subscriptions on unmount |
Midnight Network Tutorial — Eclipse Bounty #315
Imagine a user needs to prove they're over 21 — without revealing their exact age, name, or address. On transparent blockchains, this is impossible: you either share everything or nothing. Midnight's ZK architecture makes selective disclosure practical.
This tutorial builds a compliance attestation system where an authority commits to user properties (age, residency, certifications) via Merkle tree commitments, and users can selectively prove specific properties without revealing others. Domain-separated hashing ensures different properties can't be correlated.
A practical guide to writing time-based smart contracts on Midnight Network
Most smart contracts need time. Auctions end at a deadline. Escrows expire if unclaimed. Games progress through rounds. On traditional chains, you read the current timestamp and compare. On Midnight, privacy changes everything — you can't simply read block.timestamp because that would leak information.