Midnight (NIGHT): NIGHT Holds Value; DUST Pays for Network Capacity
Midnight is a privacy-focused smart-contract network that supports public and shielded data states. NIGHT is a transferable utility asset that generates DUST; DUST is a separate, non-transferable resource used for network transactions. This page focuses on nIGHT Holds Value; DUST Pays for Network Capacity and the checks users need before sending funds, paying fees or using the network.
Use NIGHT and Midnight applications while understanding DUST capacity, privacy state and multichain asset handling.
Subject:
Midnight
Market mode:
Snapshot Only
Fee asset:
DUST
Timezone:
UTC
This page does not generate DUST, prove a transaction is anonymous, assess regulatory duties, bridge NIGHT, audit a disclosure policy or guarantee wallet compatibility.
Content ownership: BitcoinToolkit Editorial TeamTechnical references: Official protocol and developer documentation.Review approach: Technical explanations are checked against primary sources and updated when the network or asset changes.Last content review: Data integration last tested:
NIGHT Holds Value; DUST Pays for Network Capacity
Midnight deliberately separates the transferable asset from the resource consumed by transactions.
Midnight workflow from the first user decision to a verified outcome.
Generate, designate and consume
NIGHT is transferable and supports utility, incentives and future governance roles. When eligible NIGHT is registered, it generates DUST over time. DUST is shielded, non-transferable and perishable: it is designated to an address, used for transaction execution and decays instead of operating like a freely traded gas token.
Check whether the wallet supports the relevant NIGHT representation and DUST designation workflow. Holding market-traded NIGHT does not mean a wallet already has spendable DUST on Midnight. DUST capacity can change as NIGHT moves or registration state changes, so applications should expose resource state rather than showing only a NIGHT balance.
The network provides privacy tools, but the application and user still choose what enters each state.
Public facts and protected data
Midnight contracts can combine unshielded ledger state with shielded data and zero-knowledge proofs. A proof can establish that a condition is satisfied without publishing every underlying value. The transaction may still expose timing, application interaction, public outputs, designated disclosures or offchain data supplied to another party.
Read the application disclosure policy before signing and identify which fields, recipients and proofs are public. Use separate operational identities when appropriate and avoid assuming a shielded balance hides browser, wallet, exchange or network metadata. Privacy depends on contract design, wallet behavior, user choices and the size of the relevant anonymity set.
Cardano and Midnight NIGHT Are Coordinated Representations
The token launched on Cardano before being represented in the live Midnight ledger.
Check chain, phase and movement direction
NIGHT launched as a Cardano native asset in December 2025 and is mirrored into the Midnight network under the published multichain design. Protocol controls are intended to prevent the same supply from being unlocked on both chains at once. Current movement direction, redemption and wallet support depend on the rollout phase and official interfaces.
Verify chain, policy ID or Midnight asset identity and the current movement process. Keep ADA for Cardano redemption transactions when required; DUST is used for Midnight execution. Do not send a Cardano native asset to a Midnight address or assume a same-ticker exchange withdrawal completes the protocol movement automatically.
Token holders, application users and developers need different evidence.
Asset, capacity and disclosure checklist
NIGHT holders should verify representation, custody and DUST designation. Application users should review wallet support, requested disclosures and DUST sponsorship. Developers should model public and private state, proof generation, resource exhaustion and recovery. Network participants should verify current block-production and incentive rules rather than relying on a roadmap description.
Preserve Cardano and Midnight transaction identifiers separately and confirm official wallet support before moving value. Test applications with non-sensitive data first. Use security tools for key handling, developer tools for contract and proof workflows, and current Midnight documentation for rollout-dependent behavior.
No. NIGHT is transferable; DUST is a non-transferable transaction resource.
Does every NIGHT balance immediately provide Midnight transaction capacity?
No. Registration, designation and wallet support matter.
Does shielded state guarantee anonymity?
No. Application design and surrounding metadata still matter.
What pays transaction fees when using Midnight?
Midnight network resource (DUST) pays the applicable network fee. DUST is the non-transferable, decaying resource consumed for Midnight transactions. Verify the selected network before signing because a later approval, bridge, claim or exit can require another transaction.
What should I verify before a Midnight transaction?
Check the official destination, current network, asset representation, amount, recipient and requested permissions. Applications use zero-knowledge techniques and dual-state contracts to keep selected data private while exposing required facts. Registered NIGHT generates decaying DUST capacity that can be designated to power transaction execution. After confirmation, inspect the resulting balance or protocol state instead of relying only on a wallet success message.
Known Limitations
Wallet, bridge and governance features continue to evolve.
Shielded execution does not remove every metadata leak.
The page does not inspect a DUST designation or disclosure policy.
Market Data Methodology
The page uses a CoinGecko aggregated NIGHT/USD snapshot. No exchange chart is rendered for this entity.
Market Snapshot Source
CoinGecko aggregated market data (NIGHT/USD)
Cache
Snapshot cache is approximately 60 seconds.
Failure Handling
Verified cached data is labeled Cached or Delayed. Missing values remain unavailable.
