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.
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.
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.
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
. The SDK now
contain at least 3 of: uppercase, lowercase, digits, special. Found: 2
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.
The Extend quest wants a real PR back to the midnight-expert repo. I had the perfect thing,
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.
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.