Understanding Shielded Transactions on Midnight

Midnight is a programmable-privacy blockchain. Its core premise is simple but revolutionary: public verifiability without public visibility. In simple terms, anyone can verify the validity of a transaction (via zero-knowledge proofs), but the actual data, inputs, and identities can remain completely private.

If you’ve come from Ethereum, Solana, or even other ZK chains and found “shielded transactions” confusing, you’re not alone. I spent days wrestling with the mental model until it clicked.

Before continuing, make sure you're familiar with the following topics:

• UTXO Model (NIGHT transactions use the UTXO model)
• Merkle Trees

It is also worth keeping in mind that shielded tokens on Midnight use a private UTXO model (the focus of this article), while smart contracts use an account-style model for their persistent on-chain state, giving you the best of both worlds.

The Core Mental Model:

Every shielded interaction on Midnight rests on a clean split that the protocol enforces at the lowest level:

1. Public Ledger (what everyone can see)
   This is the visible part of the blockchain. It holds commitments, nullifiers, and the final public state changes. Think of it as the “receipt” that proves something happened correctly.

2. Private State (what stays on your device)
   Your actual secrets - balances, messages, keys, and history, never leave your wallet or computer. This is the shielded ledger. Only you (and the intended recipient) can read it.

3. Zero-Knowledge Proof (the cryptographic bridge)
   This is the magic. Alice’s wallet runs the contract logic locally, using her private data + Bob’s public info. It generates a tiny proof that says:

“I own this input, the math adds up, the rules were followed… but I’m not telling you the numbers or who I am”.

The proof + a few public pieces (nullifiers + new commitments) get submitted to the network. Nodes verify the proof in seconds. If it checks out, the public ledger updates. Done.

Bulletin Board Analogy:

This is one of the simplest analogies I found to understand the mental model of shielded transactions on Midnight. It's called the "Bulletin Board Analogy". It's pretty simple to follow along:

Imagine a giant town square with two public objects:

1. A Bulletin Board:
   Imagine a bulletin board that can grow constantly. People pin sealed envelopes to it. You can see every envelope and when it was added, but you can't see what's inside any of them. Once an envelope is pinned, it stays there forever and can never be taken down.

   This bulletin board is what we call the "Commitment Merkle Tree".

2. A Glass Jar:
   Imagine a glass jar that everyone can see into. People occasionally drop unique tokens into the jar (the role of this jar will make sense pretty soon).

   Let's call this jar the "Nullifier Set".

Mounted above the square is a camera that automatically takes a single snapshot of the bulletin board at the end of every hour. The last 100 snapshots are kept on display next to the board.

Each townsperson/resident has:

• A secret stamp known only to them (spending key)
• A secret monocle that lets them read certain envelopes (viewing key)
• A wallet of slips that say: envelope #893454 on the board contains 10 NIGHT and belongs to me. Here's the random salt I used to seal it.

Note: A 'salt' is a random value added to the commitment to add randomness. This prevents linking any two commitments to the same recipient.

To "spend" an envelope, you don't take it down (that would allow others to link it to you). Instead, you go to the Town Magician - someone who can produce a magical receipt that says:

I'm holding a sealed envelope that's pinned to the board; I'm cancelling it; here are the new envelopes I'm pinning to replace it; the math all balances.

The receipt mathematically proves all of this is true, but reveals nothing about which envelope or what was inside.

Once that's done, you hand the magician's receipt to the Town Clerk along with a unique cancellation token (to prevent double spending the old envelope) which can only be computed from your stamp. We call this a nullifier because it's used to nullify an envelope.

The Clerk checks the jar. If your token isn't already in there, then the receipt is valid, and they:

• Drop your cancellation token into the jar (nobody can spend from the envelope again).
• Pin your new envelopes to the board.

In the process, the bulletin board grows, the jar gets one more token, but no observer can tell whose envelope was cancelled, whose new envelopes were pinned, or what amount changed hands.

That's the entire system in one mental picture. Now, let's lift the curtain.

The Onchain State - What's Actually Stored

On Midnight’s public ledger, you’ll only ever see two main cryptographic structures (plus the ZK proof):

• The Commitment Merkle Tree (the Bulletin Board):
  An append-only Merkle tree that stores every shielded note/commitment ever created. Each leaf is a cryptographic commitment, i.e., a sealed envelope that hides the value, owner, and other private data. Because it’s a Merkle tree, wallets can efficiently prove that a particular note exists on the board without revealing which one it is.

• The Nullifier Set (the Glass Jar):
  A growing set of unique nullifiers. When you spend a note, its nullifier is added here. This prevents double-spending forever. Once a nullifier is in the set, that note is permanently spent.

That’s it. There are no visible addresses, visible amounts, or visible links between transactions. The entire history of who sent what to whom is hidden in the private state on users’ devices.

How a Shielded Transaction Actually Works

Now that you understand the pieces, let's walk through a full transaction. Say Alice wants to send shielded tokens to Bob.

Step 1: Alice finds her note
Alice's wallet scans its private state and finds a note she owns (commitment on the bulletin board). Her private state tells her -

Commitment #893479 contains tokens belonging to you. Here's the salt (blinding factor), value, and Merkle path proving it's on the board.

Step 2: Alice creates new outputs
Alice needs Bob's public address to create a new note for him. Using it, she generates:

• A commitment for Bob: sealed envelope containing amount for Bob, Bob's public address, and a fresh salt.
• A commitment for herself as change: sealed envelope containing change amount, her address, and a different salt.

Step 3: Alice generates the ZK proof (locally)
Alice's wallet runs the circuit logic entirely on her device. It:

1. Takes her private data (value, salt, Merkle proof)
2. Takes Bob's public address
3. Computes the nullifier for the old note from her secret key
4. Produces a proof asserting all of the following simultaneously:

A note belonging to Alice exists in the Merkle tree

She is nullifying exactly that note

The new commitments sum to the same value as the old one

She hasn’t revealed the note index, the value, or her identity

Step 4: Alice submits to the network
Alice sends the proof + the nullifier + the new commitments. The node:

• Verifies the ZK proof (yes/no)
• Checks the nullifier isn't in the Nullifier Set

If both pass: nullifier goes in the jar, new commitments go on the board. The transaction is now complete.

The node never saw Alice’s identity, the amount, or who she sent to. It only verified the proof and checked the nullifier.

Step 5: Bob discovers his note

Now you might be wondering - "How does Bob even know he received anything?"

Before we understand how this works, it's important to understand the different keys generated by a seed phrase:

• Spend Key: This is a secret key. It never leaves your device and is used to generate nullifiers and authorize spending your notes
• Viewing Keys: This is what decrypts incoming notes during trial decryption, and lets you see your balances and transaction history. This key is what enables selective disclosure - you can prove you paid your taxes by sharing your viewing key with a regulator, without giving them your spending key.
• Address: This is your public-facing address. Anyone who has it can create sealed commitments addressed to you. You post this publicly so people can pay you.

Now with that out of the way, let's proceed:

Bob’s wallet continuously scans every new commitment on the bulletin board. Using his viewing key, it tries to decrypt each one. If a commitment successfully decrypts and identifies Bob as the recipient, his wallet adds it to his private state. This is called trial decryption.

It's worth noting that Alice doesn’t notify Bob. Bob’s wallet discovers the payment on its own, by watching the public board through his secret monocle. There’s no on-chain event that says “Bob got paid”, just a new sealed envelope that only Bob can read.

What the Proof Actually Guarantees (and Doesn’t)

There’s a subtle point worth understanding: the ZK proof guarantees that given the inputs provided, the circuit rules were followed. It does not guarantee that the off-chain code supplying private data, called the witness, behaved honestly.

The witness can’t lie about the spent note’s value. The circuit recomputes the commitment and checks it against the Merkle tree. If there is a mismatch, the proof fails.

The witness can lie about the output amounts. Bob’s commitment hasn’t been created yet, so there’s nothing to check against. As long as the outputs sum to the input, the proof passes.

This means if Alice’s wallet puts 1 token in Bob’s commitment instead of 10, the network accepts it. Bob decrypts the note, sees the actual value, and discovers he was short-changed, but only if he had a prior agreement with Alice about what to expect. The chain can’t help him since the proof was valid and the math was balanced.

The takeaway: the proof covers the circuit, not the witness.

Why This Matters

1. Senders stay private. An observer sees nothing more than: “an envelope was cancelled, two new ones appeared.”
2. Recipients stay private. No on-chain event says “Bob got paid.” Bob discovers his notes through trial decryption.
3. Amounts stay private. The board shows sealed envelopes, not balances.
4. Double-spending is impossible. The Nullifier Set is public, immutable, and checked by every node.
5. Everything is still verifiable. You verify the proof + check the nullifier. You don’t need to see the data.
6. Disclosure is selective. Share your viewing key with an auditor to prove compliance. Your spending key stays with you.

Midnight calls this “programmable privacy” because developers decide what’s public and what’s private, field by field. The compiler enforces the boundaries.




And that's the article. Hope it made shielded transactions a little less mysterious and helped Midnight’s shielded model click.