Midnight 開発チームの皆様へ ── ご質問への回答To the Midnight Developer Team — Responses to Your Questions

Your "~2.5 months" estimate is about right. Roughly week by week:

• Weeks 1–2 | Setup: Stood up Claude Code and a Docker proof-server (port 6300) on Linux (WSL2). Wallet and DUST already in hand. Deployed my first Compact contract, gyotak-catch (exact GPS hidden as a private witness; species, origin, timestamp, photo SHA-256 in public state), to Preview.
• Week 3 | First wall = sync: Moving to Preprod, wallet sync took ~170 minutes every time (no LevelDB persistence). I implemented persistence and cut it from 176 min → 13 sec.
• Weeks 4–5 | The longest stall = mainnet deploy: Repeated failures with Substrate 1016 (Immediately Dropped). At first I concluded mainnet contract deploy "wasn't enabled yet" (based on the compatibility matrix listing only Preprod/Preview, no mainnet proof-server in DNS, etc.). But the real cause was different: the public RPC (rpc.mainnet.midnight.network) was dropping the deploy tx with 1016. Switching to the Foundation-provided RPC endpoint made the deploy succeed. Mainnet itself was working; I was effectively blocked by a public-RPC limitation. This burned the most time (~2 weeks).
• An environment trap | Node 22 required: The mainnet deploy required Node 22 (on Node 20, Set.prototype.difference (ES2024) is missing and it crashes). Another trap a non-engineer easily hits during setup.
• The trap that will reliably stop a non-engineer | the application channel was GitHub: Using mainnet required a prior application/registration — and I didn't know that application was filed on GitHub (issue/PR), not a web form. A non-engineer has no mental model of "applications happen on GitHub," so they stall right at the entrance. Exactly where the next zero-coder drops out.
• Week 6+ | Expanding the ZK circuits: Deployed the temperature ZK circuit gyotak-temp-log to Preprod (PASS/FAIL judgment, actual temperature kept secret), then the blend-ratio gyotak-ratio-log.
• After that | the cold-sync bug: tracked across 7+ sync runs on preprod (details in Q6). Reported in issues #425/#436 / servicedesk #52 → a core developer opened midnight-ledger#587.
• Finally | mainnet production: First deployed v1 at e88a2a00… (2026-05-31). Then, because Compact has no in-place schema migration — changing the contract structure requires redeploying at a new address — I deployed gyotak-catch v2 (5f87dd30…3741f7) to production (2026-06-04, block 1106629).

Summary: The biggest time sink was the ~2 weeks on mainnet deploy. The cause was that the public RPC was silently dropping the tx; I couldn't tell whether it was my mistake, a spec limit, or the environment, and for a while I even wrongly concluded "it isn't enabled yet" (actually solved by switching to the Foundation RPC). On top of that, the entrance itself — that mainnet use needs a prior application, filed on GitHub — was invisible at first, a wall a non-engineer can't see. The hardest part mentally was the next one, the cold-sync bug (Q6).
(Timeline cross-check: the Cloudflare business system was already running at ~400 files by early April 2026, while the first Midnight-related commit is late April 2026 — so "the commerce foundation first, Midnight second" is confirmed in the git history too.)

The order I connected things:

• ① Claude Code itself (physically split: Windows = Worker/GAS, Linux = Midnight)
• ② CLAUDE.md (the full project context as a file — the AI's "long-term memory"; set up first)
• ③ Official docs docs.midnight.network (primary source)
• ④ kapa.ai (official technical Q&A — to verify design feasibility)
• ⑤ The Midnight Code Assistant, connected to Claude Code as an MCP ← the decisive one. Compact-specialized. Just add it to .claude.json (the Claude Code config file).
• ⑥ GitHub improvement-proposals / issues (to ask the dev team directly)

The single most important thing for the starter kit is ⑤, the Compact-specialized MCP. Without it, Claude writes Compact "by guessing." Kimura-san (DevRel) gave me the URL for ⑤ while I was stuck on the mainnet deploy. The key point: it is not an endpoint for connecting to the Midnight chain — it is loaded into Claude Code as a knowledge source. Accuracy on everything Compact changed at that moment.

Yes — in fact it was the most important tool. I have midnightntwrk-expert.fly.dev wired into Claude Code directly as an MCP server. The important distinction: this is not a URL (RPC) for connecting to the Midnight chain — it is loaded into Claude Code as a knowledge source. Because Compact is barely present in mainstream AI training data, before connecting it I relied on guesses or doc lookups. After connecting it, Claude could write Compact while referencing the correct spec, and accuracy changed completely.

Kimura-san (DevRel) gave me the URL for this while I was stuck on the mainnet deploy. Claude pointed out that it was an MCP server and could be wired directly into Claude Code, so I added it to .claude.json (the Claude Code config file). So the setup was two wheels: my own context (CLAUDE.md) plus the official MCP (midnight.expert). Neither alone was enough.

My usual flow: ① form a hypothesis about the cause with Claude (chat) → ② verify with Claude Code → ③ cross-check against the official docs / kapa.ai → ④ for anything still unsolved, ask the dev team directly via GitHub issues / improvement-proposals.

Did I ever need a human? Yes, clearly — but not for "how do I use this" questions. It was when I hit a chain-side bug (the kind I can't fix myself). I reported the cold-sync bug in #425/#436/servicedesk #52, and discussed deployment models in improvement-proposals#96. kapa.ai and the MCP cleared the "knowledge wall"; GitHub issues cleared the "bug wall."

On findability: kapa.ai and GitHub issues were easy to find, kept a record, and got direct responses from core developers, so they were what I relied on most. Honestly, I barely used Discord/the forum.

And the most honest thing I want to convey: my single biggest enabler — the Compact-specialized MCP (midnight.expert) — I could not find on my own. I only reached it because Kimura-san (DevRel) personally told me about it, right when I was stuck on mainnet. Without it, I would very likely have stalled at the Compact wall. That is my number-one message to the Foundation — this decisive tool is hard to discover on your own, so it should be handed to everyone from the very first step of onboarding.

As early as 2026-04-22, I had publicly written in Discord (japan-chat) that I wanted an "official" Midnight MCP for vibe coders like me:

"I wish there was an official Midnight MCP for people like me who do vibe coding."— TAKU, 2026/04/22 (japan-chat). A week later, on 4/29, I followed with "Thank you for creating the MCP server."

In other words, the very layer you now say you want to grow (non-engineers / vibe coders) was, in my person, publicly asking for the official tool before it was in hand. I raised my hand on the demand side — but couldn't reach the decisive tool on my own; it only arrived through a DevRel's personal share. There's one conclusion: the demand is real. What remains is simply to hand it out in a form people can find from the start.

Handled well: The TypeScript/Node side was nearly flawless — SDK calls, wallet handling, LevelDB persistence, CI, Cloudflare Worker integration. The translation from "my words → technical spec" is also very strong.

Got wrong by guessing (the Compact/Midnight-specific parts absent from training data):

• Whether Compact's syntax and standard library could do certain things (folding over arrays, min/max, looping over a Vector) was unclear — I had to start each time with a "capability check."
• Library version consistency (e.g. ledger-v8: even with ^8.0.3 specified, npm resolved up to 8.1.0, causing a cross-version mismatch with the shared proof-server 8.0.3 — fixed by pinning to 8.0.3)
• The proof-server endpoint (I trusted a wrong URL in the official docs and got stuck).
• The real operational constraints of mainnet (e.g. the public RPC dropping the tx — operational pitfalls absent from training data, which it walked into and failed on repeatedly).

Conclusion: the root of all of it is that Compact + Midnight-specific SDK/infra knowledge is missing from the AI's training data. This stands in contrast to mainstream web tech (TypeScript / Node / SDK calls), which Claude implemented almost perfectly — the same AI splits this sharply on "present vs. absent in training data." The MCP connection improved things dramatically, but the latest behavior and known bugs still depend on humans / issues.

Where the documentation specifically tripped me up:

• The proof-server URL was wrong in the official docs (lace-proof-pub.preprod… is NXDOMAIN; the correct one is proof-server.preprod.midnight.network). I trusted it and lost time on setup.
• The compatibility matrix listed only Preprod/Preview, so there was no clear guidance for mainnet (e.g. which RPC to use).
• That mainnet use requires a prior application — and that its channel is GitHub — was hard to find (details in Q1). A path a non-engineer wouldn't think to look for.

The moment I almost stopped: The hardest stretch mentally was tracking the cold-sync bug. On preprod I hit the same failure (WASM unreachable) across seven sync runs. (Technically, the DustLocalState.replayEvents unreachable was a non-fatal error retried inside the SDK; the fatal crash that killed the process was on the get utxos side (CoinsAndBalances.js). The events skipped in replayEvents corrupted the Dust internal state, which then trapped during UTXO enumeration.) Each run made me wait through a long sync, only to fail at the exact same point every time. With no way to tell whether it was my own code or a chain-side bug, I went through the same darkness seven times. I thought "maybe this is the end" more than once. It was eventually identified as a ledger-side bug, leading to #425/#436/#52 → midnight-ledger#587 — but getting there was genuinely long. If a non-engineer had been alone, I'm almost certain they would have dropped out here.

Happy to. What I'll share is a teaching repo containing only the contracts' .compact sources and circuit design — two contracts:

① gyotak-catch (provenance): the exact GPS coordinates are taken as a private witness and never written to public state. What the contract records is not the coordinates but only their hash (gpsHash) — keeping the precise fishing spot secret while fixing the record immutably. The region is stored as a label. This catch contract on its own does not include a range proof of region-membership (stated honestly).

② gyotak-komon: the part your engineers want to see — proving "the catch falls within the declared region" without revealing the coordinates — is implemented here. Against the witnessed coordinates, the circuit asserts latMin ≤ lat ≤ latMax / lngMin ≤ lng ≤ lngMax, and what's disclosed is only the boolean "inside the range" — never the coordinate values. It also offers two modes via a privacyMode flag (0 = shielded / 1 = coordinates also disclosed); because the circuit forces the values, it is impossible to claim "shielded" while actually revealing, or claim "disclosed" while actually hiding. The range proof runs in both modes.

The contract addresses are already public (catch mainnet v2 5f87dd30…3741f7 / defensive publication perma.cc/J9GD-MRE5 / technical report gyotak-tr.pages.dev). GYOTAK has always aimed to be a template that producers across primary industries, manufacturing, and beyond can copy — and the defensive publication (ECOSUS-DP-2026-001) secures generic ZKP claims, so the scope isn't limited to seafood. Turning it into teaching material fits the intent. Welcome.

One thing on sequencing: the design is proven in KOMON, but integrating the range proof into the live catch contract is something I intend to do only after a third-party audit. I don't want to push an unaudited ZK circuit onto a production contract that's already running, so the order is prove the design (KOMON) → audit → integrate into live catch. The principle is that "it works" is not enough to ship to production — changes to production go through an audit gate (this ties back to the audit point in Q8).

Since the full production repo contains confidential material (pricing logic, customer DB, secrets), what I'm sharing is a teaching repo with only the .compact sources and circuit design. It's already published under Apache-2.0: github.com/ecosus-co/gyotak-compact-teaching
The README explains the two contracts' roles, docs/ covers the circuit design (notably 03-komon-range-proof.md for the range proof + two modes), and src/ holds the actual contract .compact files. Please feel free to study and reuse it.

For the technical detail of KOMON, the on-chain layer (range proof + dual-mode privacy) is written up in TR-2026-009, and the photo-only physical authentication engine in TR-2026-010 (the latter identifies an individual item — an EPS foam box, or produce such as durian — from a photo alone, with no QR or tag, aiming to generalize provenance to primary industry).

Kimura-san, thank you for raising this. You're right, and I take it as an important point. To be honest, I have not had a formal third-party audit — it has been reviewed by me and Claude.

For context, GYOTAK's Midnight contracts record data such as origin and temperature; they don't custody or transfer funds, so I believe the "assets getting stolen" class of risk is low. That said, I do understand that a bug in a circuit could leave incorrect data, and that this bears on the credibility of the origin proof itself.

If it's not too much trouble, having someone look over the Compact circuit part of the contract once would give me real peace of mind. I'd be grateful for the chance to consult with you on it.

I want to be clear on one point: my openness to sharing and to teaching use is not because I'm giving up on IP — it's because I understand it and am opening it deliberately.

The ZKP techniques used in GYOTAK already have established prior art via a defensive publication, ECOSUS-DP-2026-001 (covering seven ZKP claims), archived at Harvard Library through perma.cc (perma.cc/J9GD-MRE5). The intent is to prevent any single party from patent-fencing these techniques, and to keep them freely usable by anyone. Releasing the teaching repo under Apache-2.0 (with its patent grant) is part of the same posture.

So when I welcome study, reproduction, and teaching use, it is not an unguarded hand-off — it's a deliberate opening built on prior art and an appropriate license. I believe that also makes it something the Foundation can use as teaching material with confidence.