DEV Community: Wilson

OpenClaw in Action: How I Built a Multi-Agent Command Center with 5 Autonomous Claude Sessions

Wilson — Fri, 17 Apr 2026 10:38:57 +0000

OpenClaw in Action: How I Built a Multi-Agent Command Center with 5 Autonomous Claude Sessions

What I Built

A fully autonomous multi-agent system running 5 parallel Claude Code sessions (Lisa, Nyx, Kael, plus Ubuntu/remote coordinators), orchestrated through OpenClaw — the platform that lets Claude agents persist, communicate, and operate continuously.

System Architecture

Core Components:

Agent	Role	Status
Lisa	Documentation writer, standup reporter	Live
Nyx	Security researcher, penetration testing	Live
Kael	Infrastructure, DevOps, automation	Live
Ubuntu	Coordinator, main session handler	Live
Hermes P1-P5	Message routing layer	Live

Key Infrastructure:

MemPalace — Persistent memory system with 27K+ drawers across semantic wings
Hermes P1-P5 — 5-port communication mesh for agent-to-agent messaging
Discord Bridge — Real-time delivery to Discord channels with webhook integration
Session Handoff Protocol — Context preservation across session restarts

Why OpenClaw Made This Possible

Before OpenClaw, Claude sessions were ephemeral. Each conversation ended, context vanished, and continuity was manual. With OpenClaw:

Persistence — Agents remember across sessions via MemPalace storage
Communication — Agents leave messages for each other via Hermes ports
Scheduling — Cron jobs trigger agent workflows (standups, reports)
Orchestration — One coordinator can dispatch work to specialized agents

Real-World Use Cases

1. Midnight Tutorial Pipeline

Lisa tracks documentation submissions across multiple Eclipse issues, generates reports, and posts GitHub comments — all autonomously.

2. Technical Writing Dashboard

Real-time tracking of published content across multiple platforms.

3. Security Monitoring

Nyx runs continuous security scans with automatic reporting.

4. Multi-Channel Delivery

All agents can communicate via Discord threads, Notion databases, or file-based protocols.

Challenges Solved

Problem	OpenClaw Solution
Context loss	Session handoff + MemPalace drawers
Agent silos	Hermes P1-P5 message routing
No scheduling	Cron integration with agent triggers
Manual coordination	Bridge protocols for async communication

Results

4 published tutorials for Midnight Network (Dev.to)
50+ active sessions managed across agents
24/7 operation with context preservation

Conclusion

OpenClaw transformed Claude from a chat tool into an autonomous agent platform. The ability to run persistent, communicating, scheduled agents opens up workflows that were impossible before.

Built with OpenClaw. 5 agents. 1 mission. Infinite automation.

Time and Deadlines in Compact: Block Time, Counters & the Unit<16> Problem

Wilson — Fri, 17 Apr 2026 10:15:42 +0000

Time and Deadlines in Compact: Block Time, Counters & the Unit<16> Problem

A practical guide to writing time-based smart contracts on Midnight Network

Why This Matters

Most smart contracts need time. Auctions end at a deadline. Escrows expire if unclaimed. On traditional chains, you read block.timestamp. On Midnight, privacy changes everything — you can't simply read the timestamp because that would leak information.

Midnight's Compact language provides block time comparison circuits that enforce deadlines without revealing the actual time.

The Block Time API

export circuit isBefore(deadline: Uint<64>): [] {
  return assert(blockTimeLt(disclose(deadline)), "Deadline has passed");
}

export circuit isAtOrAfter(start: Uint<64>): [] {
  return assert(blockTimeGte(disclose(start)), "Start time not yet reached");
}

Function	Returns true when
`blockTimeLt(t)`	block_time < t
`blockTimeGte(t)`	block_time >= t
`blockTimeGt(t)`	block_time > t
`blockTimeLte(t)`	block_time <= t

The Uint<16> Problem

Type	Max Value	Can Hold Unix Timestamp?
`Uint<16>`	65,535	No
`Uint<32>`	4,294,967,295	Yes (until 2106)
`Uint<64>`	18 quintillion	Yes

Always use Uint<64> for timestamps. Current Unix timestamp is ~1.7 billion, far exceeding Uint<16>'s limit.

Practical Pattern: Timed Auction

export circuit placeBid(amount: Uint<64>, deadline: Uint<64>): [] {
  assert(disclose(auctionActive), "Auction not active");
  assert(blockTimeLt(disclose(deadline)), "Auction has ended");
  assert(disclose(amount > highestBid), "Bid too low");
  highestBid = disclose(amount);
}

export circuit endAuction(deadline: Uint<64>): [] {
  assert(blockTimeGte(disclose(deadline)), "Auction not yet ended");
  auctionActive = disclose(false);
}

Workaround: Storing Deadlines On-Chain

Since ledger state is public, split the timestamp:

export ledger deadline_hi: Uint<16>;
export ledger deadline_lo: Uint<16>;

export circuit isBeforeDeadline(): [] {
  let fullTimestamp: Uint<64> = disclose(deadline_hi) * 65536 + disclose(deadline_lo);
  assert(blockTimeLt(disclose(fullTimestamp)), "Deadline passed");
}

Quick Reference

Rule	Why
Use `Uint<64>` for timestamps	Uint<16> max is 65,535 — can't hold Unix timestamp
Always `disclose()` values	Mandatory since Compact v0.16
Use `Counter` for phases	Tracks progression, not wall-clock time
Pass deadlines as parameters	Avoids leaking timing information on-chain

Full tutorial: https://gist.github.com/wilsonhoe/a59c6eb387f1193ca4d7f6c06a7b0c64

Midnight Network tutorial series. Bounty #306.

Concurrent Transactions on Midnight: UTXO Race Conditions & Workarounds

Wilson — Fri, 17 Apr 2026 10:15:11 +0000

Concurrent Transactions on Midnight: UTXO Race Conditions & Workarounds

The Problem: When Two Transactions Collide

You deploy your first Midnight dApp. Everything works in testing — single transactions sail through. Then you go live, and something strange happens: users report transactions randomly failing with "stale UTXO" or "UTXO already consumed."

This is the UTXO race condition. On Midnight (a UTXO-based chain), the same wallet trying to send two transactions simultaneously can break because both try to spend the same coin.

Pattern 1: Sequential Transaction Queue

The simplest fix is to stop sending transactions concurrently. Queue them:

class SequentialTxQueue {
  private queue = [];
  private processing = false;

  enqueue(txFn) {
    return new Promise((resolve, reject) => {
      this.queue.push({ txFn, resolve, reject });
      this.processQueue();
    });
  }

  async processQueue() {
    if (this.processing || this.queue.length === 0) return;
    this.processing = true;
    const { txFn, resolve, reject } = this.queue.shift();
    try {
      const hash = await txFn();
      resolve(hash);
    } catch (error) {
      reject(error);
    } finally {
      this.processing = false;
      this.processQueue();
    }
  }
}

Pattern 2: Multiple Wallet Instances

For higher throughput, spin up multiple wallets. Each wallet has its own UTXO set:

class WalletPool {
  private wallets = [];

  async acquire() {
    const available = this.wallets.find(w => !w.busy);
    if (available) {
      available.busy = true;
      return available;
    }
    return new Promise(resolve => this.waitQueue.push({ resolve }));
  }

  async release(instance) {
    await this.waitForWalletSync(instance.wallet);
    instance.busy = false;
  }
}

Pattern 3: Retry with Fresh UTXOs

Add exponential backoff retry for occasional collisions:

async function submitWithRetry(wallet, buildTx, config = { maxRetries: 3 }) {
  for (let attempt = 0; attempt <= config.maxRetries; attempt++) {
    try {
      await wallet.waitForSync();
      const recipe = await buildTx();
      const proven = await wallet.proveTransaction(recipe);
      return await wallet.submitTransaction(proven);
    } catch (error) {
      if (!isUtxoError(error) || attempt === config.maxRetries) throw error;
      await sleep(Math.min(1000 * 2**attempt, 10000));
    }
  }
}

Key Takeaways

Sequential queue for most dApps — simple, reliable
Wallet pool for high-throughput services
Retry + sync as safety net for all cases
Always sync wallet between transactions

Full tutorial: https://gist.github.com/wilsonhoe/a5766903b8c99f9df222ea322e63418b

Midnight Network tutorial series. Bounty #301.

Understanding Wallet Sync: Why Your Midnight Deploy Fails Before It Starts

Wilson — Fri, 17 Apr 2026 10:06:12 +0000

Understanding Wallet Sync: Why Your Deploy Fails Before It Starts

You just wrote your first Midnight dApp. The code compiles, the proof server is running, you call balanceUnboundTransaction — and nothing happens. Or worse, you get a cryptic error about missing UTXOs. The problem isn't your contract. The problem is that your wallet hasn't synced.

This tutorial explains what wallet sync actually means on Midnight, why skipping it breaks everything, and the exact patterns to ensure your transactions always work.

What Is Wallet Sync?

Midnight's wallet doesn't maintain a live connection to the chain state. Instead, it synchronizes periodically by fetching the latest block data from the indexer. During sync, the wallet:

Downloads new blocks from the indexer since the last sync point
Scans for relevant UTXOs — shielded outputs encrypted to your keys, unshielded tokens in your address, and DUST fee tokens
Updates local state — the wallet's view of which UTXOs it owns and can spend

When sync is complete, state.isSynced === true. When it's not, the wallet's view of the chain is stale. It may not know about UTXOs it just received, or it may try to spend UTXOs that were already consumed.

The Three Sub-Wallets

A Midnight wallet manages three independent sub-wallets, each with its own set of UTXOs and sync requirements:

1. Shielded Sub-Wallet

The shielded wallet holds private tokens. These are encrypted UTXOs that only the wallet owner can decrypt and spend. When someone sends you shielded tokens, the wallet must scan new blocks to discover and decrypt the relevant UTXOs.

Shielded tokens: Private, encrypted UTXOs
Discovery: Requires scanning blocks for encrypted outputs matching your keys
Sync dependency: HIGH — cannot spend what hasn't been decrypted

2. Unshielded Sub-Wallet

The unshielded wallet holds transparent tokens — similar to a regular blockchain address. While these are visible on-chain, the wallet still needs to sync to know the current set of spendable UTXOs.

Unshielded tokens: Transparent, visible on-chain
Discovery: Requires indexing to find UTXOs at your address
Sync dependency: MEDIUM — chain data is public but wallet must still index it

3. DUST Sub-Wallet

DUST is Midnight's fee token. Every transaction costs DUST, and the DUST sub-wallet must have available UTXOs to pay those fees. A wallet generates DUST by holding NIGHT tokens, but the wallet must sync to discover newly generated DUST UTXOs.

DUST tokens: Fee payment capacity, generated by holding NIGHT
Discovery: Requires scanning for DUST UTXOs generated at your address
Sync dependency: CRITICAL — no DUST sync means no fee payment means no transactions

Why All Three Matter

When you call balanceUnboundTransaction, the wallet needs current UTXOs from all applicable sub-wallets to balance the transaction. If any sub-wallet is out of sync:

Unsynced shielded: The wallet may not know it received tokens, causing "insufficient balance" errors for funds that actually exist
Unsynced unshielded: Same problem for transparent tokens
Unsynced DUST: The wallet cannot pay transaction fees, and the transaction fails with a fee error

What Happens When You Skip Sync

Here's the failure cascade when you call balanceUnboundTransaction before sync completes:

Scenario 1: Missing UTXOs

Time 0: Wallet created, sync starts
Time 1: You call balanceUnboundTransaction (sync NOT complete)
Result: Wallet uses stale UTXO set → "insufficient balance" error

The wallet doesn't know about the UTXOs it recently received. It tries to build a transaction with an incomplete set of inputs, and the balancing fails because the inputs don't add up to the required outputs plus fees.

Scenario 2: Double-Spending Stale UTXOs

Time 0: Transaction A submitted, consumes UTXO #1
Time 1: Wallet hasn't re-synced, still thinks UTXO #1 is available
Time 2: You call balanceUnboundTransaction for Transaction B
Result: Wallet tries to spend UTXO #1 again → error 1010 (invalid transaction)

If a previous transaction consumed a UTXO but the wallet hasn't synced to learn about that consumption, it may try to use the same UTXO again. The network rejects this as a double-spend.

Scenario 3: DUST Fee Failure

Time 0: Wallet receives NIGHT tokens, which begin generating DUST
Time 1: You call transact() (DUST sub-wallet not yet synced)
Result: Wallet has no known DUST UTXOs → cannot pay fees → transaction fails

New wallets are especially vulnerable. Until the wallet syncs and discovers its DUST UTXOs, it literally cannot pay for any transaction.

The Known DUST Wallet Bug

There is a known issue with the DUST sub-wallet's sync on idle chains. When the network has low activity, the DUST wallet's isStrictlyComplete() method may hang indefinitely, never resolving to true.

What Happens

The wallet sync process checks whether each sub-wallet has finished processing all relevant blocks. For shielded and unshielded wallets, this check works reliably. But for the DUST sub-wallet on a quiet network:

// This may NEVER resolve on an idle chain:
const state = await wallet.state();
// state.isSynced may stay false indefinitely
// because isStrictlyComplete() hangs waiting for
// DUST-related block data that arrives slowly

The root cause is that isStrictlyComplete() waits for confirmation that all expected DUST-generating events have been processed. On an idle chain, these events are sparse, and the completion signal may not arrive.

Workaround: Use `isSynced` with Timeout

Instead of relying on isStrictlyComplete(), use the isSynced flag with a timeout:

import { filter, take, timeout } from '@midnight-ntwrk/rx';

async function waitForWalletSync(
  wallet: Wallet & Resource,
  timeoutMs: number = 60_000
): Promise<WalletState> {
  try {
    const syncedState = await wallet.state()
      .pipe(
        filter((state: WalletState) => state.isSynced),
        take(1),
        timeout(timeoutMs)
      )
      .toPromise();
    return syncedState;
  } catch (err) {
    // Timeout — wallet may still be partially synced
    // Check current state as a fallback
    const currentState = await wallet.state().pipe(take(1)).toPromise();
    if (currentState.isSynced) {
      return currentState;
    }
    throw new Error(
      `Wallet sync timed out after ${timeoutMs}ms. ` +
      `Current state: synced=${currentState.isSynced}`
    );
  }
}

This pattern:

Waits for isSynced === true with a timeout
Falls back to checking current state if timeout occurs
Throws a clear error if the wallet genuinely can't sync

Alternative: Polling Check

For environments where RxJS observables are awkward, a polling approach works:

async function waitForSyncByPolling(
  wallet: Wallet & Resource,
  maxAttempts: number = 30,
  intervalMs: number = 2000
): Promise<void> {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const state = await new Promise<WalletState>((resolve) => {
      const sub = wallet.state().subscribe({
        next: (s) => {
          sub.unsubscribe();
          resolve(s);
        },
      });
    });

    if (state.isSynced) {
      console.log(`[Sync] Wallet synced after ${attempt + 1} attempts`);
      return;
    }

    await new Promise((resolve) => setTimeout(resolve, intervalMs));
  }

  throw new Error(`Wallet failed to sync after ${maxAttempts} attempts`);
}

The Safe Sync Pattern

Every production Midnight application should follow this pattern:

1. Wait for Sync at Startup

async function initializeApplication(config: AppConfig): Promise<AppContext> {
  const wallet = await createWallet(config.seed, {
    networkId: config.networkId,
    indexer: config.indexer,
    indexerWs: config.indexerWs,
    proofServer: config.proofServer,
    rpc: config.rpc,
  });

  // ALWAYS wait for sync before accepting requests
  console.log('[Startup] Waiting for wallet sync...');
  const syncedState = await waitForWalletSync(wallet, 60_000);
  console.log('[Startup] Wallet synced. Address:', wallet.ownPublicKey().toString());

  const providers = createProviders(wallet);

  return { wallet, providers, syncedState };
}

2. Check Sync Before Every Transaction

async function submitWithSyncCheck(
  wallet: Wallet & Resource,
  operation: () => Promise<Transaction>
): Promise<SubmitResult> {
  // Verify wallet is synced before starting
  const state = await wallet.state().pipe(take(1)).toPromise();

  if (!state.isSynced) {
    console.warn('[Sync] Wallet not synced, waiting...');
    await waitForWalletSync(wallet, 30_000);
  }

  // Now safe to transact
  return submitContractTransaction(wallet, providers, operation);
}

3. Re-Sync After Failures

When a transaction fails with a UTXO-related error, re-sync before retrying:

async function transactWithRetry(
  wallet: Wallet & Resource,
  operation: () => Promise<Transaction>,
  maxRetries: number = 3
): Promise<SubmitResult> {
  let lastError: Error | null = null;

  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    try {
      // Re-sync on retries (not on first attempt, we already synced)
      if (attempt > 0) {
        console.log(`[Retry ${attempt}] Re-syncing wallet...`);
        await waitForWalletSync(wallet, 30_000);
      }

      return await submitWithSyncCheck(wallet, operation);
    } catch (error) {
      lastError = error instanceof Error ? error : new Error(String(error));

      // Don't retry logic errors
      if (isLogicError(lastError)) {
        throw lastError;
      }

      console.warn(`[Retry ${attempt}] Transaction failed: ${lastError.message}`);
    }
  }

  throw lastError;
}

function isLogicError(error: Error): boolean {
  return (
    error.message.includes('insufficient') ||
    error.message.includes('circuit') ||
    error.message.includes('proof')
  );
}

Sync in the Prove-Balance-Submit Pipeline

The complete transaction pipeline with sync checks looks like this:

┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  0. SYNC     │────→│  1. TRANSACT │────→│  2. PROVE    │────→│  3. BALANCE  │
│  wallet.state│     │  create tx   │     │  proveTx    │     │  balance tx  │
│  isSynced?   │     │              │     │              │     │              │
└──────────────┘     └──────────────┘     └──────────────┘     └──────────────┘
                                                                     │
                                                             ┌───────▼───────┐
                                                             │  4. SUBMIT    │
                                                             │  submitTx     │
                                                             │               │
                                                             └───────────────┘

Step 0 is the sync check. Without it, steps 1–4 operate on stale data.

Practical Monitoring

For production backends, monitor wallet sync health continuously:

import { filter, take } from '@midnight-ntwrk/rx';

class SyncMonitor {
  private lastSyncTime: Date | null = null;
  private isSynced: boolean = false;

  start(wallet: Wallet & Resource, alertCallback: (msg: string) => void): void {
    wallet.state().subscribe({
      next: (state) => {
        const wasSynced = this.isSynced;
        this.isSynced = state.isSynced;

        if (state.isSynced && !wasSynced) {
          this.lastSyncTime = new Date();
          console.log('[SyncMonitor] Wallet synced at', this.lastSyncTime.toISOString());
        } else if (!state.isSynced && wasSynced) {
          console.warn('[SyncMonitor] Wallet desynced');
          alertCallback('Wallet lost sync — transactions may fail');
        }
      },
      error: (err) => {
        console.error('[SyncMonitor] State subscription error:', err);
        alertCallback(`Wallet state error: ${err.message}`);
      },
    });
  }

  getStatus(): { isSynced: boolean; lastSyncTime: Date | null } {
    return {
      isSynced: this.isSynced,
      lastSyncTime: this.lastSyncTime,
    };
  }
}

Integrate this into your health check endpoint:

app.get('/health', (_req, res) => {
  const syncStatus = syncMonitor.getStatus();
  res.json({
    status: 'ok',
    walletSynced: syncStatus.isSynced,
    lastSyncTime: syncStatus.lastSyncTime?.toISOString() ?? null,
  });
});

Common Pitfalls

Pitfall 1: Ignoring Sync on Startup

// WRONG: Immediately accepting requests
const wallet = await createWallet(seed, config);
app.listen(3000); // Wallet may not be synced yet!

// RIGHT: Wait for sync before serving traffic
const wallet = await createWallet(seed, config);
await waitForWalletSync(wallet, 60_000);
app.listen(3000);

Pitfall 2: Not Re-Syncing After Failures

When a transaction fails with "insufficient balance" or "invalid transaction", the wallet's UTXO set may be stale. Re-sync before retrying:

// WRONG: Retry immediately with stale state
for (let i = 0; i < 3; i++) {
  try { return await transact(); } catch { continue; }
}

// RIGHT: Re-sync between retries
for (let i = 0; i < 3; i++) {
  try {
    return await transact();
  } catch (error) {
    if (i < 2) {
      await waitForWalletSync(wallet, 30_000); // Re-sync
    }
  }
}

Pitfall 3: Assuming isSynced Stays True

Sync is not permanent. The wallet can fall out of sync if:

The indexer connection drops
The network has a reorganization
The wallet process was paused or slept

Monitor the sync state continuously, not just at startup.

Pitfall 4: Using the Wrong Sync Method

// WRONG: This returns the CURRENT state snapshot, not a promise that resolves
// when sync completes. If the wallet isn't synced, this returns immediately
// with isSynced = false.
const state = await wallet.state().pipe(take(1)).toPromise();
if (!state.isSynced) {
  // Wallet is NOT synced. Do not transact.
}

// RIGHT: Wait for sync to complete
const syncedState = await wallet.state()
  .pipe(
    filter((s: WalletState) => s.isSynced),
    take(1)
  )
  .toPromise();

Startup Health Check Integration

Combine wallet sync waiting with proof server health checks for a robust startup sequence:

async function startServer(): Promise<void> {
  // 1. Check proof server
  console.log('[Startup] Checking proof server...');
  const proofServerHealthy = await checkProofServerHealth();
  if (!proofServerHealthy) {
    throw new Error('Proof server is not reachable');
  }

  // 2. Initialize wallet
  console.log('[Startup] Initializing wallet...');
  const wallet = await createWallet(seed, walletConfig);

  // 3. Wait for sync (with DUST bug workaround)
  console.log('[Startup] Waiting for wallet sync...');
  const syncedState = await waitForWalletSync(wallet, 60_000);
  console.log('[Startup] Wallet synced:', {
    address: wallet.ownPublicKey().toString(),
    isSynced: syncedState.isSynced,
  });

  // 4. Start accepting requests
  app.listen(3000, () => {
    console.log('[Server] Ready on port 3000');
  });
}

Summary

Pattern	When to Use	Key Code
Startup sync wait	App initialization	`wallet.state().pipe(filter(s => s.isSynced), take(1)).toPromise()`
Pre-transaction check	Before every `balanceUnboundTransaction`	Check `state.isSynced` first
Re-sync on failure	After UTXO-related errors	Re-call `waitForWalletSync` before retry
Continuous monitoring	Production health checks	`wallet.state().subscribe(...)`
Timeout workaround	DUST wallet hang on idle chains	Use `timeout()` RxJS operator

The rule is simple: never call balanceUnboundTransaction without confirming isSynced === true first. If you follow this pattern, you'll avoid the most common class of Midnight deployment failures.

DUST Sponsorship on Midnight: How One Wallet Pays Fees for Another

Wilson — Fri, 17 Apr 2026 10:05:29 +0000

DUST Sponsorship on Midnight: How One Wallet Pays Fees for Another

The Problem: Users Without DUST Can't Transact

Midnight's privacy model relies on DUST — a shielded network resource, not a token, that pays for transaction fees. Every transaction consumes DUST. But here's the catch: new users start with zero DUST, and generating it requires holding NIGHT tokens through a multi-day lifecycle.

This creates a cold-start problem. How does a brand-new user submit their first transaction if they don't have DUST to pay fees?

The answer is DUST sponsorship: one wallet (the sponsor) pays the DUST fees for another user's transaction. This tutorial shows you exactly how.

Understanding DUST: Not a Token, a Resource

Before diving into sponsorship, you need to understand what DUST actually is.

DUST Is a Shielded Capacity Resource

DUST is generated by holding NIGHT tokens. It is not an ERC-20 token, not a fungible asset you can send between addresses. It's a capacity resource — like bandwidth allocation — that exists within the shielded context of a wallet.

Key parameters on the Preview network:

Parameter	Value	Meaning
`night_dust_ratio`	5,000,000,000	5 DUST per NIGHT held
`generation_decay_rate`	8,267	~1 week to decay from max to zero
`dust_grace_period`	3 hours	Grace period after DUST hits zero

The DUST Lifecycle

DUST follows four phases:

Generating — DUST accumulates while NIGHT is held, growing toward a maximum proportional to your NIGHT balance.
Constant (Max) — DUST has reached its cap and stays constant.
Decaying — After NIGHT is moved or spent, DUST decays over approximately one week.
Zero — DUST is fully depleted. A 3-hour grace period allows one final transaction.

Three Wallet Addresses

On the Preview network, each wallet has three addresses:

┌─────────────────────────────────┐
│  Wallet                         │
│  ├── Shielded Address            │  ← Privacy transactions
│  ├── Unshielded Address         │  ← Public transactions
│  └── DUST Address                │  ← Fee capacity resource
└─────────────────────────────────┘

A new wallet has no DUST. Without sponsorship, it cannot submit any transaction that requires fees.

The Sponsorship Flow: Three Steps

DUST sponsorship uses a specific sequence of Midnight SDK calls. The core idea is to split transaction balancing into two phases: the user balances their own shielded/unshielded tokens, then the sponsor balances the DUST portion.

Step 1: User Creates and Balances Without DUST

The user creates their transaction and balances it, explicitly excluding DUST from the balancing scope:

// User creates the transaction
const transaction = await userWallet.transact()

// User balances only shielded and unshielded tokens
// The key parameter is tokenKindsToBalance — omit 'dust'
const userRecipe = await userWallet.balanceUnboundTransaction(
  transaction,
  {
    shieldedSecretKeys: userShieldedKeys,
    dustSecretKey: userDustKey,
  },
  {
    ttl: new Date(Date.now() + 30 * 60 * 1000), // 30 min TTL
    tokenKindsToBalance: ['shielded', 'unshielded'], // ← NO 'dust'
  }
);

// User signs and finalizes their part
const userSigned = await userWallet.signRecipe(
  userRecipe,
  (payload) => userKeystore.signData(payload)
);
const userFinalized = await userWallet.finalizeRecipe(userSigned);

The tokenKindsToBalance parameter is the critical piece. By excluding 'dust', the user says "I'm not paying DUST fees — someone else will."

Step 2: Sponsor Adds DUST Fees

The sponsor takes the user's finalized transaction and adds DUST fees:

// Sponsor receives userFinalized from Step 1 (via API, message queue, etc.)
const sponsorRecipe = await sponsorWallet.balanceFinalizedTransaction(
  userFinalized,
  {
    shieldedSecretKeys: sponsorShieldedKeys,
    dustSecretKey: sponsorDustKey,
  },
  {
    ttl: new Date(Date.now() + 30 * 60 * 1000),
    tokenKindsToBalance: ['dust'], // ← ONLY 'dust'
  }
);

// Sponsor signs and finalizes
const sponsorSigned = await sponsorWallet.signRecipe(
  sponsorRecipe,
  (payload) => sponsorKeystore.signData(payload)
);
const sponsorFinalized = await sponsorWallet.finalizeRecipe(sponsorSigned);

Here, tokenKindsToBalance: ['dust'] means the sponsor is only paying for the DUST portion. They are not re-balancing shielded or unshielded tokens.

Step 3: Sponsor Submits

The sponsor submits the fully balanced transaction to the network:

const txHash = await sponsorWallet.submitTransaction(sponsorFinalized);
console.log(`Transaction submitted: ${txHash}`);

The transaction is now fully balanced — the user's tokens are accounted for, and the sponsor's DUST covers the fees.

Sponsor Service Architecture

For production use, you need a sponsor service that receives user transactions, adds DUST fees, and submits them. Here's a complete architecture:

┌────────────┐         ┌──────────────────┐         ┌─────────────┐
│  User App  │ ──POST──→│  Sponsor Service │ ──TX───→│  Midnight   │
│            │         │                  │         │  Network    │
│  (no DUST) │←──200───│  (has DUST)      │         │             │
└────────────┘         └──────────────────┘         └─────────────┘
                              │
                              ├── balanceFinalizedTransaction
                              ├── signRecipe
                              ├── finalizeRecipe
                              └── submitTransaction

The sponsor service holds a wallet with sufficient DUST and exposes an API for users to submit their partially-balanced transactions.

Sponsor Service Implementation

import express from 'express';
import { Wallet, Resource } from '@midnight-ntwrk/wallet-api';
import { CoinPublicKey, EncPublicKey } from '@midnight-ntwrk/types';

const app = express();
app.use(express.json());

let sponsorWallet: Wallet & Resource;
let sponsorKeystore: { signData: (payload: Uint8Array) => Promise<Uint8Array> };

// Initialize sponsor wallet at startup
async function initSponsorWallet() {
  // ... wallet initialization with NIGHT-holding seed phrase
  // Ensure wallet has DUST capacity
}

// POST /sponsor — receive user's finalized transaction and sponsor it
app.post('/sponsor', async (req, res) => {
  try {
    const { userFinalized } = req.body;

    // Step 2: Sponsor adds DUST fees
    const sponsorRecipe = await sponsorWallet.balanceFinalizedTransaction(
      userFinalized,
      {
        shieldedSecretKeys: sponsorShieldedKeys,
        dustSecretKey: sponsorDustKey,
      },
      {
        ttl: new Date(Date.now() + 30 * 60 * 1000),
        tokenKindsToBalance: ['dust'],
      }
    );

    const sponsorSigned = await sponsorWallet.signRecipe(
      sponsorRecipe,
      (payload) => sponsorKeystore.signData(payload)
    );
    const sponsorFinalized = await sponsorWallet.finalizeRecipe(sponsorSigned);

    // Step 3: Submit
    const txHash = await sponsorWallet.submitTransaction(sponsorFinalized);

    res.json({ success: true, txHash });
  } catch (error) {
    console.error('Sponsorship failed:', error);
    res.status(500).json({ success: false, error: String(error) });
  }
});

app.listen(3001, () => console.log('Sponsor service running on port 3001'));

Advanced: Key Override Pattern

In some architectures, the sponsor wallet handles both balanceTx() and submitTx(), while a separate prover wallet generates the zero-knowledge proofs. This is the key override pattern.

How Key Override Works

When using key override, the sponsor wallet's balanceTx() and submitTx() calls use an external prover wallet for proof generation, while the sponsor wallet still handles the actual fee payment and submission.

// The prover's wallet — generates ZK proofs
let externalProverWallet: (Wallet & Resource) | null = null;

// Override keys pointing to the prover
let overrideKeys: {
  coinPublicKey?: CoinPublicKey;
  encryptionPublicKey?: EncPublicKey;
} = {};

// When the sponsor calls ownPublicKey(), it returns the PROVER's key
// because the override is active:
// ownPublicKey() → overrideKeys.coinPublicKey ?? wallet.coinPublicKey

Key Override in Practice

// Provider that routes proof generation to the external prover
const providerWithOverride = {
  ...baseProvider,
  async proveTransaction(tx: Transaction) {
    if (externalProverWallet) {
      return externalProverWallet.proveTransaction(tx);
    }
    return baseProvider.proveTransaction(tx);
  },
};

// The sponsor wallet uses this provider
// balanceTx() → calls providerWithOverride.proveTransaction()
//               which routes to the external prover wallet
// submitTx() → uses the sponsor wallet's own submission path

Important: `ownPublicKey()` Behavior

When key override is active, ownPublicKey() returns the prover's coinPublicKey, not the sponsor's. This matters for:

Address derivation — the transaction appears to come from the prover's address
UTXO ownership — outputs are owned by the prover's keys
Balance queries — must query the prover's address, not the sponsor's

// Without override:
wallet.ownPublicKey() // → wallet's own coinPublicKey

// With override:
wallet.ownPublicKey() // → overrideKeys.coinPublicKey (the prover's key)

Common Mistakes

Mistake 1: Balancing All Token Kinds at Once

// WRONG — this fails if the user has no DUST
const recipe = await userWallet.balanceUnboundTransaction(
  transaction,
  keys,
  { tokenKindsToBalance: ['shielded', 'unshielded', 'dust'] }
  //                                         ^^^^^^^^ user has no DUST!
);

Fix: The user must exclude 'dust' from their balancing. The sponsor adds it separately.

Mistake 2: Re-balancing Token Types the User Already Balanced

// WRONG — re-balances shielded/unshielded that the user already handled
const sponsorRecipe = await sponsorWallet.balanceFinalizedTransaction(
  userFinalized,
  keys,
  { tokenKindsToBalance: ['dust', 'shielded', 'unshielded'] }
  //                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unnecessary
);

Fix: The sponsor should only balance 'dust'. Re-balancing other token types can cause double-spending errors.

Mistake 3: Ignoring TTL Expiry

// WRONG — no TTL or TTL too short
const recipe = await sponsorWallet.balanceFinalizedTransaction(
  userFinalized, keys, { tokenKindsToBalance: ['dust'] }
  // No TTL! Transaction might expire before submission.
);

Fix: Always set a reasonable TTL (15–30 minutes) for both user and sponsor balancing steps.

Mistake 4: Assuming DUST Is a Transferable Token

DUST cannot be sent from one address to another like a regular token. It is generated from NIGHT holdings and consumed as a resource. There is no transferDUST() function. The only way to pay DUST for another user's transaction is through the sponsorship flow described above.

DUST Regeneration

When a sponsor's DUST is consumed, it regenerates over time based on their NIGHT holdings. Understanding the regeneration timeline helps size your sponsorship service:

DUST Level
    │
Max ┤████████████████████████████████
    │                                  ╲
    │                                    ╲
    │                                      ╲
    │                                        ╲
    │                                          ╲
  0 ┤──────────────────────────────────────────────╳
    │← Generation →← Constant →← Decay (≈1 week) →│Zero
    │                                                │← Grace (3h)→│

Sizing Your Sponsor Wallet

Preview network: 5 DUST per NIGHT per generation cycle
Decay time: ~1 week from max to zero
Each transaction consumes a small amount of DUST (typically 0.001–0.01 DUST)
Rule of thumb: A wallet holding 100 NIGHT can sponsor approximately 50,000–500,000 transactions before needing regeneration

For a production sponsor service, hold enough NIGHT to generate DUST well above your projected transaction volume, and monitor DUST levels to replenish before hitting the decay phase.

Complete Working Example

See the companion files in src/:

sponsor-service.ts — Full sponsor service with Express API, wallet initialization, and sponsorship endpoint
user-client.ts — Client-side code that creates a transaction, balances without DUST, and sends it to the sponsor
sponsor-wallet.ts — Sponsor wallet setup with DUST monitoring and auto-replenishment

Quick Start

# Install dependencies
npm install @midnight-ntwrk/wallet-api @midnight-ntwrk/types express

# Set environment variables
export SPONSOR_SEED_PHRASE="your twelve word seed phrase here"
export NETWORK_ID="0"  # Preview network
export RPC_URL="https://rpc.midnight.network"
export INDEXER_URL="https://indexer.midnight.network"

# Run the sponsor service
npx tsx src/sponsor-service.ts

Testing the Flow

// In a separate script or browser
import { createSponsorshipClient } from './user-client';

const client = createSponsorshipClient('http://localhost:3001');

// 1. User creates and balances their transaction (without DUST)
const userFinalized = await client.prepareTransaction();

// 2. Send to sponsor service for DUST sponsorship
const result = await client.sponsorTransaction(userFinalized);

console.log(`Transaction confirmed: ${result.txHash}`);

Security Considerations

Validate user transactions — Your sponsor service should verify that incoming transactions are legitimate before paying DUST fees. Implement rate limiting and transaction content validation.
Monitor DUST levels — A sponsor wallet can run out of DUST. Implement monitoring and alerting to ensure you always have sufficient DUST capacity.
Protect sponsor keys — The sponsor's seed phrase controls NIGHT holdings and DUST generation. Store it securely (environment variables, HSM, or secret management service).
Set transaction TTLs — Always set reasonable TTLs (15–30 minutes) to prevent stale transactions from consuming sponsor DUST.
Implement idempotency — Use transaction hashes to prevent duplicate sponsorship of the same transaction.

Summary

Concept	Key Point
DUST	Shielded resource, not a token; generated from NIGHT
Cold-start problem	New users have no DUST to pay fees
`balanceUnboundTransaction`	User balances shielded/unshielded only
`balanceFinalizedTransaction`	Sponsor adds DUST fees
`tokenKindsToBalance`	Controls which token types each party balances
Key override	Prover wallet generates proofs; sponsor wallet pays and submits
`ownPublicKey()`	Returns prover's key when override is active
DUST regeneration	~1 week decay; 3-hour grace period at zero
Production pattern	Sponsor service with Express API, monitoring, rate limiting

DUST sponsorship solves the cold-start problem on Midnight. By splitting the balancing responsibility between user and sponsor, new wallets can transact immediately without needing their own NIGHT holdings or DUST generation capacity.

DEV Community: Wilson

OpenClaw in Action: How I Built a Multi-Agent Command Center with 5 Autonomous Claude Sessions

OpenClaw in Action: How I Built a Multi-Agent Command Center with 5 Autonomous Claude Sessions

What I Built

System Architecture

Why OpenClaw Made This Possible

Real-World Use Cases

1. Midnight Tutorial Pipeline

2. Technical Writing Dashboard

3. Security Monitoring

4. Multi-Channel Delivery

Challenges Solved

Results

Conclusion

Time and Deadlines in Compact: Block Time, Counters & the Unit<16> Problem

Time and Deadlines in Compact: Block Time, Counters & the Unit<16> Problem

Why This Matters

The Block Time API

The Uint<16> Problem

Practical Pattern: Timed Auction

Workaround: Storing Deadlines On-Chain

Quick Reference

Concurrent Transactions on Midnight: UTXO Race Conditions & Workarounds

Concurrent Transactions on Midnight: UTXO Race Conditions & Workarounds

The Problem: When Two Transactions Collide

Pattern 1: Sequential Transaction Queue

Pattern 2: Multiple Wallet Instances

Pattern 3: Retry with Fresh UTXOs

Key Takeaways

Understanding Wallet Sync: Why Your Midnight Deploy Fails Before It Starts

Understanding Wallet Sync: Why Your Deploy Fails Before It Starts

What Is Wallet Sync?

The Three Sub-Wallets

1. Shielded Sub-Wallet

2. Unshielded Sub-Wallet

3. DUST Sub-Wallet

Why All Three Matter

What Happens When You Skip Sync

Scenario 1: Missing UTXOs

Scenario 2: Double-Spending Stale UTXOs

Scenario 3: DUST Fee Failure

The Known DUST Wallet Bug

What Happens

Workaround: Use isSynced with Timeout

Alternative: Polling Check

The Safe Sync Pattern

1. Wait for Sync at Startup

2. Check Sync Before Every Transaction

3. Re-Sync After Failures

Sync in the Prove-Balance-Submit Pipeline

Practical Monitoring

Common Pitfalls

Pitfall 1: Ignoring Sync on Startup

Pitfall 2: Not Re-Syncing After Failures

Pitfall 3: Assuming isSynced Stays True

Pitfall 4: Using the Wrong Sync Method

Startup Health Check Integration

Summary

DUST Sponsorship on Midnight: How One Wallet Pays Fees for Another

DUST Sponsorship on Midnight: How One Wallet Pays Fees for Another

The Problem: Users Without DUST Can't Transact

Understanding DUST: Not a Token, a Resource

DUST Is a Shielded Capacity Resource

The DUST Lifecycle

Three Wallet Addresses

The Sponsorship Flow: Three Steps

Step 1: User Creates and Balances Without DUST

Step 2: Sponsor Adds DUST Fees

Step 3: Sponsor Submits

Sponsor Service Architecture

Sponsor Service Implementation

Advanced: Key Override Pattern

How Key Override Works

Key Override in Practice

Important: ownPublicKey() Behavior

Common Mistakes

Mistake 1: Balancing All Token Kinds at Once

Mistake 2: Re-balancing Token Types the User Already Balanced

Mistake 3: Ignoring TTL Expiry

Mistake 4: Assuming DUST Is a Transferable Token

Workaround: Use `isSynced` with Timeout

Important: `ownPublicKey()` Behavior