Nocturne

Humanitarian organizations need to prove that funds reached eligible people, but the usual evidence is a centralized recipient spreadsheet. That creates a dangerous bargain: the more accountable the program appears, the larger the surveillance and breach surface becomes. People seeking help should not have to trade dignity for assistance.

Nocturne starts from a different question: what is the smallest public fact an aid system actually needs? The answer is not a person's identity. It is proof that one approved credential made one valid claim in one campaign.

What it does

An approved issuer enrolls a one-way eligibility commitment. When a recipient claims aid, their device supplies the private credential values to a Compact circuit. The circuit proves membership, campaign state and capacity, then derives a campaign-scoped nullifier. Midnight rejects a reused nullifier, increments the public aggregate, consumes the commitment, and releases a shielded voucher.

The product includes:

a live relief-operations dashboard;

a guided four-step private claim journey;

public campaign totals and proof receipts;

a Privacy Lens for recipient, donor, auditor, and network-observer views;

Lace 4.x / PreProd connection logic;

a Compact 0.23 contract, witness adapter, Midnight.js API, browser providers, and policy tests; and

architecture, security, deployment, and judge-demo documentation.

How we built it

The smart contract is written in Compact 0.23. Private organizer and credential values enter through witnesses. persistentHash domain-separates organizer authorization, eligibility commitments, and per-campaign nullifiers. Public ledger state stores campaign parameters, aggregate counters, eligible commitments, and spent nullifiers—never recipient attributes.

The TypeScript protocol layer wraps generated bindings with Midnight.js deploy, join, observe, and circuit-call methods. The browser provider integrates the Midnight DApp Connector API, Lace 4.x, PreProd indexer endpoints, a local proof server, and shielded transaction balancing.

The responsive frontend is built with React/TypeScript and a custom visual system. Its guided demo computes the claim material locally and faithfully mirrors the contract state transition while clearly distinguishing demo mode from a funded wallet transaction.

Why Midnight is essential

On a transparent ledger, the data needed to establish eligibility can become a permanent targeting surface. A conventional database can hide that data but cannot give independent, cross-organization proof that claims were unique and valid. Midnight provides both properties: Compact computes over private witnesses, while the shared ledger verifies the resulting state transition.

Challenges we ran into

The hardest design problem was preventing duplicate claims without creating a global identifier. A universal recipient hash would let campaigns track the same person. We solved this by including the campaign ID in both the eligibility and nullifier domains, so uniqueness is enforceable within one relief pool but not linkable across pools.

We also treated privacy communication as a product problem. Instead of hiding the protocol in documentation, the Privacy Lens lets judges inspect exactly what each participant can and cannot see.

Accomplishments we are proud of

Accountability is public while recipient identity is not collected.

Duplicate prevention does not create a cross-campaign identity.

The full claim story is understandable in under one minute.

The interface makes a complex ZK system feel calm, humane, and operational.

The protocol, API, wallet connector, tests, security review, and deployment runbook are packaged together rather than presented as a visual mockup alone.

What we learned

Privacy is not simply removing fields from a database. The identifier design, domain separation, proof infrastructure, wallet boundary, metadata timing, and every disclose() call matter. Midnight's separation between private witnesses and public ledger state made those decisions explicit and reviewable.

What's next

Next we will add threshold enrollment across multiple trusted issuers, revocation accumulators, batched claim submission to reduce timing leakage, sponsored DUST so recipients never manage fees, and selective disclosure for a recipient-consented audit. A field pilot would begin with cash/voucher programs where duplicate prevention is necessary and disclosure risk is high.