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

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

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.