Midnight networkMidnight network access starts with a compatible wallet and environment
Midnight network access depends on a wallet which supports the chosen environment, the dApp connector version and the operation you plan to approve. A wallet may hold NIGHT yet lack the connector or proving path a particular dApp needs. Before authorizing a transaction, confirm the wallet identifies the correct network, exposes a compatible API and can provide the required address type. Transaction readiness also depends on DUST and a supported zero-knowledge proving route. Lace, 1AM and CTRL are documented Midnight interfaces, although support can differ by environment and feature. Treat the wallet's connected status and network ID as the initial proof of compatibility, then review the proposed action before signing.
Supported wallet and environment combinations
Wallet compatibility depends on the wallet, network and intended action. Mainnet is the production environment. Preprod mirrors production closely for release testing, while Preview is intended for earlier experimentation. A wallet listed for one environment does not automatically support the same contracts or connector behavior elsewhere.
Mainnet has persistent production state, while Preprod and Preview may be reset. An address, contract or transaction record from a test environment should not be treated as a mainnet record, even when the interface looks similar.
Lace supports Midnight environments, while 1AM and CTRL are also documented as interfaces for managing assets and private smart-contract interactions. Their available platforms, proving methods and feature coverage can differ. Check the actual wallet build and the dApp's requested environment instead of relying on a general ecosystem announcement.
The connector links the wallet, dApp and network
The DApp Connector API is the negotiation layer between a browser dApp and an installed Midnight wallet. It lets the application discover a wallet, request access to a named network and receive a connected interface after approval.
A compatible browser wallet exposes its name, icon and API version before the user authorizes a connection. The dApp can use those fields to present available choices and reject an API version outside its supported range.
More than one wallet may appear in the same browser. Connector entries use generated identifiers, so a dApp should enumerate the available entries and let the user select one. A hardcoded wallet name can miss an otherwise compatible installation.
After approval, the connected interface can report addresses, balances, connection status and service configuration. That configuration can include the network, indexer, node and proving service selected by the wallet.
The wallet retains control of its keys and authorization. The dApp requests an operation, but the wallet provides the relevant state and signing boundary. A successful connection establishes communication only; it does not prove every requested transaction can be built or funded.
What must match before transaction approval?
The wallet's environment, connector API and required capabilities must match the dApp before a transaction is approved. Version labels alone are insufficient because a wallet can implement the connector yet omit a feature the requested operation needs.
- Confirm the dApp requests mainnet, Preprod or Preview intentionally.
- Check the wallet reports an API version within the dApp's accepted range.
- Make sure the wallet can expose the address role the operation requires.
- Verify a supported proving path is available for the intended transaction.
- Ensure the account can supply DUST or use an offered sponsorship path.
Compatibility matrices describe tested component sets, not every combination able to run. Earlier versions may work without being supported. A current wallet with an outdated connector can therefore fail before approval, while a matching connector may connect and fail later because the proving or transaction feature is absent.
Address roles are separate by design
A compatible wallet manages three Bech32m address roles: an unshielded address for NIGHT and other transparent ledger-defined tokens, a shielded address for private transfers and a DUST address for generation capacity. These roles come from the same wallet seed but are independent. Mainnet prefixes distinguish them, which helps a wallet reject an address intended for a different purpose. A shielded or unshielded address cannot receive DUST as a normal transfer.
DUST and proof generation determine transaction readiness
Connection status does not show whether the account can pay for the requested computation. Every on-chain transaction consumes DUST and requires a zero-knowledge proof because DUST itself is shielded. DUST is a non-transferable network resource generated from registered NIGHT, and a third party may sponsor capacity to an address the user controls.
The required amount is not a fixed wallet fee. It reflects the transaction's computational work, storage impact and current network load. A simple transfer and a complex contract call can therefore require different capacity. Holding NIGHT without the relevant registration or DUST state does not establish immediate readiness.
Proof generation adds another compatibility check. Some wallet flows prove in the browser or on the device, while other setups use a configured proving service. The dApp should follow the wallet's service configuration because changing the node, indexer or prover independently can create mismatched state and weaken the user's privacy choices.
A compatibility decision with two installed wallets
All wallet, environment and feature states in this example are hypothetical. A reader has two browser extensions. Wallet A exposes a connector version the dApp accepts and offers the required action on mainnet. Wallet B exposes a connector, but its selected account supports that action only on Preprod.
The reader applies one shared test: the requested network, API range, address role and proving path must all agree. Wallet A passes those conditions, so it is the appropriate selection for the mainnet request. Wallet B is a valid fallback only if the intended task moves to Preprod; it is not a substitute for the mainnet action.
After Wallet A is authorized, the returned status says connected and reports mainnet as the network ID. Those two signals confirm the state transition from available wallet to active connection. Available DUST and proof workload remain variable inputs, so the connection does not promise a fixed cost or completion time.
Private state changes the recovery plan
Wallet compatibility also covers how private state is stored and restored. Midnight keeps private application state off-chain on the user's device or in the wallet. Zero-knowledge proofs let the network validate an action without receiving the underlying private values.
A seed phrase can recover unshielded addresses and public history, but it does not by itself restore locally held private state. Without a separate backup, losing that state may remove access to unspent shielded notes or contract-specific private data even though their commitments remain on-chain.
A wallet suited to shielded activity should make its storage and backup behavior clear before funds or contract state depend on it. Device support is not enough on its own. The recovery method must cover the private data required to construct future proofs, and the user should understand whether moving to another wallet preserves that data.
Connection failures reveal where support stops
A wallet which never appears in the dApp has failed at discovery. Common causes include a disabled extension, a page opened before installation or a dApp looking for a fixed wallet key instead of enumerating connector entries.
An authorization prompt followed by an error means discovery succeeded, but the connection did not. The wallet may be locked, the request may have been rejected or its selected network may differ from the network the dApp requested.
A connected wallet can still block the intended action. Missing DUST, an unavailable proving route, the wrong address role or an unsupported transaction method all occur after discovery. None of those states is repaired by reconnecting repeatedly.
The wallet's reported connector version should satisfy the dApp's accepted range, while the surrounding node, indexer and proof components should come from a tested set. A newer number in one component does not make a mixed set compatible.
If the wallet lacks a required capability, use another wallet or the environment the current wallet supports. Switching networks changes the ledger and state context, so it is appropriate only when the task itself belongs there.
How can you confirm the right network?
Confirm the network ID returned by the connected wallet and compare it with the environment the dApp requested. A connected label without that comparison can hide a mainnet, Preprod or Preview mismatch.
Address formatting provides another signal, but it should not replace the reported network ID. Mainnet and test environments use distinguishable address forms, while the wallet configuration also identifies its node and indexer. All of these signals should agree before an operation is prepared.
Before approving the operation, read the network, account, address role and requested action shown in the wallet prompt. If the prompt lacks enough information to identify the commitment, canceling preserves the current state and leaves the underlying compatibility question unresolved.
The commitment boundary starts after connection
Connecting exposes the approved wallet interface to the dApp; it does not move assets or submit a transaction. Commitment begins when the wallet is asked to sign, balance, prove or submit a specific operation. Review that request in the context of the selected network and account. Even a technically compatible wallet cannot make an unsupported address type, insufficient DUST or missing private state valid, so compatibility depends on the complete transaction path.
Things people ask about Midnight network
Is Midnight network a Cardano rollup or sidechain?
Midnight is a specialized layer-1 partner chain which operates alongside Cardano rather than rolling transactions up to it. NIGHT exists on both Cardano and Midnight. Cardano-held NIGHT can be registered to generate DUST, but a Midnight dApp still needs a Midnight-compatible wallet interface. The selected Midnight environment and address role must also match. Cardano wallet support alone does not establish compatibility with a Midnight dApp.
Can a dApp see my private balance after I connect?
Connecting does not give a dApp unrestricted access to your private balance. Private state stays encrypted locally, and the application can use zero-knowledge proofs to verify required conditions without reading raw values. A dApp may see public or unshielded information and anything you explicitly disclose. The permission shown by the wallet still matters because connecting, approving data access and signing a transaction are different actions.
What happens to DUST capacity when a registered NIGHT balance falls?
DUST capacity falls when the registered NIGHT balance supporting it decreases. Transfers, deregistration or re-registration can lower the maximum capacity associated with the address, and excess DUST then decays toward the new cap. Removing all registered NIGHT makes the associated DUST decay toward zero. This behavior is separate from DUST already consumed by transactions and from any capacity another party sponsors.
Will a failed proof attempt change the ledger or charge DUST?
A proof attempt which fails before submission does not change ledger state or consume a transaction fee. The transaction was constructed locally but never broadcast, so no partial result appears on-chain. The wallet or application can restart the proving attempt if its configuration remains supported. Distinguish that local failure from a completed transaction which reached the network and was rejected for another reason.
May the same token switch between shielded and unshielded form?
A token is either shielded or unshielded at the protocol level; it does not switch states automatically. If an application needs movement between private and public representations, its smart-contract logic must define the relevant behavior. That application-specific path still requires compatible wallet methods, address roles and proofs. Do not treat an unshielded balance display as evidence the wallet can perform a shielded operation.
Does Midnight use a gas auction to prioritize transactions?
Midnight does not use a gas auction or a priority-by-price mempool. DUST cost reflects computational and storage demands plus network usage, while validators select transactions for block efficiency. A higher wallet balance does not buy a faster queue position through a bid. The amount required can still vary between actions, so the connected wallet must have enough DUST for the transaction being prepared.
When is Cardano-held NIGHT ready to generate DUST?
Cardano-held NIGHT can support DUST generation after the relevant account is explicitly registered and a Midnight DUST address is designated. The registration flow submits a Cardano transaction, so the active Cardano account needs enough ADA for that network fee. Registration applies to the active account's stake key rather than every account in the wallet, making account selection part of the compatibility check.
Why does hardware support for NIGHT not prove dApp compatibility?
Holding NIGHT in a hardware wallet does not prove the device can authorize a Midnight dApp operation. The mainnet launch configuration did not include hardware-wallet support for Midnight, and any later integration must be checked for the exact wallet, environment and action. A companion wallet also needs the expected connector, address role and proving path.