Midnight network
Midnight network transactions require input checks before approval and record validation after submission
Midnight network transaction approval should begin only after the wallet, network identifier, intended effect and spendable inputs match the request. The wallet then balances token movements and supplies the required proofs before submission. When configured to pay the fee, it also adds the required DUST spend. When the wallet presents an approval prompt, treat it as the final user-controlled boundary. After submission, use the transaction record to distinguish a relayed request from confirmed execution and finalized state.
Wallet and network compatibility determine whether a transaction can proceed
Transaction availability depends on a compatible wallet API, an exact network match and permission to perform the requested operation. The connected network identifier should match the environment selected by the application. The connector version must also fall within the range the application supports. A connected label confirms the session, but it does not prove the wallet can balance or authorize the proposed transaction.
Wallet state must be synchronized before coin selection begins. The wallet needs spendable inputs for the intended token movement and current DUST outputs capable of covering the calculated fee. Holding NIGHT does not by itself prove DUST is ready. NIGHT holdings must be registered to generate DUST for a designated DUST address. The available resource depends on the current value of unspent DUST outputs associated with that address.
Address compatibility belongs in the same check. Unshielded, shielded and DUST addresses serve different roles, so an address valid for one role is not interchangeable with another. The wallet should reject a network mismatch or unsupported request before the user reaches a meaningful approval decision.
Approval decision checklist
- Confirm the connected network identifier matches the intended environment.
- Check each recipient uses the address type required by the operation.
- Read the token type, amount and contract effect presented for approval.
- If the wallet pays the fee, compare the calculated fee with its spendable DUST rather than its NIGHT balance.
- Continue only if the balanced request still matches the intended action.
Preparation ends before submission begins
The application or wallet first prepares the intended effect, such as an output or contract action. A Compact contract call can use public ledger data and private witness data during local execution. Zero-knowledge proof generation demonstrates the required conditions without placing the raw private witness on the public ledger. At this stage, the proposed state change still lacks network acceptance.
The wallet then completes the parts tied to its own state. It selects eligible inputs and creates change outputs to balance the required token movements. When configured to pay the fee, it also adds the required DUST spend; otherwise, the designated fee payer must add it. Adding inputs or outputs can increase the fee, so a preliminary estimate may differ from the balanced request the wallet ultimately presents.
A transaction returned from the wallet for submission should be cryptographically bound and contain the required proofs and authorizations. Submission is still a separate operation. This separation matters because a prepared request, an approved request and a relayed transaction represent different boundaries. Only the later record shows whether the network included and executed it.
The approval view is the commitment boundary
Every on-chain transaction requires a zero-knowledge proof because paying its DUST fee is a shielded action. Approval should apply to the balanced transaction rather than an earlier skeleton. Review the final effect and every operation-specific detail the wallet exposes, including any recipient, token amount and DUST requirement. If any essential detail changed during balancing, reject the request and rebuild it. Wallet interfaces may present these fields differently, but approval does not establish inclusion or finality.
A transaction record separates relay from finality
The connector history model distinguishes pending, confirmed, finalized and discarded transaction states. Pending means the transaction was sent but is not yet known to be included or discarded. Confirmed means it appears on-chain without finality. Finalized means inclusion reached the final state reported by the wallet, while discarded means the transaction failed to enter the chain.
Confirmed and finalized records carry execution results for the transaction's intents. Check those results when a transaction contains contract actions because inclusion alone does not prove every fallible action succeeded. For an operation expected to change public contract state, compare the resulting ledger field with the intended change. A transaction identifier helps locate the record, but the identifier alone is not completion evidence.
Private state needs a different check. It remains on the user's device or in the wallet rather than appearing in a public transaction record. The public record can prove inclusion and expose permitted execution results without revealing the private witness. Validation therefore combines the network status with the expected public effect and any local private-state update relevant to the application.
A missing record points back to the wallet request
When approval ends without a transaction record, begin with the connector response instead of repeating the action. A Rejected error represents a one-time refusal, such as declining after reviewing the cost. PermissionRejected indicates the wallet denied access to that operation for the session. InvalidRequest points to malformed or incompatible data, while Disconnected means the wallet connection was lost.
Without a history entry or submission response, there is no evidence the network received the transaction.
For a one-time rejection, compare the intended effect with the balanced request before opening another approval. A session-level permission refusal needs a permission decision rather than repeated prompts. If the connection was lost, restore the correct network session and read fresh wallet state before rebuilding anything.
Sending the same invalid payload again does not correct its inputs or compatibility.
Rebuild an invalid or expired request from synchronized state, a current cost model and spendable inputs. Any changed amount, recipient, contract action or selected input changes the statement being authorized, so the associated proof and binding must also be regenerated. Once a new record reaches pending status, stop using the approval-recovery path and validate that record instead.
Shielded, unshielded and DUST inputs play different roles
Shielded inputs rely on commitments, nullifiers and zero-knowledge proofs. Unshielded inputs identify UTXOs and carry authorization signatures, while a DUST action pays the fee and commits to its successor output. The connector does not give an application direct access to raw shielded coins or unshielded UTXOs. It asks the wallet to produce an effect-specific transaction instead. A finalized record can prove execution status, but it cannot reveal private data intentionally kept local.
Common questions about Midnight network
Why can the DUST requirement rise during balancing?
Balancing can add token inputs, change outputs and DUST spends, each of which affects the transaction's resource cost. The fee model also accounts for computational and storage impact alongside network conditions. The wallet therefore recalculates the requirement while completing the transaction. Compare the final DUST amount presented for approval with the spendable DUST outputs, not with an estimate shown before balancing.
Does wallet approval expose private contract inputs?
Approval does not make private witness data public on the ledger. A Compact contract can use private inputs locally, while a zero-knowledge proof demonstrates the relevant condition without revealing the underlying value on-chain. If the wallet supplies the proving provider, however, it can receive proof preimages containing the private data the proof hides. The approval interface may show the intended public effect and fee, but presentation varies. Validate the visible action and check the proving arrangement separately from the public transaction record.
When does partial success appear in a Midnight transaction record?
Partial success can occur when the guaranteed section succeeds but one or more fallible sections fail. The successful intent identifiers or execution-status entries show which parts completed. If the guaranteed section fails, the fallible sections do not execute. Check the execution results of a confirmed or finalized record before treating a multi-action contract transaction as fully completed.
Why can a second request fail after the first one used the same DUST output?
A DUST output can be spent only once, so two concurrent requests cannot rely on the same output. The first spend creates a successor output, which must become available before it can fund another transaction. A wallet with several eligible unspent DUST outputs may support parallel requests by selecting different outputs. Refresh wallet state before retrying instead of resubmitting the conflicting transaction unchanged.