DEV Community: Tminus1sec base.eth

Building a .night domain profile viewer on Midnight with the Midnames SD

Tminus1sec base.eth — Fri, 24 Jul 2026 01:59:21 +0000

I'm a self-taught builder, and this week I built a small thing that made a concept finally click for me: a .night domain profile viewer. You type a name like tomin.night, it resolves on-chain, and it shows you the profile. This is the walkthrough — what a .night name actually is, the one SDK call that resolves it, the two gotchas that cost me time, and how I wrapped it into a tiny dApp.

Repo: https://github.com/tomiin/midnames-profile-viewer

What a .night name actually is

On Midnight, .night domains are managed by Midnames. The important part for a developer: the name registry is a Compact smart contract deployed on-chain. The @midnames/sdk package literally ships the compiled contract (it exports Contract, ledger, witnesses, and a MANAGED_DIR of Compact artifacts).

So "look up a domain" doesn't mean "call a company's REST API." It means read contract state. The domain, its owner, where it points, and its profile fields all live on the chain. That's the whole appeal: a .night name is a portable, on-chain identity you own.

The one call that does the work

Install the SDK (Node ≥ 22, ESM):

bash
npm install @midnames/sdk
npm pkg set type=module

Resolving a domain is two lines:

ts
import { createDefaultProvider, getDomainProfile } from "@midnames/sdk";

const provider = createDefaultProvider({ networkId: "mainnet" });
const result = await getDomainProfile("tomin.night", { provider });

if (result.success) {
console.dir(result.data, { depth: null });
} else {
console.error(result.error); // e.g. DomainNotFoundError
}

The SDK returns a result object with a success flag — no try/catch gymnastics for the "domain doesn't exist" case, which is nice.

What comes back

Here's the real shape of result.data for my domain (trimmed):

js
{
fullDomain: 'tomin.night',
info: {
id: 142n,
owner: '0e3240f66410...a9f36a6694',
ownerAddress: 'mn_addr1vglt...w63s8cp7sd',
target: {
type: 'shielded',
address: 'mn_shield-cpk1...nvxdys3gwdtn'
},
targetLocked: false
},
fields: Map(4) {
'epk' => 'mn_shield-epk1...',
'profile_type' => 'personal',
'discord' => 'Uetto',
'Zealy' => 'tminus1sec'
},
settings: { coinColor: Uint8Array(32) [...], costs: {...}, buyEnabled: false }
}

Two things jump out:

target — the address the name points to, like a DNS record but for wallets. Mine resolves to a shielded address. So a wallet could let you "pay tomin.night" and quietly turn it into that address, instead of anyone copying 60 hex characters.
fields — arbitrary key/value profile data (discord, socials, a profile_type, whatever you set). This is the identity layer.
Gotcha #1: which network is your domain on?

This one cost me real time. The Midnames SDK supports two networks, mainnet and preprod. I first ran a script against preprod and got:

DomainNotFoundError: Domain not found: tomin.night

The domain wasn't missing — it was registered on mainnet, and I was querying preprod. The tell is in the addresses: a mainnet owner address looks like mn_addr1..., while preprod is mn_addr_preprod1.... So point the provider at the network your domain actually lives on:

ts
const provider = createDefaultProvider({ networkId: "mainnet" }); // not "preprod"
Gotcha #2: the SDK returns real JS types, not JSON

Look again at that result: id is a BigInt (142n), coinColor is a Uint8Array, and fields is a Map. If you JSON.stringify that to send it to a browser, it throws on the BigInt and mangles the Map. So I wrote a small serializer:

js
function serialize(v) {
if (typeof v === 'bigint') return v.toString();
if (v instanceof Uint8Array) return Buffer.from(v).toString('hex');
if (v instanceof Map) return Object.fromEntries([...v].map(([k, val]) => [k, serialize(val)]));
if (Array.isArray(v)) return v.map(serialize);
if (v && typeof v === 'object') {
const o = {};
for (const [k, val] of Object.entries(v)) o[k] = serialize(val);
return o;
}
return v;
}
Wrapping it in a dApp

I kept the architecture boring on purpose: the SDK runs in a tiny Node/Express backend (where it's happiest — no browser polyfills), and a plain HTML/JS page calls it and renders the card.

js
import express from 'express';
import { createDefaultProvider, getDomainProfile } from '@midnames/sdk';

const app = express();
app.use(express.static('public'));

const providers = {};
const providerFor = (net) => (providers[net] ??= createDefaultProvider({ networkId: net }));

app.get('/api/resolve', async (req, res) => {
const domain = String(req.query.domain || '').toLowerCase();
const network = String(req.query.network || 'mainnet').toLowerCase();
const result = await getDomainProfile(domain, { provider: providerFor(network) });
if (!result.success) return res.status(404).json({ error: result.error?.message });
res.json({ domain, network, data: serialize(result.data) });
});

app.listen(5173, () => console.log('http://localhost:5173'));

The front end is just an input, a network toggle, and a fetch to /api/resolve that renders the owner, the resolved target, and the profile fields. No wallet connect, no login — resolving a name is a public read.

Run it
bash
git clone https://github.com/tomiin/midnames-profile-viewer
cd midnames-profile-viewer
npm install
npm start

open http://localhost:5173

Takeaways
A .night name is an entry in an on-chain Compact contract you own — resolvable to an address plus a bag of profile fields. It's a genuinely nice identity primitive.
Reading it is one SDK call; the friction is all around it: pick the right network, and serialize the rich JS types (BigInt / Uint8Array / Map) before they hit a browser.

Code: https://github.com/tomiin/midnames-profile-viewer

MidnightForDevs

Midnight sprint: a sealed-bid auction, a stubborn error 170, and everything it taught me"

Tminus1sec base.eth — Sun, 19 Jul 2026 01:46:51 +0000

I'm a self-taught builder, not a career dev. I lean on AI to help me a lot when my syntax breaks and explanations are rather verbose, I read a lot of
docs, and I break things constantly. So this is a build story from that seat — the
Midnight Expert sprint, everything I shipped, and every wall I hit getting there.
If you're also learning this stuff, the messy parts below are the useful parts.

The whole sprint ran through the Midnight Expert plugins inside Claude Code
— a marketplace of AI agent plugins for the Midnight blockchain (Compact contracts,
DApp frontends, toolchain, an error-code lookup, and more). I installed it there,
ran the diagnostics, and did the contract + tooling work from that setup. The
finishing and debugging happened in a mix of Claude Code and Claude's desktop
agent, but the Midnight-specific muscle came from those plugins.

What I shipped

A Compact smart contract — a sealed-bid auction with a real nullifier: https://github.com/tomiin/midnight-sealed-bid-commit-reveal
Deployed it to Midnight Preprod with a live on-chain interaction (contract address is in that repo's README).
A PR back to the Midnight Expert repo improving an error-code entry I'd just spent hours living inside.
(Bonus, same journey: a from-scratch CLI wallet — https://github.com/tomiin/midnight-cli-wallet — which is where I accidentally learned the fix that unblocked everything else.)

Getting set up (the easy 10-XP wins)

First three quests were the warm-up: explore the marketplace, star the repo, and
install + run diagnostics. In Claude Code that last one is a single command:

/midnight-expert:doctor

It checks your compiler version, tooling, and MCP servers and tells you what's
green. Mine flagged that my Compact compiler had upgraded (0.30 → 0.31.1) and a
couple of harmless warnings. Good baseline before touching anything real.

Quest 1 — Writing a Compact contract

The idea: a sealed-bid auction. While bidding is open, nobody — not other
bidders, not even the auctioneer — can see what anyone bid. When bidding closes,
people reveal their numbers, the contract checks each against what was locked in
earlier, and the highest honest bid wins. Think sealed envelopes: shut while you're
bidding, opened at reveal time.

The part I actually wanted to get right was the nullifier. Compact has no
msg.sender — there's no built-in "who's calling." So a caller proves who they are
by knowing a secret key that never leaves their machine, and the contract derives a
one-way fingerprint (a nullifier) from it. Two details make it real: it's
domain-separated (tagged "sbid:v1:nullifier" so it can't be confused with any
other hash from the same key), and it's the double-bid guard (your commitment is
filed under your nullifier, so a second bid collides and bounces). One identity, one
bid, and your identity never hits the chain.

I wrote it with the compact-core plugin, compiled it, and got a passing test suite
before going anywhere near a network. The honest boundary, which a lot of "private"
demos skip: the bid amounts are private while bidding is open, but the
nullifiers and commitments are public — that's what makes the anti-double-bid check
work.

Quest 2 — Ship and deploy it (a.k.a. the error 170 saga)

This is where I lost a night, so buckle up. The quest wants the contract deployed to
Preprod (a public test network) with at least one real on-chain interaction.

My deploy CLI would build the transaction, prove it, submit it — and the node would
spit back:

1010: Invalid Transaction: Custom error: 170

Every single time. Error 170 is InvalidDustSpendProof. Here's the thing I didn't
understand at first: on Midnight you don't pay fees with the main token (NIGHT). You
register NIGHT to generate a fee resource called DUST, and every transaction
proves a little DUST spend to cover its fee. 170 is the fee leg getting rejected
— nothing to do with my contract.

I assumed it was the test network being slow (a Midnight dev even confirmed that
version of it happens when the public indexer lags behind the node). So I tried the
other public network, Preview. Its faucet's human-check spun forever and then locked
me out for 24 hours. Two public networks, two different dead ends, same night.

So I did the thing that actually cracked it: I stood up a local devnet with the
midnight-tooling plugin — a node and indexer in Docker, right on my machine, with
zero lag between them. And it still threw 170. That was the lightbulb. If a chain
that's perfectly in sync with itself rejects my transaction too, the problem isn't
the network — it's my code.

Three things had to be fixed, in order:

1. Rebuild the transaction on every retry — don't resubmit the same one. My retry
loop was resubmitting the exact same proven transaction each time. But a 170's
stale DUST proof is baked into that transaction, so re-sending it just re-presents
the same dead proof. On a chain minting blocks every few seconds, it's stale the
instant it's built. The fix was to rebuild and re-balance the whole thing on each
attempt so every try carries a fresh proof:

Attempt 1: building (fresh dust balance), proving, submitting…
  attempt 1 failed: Transaction submission error   (that's the 170)
Attempt 2: building (fresh dust balance), proving, submitting…
Transfer submitted. Tx: 0087338e7833176e...c008fe3d

Attempt two, fresh rebuild, straight through. (I found this on the wallet first, then
carried it to the deploy.)

2. Keep the wallet's DUST synced to the current tip. Even with the rebuild loop,
if the wallet's DUST state is hours behind the chain it can't even balance the fee —
you get instant "could not balance dust" failures instead of 170. My deploy wallet
was restoring from a checkpoint saved earlier in the day. I re-synced it to the
current tip first, then deployed.

3. Use a strong local password. Once the DUST was sorted, the deploy got all the
way to storing private state and died with PasswordValidationError: Password must contain at least 3 of: uppercase, lowercase, digits, special. Found: 2. The SDK now
enforces that on the local private-state store. Bumped my dev password to four
classes and moved on.

And then, finally:

✅ DEPLOYED. Contract address: ad08e233a172874748b05ab40a30c9217699650115aa5650c3c671accfee4244
Placing one sealed bid (on-chain interaction)…
✅ placeSealedBid submitted.

Live on Preprod, with a real interaction. After all that, it went through on the
second attempt.

Quest 3 — Extend Midnight Expert

The Extend quest wants a real PR back to the midnight-expert
repo. I had the perfect thing,
because I'd just been inside the exact gap.

The repo has a midnight-status-codes plugin — a searchable catalog of every
Midnight error code. I looked up 170, and its only suggested fix was:

"Regenerate the dust spend proof using the proof server"

Which is exactly the trap I'd fallen into. Re-proving or resubmitting the same
transaction can never clear a 170 — that's the whole lesson I'd just paid for in
hours. So I expanded the entry with the remediation that actually works: sync the
DUST to the tip, rebuild-don't-resubmit on 170, and the practical tell (instant
"could not balance dust" = too stale to balance, resync; a 170 after proving = the
block-advance race, which rebuilding rides through).

Their repo has a schema check and a test suite, and both pass with the change:

Schema check PASSED
Results: 14 passed, 0 failed
All checks passed.

Small, genuine, and something I could only have written by living through it.

What I'd tell past-me

A retry only helps if the next attempt is different from the one that failed. For a dropped connection, resend. For a rejected proof, rebuild. I'd copied a retry that resent, and it couldn't have worked no matter how many times it ran.
When a public network keeps telling you "it's infra," reproduce it somewhere you fully control. The local devnet turning "the chain is broken" into "my code is wrong" was the single most useful move of the whole sprint.
Read the real state, not the tutorial's idea of it. The SDK moves fast; half my walls were things that had quietly changed shape since the docs were written.

Links

Sealed-bid auction (contract + deploy CLI + the full roadblocks writeup): https://github.com/tomiin/midnight-sealed-bid-commit-reveal
CLI wallet: https://github.com/tomiin/midnight-cli-wallet
Midnight Expert marketplace: https://github.com/devrelaicom/midnight-expert

If you're learning Midnight too: the concepts are genuinely different (DUST fees,
nullifiers, no msg.sender), but none of the walls I hit were exotic. They were
stale state, flaky endpoints, and a fast-moving SDK. Reproduce, rebuild, and don't
trust "it's infra" until you've seen it fail somewhere you own.

Privacy isn't encryption: what building on Midnight actually taught me

Tminus1sec base.eth — Tue, 07 Jul 2026 10:11:39 +0000

When I started building on Midnight, I had the wrong mental model, and I suspect
most people arriving from "normal" blockchains have it too. I assumed a privacy
chain meant my data would sit on-chain, encrypted, and only the right people could
decrypt it. A lockbox on a public ledger.

That model is wrong. And if you design around it, you'll build the wrong thing.
Here's what actually clicked for me after building a few contracts, including a
privacy-preserving health-records system.

Encryption and zero-knowledge are different tools

They get lumped together, but they solve different problems.

Encryption hides bytes. You scramble data so only someone with the key can
read it. The catch: whoever has the key sees everything. And "encrypted, on a
public ledger, forever" is a liability, not a feature. Keys leak. Keys get lost.
And a ciphertext that sits on-chain for eternity is a standing bet that today's
encryption survives tomorrow's computers.

Zero-knowledge proves statements. It lets you show that something is true —
"I'm over 18," "this vote is valid," "I'm the assigned doctor" — without
revealing the underlying data at all. No key handed over, nothing decrypted. The
sensitive part never has to be shown to anyone.

So privacy on Midnight is not "encrypt the data and put it on-chain." It's almost
the opposite: keep the sensitive data off the ledger entirely, and put only
proofs and commitments on it.

The real model: selective disclosure

The idea that runs through everything on Midnight is selective disclosure. You
choose exactly which facts become public, and everything else simply never touches
the chain. A couple of examples from things I built:

A tip jar where the running total is public — so it's trustworthy — but each donor is recorded only as a one-way hash. The chain never learns who gave.
A vote where the tally is public but the voter is a nullifier. Reveal the count, hide the identity.

Notice what's not happening: nothing is "encrypted and then decrypted later." The
private part is never on-chain in any form. That's the whole point.

Where the misconception really bites: health records

I built an access-control contract for medical results, and it's the perfect place
to see the wrong model fail.

If you believe "privacy = encrypt on-chain," you'd try to store encrypted lab
results on the chain and build a key-management scheme around them. You'd spend all
your time on the vault. And you'd have put the most sensitive data humans produce
onto a public ledger forever.

Here's what I built instead:

The result stays encrypted off-chain. The chain holds only a commitment — a one-way hash of it. Tamper-proof, but it reveals nothing.

// the lab posts only the HASH of the (off-chain, encrypted) result
resultHash.insert(disclose(recordId), disclose(resultCommitment));

Identity never goes on-chain. A caller proves they hold a secret key — a private witness — and all the chain ever stores is a hash of it.

witness localSecretKey(): Bytes<32>;              // private, never disclosed

export pure circuit accountId(sk: Bytes<32>): Bytes<32> {
  return persistentHash<Vector<1, Bytes<32>>>([sk]);   // one-way
}

The chain enforces the rules: only the assigned doctor with the patient's
consent gets routine access; an emergency responder can break the glass, but
every override is logged for audit. None of that needs the data — it needs
proofs.
And you can still prove a result is the genuine one, without the chain ever
seeing it:

export circuit verifyResult(recordId: Uint<64>, candidate: Bytes<32>): Boolean {
  return resultHash.lookup(disclose(recordId)) == disclose(candidate);
}

The chain never sees your data. It enforces the rules about your data, and keeps
an honest audit trail. The data itself stays where sensitive data belongs — off
the public ledger.

The design lesson

Once I stopped thinking "hide the bytes" and started thinking "prove the facts,"
the designs got simpler and better:

Don't put sensitive data on-chain, even encrypted. Put proofs and commitments on-chain; keep data off-chain.
Let the chain be the referee — rules, consent, audit — not the vault.
Compact makes this explicit whether you like it or not: the disclose() keyword forces you to opt in every time you make something public. You can't accidentally leak private data; you have to choose to reveal it. That constraint is a gift.

The honest boundary

Midnight isn't magic, and pretending otherwise is how you ship a demo that
overpromises. The encryption and key management for the actual data still happen
off-chain with ordinary cryptography. What Midnight adds is the layer on top: the
proofs, the rules, and the audit. Being clear about that line is the difference
between a real design and a pitch.

The takeaway

Privacy on Midnight isn't a lockbox on the chain. It's proving the truth while
keeping the data to yourself. Once that clicked, I stopped trying to hide bytes and
started asking a better question: which facts actually need to be public? Answer
that, put only those on-chain as proofs, and let everything else stay private by
never being there in the first place.

midnight #zero-knowledge #privacy #blockchain #selective-disclosure

Why your Midnight contract "can't be found on chain" (or: Midnight, stop playing with my emotions)

Tminus1sec base.eth — Fri, 26 Jun 2026 01:48:18 +0000

I'm a self-taught learner grinding through the Midnight quests, and this week the chain and I had a little falling out. I deployed a contract, got an address back, submitted it like a proud parent at a recital, and got served four of the saddest words in Web3: "cannot find contract on chain."

My code was fine. I just didn't understand Midnight's networks and tokens yet, and a tutorial I trusted shipped me off to a network that doesn't exist anymore.

So before we get into it: Midnight team, I love you, you're literally building the future of privacy, but quit teasing those of us out here learning. As the song goes - my feelings, don't play with them.

Okay. Map time. This is the thing I wish someone had handed me on day one.

Midnight is not one network (plot twist)
The first thing that got me: "Midnight" isn't a single place. There are a few networks, and they do not talk to each other:

A local one. You run a node, an indexer, and a proof server on your own machine with Docker (people call it "standalone" or "undeployed"). Everything here lives only on your computer.
Preview. A public test network.
Preprod. Another public test network, and the one a lot of the current quests and tutorials point you at.
Mainnet. The real one.
"It works on my machine" is the oldest excuse in software, and on Midnight it's sometimes literally true. My contract was absolutely on chain. The chain was just my laptop.

Oh, and there used to be a network called testnet-02. It has been retired. It is gone. But a lot of older tutorials and example repos were written for it and still point right at its ghost.

The trap: old tutorials point at a network that left the chat
testnet-02 walked so the newer networks could run. Then it kept walking, straight out of existence. Following an older tutorial that targets it is like pulling up to the function at last year's address: lights off, cups gone, nobody's coming.

Here's what actually bit me. I forked an older example dApp, followed its instructions to the letter, deployed, and my contract was nowhere. When I finally opened the project's config, every address pointed at the dead network:

indexer = 'https://indexer.testnet-02.midnight.network/api/v1/graphql'
node = 'https://rpc.testnet-02.midnight.network'
Those URLs are tombstones. So before you run any older Midnight project, open its config and check which network it targets. A quick way to sniff it out:

grep -rn "midnight.network" --include=*.ts .
If you see "testnet-02" or an old path like "/api/v1," back away slowly. The live networks today are reached through "indexer.preview.midnight.network" and "indexer.preprod.midnight.network" on a newer API version. If a repo hasn't been touched since testnet-02 was alive, it probably won't land anywhere you can verify, no matter how clean your code is.

"Cannot find contract on chain": the two usual heartbreaks
Once the networks clicked, the error finally made sense. When a quest checker (or another human) can't find your contract, it's almost always one of these:

You deployed to your local network. The address is real, but it lives on your machine and nowhere else. (See: "works on my machine.")
You deployed against a dead or wrong network, so it never landed anywhere a live explorer can see.
The fix for both is the same: deploy to a live public network (Preview or Preprod), then confirm it in a public explorer before you submit the address anywhere. If you can't find it in an explorer, the checker won't either. Trust, but verify - and in Web3, verify twice.

Tokens: NIGHT, DUST, and their test-network twins (please stop trying to buy anything)
Confession: I went hunting for the NIGHT token on an exchange so I could deploy a contract. Like a clown. You do not buy anything to build and test. But the token setup confused me for a minute, because there are four names floating around, not two. Here's the simple version:

NIGHT is the real, mainnet token - staking and governance, and it's what generates the fee token.
DUST is what actually pays transaction fees. You don't buy it; you generate it by holding and registering NIGHT.
On a test network, both have free stand-ins: test NIGHT (tNIGHT) and tDUST. They mirror the real pair exactly.
So the real flow for testing is: get free test NIGHT from the faucet, register it for DUST generation, and that produces the tDUST that pays your fees. You hold the NIGHT, the DUST drips out of it over time, and none of it costs you a cent.

Here's the part that humbled me: I had 1000 test NIGHT sitting in my wallet, staring at "you have no DUST for gas," wondering who hurt me. The answer was me. I hadn't registered the NIGHT yet, so no DUST was being generated. Rookie move. NIGHT in the wallet is potential energy; you have to register it before the fees actually flow.

The other catch that gets everyone: set your wallet to the Preprod network BEFORE you copy your address. Hand the faucet a mainnet address and it'll look at you like "I don't know her," even though it's the same wallet.

The proof server (somebody's gotta do the math)
Every Midnight transaction needs a zero-knowledge proof, and something has to actually do that homework. That something is a "proof server." You either run one yourself locally in Docker, or you use a wallet that does the proving for you (the 1AM wallet does this "dust-free," so you can skip the Docker dance). If your deploys or DUST registration just hang there spinning, the proof server and your network config are the first suspects.

Big shoutout to Gutopro, who already wrote the Preprod survival guide for the exact faucet-and-sync headaches that come next - linked at the bottom. Standing on the shoulders of devs who suffered first.

A short checklist before you deploy (so the chain stops ghosting you)
Pick your network: local for solo testing, Preview or Preprod for anything others (and quests) need to see.
Open the project config and confirm it targets that live network, not testnet-02 or an old API path.
Fund your wallet with free test NIGHT from the faucet (wallet set to that network first), then register it so DUST starts generating.
Make sure a proof server is available, local in Docker or via a dust-free wallet.
After deploying, find your contract in a public explorer. There? You're golden. Not there? You're on local-only or a dead network.
Wrapping up
Honestly, this is still the most fun I've had while being completely confused. Privacy tech on the frontier comes with a few battle scars, and that's part of the charm. Midnight team: I'm not mad, I'm just... also a little mad. But mostly grateful, and mostly having a blast. Just, you know - don't play with my tDUST.

If you're just starting out: the networks are separate, old repos may point at a dead one, and you fund testing with free test tokens, not your wallet. Get those three straight and you'll save yourself the afternoon I lost.

Built on, and learning with, the Midnight community.

Further reading: "Troubleshooting Midnight Pre-Prod: A Week in the Trenches" by Gutopro for the Midnight Aliit Fellowship - https://dev.to/midnight-aliit/troubleshooting-midnight-pre-prod-a-week-in-the-trenches-2g4d

Learning Midnight: nothing goes public by accident

Tminus1sec base.eth — Mon, 22 Jun 2026 13:26:58 +0000

I'm a self-taught enthusiast poking around the Midnight Network, and I wanted to write down one thing that finally clicked for me this week. Maybe it helps someone else who's just starting out.
Midnight is a privacy blockchain, and you write its smart contracts in a language called Compact. Coming in, I assumed "privacy blockchain" meant everything is hidden by default and you flip a switch when you want to share something.
It's actually the other way around, and that surprised me.
In Compact, anything you want to put into the public, on-chain state you have to mark on purpose, with a keyword called disclose(). If you forget, the compiler stops you. It won't let you publish a value unless you've clearly said "yes, I mean to make this public."
The first time I hit that, it felt annoying, like extra typing for no reason. Then it clicked: that IS the privacy model. Nothing leaks by accident. You go line by line and decide exactly what crosses from the private side to the public side. Everything you don't disclose just stays private.
That made Midnight's whole "choose what you share, nothing more" idea real for me in a way the tagline never did.
To play with it, I built a tiny app: a proof-of-age gate. You prove you're over 18 without ever showing your birth year. The birth year stays private the whole time; the only thing that becomes public is a simple "yes, this person qualifies." Same idea, share the one fact that matters and keep the rest to yourself.
Still very early in my journey, but this one stuck with me. Most of what I picked up came straight from the docs at docs.midnight.network.
Repo, if you want to peek: https://github.com/tomiin/midnight-proof-of-age