DEV Community: Tosh

I Replaced My $8k/Month Freelance Stack with 3 Claude Prompts

Tosh — Thu, 16 Apr 2026 23:06:43 +0000

Last year I was charging $150/hour for consulting work that took me 6 hours.

Same work now takes 45 minutes. I haven't lowered my rates.

Here's exactly what changed — and the three prompts that did it.

The Problem I Had (That You Probably Have Too)

I was doing B2B content strategy for SaaS companies. Each engagement:

3 hours of research
1 hour writing the strategy doc
1 hour of revisions
1 hour of client calls

$900 for a 6-hour day. Before expenses.

It was good money. But it wasn't leveraged money.

Prompt 1: The Research Accelerator

Before I discovered this, research meant reading 20+ competitor pages, taking notes, then synthesizing everything into a coherent picture. 3 hours minimum.

Now:

You are a B2B content strategist. I need competitive landscape research for [COMPANY].

They sell [PRODUCT] to [ICP].

Analyze their top 5 competitors: [LIST]. For each, identify:
1. Core messaging angle (what problem do they claim to solve)
2. Content pillars (what topics they consistently publish)
3. SEO gaps (topic clusters competitors haven't covered well)
4. Tone and positioning (how they talk to buyers)

Then synthesize: what's the white space? What angles aren't being covered well?
Format as a strategic brief with executive summary + detailed breakdown.

This doesn't replace thinking. It replaces the mechanical part of thinking — the reading, noting, and initial pattern-matching. I spend 30 minutes reviewing and refining instead of 3 hours doing it.

Prompt 2: The Strategy Writer

Once I have research, I used to spend 60-90 minutes writing the actual strategy document. Now:

Based on this competitive analysis: [PASTE RESEARCH]

Write a 6-month content strategy for [COMPANY] that:
- Targets [ICP] at each stage of the funnel
- Differentiates from [MAIN COMPETITORS] by focusing on [WHITE SPACE ANGLE]
- Prioritizes [METRIC] as the primary success measure

Structure: Executive Summary → Strategic Pillars (3-4) → Topic Clusters per Pillar → Distribution Strategy → Month-by-Month Roadmap

Tone: [COMPANY TONE]. Be specific, not generic. Every recommendation should be actionable.

The output isn't perfect. It's 70% there. But 70% is infinitely better than 0%, and editing a draft is 3x faster than writing from scratch.

Prompt 3: The Client Brief Translator

This is the one most people miss.

Clients don't know what they want. They say "we need more leads" when they mean "our sales team is complaining and we need to show we're doing something."

Before every engagement, I run their brief through:

Here's a client brief: [PASTE BRIEF]

Translate this into:
1. What they literally asked for
2. What they actually want (the underlying business goal)
3. What success looks like to THEM (not to us)
4. What the hidden risks are (what could make this fail)
5. What questions I should ask in the discovery call to clarify scope

Be direct. If the brief is vague, say so.

This saves me from building the wrong thing and having to redo it.

The Math

Old workflow: 6 hours × $150 = $900 project
New workflow: 1.5 hours × $150 = $225 billable (for same output)

But here's the thing: I didn't cut my rates. I took on more projects.

4 projects/week at $900 = $3,600/week
Now I do 8 projects/week at same quality = $7,200/week

I also got better at identifying which projects weren't worth taking.

What This Isn't

This isn't "AI does my job." The thinking, the judgment, the client relationships — all still human. What AI eliminated is the mechanical parts: reading, structuring, first drafts.

If your skill is mechanical (raw research, raw writing, raw coding) you need to adapt. If your skill is judgment, strategy, and relationships — AI just made you faster.

If you're building an AI services practice, I put together an agency starter kit with the full stack: cold email templates, service packages with pricing, Claude prompt libraries, and delivery SOPs.

AI Agency Starter Kit → — $97

The templates alone save 20+ hours. One client engagement pays for it 10x over.

What prompts are you using to accelerate your work? Drop them below.

7 Ways I'm Using AI to Make Money Right Now (With Exact Tools and Prompts)

Tosh — Thu, 16 Apr 2026 22:36:22 +0000

I've been running an experiment: can AI tools generate real income in 2026?

Short answer: yes — but only if you know which tasks to focus on.

Here's what's actually working, with specifics.

1. AI Copywriting as a Service ($50–$500/project)

The highest-leverage move I've found is selling AI-assisted copywriting on Upwork and Fiverr. Not "AI wrote it" but "I used AI to write 10x faster."

What sells:

Product descriptions for e-commerce stores
Sales page copy for SaaS products
Email sequences for coaches and consultants

The key: AI drafts, you edit for voice and accuracy. Clients don't care how it was made — they care if it converts.

2. Building Claude Code Tools for Bounties ($50–$500/bounty)

There's a growing ecosystem of bounty boards paying for Claude Code utilities:

CHANGELOG generators
PR review bots
Workflow automation tools

The claude-builders-bounty repo has active bounties. These pay $50–$200 each and you can build them in an afternoon with Claude.

3. Technical Tutorial Writing for Web3 Projects ($300–$1,000/article)

Privacy blockchain projects like Midnight Network actively pay for high-quality tutorials. Their bounty board: midnightntwrk/contributor-hub.

The secret: they want articles that explain complex ZK/privacy concepts to developers. AI is great at structuring this — you just need to verify technical accuracy.

4. Selling Prompt Packs on Gumroad ($19–$47)

This one is passive. I've published three prompt packs that sell without any ongoing work:

500+ AI Business Prompts — $27 — covers content, sales, strategy, email, social
AI Freelancer Income Blueprint — $47 — full playbook for monetizing AI skills
200 Developer Prompts — $19 — code review, testing, debugging, architecture

The math: 10 sales/day at $27 = $270/day = $8,100/month. Even 2 sales/day is meaningful passive income.

5. n8n + Claude Automations for Local Businesses ($200–$1,000/setup)

Local businesses will pay for "set it and forget it" automations:

Weekly report generation from their Google Sheets
Customer review response drafts
Invoice follow-up emails

Build once with n8n + Claude API. Sell to 10 businesses. Ongoing maintenance is 2 hours/month.

6. GitHub Bounties via Algora and IssueHunt

Algora lists funded GitHub issues across real open source projects. Filter by min_reward=$100 and you'll find issues you can solve with AI assistance in a few hours.

Key insight: AI doesn't just write code — it reads codebases, understands patterns, and suggests fixes. The human's job is to validate and submit.

7. AI-Assisted Content for Medium Partner Program

Medium pays per read. AI-assisted articles on AI topics perform well because:

The audience is interested in AI
You can produce high-quality content faster
Evergreen topics (how to use Claude, prompt engineering) keep earning

Apply to the Partner Program on day one. It takes 2–4 weeks to get approved but then every article you've published starts earning.

The Stack I'm Using

Claude Sonnet — writing, code generation, research synthesis
n8n — automation workflows
Gumroad — digital product sales
dev.to + Hashnode — content distribution
GitHub — bounty hunting and PR submissions

What Doesn't Work (Honest Assessment)

Pure AI content farms: Too crowded, Google filters it, ad revenue is terrible
Trading bots: The edge evaporates faster than you can build it
"AI will do everything" freelance promises: Clients want accountability, not automation

The winners are people who use AI as a 10x multiplier on skilled work — not a replacement for judgment.

Resources:

What's working for you? Drop it in the comments.

Handling Midnight SDK Breaking Changes: A Developer's Survival Guide

Tosh — Thu, 16 Apr 2026 18:24:25 +0000

Handling Midnight SDK Breaking Changes: A Developer's Survival Guide

Every developer building on early-stage blockchain SDKs has lived through this: you run npm install after a team member updates the lockfile, and suddenly nothing compiles. Midnight's SDK is actively evolving, and breaking changes are frequent enough that you need a systematic approach to handling them.

This guide covers practical strategies for managing Midnight SDK upgrades — from detecting breaking changes before they break production, to a step-by-step migration workflow, to maintaining backward compatibility when you can't upgrade immediately.

Why Midnight SDK Changes Break More Than Normal Libraries

Midnight SDK upgrades are more disruptive than typical library updates for a structural reason: proving keys are cryptographically bound to specific circuit versions.

When you upgrade the SDK, even a minor version bump can:

Change the circuit constraint system
Invalidate your existing proving keys
Require regeneration of proving and verification keys
Break existing proofs generated against the old keys

Unlike a typical API change where you update a function call, a circuit change means any proofs generated before the upgrade are incompatible with contracts deployed after it.

This creates a hard migration surface on two dimensions:

Your development environment: compilation and proof generation
Your deployment state: on-chain contracts vs. client-generated proofs

Step 1: Track Changes Before Upgrading

Never upgrade blindly. Before changing any @midnight-ntwrk/* version:

Check the changelog:

# In your repo, view the current versions
cat package.json | grep "@midnight-ntwrk"

# On npm, check what changed between versions
npx npm-check-updates --filter "@midnight-ntwrk/*" --dry-run

Read the release notes directly:

The Midnight SDK publishes changelogs at: https://github.com/midnight-ntwrk/midnight-js/releases

Look specifically for entries labeled:

BREAKING CHANGE — requires code changes
Circuit change — requires key regeneration
API rename — function/interface names changed
Type change — TypeScript types modified (common source of silent breakage)

Check the migration guide:
If a migration guide exists, read it in full before starting. The 15 minutes of reading saves hours of debugging.

Step 2: Pin Exact Versions (Never Use `^` or `~`)

// DANGEROUS — floating versions
{
  "dependencies": {
    "@midnight-ntwrk/compact-runtime": "^0.14.0",
    "@midnight-ntwrk/midnight-js-types": "~0.14.0"
  }
}

// CORRECT — pinned exact versions
{
  "dependencies": {
    "@midnight-ntwrk/compact-runtime": "0.14.0",
    "@midnight-ntwrk/midnight-js-types": "0.14.0",
    "@midnight-ntwrk/midnight-js-contracts": "0.14.0",
    "@midnight-ntwrk/midnight-js-network-id": "0.14.0"
  }
}

Lockfile discipline:
Commit package-lock.json (or yarn.lock). Never .gitignore it. Your CI should install with npm ci (not npm install) to use the exact lockfile versions.

Step 3: Upgrade in an Isolated Branch

Never upgrade the Midnight SDK directly on main. Create an upgrade branch:

git checkout -b upgrade/midnight-sdk-0.15.0

This lets you:

Run the full migration without disrupting other work
Revert cleanly if something breaks badly
Get a code review of the upgrade diff before merging

Step 4: Update Versions and Recompile Contracts

Update package.json manually (don't use npm update with floating versions):

# Update to specific new version
npm install @midnight-ntwrk/compact-runtime@0.15.0 \
  @midnight-ntwrk/midnight-js-types@0.15.0 \
  @midnight-ntwrk/midnight-js-contracts@0.15.0 \
  --save-exact

Then recompile all Compact contracts:

# Recompile all .compact files
find ./contracts -name "*.compact" | while read contract; do
  echo "Compiling: $contract"
  npx compactc "$contract" -o "$(dirname "$contract")/build"
done

If compilation fails, the error messages from compactc are usually clear about what changed. Common patterns:

Error: 'disclose' function signature changed in 0.15.0
# Fix: Update all disclose() calls to new signature

Error: Type 'Uint64' is no longer assignable to 'Field'
# Fix: Use explicit conversion via toField()

Step 5: Regenerate Proving Keys

After any compilation success, regenerate proving and verification keys. Even if the circuit didn't visibly change, don't trust old keys.

# Script to regenerate all keys
#!/bin/bash
set -euo pipefail

CONTRACTS_DIR="./contracts"
KEYS_DIR="./keys"

mkdir -p "$KEYS_DIR"

for contract_dir in "$CONTRACTS_DIR"/*/build; do
  contract_name=$(basename "$(dirname "$contract_dir")")

  echo "Generating keys for: $contract_name"

  npx compact-cli keygen \
    --circuit "$contract_dir/circuit.json" \
    --proving-key "$KEYS_DIR/${contract_name}.pk" \
    --verification-key "$KEYS_DIR/${contract_name}.vk"

  echo "✅ Keys generated for $contract_name"
done

echo "All keys regenerated. Commit the new keys."

Important: Proving keys must be committed to your repository. They're large (often 50-200MB), so use Git LFS if needed:

git lfs track "*.pk"
git lfs track "*.vk"
echo "*.pk filter=lfs diff=lfs merge=lfs -text" >> .gitattributes
echo "*.vk filter=lfs diff=lfs merge=lfs -text" >> .gitattributes
git add .gitattributes
git lfs install

Step 6: Update the Witness Implementation

After recompiling, review your TypeScript witness implementations. These are the most failure-prone area because TypeScript doesn't always catch circuit-level mismatches at compile time.

What to look for:

// Old pattern (pre-0.15.0)
import { buildTransferWitness } from '@midnight-ntwrk/compact-runtime';

// New pattern (post-0.15.0) — function renamed
import { createTransferWitness } from '@midnight-ntwrk/compact-runtime';

Run the TypeScript compiler as a first check:

npx tsc --noEmit 2>&1 | head -50

TypeScript errors reveal API changes. Fix all TypeScript errors before running tests.

Step 7: Run the Full Test Suite

After compilation and TypeScript checks pass, run your tests:

npm test

Common test failure modes after upgrades:

Constraint violations in tests: If tests fail with "constraint not satisfied," the witness implementation doesn't match the new circuit. Compare the old and new circuit constraint counts.
Proof verification failures: Old proofs in test fixtures are invalid. Regenerate test fixtures.
Timeout failures: A new proving system may be slower. Increase test timeouts:

   // In jest.config.ts
   export default {
     testTimeout: 120000, // 2 minutes for proof generation
   };

Network interaction failures: If the SDK changed how it connects to the network, update your test setup.

Step 8: Test on Local Devnet, Then Testnet

After local tests pass:

Deploy to local devnet (if Midnight provides one)
Run integration tests against the devnet
Deploy to testnet
Run smoke tests on testnet before committing to the upgrade

If you have existing testnet deployments, understand that you may need to redeploy contracts if the circuit changed. Old contracts with new client code will produce proof verification failures.

Handling "I Can't Upgrade Right Now" Situations

Sometimes you learn about a breaking SDK change but you can't migrate immediately (active user base, other ongoing work, etc.).

Strategy 1: Lock the environment completely

Prevent accidental upgrades at the system level:

# .npmrc — add to repo root
package-lock=true
engine-strict=true

# package.json engines field
"engines": {
  "node": ">=18.0.0 <20.0.0"
}

Strategy 2: Document the freeze with a clear exit criteria

Create UPGRADE_BLOCKED.md in the repo:

# Midnight SDK Upgrade Blocked

Current version: 0.14.0
Target version: 0.15.0
Blocked since: 2026-01-15
Blocker: Active testnet deployment with 200+ users
Exit criteria: Testnet migration window scheduled for 2026-02-01
Owner: @yourname

## What breaks in 0.15.0
- [List specific breaking changes]
- [Associated code areas]

## Migration plan
[Brief migration plan when the window opens]

Strategy 3: Run parallel environments

For longer freezes, maintain two deployment environments with different SDK versions. Route traffic based on contract version detected from on-chain state.

Diagnosing Proof Generation Failures After Upgrade

If proof generation fails after a successful upgrade, here's the diagnostic checklist:

1. Check proving key freshness

# Get the modification time of the compiled circuit
stat contracts/my-contract/build/circuit.json

# Compare with proving key
stat keys/my-contract.pk

# If circuit is newer than key: regenerate the key

2. Verify circuit input types

# Inspect the circuit's public inputs
cat contracts/my-contract/build/circuit.json | python3 -c "
import json, sys
circuit = json.load(sys.stdin)
print('Public inputs:')
for name, type_info in circuit.get('public_inputs', {}).items():
    print(f'  {name}: {type_info}')
print('Private inputs:')
for name, type_info in circuit.get('private_inputs', {}).items():
    print(f'  {name}: {type_info}')
"

Compare against your witness implementation and verify the types match exactly.

3. Test with minimal inputs

Isolate the failing constraint with a minimal test:

it('should prove minimal transfer', async () => {
  const proof = await proveTransfer({
    from: testKey,
    to: testAddress,
    amount: 1n,           // minimum amount
    balance: 1n,          // exactly equal to amount
  });
  expect(proof).toBeDefined();
});

4. Enable verbose proving output

COMPACT_PROOF_VERBOSE=1 npm test 2>&1 | grep -E "constraint|witness|error"

Automating Upgrade Detection

Set up a CI job to detect new SDK versions:

# .github/workflows/check-sdk-updates.yml
name: Check Midnight SDK Updates
on:
  schedule:
    - cron: '0 9 * * 1'  # Every Monday 9AM

jobs:
  check-updates:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Check for SDK updates
        run: |
          npm install -g npm-check-updates
          UPDATES=$(ncu --filter "@midnight-ntwrk/*" --jsonUpgraded 2>/dev/null || echo "{}")
          if [ "$UPDATES" != "{}" ] && [ "$UPDATES" != "null" ]; then
            echo "New SDK versions available:"
            echo $UPDATES
            # Optionally create a GitHub issue or send a notification
          fi

After going through this a few times, it gets less painful — you develop a feel for what's likely to break and where. The things that burned me most: skipping key regeneration because "I didn't change the circuit logic" (I did, indirectly), and not testing witness edge cases after an upgrade because the TypeScript compiled clean.

If you're building anything serious on Midnight right now, set up the weekly CI check for SDK updates and treat every version bump as a breaking change until proven otherwise. The proving key dependency is what makes these upgrades fundamentally different from normal library updates — once you've debugged a proof verification failure at 2am, you won't skip that step again.

Running a Midnight Node: Setup, Sync, and Monitoring

Tosh — Thu, 16 Apr 2026 18:22:47 +0000

Running a Midnight Node: Setup, Sync, and Monitoring

I set up a Midnight node on a spare Ubuntu box last month and hit pretty much every failure mode there is — 0 peers for 20 minutes, stuck on block 1 for an hour, then a surprise OOM kill that corrupted the database. This guide documents what actually works, including the "stuck on block 1" issue that seems to catch everyone off guard the first time.

Hardware Requirements

Before starting, confirm your hardware meets these minimums:

Component	Minimum	Recommended
CPU	4 cores (x86_64 or ARM64)	8+ cores
RAM	8 GB	16 GB
Storage	100 GB SSD	500 GB NVMe SSD
Network	10 Mbps stable	100 Mbps
OS	Ubuntu 22.04 LTS	Ubuntu 22.04 LTS

Why SSD matters: Midnight, like Cardano, performs heavy ledger operations during sync. Mechanical drives will make initial sync take 10-20x longer and may cause peer disconnections as your node fails to keep up.

RAM consideration: The proof server (if running locally) requires an additional 4-8 GB during proof generation. On a node dedicated to block validation only, 8 GB is sufficient.

Installation via Docker (Recommended)

Docker is the supported deployment method. It handles dependency management and makes upgrades straightforward.

Step 1: Install Docker

# Ubuntu 22.04
sudo apt update
sudo apt install -y docker.io docker-compose-plugin
sudo systemctl enable --now docker
sudo usermod -aG docker $USER
# Log out and back in for group changes

Step 2: Pull the Midnight node image

docker pull midnightntwrk/midnight-node:latest
# Or pin a specific version (recommended for production):
docker pull midnightntwrk/midnight-node:0.14.0

Step 3: Create a working directory and configuration

mkdir -p ~/midnight-node/{data,config,logs}
cd ~/midnight-node

Create docker-compose.yml:

version: '3.8'
services:
  midnight-node:
    image: midnightntwrk/midnight-node:0.14.0
    container_name: midnight-node
    restart: unless-stopped
    ports:
      - "9944:9944"   # RPC WebSocket
      - "9933:9933"   # RPC HTTP
      - "30333:30333" # P2P
    volumes:
      - ./data:/data
      - ./config:/config
      - ./logs:/logs
    environment:
      - RUST_LOG=info
    command: |
      --base-path /data
      --chain testnet
      --port 30333
      --rpc-port 9933
      --ws-port 9944
      --rpc-cors all
      --unsafe-rpc-external
      --name "my-midnight-node"
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "5"

Step 4: Start the node

docker compose up -d
docker compose logs -f midnight-node

Understanding the Initial Sync

When you start a fresh node, it goes through three phases:

Phase 1: Peer Discovery (seconds to minutes)
Your node announces itself to the network and discovers peers. You'll see logs like:

INFO sync  💤 Idle (0 peers), best: #0 (0x0000…0000)
INFO network  Discovered new external address
INFO network  Connected to peer 12D3Koo...

If you see Idle (0 peers) for more than 5 minutes, you have a connectivity issue (see troubleshooting below).

Phase 2: Header Sync (minutes to hours)
Your node downloads block headers first, much faster than full blocks:

INFO sync  ⚙️  Syncing 847.3 bps, target=#485231 (8 peers)

"bps" here means blocks per second. Rates of 100-1000 bps are normal during header sync.

Phase 3: Block Execution (hours to days depending on chain age)
Full block execution is the slow part — every transaction is re-executed and state is computed:

INFO sync  ⚙️  Syncing 12.1 bps, target=#485231 (8 peers)
INFO state  Applied block #102847

Rates of 5-50 bps during execution are normal. Don't panic.

How long does full sync take?

For Midnight testnet (still relatively young):

Hardware minimum: 6-12 hours
Hardware recommended: 2-4 hours
With fast NVMe SSD and strong CPU: 1-2 hours

Monitoring Block Height

Method 1: RPC polling

Once your node is running, poll its current best block:

# Check current synced block
curl -s -H "Content-Type: application/json" \
  -d '{"id":1,"jsonrpc":"2.0","method":"chain_getBlock","params":[]}' \
  http://localhost:9933 | python3 -c "
import json, sys
d = json.load(sys.stdin)
block = d['result']['block']['header']
print(f\"Block: #{int(block['number'], 16)}\")
print(f\"Hash: {block['parentHash'][:20]}...\")
"

Method 2: WebSocket subscription

For real-time monitoring:

# Install wscat if needed
npm install -g wscat

wscat -c ws://localhost:9944 << 'EOF'
{"id":1,"jsonrpc":"2.0","method":"chain_subscribeNewHeads","params":[]}
EOF

Method 3: Simple sync check script

Save as check_sync.sh:

#!/bin/bash
LOCAL_BLOCK=$(curl -s -H "Content-Type: application/json" \
  -d '{"id":1,"jsonrpc":"2.0","method":"chain_getHeader","params":[]}' \
  http://localhost:9933 | python3 -c "
import json, sys
d = json.load(sys.stdin)
print(int(d['result']['number'], 16))
" 2>/dev/null)

# Compare against a known good peer (replace with actual peer RPC)
# PEER_BLOCK=$(...)

echo "Local best block: #$LOCAL_BLOCK"
echo "Time: $(date)"

# Check if node is making progress by comparing with previous run
PREV_FILE="/tmp/midnight_prev_block"
if [ -f "$PREV_FILE" ]; then
  PREV_BLOCK=$(cat "$PREV_FILE")
  PROGRESS=$((LOCAL_BLOCK - PREV_BLOCK))
  echo "Progress since last check: +$PROGRESS blocks"
fi
echo $LOCAL_BLOCK > "$PREV_FILE"

Run on a schedule:

chmod +x check_sync.sh
watch -n 10 ./check_sync.sh

Diagnosing "Stuck on Block 1"

This is the most common issue new node operators hit. Symptoms:

INFO sync  💤 Idle (0 peers), best: #1 (0x1234…abcd)
# or
INFO sync  ⚙️  Syncing 0.0 bps, target=#485231 (3 peers)

Your node has peers but isn't advancing. Here's the diagnostic tree:

Check 1: Are peers actually connected?

curl -s -H "Content-Type: application/json" \
  -d '{"id":1,"jsonrpc":"2.0","method":"system_peers","params":[]}' \
  http://localhost:9933 | python3 -c "
import json, sys
peers = json.load(sys.stdin)['result']
print(f'Connected peers: {len(peers)}')
for p in peers:
    print(f\"  {p['peerId'][:20]}... best: #{p['bestNumber']}\")
"

If peers show bestNumber: 1, your entire peer set is also stuck — you may have hit isolated testnet nodes. Restart and wait for better peers.

Check 2: Is the network port accessible?

# From another machine or use online port checker
nc -zv YOUR_SERVER_IP 30333

If port 30333 isn't reachable from the internet, you'll only get local peers (usually none). Fix firewall rules:

# Ubuntu UFW
sudo ufw allow 30333/tcp
sudo ufw status

If behind NAT (home network), you need port forwarding on your router for port 30333.

Check 3: Storage I/O performance

# Check if storage is the bottleneck
iostat -x 1 5

# Look at the %util column for your storage device
# >80% sustained means storage is saturating

If your storage is consistently >80% utilized, the node is I/O bottlenecked. Migrate to faster SSD.

Check 4: Memory pressure

free -h
# If available memory < 1GB, you have memory pressure

# Check if the node is being OOM-killed
docker inspect midnight-node | grep -A5 "State"
dmesg | grep -i "out of memory" | tail -5

Check 5: Corrupt chain database

If the node was killed ungracefully (power loss, kill -9), the chain database may be corrupt:

docker compose down
# Back up and remove the data directory
mv data data.bak
mkdir data
docker compose up -d
# Node will re-sync from genesis

Resource Requirements During Operation

After initial sync completes, steady-state resource usage:

CPU: 5-20% on a 4-core machine during normal operation. Spikes to 80%+ during epoch transitions.

RAM: 2-4 GB for the node process alone. Add proof server if running locally.

Storage growth rate: Approximately 5-15 GB/month depending on network activity (testnet figures — mainnet will differ).

Network: 50-200 MB/hour download, 20-50 MB/hour upload for a non-archival node.

Verifying Your Node is Synced and Healthy

When sync completes, you'll see:

INFO sync  💤 Idle (12 peers), best: #485231 (0xabcd…1234)

"Idle" with the current chain head block number = fully synced.

Health check script (health_check.sh):

#!/bin/bash
set -euo pipefail

RPC="http://localhost:9933"

# Get sync state
SYNC=$(curl -s -H "Content-Type: application/json" \
  -d '{"id":1,"jsonrpc":"2.0","method":"system_health","params":[]}' \
  $RPC)

IS_SYNCING=$(echo $SYNC | python3 -c "import json,sys; print(json.load(sys.stdin)['result']['isSyncing'])")
PEERS=$(echo $SYNC | python3 -c "import json,sys; print(json.load(sys.stdin)['result']['peers'])")

echo "Peers: $PEERS"
echo "Syncing: $IS_SYNCING"

if [ "$IS_SYNCING" = "False" ]; then
  echo "✅ Node is synced and healthy"
else
  # Get current block
  BLOCK=$(curl -s -H "Content-Type: application/json" \
    -d '{"id":1,"jsonrpc":"2.0","method":"chain_getHeader","params":[]}' \
    $RPC | python3 -c "import json,sys; print(int(json.load(sys.stdin)['result']['number'], 16))")
  echo "⏳ Still syncing, current block: #$BLOCK"
fi

# Check peer connectivity
if [ "$PEERS" -lt 3 ]; then
  echo "⚠️  Warning: low peer count ($PEERS). Check firewall rules."
fi

Run this check after every deployment or restart.

Monitoring with Docker Logs

The Midnight node logs are structured and informative. Key patterns to watch:

# Follow logs in real time
docker compose logs -f midnight-node

# Filter for errors only
docker compose logs --since 1h midnight-node | grep -E "ERROR|WARN"

# Check sync rate (last 10 sync messages)
docker compose logs --since 1h midnight-node | grep "Syncing" | tail -10

Concerning log patterns:

WARN network Dropping slow peer: One or two is fine, many indicate network issues
ERROR import Failed to import block: Usually means corrupt database or invalid block — investigate immediately
WARN sync Reorg at block: Chain reorganization — normal if infrequent, concerning if frequent
WARN peering Peer disconnected: Normal to see occasionally; constant disconnects indicate networking or resource issues

Operational Best Practices

Automatic restart on failure:
The restart: unless-stopped in the compose file handles this. Verify:

docker inspect midnight-node | grep RestartPolicy

Log rotation: Already configured in the compose file above. Verify rotation is working:

ls -lh ~/midnight-node/logs/
docker system df  # Check Docker's disk usage

Monitoring alerting: Set up a simple cron job to alert if the node falls behind:

# Add to crontab: crontab -e
*/5 * * * * /home/user/midnight-node/health_check.sh >> /home/user/midnight-node/logs/health.log 2>&1

Backup strategy: The node database can be re-synced from genesis, so it doesn't need backup. What does need backup: any private keys used for block authoring (if you're running a validator, which requires separate setup).

Upgrade procedure:

docker compose pull          # Get new image
docker compose down          # Stop current node
docker compose up -d         # Start with new image
docker compose logs -f       # Watch startup

Common Questions

Q: Can I run this on a VPS/cloud server?

Yes. Most cloud providers work. Avoid burstable CPU instances (AWS T-series, GCP E2) for sustained sync workloads — they'll throttle under sustained load. Use compute-optimized instances with dedicated CPU.

Q: Do I need to keep port 30333 open?

For syncing: yes, strongly recommended. Without inbound P2P connections, your node relies entirely on outbound connections and has fewer peers, which slows sync and makes you vulnerable to being isolated from the main network.

Q: How do I know if my node is on the canonical chain?

Compare your node's best block hash with hashes from the Midnight block explorer. If they match at the same height, you're on the canonical chain.

Q: What's the difference between an archival and non-archival node?

A non-archival node (default) prunes old state to save space. An archival node (--pruning archive) keeps all historical state, useful for querying historical data. Archival nodes require significantly more storage.

In my experience, 90% of "stuck at block 1" issues come down to two things: port 30333 isn't reachable from outside, or you're running on spinning rust and the I/O just can't keep up. Check those before going deeper into the diagnostic tree.

Security Checklist for Midnight dApps Before Deployment

Tosh — Thu, 16 Apr 2026 18:16:00 +0000

Security Checklist for Midnight dApps Before Deployment

I've been going through Midnight's Compact contracts over the past few weeks and kept hitting the same class of bugs — not the kind that throw errors during compilation, but the kind that silently misbehave at runtime. ZK architecture introduces failure modes that EVM developers don't have muscle memory for: constraint violations that only surface during proof generation, disclosure leaks that pass all your unit tests, witness bugs that produce valid-looking but incorrect proofs.

This is the checklist I put together after working through these issues. It's focused specifically on Midnight — not generic smart contract security.

1. `disclose()` Audit: No Unintended Secret Leaks

The disclose() operation in Compact moves data from private state to public state. It's necessary for transparency (e.g., emitting events, publishing commitments) but dangerous when applied carelessly.

What to look for:

// DANGEROUS: Accidentally disclosing private user data
circuit completeOrder(
  userBalance: Uint64,    // private
  orderId: Field,         // public
): void {
  // This discloses the private balance — DON'T DO THIS
  disclose(userBalance);
  disclose(orderId);  // OK: orderId was already public
}

Correct pattern:

circuit completeOrder(
  userBalance: Uint64,    // private
  orderId: Field,         // public
  orderAmount: Uint64,    // private
): void {
  // Only disclose what needs to be public
  assert(userBalance >= orderAmount);
  disclose(orderId);
  disclose(orderAmount);  // OK: amount is disclosed by design
  // userBalance stays private
}

Checklist items:

[ ] Enumerate every disclose() call in your codebase
[ ] Confirm each disclosure is intentional and documented
[ ] Ask: "If an adversary sees this disclosed value, can they infer private state?"
[ ] Check for indirect disclosure (disclosing a value derived from private data can leak the private data)

2. `ownPublicKey()` Usage Review

ownPublicKey() retrieves the caller's public key within a circuit. There's a known vulnerability pattern: if you use the result of ownPublicKey() in a way that allows an adversary to choose a specific key for them, you may enable impersonation.

The vulnerability pattern:

// VULNERABLE: attacker can craft inputs to pass as someone else
circuit withdrawFunds(
  claimedKey: PublicKey,
  signature: Signature,
  amount: Uint64,
): void {
  // If signature verification is flawed, anyone can withdraw
  verifySignature(claimedKey, signature, amount);
  transfer(claimedKey, amount);
}

Safer pattern — use ownPublicKey() directly:

circuit withdrawFunds(
  amount: Uint64,
): void {
  // The key comes from the ZK proof itself, not from caller input
  const caller: PublicKey = ownPublicKey();
  assert(balances[caller] >= amount);
  balances[caller] -= amount;
}

Checklist items:

[ ] If you accept PublicKey as a parameter, verify you have a cryptographic reason for doing so
[ ] Prefer ownPublicKey() over accepting keys as inputs wherever possible
[ ] Review every function that accepts a PublicKey parameter for authorization logic
[ ] Ensure key derivation functions aren't exploitable with crafted inputs

3. Replay Protection: Nonces and Nullifiers

Without replay protection, an attacker can resubmit a valid ZK proof to execute the same operation multiple times. This is the ZK equivalent of a reentrancy attack.

Two standard mechanisms:

Nonce-based protection (for sequential operations):

export ledger {
  nonces: Map<PublicKey, Uint64>;
}

circuit executeAction(
  nonce: Uint64,
  // ... other params
): void {
  const caller = ownPublicKey();
  const expectedNonce = nonces[caller];
  assert(nonce === expectedNonce, "Invalid nonce");
  nonces[caller] = expectedNonce + 1;
  // ... rest of logic
}

Nullifier-based protection (for one-time use):

export ledger {
  spentNullifiers: Set<Field>;
}

circuit spendNote(
  noteCommitment: Field,
  nullifier: Field,     // derived from the note's secret
  // ... other params
): void {
  assert(!spentNullifiers.has(nullifier), "Note already spent");
  spentNullifiers.add(nullifier);
  // ... process note
}

Checklist items:

[ ] Every state-modifying operation has replay protection
[ ] Nonces are user-specific, not global (global nonces serialize all transactions)
[ ] Nullifiers are cryptographically bound to the specific note/credential being consumed
[ ] Nullifier derivation doesn't leak private data about the note

4. Exported Ledger Field Review

Midnight's dual ledger model lets you mark fields as exported to the public ledger. Exported fields are visible to all observers. Review every exported field as if it will be on a public blockchain forever — because it will be.

What to audit:

export ledger {
  // These are ALL visible publicly:
  totalSupply: Uint64;           // OK: intentionally public
  merkleRoot: Field;             // OK: commitment, no private info
  @private userBalances: Map<...>; // OK: private, only commitments exported

  // POTENTIAL ISSUE: Is this field revealing too much?
  lastTransactionTime: Timestamp;  // Leaks activity patterns
  participantCount: Uint64;        // May correlate with private activity
}

Checklist items:

[ ] List every exported ledger field
[ ] For each field: "What does an adversary learn from watching this field change?"
[ ] Check for timing-channel leaks (when something changes can be as revealing as what changes)
[ ] Verify that commitment schemes don't leak set membership information
[ ] Consider correlation attacks: can exported fields be combined with other public data to infer private state?

5. Witness Implementation Correctness

Witnesses are the off-chain computations that generate inputs to ZK circuits. A bug in a witness doesn't fail with an error — it generates incorrect proofs that may still verify. This is the sneakiest class of Midnight bug.

Common witness bugs:

// TypeScript witness implementation
async function generateTransferWitness(
  fromSecret: SecretKey,
  toAddress: PublicKey,
  amount: bigint,
  currentBalance: bigint,
): Promise<TransferWitness> {
  // BUG: Off-by-one in balance check
  // The circuit checks balance >= amount
  // But the witness passes balance - 1, which will fail constraint
  return {
    balance: currentBalance - 1n,  // WRONG
    amount: amount,
    // ...
  };

  // CORRECT:
  // return {
  //   balance: currentBalance,
  //   amount: amount,
  // };
}

Checklist items:

[ ] Every circuit constraint has a corresponding witness computation test
[ ] Witness inputs match circuit input types precisely (bit widths, field sizes)
[ ] Test witnesses with edge cases: zero values, maximum values, equal values (e.g., amount == balance)
[ ] Verify witness generation doesn't fail silently — errors should propagate, not return invalid witnesses
[ ] Test that invalid witnesses correctly fail proof generation

6. Version Compatibility Confirmation

Midnight's SDK is evolving. API changes between versions can break proof generation in non-obvious ways.

What can break between versions:

Constraint system changes invalidate old proofs
API renames cause silent failures if TypeScript types are too permissive
Proving key format changes require key regeneration

Checklist items:

[ ] Pin exact SDK versions in package.json (no ^ or ~ prefixes for Midnight packages)
[ ] Check Midnight's changelog for breaking changes before upgrading
[ ] Regenerate proving keys after any SDK upgrade — don't reuse keys from a previous version
[ ] Test the full proof generation pipeline after version updates, not just compilation
[ ] Document the exact SDK version in your deployment runbook

Pin versions explicitly:

{
  "dependencies": {
    "@midnight-ntwrk/compact-runtime": "0.14.0",
    "@midnight-ntwrk/midnight-js-types": "0.14.0",
    "@midnight-ntwrk/midnight-js-contracts": "0.14.0"
  }
}

7. Proof Generation Testing on Testnet

Testnet is where you find proof generation failures, gas estimation issues, and latency problems. Deploy early, test thoroughly.

Proof generation failure modes:

Constraint violations: Circuit assertions fail during witness generation
Out-of-memory: Complex circuits require significant RAM for proof generation
Timeout: Proof generation takes longer than client timeout limits
Stale proving keys: Circuit changed without regenerating keys

Testnet testing checklist:

[ ] Complete the full transaction lifecycle: generate witness → generate proof → submit → verify
[ ] Test with realistic data sizes (if your circuit handles 1000 items, test with 1000 items)
[ ] Measure proof generation time on a standard consumer machine, not a dev workstation
[ ] Test error handling: what happens when proof generation fails?
[ ] Verify all circuit variants are tested (don't only test the happy path)
[ ] Confirm wallet integration works with the proof server
[ ] Test behavior when the proof server is slow or unreachable

Latency benchmarking:

# Time a full proof generation cycle
time npx compact-cli prove \
  --circuit transfer \
  --inputs ./test-inputs.json \
  --proving-key ./proving-key.bin \
  --output ./proof.bin

The Pre-Deployment Checklist Summary

Before mainnet deployment, confirm:

Disclosure

[ ] All disclose() calls are intentional and documented
[ ] No indirect private data leaks through disclosed derived values

Authorization

[ ] ownPublicKey() used for caller identification
[ ] No PublicKey parameters accepted without cryptographic justification

Replay Protection

[ ] All state-modifying circuits have nonce or nullifier protection
[ ] Nullifiers are cryptographically bound to specific consumed resources

Ledger Design

[ ] Every public ledger field is intentionally public
[ ] Timing channels and correlation attacks are considered

Witness Correctness

[ ] All witnesses have unit tests
[ ] Edge cases are covered (zero, max, equal values)

Version Management

[ ] Exact SDK versions pinned
[ ] Proving keys match current circuit version

Testnet Validation

[ ] Full lifecycle tested end-to-end
[ ] Proof generation benchmarked on standard hardware
[ ] Error handling verified

A Note on What This Checklist Doesn't Cover

Security doesn't stop here. This checklist covers Midnight-specific issues. You also need to audit:

Off-chain witness code for standard application security vulnerabilities (input validation, authentication, etc.)
Frontend code for wallet interaction security
Key management — how are secret keys stored and used in production?
The deployment process itself — who controls the upgrade keys?

ZK cryptography is only as secure as the code around it. A mathematically perfect ZK circuit can be defeated by a compromised witness generator.

Privacy bugs don't announce themselves. There's no revert, no thrown exception — just data that was supposed to stay hidden showing up somewhere it shouldn't. Testnet is cheap, mainnet isn't. Worth the time to go through this before you ship.

Midnight vs. Aztec vs. Aleo vs. Mina vs. Zcash: A Developer's Honest Guide to Privacy Chain Architecture

Tosh — Thu, 16 Apr 2026 18:14:31 +0000

Midnight vs. Aztec vs. Aleo vs. Mina vs. Zcash: A Developer's Guide to Privacy Chain Architecture

Privacy-preserving blockchains have moved from concept to production, but the tradeoffs between them are rarely explained honestly. This guide compares five serious contenders from the perspective of someone building applications — not investing in tokens.

The Core Problem Each Chain Solves

Before diving into architecture, understand what "privacy" means here. These chains all use zero-knowledge proofs, but they solve different problems:

Zcash: Privacy for payments — hide sender, receiver, amount
Mina: Privacy for computation — prove you ran code without revealing inputs
Aztec: Privacy for state — hide smart contract state from public chains
Aleo: Privacy for programs — compile private + public logic into a single VM
Midnight: Privacy for data — define precisely what data stays private and what's disclosed

That framing matters for choosing the right tool.

Midnight: The Data Sovereignty Approach

Midnight, built by Input Output Global (IOG) on Cardano's infrastructure, takes a fundamentally different design philosophy. Rather than making everything private by default, it gives developers explicit control over what gets disclosed.

The Dual Ledger Model

Midnight operates a dual ledger:

Public ledger: Standard on-chain state, visible to all — Merkle tree commitments, balances, contract addresses
Private ledger: Off-chain state stored only by relevant parties, proven via ZK proofs

This is a meaningful architectural choice. Your contract can have fields that are provably correct without being publicly visible. A compliance check can verify "this user is over 18" without revealing their age or identity.

Compact Language

Midnight's smart contract language is Compact, described as TypeScript-like. Contracts look like this:

// Compact pseudocode
export ledger {
  // public state - everyone sees this
  totalSupply: Uint64;

  // private state - only the owner knows
  @private balances: Map<PublicKey, Uint64>;
}

circuit transfer(
  from: SecretKey,
  to: PublicKey,
  amount: Uint64
): void {
  // this runs in ZK proof generation
  assert(balances[from.publicKey] >= amount);
  balances[from.publicKey] -= amount;
  balances[to] += amount;
}

The @private annotation controls what hits the public ledger vs. stays off-chain. TypeScript developers can pick this up quickly — no Rust knowledge required.

Developer experience verdict: Friendly to Web2 devs. TypeScript familiarity lowers the learning curve significantly. The downside: the ecosystem is very young (2024-2026 range), documentation gaps exist, and tooling is immature compared to EVM chains.

Zswap and Proof Generation

The Zswap protocol handles transaction shielding. ZK proof generation happens client-side via a proof server that runs locally. This means:

Users don't reveal private inputs to any server
First transaction is slow (~10-30 seconds for proof generation on standard hardware)
Subsequent transactions get faster with caching

Real limitation: The proof server requirement adds UX complexity. Users need software beyond a browser extension. The dApp Connector API (via Lace or 1AM wallets) abstracts this somewhat, but the setup overhead is real.

Aztec: The Ethereum Privacy Layer

Aztec's pitch is "Ethereum, but private." It runs as an L2 on Ethereum, which is both its strength and weakness.

Noir: The ZK Circuit Language

Noir is Aztec's domain-specific language for writing ZK circuits. It compiles to Ethereum-compatible bytecode. The syntax is Rust-inspired:

// Noir example
fn main(
    balance: Field,        // private witness
    minimum: pub Field,    // public input
) {
    assert(balance >= minimum);
}

The pub keyword marks public inputs; everything else is private. For pure ZK proofs this is clean. For complex dApp logic, it gets verbose.

Aztec.nr extends Noir for smart contracts with public and private functions:

contract Token {
    // public storage - on-chain visible
    #[aztec(storage)]
    struct Storage {
        balances: Map<PublicKey, PublicMutable<Field>>,
    }

    // private function - runs in ZK
    #[aztec(private)]
    fn transfer(from: AztecAddress, to: AztecAddress, amount: Field) {
        // ...
    }
}

The UTXO Note Model

Aztec uses a notes-based UTXO model for private state. Private "notes" are encrypted and stored in a note hash tree. Spending a note nullifies it (like Bitcoin UTXOs). Public state uses storage slots.

Tradeoff: This is conceptually clean for payment-like applications but awkward for complex state machines. If you're building a private DEX with order books, you'll fight the UTXO model.

Proving system: Ultra-PLONK. Fast verification, production-grade. Aztec has been in production longer than most and has battle-tested cryptography.

Developer experience verdict: Best documentation of the group. Ethereum-native developers adapt well. The UTXO mental model is foreign to Solidity developers but well-documented. Rust/Solidity background helps significantly.

Aleo: Programs All the Way Down

Aleo's approach: make privacy the default for all execution, not just selected state.

Leo Language

Leo is Rust-inspired with ZK semantics baked in:

// Leo example
program token.aleo {
    record Token {
        owner: address,        // encrypted
        amount: u64,           // encrypted
    }

    transition transfer(
        token: Token,          // private input (record)
        receiver: address,     // private
        amount: u64,           // private
    ) -> (Token, Token) {
        // returns two records: change + new token
        let change: Token = Token {
            owner: token.owner,
            amount: token.amount - amount,
        };
        let new_token: Token = Token {
            owner: receiver,
            amount: amount,
        };
        return (change, new_token);
    }
}

Records are the core abstraction — analogous to Aztec's notes but with tighter language integration.

The Records Model

Aleo's records are encrypted data structures owned by an address. They're consumed (destroyed) and created in each transaction — pure functional style.

Public state exists too (mappings in Leo), but it's treated as a second-class citizen. The entire execution model optimizes for records.

SnarkVM handles compilation and proof generation. Proofs are generated locally and verified on-chain.

Real limitations:

Testnet maturity issues — the ecosystem is still maturing
Developer tooling is less polished than Aztec
Finding good examples and documentation requires significant effort
The records model is powerful but has a steep learning curve

Developer experience verdict: Challenging. Rust developers will adapt, but the records mental model doesn't map cleanly to any existing paradigm. Good for greenfield privacy applications; difficult for migrating existing logic.

Mina: Constant-Size Blockchain with zkApps

Mina takes a completely different angle — the entire blockchain is compressed to ~22KB using recursive SNARKs. This enables client-side verification of the entire chain history.

o1js: TypeScript for ZK Circuits

o1js (formerly SnarkyJS) is the standout developer experience here. You write ZK circuits in TypeScript:

import { Field, SmartContract, state, State, method } from 'o1js';

class Counter extends SmartContract {
  @state(Field) count = State<Field>();

  @method async increment() {
    const currentCount = await this.count.getAndRequireEquals();
    this.count.set(currentCount.add(1));
  }

  @method async assertMinimum(minimum: Field) {
    // This method proves minimum without revealing count
    const currentCount = await this.count.getAndRequireEquals();
    currentCount.assertGreaterThanOrEqual(minimum);
  }
}

This is the most accessible ZK development experience available. Standard TypeScript tooling works. Existing web developers can ship zkApps without learning a new language.

Recursive SNARKs and zkApps

zkApps are Mina's smart contracts. They run off-chain (in the browser or server) and submit ZK proofs on-chain. The chain only stores a constant-size proof — not the full execution trace.

Kimchi is the proving system — a variation of PLONK optimized for recursive composition.

Real limitations:

Private state storage is genuinely constrained — you get 8 field elements of on-chain state per contract
For applications needing large private state, you'll use off-chain storage (IPFS, Arweave) and commit hashes on-chain
The constant-size chain is a design choice that constrains throughput
Ecosystem is smaller than Ethereum-adjacent chains

Developer experience verdict: Best DX for TypeScript/web developers by a significant margin. If your team knows JavaScript, Mina has the lowest ramp-up time. The 8-field state limit requires creative architecture for complex applications.

Zcash: The Pioneer, Now Limited

Zcash invented practical ZK privacy for blockchains. Its Sapling and Orchard schemes are cryptographically mature and battle-tested over 8+ years.

The honest verdict: Zcash is not a general-purpose smart contract platform. It's optimized for private payments. If you're building a privacy-preserving dApp with complex logic — use one of the others.

The Halo2 proving system (used in Orchard) is excellent and has influenced Aztec's own work. If you're doing pure ZK cryptography research, Zcash's tooling is solid. For application development, you've outgrown it.

Architecture Comparison Table

Feature	Midnight	Aztec	Aleo	Mina	Zcash
Contract Language	Compact (TS-like)	Noir (Rust-like)	Leo (Rust-like)	o1js (TypeScript)	N/A
State Model	Dual ledger	Notes (UTXO) + public slots	Records + mappings	8 field state + off-chain	N/A
Privacy Default	Explicit control	Explicit (pub/private)	Private by default	Explicit	Payments only
Base Chain	Cardano (IOG)	Ethereum L2	Own L1	Own L1	Own L1
Dev Language Familiarity	TypeScript devs	Rust + Solidity devs	Rust devs	TypeScript devs	N/A
Ecosystem Maturity	Early (2025)	Growing	Early	Growing	Mature
Proving System	Custom ZK	Ultra-PLONK	SnarkVM	Kimchi	Halo2
Smart Contracts	Yes	Yes	Yes	Yes	No

Which Should You Build On?

Choose Midnight if: You need fine-grained control over what data is disclosed vs. kept private. You're building compliance-sensitive applications (KYC without data exposure, selective disclosure, attestations). Your team knows TypeScript.

Choose Aztec if: You're already in the Ethereum ecosystem and want to add privacy without leaving it. Your application fits a notes/UTXO model. You want the most mature ZK L2 documentation available.

Choose Aleo if: You want privacy-by-default across your entire execution model. Your application is payment or asset-centric with relatively simple state transitions. Your team knows Rust.

Choose Mina if: You have TypeScript developers and want the best developer experience. You need client-verifiable computation. Your state requirements fit in the 8-field constraint.

Don't choose Zcash for general dApp development — it's a payments chain.

The Honest Caveat

All of these ecosystems except Zcash are young. Documentation has gaps. APIs change. Tooling is immature by Ethereum standards. Build-test cycles are longer because proof generation adds latency. Budget extra time for debugging ZK-specific errors ("constraint not satisfied" is harder to diagnose than "revert").

The technology is real and production-grade at the cryptographic layer. The developer experience and ecosystem support are where the maturity gaps show up.

Privacy blockchains will matter significantly for enterprise adoption, compliance-compatible DeFi, and any application handling sensitive user data. The question isn't whether to build on them — it's which architecture fits your problem.

DEV Community: Tosh

I Replaced My $8k/Month Freelance Stack with 3 Claude Prompts

The Problem I Had (That You Probably Have Too)

Prompt 1: The Research Accelerator

Prompt 2: The Strategy Writer

Prompt 3: The Client Brief Translator

The Math

What This Isn't

7 Ways I'm Using AI to Make Money Right Now (With Exact Tools and Prompts)

1. AI Copywriting as a Service ($50–$500/project)

2. Building Claude Code Tools for Bounties ($50–$500/bounty)

3. Technical Tutorial Writing for Web3 Projects ($300–$1,000/article)

4. Selling Prompt Packs on Gumroad ($19–$47)

5. n8n + Claude Automations for Local Businesses ($200–$1,000/setup)

6. GitHub Bounties via Algora and IssueHunt

7. AI-Assisted Content for Medium Partner Program

The Stack I'm Using

What Doesn't Work (Honest Assessment)

Handling Midnight SDK Breaking Changes: A Developer's Survival Guide

Handling Midnight SDK Breaking Changes: A Developer's Survival Guide

Why Midnight SDK Changes Break More Than Normal Libraries

Step 1: Track Changes Before Upgrading

Step 2: Pin Exact Versions (Never Use ^ or ~)

Step 3: Upgrade in an Isolated Branch

Step 4: Update Versions and Recompile Contracts

Step 5: Regenerate Proving Keys

Step 6: Update the Witness Implementation

Step 7: Run the Full Test Suite

Step 8: Test on Local Devnet, Then Testnet

Handling "I Can't Upgrade Right Now" Situations

Diagnosing Proof Generation Failures After Upgrade

Automating Upgrade Detection

Running a Midnight Node: Setup, Sync, and Monitoring

Running a Midnight Node: Setup, Sync, and Monitoring

Hardware Requirements

Installation via Docker (Recommended)

Understanding the Initial Sync

Monitoring Block Height

Diagnosing "Stuck on Block 1"

Resource Requirements During Operation

Verifying Your Node is Synced and Healthy

Monitoring with Docker Logs

Operational Best Practices

Common Questions

Security Checklist for Midnight dApps Before Deployment

Security Checklist for Midnight dApps Before Deployment

1. disclose() Audit: No Unintended Secret Leaks

2. ownPublicKey() Usage Review

3. Replay Protection: Nonces and Nullifiers

4. Exported Ledger Field Review

5. Witness Implementation Correctness

6. Version Compatibility Confirmation

7. Proof Generation Testing on Testnet

The Pre-Deployment Checklist Summary

A Note on What This Checklist Doesn't Cover

Midnight vs. Aztec vs. Aleo vs. Mina vs. Zcash: A Developer's Honest Guide to Privacy Chain Architecture

Midnight vs. Aztec vs. Aleo vs. Mina vs. Zcash: A Developer's Guide to Privacy Chain Architecture

The Core Problem Each Chain Solves

Midnight: The Data Sovereignty Approach

The Dual Ledger Model

Compact Language

Zswap and Proof Generation

Aztec: The Ethereum Privacy Layer

Noir: The ZK Circuit Language

The UTXO Note Model

Aleo: Programs All the Way Down

Leo Language

The Records Model

Mina: Constant-Size Blockchain with zkApps

o1js: TypeScript for ZK Circuits

Recursive SNARKs and zkApps

Zcash: The Pioneer, Now Limited

Architecture Comparison Table

Which Should You Build On?

The Honest Caveat

Step 2: Pin Exact Versions (Never Use `^` or `~`)

1. `disclose()` Audit: No Unintended Secret Leaks

2. `ownPublicKey()` Usage Review