Midnight and the Dual State Model: How to keep sensitive app data private while publishing verifiable proofs
Midnight outlines the Dual State Model: keep private state off-chain while publishing cryptographic proof that verifies transitions without revealing secrets.
Why the Dual State Model matters for application privacy
The Dual State Model reframes how developers think about on-chain systems by separating what must remain secret from what the network needs to verify. Midnight uses this model to describe an application architecture in which a Private State holds sensitive inputs and a Public State contains only the cryptographic artifacts required to prove that those private inputs satisfied a rule. That separation lets applications preserve confidentiality — for example, of medical records, identity attributes, or internal business inputs — while still publishing verifiable outcomes such as commitments, nullifiers and proof verifications. The result is a workflow in which the network verifies cryptographic evidence of a fact, rather than receiving the raw data and trusting a backend’s assertion.
Private state and public state: two complementary layers
In the Dual State Model the application is split into two distinct layers. The Private State is the full working data set that must remain confidential: exact birthdates, membership files, legal documents, private witness data and any internal logic inputs. These values are retained by the client or the application’s private components and are not published to the chain.
The Public State contains only the verifiable outcomes needed by the wider system: commitments that bind a proof to hidden values, nullifiers that prevent reuse, verification keys and state-transition markers. The Public State intentionally omits the private values themselves — it needs only proof that the circuit’s rules were satisfied. In plain terms, the chain plays the role of a public notary that checks whether a provided proof meets a specified legal standard; the notary does not require the underlying private file.
How the Dual State Model changes the flow of trust
Conventional application architecture follows a simple pattern: a client sends raw data to a backend; the backend enforces rules and writes results to a database. The Dual State Model replaces that flow with one focused on cryptographic verification: the client retains the raw data, computes a proof locally using proving logic, and submits only the proof plus minimal public inputs to the chain. The network then verifies the proof and records only the verification artifacts. This transforms trust from a centralized backend assertion to a network-level cryptographic check.
Architectural roles: circuit, verifier, commitment, nullifier
The model’s components can be mapped to concrete concepts:
- Circuit: the formal definition of what constitutes a valid state transition — the “legal standard” that must be met.
- Verifier: the on-chain or public logic that checks the submitted proof against the verification key and public inputs.
- Commitment: a cryptographic binding of private data to a public value, typically produced as a hash of private data plus randomness.
- Nullifier: a one-time-use marker derived from private identity material and an action scope that prevents replay or double claims.
These elements ensure that the public layer can confirm that rules were satisfied without learning the underlying secrets.
Design decisions developers must make
When adopting the Dual State Model, engineering teams typically define four core artifacts:
- Private witness model — Decide which attributes stay secret. The Private State holds user attributes, financial details, internal records and any private witness needed by the proving circuit.
- Public verification model — Specify what must be visible for correctness: commitments, nullifiers, proof objects, policy identifiers and timestamps.
- Circuit rules — Precisely define the facts the circuit will prove: range checks, signature validity, valid state transitions, set membership, or compliance constraints.
- On-chain verifier logic — Determine the contract or network actions after verification: mint an asset, approve an action, update a commitment registry, mark a nullifier as spent or reject a replay.
Each of these definitions constrains the scope of what the client proves and what the chain stores, and they must be aligned to avoid leaking private information while maintaining verifiability.
Common data structures and their purposes
The Dual State Model relies on a small set of recurring cryptographic constructs:
- Commitment: a hash that binds private data to a public value (commitment = hash(private_data, randomness)). Commitments allow later verification without revealing the underlying values.
- Nullifier: a one-time marker derived from private identity material and an action scope (nullifier = hash(identity_secret, action_scope)). Nullifiers prove correctness of singular actions while preventing repeat use.
- Public inputs and verification keys: the minimal data the verifier requires to check a proof, such as the commitment value, the nullifier and a current timestamp or policy identifier.
Treat these structures as the only things that should appear on the public ledger; they are the bridge between private computations and public verification.
End-to-end example: a benefit claim without revealing identity
A simple example from the Dual State Model illustrates the flow. A patient wants to prove three facts without exposing private details:
- They are over 18.
- They are a member.
- They have not already claimed the benefit.
The client holds the Private State — birthdate, membership ID and membership secret — and generates two public artifacts: a commitment for the membership and a nullifier for the benefit-claim action. The client builds public_inputs that include a current date, the membership_commitment and the nullifier, then generates a zero-knowledge proof locally by executing a benefit-claim circuit with the private witness and the public inputs. The transaction submitted to the chain contains only the proof and public_inputs; the chain runs verify_and_execute(transaction) and, if verification succeeds, records the approval and marks the nullifier as spent.
That pattern — generate commitment, compute nullifier, produce proof locally, submit proof plus minimal public inputs, have the chain verify and act on the verification outcome — is the canonical Dual State flow.
Practical mapping from traditional backend thinking to dual-state engineering
Translating existing development instincts into the Dual State Model is straightforward if you map roles directly:
- Traditional: client sends raw data → server checks permissions and rules → server writes result.
- Dual-state: client keeps raw data → client/prover computes proof locally → chain verifies proof → chain records only verifiable outcome (commitment, nullifier, verification result).
Reframing the backend’s responsibilities into a proving role and a public verification role clarifies which components must be private and which must be public.
Circuit design: narrowing the proof target
A successful circuit design focuses on minimality: prove only what is necessary. Developers should define precisely what fact the circuit must attest to (for instance, “user is over 18 and belongs to membership set X and has not previously claimed”), rather than encoding broad business logic. Narrow proof targets reduce public inputs, limit surface area for leakage and make replay prevention simpler.
Key circuit design questions include:
- What should remain private? Only keep private what is necessary for the business and compliance goals.
- What fact needs verification? Keep the proof target narrowly scoped.
- What prevents replay? Use a nullifier or spent-note mechanism tied to the action scope.
- What binds the proof to state? Commitments bind claims to specific private values.
- What is the observable public outcome? Define whether the chain will approve an action, update a commitment, mint an asset or mark a nullifier.
Answering these questions early will keep circuits modular and maintainable.
Developer pitfalls to avoid
The source lays out several common mistakes that can undermine privacy or correctness:
- Proving too much: Packing many disparate business rules into a single large circuit increases complexity and may expose more public inputs than necessary. Prefer modular circuits focused on individual transitions.
- Exposing unnecessary public inputs: If a value does not need to be public for verification, do not publish it.
- Forgetting replay protection: A valid proof without nullifier logic can be replayed. Always include a one-time-use marker or spent-note mechanism where appropriate.
- Confusing encryption with proof: Encryption hides data, but zero-knowledge proofs attest to facts about data without revealing it; they are complementary but distinct.
- Treating on-chain state as a normal database: The public ledger should hold verification artifacts — commitments, nullifiers, timestamps — not the application’s private model.
Recognizing and avoiding these mistakes helps preserve both privacy and the integrity of state transitions.
Operational considerations and developer tooling
The Dual State Model requires developers to implement local proving logic and a compact on-chain verifier. Local proving typically runs on the client or in a trusted private environment where private witnesses and secrets are available; the chain runs only the verifier and commitment registry logic. The model implies a development workflow where circuits are authored and tested locally, devs define the private witness schema, and the public verifier interface is kept intentionally small.
For teams looking for implementation resources, Midnight’s Developer Hub is presented as a central location for materials required to engineer privacy with Midnight. The Hub connects developers to training (the Academy), ecosystem expertise (Aliit Fellows), technical documentation and open-source repositories intended to help deploy smart contracts and integrate the Dual State approach into production systems.
How the Dual State Model affects application design and developer responsibilities
Designing with dual-state changes the division of labor in engineering teams. Backends shift away from storing and asserting sensitive facts; instead, developers must define proving circuits, manage private witness models and implement secure local proof generation. On-chain contracts focus on verification and recording the minimal public artifacts that represent state transitions. This redistribution of responsibilities requires new competencies — circuit specification, threat modeling for public inputs and careful handling of secrets used to derive nullifiers and commitments.
Broader implications for businesses and users
Adopting the Dual State Model has implications beyond implementation details. For businesses, it enables a clearer separation between compliance-required public records and confidential customer data, which can support privacy-by-design strategies across applications that must prove regulatory or contractual conditions without disclosing sensitive records. For end users, keeping full records off-chain while providing verifiable attestations reduces the attack surface tied to ledger visibility. From an operational perspective, organizations that retool their backend and contract layers for dual-state verification may find new pathways to balance transparency and confidentiality.
Integration patterns and where to apply the model
The Dual State Model is applicable where a verifiable fact is required but the underlying evidence must remain private. Typical use cases include age or membership checks, one-time benefit claims, authorization flows that must avoid exposing identity details, and any transition where the public record needs only a commitment and a stamp (nullifier) rather than raw documents. The approach is especially relevant where replay prevention and binding proofs to specific private values are defensible requirements.
Testing, auditing and replay protection
Because the public layer stores only verification artifacts, testing and auditing must cover both the private proving logic and the public verifier. Tests should validate that circuits enforce the desired constraints given private witnesses, and that the verifier accepts valid proofs while rejecting manipulated inputs. Replay protection requires validating that nullifiers are unique and monotonically consumable; auditors should verify that the nullifier derivation and the verifier’s spent-note logic cannot be bypassed.
Developer checklist for a Dual State implementation
A practical checklist distilled from the model:
- Define exactly which values remain private and why.
- Specify public inputs and ensure they are minimal.
- Design small, focused circuits for each transition.
- Implement nullifier logic for each one-time action.
- Keep commitments and verification keys immutable where appropriate.
- Test proof generation and on-chain verification end to end.
- Audit the public inputs for possible information leakage.
Following these steps helps reduce common mistakes and maintain privacy guarantees.
Midnight’s Developer Hub is described as a resource to find instructional material, expert support and source code to implement these patterns. Teams using the Hub can map the conceptual model into concrete circuits, verifier contracts and deployment workflows.
The Dual State Model reframes typical application trust assumptions by moving raw data out of the public ledger and relying on cryptographic proof for correctness; it demands disciplined design of circuits, commitments and nullifiers, and it shifts certain responsibilities to developers who author and audit those proofs.
Looking ahead, the Dual State Model points to architectures where privacy and public verifiability coexist: private witnesses and proving logic remain under developer control, while commitments and nullifiers become the compact public language of state changes. As more teams adopt modular circuit design and explicit nullifier schemes, it is likely we will see richer toolchains and repositories that standardize common proof patterns and verifier interfaces, enabling broader adoption of privacy-preserving verification across applications.
