Ledgers

If you're coming from Ethereum or other EVM chains, you'll encounter one of the most important differences in blockchain architecture. The choice between account and UTXO models is not just an implementation detail; it shapes how tokens are tracked and what kinds of applications you can build.

Midnight is a privacy-preserving blockchain built on the UTXO model because it enables strong privacy features, parallelism, and efficiency. Midnight also supports account-style tokens through smart contracts. This dual approach gives developers flexibility and starts with understanding these two models.

The fundamental difference

Blockchains track ownership. There are two primary approaches, and they represent different models of digital ownership:

Model	Core concept	State management	Examples
Account model	Persistent accounts with balances	Global state updated in place	Ethereum, Polygon, BSC
UTXO model	Individual coins (outputs) that are spent	State transitions via consumption/creation	Bitcoin, Cardano, Midnight

The account model is common in Ethereum-style systems. Think of it as a giant spreadsheet where each row is an address and the balance column is updated on each transaction. Each address has a persistent account with a balance. When you send tokens, the system subtracts from one balance and adds to another.

The UTXO model (Unspent Transaction Output) is used by Bitcoin and forms Midnight's foundation. Instead of tracking balances in a single table, the system tracks individual "coins" (UTXOs). Each UTXO has a specific value and owner. When you spend tokens, you consume existing UTXOs and create new ones, similar to paying with cash and receiving change. There is no single stored balance; your balance is the sum of the UTXOs you control.

Why this matters for token development

Different applications have different needs. Midnight supports both token approaches and gives you architectural flexibility:

Ledger tokens (UTXO-based) - These are native to Midnight's blockchain ledger itself. NIGHT tokens—Midnight's native utility token—are the prime example. NIGHT tokens exist as individual UTXOs directly on the ledger and serve a special purpose: they generate DUST, the renewable resource that powers all transactions on Midnight. Each NIGHT token UTXO has a specific value and owner, and spending them follows the UTXO pattern of consuming inputs and creating outputs. This UTXO structure is crucial because it enables Midnight's privacy features—individual UTXOs can be shielded or unshielded as needed.

Contract tokens (Account-based) - These live inside smart contracts written in Compact (Midnight's smart contract language) and work just like ERC-20 tokens you know from Ethereum. The contract maintains a mapping of addresses to balances, and transfers simply update these balance numbers. These tokens follow OpenZeppelin-style standards adapted for Compact, so if you're comfortable with Solidity token development, contract tokens will feel immediately familiar. Contract tokens can also support both shielded and unshielded operations, giving you privacy options even within the account model.

This approach lets you choose the right model for each use case instead of forcing one model everywhere.

Concrete comparison

The following example shows how a simple token transfer differs between the two models.

Account model (Ethereum-style)

When you send 40 ETH from Alice to Bob:

// Conceptually, the ledger does this:
// Before: Alice = 100 ETH, Bob = 50 ETH
accounts[Alice].balance -= 40;
accounts[Bob].balance += 40;
// After: Alice = 60 ETH, Bob = 90 ETH

// The state is modified in-place
// Both accounts must exist in the global state

The ledger maintains a global database of all account balances, updating them in place. Every account that has ever received tokens must be tracked forever.

UTXO model (Midnight-style)

When Alice sends 40 NIGHT tokens to Bob:

// Alice has a 100 NIGHT UTXO
// Transaction consumes it entirely and creates new ones:
transaction = {
    inputs: [
        { value: 100, owner: Alice, id: "utxo_123" }  // Consumed entirely
    ],
    outputs: [
        { value: 40, owner: Bob },      // Payment to Bob (new UTXO)
        { value: 60, owner: Alice }     // Change back to Alice (new UTXO)
    ]
}

// Old UTXO is marked as spent, new UTXOs are created
// No balances are updated - only coin ownership changes

No balances are updated in place. Instead, Alice's 100 NIGHT UTXO is marked as spent and two new UTXOs are created. This is like paying with a $100 bill for a $40 item and receiving $60 in change.

The architectural impact

This difference in value tracking has major implications for scalability, privacy, and application design.

Parallelism and performance

The UTXO model naturally enables parallel transaction processing. Since each UTXO is independent, transactions using different UTXOs can be processed simultaneously. For example, if Alice has 10 different UTXOs, she can send them to 10 different recipients in parallel transactions.

In contrast, account-based systems must process transactions that touch the same account sequentially. Each transaction modifies the same balance, which creates a bottleneck.

Privacy through architecture

Midnight's privacy model is compliance-friendly. Unlike systems that enforce full anonymity, Midnight offers "rational privacy": users can choose shielded tokens when needed and still support compliance requirements through viewing keys (special keys that provide read-only access to shielded transactions).

The UTXO model makes this possible because each coin is independent. You can use shielded UTXOs without affecting others. You can reveal specific transactions for compliance while keeping others private. This granular control is difficult in account models where activity is tied to one persistent address.

This privacy capability extends to ledger tokens (UTXO-based) and, in evolving form, contract tokens (account-based), though implementation details differ. Ledger tokens can be shielded at the UTXO level, while contract tokens use Midnight's private smart contract state model.

State management and efficiency

Account systems must maintain an ever-growing global state. Every account that has ever existed must be tracked, even when it holds a zero balance. This leads to state growth that increases node operating cost over time.

The mental model shift

For developers coming from Ethereum, the biggest adjustment is thinking about value differently:

Your current thinking	UTXO thinking	Why it matters
"Check my account balance"	"Count my unspent coins"	No single privacy linkage point
"Update sender and receiver balances"	"Consume inputs, create outputs"	Enables atomic coin-level operations
"Transaction failed due to insufficient balance"	"Not enough UTXOs to cover the amount"	Better error and fee planning
"Gas is deducted from my account"	"I need DUST (generated by NIGHT) for fees"	More explicit resource management
"One address = one identity"	"Many UTXOs = flexible identity surface"	Stronger privacy options

This shift also matters for Midnight's smart contracts, which execute off-chain with proof generation. Instead of every node re-executing contract code, Midnight uses zero-knowledge circuits to prove correct execution.

Choosing the right token type

Understanding these models is practical preparation for building on Midnight. Choosing between ledger tokens and contract tokens is one of your first major design decisions:

Use case	Best choice	Why this model works	Example applications
High-volume payments	Ledger tokens (UTXO)	Parallel transaction processing	Payment processors, remittance systems
Private transactions	Ledger tokens (UTXO)	Individual UTXOs can be shielded	Confidential transfers, private auctions
Cross-chain bridges	Ledger tokens (UTXO)	Atomic operations and clear ownership	Bridge protocols, wrapped assets
Complex DeFi logic	Contract tokens (account)	Rich state management capabilities	AMMs, lending protocols, yield farming
Gaming mechanics	Contract tokens (account)	Complex rules and interactions	In-game currencies, item crafting
Governance systems	Contract tokens (account)	Voting weights and delegation	DAOs, protocol governance
Compliance-friendly assets	Both (hybrid approach)	Transparent base plus private options	Securities, regulated stablecoins

You are not forced to choose one model forever. You can use UTXO-based ledger tokens when you need performance and privacy, and account-based contract tokens when you need familiar programming patterns. You can also use both in the same application.