DEV Community: Cory Dabrowski

Certifying something on-chain without revealing it: privacy attestation on Midnight

Cory Dabrowski — Sat, 27 Jun 2026 01:03:22 +0000

I built Grid Audit, a tool that reviews Midnight code and then lets you certify that review on-chain. The thought behind this was to help assist people with reviewing what code they have created. But then my original thought grew: how do you record on a public ledger that an audit happened, by an authorized auditor, over a specific report, without publishing the report and without exposing the auditor's key?

That turns out to be a general Midnight pattern, and this post walks through the small contract that does it.

The problem

You want a public, tamper-evident receipt that says "this exact thing was reviewed and signed off." But:

The report itself is private. It should never touch the chain.
Only the real auditor should be able to publish a receipt. No impersonation.
Anyone should be able to verify a receipt later, without learning the report or the auditor's secret.

On a transparent chain you would have to publish the report or trust an off-chain server. On Midnight you can do it with two primitives: witnesses and commitments.

The contract

Here is the whole registry. It is small, which is the point.

pragma language_version >= 0.23;
import CompactStandardLibrary;

// Public ledger state.
export ledger ownerCommitment: Bytes<32>;            // H(auditorSecret), set once at deploy
export ledger receipts: Map<Bytes<32>, Bytes<32>>;   // receiptId -> H(reportFingerprint)
export ledger published: Counter;

// Private inputs (witnesses). Supplied by the prover, never written to the ledger in the clear.
witness auditorSecret(): Bytes<32>;
witness reportFingerprint(): Bytes<32>;

// Bind the registry to the auditor's secret at deploy. Stores only the commitment, never the secret.
constructor() {
  ownerCommitment = disclose(persistentHash<Bytes<32>>(auditorSecret()));
}

export circuit publishReceipt(receiptId: Bytes<32>): [] {
  // Access control: re-derive H(secret) in-circuit and require it to match the commitment.
  assert(persistentHash<Bytes<32>>(auditorSecret()) == ownerCommitment, "not the auditor");

  assert(!receipts.member(disclose(receiptId)), "receipt already exists");

  // Only the commitment to the private report fingerprint is stored.
  receipts.insert(disclose(receiptId), disclose(persistentHash<Bytes<32>>(reportFingerprint())));
  published.increment(1);
}

Pattern 1: in-circuit secret-knowledge auth (not ownPublicKey())

The access control here is the important bit. At deploy, the constructor stores ownerCommitment = H(auditorSecret). The secret stays in the auditor's wallet. To publish, publishReceipt re-derives H(auditorSecret()) from the witness inside the circuit and asserts it equals the stored commitment.

The proof convinces the chain that the caller knows the secret, without the secret ever being disclosed. An observer sees only the commitment and the proof, never the secret, so nobody can impersonate the auditor.

This matters because the obvious habit from other chains, gating on the caller's public key, does not work on Midnight. ownPublicKey() is witness-sourced, so it is not a trusted caller identity and can be spoofed. The correct pattern is exactly this: make the caller prove knowledge of a secret in-circuit against an on-chain commitment.

Pattern 2: a commitment to a private value

The report never goes on-chain. The auditor computes a reportFingerprint (a hash of the report) locally, and the circuit stores only H(reportFingerprint) as the receipt value. Later, anyone holding the report can recompute the fingerprint, hash it, and check it against the stored commitment, proving the receipt matches that exact report. The chain learns that a report was certified, not what it said.

The one assumption that makes this safe

persistentHash only hides inputs that are hard to guess. This contract is safe because auditorSecret and reportFingerprint are high-entropy: a random 32-byte secret and a hash. If you tried this same pattern with a low-entropy input, say a four-digit code or a yes/no value, the published hash would be brute-forceable and the privacy would evaporate. For low-entropy values you need a commitment with a fresh secret salt instead of a bare hash. Here the inputs are already high-entropy, so a plain hash is fine. Knowing which case you are in is the whole game.

What you end up with

A public registry where:

Only the holder of the auditor secret can publish, proven in zero knowledge.
Each receipt commits to a private report without revealing it.
Anyone can verify a receipt against a report they hold.
The auditor's secret and the report contents never touch the chain.

Wrapping up

This is a small contract, but it is a reusable shape: prove authorization by secret knowledge, and publish commitments instead of data. Any time you want an on-chain record of something private, this is the pattern to reach for.

The full project is here: Grid Audit on GitHub. It pairs this registry with a reviewer that flags Midnight-specific privacy and security traps, so you can review your Compact code and then certify the result on-chain, privately.

What actually stays private on Midnight! (A builder's mental model)

Cory Dabrowski — Wed, 17 Jun 2026 04:12:55 +0000

Intro

Coming from the XRPL, the challenge for me has been grasping what actually stays hidden on a privacy chain and how they acomplish that. On a transparent ledger, you always know what is public, because everything is. On Midnight the answer is not obvious, and getting it wrong is exactly how supposedly private data leaks.

Here is the mental model I use. Once it clicked, most of my privacy mistakes stopped.

Three places your data can live

On Midnight, every value in a contract sits in one of three places, and the place decides who can see it:

Witness data: private inputs that never leave the user's device.
Ledger state: public, on chain, visible to everyone forever.
Disclosed values: things you deliberately move from private to public with disclose().

Get these three straight and most privacy bugs disappear.

1. Witnesses: the private inputs

A witness is a value the contract receives from the user's local environment. It feeds the zero-knowledge proof, but it never goes on chain.

import CompactStandardLibrary;

// A private input. The prover knows it. The chain never sees it.
witness getBalance(): Bytes<32>;

The key idea: a proof can depend on a witness without revealing it. A contract can prove "the balance is at least 100" while nobody learns the balance. And anything derived from a witness is also treated as private by the compiler, which matters in a minute.

2. Ledger: the public state

Ledger fields are the opposite. They are stored on chain and readable by anyone.

// Public state. Everyone can read this, now and forever.
export ledger balance: Bytes<32>;

If a value reaches a ledger field, it is public. Full stop. There is no private ledger. So the only interesting question is how a private witness ever gets into a public ledger field. It does not, unless you say so.

3. disclose(): the deliberate door

Midnight will not let you move witness-derived data into public space by accident. If you try, the compiler stops you:

export circuit recordBalance(): [] {
  balance = getBalance();   // compiler error: undeclared disclosure
}

You have to open the door on purpose with disclose():

export circuit recordBalance(): [] {
  balance = disclose(getBalance());   // ok: you declared the disclosure
}

disclose() does not encrypt or protect anything. It is a declaration: I know this value came from private data, and I am choosing to make it public. That is the entire point. Disclosure is an explicit, auditable decision, not something that happens to you.

This is the mental flip from transparent chains. There, everything is public unless you do extra work. Here, everything private stays private unless you deliberately disclose it.

Where it gets people: the boundary is sticky

The trap is that "derived from a witness" spreads. The compiler tracks it through arithmetic, type casts, function calls, even conditionals.

witness getBalance(): Uint<64>;

export circuit balanceExceeds(n: Uint<64>): Boolean {
  return getBalance() > n;   // compiler error: the boolean still leaks the balance
}

Returning whether the balance exceeds n is not safe just because you did not return the balance itself. The comparison result is derived from private data, so the compiler still makes you disclose() it. That is the feature working. It forces you to notice that even a yes or no answer is a disclosure.

A subtler leak: disclosing is not the same as hiding

Here is the part that bites even careful people. The compiler treats some standard library routines as safe to disclose. A commitment, transientCommit or persistentCommit, is treated as not containing witness data, so you can publish it without a disclose() wrapper.

But the compiler allowing it is not the same as it being secret. If you commit or hash a value that has only a few possible inputs, anyone can brute-force it:

// looks safe, is not: a yes/no vote has only two possible hashes
recordedVote = disclose(persistentHash<Field>(localVote()));

An observer hashes 0 and 1 and instantly knows the vote. The fix is a commitment with fresh secret randomness:

witness voteSalt(): Bytes<32>;   // fresh, secret, never reused

recordedVote = persistentCommit<Field>(localVote(), voteSalt());

The salt is the real secret. Same value plus a fresh salt gives a different, unguessable output. The compiler will not verify the salt is actually fresh or secret. That part is on you.

A checklist before you ship

Before any circuit goes out:

Is it a witness, or derived from one? Then it is private, and the compiler will fight you if you leak it. Good.
Does it land in a ledger field, or get returned from an exported circuit? Then it is public. Did you mean that?
Is there a disclose() in the path? Then stop and ask: is this value low-entropy or guessable? If so, use a commitment with a fresh salt, not a bare hash.
Did I reuse a salt anywhere? Identical inputs make identical commitments, which links them. Fresh salt every time.

That is the whole model. Three buckets, one deliberate door, and a hard look at anything going through it.

Closing

Privacy on Midnight is not magic, and it is not something you just assume happens.

The way I look at it is simple.

Midnight gives builders privacy by default, but there is still a door you choose to open when something needs to be revealed.

Private logic, public rails: Pairing Midnight's ZK privacy with XRPL settlement

Cory Dabrowski — Thu, 11 Jun 2026 04:32:46 +0000

Building on XRPL has taught me one thing fast: public rails are powerful, but not every part of the app should be public.

I can put settlement, payments, tokens, escrows, and wallet flows on-chain all day. That part makes sense. But the second you are dealing with identity, eligibility, compliance checks, customer data, private business logic, or anything sensitive, you hit a wall. You do not want that sitting out in public forever.

Public ledgers made trust programmable, but that transparency cuts both ways. On the XRP Ledger, every amount, address, and balance is out in the open. That is exactly what you want for settlement, and exactly what you cannot have for sensitive business logic.

The argument of this post is simple:

You should not have to choose between public settlement and private logic.

Use Midnight for the private half.
Use XRPL for the public half.
That gives you both.

Two halves of one problem

Most on-chain apps are really dealing with two different problems at the same time.

One side is settlement.

That means moving value fast, cheap, final, and in a way people can audit.

The other side is private logic.

That means proving something is true without exposing all the data behind it.

Most chains force you into one lane. Either everything is public, or you move to a privacy setup and lose some of the settlement rails, liquidity, and ecosystem you already have.

I do not think it has to be that way.

What XRPL is great at

XRPL is my home base, and the strength is obvious once you build on it.

It is fast.
The fees are tiny.
Settlement is final.
The native DEX is already there.
Issued tokens are built into the ledger.
Escrow, payment channels, trust lines, and wallet flows are all part of what makes XRPL useful for real apps.

That is why I like building on it. You can move value without needing a bunch of extra layers just to do basic things.

But XRPL does not give you privacy.

Everything is public by design.

For settlement, that is a feature.

For customer data, business logic, compliance decisions, identity checks, or private financial data, that becomes a problem fast.

What Midnight adds

Midnight brings in the private side.

Midnight is a zero-knowledge data-protection chain, built as a Cardano partner chain, where privacy is the default. Data only becomes public when you choose to disclose it.

The important pieces are:

Zero-knowledge proofs: prove something is true without showing the private data behind it.
Private witness state vs. the public ledger: the sensitive inputs stay private.
Selective disclosure and viewing keys: show only what needs to be shown, to only who needs to see it.

The simple way to think about it:

Run the private logic on Midnight.
Publish only the proof.
Then use XRPL to settle.

Private logic, public rails

This is the pairing.

Split the app by what each chain is good at.

Confidential decision, eligibility, or private state goes to Midnight.

Final value movement goes to XRPL.

The flow looks like this:

Private inputs go into Midnight.
Midnight creates a ZK proof that the rules were followed.
The app takes that proof or token.
XRPL handles the payment or settlement publicly.

The honest caveat:

Right now, there is no native trust-minimized bridge between Midnight and XRPL. This is not a magic one-click bridge today. This is an application-layer pattern that the app coordinates itself.

Midnight's hybrid dApp direction points toward this kind of cross-chain future, but for now, this is something builders can prototype and design around at the app layer.

What the private half looks like

Here is a simplified Midnight / Compact-style example to show the pattern. The goal is not to ship a full contract here, but to show how private inputs, public ledger state, and selective disclosure fit together.

export ledger eligibleRoot: MerkleTreeDigest;
export ledger usedTokens: Set<Bytes<32>>;

witness credentialSecret(): Bytes<32>;
witness membershipPath(): MerkleTreePath<10, Bytes<32>>;

export circuit proveEligibility(): Bytes<32> {
  const secret = credentialSecret();
  const path = membershipPath();

  const commitment = persistentHash<Vector<2, Bytes<32>>>([
    pad(32, "elig:commit:"),
    secret
  ]);

  assert(path.leaf == commitment, "wrong credential");
  assert(merkleTreePathRoot<10, Bytes<32>>(path) == eligibleRoot, "not eligible");

  const token = persistentHash<Vector<2, Bytes<32>>>([
    pad(32, "elig:token:"),
    secret
  ]);

  assert(!usedTokens.member(disclose(token)), "already used");

  usedTokens.insert(disclose(token));

  return disclose(token);
}

Here is what matters.

The witness values are private inputs. That means the credential secret and the membership path are not being posted publicly.

The Merkle check proves the user is part of the eligible set, but it does not reveal which user they are.

That is the important part.

The app can prove, "this person is eligible," without exposing their identity, their credential, or the private data used to check them.

The only thing disclosed is the one-time token.

That token works like a nullifier. It proves this eligibility check has been used once, and it prevents the same private credential from being reused over and over.

So the public chain gets the proof reference.

It does not get the private data.

What the public half looks like

Now XRPL does what XRPL does best.

It settles.

In a real app, the eligibility token should be hex-safe before it goes into the XRPL memo.

const eligibilityTokenHex = eligibilityToken.toUpperCase();

const payment = {
  TransactionType: "Payment",
  Account: payer.classicAddress,
  Destination: RECIPIENT_ADDRESS,
  Amount: xrpToDrops("100"),
  Memos: [
    {
      Memo: {
        MemoType: Buffer.from("midnight:eligibility-token")
          .toString("hex")
          .toUpperCase(),
        MemoData: eligibilityTokenHex,
      },
    },
  ],
};

const prepared = await client.autofill(payment);
const signed = payer.sign(prepared);
const result = await client.submitAndWait(signed.tx_blob);

The XRPL transaction is public and auditable.

Anyone can see the payment happened.

Anyone can see the eligibility token attached in the memo.

But they do not see the private logic behind it.

They do not see the identity check.
They do not see the full customer data.
They do not see the private business rules.
They only see the public settlement tied to a valid proof reference.

That is the point.

Public rails. Private logic.

A concrete use case: private eligibility, public payment

This is where it gets real for compliance and audits.

Say an app needs to make sure someone is eligible before a payment happens.

Maybe they need to be KYC'd.
Maybe they need to not be sanctioned.
Maybe they need to be accredited.
Maybe they need to meet some internal business rule before they can claim, buy, settle, or receive funds.

On XRPL alone, you either expose too much or you handle the private side off-chain and ask everyone to just trust the app.

With Midnight added, the app can prove the user passed the check without leaking the actual data.

Then XRPL handles the payment.

If a regulator, auditor, or approved third party needs to review it, selective disclosure or a viewing key can give them access to exactly what they need.

Not the whole world.

Just the right party.

That is the difference.

This is not privacy to hide from compliance.

This is privacy that can work with compliance.

Compliant AND confidential.

That is the lane I think matters.

How a developer would build this flow

At the app level, the flow would look something like this:

Create an eligible-user set off-chain.
Store the Merkle root publicly on Midnight.
Keep each user's credential secret private.
Let the user generate a Midnight proof that they are in the eligible set.
Disclose only the one-time eligibility token.
Attach that token to an XRPL payment memo.
Let the app, auditor, or verifier connect the XRPL payment back to the Midnight proof reference.

The key part is that the private data never needs to touch XRPL.

XRPL only sees the settlement and the proof reference.

Midnight handles the private check.

That gives you a cleaner split:

Midnight proves the private rule was followed.
XRPL proves the public payment happened.
The app connects the two.

This is also why the one-time token matters.

Without it, someone could try to reuse the same eligibility proof again and again. With the token/nullifier pattern, the app can tell that the private credential was already used without learning who the user is.

That is a useful pattern for claims, gated payments, allowlists, private compliance checks, and other flows where you need proof without exposing the full dataset.

Why both beats either

XRPL alone gives you fast, liquid, low-cost settlement.

But it does not give you privacy.

A privacy chain alone gives you confidentiality.

But then you may lose the XRPL settlement layer, liquidity, tooling, users, and ecosystem that already exist.

Together, the two make more sense.

Midnight handles the private proof.

XRPL handles the public settlement.

That gives builders a way to keep sensitive logic private without giving up auditability.

And that distinction matters.

Because real businesses do not want to dump sensitive data on-chain just to prove something happened.

But they also do not want black-box systems where nobody can verify anything.

The better model is selective proof.

Show what needs to be shown.
Hide what should stay private.
Still settle in public.

What it will take to make this real

The hard part is coordination.

If Midnight proves something privately and XRPL settles publicly, you need strong guarantees that those two actions stay tied together.

That means better bridge patterns, oracle models, proof verification flows, or atomic-style guarantees so the proof and the settlement cannot be split apart or abused.

That part is still early.

But I think this is exactly where serious builders should be looking.

Because the next wave of Web3 apps will not just be about putting everything on-chain.

It will be about knowing what belongs on-chain, what should stay private, and how to prove the difference.

Takeaway

XRPL gives us strong public rails.

Midnight gives us private logic.

Together, they point to a better pattern for real applications.

You do not have to trade away auditability to get confidentiality.

And you do not have to expose sensitive data just to prove the rules were followed.

Private logic.
Public rails.
That is the build path I want to see more people explore.