DEV Community: spy

Phase 2 Open: Guardrails Relaxed, Federation Expanded

spy — Sat, 18 Apr 2026 17:35:33 +0000

NOTES: X Space today April 18, 2026:

Phase 2 Open: Guardrails Relaxed, Federation ExpandedDeployment restrictions are lifted and a broader validator/federation set is onboarded. This phase functions as the developer bridge between controlled environments and production effectively a Preprod-to-Mainnet transition layer.

Builders graduate from writing contracts to engineering production-ready, privacy-preserving systems where circuits, proofs, and applications must all be optimized, verified, and deployment-approved before hitting global execution.

You preprod environment will look like this:

Parallel network instance mirroring Mainnet conditions
End-to-end contract lifecycle execution (deploy → interact → upgrade)
ZK circuit validation, constraint optimization, and performance tuning

Followed by the deployment path:

Build and validate in Preprod
Perform internal risk assessment against defined rubrics
Submit artifacts for deployment authorization
Approved promote to Mainnet

The system role in Preprod operates as a circuit hardening layer, ensuring contracts and proofs are production-ready before incurring the cost of global verification.

What It Actually Means for Builders
1) From “Experiment” → “Pre-Production Reality”
Phase 2 is essentially the bridge between sandbox and real deployment.
You’re no longer just prototyping on preview/test environments
You’re building in a preprod system that mirrors Mainnet conditions
Your contracts, circuits, and UX flows are expected to behave like production systems.

In practical terms: You move from “does this work?” → “is this safe, efficient, and deployable?” This aligns with how Midnight positions itself as a production-grade privacy blockchain for real applications, not just experimentation.

2) The Core Shift: Circuits Become the Product
We already know that Midnight is fundamentally different from traditional chains, you’re not just writing smart contracts as discussed above, you are are designing zero-knowledge circuits + contract logic together.

Repos like:

the midnightntwrk/example-bboard and
OpenZeppelin-style starter stacks

…show that every deployable unit includes:

Contract logic (.compact)
Generated ZK circuits
Proof execution layer (proof server / runtime)

The expectations of this phase is the circuits must be optimized (constraints, proving cost, latency)and the proof generation is no longer optional it’s core infrastructure.

3) Full Lifecycle Testing (Not Just Deployment)
This phase introduces end-to-end contract lifecycle responsibility, you are expected to validate:

Deploy → interact → upgrade flows
Wallet + indexer + UI integration
Proof generation under real conditions (Docker proof server, etc.)

Yes! This is closer to shipping a full system, not just a contract.

4) The Emergence of a Real Dev Stack
From Midnight GitHub + docs ecosystem:

Contract layer → Compact language
SDK layer → MidnightJS / APIs
Infra layer → indexer, wallet, proof server
App layer → React / UI / CLI dApps

Notice you are building across the entire stack, not just one layer. This is why starter repos exist to show the expected architecture of real dApps. I totally believe this phase will go the quickest.

5) Preprod as a “Circuit Hardening Layer”
This is the most important conceptual shift this pahse introduces a gating model: Build → Test → Evaluate → Request Deployment

Before Mainnet, your system must:

Pass internal risk + correctness evaluation
Demonstrate circuit reliability and efficiency
Be ready for global verification cost (on-chain proofs)

This matters because ZK proofs are expensive → mistakes are costly and this phase ensures only production-grade logic reaches Mainnet.

6) What Changes for YOU as a Builder before Phase 2

Prototype circuits
Experiment with dApps
Learn flow
Builders must now have the ability to:
Design efficient ZK circuits (not just correct ones)
Treat contracts as verifiable systems
Build full-stack dApps (contract + proof + UI)
Prepare for deployment authorization (not automatic deploy)

7) Mental Model (Simple)
I think of this phase like Ethereum: Testnet → Mainnet and
Midnight: Preview → Preprod (Phase 2) → Mainnet. But with one key and obvious difference, Midnight adds cryptographic validation readiness as a gate.

When reasearching for this Space, I wondered what the Midnight Foundation's drive is during this phase. They are actually simultaneously pushing, open-source tooling, developer onboarding + challenges, and privacy-first application design.

The Foundation's goal is to turn builders into privacy-native system designers, not just smart contract devs, where that vision becomes enforced reality.

In conclusion, Phase 2 Mainnet means builders graduate from writing contracts to engineering production-ready, privacy-preserving systems where circuits, proofs, and applications must all be optimized, verified, and deployment-approved before hitting global execution.

What will you build?

Midnight Zero-Knowledge Briefing: Dual State Model Developer Walkthrough

spy — Sat, 18 Apr 2026 00:33:36 +0000

The easiest way for me to understand the Dual State Model is I had to stop thinking about what data do I send to the chain and start thinking in terms of what fact does the chain need to verify. In a dual-state system, your application is split into two layers Private State and Public State. Think of the Private State as just that private- where sensitive data lives. This would be things like medical records, identity attributes, legal documents, internal business logic inputs. Because this is private state it is not published on-chain.

The Public State is public where the verifiable outcomes live. This would be like commitments, nullifiers, proof verifications, state transition markers, and authorization results. The public layer does not need the underlying private data. It only needs proof that the rules were satisfied.

Think of it this way:

Private state = your full working file
Public state = notarized proof that the file satisfies required conditions
Circuit = the legal standard for what counts as valid
Verifier = the public notary
Nullifier = the stamp that prevents duplicate use

A conventional app says:

input data → backend checks rules → database stores result

A dual-state app says:

private data → local proving logic checks rules → proof sent on-chain → chain verifies result`

So instead of trusting the backend to say “yes, this is valid,” the network verifies cryptographic proof that it is valid.

Let’s put this to the test on a basic example where you are the patient wants to prove the following:

they are over 18
they are a member
they have not already claimed a benefit

without revealing:

exact birthdate
identity record
membership file contents

Here what the architect looks like:

┌──────────────────────────┐

│ Private Client │

│--------------------------│

│ birthdate │

│ membership credential │

│ private witness data │

│ proof generation │

└─────────────┬────────────┘

│

│ generates proof

▼

┌──────────────────────────┐

│ Public Chain │

│--------------------------│

│ verification key │

│ commitment registry │

│ nullifier set │

│ proof verification │

└──────────────────────────┘
Public inputs are the values the chain is allowed to see and verify against.

Example public inputs:

current_date = 2026-04-17 membership_commitment = H(member_id, membership_secret) nullifier = H(member_id, "benefit-claim")

Why these are public:

current_date is needed for age comparison

membership_commitment links proof to an existing commitment

nullifier prevents double use without revealing identity

Define the Circuit

A circuit is the rule system the prover must satisfy.

Recall this circuit must prove:

the user is at least 18
the commitment matches a real membership secret
the nullifier is correctly derived
the claim has not been used already

Circuit logic in plain English plaintext

Given private witness:
birthdate
member_id
membership_secret`

Given public inputs:
current_date
membership_commitment
nullifier

Prove that:
age(birthdate, current_date) >= 18
H(member_id, membership_secret) == membership_commitment
H(member_id, "benefit-claim") == nullifier

What Developers Need to Design

When building with a dual-state architecture, developers usually need to define 4 things:

Private witness model: What data remains secret? These are the user attributes, financial data, legal records, and internal app state items.
Public verification model: What must be visible to verify correctness? Commitments, proofs, nullifiers, policy identifiers, and timestamps are some examples.
Circuit rules: What exactly must be proven? This would include value is in range, signature matches, state transition is valid, user belongs to a set, record satisfies compliance constraints.
On-chain verifier logic: What does the contract/network do after proof verification? Some examples are mint asset, approve action, update commitment, mark nullifier spent, and reject replay.

Practical Developer Mapping

Here is the easiest way to translate existing engineering instincts.

Traditional backend thinking

client sends raw data server checks permissions server checks rules server writes result

Dual-State Thinking

client keeps raw data client/prover computes proof chain verifies proof chain records only verifiable outcome

Common Data Structures

Commitment

A cryptographic representation of private data.

commitment = hash(private_data, randomness)

Purpose:

bind proof to a specific hidden value
allow later verification without revealing the value

Nullifier

A one-time-use marker derived from private identity material.

nullifier = hash(identity_secret, action_scope)

Purpose:

prove correctness without exposing witness data

Full Flow Example

Here’s the end-to-end pattern in one block:

# Step 1: user has private state

private_state = { "birthdate": "2000-04-01",
"member_id": 847392,
"membership_secret": 928374928374
}

Step 2: derive public bindings

membership_commitment = hash(
private_state["member_id"],
private_state["membership_secret"]
)

nullifier = hash(
private_state["member_id"],
"benefit-claim"
)

public_inputs = {
"current_date": "2026-04-17",
"membership_commitment": membership_commitment,
"nullifier": nullifier
}
# Step 3: generate proof locally

proof = generate_zk_proof(
circuit="benefit_claim_circuit",
witness=private_state,
public_inputs=public_inputs
)
# Step 4: submit only proof + public inputs

transaction = {
"proof": proof,
"public_inputs": public_inputs
}
# Step 5: chain verifies

result = verify_and_execute(transaction)
if result:
print("Claim approved")
else:
print("Claim denied")

Here’s some things to consider when writing or thinking about the Circuit Design

What should remain private? Do not expose data just because it is available.

What fact actually needs verification? The proof target should be as narrow as possible.

What prevents replay? Usually a nullifier or spent-note mechanism.

What binds the proof to state? Usually commitments.

What is the public outcome? Approval, update, mint, transition, authorization, settlement.

Some Developer pitfalls to avoid:

Proving too much: Do not cram every business rule into one giant circuit unless necessary. Much better to keep circuits modular and prove only what matters for that transition.
Exposing too many public inputs If a value does not need to be public, do not publish it.
Forgetting replay protection A valid proof without nullifier logic can often be reused.
Confusing encryption with proof Encryption hides data. ZK proves facts about data. Those are not the same thing.
Treating on-chain state like a normal database The public side should store verification artifacts, not your whole private app model.

In conclusion the Dual State Model lets developers keep sensitive application state private while publishing cryptographic proof that state transitions are valid.

END

Visit Midnight’s Developer’s Hub! It connects you with everything required for engineering privacy with Midnight, from your first line of code to production. Use the Academy to get started, connect with Aliit Fellows for deep ecosystem knowledge and access technical documentation and open-source repos to deploy smart contracts. https://midnight.network/developer-hub

Midnight in Motion: How Builders Are Turning Privacy into Infrastructure

spy — Sat, 11 Apr 2026 16:37:50 +0000

From theory to execution here’s what recent builder activity reveals about the future of verifiable privacy.

Recent activity across the Midnight Network ecosystem signals a meaningful shift in how privacy is being developed, understood, and applied. What was once a conceptual promise privacy-preserving systems built on zero-knowledge principles is now being translated into practical design patterns by active builders. The most important development within Midnight is not a single release or announcement. It is the emergence of a new design paradigm, systems can now be built to prove what is true, without revealing what is private. As builders continue to refine and implement these patterns, Midnight is positioning itself not simply as a blockchain network, but as a foundation for privacy-preserving digital infrastructure.

This evolution reflects a broader Blockchain transition, privacy is no longer a theoretical feature, it is becoming programmable infrastructure. Emerging signals across builder programs from the ecosystem, technical discussions, and early-stage project exploration, several consistent themes are emerging. Midnight is the essential ecosystem hub go-to as privacy becomes programmable. As its core design of enabling systems to verify the truth without exposing underlying data, is increasingly being implemented at the application layer.

As a Midnight builder, I am actively working with zero-knowledge proof logic, selective disclosure mechanisms with dual-state architecture, the public and private execution. These are not abstract ideas. They are being operationalized into repeatable patterns for application development, with real-world use cases driving design in the typical systems: legal, healthcare, finance, government, education, and gaming.

The notable characteristic of current builder activity I have noticed is the focus on regulated, high-stakes environments, including the domains of i) Legal workflows (evidence validation, discovery processes); ii) healthcare systems (data access and consent management); and iii) financial services (verification without disclosure). These domains require both verifiable truth and protection of sensitive information. Midnight’s architecture is uniquely aligned with this requirement, enabling systems to meet compliance obligations without unnecessary data exposure. Government, education, and gaming domains intermingled.

As a normie a year into the cryptographic world it is quite clear that the builder culture must prioritize substance; taking it one further, looking to the solutions already built and how it might fit in my project build. Ecosystem programs and participation standards are reinforcing a clear expectation that contribution is measured by technical depth and implementation, not visibility alone. This is reflected in Midnight’s emphasis on documentation and clarity, development of tools and frameworks, and exploration of deployable use cases. The result is an ecosystem that is capability-driven, rather than narrative-driven. This matters because traditional blockchain architectures prioritize transparency, often requiring data to be publicly visible to achieve verification.

Midnight introduces a fundamentally different model of verification without exposure. This distinction enables a new class of systems where truth can be validated independently, sensitive data remains protected, and compliance and privacy are not in conflict. This is particularly relevant for industries where data sensitivity is not optional but required.

Conclusion

Current builder activity demonstrates that Midnight’s core principles are moving beyond theory and into practice. This progression, driven by technical contributors working at the intersection of privacy, verification, and real-world application, marks an early but significant step toward broader adoption. Midnight does not obscure systems. It enables them to function with precision revealing only what is necessary, and nothing more.

New B

spy — Mon, 20 Oct 2025 00:39:27 +0000

Currently in Web3 just crafted and filed DAO in Wyoming since they have already worked through legislation and policies.