Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From core-concepts
This skill should be used when the user asks about UTXO vs account models, ledger tokens, shielded/unshielded tokens, nullifiers, coin commitments, the Zswap commitment tree, double-spend prevention, token balances, parallel transaction processing, choosing between token paradigms in Midnight, minting tokens, token type identification, or the ledger structure.
npx claudepluginhub devrelaicom/midnight-expert --plugin core-conceptsHow this skill is triggered — by the user, by Claude, or both
Slash command
/core-concepts:data-modelsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Midnight supports two distinct token paradigms: **UTXO-based ledger tokens** and **account-based contract tokens**. Choose based on privacy requirements and use case complexity.
This skill should be used when the user asks about Midnight tokens, token types (NIGHT, DUST, shielded, unshielded), minting and burning tokens, token transfers, token colors and domain separators, the zswap protocol, ShieldedCoinInfo, QualifiedShieldedCoinInfo, Kernel mint operations, contract token patterns (FungibleToken, NonFungibleToken, MultiToken), the account model vs UTXO model for tokens, sendShielded, receiveShielded, sendUnshielded, mintShieldedToken, mintUnshieldedToken, unshieldedBalance, OpenZeppelin Compact token contracts, or choosing between shielded and unshielded token approaches.
This skill should be used when the user asks about Midnight tokens, NIGHT token, DUST resource, token distribution, Glacier Drop, Scavenger Mine, block rewards, tokenomics whitepaper, STAR denomination, token economics, dual-token model, MEV resistance, token supply, or how transaction fees work in Midnight.
This skill should be used when the user asks about the Midnight.js SDK, midnight-js packages, @midnight-ntwrk npm packages, setting up SDK providers, deploying or finding contracts with deployContract or findDeployedContract, calling circuits with callTx or submitCallTx, the transaction lifecycle, SDK provider types (WalletProvider, MidnightProvider, PublicDataProvider, ProofProvider, ZkConfigProvider, PrivateStateProvider), testkit-js testing, observable state subscriptions, contract maintenance and verifier keys, or connecting to the indexer or proof server.
Share bugs, ideas, or general feedback.
Midnight supports two distinct token paradigms: UTXO-based ledger tokens and account-based contract tokens. Choose based on privacy requirements and use case complexity.
| Requirement | Use UTXO (Ledger Tokens) | Use Account (Contract Tokens) |
|---|---|---|
| Privacy critical | Yes - independent, shieldable | Less native privacy than UTXO; shielded contract tokens in development |
| Parallel processing | Yes - no ordering deps | No - sequential nonce |
| Simple transfers | Yes | Overkill |
| Complex DeFi logic | Limited | Yes |
| Gaming state machines | No | Yes |
| Governance/delegation | No | Yes |
UTXO = Unspent Transaction Output. Each token is a discrete digital coin that must be spent entirely.
Creation -> Existence -> Consumption -> Prevention of Reuse
Unlike Bitcoin, which references prior outputs directly by txid+index (revealing which coin was spent), Midnight uses nullifiers:
Each coin carries a value, token type, and unique nonce. The nullifier is a hash derived from the coin data and the spending key.
Privacy benefit: The nullifier is computed from the raw coin data and the spending key, not from the commitment. This means the nullifier reveals nothing about which coin commitment was spent.
Each UTXO independently chooses privacy level:
Maintain address-to-balance mappings within Compact contracts, following patterns inspired by OpenZeppelin-style token standards adapted for Compact.
| Aspect | Account Model Limitation |
|---|---|
| Privacy | Less native privacy than UTXO; shielded contract tokens in development |
| Ordering | Nonce creates sequential dependency |
| MEV | Mempool visibility enables front-running |
| Scalability | Redundant computation on every node |
Midnight's ledger has two components:
Token types are 256-bit collision-resistant hashes:
For detailed technical information:
references/utxo-mechanics.md - Complete UTXO lifecycle, nullifier computationreferences/ledger-structure.md - Zswap state internals, Merkle tree details