DEV Community: Tminus1sec

You Cannot Leak What You Never Collected

Tminus1sec — Fri, 04 Sep 2026 15:00:36 +0000

On 1 September 2026, KrebsOnSecurity reported that a dark web service was selling scans of more than 153 million driver's licences from the US and Canada, alongside identity cards, travel documents and medical cards.

The reporting traced the likely source to an identity verification vendor that processes over 21 million verifications per month across 20,000+ locations. The operators claimed they had been exfiltrating continuously for over a year. The FBI has opened an investigation.

I want to skip the outrage and look at the architecture, because the architecture is the story.

The shape of the failure

Consider what each verification event actually needed to establish:

Car rental: this person holds a valid licence, and is the person on it
Cannabis dispensary: this person is over 21
Alcohol delivery: this person is over 21
Hotel check-in: this person is who they claim to be

Every one of those is a predicate. A boolean. The answer is one bit.

What was transmitted and retained instead: name, address, date of birth, document number, portrait, signature, issue and expiry dates, plus infrared and ultraviolet captures of the physical document.

A one-bit question was answered with a multi-megabyte artefact, which was then persisted by a third party.

That persistence is the vulnerability. Not the network perimeter, not the access controls, not whatever the forensic firm eventually finds. Those are proximate causes.

The root cause is that a system was designed so that verification implies collection.

Why this class of data is uniquely bad

Credentials have a rotation story. Passwords get changed, keys get rotated, tokens expire. The blast radius of a leak is bounded by how fast you can rotate.

Identity documents have no rotation story.

Date of birth is immutable
Biometric portrait is effectively immutable
Address history is append-only
Even reissuing a licence gives you a new number attached to the same underlying person

So the correct mental model for a leaked ID scan is not a compromised credential. It is a permanent capability grant to anyone who buys it.

And the reporting notes the data includes people in witness protection and people who have fled domestic violence, for whom the threat model is not financial.

The minimisation argument, stated precisely

A system cannot lose data it does not hold.

This sounds trite until you treat it as a design constraint rather than a platitude.

Under a collection model, your security posture is a function of every control you maintain, forever, across every vendor and subprocessor who touches the data. It degrades over time. It requires perpetual investment. It fails eventually, on a long enough timeline, for everyone.

Under a proof model, there is no data at rest to protect. The verifier's breach exposure for that class of data approaches zero, because the class of data was never created.

This is not a claim that proof systems are unbreakable. It is a claim that they move the failure mode from inevitable and catastrophic to bounded.

How verifying without collecting actually works

The primitive is a zero-knowledge proof: prove a statement is true without revealing the data that makes it true.

The practical flow:

A trusted issuer (DMV, bank, government service) verifies your identity once and issues a credential you hold on your own device
A verifier needs to check something specific
Your device generates a proof of that predicate only
The verifier checks the proof against the issuer's signature

Traditional:
  user ──[ full licence scan ]──> verifier ──> storage ──> breach

Proof-based:
  user ──[ proof: age >= 21 ]──> verifier ──> (nothing to store)

Prove age over 21 without revealing date of birth. Prove licence validity without revealing licence number. Prove residency without revealing address.

The verifier gets a cryptographically sound yes or no. It receives, and therefore stores, nothing else.

The privacy property is not policy. It is not a promise in a data processing agreement. The verifier cannot leak your date of birth because it never received your date of birth.

Where Midnight fits, and where it doesn't

I build on Midnight, so I'll declare the bias up front.

Midnight is a blockchain designed around this idea rather than retrofitted for it. It maintains separate public and private state, so sensitive data stays on the user's device and never reaches the chain. Its smart contract language, Compact, enforces the boundary at compile time. Attempting to move a private value into public state is a compilation error, not a lint warning:

potential witness-value disclosure must be declared but is not:
  witness value potentially disclosed:
     the return value of witness get_amount at line 8 char 1
  nature of the disclosure:
     ledger operation might disclose the witness value

That last detail matters more than it sounds. In most systems, data minimisation is a policy that a tired developer can violate on a Tuesday. Making it a compiler error changes who has to remember.

What I am not claiming: that this is deployed at rental counters today. It is not. There is no path right now where you present a ZK proof to a clerk with a document scanner and a vendor contract. The infrastructure gap is real and large.

The claim is narrower, and I think harder to dispute: the failure here was architectural, not operational. The alternative architecture exists and works. What is missing is the incentive to adopt it.

The incentive question

Collection persists because it is currently cheap and proof is currently expensive, in integration effort, not compute.

Three things change that calculation:

Liability. If holding identity documents becomes an uninsurable risk, holding them stops being free
Regulation. Data minimisation is already law in several jurisdictions, but enforcement targets breach response rather than collection design
Standards. Verification is a solved problem cryptographically and an unsolved problem in plumbing. Whoever makes the integration trivial wins

Engineers reading this have more leverage on the third than anyone else does.

The takeaway

The next time you specify an identity check, ask what predicate you actually need to satisfy. Then ask what you are about to store, for how long, and who inherits the liability.

If those two answers are wildly different sizes, you are building a honeypot. It may not leak on your watch. On a long enough timeline it leaks on somebody's.

153 million people answered a yes-or-no question by handing over everything.

The technology to just say yes already exists.

Six things I learned moving USDM between Cardano and Midnight

Tminus1sec — Thu, 03 Sep 2026 05:37:55 +0000

Notes from building a cross-chain USDM transfer app and a private invoice contract on Midnight. Enterprise addresses, explorer link rules, a node error code, and why a contract cannot hold USDM today.

I built two things on VIA's USDM cross-chain transfers over the past two weeks:

Tender — a browser app that moves native USDM between Cardano Preprod and Midnight Preview, both directions, signed by the user's own wallets.
Privoice — a private invoice contract in Compact, settling in USDM, deployed on Midnight Preview.

Eight transfers landed. One contract deployed with four on-chain interactions. Along the way I hit five things that are either not in the docs or are in the docs in a form that does not warn you about the consequence.

None of this is a criticism of VIA's documentation, which is good. It is the gap between "correctly specified" and "you will not guess this at 2am".

1. Your USDM arrives at an address your wallet will not show you

This one cost me a day, and I suspect it has cost other people their submissions.

Send USDM from Midnight to Cardano and it will not appear in Lace. The balance does not move. The transfer looks like it failed. It did not fail — the money is at an address your wallet does not watch.

Here is the mechanism, from VIA's own message spec. The VILR payload has fixed-width fields:

Offset	Width	Field
76	28	`source_depositor` — payment key hash of the depositor
136	32	`destination_recipient`

And the rule:

source_token, destination_token, and destination_recipient are each exactly 32 bytes. No shorter, no longer.

A Cardano base address is 57 bytes: a header, a 28-byte payment credential, and a 28-byte stake credential. It does not fit in 32 bytes. What survives is the payment credential — which is exactly what source_depositor is defined as.

Reconstruct an address from a payment credential with no stake credential and you get an enterprise address. Every time. By design.

So the spec is correct and complete, and the consequence — your funds land somewhere Lace does not display, and you will think the bridge ate them — is nowhere.

I built the derivation into Tender so the app shows both balances side by side:

Cardano Preprod        990.000000 USDM
  977.000000 at your wallet address
   13.000000 at your enterprise address

VIA export getEnterpriseAddress from the package, so they know. If you are building anything user-facing on this, derive it and show it.

2. VIA Scan needs `0x` on Midnight hashes and refuses it on Cardano ones

Same transfer, two URLs:

scan.vialabs.tech/tx/3c7daa78…9fda6034      →  Not found
scan.vialabs.tech/tx/0x3c7daa78…9fda6034    →  Delivered

A Cardano-source hash must be bare. A Midnight-source hash must be 0x-prefixed. Get it wrong and Scan tells you the transaction does not exist, on a transfer that completed.

And one more: VIA Scan opens on Mainnet. Every testnet message is invisible until you flip the network toggle.

That is three separate ways to conclude a working transfer failed. I wrote one helper and stopped guessing:

function viaScanHref(hash: string, fromMidnight: boolean): string {
    const h = fromMidnight && !hash.startsWith("0x") ? `0x${hash}` : hash;
    return `${VIA_SCAN}/tx/${h}`;
}

3. Testnet attests after one block. Mainnet is the fifty-minute one

The docs say it plainly, but it is easy to read the wrong row:

Validators wait for source-chain confirmations before attesting a message: 1 block on testnet, 150 Cardano blocks (≈50 minutes) on mainnet.

My fastest Preprod → Preview transfer delivered in 1 minute 52 seconds. So if you are on testnet and nothing has arrived after ten minutes, something is wrong — do not wait an hour because you saw "~55 min" somewhere.

Which is how I noticed the next thing.

4. A Compact contract cannot take custody of USDM on Preview today

Privoice was originally designed to pool USDM inside the contract, so amounts could be hidden outright rather than just unlinked. Before writing it, I tested whether that was possible.

I put two circuits in one contract — same deploy, same wallet, same DUST state, same block window — differing by a single line:

export circuit bump(): [] {
  bumps = (bumps + (1 as Uint<64>)) as Uint<64>;
}

export circuit deposit(color: Bytes<32>, amount: Uint<128>): [] {
  receiveUnshielded(disclose(color), disclose(amount));
  deposits = (deposits + (1 as Uint<64>)) as Uint<64>;
}

Contract c755041b16edcde0fb504e8967317d8de0cb2ef6a8593585877cd2a7e9c6e928 on Preview:

circuit	result
`bump()` — ledger write only	ACCEPTED
`deposit()` — ledger write + `receiveUnshielded`	REJECTED, `Custom(192)`

Six attempts, each rebuilt and re-proved from scratch rather than resubmitted, all rejected identically, about forty seconds after the control was accepted from the same wallet.

Decoding 1010: Invalid Transaction: Custom error: 192 matters here, so: 1010 is upstream Substrate and carries no Midnight meaning. The cause is the inner u8. Look it up in impl From<LedgerApiError> for u8 in midnight-node/ledger/src/versions/common/types.rs — not in a blog post, because the mapping changes across ledger versions.

MalformedError::InputsSignaturesLengthMismatch => 192,

192 sits in a run of four checks that are all specifically about unshielded inputs and outputs: InputsNotSorted (189), OutputsNotSorted (190), DuplicateInputs (191), InputsSignaturesLengthMismatch (192).

So Privoice settles at the application layer — the contract records that settlement happened and never touches the token. That is a measured constraint, not a design preference, and the README says so with both contract addresses.

Worth knowing if you are designing anything that wants a contract to hold USDM.

5. Unshielded inputs each need a signature, and forgetting it lands you on 192 too

Related, and the practical version of the above. When you move USDM wallet-to-wallet with the SDK, the recipe must be signed before it is finalised:

const recipe = await facade.transferTransaction(
  [{ type: "unshielded", outputs: [{ amount, type: USDM_TOKEN_COLOR, receiverAddress }] }],
  { shieldedSecretKeys, dustSecretKey },
  { ttl, payFees: true },
);

const signed    = await facade.signRecipe(recipe, (d) => keystore.signData(d));
const finalized = await facade.finalizeRecipe(signed);
const txId      = await facade.submitTransaction(finalized);

Skip signRecipe and the transaction reaches the node with fewer signatures than inputs — and you get Custom(192) again, from a completely different cause than the contract case above. Same code, same error, unrelated bug.

6. When the gateway stops, there is no other way to get USDM

USDM is minted on Midnight solely by VIA's cross-chain gateway delivering a
message from Cardano. No faucet, no other issuance path. Which means if that
gateway stops delivering, you cannot get USDM on Preview at all — and I found
that out with a submission deadline in front of me.

On 2 September I sent 10 USDM from my own bridge UI at 12:15 MDT. Nothing
arrived. An hour later I sent 1 USDM using VIA's own CLI as a control, to
rule out my code. Both sat at Awaiting Attestation.

The evidence said it was not me:

Both messages carried routing values matching VIA's published testnet table — chain ids 2273266 → 64364450, gateway 471dfe55…e73e485c, token colour 003bacd9…947d73
Both destinationRecipient fields decoded to my own address
Cardano Preprod was healthy — the tip was ~260 blocks past my lock
The docs say testnet attests after 1 block, and my 29 August transfer on the same route delivered in 1m 52s
On VIA's global message feed, the last delivered message on that route was ~24 hours old. Mine were the only two since.

Two independent clients, two package versions, ninety minutes apart, identical
failure. That is about as clean a "not my code" result as you get.

So I shipped anyway, and documented it. The payment leg is a parameter — one
32-byte token colour — so I ran the settlement with NIGHT instead, and the
README said exactly that: which token moved, which token the code defaults to,
why the substitution was necessary, and both stuck message ids so a reviewer
could check the claim themselves in thirty seconds.

The next morning both messages delivered — 16h 32m and 15h 4m. VIA's
scanner still labels those "normal". I re-ran the lifecycle with real USDM,
paying a second address rather than my own, and removed the substitution note
from the README, because it had stopped being true.

Two things I would take from that. Delivery time on Preprod → Preview is not
something to plan around — the documented rule is one block and I saw sixteen
hours. And when you are blocked by someone else's infrastructure, the move is
to make the blocker verifiable rather than quietly omit it. Naming it cost
nothing and would have survived review either way.

Two smaller ones, for whoever hits them next

DUST is not automatic. Holding NIGHT does not generate DUST. It must be registered. My wallet and my probe both read zero until I registered, and nothing tells you that is why.

The DUST wallet syncs separately, and far more slowly. Most sync helpers wait on state.unshielded.progress, which catches up in about a second — then declare success while dust sits at 42 of 183,000 events. A zero DUST balance in that state is correct, not a fault. Wait on state.dust.progress explicitly, and save a checkpoint afterwards or you pay the cold sync every run.

What I ended up with

Tender — eight transfers, both directions, three of them signed in Lace rather than by the service. Enterprise-address derivation and correct explorer links built in.

Privoice — a Compact contract where only persistentHash(amount, payer, memo, salt) goes on chain. The payer proves an invoice names them by reconstructing a commitment that matches, so identity is demonstrated rather than asserted. Deployed on Preview with issue → acknowledge → pay → settle, all four accepted.

Both repos have the full working code, the failed experiments, and the addresses to check any of this yourself.

If you are starting on this today: derive the enterprise address, put 0x on your Midnight hashes, register your NIGHT, and read error codes from types.rs. That is most of the day I lost, in one line.

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

Tminus1sec — 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 — 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 — 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 — 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 — 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

DEV Community: Tminus1sec

You Cannot Leak What You Never Collected

The shape of the failure

Why this class of data is uniquely bad

The minimisation argument, stated precisely

How verifying without collecting actually works

Where Midnight fits, and where it doesn't

The incentive question

The takeaway

Six things I learned moving USDM between Cardano and Midnight

1. Your USDM arrives at an address your wallet will not show you

2. VIA Scan needs 0x on Midnight hashes and refuses it on Cardano ones

3. Testnet attests after one block. Mainnet is the fifty-minute one

4. A Compact contract cannot take custody of USDM on Preview today

5. Unshielded inputs each need a signature, and forgetting it lands you on 192 too

6. When the gateway stops, there is no other way to get USDM

Two smaller ones, for whoever hits them next

What I ended up with

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

open http://localhost:5173

MidnightForDevs

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

What I shipped

Getting set up (the easy 10-XP wins)

Quest 1 — Writing a Compact contract

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

Quest 3 — Extend Midnight Expert

What I'd tell past-me

Links

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

The real model: selective disclosure

Where the misconception really bites: health records

The design lesson

The honest boundary

The takeaway

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

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

Learning Midnight: nothing goes public by accident

2. VIA Scan needs `0x` on Midnight hashes and refuses it on Cardano ones