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

A developer built a sealed-bid auction smart contract on the Midnight blockchain using the Midnight Expert plugin suite within Claude Code. The contract uses domain-separated nullifiers for privacy and double-bid prevention, and was deployed on a local devnet after persistent 'Error 170' fee issues on public test networks. The developer resolved the error by running a local node with zero lag between indexer and node.

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 https://github.com/devrelaicom/midnight-expert . 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.