Understanding Midnight Network for EVM Developers

Introduction: A Different Kind of Blockchain

If you’ve been building on Ethereum or any EVM-compatible chain, you’re used to a world where everything is transparent. Every transaction, every balance, every contract interaction it’s all visible on the blockchain for everyone to see. That’s the design philosophy of EVM chains: transparency equals security.

Midnight Network flips this on its head. It’s a blockchain built with privacy as the default, not transparency. This isn’t just about hiding transaction amounts it’s a fundamentally different architecture that uses zero-knowledge proofs to let you prove things are correct without revealing what those things are.

This guide will walk you through the major mental shifts you need to make when coming from EVM development.

The Big Picture: What Makes Midnight Different?

1. Privacy-First Architecture

In EVM chains:
When you deploy a token contract, everyone can see every balance, every transfer, every approval. Tools like Etherscan show your complete transaction history. This transparency is a feature it’s how we audit contracts and verify behavior.

In Midnight:
You can have contracts where balances are private, transfers are private, but the contract logic is still verified and correct. The blockchain knows the rules are being followed (because of zero-knowledge proofs), but it doesn’t know the specific amounts or participants.

Why this matters:
This model targets applications that need verifiability plus confidentiality, such as privacy-sensitive financial, identity, and compliance flows.

2. Zero-Knowledge Proofs Instead of Transparent Execution

In EVM chains:
Your Solidity code compiles to bytecode. Every validator runs that bytecode and sees the exact same state changes. If you transfer 100 tokens, every node sees you had 200, now you have 100, and Bob has 100 more. Everyone re-executes everything to verify it.

In Midnight:
Your contract functions compile to circuits mathematical representations that can be proven with zero-knowledge proofs. When you transfer tokens, you generate a proof that says “I followed the rules” without revealing what those inputs and outputs were. Validators check the proof (which is fast) rather than re-executing everything (which is slow and exposes data).

Why this matters:
This is a completely different execution model. You’re not writing functions that run on a virtual machine you’re writing functions that get turned into mathematical circuits. The tooling, debugging, and mental model are all different.

3. Two Kinds of State: Public and Private

In EVM chains:
All contract state is public. If you store a mapping of balances, anyone can query any balance. Private variables in Solidity just mean “not automatically exposed via a getter” they’re still visible on-chain if you know where to look.

In Midnight:
Contracts have public ledger state on-chain, while private state remains local to each DApp/user context. Zero-knowledge proofs let you prove correctness involving private inputs without revealing those inputs.

Why this matters:
You need to explicitly decide what goes into public ledger state and what stays in local private state.

Token Models: EVM vs Midnight

EVM Token Model

In EVM chains, tokens are primarily smart contract-based. When you create a token, you deploy a contract (like ERC-20 or ERC-721) that maintains an account-based ledger of balances.

Every token is:

• Contract-managed: All logic lives in smart contract code
• Fully transparent: All balances and transfers are publicly visible
• Account-based: State is stored as mappings of addresses to balances
• Uniform approach: Everything follows the same transparent model

Midnight Token Model

Midnight offers two fundamental token categories, each with privacy options:

Ledger Tokens

Live directly on Midnight’s blockchain and are managed by the core protocol. These use a UTXO model:

• Shielded Ledger Tokens: Private, maximum efficiency
• Unshielded Ledger Tokens: Transparent, high performance

Contract Tokens

Created and managed by Compact smart contracts:

• Shielded Contract Tokens: Programmable privacy + custom logic
• Unshielded Contract Tokens: ERC-20 style, fully programmable

Why this matters:
In EVM, you’re limited to transparent contract tokens. In Midnight, you choose between:

• Ledger vs Contract
• Shielded vs Unshielded

This flexibility lets you optimize for your exact use case.

The Language: From Solidity to Compact

Solidity: What You Know

Solidity is inspired by JavaScript/Java. It includes:

• payable, view, pure
• msg.sender, block.timestamp
• Modifier chains

It compiles to EVM bytecode.

Compact: The New World

Compact looks like TypeScript — but behaves very differently.

Circuits Are Entry Points

Instead of:

function transfer(...)

You write:

circuit transfer(...)

These compile into zero-knowledge circuits.

Ledger State vs Witnesses

• Circuits: Update on-chain ledger state
• Witness functions: Handle private/local inputs

Stricter Types

Instead of just address, you have:

• ContractAddress
• ZswapCoinPublicKey
• Either<ZswapCoinPublicKey, ContractAddress>

Why this matters:
You can’t treat everything as a generic address anymore. Types matter.

Wallets: From One Key Pair to Three Components

EVM Wallets

Simple:

• One private key
• One address
• Everything tied to it

Midnight Wallets

Three components:

1. Shielded Wallet

• Fully private
• Balances and transfers hidden

2. Unshielded Wallet

• Public and transparent
• Used when visibility is needed

3. Dust Wallet

• Handles gas (DUST)
• Separate from funds

Why this matters:
You’re not dealing with a single identity anymore — you’re managing multiple contexts.

Gas: DUST is Not Like ETH

In EVM

• Pay gas using ETH
• Automatic and simple

In Midnight

• DUST must be generated/setup first
• Managed in a separate wallet component

Why this matters:
You can’t just send a transaction you need DUST ready beforehand.

Deployment: Proof Servers and Providers

EVM Deployment

• Connect to RPC
• Deploy via transaction
• Done

Midnight Deployment

Requires:

1. Proof Server (Docker)
2. Multiple Providers:

• Private State Provider
• Public Data Provider
• ZK Config Provider
• Proof Provider

1. Wallet Initialization
2. DUST Registration
3. Contract Deployment

Why this matters:
Deployment is heavier — but enables privacy.

Transactions: Sign vs Prove

EVM

1. Create transaction
2. Sign
3. Broadcast
4. Validators execute

Midnight

1. Create transaction
2. Generate proof locally
3. Sign proof
4. Broadcast
5. Validators verify proof

Key difference:
Proof generation happens before broadcast and can take 30–60 seconds.

Get Cadalt’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Why this matters:
Transactions feel slower because privacy has a computational cost.

Contract Design: New Mental Models

State Management

• Solidity: Direct mutation
• Midnight: Circuits + Witness separation

Address Handling

• Solidity: One address
• Midnight: Multiple address types

Privacy Boundaries

You decide:

• What is public
• What is private
• What is provable

Why this matters:
Privacy is not automatic it’s a design choice.

Final Takeaway

Midnight is not just “Ethereum with privacy.”

It forces you to rethink:

• Execution
• State
• Identity
• Transactions
• Architecture

You’re moving from:

“Run code and show everything”

to

“Prove correctness and reveal nothing unnecessary.”