Find answers to some of the most frequently asked questions here.
Mainnet marks a huge step in the development of Midnight, crucially introducing state continuity and permanence (no chain resets) to the network. The mainnet launch doesn't mean that the work is done or that all planned features are delivered; rather, it marks the beginning of the recorded and immutable history of the blockchain.
Crucially, mainnet has state continuity and permanence. Conversely, preprod and preview carry no such promises, and may undergo chain resets, erasing all history and starting from scratch. As for each one's main usage:
- Mainnet is the production environment, where transactions have real value and protocol guarantees are binding.
- Preprod is a production-like test network used to validate releases under conditions that closely mirror mainnet.
- Preview is an early-stage development network for rapid experimentation and protocol evolution.
The initial launch establishes the foundational "physics" of the network under a trusted validator system - the first phase on the road to decentralization.
- Dual-component tokenomics: The NIGHT token is live on both Cardano and Midnight, and the DUST resource generation is active for shielded transaction fees.
- Selective disclosure/programmable privacy: Developers can use the Compact language and Midnight.js SDK to build applications that combine public and private state.
- Cross-chain upgadability and Federated Governance: Mainnet launches with built-in support to coordinate protocol upgrades across both Cardano (authoritative contracts) and Midnight (runtime/ledger rules), using a federated decision model run by a small set of accountable governance bodies. During the initial phase, block production is performed by up to 13 trusted nodes (no block rewards), providing a stable operational base while the network and governance mature towards decentralization.
- Cardano synergy: The DUST Generator DApp is implemented, allowing users to generate DUST and operate on Midnight from their Cardano NIGHT.
Selective disclosure is a protocol capability that allows for revealing only specific, necessary information while keeping all other data private. It enables smart contracts that allow users to prove a claim - such as being over 21 - without revealing sensitive underlying information, like their actual date of birth. This is achieved through Zero-Knowledge (ZK) proofs, which allow the network to provide verification that a statement is true without the user ever having to disclose the private data itself.
This refers to the developer's ability to define the data model itself. Unlike traditional blockchains where everything is public, or privacy coins where everything is hidden, Midnight offers a dual-state architecture that combines both public and private models.
Using the Compact smart contract language, developers can explicitly program which data fields remain in a local private state (on the user's device) and which fields are synchronized to the public ledger.
The result is that privacy becomes a programmable feature, not a binary toggle. The developer "programs" the boundary of the application's privacy by deciding where data lives.
A high-level overview of the four-phase roadmap is available here. This proposed high-level roadmap was published in November 2025 and should be subject to revisions once Mainnet launches and the evolving needs of the network and community assessed.
Midnight uses AURA (Authority Round), a proof‑of‑authority algorithm to determine which validator is responsible for producing each block in a round‑robin schedule, and GRANDPA (GHOST‑based Recursive ANcestor Deriving Prefix Agreement) as a separate finality gadget that lets validators vote to finalize blocks asynchronously. More details can be found in the documentation.
Not at launch. The Midnight mainnet will launch with a set of permissioned nodes operated by Shielded Technologies. The set will shortly thereafter expand to encompass 13 distinct federated node operators as block producers to ensure security during bootstrapping. A phased approach will be taken, with gradual decentralization until Midnight reaches full permissionless node operators.
Midnight launches with permissioned/trusted nodes to control risk during a new, privacy-critical protocol’s bootstrapping phase. This does not mean Midnight is designed to be centralized -- this choice reflects phased decentralization, not a centralized design.
Federated nodes are a permissioned set of trusted block producing nodes that will collectively operate the Midnight network during its controlled bootstrapping phase, under explicit rules about who may participate and how changes are coordinated.
No. Running a federated node during the bootstrapping phase is restricted to a set of trusted partners. Permissionless node operators will occur gradually, more information on future node operations will become available at a later date.
During the bootstrapping period, there will be up to 13 block producing validator nodes operating in the Midnight network. While at first all of them will be run by Shielded Technologies to ensure early stability and security, the plan is to to reach 13 distinct trusted, federated node operators in the weeks following mainnet launch.
No, federated node operators do not earn block rewards. No block rewards will be dispensed until later on the road to full permissionless node operators.
A Zero-Knowledge Proof (ZKP) is a cryptographic method that allows one party to prove to another that a statement is true without revealing any information beyond the validity of the statement itself. In the simplest context, a ZKP answers a true or false question (ex. "Are you old enough to do X?") without disclosing the specific value (ex. " born on DD/MM/YY" etc.) that proves it true.
A proof server is an off-chain service that constructs zero-knowledge proofs for Midnight transactions or contracts, typically on behalf of a user, without being trusted to authorize transactions or violate ledger correctness. At launch, to ensure that private transaction inputs never leave the user's environment, a local proof server is provided via a Docker container that users must install and run in their machines.
Proof servers are needed in order to create the zero-knowledge proofs required by Midnight transactions without exposing the underlying private data or leaking it on-chain.
Yes. Every on-chain transaction requires a fee paid in DUST, whether public or shielded. As DUST is a shielded resource, spending it requires a ZK proof. Therefore, every transaction requires a ZK proof.
At launch, a local proof server is provided to run proofs locally. This local server is a provided via a Docker container which must be installed. Instructions for how to get started can be found in the documentation.
Yes, it is anticipated that there will be alternatives to the Docker-based proof server provided after mainnet launch. Additional models are currently in development to support a wider range of trust assumptions, use cases, and device types.
The exact time it takes to generate a proof is variable. Generating a zero-knowledge proof is the most computationally intensive (and thus, time-consuming) part of a Midnight transaction. Since the provided proof server runs off-chain, locally to each user's machine, processing performace can vary greatly depending on the system running it (ex. retail laptop vs. institutional-grade server rack).
Proof size is the primary component of proof generation time: the larger the proof, the longer it takes to generate it. Proof size/complexity is represented as a value in 'k'. The larger the 'k' value, the more time it takes to process.
There is no change to the blockchain state, and your funds remain safe. Since Midnight transactions are constructed and proved locally before being sent to the network, a crash simply means the proof generation fails and the transaction is never broadcast. No partial state is recorded on the ledger, and no gas fees are paid. You can simply restart your application or wallet and try the transaction again. Your private data remains secure on your device because it never left your local environment.
There is a known issue with Docker in some Macs that run on Apple silicon. To solve it, go to Docker Settings > General > Virtual Machine Options and make sure Use Rosetta for x86_64/amd64 emulation on Apple Silicon is unchecked.
Using the Midnight network requires DUST, a non-transferable, renewable network resource generated over time by holding NIGHT tokens. DUST is consumed when transactions are executed, but NIGHT itself is never spent.
DUST-denominated transaction fees are dynamic and reflect the actual computational and storage impact of each transaction, as well as current network load. Simple transactions require less DUST than more complex ones.
Midnight does not rely on fee-market bidding; instead, the protocol adjusts the required DUST based on network capacity to help maintain predictable and stable transaction costs.
Midnight distinguishes itself through a "privacy-first" architecture that balances privacy primitives with the flexibility to allow applications to deploy highly programmable data models that adjust to each use case/jurisdiction. Its unique capabilities include:
Dual-state ledger: Unlike chains that are either fully transparent or fully anonymous, Midnight synchronizes two parallel states. The public state records clear transactions for auditability, while the local, private state keeps sensitive data (like business logic or personal IDs) encrypted locally on the user's device. The two interact via zero-knowledge proofs, ensuring the network verifies validity without ever seeing the raw secrets.
Programmable Privacy & Selective Disclosure: Using Compact (Midnight’s TypeScript-based language), developers can write "compliance-as-code." Instead of a binary privacy toggle, they can program granular rules—allowing users to prove facts (e.g., "I am solvent") via ZK proofs without revealing the underlying data.
Dual-component tokenomics (NIGHT & DUST): The network splits value/ownership from operational capacity to stabilize costs. NIGHT is the unshielded governance and utility token. Holding NIGHT automatically generates DUST, a shielded, non-transferable "gas" for transactions. DUST decays if unused, preventing hoarding and ensuring that private transaction metadata stays protected.
No. Midnight is a partner chain, a specialized layer-1 that operates alongside Cardano. It leverages Cardano's security and existing ecosystem of DApps, but maintains its own specialized ledger architecture optimized for zero-knowledge (ZK) state management. Transactions on Midnight occur independtly of Cardano and no rollup to Cardano takes place.
No, the launch of mainnet marks an important step in Midnight's evolution, but development continues and will only accelerate as the community grows. While the core protocol is live and functional, a phased roadmap will progressively introduce more complex features, deeper decentralization, and expanded interoperability.
Please refer to the Midnight tokenomics and incentives whitepaper.
Shielded tokens protect transaction metadata (such as sender, receiver, and input/output values) using zero-knowledge proofs, allowing transactions to be validated without publicly revealing those details.
Unshielded tokens operate like traditional blockchains, where data/metadata are fully visible and traceable on-chain.
Midnight's architecture integrates both models to enhance flexibility, performance, and to introduce rational privacy not just to simple token transfers, but also to complex smart contract interactions.
UTXO foundation
The core of Midnight's ledger operates on the UTXO model, securing the benefits of parallelism, efficient state management, and privacy through shielded UTXOs. The network's native utility token, NIGHT, exists as unshielded UTXOs. DUST, Midnight’s network resource, is based on Zswap, itself a UTXO-like scheme.
Account-based smart contracts
Layered on top of this UTXO foundation, the Midnight ledger keeps an account-based state for smart contracts and enhanced programmability.
Transactions are processed in the order they are packed by the validator. Inclusion is based on the node's transaction selection mechanism to maximize block efficiency. There is no gas auction and no priority-by-price mempool.
NIGHT is the unshielded native token of the Midnight network, used for generating DUST network resource, and -- in the future -- block rewards/ecosystem incentives and governance participation.
DUST is a shielded, non-transferable resource that is consumed to pay transaction fees. NIGHT is not spent to use the network. Instead, holding NIGHT and designating a DUST address will generate DUST over time, which is then used to execute transactions.
Midnight employs a dual-state architecture to bridge the gap between privacy and compliance. Instead of a single transparent ledger, the network synchronizes two distinct environments:
Public state (global): The on-chain, transparent ledger visible to all. It records necessary public data (like NIGHT balances and contract states) and stores the zero-knowledge proofs that verify transactions.
Private state (local): This is the off-chain, shielded environment located on each user's own device. Sensitive data (like private keys, identity documents, or business logic) remains here, encrypted and inaccessible to the network.
How they work together
Developers use the Compact programming language to define the boundary between these two states. By declaring specific fields as witness (private input) or using functions to disclose (publish output), they program exactly when and how data transitions from private to public. The local proof server then generates a ZK proof that updates the public state based on the private state, ensuring the blockchain reaches consensus on the validity of the data without ever seeing the data itself.
To generate DUST, you must explicitly register your NIGHT and designate a Midnight address to receive DUST. Registration links your NIGHT wallet to a DUST address, enabling DUST to be generated over time.
If your NIGHT is on Cardano, you can register using the DUST Generator DApp. This involves submitting a transaction on Cardano, so you will need enough ADA in your wallet to cover the network fee.
If your NIGHT is native to Midnight, registration is handled directly within a Midnight-compatible wallet.
For NIGHT held on Cardano, DUST generation begins approximately 12 hours after address registration. This delay reflects the cross-chain confirmation and block confirmation finality required to activate DUST generation on Midnight.
For Midnight-native NIGHT, DUST generation begins immediately after successful registration.
Yes. A protocol-level bridge for moving NIGHT between Cardano and Midnight is being deployed in phases.
Stage 1: One-way bridge. Shortly after mainnet launch, NIGHT will be able to move from Cardano to Midnight.
Stage 2: Two-way bridge. Support for moving NIGHT from Midnight back to Cardano will be introduced at a later stage.
The phased rollout prioritizes security and network stability. Two-way bridging introduces additional validation and security considerations that require more extensive mainnet-level testing before activation.
The bridge is launching in stages to prioritize security, supply integrity, and network stability. Enabling two-way transfers introduces additional validation logic and cross-chain coordination requirements that must be thoroughly tested under mainnet conditions.
By starting with Cardano-to-Midnight transfers only, the network can safely activate core functionality while additional safeguards for two-way bridging are finalized and validated before release.
Each 1 NIGHT can generate up to 5 DUST over a 7-day period, accruing linearly over time.
Once the maximum generated amount is reached, additional DUST will not accrue unless previously generated DUST is consumed or the amount of NIGHT in the registered address increases or decreases.
Understanding Midnight's peformace requires considering both the end-user side (time to generate proofs) and the block producing nodes' side (time to build, process, and propagate blocks). This relative complexity makes direct comparisons to other networks in simplistic terms (like transactions per second) difficult, even if only comparing to similar privacy-preserving, ZK-based peers.
The block time is approximately 6 (six) seconds. This may be changed via governance action and hardfork.
The target blocksize at launch is 1024kb. This may be changed via governance action and runtime upgrade.
Midnight nodes will be able to observe Cardano addresses that hold NIGHT and have registered for DUST generation via DUST Generator DApp. Once a NIGHT-holding Cardano address has been registered, Midnight will maintain observability to ensure the corresponding generation of DUST for that NIGHT remains consistent on Midnight.
Midnight uses a dual-component model to separate persistent value/utility from network operations. NIGHT represents governance and long-term participation, while DUST powers transactions. This design reduces the direct impact of market volatility on transaction costs and allows transaction metadata to remain shielded without requiring the utility token itself to be private.
The DUST Generator DApp is a non-custodial Cardano application that allows NIGHT holders to register their Cardano-based tokens to generate DUST on Midnight. It links a NIGHT-holding Cardano address to a Midnight DUST address without moving or locking the underlying NIGHT.
No. Registering for DUST generation does not require you to transfer or relinquish custody of your NIGHT. The DUST Generator DApp records a registration on Cardano, but your tokens remain in your wallet and under your control at all times.
Compact is the domain-specific programming language (DSL) designed for writing privacy-preserving smart contracts on the Midnight blockchain. Inspired by TypeScript, it features a familiar, strongly statically typed syntax that allows developers to program "dual-state" logic-defining both public ledger data and private local data without the need for deep cryptographic expertise.
The language compiler automatically handles the generation of Zero-Knowledge Proofs (ZKPs), abstracting away the complexity of ZK circuit construction. Compact is developed as an open-source project under the name Minokawa within the Linux Foundation Decentralized Trust (LFDT), ensuring transparency and community-driven governance. LINK: https://github.com/LFDT-Minokawa/compact
DUST generation capacity is tied to the amount of NIGHT you have registered. If you reduce your registered NIGHT balance, the maximum DUST that balance can support will also decrease.
If you spend part of your registered NIGHT, any DUST above the new allowable cap will gradually decay until it aligns with the remaining NIGHT.
If you spend all of your registered NIGHT, the associated DUST will decay to zero.
When additional NIGHT is received into a registered address, the DUST generation capacity increases proportionally. Accrual continues linearly based on the updated NIGHT balance until the new maximum is reached.
Midnight supports two primary token categories:
- Ledger-based tokens, which are embedded directly into the protocol for high efficiency and basic value transfer. While native ledger-based tokens like NIGHT and DUST follow fixed protocol rules, custom ledger-based tokens allow for basic fungible or non-fungible assets that integrate natively with wallets.
- Contract-based tokens, which offer full programmability for complex financial logic and advanced access control.
As for standards, equivalents to Ethereum's ERC-20 and ERC-721 are being developed through the OpenZeppelin Compact Contracts library to ensure interoperability and composability across decentralized applications. However, developers should note that contract programmable shielded tokens currently face limitations due to the absence of native "custom spend" hooks in the Zswap protocol.
On Midnight, selective disclosure is proof-based, not data-sharing-based. A user does not "disclose" the transaction itself. They produce a proof about the transaction that discloses only the select facts that are required by/satisfy the constraints set by the other party. The key concept is that the end-user cannot arbitrarily choose what facts to prove or share; that prerogative lies with the smart contract they are interacting with. End-users can only choose to accept/reject the request.
Governance is the mechanism the network uses to discuss, debate, and decide changes, and then record and (when needed) execute those decisions using a mix of off-chain coordination (proposal write-ups, reviews, revisions, and evidence like testing results) and on-chain actions (authoritative approvals and updates).
Because Midnight also includes components on Cardano, governance decisions can have effects on either chain (and sometimes both), so the process has to make it clear what’s being decided, who can decide it, and what actions represent the decision on each chain.
In the federated phase, the main bodies are the Council (oversight and accountability), the Technical Authority (technical evaluation and safety/feasibility), and Federated Node Operators (run the network and perform operational rollouts like client distribution and readiness signaling).
People propose and refine changes off-chain, then the Council/TA provide the formal approvals that make certain actions legitimate. On Cardano, membership and other anchored “source-of-truth” records are updated through governance-authorized transactions, and on Midnight, privileged network changes (like runtime upgrades/parameter updates) are approved and executed through the federated governance mechanism. Operators carry out the rollout steps as necessary (e.g. Hard Forks) and the network and observers can verify what was approved, what was executed, and what outcomes were recorded.
The Midnight Improvement Proposal (MIP) is a formal, community-driven process for proposing changes, standards, and enhancements to the Midnight network ecosystem. It is modeled after similar frameworks like Cardano's CIP, Bitcoin's BIP and Ethereum's EIPs.
Anyone in the community can submit a proposal, which then goes through stages of drafting, review, and discussion before being accepted or rejected. MIPs cover a wide range of topics, from protocol-level changes and token standards to governance processes and wallet conventions. All proposals are managed publicly on GitHub, with a group of MIP editors helping ensure quality and consistency, making the whole process transparent, well-documented, and open to participation.
A Midnight Problem Statement (MPS) is a formal document within the Midnight ecosystem that allows community members to clearly define and describe a problem or challenge facing Midnight without necessarily proposing a specific solution. It serves as a complementary companion to the MIP process.
While a MIP proposes a concrete change or standard, a MPS focuses on articulating the problem space first, encouraging open discussion and exploration of the issue before jumping to solutions. This helps ensure that problems are well-understood and agreed upon by the community, and it can inspire one or more MIPs to address the identified issue. Like MIPs, MPSs are managed publicly on GitHub and are open to community feedback and collaboration.
Not at launch. The Docker requirement for proof generation necessitates a desktop/server environment. As new modalities for proof serving become available (ex. in-browser, TEE-hosted), the ability to use Midnight on mobile devices will expand.
Yes, there will be multiple block explorers. Please refer to the ecosystem catalog for a wide catalog of Midnight-based projects.
The transaction cost model determines how much DUST is required to execute a transaction on Midnight. It evaluates the computational and storage impact of each transaction and adjusts pricing based on overall network usage.
This model ensures that fees reflect actual resource consumption rather than fee-market bidding, helping maintain predictable and stable transaction costs.
Yes, you can run a non-block-producing full and/or archive node. Instructions can be found in the documentation.
Yes, Midnight's core codebase is open source and publicly available. Additionally, Midnight's smart contract language, Compact, is now officially part of the LF Decentralized Trust, under the Minokawa project.
The core protocol code is open source and subject to professional third-party security audits, with particular focus on cryptography, zero-knowledge circuits, ledger invariants, and economic safety. Auditing is treated as an ongoing process, not a one-time certification.
Lace wallet supports mainnet and other Midnight environments. Other wallet providers that may support mainnet can be found in the ecosystem catalog.
Not without your explicit permission. Your private balance resides in your local private state, encrypted on your device. DApps interact with this data only through Zero-Knowledge Proofs, which mathematically verify that you have sufficient funds for a transaction without ever revealing the actual amount. The DApp never sees your raw data unless you explicitly choose to unshield it.
Not at mainnet launch and early bootstrapping phase. When launched, the bridge will at first support one-way transfers from Cardano to Midnight only. Support for moving NIGHT from Midnight back to Cardano will be introduced in a later phase once additional validation and security safeguards have been fully tested.
Tokens do not have a “shielded” or “unshielded” state at the protocol level. A token is either shielded or unshielded --- the same token cannot be both. If an application/token creator needs this type of token behavior, they must implement it at the smart contract level.
Federated governance means that, in the early phase, Midnight is governed by a known set of accountable authorities, rather than an open, token-holder-driven on-chain process. It splits responsibility across roles: the Council and Technical Authority (TA) both approve the same governance actions, but through different lenses. Council focuses on legitimacy, policy, and ecosystem risk, while TA focuses on technical correctness, safety, and sequencing.
Federated Node Operators (FNOs) don’t decide what should change, but they make change execution possible in practice: they operate the network and coordinate client rollouts (including hard-fork-like upgrades), provide readiness/convergence signals, and help ensure the network has adopted the required version before governance actions are activated.
DUST generation capacity is directly tied to your registered NIGHT address's "balance". If that balance decreases through transfer, deregistration, or re-registration, the maximum DUST your address can support decreases as well. Any excess DUST will gradually decay to match the updated cap, and if all registered NIGHT is removed, the associated DUST will decay to zero.
Metadata is the set of data attached to transactions that provides context (data about data) to transactions. It includes timestamps, sender/receiver addresses, gas fees, and smart contract inputs.
Midnight protects against the most privacy-harming forms of metadata leakage: transaction contents, graph mapping/interconnections, and fee signals.
Yes. Midnight Preprod (testnet) and Midnight Preview (devnet) will continue to exist.
Not at launch. There is no staking mechanism at mainnet launch. Future staking functionality, if proposed, would be introduced through the network’s governance process.
Is the official TypeScript client library designed to facilitate the development of privacy-preserving decentralized applications (DApps) on the Midnight network. It acts as the bridge between a web application and the blockchain, providing a set of standardized "providers" that abstract away the complexity of the underlying architecture.
These providers allow developers to easily manage local private state, query public ledger data, connect to wallets for signing, and orchestrate the generation of zero-knowledge proofs, enabling DApps to interact with Compact smart contracts and submit shielded transactions without requiring deep cryptographic expertise.
The Private state applies specifically to Shielded tokens and privacy-preserving smart contracts and is never stored on the Midnight blockchain. This data resides off-chain solely on the user’s local device or wallet and is kept encrypted. The network interacts with this state only through ZK proofs, which verify that a user’s private data meets a contract's rules (e.g., sufficient balance or valid ID) without ever accessing, storing, or exposing the raw information to the public ledger.
No. Validators verify cryptographic proofs but cannot see the contents of shielded transactions, including private balances, private transaction details, or private smart contract states. Validators (and everyone else) can still see unshielded transactions.
Yes. Midnight smart contracts are written in Compact, a Typescript-based domain-specific language which abstracts much of the advanced cryptography to make it easier for developers to create privacy-preserving applications.
DUST is generated to a designated Midnight address that is separate from the NIGHT address that generates it. This separation helps protect transaction metadata and ensures that DUST activity cannot be directly inferred from a user’s NIGHT holdings. It also provides flexibility, allowing a NIGHT holder to change the DUST recipient address over time rather than permanently linking generation to a single address.
DUST addresses are managed by wallets, derived from a DUST public key and encoded as a special Midnight address type. On mainnet, DUST addresses are prefixed by mn_dust-addr, followed by a string of characters of variable length, up to 33 bytes.
A DUST public key is computed as a hash of a DUST secret key. The DUST secret key itself is derived from the wallet's HD seed using a dedicated "DUST" role in the derivation path. Technical and implementation details can be found here.
Midnight uses three Bech32m-encoded address types, each serving a distinct purpose. Although all three are deterministically derived from the same wallet seed, they are independent from one another and are handled separately by Midnight wallets.
The first is the unshielded address, used to receive NIGHT and other unshielded ledger-defined tokens. These addresses use the "addr" prefix, such as mn_addr on mainnet and mn_addr_test on testnet.
The second is the shielded address, used for private transactions. It encodes both a shielded token public key and an encryption public key. This address type is independent of and not compatible with DUST. These use the "shield-addr" prefix, such as mn_shield-addr.
The third is the DUST address, which is used specifically as the recipient for DUST generation. DUST can only be generated into this address type. These use the "dust-addr" prefix, such as mn_dust-addr.
DUST cannot be transferred to shielded or unshielded payment addresses. If you attempt to send DUST as a standard transfer, the transaction will fail. DUST is not a transferable token. It can only be used as a network resource to pay transaction fees, and when used, it is consumed rather than sent to another party.
DUST cannot be purchased because it is not a transferable asset. It can only be generated from registered NIGHT and is consumed when used to pay transaction fees. If you do not hold NIGHT, you cannot generate DUST yourself and therefore cannot initiate transactions directly. However, a third party such as a DApp operator may generate DUST to an address under your control, effectively sponsoring your use of the network.
Capacity exchanges and other forms of marketplace for network capacity have been introduced in the Midnight tokenomics and incentives whitepaper as an emergent functionality at the core of Midnight's cooperative economics. While potential features are being explored, as of mainnet, there won't be a mechanism to achieve that.
Midnight separates capital from usage. NIGHT provides long-term incentives and governance, while DUST powers transaction execution. Because DUST is generated from NIGHT, non-transferable, and consumed when used, capacity cannot be stockpiled or auctioned in speculative fee markets. This structure aligns incentives and supports predictable, sustainable network operations.
Midnight governance is designed to evolve over time. It begins in a federated phase, where a small set of accountable governance bodies can make and execute decisions while the network is still being bootstrapped. As Midnight’s security and operational maturity increase, governance will decentralize gradually, with more decision-making responsibility shifting toward the broader community.
Crucially, Midnight’s on-chain governance is built to be self-updatable: the governance system can change its own parameters, roles, structure and decision mechanisms through governance itself. That means decentralization can be proposed and delivered as community-driven initiative (for instance, through MIPs) using the governance foundations that already exist on-chain.
DUST is Midnight’s shielded asset, meaning it is private by default. On the public ledger, a DUST transaction reveals only a Zero-Knowledge (ZK) proof and a "nullifier" - cryptographic markers that prove a transaction is valid and prevent double-spending without revealing the underlying details. Unlike transparent tokens, DUST hides the sender and receiver addresses, the transaction amount, and the link to your NIGHT balance. This metadata remains invisible to the public unless you intentionally choose to share it via a viewing key or through specific programmable privacy features defined by a dApp developer.
At launch, NIGHT on Cardano cannot directly activate DUST generation on Midnight because a protocol-level bridge is not yet live. The DUST Generator DApp records the required cross-chain registration, allowing you to generate DUST without moving your NIGHT. A one-way bridge from Cardano to Midnight is expected shortly after mainnet, with two-way functionality added later.
Hardware wallets are not supported at mainnet launch. Support may be introduced in the future, subject to further development and ecosystem integration.
With any new blockchain network launch, initial support by wallets and other applications can be challenging. Midnight's specific launch approach (Glacier Drop, federated governance, Cardano partner chain model) has been chosen to mitigate these challenges. Beyond this, inherent aspects of Midnight (proof generation, unique tokenomics, ZK, privacy-first design) may carry a steep learning curve for users and builders alike.
Your wallet seed phrase allows you to recover your unshielded addresses and associated assets, such as NIGHT, as well as publicly visible transaction history. However, shielded assets and certain private contract interactions rely on locally stored private state that is not recoverable from the seed phrase alone.
If that private state is lost and no backup exists, you may lose access to unspent shielded notes and any contract-specific private data tied to it. The on-chain commitments remain intact, but without the corresponding private state, you cannot generate the proofs required to access or spend those assets.
If you hold NIGHT in an address that has not been registered for DUST generation, you can still access previously accrued generation capacity retroactively. When building a transaction that includes those NIGHT tokens, the protocol may treat them as if they had been registered from the moment they were received, allowing the transaction fee to be covered by the DUST that would have accrued during that time. Any unused portion of that accrued capacity becomes available as DUST after the transaction.
If you do not hold NIGHT at all, you cannot generate DUST yourself and would need a third party to sponsor your transaction.
A contract's state is not permanently "shielded" or "unshielded". The dual-state model (public state on-chain and private state held locally by each user/DApp) allows data to transition between these states through programmatic logic in Compact.
Transitioning between Shielded and Unshielded is accomplished by defining specific interactions in the smart contract:
To move data from a private, shielded context to the public ledger, you must use the disclose() function in the Compact code. This signals to the Compact compiler that you are intentionally allowing a value that is (directly or indirectly) derived from private witness data to be written into the public ledger state.
Bringing public data into a private context is achieved by having a witness function read data from the public ledger (via the witness context’s ledger view) and then use it locally as input for private logic. Note: this does not make on-chain data private again, it remains public; you’re just consuming it in the private/off-chain part of the system.
Ultimately, data visibility is a matter of programmatically defining the logic of a contract. Developers must also consider upgradability; if core changes are made to the contract logic or if Midnight introduces breaking proof-system/runtime upgrades, a designated Contract Maintenance Authority (CMA) can perform privileged updates (e.g., managing verifier keys / versions) so the contract can continue to operate under supported versions.
Midnight implements a dual-state architecture that combines a global public state and a local (to each user) private state. Data can be either public/on-chain, or private/locally stored.
Public Data:
All unshielded token transactions are by definition public and visible on-chain. Any information that was defined as public data by the smart contract will also be publicly visible. Other information that can be viewed includes that a transaction occurred and what time. Other details about the block will also be public, including block headers, timestamps, validator signatures, and the bytecode of smart contracts.
Abstracted Data:
Data defined as private by the smart contract will be stored as opaque payloads. Midnight records commitments (hidden amounts / owners) and nullifiers (proof that an asset was spent) on-chain via zero-knowledge proofs. These proofs allow the network to verify a transaction is valid without ever having access to the underlying data.
Local Data:
Users' local private states (i.e. data on their personal devices), private keys, and the raw data used to construct transactions and proofs never leave a user's local machine.
Midnight uses a dual-state ledger to securely manage the relationship between public and private data. Sensitive information -- like personal identity or private balances — is never uploaded to the network; instead, it is stored locally on the user's device in their private state.
When a user transacts, their local proof server combines this private information with data from the public ledger to generate a zero-knowledge proof (ZKP). This proof is then recorded on the blockchain to mathematically validate that the transaction followed the contract's rules. However, to anyone observing the network, the proof simply confirms the action is valid - the underlying data and user identity remain completely opaque and mathematically impossible to reverse-engineer.
In short: the blockchain stores the mathematical proof that your transaction is valid, while keeping the substance of the underlying data hidden from everyone—including validators and indexers.
The DUST Generator DApp works based on a Cardano wallet account's stake key. If you hold NIGHT in more than one account within the same wallet, only the active account will be registered when using the DUST Generator DApp. You must manually switch accounts if you want to generate from another account.
Midnight is a ground-breaking data protection blockchain. Developers can quickly, easily, and securely build regulation-friendly apps that safeguard personal and commercial data.
Midnight uses zero-knowledge technology to transact on user data without sharing it. This protects users’ identities and ensures integrity because personal data never leaves the user’s device.
There are several types of zero-knowledge proofs (ZKPs) that differ in performance and cryptographic assumptions. Midnight uses ZK Snarks to separate an app’s source of public and private data, so sensitive data remains on the owners’ systems or devices.
Midnight offers an innovative programming model to simplify the DApp development process. Using TypeScript libraries and Midnight's contract-definition language, developers can quickly build and launch new apps.
Organizations and developers can create privacy-preserving smart contracts with ease, as Midnight provides the necessary tools to build and run software, allowing for seamless integration with the platform.
The Midnight testnet is an alpha release of the Midnight blockchain. It serves as a testing ground for development. Testnet users will be able to build and run confidential smart contracts and gain familiarity with zero-knowledge technology. Devnet users can still access projects built in that environment, but it is recommended that projects are migrated to testnet. Testnet features include programmable data protection capabilities, hard forking capabilities, minimized chain resets, and onboarding for block producers.
The Midnight software development kit for testnet includes:
VS Code plugin and debugger
Midnight SDK installer (tools to build and run software, including Compact compiler and runtime)
Development tools for testing the node and Midnight Lace wallet (alpha)
Smart contract utility libraries and sample projects
There are a number of resources for developers under Midnight Docs at docs.midnight.network. Developers can get started building on the testnet by reviewing and following Midnight’s docs, where you'll find all the information and packages you need to interact, run, and develop on the Midnight testnet. Additional support can be found through the Midnight Discord.